Коротко
• Пилот начинается с границ проверки, владельцев и критериев приёмки, а не с установки инструмента на весь домен.
• Первый результат — утверждённый инвентарь и эталонное состояние реального платёжного сценария.
• Контролируемое штатное и необъяснимое изменение проверяют обнаружение, маршрутизацию, первичный разбор и доказательства.
• JSIR поддерживает технический контроль, но область применимости, авторизация, реагирование и итоговый вывод PCI остаются ответственностью организации и аудитора.
До подключения: зафиксируйте результат пилота
Выберите один приоритетный платёжный сценарий и назовите его владельца. Опишите URL и состояния, тип интеграции с платёжным провайдером, локали, менеджер тегов, режимы согласия, сторонние ресурсы и системы, которые могут изменить страницу.
Согласуйте критерии приёмки: полнота инвентаря относительно наблюдаемых состояний, назначенные владельцы, утверждённое эталонное состояние, обнаружение тестового изменения, доставка события ответственному, задокументированное решение и воспроизводимый экспорт.
Этап 1. Соберите наблюдаемый инвентарь
Подключите наблюдение только к согласованному сценарию и пройдите его значимые состояния. JSIR публично описан как средство наблюдения DOM-скриптов и сторонних источников на фактической клиентской странице. Полученный список нужно сверить с репозиторием, менеджером тегов, поставщиками и владельцами приложений.
Каждую запись дополните назначением, техническим и бизнес-владельцем, статусом авторизации, способом контроля целостности, датой пересмотра и ссылкой на решение. Неизвестный скрипт — это задача классификации, а не автоматическое доказательство атаки.
- Руководство: Инвентаризация скриптов платёжной страницы
- Чек-лист: Чек-лист внедрения PCI DSS
Этап 2. Утвердите эталонное состояние страницы
Эталон должен описывать ожидаемую страницу, а не единственный случайный снимок. Зафиксируйте применимый вариант платёжного сценария, скрипты и источники, значимые структурные элементы, выбранные HTTP-заголовки, версию, релиз, владельца и согласование.
Отдельно задокументируйте допустимую динамику: согласие пользователя, локаль, A/B-тест, смену идентификаторов, поведение CDN и ответы провайдера. Нормализация должна удалять шум, но не скрывать новые источники скриптов, изменение исполняемого ресурса, поведения формы или назначения запросов.
Этап 3. Проверьте штатное и необъяснимое изменение
Сначала выпустите заранее согласованное изменение и проверьте, что событие связано с нужной версией эталона, релизом и владельцем. Решение должно обновлять эталон управляемо и сохранять предыдущую версию.
Затем используйте безопасное тестовое отклонение, не затрагивающее реальные платёжные данные. Проверьте обнаружение, контекст, уведомление, назначение, первичный разбор, действие и закрытие. Сценарий теста и способ его удаления согласуйте до запуска.
Этап 4. Подключите операционный процесс
Определите, кто получает уведомления, кто оценивает бизнес-контекст, кто может согласовать эталон и кто эскалирует событие как инцидент. Маршрутизация по электронной почте, через webhook или в SOC/SIEM имеет смысл только вместе с ответственными ролями, уровнем критичности и сроком реакции.
Сохраните инструкцию реагирования для штатного релиза, неизвестного стороннего скрипта, изменения заголовка и подозрительного поведения формы. Для каждого сценария укажите минимальный контекст и ожидаемое доказательство закрытия.
Что должно войти в итоговый пакет
Пакет пилота должен позволить независимому специалисту восстановить границы проверки, ожидаемое состояние и два тестовых события без устного объяснения. Скриншоты полезны для навигации, но не должны быть единственным источником.
- Карта платёжного сценария, границы наблюдения и владельцы.
- Инвентарь со статусами авторизации, обоснованием и способом контроля.
- Версия эталонного состояния, согласование и связь с релизом.
- Различия, время, страница и контекст штатного и тестового отклонения.
- Маршрутизация, решение, действие, закрытие и экспорт истории.
- Карта артефактов: Карта доказательств PCI DSS
Критерии перехода в рабочую эксплуатацию
Переход оправдан, когда наблюдаемые состояния покрыты, неизвестные скрипты классифицированы, эталон согласован, тестовые изменения обнаружены, владельцы реально обработали события, а доказательства воспроизводимы. Оставшиеся пробелы должны иметь владельца, срок и принятое решение о риске.
После пилота расширяйте область наблюдения по одному типу сценариев и повторяйте проверку. Не переносите правила нормализации и эталон на другие платёжные сценарии без проверки: различия архитектуры могут скрыть значимые изменения.
- См. также: Как провести пилот по защите на стороне клиента без тяжёлого проекта
- Методология: Методология мониторинга JSIR
Технический контракт пилота JSIR
До подключения наблюдения согласуйте не только URL, но и состояния платёжного сценария: первый показ формы, выбор способа оплаты, 3DS-переход, ошибка и успешное завершение. Для каждого состояния определите ожидаемые скрипты и ресурсы, допустимую динамику, владельца эталона и связь с релизом.
Отдельно зафиксируйте границы данных. Для оценки клиентских изменений не требуется сохранять PAN, CVC, значения полей формы, cookie или заголовки авторизации. Тестовый протокол должен подтверждать исключение чувствительных данных и описывать, какие структурные сигналы сохраняются вместо них.
Иллюстративный паспорт пилота, не схема API
{
"journey_id": "checkout-main",
"states": ["payment", "3ds-transition", "success", "error"],
"excluded_data": [
"payment-field values",
"cookies",
"authorization headers"
],
"approved_release": "release-2026.07.15",
"test_events": [
"approved script update",
"safe unknown source"
],
"acceptance_owner": "payment-security-owner"
}Что отличает рабочее внедрение от демонстрации
Рабочий результат можно повторить после следующего релиза: новый скрипт получает владельца и решение, изменение страницы связывается с версией эталона, а событие доходит до ответственной команды и закрывается с доказательством. Если результат держится только на ручном показе панели, контроль ещё не встроен в процесс.
- Покрытие состояний подтверждено фактическими наблюдениями.
- Правила исключения прошли негативные тесты и не скрывают новые источники.
- Штатное изменение и безопасное отклонение воспроизводят полный процесс.
- Экспорт понятен специалисту, не участвовавшему в настройке.
- План пилота: Как провести пилот по защите на стороне клиента без тяжёлого проекта
Практический порядок действий
1
Согласуйте один платёжный сценарий, владельцев и критерии приёмки.
2
Подключите наблюдение и проверьте исключение чувствительных данных.
3
Соберите и авторизуйте инвентарь скриптов, затем утвердите эталонное состояние.
4
Проведите штатное и безопасное тестовое отклонение через полный первичный разбор.
5
Проверьте пакет доказательств и зафиксируйте решение о границах рабочей эксплуатации.
Вопросы по теме
JSIR заменяет PCI DSS-аудит?
Нет. JSIR помогает собрать технические данные, события и доказательства для процесса соответствия, но итоговую оценку применимости и достаточности контролей проводит команда и аудитор.
Нужно ли переписывать платёжный сценарий для пилота?
Цель пилота — ограниченное подключение к одному платёжному сценарию. Точный способ интеграции, исключение чувствительных данных и влияние на рабочую среду нужно проверить до запуска на технической встрече.
Какие два теста обязательны для полезного пилота?
Проверьте согласованное штатное изменение и безопасное необъяснимое отклонение. Для обоих должен воспроизводиться путь от наблюдения и эталона до владельца, решения, действия и сохранённого доказательства.