Скоуп PCI DSS: где на самом деле заканчиваются границы аудита?

01.09.2026

Границы проверки PCI DSS определяют реальный объем работ и затрат компании на информационную безопасность. Неверно очерченный периметр создает технические и финансовые сложности еще до начала аудита. Рассмотрим критерии включения систем в аудит, неочевидные объекты проверки и технически обоснованные способы уменьшения периметра.

Сначала разберемся, что означают базовые термины PCI DSS:

Скоуп аудита (границы проверки) — полный перечень систем, процессов, людей и среды организации, которые подлежат аудиту. Объем скоупа определяет сложность, сроки и бюджет проекта сертификации. Каждая система в границах аудита предполагает полный набор контролей — например, управление конфигурациями, обновления, журналирование, контроль доступа, сканирование уязвимостей.
Системный компонент (system component) — базовая техническая единица в аудитах PCI DSS, которая включается в границы аудита. Это может быть, например, платежное приложение, сервер баз данных, сетевое устройство, система управления виртуализацией, облачные компоненты, принтер, а также рабочая станция администратора или мобильное устройство, с которых осуществляют администрирование. 
CDE (Cardholder Data Environment) — среда данных держателей карт. Это совокупность системных компонентов, процессов и персонала, задействованных в хранении, обработке или передаче карточных данных (CHD) либо чувствительных аутентификационных данных (SAD), а также все неизолированные системы, соединенные с CDE. 

Однако CDE — это основа, а не весь скоуп. Границы аудита шире: они также охватывают системы, способные повлиять на безопасность CDE, даже если те не хранят, не обрабатывают и не передают карточные данные. Компрометация таких систем может открывать злоумышленнику доступ к карточным данным, поэтому ее проверяют наравне с системами CDE.

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

С чего начинается определение границ аудита?

Границы аудита определяются согласно руководству PCI SSC Guidance for PCI DSS Scoping and Segmentation. Именно на его логику опирается аудитор при проверке полноты определенного скоупа.

Система попадает в границы аудита, если выполняется хотя бы одно из условий:

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

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

Критерии включения не-CDE систем в границы аудита PCI DSS

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

Системы в одном сетевом сегменте с системами, которые хранят, обрабатывают или передают карточные данные

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

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

Системы, влияющие на безопасность CDE

Такие системы имеют особый статус, поскольку непосредственно влияют на защищенность среды карточных данных. Этот критерий охватывает две подкатегории:

1. Системы, которые управляют доступом, администрированием или влияют на безопасность CDE: например, серверы аутентификации и службы каталогов (Active Directory, LDAP, IAM/PAM), рабочие станции администраторов (PAW / jump-серверы), а также критические сетевые сервисы (NTP, DNS).
2. Системы, которые поддерживают выполнение требований стандарта: например, антивирус, DLP (предотвращение утечек данных), IPS/IDS (предотвращение вторжений и их обнаружение), FIM (контроль целостности файлов), SIEM (управление событиями и информацией безопасности).

Такие системы расположены за пределами CDE, но имеют прямой административный доступ к среде или управляют процессами внутри нее. Компрометация сервера антивируса позволяет отключить защиту или загрузить вредоносный код на системы без прямого доступа к CDE. Компрометация службы каталогов дает злоумышленнику административный доступ к CDE без прямой атаки на системы CDE, а компрометация SIEM позволяет удалить следы действий в журналах или использовать агента как точку проникновения.

Системы с прямым подключением к CDE

Последний критерий охватывает системы, которые не включаются в CDE, но имеют к нему прямое подключение (например, бастионные серверы (jump hosts) для удаленного администрирования). Они не хранят, не обрабатывают и не передают карточные данные, но компрометация такого сервера через существующую сетевую связь открывает злоумышленнику доступ к CDE.

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

Отдельного внимания требует «правило исключения» (out-of-scope). Система остается за пределами аудита только при одновременном соблюдении четырех критериев (нарушение хотя бы одного из них автоматически включает систему в скоуп):

Системы, которые чаще всего забывают включить в границы аудита

