Коротко
• Нужен живой реестр скриптов, владельцев и бизнес-обоснований.
• Контроль целостности должен быть встроен в процесс изменений, а не храниться вручную.
• 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 полезны quality-gate, автоматическая генерация или проверка хэшей, CSP в режиме report-only перед enforce и отдельная процедура разбора исключений.
Типовые ошибки внедрения
Самые частые ошибки — считать CSP полной заменой процесса, учитывать только собственные скрипты, не назначать владельцев и не проверять страницу так, как её видит пользователь.
Практический порядок действий
1
Соберите живой инвентарь скриптов платежной страницы.
2
Назначьте владельца и бизнес-обоснование для каждого скрипта.
3
Встройте контроль целостности или подлинности в процесс изменений.
4
Настройте регулярный пересмотр и хранение доказательств для аудита.
Вопросы по теме
Достаточно ли только CSP для PCI DSS 6.4.3?
Нет. CSP полезен как технический слой, но сам по себе не даёт полного инвентаря, владельцев, письменного бизнес-обоснования и процесса авторизации каждого скрипта.
Можно ли вести инвентарь скриптов вручную?
Можно начать вручную, но для промышленной страницы оплаты ручной список быстро устаревает. Надёжнее собирать данные из фактической страницы и регулярно сверять их с разрешённым состоянием.