Как пройти сертификацию PCI DSS для интернет‑магазина: пошаговое руководство

Кому нужна сертификация PCI DSS и что она дает вашему магазину

PCI DSS — стандарт безопасности платежных данных, который обязателен для организаций, обрабатывающих, передающих или хранящих данные платежных карт. Для интернет‑магазина это значит: если вы принимаете карты напрямую или храните PAN (Primary Account Number) — соответствие необходимо, иначе вас могут обязать по договору с платежным провайдером или банковским эквайером.

Сертификация помогает систематизировать требования по защите карт, снизить риск утечки данных и упростить взаимодействие с банками и PSP. При этом подход к соответствию зависит от архитектуры магазина: интеграция с PSP, использование токенизации, хостинг платежной формы у провайдера — всё это влияет на уровень валидации и набор необходимых работ.

В этом руководстве мы проводим вас от подготовки — что собрать и какие решения принять — до финальной внешней проверки и пост‑релизной поддержки. Цель — обеспечить, чтобы на каждом этапе были понятные контрольные точки и тесты, исключающие критические просчёты.

Что подготовить до начала работ: документы, инфраструктура, права доступа

Прежде чем приступать к техническим изменениям, соберите ключевые документы и данные: архитектурную схему обработки платежей, реестр систем, которые касаются карт, договоры с PSP/эквайерами, текущие политики безопасности (пароли, доступ, логирование). Это позволит корректно определить зону хранения и передачи карточных данных.

Технически подготовьте список серверов и сервисов, через которые проходят платежи: веб‑серверы, API, базы данных, хранилища логов, внешние интеграции. Убедитесь, что у команды есть доступ к конфигурациям, журналам и средствам мониторинга — без этого внутренний аудит и тестирование будут затруднены.

Организационно назначьте ответственного за процесс (проектный владелец) и определите роли: разработчики, сисадмины, специалист по информационной безопасности, контакт с банком/PSP. Пропуск этого шага часто создаёт задержки при внешней проверке — аудиторы запрашивают контактное лицо и подтверждение введённых изменений.

Шаг 1. Определение зоны контроля и уровня валидации (SAQ, ROC, QSA)

Первое практическое действие — классифицировать ваш маршрут карт в инфраструктуре и понять, какой тип валидации вам нужен. Для большинства небольших магазинов подходит один из SAQ (Self‑Assessment Questionnaire), если же вы храните значительный объём данных или используете собственную платёжную систему, потребуется отчёт от квалифицированного аудитора (ROC) и работа через QSA (Qualified Security Assessor).

Определите, где именно возникают и хранятся PAN и связанные данные: на вашем сервере, на стороне PSP, в логах. Если платежная форма отдана PSP и токены возвращаются вместо PAN, зона ответственности магазина значительно сокращается. Напротив, прямое приёмо‑обработка карт на ваших серверах требует более строгих мер и внешней оценки.

Результат этого шага — документ с границами PCI‑зоны (cardholder data environment), выбранным деревом валидации (напр., SAQ A, SAQ A‑EP, SAQ D) и перечнем систем, попадающих в зону. Без корректной классификации дальнейшие шаги теряют эффективность.

Шаг 2. Техническая реализация требований: сегментация, шифрование, аутентификация

После определения зоны контроля необходимо реализовать ключевые технические требования стандарта. В первую очередь — сегментация сети: изолируйте системы, обрабатывающие платежи, от остальной инфраструктуры. Это снижает площадь атаки и уменьшает объём систем, подлежащих проверке.

Шифрование данных при передаче и хранении — обязательное требование. Настройте TLS для всех интерфейсов, по возможности используйте строгие настройки шифров и обновлённые сертификаты. Для хранения применяйте сильное шифрование и грамотное управление ключами; если возможно — избегайте хранения PAN, используйте токенизацию или решение PSP.

Аутентификация и управление доступом: включите многофакторную аутентификацию (MFA) для удалённых доступов и административных учётных записей, настройте минимальные привилегии по принципу need‑to‑know. Логи доступа должны собираться централизованно и храниться в защищённом виде — подготовьте репликацию и резервирование логов.

Шаг 3. Интеграция платежного решения: выбор подхода и реализация без хранения PAN

Выберите модель интеграции с учётом желаемого уровня ответственности: перенаправление на страницу PSP, внедрение iframe/hosted form, сервер‑то‑серверные интеграции с токенизацией. Чем меньше PAN проходит через ваши сервера, тем проще требования и ниже объём работ по соответствию.

При интеграции обеспечьте, чтобы третьи стороны были PCI‑совместимы: запросите у PSP подтверждение их соответствия и условия обработки данных. Если используется токенизация, проверьте, что токены не являются восстановимыми до PAN в вашей зоне ответственности; это значительно упрощает аудит.

Особое внимание уделите обработке ошибок и логированию: в логах не должно храниться PAN или CVV. Разработчикам нужно встроить проверки очистки данных в местах, где могли бы записываться чувствительные значения, а также реализовать корректное управление сессиями и CSRF‑защиту для платежных форм.

