В трёх из пяти проектов по микросегментации, которые я аудировал за последние полтора года, внутри созданных сегментов стояло правило «permit any any». Формально сегментация сети есть, в отчёте для руководства архитектура нулевого доверия красиво нарисована - а реально атакующий перемещается горизонтально без единого препятствия. CISA в 2025 году выпустила отдельный документ «Microsegmentation in Zero Trust Part One», где прямо говорит: ошибки на этапе проектирования политик обнуляют все инвестиции в Zero Trust архитектуру. При средней стоимости утечки данных $4,88 млн (IBM Cost of a Data Breach Report 2024) значительная доля ущерба приходится на организации, где горизонтальное перемещение атакующего не было остановлено микросегментацией сети.
Почему классическая сегментация сети не останавливает lateral movement
Традиционная сетевая сегментация строится на VLAN и ACL. Для разделения broadcast-доменов и контроля north-south трафика - того, что идёт от клиента к серверу через периметр - этого хватает. Проблема в другом: основной объём трафика современных дата-центров и облачных сред - east-west, между рабочими нагрузками внутри периметра. По данным Palo Alto Networks, east-west коммуникации составляют бо́льшую часть трафика дата-центров, а периметровые средства защиты этот трафик попросту не видят. Всё, что внутри периметра, неявно считается доверенным.Атакующий, получивший первоначальный доступ через скомпрометированные учётные данные (T1078, Valid Accounts), начинает разведку: обнаружение сетевых сервисов (T1046), поиск соседних систем (T1018), анализ сетевых соединений (T1049) и конфигурации сети (T1016). Затем - горизонтальное перемещение через Remote Services (T1021) и, если повезёт, Network Boundary Bridging (T1599) для выхода за пределы текущего сетевого сегмента. Классическая VLAN-сегментация не помешает ни одному из этих шагов, если атакующий уже внутри «доверенного» периметра.
Пересобрать VLAN-структуру под новые требования - задача, которая тянет за собой изменение физической или логической архитектуры сети. По оценке Palo Alto Networks, реархитектура сетей и переконфигурация VLAN под требования безопасности - процесс долгий и дорогой. Именно поэтому микросегментация сети Zero Trust - это не «VLAN помельче», а принципиально другой подход к контролю east-west трафика, построенный на программно-определяемых периметрах вокруг каждой рабочей нагрузки.
Три подхода к микросегментации сети
По классификации Palo Alto Networks, контроли микросегментации делятся на три категории. Выбор подхода определяет архитектуру, бюджет и сроки внедрения - решение нужно принимать до закупки конкретных инструментов микросегментации.Агентные решения
Программный агент ставится непосредственно на рабочую нагрузку - хост, VM, контейнер - и обеспечивает гранулярную изоляцию на уровне хоста. Агент может использовать встроенный файрвол ОС (iptables, Windows Firewall) или собственный механизм enforcement. Политики строятся на основе идентичности рабочей нагрузки и её атрибутов, а не IP-адресов. Для динамических сред это принципиально.Главное преимущество - полная независимость от сетевой инфраструктуры. Агент одинаково работает в on-premise дата-центре, публичном облаке и гибридной среде. Видимость east-west трафика полная, включая коммуникации между процессами на одном хосте. Обратная сторона - агент нужно ставить, настраивать и обновлять на каждом хосте. В средах с тысячами узлов это ощутимая операционная нагрузка, и без зрелых процессов конфигурационного управления начнётся хаос.
Сетевые (SDN) решения
Контроль идёт через программно-определяемую сеть: виртуальные коммутаторы, overlay-сети, распределённые файрволы на уровне гипервизора. Политики применяются на сетевом фабрике без установки агентов на рабочие нагрузки. В случае VMware NSX каждый виртуальный порт получает собственный файрвол (Distributed Firewall), который инспектирует east-west трафик до того, как он попадёт в физическую сеть.Плюс - централизованное управление и отсутствие агентской нагрузки. Минус - привязка к вендору сетевой платформы и головная боль в гетерогенных средах, где сосуществуют несколько гипервизоров, bare-metal серверы и контейнерные оркестраторы.
Облачные нативные контроли
Встроенные механизмы облачных провайдеров: AWS Security Groups, Azure Network Security Groups, Google Cloud Firewall. Управление через API провайдера, интеграция «из коробки».Плюс - нулевые затраты на дополнительные инструменты. Минус - работает только внутри конкретного облака, не покрывает on-premise или мультиоблачные сценарии.
| Критерий | Агентные | Сетевые (SDN) | Облачные нативные |
|---|---|---|---|
| Зависимость от инфраструктуры | Нет | Да (вендор сети) | Да (облачный провайдер) |
| Гибридные среды | Нативно | Частично | Нет |
| Гранулярность | До процесса/контейнера | До VM/порта коммутатора | До VM/подсети |
| Операционная нагрузка | Высокая (агенты на хостах) | Средняя | Низкая |
| Видимость east-west трафика | Полная | Зависит от архитектуры | В рамках облака |
| Вендорная независимость | Частично | Нет | Нет |
Для большинства корпоративных сред с гибридной инфраструктурой оптимальна комбинация: агентное решение для кросс-платформенного enforcement плюс облачные контроли для cloud-native рабочих нагрузок. В ближайшие годы большинство предприятий, внедряющих Zero Trust, будут использовать несколько методов сегментации одновременно - и это не избыточность, а реальность гибридного мира.
Инструменты микросегментации: сравнение для вашей инфраструктуры
Выбор конкретного продукта - один из первых вопросов, который задаёт CISO или IT-директор. Ниже - сравнение решений, с которыми я работал в проектах по Zero Trust-трансформации.| Инструмент | Подход | Преимущества | Ограничения | Когда выбирать |
|---|---|---|---|---|
| Illumio | Агентный | Кросс-платформенная видимость, политики на основе меток, визуализация зависимостей | Агент на каждом хосте, стоимость лицензий при масштабировании | Гибридные среды (GNU/Linux)/Windows/контейнеры |
| Akamai Guardicore | Агентный | Детальная карта зависимостей приложений, встроенный deception-модуль | Агентская нагрузка, ограниченная поддержка ряда legacy ОС | Среды с высокими требованиями к видимости и threat deception |
| VMware NSX | Сетевой (SDN) | Distributed Firewall на гипервизоре, глубокая интеграция с vSphere | Привязка к VMware-стеку, не покрывает bare-metal | Полностью виртуализированные дата-центры на VMware |
| Cisco ACI | Сетевой | Аппаратное enforcement, высокая пропускная способность | Требует Cisco Nexus, значительные начальные инвестиции, сложная настройка | Крупные дата-центры на оборудовании Cisco |
Illumio и Akamai Guardicore стабильно получают высокие оценки на Gartner Peer Insights и PeerSpot - агентный подход для задач сетевой изоляции рабочих нагрузок действительно вызрел.
Инструменты для российского рынка
Для субъектов критической информационной инфраструктуры и организаций под 187-ФЗ и требованиями ФСТЭК выбор инструментов микросегментации ограничен. По Приказу ФСТЭК №76, средства защиты информации должны соответствовать определённому классу и пройти сертификацию. По Приказу ФСТЭК №9 от 09.02.2016, межсетевые экраны классифицируются по типам (А - уровень сети, Б - логическая граница сети, В - уровень узла, Г - уровень веб-сервера, Д - промышленный), а требуемый уровень доверия (ОУД) зависит от класса защиты конкретного МЭ.В российских реалиях для задач микросегментации применимы:
- UserGate NGFW - сертифицированный МЭ с L7-фильтрацией, применим для сегментации между зонами и контроля east-west на уровне подсетей
- PT NGFW (Positive Technologies) - NGFW с интеграцией в экосистему PT, включая MaxPatrol SIEM для корреляции событий сегментации с другими источниками
- Сетевые политики Kubernetes (NetworkPolicy) - для контейнерных сред; не требуют отдельной сертификации, если периметровые средства защиты сертифицированы
- RUNOS и Astra Infrastructure Cloud - SDN-решения для российского рынка, но их возможности микросегментации на уровне enterprise пока заметно уступают зарубежным аналогам
Внедрение микросегментации в Zero Trust архитектуре: пошаговый план
Рекомендуемая классификация по уровням:
- Критические системы: приложения, обрабатывающие данные ЗОКИИ (187-ФЗ), финансовые транзакции
- Чувствительные данные: персональные данные (152-ФЗ), медицинская информация, коммерческая тайна
- Инфраструктурные сервисы: Active Directory, DNS, DHCP, системы мониторинга - компрометация любого из них даёт атакующему контроль над всей средой
- Пользовательские сегменты: рабочие станции, сгруппированные по подразделениям и ролям
Формирование политик: от мониторинга к enforcement
Самая ответственная фаза. Типичная ошибка - немедленно включить блокировку. Правильный подход - три последовательные стадии.Стадия 1 - Обнаружение (2–4 недели). Инструмент работает в режиме мониторинга и пассивно собирает данные о реальных коммуникациях. Никакой трафик не блокируется. На выходе - карта всех east-west потоков и автоматически сгенерированные рекомендации по политикам.
Стадия 2 - Тестирование политик (2–4 недели). Создаются правила на основе собранных данных. Инструмент показывает, какой трафик был бы заблокирован при активации enforcement, но фактически пропускает всё. Цель - выявить ложные срабатывания и незадокументированные зависимости между сервисами. Именно здесь всплывают те самые «а мы забыли, что бэкап-агент ходит на все серверы по порту 9090».
Стадия 3 - Enforcement (поэтапный). Политики переводятся в режим блокировки начиная с наименее критичных сегментов: тестовые среды, среды разработки. Критичные production-системы - в enforcement последними, после полной верификации.
Политики микросегментации: принцип минимальных привилегий на практике
Принцип минимальных привилегий применительно к сетевой безопасности: каждая рабочая нагрузка имеет доступ только к тем ресурсам, которые необходимы для выполнения её функции. Не шире, не дольше.
По NIST SP 800-53, контроль AC-1 (Access Control) требует разработки политик, которые определяют цели, роли и ответственность в управлении доступом. Для микросегментации это три правила:
- Default deny - базовое: весь east-west трафик запрещён, кроме явно разрешённого. Прямая противоположность классической модели, где внутренний трафик разрешён по умолчанию
- Least privilege - разрешения выдаются на минимально необходимом уровне: конкретный порт, конкретный протокол, конкретное направление
- Time-bound access - для административных подключений, сервисных окон и задач обслуживания используются временные разрешения с автоматическим откатом
allow 10.100.0.10 tcp/80 политика выглядит как env=prod, app=billing -> env=prod, app=database, port=5432. Изменения в инфраструктуре автоматически обновляют политики без вмешательства человека.Пример политики default deny с явным разрешением для Kubernetes:
YAML:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: billing-to-db
namespace: production
spec:
podSelector:
matchLabels:
app: database
ingress:
- from:
- podSelector:
matchLabels:
app: billing
ports:
- protocol: TCP
port: 5432
policyTypes:
- Ingressapp=billing обращаться к базе данных на порту 5432. Все остальные входящие коммуникации к базе заблокированы - default deny.Типичные ошибки при внедрении микросегментации сети
По данным опроса Zero Networks, 88% CISO сообщили о серьёзных трудностях при внедрении Zero Trust (методология и выборка не раскрыты, так что цифру воспринимайте с оговоркой). Микросегментация - одна из самых сложных компонент, и ошибки здесь бьют по бюджету и срокам напрямую.1. «Permit any any» внутри сегмента. Самая частая и самая разрушительная ошибка. Организация создаёт сегменты, но внутри каждого - полная свобода коммуникаций. Атакующий, попавший в сегмент, перемещается по нему без ограничений. Микросегментация работает только при default deny внутри сегмента. Иначе это VLAN с новым названием.
2. Big bang deployment. Попытка перевести все сегменты в enforcement одновременно. Результат - массовые инциденты с доступностью, паника пользователей, волевое решение руководства откатить всё. Проект «замораживается» на неопределённый срок. Правильный путь - поэтапный ввод, начиная с тестовых сред.
3. Политики на основе IP-адресов. IP-адреса меняются при масштабировании, миграции VM, в облачных средах. Правило
allow 10.0.1.0/24 -> 10.0.2.0/24 ломается при первой же реорганизации адресного пространства. Метки и атрибуты рабочих нагрузок устойчивы к изменениям инфраструктуры.4. Отсутствие мониторинга после деплоя. Политики создали, перевели в enforcement - и забыли. Без постоянного мониторинга не видно: новых легитимных зависимостей, которые блокируются; попыток обхода или отключения средств сегментации (T1686, Disable or Modify System Firewall); дрейфа конфигурации. Интеграция с SIEM обязательна - события микросегментации должны коррелироваться с другими источниками.
5. Игнорирование east-west внутри одного уровня доверия. Типичная картина: сегментируют «бухгалтерию от IT-отдела», но не сегментируют серверы баз данных между собой внутри одного дата-центра. Именно так работает Network Boundary Bridging (T1599) - атакующий перемещается между системами на одном уровне доверия, где контроль минимален.
Чеклист внедрения микросегментации сети
Готовый список действий для передачи команде - от планирования до эксплуатации.- Провести инвентаризацию всех рабочих нагрузок (серверы, VM, контейнеры, сетевое оборудование) с указанием владельца и уровня критичности
- Собрать матрицу east-west коммуникаций - NetFlow/sFlow или агентные данные за минимум 2 недели рабочей активности
- Определить protect surfaces: критичные данные, приложения, инфраструктурные сервисы
- Классифицировать активы по уровню риска и регуляторным требованиям (187-ФЗ для ЗОКИИ, 152-ФЗ для ИСПДн, отраслевые стандарты)
- Выбрать подход к микросегментации (агентный / сетевой / облачный / комбинированный) на основе текущей инфраструктуры
- Для субъектов КИИ - проверить соответствие выбранного инструмента требованиям ФСТЭК (класс защиты, ОУД, профиль защиты МЭ)
- Развернуть инструмент в режиме мониторинга (без блокировки) на пилотной группе - минимум 2 недели
- Сформировать политики на основе реального трафика: default deny + явные разрешения по меткам и атрибутам
- Протестировать политики в режиме alert-only - зафиксировать все ложные срабатывания и незадокументированные зависимости
- Перевести в enforcement пилотный сегмент, мониторить инциденты доступности минимум 1 неделю
- Поэтапно расширять enforcement - от менее критичных сегментов к более критичным
- Настроить интеграцию с SIEM для корреляции событий микросегментации с другими источниками телеметрии
- Установить регулярный цикл пересмотра политик: раз в квартал или при каждом изменении архитектуры приложений
- Документировать все исключения и временные разрешения с указанием срока действия и ответственного лица
- Провести табличные учения: смоделировать компрометацию узла внутри защищённого сегмента и проверить, останавливает ли микросегментация lateral movement
Неудобная правда: микросегментация - это не покупка ещё одного продукта, а перестройка операционной модели управления сетью. Пока CISO воспринимает микросегментацию как «проект закупки», а не как трансформацию процессов - результат будет один: красивые дашборды в режиме мониторинга и ни одного правила в enforcement.
Я видел организации, которые два года собирали данные о трафике и ни разу не перешли к блокировке - потому что никто не взял на себя ответственность за потенциальный простой сервиса на 15 минут. Программно-определяемый периметр существует формально, а lateral movement атакующего по-прежнему не встречает сопротивления.
Если команда не готова к первому ложному срабатыванию, которое уронит тестовый сервис - она не готова к микросегментации. И это нормально. Начните с одного protect surface, одного сегмента, одного приложения. Один сегмент в enforcement приносит больше пользы, чем сотня в мониторинге.
Последнее редактирование модератором:
