PCI DSS 2.0 на практике: помогаем e-commerce пройти SAQ и разобраться с сегментацией

Переход с PCI DSS v1.2 на v2.0 формально завершился в конце 2011-го. Это значит, что с января 2012-го все SAQ и QSA-аудиты принимаются исключительно по второй версии. Клиент из e-commerce пришёл к нам в июне с простым запросом: «надо пройти Self-Assessment Questionnaire, но мы не понимаем, что именно у нас не так». Понятная история - SAQ на 200+ вопросов при первом знакомстве выглядит устрашающе, особенно если читать его без контекста о том, что именно входит в Cardholder Data Environment.

Разбирались несколько недель. Вот что оказалось главным.

Какой SAQ им вообще нужен

Первый вопрос при работе с PCI DSS - не «как защититься», а «в рамках какого SAQ мы вообще находимся». Их несколько, и объём требований отличается кардинально. Клиент принимает карты через платёжный шлюз, на своём сайте форма оплаты открывает iframe со страницы процессора. Значит, он не хранит и не обрабатывает PAN напрямую - это SAQ A или SAQ A-EP, в зависимости от того, как реализован iframe.

Выяснилось, что у клиента редирект-интеграция, а не hosted fields. Страница оплаты технически поднимается на домене клиента, а потом перенаправляет на процессора. В этом случае PCI DSS считает, что сервер клиента всё равно участвует в транзакции - это SAQ A-EP, а не лёгкий SAQ A. Разница: SAQ A - 13 требований, SAQ A-EP - около 100. Это первое открытие, которое заметно подняло сложность.

Сегментация сети: где начинается CDE

Второй большой блок - сегментация. PCI DSS требует, чтобы системы, которые хранят, обрабатывают или передают данные держателей карт, были изолированы от остальной инфраструктуры. Это называется Cardholder Data Environment (CDE). Если сегментации нет - в область аудита попадает вся сеть.

У клиента сеть была плоская. Сервер приложения, база данных, внутренняя CRM, офисные машины разработчиков - всё в одном VLAN без ACL между сегментами. Формально под SAQ A-EP это уже проблема: веб-сервер, который принимает запросы с данными карт до редиректа, и база данных клиентов находились в одном сетевом сегменте, и изолировать один без другого было нетривиально.

Сделали следующее:

• Выделили DMZ для веб-серверов. Сервер приложения переехал в отдельный VLAN за межсетевым экраном. ACL ограничивает доступ: снаружи - только 443, изнутри - только к нескольким портам внутренних сервисов.
• Изолировали базу данных. БД с клиентскими данными (там были email, имена, телефоны - не PAN, но чувствительные данные) переехала в отдельный VLAN. Доступ к ней - только с сервера приложения по конкретному порту.
• Задокументировали периметр CDE. Это отдельный артефакт, который нужен для SAQ: описание того, что именно входит в scope, с диаграммой сети. Без документа - нечего показывать при проверке.

Сегментация подняла объём работы, но одновременно сократила scope: теперь под требования PCI DSS попадают два-три сервера, а не вся инфраструктура.

Шифрование данных держателей карт - точнее, их отсутствие

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

Хранения PAN не было - данные карт напрямую не писались ни в базу, ни в логи. Это хорошо. Но в логах приложения обнаружились части запросов от процессора - там были замаскированные, но читаемые токены транзакций и иногда последние 4 цифры карты в теле ответа. По формальной логике PCI DSS последние 4 цифры PAN хранить разрешено, но контекст вокруг них (имя держателя, сумма, дата) вместе формировал запись, которая требовала защиты.

Лог-файлы были в открытом виде на диске сервера. Требование 3.4 PCI DSS 2.0 говорит: PAN при хранении должен быть нечитаем (через хеш, усечение, токенизацию или шифрование). Для данных, которые технически не являются полным PAN, прямого требования шифрования нет, но хранить чувствительные данные транзакций в читаемых логах - это риск, который проверяющий точно отметит.

Решение: ротацию и очистку логов настроили через logrotate с retain 7 дней вместо неограниченного хранения, чувствительные поля в logging-конфиге приложения замаскировали через фильтры на уровне фреймворка. Не шифрование в строгом смысле, но данных в читаемом виде на диске стало существенно меньше.

Где сейчас

SAQ A-EP с клиентом ещё не закрыт - там остаётся раздел по управлению уязвимостями (требование 6) и по мониторингу доступа (требование 10). Про это напишем отдельно, если будет что сказать.

Главный вывод из этого кейса: самый сложный момент в PCI DSS - не технические требования, а определение scope. Плоская сеть без сегментации делает весь парк серверов частью CDE, и тогда объём работы вырастает в разы. Сегментация требует усилий на старте, но после неё требования применяются к изолированному набору систем, а не ко всей инфраструктуре.

Если вы принимаете карты и не уверены, какой SAQ вам нужен - начать стоит с аудита именно scope, а не с попыток сразу ответить на все 200 вопросов анкеты.