В границы аудита попадают не только хранилища данных, но и любые системные компоненты, способные повлиять на безопасность CDE.

Рабочая станция администратора при работе с облаком

Если в IaaS (инфраструктура как услуга) организация имеет доступ к операционной системе виртуальных машин и настраивает защиту самостоятельно, то в PaaS (платформа как услуга) и SaaS (программное обеспечение как услуга) такого доступа нет. Из-за этого возникает ложное впечатление, что рабочие станции администраторов выпадают из скоупа.

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

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

В частности, аудитор учитывает две критические угрозы:

Таким образом, даже без сохранения карточных данных на диск рабочая станция напрямую влияет на безопасность CDE через активную сессию управления. Именно из-за этого влияния (security-impacting) аудитор квалифицирует ее как системный компонент в границах скоупа.

Смартфон администратора

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

Проблема в том, что личный смартфон мгновенно попадает в скоуп как устройство администрирования. Если на нем нет корпоративного профиля защиты (MDM), антивируса и контроля обновлений, аудитор квалифицирует такое подключение как критическое несоответствие стандарту.

Стандарт четко относит мобильные устройства и рабочие станции администраторов к системным компонентам. Если со смартфона или рабочей станции заходят в консоль управления CDE, они попадают в границы аудита наравне с ноутбуком. Если же устройство подключено одновременно к недоверенной сети и к CDE, начинает действовать требование 1.5.1 с отдельным набором контролей.

Наличие сертификата соответствия (AoC) у облачного провайдера не освобождает клиента от прохождения сертификации собственной среды. Чтобы разграничить зоны контроля, облачные провайдеры разрабатывают матрицу распределения ответственности (Shared Responsibility Matrix).

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

Репозитории кода

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

Именно поэтому стандарт требует:

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

Легитимные способы уменьшить границы аудита

Уменьшение скоупа — это не попытка скрыть системы от аудитора, а целенаправленная перестройка архитектуры, которая устраняет основания для включения некритичных компонентов в границы аудита.

Сегментация сети

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

Само по себе наличие VLAN (виртуальной локальной сети) или межсетевого экрана не доказывает возможность исключения сети из границ аудита. Нужно подтверждение — тестирование на проникновение мер сегментации: раз в 12 месяцев (требование 11.4.5), для сервис-провайдеров — раз в 6 месяцев (требование 11.4.6), а также после значительных изменений в структуре сетевой изоляции, которые влияют на сегментацию. Пассивной проверки конфигураций недостаточно: специалист по тестированию на проникновение должен попытаться обойти защитные контроли, которые обеспечивают сегментацию.

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

Интеграционная шина данных

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

Интеграционная шина данных (ESB) работает как посредник: принимает запрос от информационной системы, разрывает прямое соединение, проверяет данные, выполняет логику и обращается к CDE под собственной учетной записью. Сама шина при этом полностью включается в границы аудита, а потоки данных ограничиваются на ее контролируемых интерфейсах.

Благодаря отсутствию прямого подключения смежные сервисы — например, CRM (управление взаимоотношениями с клиентами) или системы электронного документооборота — можно обоснованно вывести за пределы скоупа. Впрочем, корректность такого архитектурного исключения окончательно подтверждает QSA-аудитор.

Почему границы аудита требуют регулярного пересмотра?

Стандарт требует документировать и подтверждать границы проверки не реже одного раза в 12 месяцев (требование 12.5.2), а для сервис-провайдеров — раз в 6 месяцев (требование 12.5.2.1). Подтвердить границы — значит проверить, соответствуют ли диаграммы, инвентаризация системных компонентов и перечень потоков карточных данных фактическому состоянию инфраструктуры.

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

Оптимизация и точный расчет границ PCI DSS со специалистами IT Specialist

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

Мы обеспечиваем комплексное сопровождение при подготовке к сертификации:

Готовитесь к сертификации или сомневаетесь, правильно ли определены границы аудита? Обратитесь к IT Specialist — обсудим текущий скоуп и возможные варианты его сокращения.

Автор статьи — Анастасия Кармазина, ведущий аудитор информационных технологий