Решения
Инвентаризация скриптов платёжной страницы как рабочий процесс
Превратите фактически исполняемые на странице оплаты скрипты в управляемый реестр: источник, владелец, назначение, статус авторизации, способ контроля целостности, дата проверки и история доказательств.
Для владельцев PCI DSS, AppSec, e-commerce-разработки и команд, которые готовят материалы для QSA и не хотят ограничиваться разовой таблицей.
На какие вопросы отвечает реестр
Какие собственные и сторонние скрипты исполняются в каждом платёжном сценарии?
Кто владеет и авторизовал каждый скрипт и зачем он нужен бизнесу?
Как контролируется целостность или подлинность и когда проводилась последняя проверка?
Что изменилось относительно утверждённого состояния и как обработали изменение?
Обновлено: 26 июля 2026 г.
Основа проверки
Материал сверён с PCI DSS v4.0.1 и руководством PCI SSC по защите платёжных страниц. Примеры помогают внедрению, но не являются форматом API Cartelta или заранее согласованным аудитором дизайном контроля.
Фактический инвентарь
Исходной точкой служат реальная страница, DOM, менеджер тегов и загружаемые сторонние источники, а не только плановый список файлов.
Владельцы и обоснование
У каждой записи есть ответственный, бизнес-назначение, статус авторизации и периодичность пересмотра.
Проверяемые доказательства
Снимки, решения, исключения и история изменений доступны для внутренней проверки и QSA.
Сначала определите состав проверяемого инвентаря
Полноту реестра можно оценить только относительно заданного состава. Начните с одного платёжного сценария и перечислите состояния, меняющие загрузку в браузере: локаль, мобильный вариант, выбор согласия, гостевая или авторизованная оплата, ответ провайдера, ошибка валидации и ветка менеджера тегов.
Для каждого состояния сохраните URL или маршрут, способ наблюдения, время теста, контекст браузера и результат прохождения. Тогда аккуратный реестр не скроет непроверенную ветку оплаты.
- Учитывайте inline-код, модули, workers, дочерние скрипты менеджера тегов и загрузку после действия пользователя.
- Сохраняйте цепочку загрузчиков, а не только конечный URL, чтобы было понятно, какая система или правило добавили объект.
- Не исключайте молча недоступные состояния: назначьте владельца и срок повторной проверки.
Почему статичная таблица быстро устаревает
Платёжная страница меняется не только через основной релиз приложения. Маркетинговые теги, платформы управления согласием, платёжные виджеты, CDN-ресурсы и правила менеджера тегов могут изменить набор скриптов, который видит клиент, без изменения репозитория приложения.
Поэтому полезный инвентарь начинается с наблюдения в браузере и сверяется с утверждённым реестром. Реестр остаётся документом управления, а наблюдение подтверждает, что он соответствует фактической странице.
Минимальная модель данных для каждого скрипта
Одного URL недостаточно для требования 6.4.3. Запись должна давать проверяющему контекст, позволяющий определить ожидаемость, авторизацию, необходимость и способ контроля скрипта.
- Платёжный сценарий и страница, на которой исполняется скрипт.
- Собственный или сторонний источник, загрузчик и связь с менеджером тегов.
- Бизнес-назначение, технический владелец, согласующая роль и дата авторизации.
- Способ контроля целостности или подлинности, статус проверки и ссылка на исключение.
- Даты первого и последнего наблюдения, изменения и связанный артефакт или инцидент.
Выберите способ контроля, подходящий модели доставки
Subresource Integrity полезен для стабильного стороннего ресурса, точные байты и заголовки доставки которого контролируются. Но это не универсальное решение: скрипты поставщика, меняющиеся по одному URL, inline-код, динамические пакеты и цепочки загрузчиков требуют документированной альтернативы или сочетания методов.
В записи укажите выбранный способ и обоснование: контролируемая сборка и хеш релиза, цифровая подпись, строгая политика источников и nonce, подтверждение провайдера, мониторинг содержимого или комбинация мер. Формулировки «закрыто CSP» недостаточно без политики, режима применения, исключений и доказательств.
Связь реестра с управлением изменениями
Новый или изменённый скрипт должен проходить тот же управляемый путь, что и изменение в рабочей среде: заявка, владелец, обоснование, техническая проверка, согласование, выпуск и проверка после релиза. Экстренному изменению нужен последующий пересмотр, а не бессрочное недокументированное исключение.
У инвентаря также должен быть владелец периодического контроля. Он разбирает устаревшие записи, скрипты без ответственной команды, неиспользуемые интеграции и расхождения между реестром и живым платёжным сценарием.
Проверяйте контроль, а не количество строк
Большой реестр может не работать. Проверьте, обнаруживается ли контролируемо добавленный скрипт, нельзя ли согласовать запись без владельца, корректно ли штатный релиз обновляет поля и сохраняется ли история после удаления интеграции.
Практический критерий завершения: независимый проверяющий выбирает любой наблюдаемый скрипт и без устных пояснений находит сценарий, загрузчик, владельца, необходимость, согласование, решение по целостности, текущий статус и исходное доказательство.
Содержание
Соберите запись, выдерживающую независимую проверку
Шаблон намеренно подробнее обычного списка URL. Заполните его по наблюдаемому состоянию платёжной страницы, затем подтвердите бизнес-необходимость и способ контроля у владельца и согласующей роли.
Критерий готовности
Управляемый реестр одного платёжного сценария, сверенный с живым состоянием браузера, без необъяснённых скриптов и с воспроизводимой ссылкой на доказательство каждого согласования или исключения.
01
Перечислите значимые состояния
Зафиксируйте варианты оплаты, согласия, ответы провайдера, локали и действия, меняющие набор исполняемых скриптов.
02
Наблюдайте объект и загрузчик
Сохраните ресурс, тип inline или external, родительский загрузчик, источник, первое наблюдение и состояние страницы.
03
Определите владельцев до согласования
Назначьте технического и бизнес-владельца. Значение «неизвестно» означает исключение и расследование, а не завершённую запись.
04
Обоснуйте необходимость и контроль
Опишите функцию скрипта на странице оплаты и способ контроля, подходящий модели доставки, включая ограничения и исключения.
05
Сверяйте после изменений
После релизов и существенных изменений третьих сторон сравните фактический состав и сохраните решение о согласовании, удалении или инциденте.
Пример управляемой записи
Названия полей иллюстративны. Платёжные значения, cookie, токены и идентификаторы клиентов в запись не включаются.
{
"record_id": "script-042",
"journey": "checkout-card-entry",
"page_state": "default-consent",
"observed_url": "https://cdn.example.test/payment-sdk.js",
"loaded_by": "tag-manager:container-7",
"purpose": "Render hosted payment fields",
"technical_owner": "payments-engineering",
"business_owner": "checkout-product-owner",
"authorization": {
"status": "approved",
"reference": "CHG-1842"
},
"integrity_method": {
"method": "provider-controlled delivery plus monitored change",
"reference": "CTRL-643-07"
},
"last_reviewed": "2026-07-26",
"evidence_reference": "EVID-643-2026-07"
}Шаблон реестра скриптов платёжной страницы
CSV с полями сценария, состояния, загрузчика, владельцев, авторизации, целостности, проверки, исключения и доказательств.
CSV · UTF-8 · одна явно обозначенная примерная строка
Это нейтральный шаблон внедрения. Настройте роли, способы контроля, сроки хранения и статусы согласования под проверяемую среду.
Рабочий процесс инвентаризации
Последовательность связывает наблюдение в браузере, бизнес-авторизацию и доказательства для проверки.
01
Наблюдение
Собрать скрипты и загрузчики из фактического платёжного сценария.
02
Классификация
Определить источник, назначение, страницу, владельца и зависимость.
03
Авторизация
Зафиксировать согласование, обоснование и способ контроля целостности.
04
Сравнение
Сверить живую страницу с утверждённым реестром и эталонным состоянием.
05
Пересмотр
Закрыть исключения и сохранить решение вместе с доказательствами.
Пример полей инвентаря
Пример показывает необходимый уровень контекста и не описывает инфраструктуру конкретного заказчика.
| # | Наблюдаемый объект | Назначение и владелец | Авторизация | Контроль и пересмотр |
|---|---|---|---|---|
| 01 | Собственный пакет страницы оплаты | Проверка оплаты — команда электронной коммерции | Ссылка на согласованный релиз | Хеш/подпись релиза; проверка после выпуска |
| 02 | SDK платёжного провайдера | Hosted payment component — платёжная команда | Согласованы провайдер и версия | Разрешённый список источников и проверка наблюдаемой версии |
| 03 | Аналитика из менеджера тегов | Измерение конверсии — владелец маркетинга | Задокументированы необходимость и область применения | Управление контейнером и сравнение живой страницы |
| 04 | Inline-загрузчик страницы оплаты | Запуск собственного платёжного сценария — команда платформы | Согласованный релиз приложения | Контролируемая сборка и сравнение с эталоном |
| 05 | Неизвестный дочерний скрипт | Назначение и владелец не определены | Не согласован; открыто исключение | Проверить загрузчик, при необходимости ограничить, сохранить решение |
Точный набор полей, способы контроля и согласующие роли должны соответствовать оцениваемой среде и внутреннему дизайну контроля.
Инвентарь — это доказательство, но не автоматическое соответствие
Cartelta может поддержать наблюдение, назначение владельцев, историю изменений и подготовку артефактов. Организация и её аудитор отвечают за область применимости, устройство контроля, согласования, операционную эффективность и итоговый вывод о соответствии.
Вопросы об инвентаризации скриптов
Нет. Нужно учитывать скрипты, загружаемые и исполняемые в контексте платёжной страницы, включая сторонние источники и динамические теги в пределах оцениваемой области.
Да, но его необходимо сверять с фактической загрузкой в браузере. Ручной список быстро теряет точность, когда менеджер тегов, виджеты, CDN и сторонние зависимости меняются независимо.
Задокументируйте такую модель доставки и выберите меры, которые позволяют ограничить или обнаружить неавторизованное изменение. Это может быть сочетание управления поставщиком, ограничений источников, наблюдения содержимого, координации релизов и исключений; SRI непрактичен, если согласованные байты непредсказуемо меняются.
Оно описывает конкретную функцию на платёжной странице, необходимость именно в этом сценарии, владельца принимаемого риска и последствия удаления. Фраза «нужно бизнесу» не помогает оператору или аудитору оценить необходимость.
Первичные источники PCI SSC
Сначала проверьте один платёжный сценарий
В рамках сфокусированного пилота можно сравнить утверждённый реестр со скриптами, которые фактически исполняются на странице оплаты.
Обсудить пилот инвентаризации