Глава 3. Архитектурные паттерны
В Главе 2 мы познакомились с тремя архитектурными подходами NIST SP 800-207: Enhanced Identity Governance (EIG), микросегментация и программно-определяемый периметр (SDP). В этой главе мы разберём каждый подход детально — с конкретными реализациями, инструментами и критериями выбора.
Поток принятия решений: PE → PA → PEP
Прежде чем разбирать подходы, рассмотрим, как работает центральная триада NIST SP 800-207 — механизм политик (PE), администратор политик (PA) и точка применения политик (PEP) — в контексте реального запроса.
Ключевые особенности потока (NIST SP 800-207, Section 3):
- PE не действует в вакууме. Решение основано на данных из множества источников: IdP (идентичность), CDM (состояние устройства), SIEM (аномалии поведения), threat intelligence (индикаторы компрометации).
- PA исполняет, но не решает. PA переводит решение PE в конфигурацию: создаёт токен, открывает туннель, обновляет правило файервола.
- PEP — единственная точка контакта субъекта. Субъект никогда не обращается напрямую к ресурсу; PEP медиирует каждый запрос.
- Решение не финальное. Тенет 6 NIST требует динамической переоценки: если состояние устройства ухудшается mid-session, PE может отозвать доступ через PA → PEP.
Три модели развёртывания NIST
NIST SP 800-207 (Section 3.2) описывает три модели размещения компонентов PEP в инфраструктуре:
1. Агент/шлюз на устройстве (Device Agent/Gateway)
PEP разделён на два компонента: агент на устройстве субъекта и шлюз перед ресурсом. Агент инициирует запрос, шлюз применяет решение.
Когда использовать: организация контролирует устройства и может установить агент (MDM/UEM managed devices). Типичный сценарий: корпоративные ноутбуки с агентом ZTNA.
Пример: Zscaler Client Connector + Zscaler Private Access; CrowdStrike Falcon Zero Trust Assessment + conditional access.
2. Анклав (Enclave-Based)
PEP — шлюз перед группой ресурсов (анклавом). Защищает не отдельный ресурс, а коллекцию ресурсов, объединённых бизнес-функцией.
Когда использовать: легаси-приложения, которые нельзя модифицировать; частное облако или дата-центр с однородной группой сервисов.
Ограничение: внутри анклава контроль ограничен — субъект может видеть ресурсы, к которым не имеет привилегий (NIST SP 800-207, Section 3.2).
3. Ресурсный портал (Resource Portal)
PEP — единый шлюз (портал), через который проходят все запросы. Не требует агента на устройстве субъекта.
Когда использовать: BYOD-сценарии, когда нельзя установить агент; веб-приложения; необходимость поддержки разнородных устройств.
Пример: Google BeyondCorp Access Proxy — именно эта модель. Также: GCP Identity-Aware Proxy (IAP), Cloudflare Access.
Ограничение: портал — потенциальная точка отказа и цель DoS-атак; должен быть хорошо масштабирован (NIST SP 800-207, Section 3.2).
Подход 1: Enhanced Identity Governance (EIG)
Как работает
Идентичность субъекта — главный входной параметр политики. Решение о доступе основано на:
- Кто вы (аутентифицированная идентичность из IdP)
- В каком состоянии ваше устройство (оценка через CDM/EDR)
- Какой контекст запроса (время, геолокация, IP-репутация, поведенческие аномалии)
Сетевая локация явно исключена из факторов доверия. Это наиболее близкий к определению Zero Trust подход: «доступ определяется идентичностью, а не сетью».
Кейс: Google BeyondCorp
Google — первая организация, публично описавшая реализацию EIG в масштабе. С 2014 по 2018 год команда Google опубликовала 6 статей в USENIX ;login:, документирующих архитектуру, развёртывание, миграцию и пользовательский опыт BeyondCorp.
Архитектурные компоненты (Ward & Beyer, USENIX ;login:, Vol. 39, No. 6, December 2014):
| Компонент | Функция | Маппинг на NIST |
|---|---|---|
| Access Proxy | Интернет-facing обратный прокси; все запросы к корпоративным приложениям проходят через него | PEP |
| Access Control Engine (ACE) | Принимает решение allow/deny на основе идентичности, trust tier устройства и политик приложения | PE |
| Trust Inferer | Анализирует состояние устройства (патчи, ПО, шифрование) и назначает динамический уровень доверия | Входные данные для PE |
| Device Inventory | Мета-база, агрегирующая данные об устройствах из множества источников | CDM |
| Pipeline | Конвейер данных: directory services, Puppet, vulnerability scanners, CA, ARP-таблицы → ACE | Источники данных |
Ключевые архитектурные решения:
Нет VPN. Google полностью отказался от привилегированной корпоративной сети. Внутренняя сеть — «непривилегированная» (unprivileged network): частное адресное пространство с минимальными сервисами (DNS, DHCP, Puppet). Устройства подключаются через 802.1x/RADIUS для VLAN-назначения, но это управление трафиком, не контроль доступа.
Per-request авторизация. Access Proxy проверяет каждый HTTP-запрос, не сессию. Устройство, выпавшее из compliance mid-session, теряет доступ на следующем запросе.
Постепенная миграция. Google не отключил VPN в один день. Системы BeyondCorp и VPN работали параллельно; пользователи и приложения переносились постепенно (Peck et al., USENIX ;login:, Summer 2017).
Источник: Ward & Beyer, 2014 (PDF)
Маппинг на NIST: архитектура BeyondCorp наиболее близка к модели ресурсного портала (NIST SP 800-207, Section 3.2) — Access Proxy выступает единым шлюзом для всех запросов, без обязательного агента на устройстве для базового веб-доступа. NIST не делает этого маппинга явно, но структурное сходство очевидно.
Коммерческие реализации EIG
| Продукт | Вендор | Роль PEP | Особенности |
|---|---|---|---|
| Chrome Enterprise Premium (ранее BeyondCorp Enterprise) | Google Cloud | Identity-Aware Proxy (IAP) | Context-Aware Access, Endpoint Verification (Chrome extension), mTLS через HTTPS LB. Переименован в апреле 2024 г. $6/user/month |
| Verified Access | AWS | Resource gateway | Интеграция с AWS IAM Identity Center, Cedar policy language, device trust через CrowdStrike/Jamf |
| Entra Private Access | Microsoft | Global Secure Access connector | Conditional Access как PE, Entra ID как IdP, поддержка TCP/UDP (не только HTTP) |
Источники: Chrome Enterprise Premium; AWS Verified Access; Entra Private Access
Подход 2: Микросегментация
Как работает
Ресурсы размещаются в индивидуальных сегментах с собственными политиками доступа. Фокус — контроль east-west трафика (между рабочими нагрузками внутри сети), а не только north-south (внешний → внутренний).
Ключевое отличие от традиционной сегментации (VLAN):
| Аспект | VLAN-сегментация | Микросегментация |
|---|---|---|
| Гранулярность | Подсеть/VLAN (L2) | Рабочая нагрузка/процесс |
| Основа политик | IP-адреса, порты | Идентичность, лейблы, контекст |
| Латеральное перемещение | Возможно внутри VLAN | Заблокировано — каждая нагрузка изолирована |
| Адаптивность | Статические ACL, ручное обновление | Динамические, программно-определяемые |
| East-west видимость | Минимальная | Полная |
Источник: Akamai: Microsegmentation vs VLANs; CISA Microsegmentation Guidance, July 2025
Два подхода к реализации
Сетевой (network-based): правила применяются инфраструктурой — SDN-контроллером, распределённым файерволом в гипервизоре. Пример: VMware NSX-T Distributed Firewall — правила на уровне vNIC в ядре гипервизора.
Хостовый (host-based): агент на каждой рабочей нагрузке управляет встроенным файерволом ОС (iptables на Linux, WFP на Windows). Пример: Illumio VEN (Virtual Enforcement Node).
Инструменты
Cilium — eBPF-based, Kubernetes-native:
- Программирует ядро Linux напрямую через eBPF — без iptables, без sidecar-прокси
- Identity-based security: каждый pod получает числовой Security Identity на основе Kubernetes-лейблов (не IP-адресов). Политики ссылаются на идентичности
- L3/L4/L7 policy enforcement: фильтрация HTTP-методов, gRPC, DNS-запросов в ядре
- Hubble — встроенная наблюдаемость: flow logs и service maps (L3-L7) в реальном времени
- eBPF использует хеш-таблицы для lookup правил, что эффективнее последовательной обработки цепочек iptables
Источник: Cilium docs: Identity-Based Policy; Cilium docs: eBPF Datapath
Calico — NetworkPolicy + расширенные CRD:
- Поддержка стандартных Kubernetes NetworkPolicy + собственные CRD (GlobalNetworkPolicy)
- Несколько data plane: iptables (традиционный), eBPF (с v3.13), Windows HNS
- Концептуально ближе к традиционным файерволам — легче для аудиторов
Источник: Tigera: Calico vs Cilium
VMware NSX-T (vDefend) Distributed Firewall — для VM-сред:
- East-west файервол в ядре гипервизора, правила на уровне vNIC
- Dynamic Grouping: теги, атрибуты AD, атрибуты VM → политики (не статические IP)
- Default deny: Zero Trust по умолчанию
Источник: VMware NSX Distributed Firewall
Illumio — host-based, любая инфраструктура:
- PCE (Policy Compute Engine): вычисляет политики на основе лейблов (role, application, environment, location)
- VEN (Virtual Enforcement Node): агент на рабочей нагрузке, управляет iptables/WFP
- Два режима: Visibility Only (allow-all + flow reporting) и Full Enforcement (deny by default)
- Работает на VM, bare-metal, облачных инстансах, контейнерах
Источник: Illumio VEN Overview
CISA Microsegmentation Guidance (29 июля 2025)
CISA выпустила руководство «Microsegmentation in Zero Trust, Part One: Introduction and Planning» как часть серии «The Journey to Zero Trust». Документ определяет 4 фазы внедрения микросегментации:
- Identify — определить кандидатов (высокоценные активы и их зависимости)
- Map — картировать зависимости между ресурсами
- Determine — определить политики сегментации на основе рисков
- Deploy — развернуть с валидацией (на уровне хоста, приложения или сервиса)
CISA подчёркивает переход от IP-based к identity-based микросегментации: политики должны основываться на атрибутах идентичности (роли пользователей, типы устройств, поведенческие паттерны), а не на IP-адресах.
Источник: CISA Microsegmentation Guidance
Подход 3: Программно-определяемый периметр (SDP)
Как работает
SDP создаёт невидимую инфраструктуру («dark cloud»): ресурсы не отвечают на сетевые запросы до прохождения аутентификации. Сканирование портов не обнаруживает ничего. Принцип — «authenticate first, connect second» (в противовес TCP, где сначала соединение, потом аутентификация).
Спецификация разработана Cloud Security Alliance (CSA). Версия 1.0 — апрель 2014. Текущая: CSA SDP Specification v2.0 — март 2022. Истоки концепции обычно возводят к модели «need-to-know» DISA (Defense Information Systems Agency), хотя точная дата и документ-первоисточник варьируются в литературе.
Источники: CSA SDP v2.0; BusinessWire: CSA SDP v2.0 announcement
Компоненты CSA SDP v2.0
| Компонент | Роль | Маппинг на NIST |
|---|---|---|
| SDP Controller | Брокер доверия: аутентификация, авторизация, выдача разрешений. Проверяет контекст (идентичность, состояние устройства, геолокация) | PDP (PE + PA) |
| Initiating Host (IH) | Клиент: предоставляет идентичность и контекстные сигналы, инициирует запрос через SPA | Субъект |
| Accepting Host (AH) | Шлюз/сервер: применяет решения Controller, принимает только авторизованные соединения | PEP |
Спецификация разделяет плоскость управления (Controller ↔ IH/AH) и плоскость данных (IH ↔ AH). Все коммуникации защищены Single Packet Authorization (SPA).
Single Packet Authorization (SPA)
SPA — механизм, делающий инфраструктуру невидимой:
Улучшения в SDP v2.0: nonce + timestamp для предотвращения replay-атак; HMAC для целостности; ротация ключей (новый ключ генерируется в течение секунд); уникальные ключи для каждого типа взаимодействия (Client→Controller, Client→Gateway, inter-appliance).
Источник: Appgate: Inside ZTNA — Better SPA
6 моделей развёртывания CSA SDP v2.0
| Модель | Описание | Сценарий |
|---|---|---|
| Client-to-Server | AH и сервис на одном хосте; end-to-end SDP | Прямой доступ к приложению |
| Client-to-Gateway | AH — шлюз перед защищёнными серверами | Легаси-приложения за шлюзом |
| Server-to-Server | Оба сервера запускают SDP; все соединения шифрованы | API-to-API, микросервисы |
| Client-to-Server-to-Client | Сервер как relay между клиентами | Коллаборация, peer-коммуникации |
| Client-to-Gateway-to-Client | Шлюз медиирует peer-to-peer с enforcement | P2P с политиками |
| Gateway-to-Gateway | Новая в v2.0; для IoT-сред | IoT, site-to-site |
Источник: CSA: 6 SDP Deployment Models
Коммерческие реализации SDP
Zscaler Private Access (ZPA):
- Cloud-delivered SDP, 100% software-defined, без on-prem appliances
- App Connector устанавливает только исходящие соединения к облаку Zscaler — нет входящих, инфраструктура невидима
- Пользователи подключаются к приложениям, не к сети (application-level access)
Источник: Zscaler ZPA Data Sheet
Appgate SDP:
- Три компонента: Client, Controller, Gateway
- SPA + mTLS для аутентификации
- «Segment of One» — зашифрованный туннель per-user, трафик только от устройства пользователя к авторизованному ресурсу
- Ротация SPA-ключей: уникальные ключи per interaction type, ротация в секундах
Источник: Appgate: How It Works
Матрица выбора: когда какой подход
NIST SP 800-207 (Section 3) подчёркивает: три подхода комплементарны, а не взаимоисключающи. Большинство организаций используют их комбинацию:
| Критерий | EIG | Микросегментация | SDP |
|---|---|---|---|
| Основной вектор угрозы | Компрометация идентичности, повышение привилегий | Латеральное перемещение, east-west атаки | Разведка, сканирование, неавторизованный доступ |
| Направление трафика | North-south (пользователь → приложение) | East-west (рабочая нагрузка → рабочая нагрузка) | North-south (внешний → внутренний) |
| Требования к клиенту | Браузер (для портальной модели) | Нет (enforcement на хосте/сети) | Агент SDP (для SPA) |
| Cloud-native среды | Естественный выбор (IAM, OIDC, WIF) | Cilium/Calico для Kubernetes | Cloud-delivered (Zscaler ZPA) |
| Легаси/on-prem | Требует интеграцию с IdP | Illumio/NSX-T для VM/bare-metal | Appgate SDP для гибридных сред |
| Пример NIST-модели | Ресурсный портал | Агент/шлюз или Анклав | Агент/шлюз (с SPA) |
| Сложность внедрения | Низкая-средняя (если есть IdP) | Средняя-высокая (маппинг зависимостей) | Средняя (клиент + шлюз) |
| Когда приоритет | Контроль доступа пользователей к приложениям | Изоляция рабочих нагрузок, ограничение радиуса поражения (blast radius) | Замена VPN, «тёмное облако» для чувствительных активов |
Комплементарная модель
На практике три подхода закрывают разные векторы атак:
- SDP/ZTNA контролирует north-south трафик — внешние пользователи, доступ к внутренним приложениям. Замена VPN.
- Микросегментация контролирует east-west трафик — коммуникации между рабочими нагрузками. Предотвращение латерального перемещения.
- EIG — идентификационный фундамент для обоих. IdP, MFA, OIDC-федерация, RBAC-политики.
Пример комбинации: сотрудник подключается к внутреннему приложению через Zscaler ZPA (SDP) → приложение обращается к базе данных через Cilium NetworkPolicy (микросегментация) → и VPN-доступ, и межсервисное взаимодействие авторизованы на основе идентичности из Okta (EIG).
Источник: ColorTokens: ZTNA + Microsegmentation
Что дальше
В Главе 4 мы переведём теорию в практику: как оценить текущую зрелость организации по CISA ZTMM, выбрать приоритетные инициативы и построить дорожную карту внедрения Zero Trust на 6-18 месяцев.
Ключевые выводы главы:
- NIST SP 800-207 определяет три модели размещения PEP: агент/шлюз, анклав и ресурсный портал — каждая подходит для своих сценариев
- EIG (BeyondCorp-подход) ставит идентичность в центр: Access Proxy + per-request авторизация + trust tiers устройств, без VPN
- Микросегментация контролирует east-west трафик: от VLAN → к identity-based изоляции на уровне рабочих нагрузок (Cilium, Calico, NSX-T, Illumio)
- SDP создаёт невидимую инфраструктуру через SPA: «authenticate first, connect second» (CSA SDP v2.0, Zscaler ZPA, Appgate)
- Три подхода комплементарны: EIG (идентификационный фундамент) + SDP (north-south) + микросегментация (east-west) = полное покрытие
- CISA Microsegmentation Guidance (июль 2025) формализует 4 фазы внедрения: Identify → Map → Determine → Deploy