PCI DSS 2.0: виртуализация в scope и переработка сегментации VMware-кластера

В октябре PCI SSC опубликовал версию 2.0 стандарта. До января 2012 года можно работать по 1.2, переход не обязателен прямо сейчас - но мы с клиентом всё равно сели и разобрали, что изменилось. Клиент тот самый, с которым мы делали gap-анализ по 1.2 в октябре: платёжный сегмент, интернет-эквайринг, работы по сегментации ещё идут. Логично было посмотреть на 2.0 заранее, пока инфраструктура ещё в процессе перестройки.

Общая тональность новой версии - «уточнение, а не революция». PCI SSC подчёркивает, что требования существенно не изменились, только конкретизированы. Но есть один раздел, который для нашего клиента оказался очень даже революционным.

Виртуализация теперь явно в scope

В версии 1.2 виртуализация упоминалась вскользь. На практике это порождало разные интерпретации: одни считали, что гипервизор - это просто «железо», другие - что VM в CDE автоматически тянут за собой весь хост целиком. Аудиторы трактовали по-разному, клиенты строили инфраструктуру под удобную трактовку.

В 2.0 PCI SSC убрал эту двусмысленность. Появилось явное указание: компоненты виртуализации - гипервизоры, виртуальные машины, виртуальные коммутаторы, виртуальные сетевые адаптеры - входят в scope, если они обрабатывают, хранят или передают данные карт, либо связаны с такими компонентами. Отдельно упомянуто: если VM из CDE и VM вне CDE сидят на одном физическом хосте, этот хост и все его компоненты виртуализации попадают в scope.

Для клиента это прямое попадание. У него VMware-кластер, и часть VM на нём - платёжные серверы. Мы уже работали над сегментацией на сетевом уровне, но схему виртуализации под угол зрения PCI проектировали по старой логике 1.2.

Что это значит для VMware-кластера

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

Есть два пути решения:

• Выделить отдельные физические хосты под CDE-нагрузку. Тогда на этих хостах только платёжные VM, и scope ограничен ими плюс инфраструктурой управления. Понятно, но дорого - нужно железо.
• Жёсткая изоляция на уровне гипервизора - если аудитор готов принять компенсирующие меры: отдельные vSwitch без общих uplink, политики без возможности миграции CDE-VM на хосты вне CDE, раздельные учётные записи vCenter с разграничением по кластерам. Это технически реализуемо на vSphere, но требует точной документации и убедительной демонстрации аудитору.

Клиент склоняется к первому варианту - выделить два хоста из четырёх под CDE. Это проще аргументировать и меньше зависит от того, как конкретный QSA интерпретирует «жёсткую изоляцию на гипервизоре». Два оставшихся хоста уходят под корпоративные нужды.

Отдельный вопрос - vCenter. Если сервер управления виртуализацией один и он управляет и CDE-хостами, и всеми остальными - он тоже в scope. Либо отдельный vCenter для CDE, либо обоснование почему нет. Это не катастрофа, но ещё одна VM, которую нужно включить в аудит, защитить и задокументировать.

Остальные изменения - меньше сюрпризов

Что ещё поменялось в 2.0, коротко:

• Требование 6.6 (защита веб-приложений) - уточнена формулировка: WAF или проверка кода, но сделан акцент на том, что проверка кода должна быть независимой. Внутреннее code review уже не так однозначно принимается.
• Требование 11.1 (поиск беспроводных точек доступа) - сканирование на несанкционированные точки теперь должно быть ежеквартальным и охватывать физические помещения CDE. Раньше формулировка была мягче.
• Требование 12 (политики и процедуры) - добавлена явная привязка политики управления рисками к ежегодной переоценке. Не новая идея, но теперь прямо прописана.
• Удалено требование 6.3 в части отдельного критерия разработки и тестирования - интегрировано в другие пункты. Скорее косметика.

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

Где мы сейчас

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

До января 2012 времени достаточно, чтобы всё сделать по 2.0 сразу, не переделывая потом. Так и планируем.