PCI DSS 4.0: что именно требуют проверять пункты 11.3 и 11.4

PCI DSS — единственный стандарт, который прямо говорит «пентест» и назначает его периодичность. Разбираем, что сканируется автоматически, что тестирует человек и какие доказательства ждёт QSA.

Представьте типичную картину: компания годами рисовала на схеме аккуратную границу вокруг «сервера платежей», а на аудите выяснилось, что из соседнего VLAN до карточных данных доходят за два шага — через забытое правило на фаерволе и одну админскую станцию. Сегментация, которая существовала только в документации, не уменьшила периметр, а тихо его расширила. Именно вокруг этого сюжета и построены требования 11.3 и 11.4 стандарта PCI DSS 4.0.

PCI DSS стоит особняком среди всех регуляторных рамок: ISO 27001 и GDPR говорят о безопасности вообще, а здесь прямым текстом написано «тест на проникновение» — и зафиксирована его периодичность. Версия 4.0 принцип не изменила, но закрутила гайки: часть требований, которые раньше считались хорошей практикой, стала обязательной после 31 марта 2025 года, а тестирование сегментации вышло на первый план. Разберём, что здесь сканируется машиной, что обязан проверить человек, как часто и какие доказательства попросит оценщик.

Что входит в периметр: CDE и всё, что его касается

Периметр — это не «платёжный сервер». Это среда данных держателей карт (CDE) плюс любая система, которая может к ней подключиться или повлиять на её безопасность: станции администрирования, системы аутентификации, решения мониторинга, подключённые сервис-провайдеры. Система, выведенная за периметр, должна быть выведена и технически — а это доказывается как раз тестированием сегментации.

Самая частая неожиданность на оценке выглядит так: в документации VLAN описан как «отдельный», но добраться до CDE из него можно через забытую firewall-правило или прыжок через админскую станцию. Неподтверждённая сегментация не сокращает периметр, а молча его увеличивает — вместе со всеми требованиями PCI DSS, которые на этот периметр распространяются.

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

Требование 11.3 — сканирование уязвимостей

Пункт 11.3 требует внутренних и внешних сканирований как минимум раз в квартал, а также после любого значимого изменения. Внешние сканирования обязан выполнять ASV — сканирующий вендор, авторизованный PCI SSC. Внутренние можно делать своими силами, но персоналом, независимым от тех, кто администрирует проверяемые системы. В обоих случаях результат «пройдено» означает ноль уязвимостей высокой критичности — а не «мы их все записали в реестр».

Здесь кроется тонкость, которую многие недооценивают. Сканер находит известные проблемы на exposed-сервисах: устаревший TLS, открытый порт с версией библиотеки из базы CVE, отсутствующий патч. Он не умеет связывать находки в цепочку и не понимает бизнес-логику. Поэтому квартальный отчёт ASV — это гигиена, а не доказательство защищённости.

Требование 11.4 — тесты на проникновение

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

Для сервис-провайдеров планка выше. Пункт 11.4.6 поднимает частоту тестирования сегментации до одного раза в шесть месяцев вместо ежегодного. А 11.4.7 добавляет проверку изоляции между клиентами для multi-tenant-провайдеров — требование, которое догоняет ровно ту модель работы, по которой живут SaaS-платформы платежей.

Кто, что и как часто

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

Что QSA попросит из отчёта

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

Обычно QSA ожидает увидеть следующее:

• Заявленную и принятую в индустрии методологию — PTES, OWASP, NIST SP 800-115.
• Обоснование периметра: почему именно эти системы, со ссылкой на диаграмму потоков карточных данных.
• Доказательство, что тестирование покрыло и сетевой слой, и слой приложения.
• Для сегментации — какие контроли проверялись извне CDE и каков результат каждой попытки.
• Документированный ретест по каждой эксплуатируемой уязвимости, с датой и финальным статусом.
• Независимость тестировщика от команды, которая администрирует проверяемые системы.

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

Важно: «мы всё записали и запланировали исправление» не закрывает требование. Уязвимость, которую можно эксплуатировать, должна быть устранена и перепроверена — с датой и подтверждённым статусом.

Сегментация: главный сюжет версии 4.0

Тестирование сегментации проверяет простую вещь: действительно ли сети, объявленные вне периметра, не могут добраться до среды карточных данных. Значимость здесь не косметическая. Сегментация — это механизм, которым сокращается периметр. Если она не держится, в периметр попадают все системы, достигающие CDE, а вместе с ними — все требования стандарта: инвентаризация, управление патчами, журналирование, контроль доступа.

На практике проверка выглядит не как запуск сканера, а как серия целенаправленных попыток. Из-за пределов CDE тестировщик пробует пройти по маршрутам, которые в документации считаются закрытыми: прыжок через админскую станцию, использование доверенных отношений между доменами, доступ через систему мониторинга, подключённую к обоим сегментам. Каждая попытка фиксируется вместе с результатом — именно этот список и запрашивает оценщик.

Для сервис-провайдеров добавляется измерение multi-tenant. Клиенты одной платформы не должны видеть данные друг друга, и это тоже проверяется технически, а не декларацией. Для SaaS-платформ платежей это ровно та зона, где архитектурная ошибка превращается в инцидент сразу у нескольких клиентов.

Что изменилось при переходе с 3.2.1 на 4.0

Структура требований к тестированию была перенумерована: 11.3 стало сканированием, 11.4 — пентестом. Появились новые требования к изоляции multi-tenant и к многофакторной аутентификации, а ряд практик, считавшихся «хорошими», стал обязательным после 31 марта 2025 года. Возник и персонализированный подход, позволяющий достичь цели требования через альтернативные контроли — но с существенно более тяжёлой документацией и валидацией.

Смысл изменений прост: стандарт перестал доверять формулировкам и перешёл к доказательствам. Раньше можно было написать «сегментировано» и приложить схему. Теперь нужно показать, что именно вы пытались сделать извне периметра и что из этого вышло.

Применимо ли это к компании из Молдовы

PCI DSS — не закон, а контрактное требование, которое карточные схемы накладывают через банки и процессинговые компании. Оно распространяется на любую организацию, которая хранит, обрабатывает или передаёт карточные данные, независимо от страны. Для компаний из Молдовы требование обычно приходит через банк-эквайер или партнёра-процессора, а уровень валидации зависит от годового объёма транзакций. Мы выполняли тестирование для платёжных процессоров и финансовых организаций Молдовы, в том числе в рамках процессов регистрации в Национальном банке Молдовы.

Как выстроить работу без авралов

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

Отдельно стоит вложиться в документацию периметра. Диаграмма потоков карточных данных, которая честно отражает, какие системы касаются CDE, экономит недели на этапе согласования объёма. Если же схема расходится с реальностью, тестирование сегментации это покажет — и лучше узнать об этом от пентест-команды, чем от QSA в последний день аудита.

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