Коротко
• Нужен живой реестр скриптов, владельцев и бизнес-обоснований.
• Контроль целостности должен быть встроен в процесс изменений, а не храниться вручную.
• CSP, SRI и мониторинг работают лучше как связанная программа, а не как один изолированный контроль.
Что требует PCI DSS 6.4.3
Требование 6.4.3 относится к скриптам, которые загружаются и выполняются на платежной странице. Его смысл не в том, чтобы разово составить список URL, а в том, чтобы сделать исполняемый код управляемым.
Команда должна понимать, какие скрипты разрешены, кто отвечает за каждый скрипт, зачем он нужен бизнесу и каким техническим способом контролируется целостность или подлинность.
Три слоя контроля
Практически 6.4.3 раскладывается на три слоя: инвентаризация, авторизация и обеспечение целостности. Если один слой отсутствует, аудитору будет сложно принять контроль как устойчивый процесс.
- Инвентаризация: актуальный список first-party, third-party и tag-manager скриптов на реальной странице.
- Авторизация: владелец, назначение, бизнес-обоснование, дата ревью и статус разрешения.
- Целостность: SRI, CSP, подпись, контроль изменений или другой механизм, встроенный в процесс релиза.
Почему ручного Excel недостаточно
Ручной реестр быстро устаревает: маркетинг добавляет теги, платежный провайдер меняет SDK, CDN отдаёт другую версию, а менеджер тегов может подгружать скрипты динамически.
Поэтому инвентарь должен собираться из фактического DOM и сетевой активности страницы. Это помогает увидеть не только то, что команда планировала загрузить, но и то, что реально исполнилось в браузере клиента.
Как связать 6.4.3 с разработкой
Контроль должен быть частью изменения, а не постфактум-проверкой перед аудитом. Новый скрипт должен проходить через заявку, владельца, бизнес-обоснование и техническую проверку до попадания на промышленную страницу.
Для CI/CD полезны контрольный этап перед выпуском, автоматическая генерация или проверка хэшей, CSP сначала в режиме report-only, затем в enforce, и отдельная процедура разбора исключений.
Типовые ошибки внедрения
Самые частые ошибки — считать CSP полной заменой процесса, учитывать только собственные скрипты, не назначать владельцев и не проверять страницу так, как её видит пользователь.
Минимальная техническая запись о скрипте
Для тестовой выборки возьмите собственный пакет приложения, SDK платёжного провайдера и скрипт, загруженный менеджером тегов. Для каждого сохраните наблюдаемый источник, состояние страницы, загрузчик, назначение, владельца, согласование, способ контроля целостности, дату проверки и ссылку на исключение или изменение.
Запись ниже иллюстрирует структуру реестра, а не формат API Cartelta. В такой реестр не должны попадать значения платёжных полей, cookie, токены авторизации или другие секреты.
Пример машиночитаемой записи инвентаря
{
"script_id": "script-042",
"payment_state": "checkout.payment",
"observed_url": "https://cdn.example/sdk.js",
"loaded_by": "tag-manager:container-7",
"owner": "payments-platform",
"business_reason": "render hosted payment fields",
"authorization": {
"status": "approved",
"change_id": "CHG-1842"
},
"integrity_method": "documented control for this source",
"first_seen": "2026-07-01T08:15:00Z",
"last_reviewed": "2026-07-15"
}Приёмочные тесты для контроля 6.4.3
После релиза сверяйте утверждённый реестр с фактической страницей. Расхождение должно создавать решение: подтвердить ожидаемое изменение, локализовать неизвестный источник, отклонить изменение или оформить ограниченное по сроку исключение. Автоматическое добавление любого нового состояния в разрешённый список уничтожает смысл контроля.
- Ожидаемый релиз: новый хэш или версия связаны с согласованным изменением и владельцем.
- Неизвестный источник: событие содержит страницу, загрузчик, время первого наблюдения и назначенного ответственного.
- Устаревшая запись: скрипт, который больше не наблюдается, получает решение об удалении или сохранении с объяснением.
- Динамический загрузчик: проверка показывает дочерние источники, а не только разрешённый контейнер верхнего уровня.
- Шаблон процесса: Инвентаризация скриптов платёжной страницы
- Карта доказательств: Карта доказательств PCI DSS
Практический порядок действий
1
Соберите живой инвентарь скриптов платежной страницы.
2
Назначьте владельца и бизнес-обоснование для каждого скрипта.
3
Встройте контроль целостности или подлинности в процесс изменений.
4
Настройте регулярный пересмотр и хранение доказательств для аудита.
Вопросы по теме
Достаточно ли только CSP для PCI DSS 6.4.3?
Нет. CSP полезен как технический слой, но сам по себе не даёт полного инвентаря, владельцев, письменного бизнес-обоснования и процесса авторизации каждого скрипта.
Можно ли вести инвентарь скриптов вручную?
Можно начать вручную, но для промышленной страницы оплаты ручной список быстро устаревает. Надёжнее собирать данные из фактической страницы и регулярно сверять их с разрешённым состоянием.