Шаг 4. Внутренний аудит и подготовка доказательств соответствия

Перед внешней проверкой проведите внутренний аудит: проверьте выполненные технические задачи, соберите журналы и снимки конфигураций, выполните сканирование уязвимостей через ASV (или аналогичный инструмент). Документируйте все изменения и сохраните результаты сканирований как доказательства.

Подготовьте политики и инструкции: политика контроля доступа, инцидент‑response, управление уязвимостями, резервное копирование. Аудиторы оценивают не только код и конфигурации, но и наличие оформленных процедур, подтверждающих регулярность и системность мер безопасности.

Соберите пачку доказательных материалов: архитектурная схема PCI‑зоны, список систем с IP/именами, результаты сканов, логи доступа за требуемый период, журналы смены конфигураций. Чем лучше оформлены и структурированы доказательства, тем меньше вопросов на стадии внешнего аудита.

Контрольные точки перед внешней проверкой — чеклист критичных пунктов

Перед вызовом внешнего аудитора пройдитесь по контрольному чеклисту: это уменьшит вероятность несоответствий и дополнительных доработок. Ниже — отдельный блок с нумерованными, практическими проверками, которые обязательно должны быть закрыты.

Каждый пункт чеклиста желательно документировать скриншотами конфигураций, фрагментами логов и ссылками на соответствующие политики. При подготовке используйте принцип «1‑документ = 1‑подтверждение» для ускорения взаимодействия с аудитором.

Закрытие всех контрольных точек не гарантирует автоматического прохождения, но существенно повышает шансы на успешную внешнюю проверку и снижает объём доработок после отчёта.

• 1) Определена граница PCI‑зоны и задокументирована схема передачи данных;
• 2) Исключено хранение PAN/CVV в логах и базе данных препаратовных сред;
• 3) Включён TLS с современными настройками на всех точках ввода/передачи;
• 4) Включена MFA для административного доступа и SSH/RDP через защищённые jump‑hosts;
• 5) Ведётся централизованное логирование и хранение логов за требуемый период;
• 6) Выполнены внешние сканы на уязвимости и устранены критические/высокие замечания;
• 7) Подготовлены политики и инструкции: управление доступом, инциденты, резервное копирование.

Шаг 5. Внешняя проверка: что ожидают аудиторы и как взаимодействовать

Внешняя проверка может включать удалённые сканы (ASV), интервью с ответственными, проверку документов и выборочные тесты. Если ваш проект требует ROC, в работу вступает QSA — он проводит углублённый аудит и формирует отчёт о соответствии. Подготовьте выделенное время и контакт‑лицо для коммуникации с аудитором.

Во время проверки будьте готовы оперативно предоставлять доступы, логи и пояснения по архитектуре. Не скрывайте проблемные места: лучше показать фиксированный план по устранению и подтверждение работ, чем пытаться замаскировать несоответствие.

По итогам вы получите отчёт и/или аттестацию. Если найдены несоответствия, аудиторы перечислят требования к доработке и сроки. Планируйте реакцию команды: распределите задачи, опишите ответственность и сроки на устранение замечаний.

Шаг 6. Тестирование и ввод платежной части в эксплуатацию

После устранения замечаний и получения подтверждения аудитора проведите комплексное тестирование: функциональное (оплата, возврат, отмена), нагрузочное (если трафик значительный), и тестирование безопасности (повторный скан ASV, внутрисетевые проверки). Тесты должны воспроизводить реальные сценарии пользователя и ошибочные случаи.

Организуйте предрелизную среду, максимально приближенную к продакшену, и прогоните чек-листы. Важно, чтобы логи в предрелизной среде также не содержали PAN; используйте тестовые карты и токены, предоставляемые PSP для тестирования.

После успешного тестирования разработайте план поэтапного ввода в эксплуатацию: частичный релиз, мониторинг ключевых метрик безопасности и платежей, проверка логов и оповещений. Планируйте откатные сценарии на случай обнаружения критических проблем.

Шаг 7. Что проверить после запуска и как поддерживать соответствие

Соответствие PCI DSS — не одноразовая задача. После ввода в эксплуатацию установите регулярный цикл проверок: ежемесячные и ежегодные сканирования, ревью политик, контроль смены паролей и отзывов доступов. Обновляйте список систем в PCI‑зоне при каждом изменении архитектуры или интеграции.

Настройте мониторинг инцидентов и процесс их обработки: моментальные уведомления о подозрительной активности, регламенты расследования и уведомления сторон (эквайер, PSP) при инциденте. Подготовьте шаблоны отчётов и контакты для экстренной связи.

Регулярно обучайте команду: базовые правила обработки данных, требования к логированию и работе с платежными интеграциями. Малые ошибки разработчиков или администраторов чаще всего приводят к несоответствиям в повторяющихся аудитах.

Частые вопросы