Нарисуйте реальную границу платежа
Составьте карту пути покупателя от страницы товара до подтверждения. Отметьте точку ввода карты, перенаправления, фреймы, скрипты, API, плагины, менеджеры тегов, сети доставки контента и учётные записи администраторов, которые могут на это повлиять. Включите связанные логи, инструменты поддержки и аналитику. Это стартовый документ для вашего провайдера или оценщика, а не решение о соответствии.
Зафиксируйте домен, который обслуживает каждый элемент страницы оплаты. PCI SSC указывает, что право на SAQ A требует, чтобы все элементы страницы оплаты поступали только от провайдеров, соответствующих PCI DSS, и ни один элемент не исходил с сайта продавца. Для SAQ A-EP каждый элемент может исходить от продавца или от такого провайдера, но не из другого источника. Все другие критерии по‑прежнему применяются.
Репозиторий кода может не показать инъекции через менеджер тегов и настройки платформы. Просмотрите скрипты, фреймы, домены и заголовки в обычной сессии чек-аута в браузере.
Проверьте логи, аналитику и рабочие процессы поддержки на предмет полей оплаты. Никогда не используйте реальные данные карт в тестовых обращениях или общей документации.
Сократите область воздействия понятной моделью платежей
По возможности используйте интеграцию, при которой PCI DSS‑совместимый провайдер собирает данные карт, а не ваше приложение получает или хранит их. Полностью хостимый перенаправляемый чек-аут часто проще, чем кастомная форма, но встроенные поля и iframe всё равно позволяют вашему сайту влиять на платёж. Документируйте фактическую интеграцию, а не полагайтесь на ярлык «хостинг».
Избегайте хранения основных номеров счетов (PAN), кодов безопасности, скриншотов ошибок при оплате или скопированных деталей платежа, если это не требуется утверждённым решением. Шифрование помогает защитить данные, но PCI SSC предупреждает, что одно только шифрование обычно не выводит окружение из области применения. Подтвердите обработку токенов, ключей, webhooks, возвратов и распределение ответственности с провайдером и квалифицированными рецензентами.
Храните руководство по интеграции, информацию по зонам ответственности, релевантную документацию по соответствию и процесс уведомления об изменениях вместе с архитектурной записью.
Не добавляйте маркетинговые эксперименты, инструменты записи сессий, виджеты чата или необязательные библиотеки без назначенного владельца и проверки того, к чему они имеют доступ.
Контролируйте скрипты, теги и заголовки
Сторонний код в браузере может ввести неконтролируемые изменения, исполнение произвольного кода и раскрытие данных другим сторонам. Ведите инвентаризацию чек-аута с указанием домена каждого скрипта, назначения, владельца, утверждения и места загрузки. Включайте правила менеджера тегов и код, загружаемый поставщиками, а не только файлы в дереве исходников.
PCI SSC фокусируется на авторизованных скриптах, целостности, мониторинге вмешательств и заголовках, влияющих на безопасность. Утвердите эталон, ограничьте изменения, обнаруживайте расхождения и расследуйте их. Content Security Policy (CSP) может ограничить источники ресурсов. По возможности тестируйте CSP в режиме report-only перед принудительным применением. CSP — средство слоистой защиты, но не замена безопасной разработки или ревью.
Subresource Integrity (SRI) может отклонять изменённый внешний скрипт, но требует совместимой кросс-доменной конфигурации и может ломаться после обновлений поставщика.
Ограничьте роли публикации, требуйте надёжной аутентификации, проверяйте возможность выполнения кастомного кода и сохраняйте след аудита.
Ограничьте доступ и сделайте изменения в чек-аутах откатываемыми
Разделяйте рутинную публикацию контента и код чек-аута, администрирование провайдера платежей, хостинг, DNS и менеджмент тегов. Используйте именованные учётные записи, принципы наименьших привилегий и многофакторную аутентификацию там, где это поддерживается. Пересматривайте доступ после смен ролей и удаляйте бывших сотрудников, поставщиков и агентства. Точная применимость PCI DSS зависит от окружения, но уменьшение общего и постоянного доступа снижает риск.
Используйте процесс релиза для чек-аута: назначенный владелец, ревью, тестирование где возможно, метод отката и проверка после релиза. Тестируйте успешные и неуспешные пути оплаты, перенаправления и поведение на мобильных устройствах. Status Is UP поддерживает проактивную готовность запуска, оптимизацию производительности и планирование отката при релизах; оно не определяет соответствие PCI DSS.
Храните учётные данные, резервные коды и инструкции по откату в утверждённых системах с контролем доступа, никогда не в тикетах, скриншотах или публичных репозиториях.
После релиза сопоставьте видимые в браузере скрипты, домены и заголовки с утверждённой инвентаризацией.
Обновляйте стек и проверяйте результат
Ведите инвентаризацию платформы электронной коммерции, плагинов, тем, серверных компонентов, библиотек, SDK платежей, шаблонов тегов и сервисов, влияющих на чек-аут. Подписывайтесь на уведомления критических поставщиков. NIST описывает управление патчами как выявление, приоритизацию, получение, установку и проверку обновлений. Записывайте изменения, тестируйте путь оплаты и подтверждайте, что развернуто.
Определите экстренный путь для проблем высокого риска и окно обслуживания для рутинных изменений. Приоритетизируйте компоненты, напрямую затрагивающие чек-аут, но не патчьте слепо продакшн и не ломайте оплату. Используйте проверенный подход к откату и руководство по релизам от провайдера. Отсутствие владельца у устаревшего компонента — риск, который нужно устранить.
Храните уведомление поставщика, решение по риску, результат теста, запись о деплое и итоговую верификацию вместе.
Храните доказательства и привлекайте квалифицированных специалистов
Храните диаграммы, информацию о зонах ответственности провайдера, обоснование права на выбранную SAQ, инвентаризации скриптов и заголовков, обзоры доступа, утверждения, результаты тестов, изменения и контакты поставщиков в контролируемом месте. Обновляйте их при изменении архитектуры, владельцев, скриптов или провайдеров. Доказательства должны помогать уполномоченному рецензенту без раскрытия данных карт, секретов или записей клиентов.
Ваш эквайер или платёжный бренд определяет требования к валидации. PCI SSC выделяет Qualified Security Assessors (QSA) как независимые организации, квалифицированные для проведения оценок PCI DSS, и Approved Scanning Vendors (ASV) как поставщиков внешнего сканирования в рамках применимых требований. Привлекайте квалифицированную помощь для кастомного чек-аута, неясной области, предполагаемого компромета или выбора SAQ.
Держите модель чек-аута, технических владельцев, контакты эскалации, дату последнего обзора и ссылки на доказательства в одном месте.