Коротко
• Выборка должна отражать фактические состояния платёжного сценария, а не только список из репозитория.
• Каждая запись проходит одинаковую проверку: источник, загрузчик, назначение, владелец, авторизация и контроль целостности.
• Негативный тест доказывает обнаружение неизвестного скрипта и невозможность его молчаливого согласования.
• Результат — воспроизводимая выборка с решениями и доказательствами, а не скриншот реестра.
Короткий ответ: что проверять по PCI DSS 6.4.3
Проверка отвечает на один вопрос: может ли независимый специалист выбрать любой скрипт, реально исполняемый на платёжной странице, и без устных пояснений установить, где он наблюдался, кто его загрузил, зачем он нужен, кто его разрешил и каким способом контролируется его целостность или подлинность.
Эта статья посвящена тестированию уже созданного контроля. Подробная модель полей, интерактивный конструктор и CSV-шаблон находятся в основном руководстве по инвентаризации.
Граница материала
Процедура помогает подготовить доказательства, но не заменяет определение области применимости и профессиональное суждение QSA или другой принимающей стороны.
Сформируйте репрезентативную выборку
Минимальная выборка включает собственный пакет приложения, SDK платёжного провайдера и скрипт, появившийся через менеджер тегов или другой динамический загрузчик. Если состав меняется из-за согласия, локали, способа оплаты, ошибки или 3DS-перехода, охватите эти состояния либо явно зафиксируйте непроверенные ветки.
Источник выборки — фактическое наблюдение в браузере. Репозиторий, конфигурация tag manager и список поставщиков используются для сверки, но не доказывают, что пользователь получил именно этот набор скриптов.
- Зафиксируйте URL или состояние страницы, время и способ наблюдения.
- Сохраните цепочку загрузки до конечного исполняемого ресурса.
- Отдельно отметьте inline-код, модули, workers и дочерние скрипты.
- Не удаляйте необъяснённые записи: откройте исключение с владельцем и сроком.
Проверьте каждую запись по единым критериям
Статус «согласован» допустим только тогда, когда запись связывает наблюдаемое состояние с управленческим решением и проверяемым техническим контролем.
| Критерий | Проходит | Не проходит | Доказательство |
|---|---|---|---|
| Наблюдаемость | Есть сценарий, состояние страницы и время | Есть только URL без контекста | Снимок или машиночитаемый экспорт |
| Цепочка загрузки | Известны загрузчик и дочерние источники | Разрешён только контейнер tag manager | DOM, network log или loader chain |
| Необходимость | Указана конкретная функция в оплате | Написано только «нужно бизнесу» | Функция и последствия удаления |
| Владелец и авторизация | Есть ответственный и ссылка на решение | Владелец неизвестен или согласование устное | Change, ticket или другой устойчивый ID |
| Контроль целостности | Метод соответствует модели доставки | Указано только CSP или SRI без конфигурации | Политика, хеш, подпись или мониторинг |
| Жизненный цикл | Есть даты и история удалённых записей | Запись бессрочная и исчезает вместе со скриптом | История статусов и исключений |
Проведите негативные тесты и закройте расхождения
Положительная сверка показывает только совпадение с текущим состоянием. В согласованной тестовой среде без платёжных данных добавьте безопасный неизвестный источник, дочерний скрипт через разрешённый контейнер и контролируемую новую версию собственного пакета.
Каждое расхождение должно завершаться решением: подтвердить ожидаемый релиз, локализовать и ограничить неизвестный источник, оформить срочное исключение или эскалировать событие. Автоматическое добавление любого нового состояния в разрешённый список уничтожает смысл контроля.
- Новый источник не получает статус «согласован» автоматически.
- Динамический загрузчик показывает конечные дочерние ресурсы.
- Штатное изменение связано с релизом, владельцем и новой версией контроля.
- Удалённый скрипт получает решение без потери истории.
Соберите воспроизводимую выборку для проверки
Итоговый пакет должен позволять другому специалисту повторить вывод по одной записи: увидеть область наблюдения, скрипт, загрузчик, владельца, обоснование, авторизацию, способ контроля, последнее изменение и решение по тестовому отклонению.
Не включайте PAN, CVC, значения полей, cookie, токены авторизации и идентификаторы клиентов. Для проверки управления скриптами достаточно структурного и процессного контекста.
- Конструктор и модель данных: Инвентаризация скриптов платёжной страницы
- Карта доказательств: Карта доказательств PCI DSS
Шаблон реестра платёжных скриптов
CSV для собственной выборки; интерактивное заполнение доступно в основном руководстве.
CSV · UTF-8 · примерная строка явно обозначена
Практический порядок действий
1
Определить платёжный сценарий, состояния и источник наблюдений.
2
Сформировать выборку собственных, сторонних и динамических скриптов.
3
Проверить наблюдаемость, необходимость, владельца, авторизацию и целостность.
4
Провести безопасные негативные тесты в согласованной среде.
5
Закрыть каждое расхождение документированным решением.
6
Передать независимому проверяющему воспроизводимую выборку без секретных данных.
Вопросы по теме
Достаточно ли показать QSA выгрузку реестра?
Нет. Нужны также границы наблюдения, источник данных, авторизация, работа контроля после изменений и примеры решений по отклонениям.
Можно ли автоматически согласовывать изменения поставщика?
Автоматическое наблюдение возможно, но признание любого нового содержимого разрешённым создаёт пробел. Нужны условия, владелец решения, ограничения и сохраняемое доказательство.
Cartelta гарантирует соответствие 6.4.3?
Нет. Cartelta поддерживает наблюдение, инвентаризацию, историю и доказательства. Область, устройство контроля и итоговый вывод остаются ответственностью организации и аудитора.