Gap-анализ PCI DSS 1.2: что больнее всего у интернет-эквайера

PCI DSS - стандарт, о котором в России принято знать понаслышке: «что-то про карточки, банки занимаются». На практике к нам обратился клиент, у которого интернет-магазин принимает платежи картами через собственный эквайринг - не через внешний платёжный шлюз, а именно через прямое соединение с процессором. Банк-эквайер поставил условие: до конца года - подтверждение соответствия PCI DSS. Клиент пришёл с вопросом «и что нам теперь делать?».

Мы начали с gap-анализа по актуальной версии стандарта - PCI DSS 1.2. Версия 2.0, которую PCI SSC анонсировал к выходу в этом же октябре, ещё в стадии публикации, поэтому работаем с тем, что действует. По результатам - несколько зон, которые оказались болезненнее, чем клиент ожидал.

Кратко про структуру стандарта

PCI DSS 1.2 - это шесть целей и двенадцать требований. Технические меры перемежаются с организационными, и нередко именно организационная часть оказывается слабее: процессы не описаны, ответственность не назначена, политик нет. Но в этом проекте технические пробелы оказались не менее острыми.

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

Сегментация: требование есть, реализации нет

Требование 1 стандарта - межсетевое экранирование, ограничение трафика к компонентам карточной среды (CDE, Cardholder Data Environment). Требование 1.3 конкретизирует: запрет прямого публичного доступа к любому компоненту CDE, ограничение входящего и исходящего трафика только до необходимого минимума.

На практике у клиента этого не было вообще. Серверы платёжного сегмента стояли в той же подсети, что и рабочие станции менеджеров. Фаервол на периметре был - но правила пропускали всё внутри LAN без каких-либо ограничений. С любой офисной машины можно было обратиться к базе данных транзакций по прямому TCP-соединению. Никаких DMZ, никакой изоляции.

Объяснение простое и понятное: «ну, это же внутренняя сеть, там все свои». Объяснение не работает ни технически (инсайдер, заражённая рабочая станция, горизонтальное перемещение после взлома периметра), ни с точки зрения аудитора PCI.

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

Логирование: что писать и как хранить

Требование 10 PCI DSS - отслеживание и мониторинг всего доступа к сетевым ресурсам и данным карт. В частности, 10.2 обязывает логировать все действия привилегированных пользователей - каждую административную сессию, каждое использование root или эквивалентных прав, каждый доступ к данным карт.

У клиента логирование было, но частичное. Системные логи на серверах велись, но:

• Нет централизации. Логи лежали локально на каждом сервере. Что произойдёт с логами, если сервер скомпрометирован - вопрос риторический.
• Нет покрытия баз данных. На SQL-сервере аудит базы данных не был включён вообще. Кто обращался к таблицам транзакций, какие запросы выполнял - не фиксировалось.
• Нет логирования неуспешных попыток доступа. PCI DSS требует записывать и успешные, и неуспешные попытки - последние особенно важны как сигнал подбора.
• Сроки хранения не соблюдены. Требование 10.7 - минимум год, три месяца оперативно доступны. На серверах ротация была настроена на месяц.

Привилегированных пользователей у клиента на серверах CDE оказалось больше, чем нужно: несколько человек из IT имели root/Administrator без разбора, потому что «все занимаются инфраструктурой». PCI DSS требует минимум привилегий и отдельные учётные записи для каждого администратора - общий admin без персонализации не принимается.

Что ещё нашли

Это два самых болезненных пункта, но не единственные. Коротко по остальным находкам:

• Требование 3 (хранение данных карт) - у клиента в базе транзакций хранились полные номера карт PAN в незашифрованном виде. CVV не хранился - это хорошо, это уже нарушение запрета. Но PAN - тоже под ограничения: если хранить, то шифровать с управлением ключами. Если не нужен бизнесу - не хранить.
• Требование 6 (патчи) - на нескольких серверах обновления ОС не устанавливались последние полгода. Процесса управления уязвимостями нет.
• Требование 8 (управление доступом) - отсутствует политика паролей, удалённый доступ к серверам по RDP с простыми паролями, MFA нигде нет.

Где сейчас

Gap-анализ закончен, отчёт с приоритизированным планом устранений у клиента. Работы по сегментации сети - это несколько недель проектирования и внедрения, там спешить нельзя, можно положить платёжный процессинг. Логирование - быстрее, но требует выбора централизованного решения: syslog-сервер с нормальным хранением или что-то с элементами SIEM для корреляции.

Разговор о самооценке (SAQ) или полном QSA-аудите предстоит отдельный - зависит от того, как клиент квалифицируется по уровням PCI DSS. При объёме транзакций, который у него сейчас, скорее всего SAQ D как мёрчант с прямым подключением к процессору. Это не самый короткий опросник.

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