Решения
Инвентаризация скриптов платёжной страницы
Ведите реестр скриптов, которые фактически выполняются на странице оплаты. Для каждого укажите источник, ответственного, бизнес-назначение, согласование на использование, способ контроля целостности и дату проверки. Сохраняйте историю изменений и подтверждающие записи.
Для владельцев PCI DSS, AppSec, e-commerce-разработки и команд, которые готовят материалы для QSA и не хотят ограничиваться разовой таблицей.
На какие вопросы отвечает реестр
Какие собственные и сторонние скрипты исполняются в каждом платёжном сценарии?
Кто владеет и авторизовал каждый скрипт и зачем он нужен бизнесу?
Как контролируется целостность или подлинность и когда проводилась последняя проверка?
Что изменилось относительно утверждённого состояния и как обработали изменение?
Обновлено: 1 августа 2026 г.
Основа проверки
Материал сверён с PCI DSS v4.0.1 и руководством PCI SSC по защите платёжных страниц. Примеры помогают внедрению, но не являются форматом API Cartelta или заранее согласованным аудитором дизайном контроля.
Фактический состав скриптов
Зафиксируйте скрипты, которые действительно загружаются и выполняются на странице оплаты, включая скрипты сторонних сервисов и менеджеров тегов.
Ответственные и обоснование использования
Для каждого скрипта укажите ответственного, назначение, согласование на использование и срок следующей проверки.
Доказательства для внутренней проверки и QSA
Сохраняйте историю изменений платёжной страницы, чтобы команда и аудитор могли проверить, что изменилось и когда.
Определение состава платежной страницы
Определите шаги и варианты оплаты, которые входят в проверку. Для каждого зафиксируйте выполняемые скрипты, адреса источников, хеш-суммы, способ и порядок загрузки.
Учитывайте варианты, меняющие состав скриптов: мобильную версию, выбор согласия, оплату с авторизацией и без неё, ответы платёжного провайдера. Сохраняйте время и результат проверки; непроверенные варианты отмечайте отдельно.
- Учитывайте inline-код, модули, workers, дочерние скрипты менеджера тегов и загрузку после действия пользователя.
- Сохраняйте цепочку загрузчиков, а не только конечный URL, чтобы было понятно, какая система или правило добавили объект.
- Не исключайте молча недоступные состояния: назначьте владельца и срок повторной проверки.
Почему статичная таблица быстро устаревает
Платёжная страница меняется не только через основной релиз приложения. Маркетинговые теги, платформы управления согласием, платёжные виджеты, CDN-ресурсы и правила менеджера тегов могут изменить набор скриптов, который видит клиент, без изменения репозитория приложения.
Поэтому полезный инвентарь начинается с наблюдения в браузере и сверяется с утверждённым реестром. Реестр остаётся документом управления, а наблюдение подтверждает, что он соответствует фактической странице.
Что включить в запись о скрипте
Одного URL недостаточно для требования 6.4.3. Запись должна давать проверяющему контекст, позволяющий определить ожидаемость, авторизацию, необходимость и способ контроля скрипта.
- Платёжный сценарий и страница, на которой исполняется скрипт.
- Собственный или сторонний источник, загрузчик и связь с менеджером тегов.
- Бизнес-назначение, технический владелец, согласующая роль и дата авторизации.
- Способ контроля целостности или подлинности, статус проверки и ссылка на исключение.
- Даты первого и последнего наблюдения, изменения и связанный артефакт или инцидент.
Выберите способ контроля, подходящий модели доставки
Subresource Integrity полезен для стабильного стороннего ресурса, точные байты и заголовки доставки которого контролируются. Но это не универсальное решение: скрипты поставщика, меняющиеся по одному URL, inline-код, динамические пакеты и цепочки загрузчиков требуют документированной альтернативы или сочетания методов.
В записи укажите выбранный способ и обоснование: контролируемая сборка и хеш релиза, цифровая подпись, строгая политика источников и nonce, подтверждение провайдера, мониторинг содержимого или комбинация мер. Формулировки «закрыто CSP» недостаточно без политики, режима применения, исключений и доказательств.
Связь реестра с управлением изменениями
Новый или изменённый скрипт должен проходить тот же управляемый путь, что и изменение в рабочей среде: заявка, владелец, обоснование, техническая проверка, согласование, выпуск и проверка после релиза. Экстренному изменению нужен последующий пересмотр, а не бессрочное недокументированное исключение.
У инвентаря также должен быть владелец периодического контроля. Он разбирает устаревшие записи, скрипты без ответственной команды, неиспользуемые интеграции и расхождения между реестром и живым платёжным сценарием.
Проверяйте контроль, а не количество строк
Большой реестр может не работать. Проверьте, обнаруживается ли контролируемо добавленный скрипт, нельзя ли согласовать запись без владельца, корректно ли штатный релиз обновляет поля и сохраняется ли история после удаления интеграции.
Практический критерий завершения: независимый проверяющий выбирает любой наблюдаемый скрипт и без устных пояснений находит сценарий, загрузчик, владельца, необходимость, согласование, решение по целостности, текущий статус и исходное доказательство.
Содержание
Соберите запись, выдерживающую независимую проверку
Шаблон намеренно подробнее обычного списка URL. Заполните его по наблюдаемому состоянию платёжной страницы, затем подтвердите бизнес-необходимость и способ контроля у владельца и согласующей роли. Следующий ниже локальный конструктор показывает пробелы управления и выгружает CSV или JSON без отправки записей в Cartelta.
Критерий готовности
Управляемый реестр одного платёжного сценария, сверенный с живым состоянием браузера, без необъяснённых скриптов и с воспроизводимой ссылкой на доказательство каждого согласования или исключения.
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 · одна явно обозначенная примерная строка
Это нейтральный шаблон внедрения. Настройте роли, способы контроля, сроки хранения и статусы согласования под проверяемую среду.
Соберите проверяемый реестр скриптов
Добавьте скрипты из одного платёжного сценария, найдите пробелы управления и выгрузите нейтральный реестр в CSV или JSON. Записи остаются в этой вкладке браузера и не отправляются в Cartelta.
0
Записей
0
Согласовано
0
Нужна проверка
0
Пробелы управления
Пробел означает, что у записи пока нет владельца, бизнес-назначения или способа контроля целостности.
Записей пока нет. Добавьте первый наблюдаемый скрипт выше.
Не вводите PAN, CVC, cookie, токены авторизации, идентификаторы клиентов и значения платёжных полей.
Рабочий процесс инвентаризации
Последовательность связывает наблюдение в браузере, бизнес-авторизацию и доказательства для проверки.
01
Наблюдение
Собрать скрипты и загрузчики из фактического платёжного сценария.
02
Классификация
Определить источник, назначение, страницу, владельца и зависимость.
03
Авторизация
Зафиксировать согласование, обоснование и способ контроля целостности.
04
Сравнение
Сверить живую страницу с утверждённым реестром и эталонным состоянием.
05
Пересмотр
Закрыть исключения и сохранить решение вместе с доказательствами.
Пример полей инвентаря
Пример показывает необходимый уровень контекста и не описывает инфраструктуру конкретного заказчика.
| # | Наблюдаемый объект | Назначение и владелец | Авторизация | Контроль и пересмотр |
|---|---|---|---|---|
| 01 | Собственный пакет страницы оплаты | Проверка оплаты — команда электронной коммерции | Ссылка на согласованный релиз | Хеш/подпись релиза; проверка после выпуска |
| 02 | SDK платёжного провайдера | Hosted payment component — платёжная команда | Согласованы провайдер и версия | Разрешённый список источников и проверка наблюдаемой версии |
| 03 | Аналитика из менеджера тегов | Измерение конверсии — владелец маркетинга | Задокументированы необходимость и область применения | Управление контейнером и сравнение живой страницы |
| 04 | Inline-загрузчик страницы оплаты | Запуск собственного платёжного сценария — команда платформы | Согласованный релиз приложения | Контролируемая сборка и сравнение с эталоном |
| 05 | Неизвестный дочерний скрипт | Назначение и владелец не определены | Не согласован; открыто исключение | Проверить загрузчик, при необходимости ограничить, сохранить решение |
Точный набор полей, способы контроля и согласующие роли должны соответствовать оцениваемой среде и внутреннему дизайну контроля.
Инвентарь — это доказательство, но не автоматическое соответствие
Cartelta может поддержать наблюдение, назначение владельцев, историю изменений и подготовку артефактов. Организация и её аудитор отвечают за область применимости, устройство контроля, согласования, операционную эффективность и итоговый вывод о соответствии.
Вопросы об инвентаризации скриптов
Нет. Нужно учитывать скрипты, загружаемые и исполняемые в контексте платёжной страницы, включая сторонние источники и динамические теги в пределах оцениваемой области.
Да, но его необходимо сверять с фактической загрузкой в браузере. Ручной список быстро теряет точность, когда менеджер тегов, виджеты, CDN и сторонние зависимости меняются независимо.
Задокументируйте такую модель доставки и выберите меры, которые позволяют ограничить или обнаружить неавторизованное изменение. Это может быть сочетание управления поставщиком, ограничений источников, наблюдения содержимого, координации релизов и исключений; SRI непрактичен, если согласованные байты непредсказуемо меняются.
Оно описывает конкретную функцию на платёжной странице, необходимость именно в этом сценарии, владельца принимаемого риска и последствия удаления. Фраза «нужно бизнесу» не помогает оператору или аудитору оценить необходимость.
Первичные источники PCI SSC
Продолжить внедрение
Сначала проверьте один платёжный сценарий
В рамках сфокусированного пилота можно сравнить утверждённый реестр со скриптами, которые фактически исполняются на странице оплаты.
Обсудить пилот инвентаризации