PCI DSS 6.4.3: контроль скриптов платёжной страницы
Три «кита» 6.4.3 — инвентаризация, авторизация, целостность. Ниже — практические шаги, чего хочет аудитор и какие ошибки встречаются чаще всего.
Что именно требует PCI DSS 6.4.3?
| Компонент | Требование | Детали |
|---|---|---|
| Инвентаризация скриптов | Вести актуальный реестр всех скриптов платёжной страницы, включая GTM, чаты, BNPL-виджеты и динамические вставки. | Для каждого — назначение, владелец, среда (prod/stage), источник (1st/3rd), дата ревью, статус (разрешён/запрещён). |
| Авторизация скриптов | Каждый исполняемый скрипт должен быть одобрен уполномоченным лицом и иметь бизнес-обоснование. Изменения проходят через формальный процесс (RFC/Jira). | Аудитор ищет доказательства: политики, записи ревью, следы одобрений и журнал изменений. |
| Обеспечение целостности | Должен существовать технический контроль подлинности/целостности (например, SRI, строгий CSP, подпись, иное средство), который предотвращает несанкционированные модификации. | Контроль должен реально блокировать/сигнализировать несоответствие и быть частью CI/CD-процесса. |
Почему это важно
Client-side атаки (веб-скимминг/Magecart-атаки, formjacking) эксплуатируют то, что выполняется в браузере. WAF этого не видит: он защищает периметр, а не код после загрузки в клиент. Поэтому 6.4.3 сфокусировано на авторизации и целостности именно клиентских скриптов.
Как правильно внедрить контроль скриптов
1) Автокаталогизация
- Сканируйте реальный DOM страниц, учитывайте GTM/виджеты/динамические вставки.
- Ведите единый реестр: владелец, назначение, среда, SRI/подпись, дата ревью, статус.
2) Целостность в CI/CD
- Генерируйте SRI-хэши автоматически при сборке; несоответствие — блокирует деплой (quality-gate).
- Поддерживайте подпись/хэши для 1st и 3rd-party скриптов, документируйте процедуру обновления.
3) CSP (по этапам)
- Запускайте в report-only, собирайте отчёты, добавляйте исключения для легитимных сценариев.
- Переходите в enforce(блокирование) после тестов; контролируйте источники через script-src, hash.
Что будет проверять аудитор
Артефакты
- Реестр скриптов с владельцами и статусами.
- Политика/процедура авторизации, следы одобрений (RFC/Jira).
- Доказательства работы контроля целостности (логи SRI/CSP, quality-gate).
Интервью/наблюдение
- Как добавляется новый скрипт? Кто одобряет и когда ревью?
- Как обновляются/отзываются SRI-хэши? Что происходит при несоответствии?
- Как отлаживаете CSP и исключения, чтобы не ломать UX?
Практические рекомендации
- Регулярно (минимум ежемесячно) пересматривайте реестр и владельцев скриптов.
- Автоматизируйте сбор инвентаря: сканирование реального DOM.
- Добавьте quality-gate в CI: деплой останавливается при рассинхроне SRI.
- CSP включайте по этапам: report-only → эксперимент → enforce, с точечными исключениями.
- Готовьте артефакты для аудита: выгрузки инвентаря, выписки алертов, политики.
Делайте / не делайте
Делайте
| Инвентарь из реального DOM |
| SRI и подпись обновляются в CI |
| CSP: report-only → enforce с исключениями |
| Заданный процесс на добавление/удаление скриптов |
Не делайте
| Скрипт-инвентарь вручную в Excel |
| Задать hash один раз |
| Невыборочная CSP-политика 'self' |
| Анонимные правки в Tag Manager |
Как Cartelta JSIR упрощает выполнение 6.4.3
- Авто-каталогизация: живой реестр скриптов с владельцами и статусом (prod/stage).
- Dynamic SRI: автогенерация/проверка хэшей, quality-gate в CI.
- Real-time Watcher: события о новых/изменённых скриптах из реальных сессий.
- Экспорт отчётов (PDF/CSV), в том числе с использованием webhook для импорта в SIEM.
FAQ по 6.4.3
6.4.3 требует именно контроль целостности/подлинности. CSP помогает ограничивать источники, но не заменяет SRI/подписи — используйте слоистый подход.
Нет. Инвентарь и целостность нужно контролировать постоянно. Для 11.6.1 (обнаружение изменений) — минимум еженедельно, а лучше чаще по риску.
Продукты
© 2025 Cartelta. Все права защищены.
Свяжитесь с нами