VMware NSX 6.2 на практике: файервол на уровне vNIC и что это значит для PCI DSS

В сентябре мы писали про сегментацию VLAN как разумный минимум для любой корпоративной сети. Это честная практика: разбить L2-домен на логические зоны, поставить ACL на коммутаторах, убрать свободное перемещение трафика внутри сети. Работает, стоит недорого, делается на том что есть.

Но у одного из клиентов этого недостаточно. Финансовая организация, PCI DSS, серьёзные требования к изоляции карточных данных. И тут VLAN-сегментация - это начало разговора, а не его конец.

Почему VLAN не хватает для PCI DSS

Стандарт PCI DSS требует изолировать cardholder data environment (CDE) от всего остального. На бумаге VLAN это делает. На практике аудиторы всё строже смотрят на то, что происходит внутри самого VLAN с CDE: латеральное перемещение между VM в одном сегменте ничем не блокируется.

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

NSX предлагает принципиально другую архитектуру. Файервол - не отдельный appliance, через который ходит трафик. Файервол встроен в гипервизор и работает прямо на уровне vNIC каждой виртуальной машины.

Что такое distributed firewall в NSX 6.2

NSX Distributed Firewall (DFW) - это kernel-модуль в ESXi, который фильтрует трафик до того, как пакет вообще выходит из vNIC VM. Не на уровне vSwitch, не на уровне маршрутизатора - буквально на vNIC источника.

Практическое следствие: east-west трафик между двумя VM на одном хосте проходит через файервол дважды - на выходе из одной и на входе в другую - без участия какого-либо физического или виртуального appliance. Два VM-а на одном ESXi-хосте, один VLAN, правило блокирует между ними конкретный порт - и оно работает. Именно так, не через маршрутизацию в обход.

NSX 6.2 в этом релизе добавил несколько вещей:

• Теггирование объектов Security Tags - можно навешивать на VM динамические теги и строить правила не по IP или VLAN, а по принадлежности к тегу. VM переехала на другой хост? Правила едут с ней.
• Service Composer стал удобнее - связка между политиками безопасности и конкретными VM через группы стала менее болезненной в настройке.
• Flow Monitoring улучшили - визуализация east-west трафика между защищёнными объектами стала читаемее.

Как выглядел пилот

Для клиента развернули NSX Manager поверх существующего vSphere 6.0 U1 кластера. NSX требует vSphere 5.5 минимум, 6.0 работает корректно. NSX Manager - отдельная VA, деплоится в vCenter, после чего видит всю виртуальную инфраструктуру.

Подготовка хостов - установка NSX VIB на каждый ESXi. Это делается через vCenter централизованно, хосты уходят в maintenance mode по одному. Без перезагрузки хоста обойтись нельзя - VIB встраивается в ядро. Для кластера из нескольких хостов это планируемая работа, не катастрофа, но окно надо закладывать.

После подготовки хостов - настройка VXLAN-транспорта (NSX использует overlay-сеть на базе VXLAN) и деплой NSX Edge для north-south трафика.

Самое интересное начинается при настройке DFW-политик. NSX позволяет строить правила в терминах vCenter-объектов: не «IP 10.1.2.3», а «VM в группе Payment-Servers». Группы динамические: VM попадает в группу по имени, тегу, папке, атрибутам Guest Introspection. Это означает, что правила безопасности не привязаны к топологии сети. VM переехала - правила остались с ней.

Для PCI DSS-зоны выглядит это так:

• CDE-группа - все VM, работающие с карточными данными. Входящий трафик - только из разрешённых источников по разрешённым портам. Между VM внутри CDE - только то, что явно разрешено.
• Quarantine-тег - если VM ведёт себя подозрительно (по алертам из SIEM или вручную), оператор вешает тег, VM автоматически изолируется правилом, которое уже существует.
• Default deny внутри CDE-сегмента - то, чего физически не добиться в VLAN без appliance в разрыве.

Что получилось и что удивило

Первый сюрприз - то, что это реально работает так, как описано. Мы привыкли, что маркетинговые описания SDN-решений расходятся с практикой при первом же прикосновении. NSX DFW в этом смысле не разочаровал: правило «запретить трафик между VM в одной группе» - и он действительно запрещается, без каких-либо дополнительных танцев.

Второй сюрприз - Flow Monitoring. Видеть графически, кто с кем разговаривает внутри виртуальной инфраструктуры, на уровне VM-VM - это совсем другое ощущение по сравнению с Netflow на физическом маршрутизаторе. Для PCI DSS это отдельная ценность: аудиторы хотят видеть потоки данных, и здесь это есть из коробки.

Третий момент - операционная сложность. NSX - это не просто «поставил и работает». Это отдельный слой управления, который нужно понимать, обслуживать и который добавляет точек отказа. VXLAN-транспорт, NSX Controller Cluster (три VM для отказоустойчивости), NSX Manager, логирование - это всё требует внимания. Для клиента без выделенного сетевого инженера с опытом NSX это станет нагрузкой на поддержку.

Про стоимость говорим честно

NSX - дорого. Лицензирование per-CPU, на кластер из нескольких двухпроцессорных хостов цифра получается заметная. Это не то решение, которое берут «на вырост» или потому что модно.

Для PCI DSS-окружения у клиента с реальными требованиями к изоляции - цена оправдана. Альтернатива: физические файерволы в разрыв на каждый логический сегмент, ещё большая архитектурная сложность, и всё равно без той гранулярности, которую даёт DFW на уровне vNIC.

Для обычного корпоративного кластера без жёстких compliance-требований - скорее всего VLAN-сегментация и нормально настроенные ACL закрывают 80% задач за значительно меньшие деньги.

Пилот продолжается, в production-решение для клиента превращаем в ближайшие недели. Сопровождение такой инфраструктуры - отдельная задача, берём в рамках managed-сервиса.