Глава 2. Фреймворки и стандарты
Zero Trust — не бренд и не продукт. Это набор принципов, формализованных в нескольких ключевых документах. В этой главе мы разберём три основных фреймворка: NIST SP 800-207, CISA Zero Trust Maturity Model v2, DoD Zero Trust Strategy — и покажем, как они связаны между собой.
NIST SP 800-207: архитектурный фундамент
NIST Special Publication 800-207, «Zero Trust Architecture» — фундаментальный документ, определяющий, что такое Zero Trust на архитектурном уровне. Опубликован 11 августа 2020 года. Авторы: Scott Rose, Oliver Borchert (NIST), Stu Mitchell (Stu2Labs), Sean Connelly (DHS/CISA).
Источник: NIST SP 800-207 | PDF | DOI: 10.6028/NIST.SP.800-207
Определения
Zero Trust (ZT) — evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.
Zero Trust Architecture (ZTA) — uses zero trust principles to plan industrial and enterprise infrastructure and workflows.
Ключевое допущение: ни одному субъекту не предоставляется неявное доверие на основании сетевой локации или принадлежности актива. Аутентификация и авторизация (субъекта и устройства) — отдельные функции, выполняемые до установления сессии.
7 тенетов Zero Trust (Section 2.1)
NIST определяет 7 базовых принципов, которым должна соответствовать архитектура нулевого доверия:
| # | Тенет | Суть |
|---|---|---|
| 1 | Все источники данных и сервисы считаются ресурсами | Сеть состоит из множества классов устройств. Персональные устройства тоже могут быть ресурсами, если имеют доступ к корпоративным данным |
| 2 | Вся коммуникация защищена независимо от сетевой локации | Сетевая локация сама по себе не означает доверия. Запрос из корпоративной сети должен соответствовать тем же требованиям безопасности, что и запрос извне |
| 3 | Доступ к ресурсам предоставляется per-session | Доверие к запрашивающему оценивается перед каждым предоставлением доступа. Доступ предоставляется с минимальными привилегиями |
| 4 | Доступ определяется динамической политикой | Политика учитывает идентичность клиента, состояние приложения/сервиса, запрашивающий актив, поведенческие и контекстные атрибуты |
| 5 | Предприятие мониторит целостность и состояние безопасности всех активов | Ни один актив не является доверенным по умолчанию. Применяется модель Continuous Diagnostics and Mitigation (CDM) |
| 6 | Аутентификация и авторизация динамические и строго применяемые | Постоянный цикл: получение доступа → оценка угроз → адаптация → переоценка доверия. Требуется ICAM и системы управления активами |
| 7 | Предприятие собирает максимум информации о текущем состоянии | Данные о состоянии активов, сетевом трафике и запросах доступа используются для улучшения политик |
Источник: NIST SP 800-207, Section 2.1
Логические компоненты: PE, PA, PEP
NIST определяет три ключевых компонента архитектуры:
┌─────────────────────────────────────────┐
│ Плоскость управления │
│ ┌──────────┐ ┌──────────────────┐ │
│ │ Механизм │ │ Администратор │ │
│ │ политик │◄──►│ политик │ │
│ │ (PE) │ │ (PA) │ │
│ └──────────┘ └────────┬─────────┘ │
│ │ │
├───────────────────────────┼─────────────┤
│ Плоскость данных │ │
│ ┌────────▼─────────┐ │
│ Субъект ──────►│ Точка применения │──► Ресурс
│ │ политик (PEP) │ │
│ └──────────────────┘ │
└─────────────────────────────────────────┘- Механизм политик (Policy Engine, PE) — принимает решение о предоставлении доступа. Использует входные данные: идентичность субъекта, состояние устройства, контекст запроса, threat intelligence, логи активности
- Администратор политик (Policy Administrator, PA) — исполняет решение PE: создаёт/закрывает сессию, конфигурирует PEP
- Точка применения политик (Policy Enforcement Point, PEP) — применяет решение: разрешает, запрещает или прерывает соединение между субъектом и ресурсом
Эта триада — архитектурный шаблон, который реализуется по-разному в зависимости от выбранного подхода. Например:
- В Kubernetes: PEP — это Envoy sidecar или Cilium, PE — OPA/Gatekeeper, PA — control plane service mesh
- В облаке: PEP — это IAP (GCP) или Verified Access (AWS), PE — условные политики IdP (Entra ID Conditional Access)
- В корпоративной сети: PEP — reverse proxy (Cloudflare Access), PE — IdP + MDM signals
3 архитектурных подхода (Section 3)
NIST описывает три стратегии развёртывания ZTA (на практике организации используют их комбинацию):
1. ZTA с усиленным управлением идентичностью (Enhanced Identity Governance, EIG)
Идентичность субъекта — главный компонент политики. Решение о доступе основано на атрибутах пользователя, дополненных состоянием устройства, актива и контекстом среды. Это подход, наиболее близкий к модели Google BeyondCorp.
2. ZTA с микросегментацией
Ресурсы размещаются в отдельных сетевых сегментах, защищённых шлюзами безопасности (next-gen firewall, интеллектуальные коммутаторы). Может дополняться host-based микросегментацией через агенты на конечных устройствах.
3. ZTA с сетевой инфраструктурой и программно-определяемым периметром (SDP)
Использует оверлейную сеть, где PA выступает контроллером и реконфигурирует сеть на основании решений PE. Клиенты обращаются через PEP, управляемый PA.
Подробный разбор этих подходов с примерами реализации — в Главе 3.
CISA Zero Trust Maturity Model v2.0
CISA ZTMM v2.0 — модель зрелости, опубликованная Cybersecurity and Infrastructure Security Agency в апреле 2023 года. Предназначена для оценки и планирования внедрения Zero Trust в федеральных агентствах, но применима к любой организации.
Источник: CISA ZTMM v2 PDF
5 столпов
CISA определяет 5 столпов (pillars), каждый из которых охватывает ключевую область безопасности:
| Столп | Описание | Ключевые функции |
|---|---|---|
| Идентичность (Identity) | Атрибуты, уникально описывающие пользователя или сущность | Аутентификация, хранилища идентичностей, оценка рисков, управление доступом |
| Устройства (Devices) | Аппаратные активы: серверы, рабочие станции, IoT, мобильные | Соответствие политикам, asset management, защита от угроз на устройствах |
| Сети (Networks) | Внутренние, беспроводные, интернет, облачные среды | Сетевая сегментация, управление трафиком, шифрование трафика, отказоустойчивость |
| Приложения и рабочие нагрузки (Applications & Workloads) | Системы, программы и сервисы, исполняемые on-prem и в облаке | Контроль доступа к приложениям, защита от угроз, доступность, безопасность приложений |
| Данные (Data) | Все структурированные и неструктурированные данные | Инвентаризация данных, классификация, доступность, шифрование |
3 сквозных возможности (Cross-Cutting Capabilities)
Каждый столп дополняется тремя сквозными возможностями, обеспечивающими интеграцию:
| Возможность | Описание |
|---|---|
| Видимость и аналитика (Visibility & Analytics) | Наблюдаемые артефакты из всей инфраструктуры, анализ данных для принятия решений по политикам, построение профилей рисков |
| Автоматизация и оркестрация (Automation & Orchestration) | Автоматизация задач безопасности и оркестрация ответов для снижения человеческих ошибок и улучшения времени реагирования |
| Управление (Governance) | Управление регуляторными, правовыми и операционными требованиями; применение политик кибербезопасности в поддержку risk-based решений |
4 уровня зрелости
CISA определяет 4 уровня, отражающих прогресс организации на пути к Zero Trust:
| Уровень | Характеристики |
|---|---|
| Traditional (Традиционный) | Ручные процессы жизненного цикла, статические политики, изолированные столпы, минимальная корреляция данных |
| Initial (Начальный) | Начало автоматизации, первые решения, охватывающие несколько столпов, агрегированная видимость внутренних систем |
| Advanced (Продвинутый) | Автоматизация контролей по всем жизненным циклам, централизованная видимость, предопределённые меры реагирования, осведомлённость на уровне предприятия |
| Optimal (Оптимальный) | Автоматизированные JIT-процессы жизненного цикла, динамические политики, динамические минимальные привилегии (JEA), интероперабельность между столпами, непрерывный мониторинг |
Важное отличие v2.0 от v1.0: добавлен уровень Initial между Traditional и Advanced, что признаёт реальность постепенного внедрения.
Пример: столп «Идентичность» по уровням
| Функция | Traditional | Initial | Advanced | Optimal |
|---|---|---|---|---|
| Аутентификация | Пароли, basic MFA | MFA + атрибуты сущности | Фишинго-устойчивая MFA (FIDO2, PIV) | Непрерывная валидация с фишинго-устойчивой MFA |
| Хранилища идентичностей | Изолированные хранилища | Комбинация хранилищ, минимальная интеграция (SSO) | Консолидация, частичная интеграция | Полная интеграция всех хранилищ, включая партнёров |
| Оценка рисков | Ручные проверки | Ручные методы + статические правила | Автоматический анализ + динамические правила | Анализ в реальном времени, непрерывный мониторинг |
| Управление доступом | Статические роли | Доступ с истечением срока + автоматический пересмотр | Need-based и session-based доступ | Автоматизированный JIT/JEA-доступ |
Источник: Microsoft CISA ZTMM Identity Guidance; CISA ZTMM v2 PDF
DoD Zero Trust Strategy
DoD Zero Trust Strategy — стратегия Министерства обороны США, опубликованная в ноябре 2022 года (датирована 21 октября 2022, рассекречена 7 ноября 2022). Разработана в ответ на Executive Order 14028, NDAA FY2022 и OMB M-22-09.
Источник: DoD ZT Strategy PDF
7 столпов DoD
В отличие от CISA (5 столпов + 3 сквозных возможности), DoD выделяет 7 равноправных столпов:
| # | Столп | Описание |
|---|---|---|
| 1 | Users (Пользователи) | Аутентификация и постоянная авторизация пользователей |
| 2 | Devices (Устройства) | Инвентаризация, оценка состояния, авторизация устройств |
| 3 | Applications & Workloads | Безопасность приложений, включая on-prem и облако |
| 4 | Data (Данные) | Классификация, маркировка, шифрование, контроль доступа к данным |
| 5 | Networks & Environments | Сегментация, шифрование, контроль сетевого трафика |
| 6 | Visibility & Analytics | Мониторинг, логирование, аналитика — как полноценный столп |
| 7 | Automation & Orchestration | Автоматизация процессов безопасности — как полноценный столп |
Ключевое различие: то, что CISA считает сквозными возможностями (Visibility & Analytics, Automation & Orchestration), DoD повышает до полноценных столпов, подчёркивая их равную важность.
Уровни и сроки
DoD определяет два уровня:
| Уровень | Количество активностей | Дедлайн |
|---|---|---|
| Target (целевой) | 91 активность | Конец FY2027 |
| Advanced (продвинутый) | 61 активность | Конец FY2032 |
Всего: 152 ZT-активности (45 ZT-возможностей) для полного достижения Advanced Level ZT.
Реализация: DISA Thunderdome
Одна из первых крупномасштабных реализаций — программа Thunderdome от DISA (Defense Information Systems Agency):
- Март 2023: завершён прототип после 12 месяцев разработки. ~1 500 тестовых пользователей на 3 площадках. Подтверждено улучшение сетевой производительности и безопасности при использовании SASE и SDP
- 2023-2024: развёрнуто на 15, затем 60 площадках. Контракт с Booz Allen Hamilton на ~$1,86 млрд
- Апрель 2025: по заявлению директора ZT PfMO Randy Resnick на конференции AFCEA, Thunderdome достиг 152 из 152 ZT-активностей (Advanced level). При этом отчёт DoD Inspector General (DODIG-2025-090, 1 мая 2025) зафиксировал 85 из 91 Target-активностей по состоянию на январь 2025 для DoD в целом — разрыв объясняется различием между достижениями отдельной программы (Thunderdome) и всего DoD
Источники: DefenseScoop: Thunderdome Advanced ZT; DoD IG Report DODIG-2025-090
Организационная структура
17 июля 2025 года DTM 25-003 формализовал Zero Trust Portfolio Management Office (ZT PfMO) и должность Chief Zero Trust Officer в рамках DoD CIO. Директор ZT PfMO — Randy Resnick (бывший NSA, 34+ лет в кибербезопасности).
Источник: DTM 25-003
Сравнительная таблица: NIST vs CISA vs DoD
| Аспект | NIST SP 800-207 | CISA ZTMM v2.0 | DoD ZT Strategy |
|---|---|---|---|
| Тип документа | Архитектурное руководство | Модель зрелости | Стратегия + план реализации |
| Дата публикации | Август 2020 | Апрель 2023 | Ноябрь 2022 |
| Аудитория | Любая организация | Федеральные агентства (гражданские) | Министерство обороны |
| Структура | 7 тенетов + 3 подхода | 5 столпов + 3 сквозных + 4 уровня | 7 столпов + 2 уровня |
| Столпы/компоненты | PE, PA, PEP (логические) | Identity, Devices, Networks, Apps, Data | Users, Devices, Apps, Data, Networks, V&A, A&O |
| Уровни зрелости | Не определены | Traditional → Initial → Advanced → Optimal | Target (FY2027) → Advanced (FY2032) |
| Активности/метрики | Не определены | Функции по столпам | 152 активности (91 + 61) |
| Практические примеры | Мало (концептуальный) | Функции по столпам | DISA Thunderdome, Navy Flank Speed |
| Связь с EO 14028 | Предшествует EO | Разработана для EO | Разработана для EO + NDAA |
Как документы связаны
NIST SP 800-207 — архитектурный фундамент, на который ссылаются все остальные документы. EO 14028 превратил рекомендации в обязательства. OMB M-22-09 конкретизировал требования для гражданских агентств (дедлайн — конец FY2024). DoD разработал собственную стратегию с более детальными метриками (152 активности) и сроками (FY2027/FY2032). CISA ZTMM v2 предоставил модель для оценки прогресса.
Lab: Self-Assessment по CISA ZTMM
Используйте таблицу ниже для базовой оценки зрелости вашей организации. Для каждой функции определите текущий уровень (T/I/A/O):
Чеклист оценки зрелости
Столп 1: Идентичность
| # | Вопрос | T | I | A | O |
|---|---|---|---|---|---|
| 1.1 | Как аутентифицируются пользователи? | Пароли | MFA (TOTP, push) | Фишинго-устойчивая MFA (FIDO2) | Непрерывная валидация |
| 1.2 | Сколько хранилищ идентичностей? | Изолированные (AD, LDAP, локальные) | Частичная консолидация + SSO | Единый IdP для большинства систем | Полная интеграция, включая партнёров |
| 1.3 | Как оценивается риск при аутентификации? | Вручную | Статические правила | Автоматический анализ + динамические правила | Real-time анализ, поведенческая аналитика |
| 1.4 | Как управляется привилегированный доступ? | Статические роли, без пересмотра | Доступ с истечением + автоматический review | Session-based, need-based | JIT/JEA, полностью автоматизированный |
Столп 2: Устройства
| # | Вопрос | T | I | A | O |
|---|---|---|---|---|---|
| 2.1 | Есть ли полная инвентаризация устройств? | Частичная, ручная | Есть инвентаризация, обновляется периодически | Автоматизированная инвентаризация | Real-time инвентаризация всех активов |
| 2.2 | Оценивается ли состояние устройств при доступе? | Нет | Базовая проверка (OS version) | Compliance check (encryption, AV) | Непрерывная оценка состояния |
Столп 3: Сети
| # | Вопрос | T | I | A | O |
|---|---|---|---|---|---|
| 3.1 | Как сегментирована сеть? | Flat network или macro-сегментация | Начальная сегментация (VLAN) | Микросегментация по приложениям | Динамическая микросегментация на основе идентичности |
| 3.2 | Шифрование внутреннего трафика? | Нет | Частичное (TLS для критичных сервисов) | mTLS для большинства | mTLS повсеместно, включая east-west |
Столп 4: Приложения и рабочие нагрузки
| # | Вопрос | T | I | A | O |
|---|---|---|---|---|---|
| 4.1 | Как контролируется доступ к приложениям? | Сетевой доступ (VPN → приложение) | Начальная интеграция с IdP | Identity-aware доступ к каждому приложению | Непрерывная авторизация, контекстные политики |
| 4.2 | Как управляется безопасность supply chain? | Нет управления | Базовый SBOM | Signed images, admission control | SLSA Level 3+, полный provenance |
Столп 5: Данные
| # | Вопрос | T | I | A | O |
|---|---|---|---|---|---|
| 5.1 | Классифицированы ли данные? | Нет | Частичная классификация (manual) | Автоматическая классификация | Динамическая классификация + DLP |
| 5.2 | Как защищены данные at rest и in transit? | Частичное шифрование | TLS in transit, encryption at rest для критичных | Полное шифрование at rest + in transit | + Confidential computing (data in use) |
Как использовать результаты
- Подсчитайте, сколько ответов в каждом столбце (T/I/A/O)
- Столп с наибольшим количеством «T» — приоритет для улучшения
- Постройте radar chart (паутинную диаграмму) по 5 столпам
- Используйте результаты как входные данные для дорожной карты в Главе 4
Важно: это упрощённая версия assessment. Полный чеклист CISA для каждого столпа с детализацией по функциям — в Приложении C.
Что дальше
В Главе 3 мы рассмотрим архитектурные паттерны подробнее: Enhanced Identity Governance, микросегментацию и SDP — с конкретными примерами реализации (BeyondCorp, AWS, GCP, Azure). Вы поймёте, когда какой подход применять.
Ключевые выводы главы:
- NIST SP 800-207 (2020) — архитектурный фундамент Zero Trust: 7 тенетов, 3 подхода, триада PE/PA/PEP
- CISA ZTMM v2 (2023) — практическая модель зрелости: 5 столпов, 4 уровня (Traditional → Optimal), 3 сквозных возможности
- DoD ZT Strategy (2022) — 7 столпов (V&A и A&O как полноценные столпы), 152 активности, цель — FY2027 (Target), FY2032 (Advanced)
- Все три документа связаны через EO 14028 (2021) и OMB M-22-09 (2022)
- DISA Thunderdome заявил о достижении 152/152 ZT-активностей к апрелю 2025 (при этом DoD в целом — 85/91 Target на январь 2025)
- Используйте CISA ZTMM self-assessment как отправную точку для оценки зрелости