ZeroTrustBook

Тема

Глава 21. Комплаенс и управление ​

«Комплаенс — это не цель, а побочный продукт хорошей архитектуры. Zero Trust, реализованный по NIST SP 800-207, автоматически закрывает десятки требований SOC 2, ISO 27001 и PCI DSS.»

Организации часто воспринимают комплаенс и безопасность как параллельные процессы: одна команда строит защиту, другая собирает доказательства для аудиторов. Zero Trust объединяет их: каждый контроль, описанный в предыдущих главах, одновременно является доказательством соответствия одному или нескольким стандартам.

21.1 Зачем: от ручных аудитов к непрерывному комплаенсу ​

Проблема традиционного подхода ​

Типичный цикл SOC 2 Type II:

ПериодЭтапПроблема
Месяц 1-3Сбор доказательств (скриншоты, таблицы, PDF)Ручной процесс
Месяц 4Аудит, замечания, исправленияРеактивный подход
Месяц 5Повторная проверка, отчётЗадержки
Месяц 6-11«Период наблюдения»Контроли деградируют
Месяц 12Паника, повторитьЦикл начинается заново

В Zero Trust-архитектуре каждое решение о доступе логируется и оценивается. Механизм политик (PE) из NIST SP 800-207 принимает решения на основе контекста — и сохраняет этот контекст. Это превращает комплаенс из дискретного процесса в непрерывный.

NIST CSF 2.0: функция Govern ​

NIST Cybersecurity Framework 2.0 (февраль 2024) добавил шестую функцию — Govern (GV) — к существующим Identify, Protect, Detect, Respond, Recover. Это единственная функция, которая пронизывает все остальные:

КатегорияПодкатегорииКлючевые области
GV.OC — Организационный контекст5Миссия, стейкхолдеры, требования
GV.RM — Управление рисками7Аппетит к риску, стратегия ответа
GV.RR — Роли и ответственность4Лидерство, ресурсы, кадры
GV.PO — Политики2Создание и актуализация политик
GV.OV — Надзор3Оценка стратегии, покрытия, эффективности
GV.SC — Цепочка поставок10SCRM, due diligence, контракты

Источник: NIST CSWP 29, Feb 26, 2024. Govern содержит 6 категорий и 31 подкатегорию.

Для Zero Trust-программ особенно важны:

  • GV.RM-06 — стандартизированный метод расчёта и категоризации рисков → формализованный risk register
  • GV.PO — жизненный цикл политик → Policy as Code (глава 19)
  • GV.SC — управление рисками цепочки поставок → supply chain security (глава 13, 15)

21.2 Маппинг Zero Trust → стандарты комплаенса ​

SOC 2 Type II ​

SOC 2 оценивает организацию по Trust Services Criteria (TSC) — 5 категорий, из которых Security (Common Criteria CC1-CC9) обязательна:

КатегорияОписаниеОбязательна?
SecurityCC1-CC9: контрольная среда, коммуникации, риски, мониторинг, доступ, операции, измененияДа
AvailabilityДоступность системНет
Processing IntegrityПолнота и корректность обработкиНет
ConfidentialityЗащита конфиденциальной информацииНет
PrivacyОбработка персональных данныхНет

Источник: AICPA 2017 Trust Services Criteria (with Revised Points of Focus, 2022). 9 серий Common Criteria (CC1-CC9).

Маппинг CC6 (Logical and Physical Access) → Zero Trust:

КритерийТребованиеКонтроль Zero TrustГлава
CC6.1Архитектура логического доступаPDP/PEP, IdP, OIDC3, 5
CC6.2Регистрация и авторизация пользователейIdentity lifecycle, MFA/FIDO25
CC6.3Управление привилегиями на основе ролейLeast privilege, ABAC, JIT6, 17
CC6.6Защита от внешних угрозМикросегментация, ZTNA10, 11
CC6.7Контроль передачи данныхmTLS, шифрование, DLP12, 16
CC6.8Защита от вредоносного ПОSupply chain security, EDR9, 13

Маппинг CC7 (System Operations) → Zero Trust:

КритерийТребованиеКонтроль Zero TrustГлава
CC7.1Обнаружение уязвимостейНепрерывная оценка состояния8, 9
CC7.2Мониторинг аномалийSIEM, XDR, поведенческая аналитика18
CC7.3Оценка инцидентовАвтоматическая оценка PDP19
CC7.4Реагирование на инцидентыSOAR, автоматическое сдерживание20

ISO 27001:2022 ​

ISO 27001:2022 (опубликован 25 октября 2022, переход до 31 октября 2025) содержит 93 контроля Annex A в 4 темах:

ТемаКонтролиКоличество
OrganizationalA.5.1 — A.5.3737
PeopleA.6.1 — A.6.88
PhysicalA.7.1 — A.7.1414
TechnologicalA.8.1 — A.8.3434

Источник: ISO/IEC 27001:2022, Annex A. 93 контроля (было 114 в версии 2013). 11 новых контролей добавлено.

Ключевые технологические контроли → Zero Trust:

КонтрольНазваниеКонтроль Zero TrustГлава
A.8.1User endpoint devicesDevice trust, MDM, TPM8
A.8.2Privileged access rightsPAM, Vault, JIT6
A.8.3Information access restrictionМинимальные привилегии, ABAC17
A.8.5Secure authenticationMFA, FIDO2, OIDC5
A.8.9Configuration management (новый)Infrastructure as Code, Policy as Code19
A.8.12Data leakage prevention (новый)DLP, классификация данных16
A.8.16Monitoring activities (новый)Непрерывный мониторинг, OTel18
A.8.20Networks securityZTNA, программно-определяемый периметр11
A.8.21Security of network servicesService mesh, mTLS12
A.8.22Segregation of networksМикросегментация10
A.8.24Use of cryptographymTLS, шифрование данных12, 16
A.8.25Secure development life cycleCI/CD security, SLSA15

PCI DSS 4.0.1 ​

PCI DSS v4.0 опубликован 31 марта 2022. v4.0.1 (уточняющее обновление) — 11 июня 2024. v3.2.1 отозван 31 марта 2024. Все future-dated требования (51 из 64 новых) обязательны с 31 марта 2025.

Источник: PCI SSC. v4.0.1 — уточняющее обновление, не добавляющее новых требований.

Ключевые требования → Zero Trust:

ТребованиеОбластьКонтроль Zero TrustГлава
Req 1Сетевые контролиМикросегментация, изоляция CDE10
Req 7Ограничение доступа по need-to-knowМинимальные привилегии, ABAC6, 17
Req 8Идентификация и аутентификацияMFA для всех, пароли ≥12 символов5
Req 10Логирование и мониторингSIEM, аудит, непрерывный мониторинг18
Req 11Тестирование безопасностиСканирование, пентесты9, 13

Требование 8.4.2 (MFA для всего доступа к CDE, не только удалённого) прямо совпадает с принципом Zero Trust: каждый запрос верифицируется, независимо от сетевого расположения.

GDPR ​

GDPR (General Data Protection Regulation) не предписывает конкретные технические контроли, но два ключевых артикля напрямую поддерживают Zero Trust:

Артикль 25 — Data Protection by Design and by Default:

  • Параграф 1: технические и организационные меры на этапе проектирования
  • Параграф 2: по умолчанию обрабатываются только необходимые данные

Артикль 32 — Security of Processing:

  • (a) Псевдонимизация и шифрование → mTLS, encryption at rest
  • (b) Конфиденциальность, целостность, доступность → полная архитектура Zero Trust
  • (c) Восстановление доступности → immutable infrastructure
  • (d) Регулярное тестирование мер → continuous compliance

Источник: EDPB Guidelines 4/2019 on Article 25 явно рекомендуют «zero trust approach to security» при реализации Data Protection by Design.

Сводная матрица ​

Контроль Zero TrustSOC 2 (CC6-7)ISO 27001PCI DSSGDPR (Art.25/32)
Идентичность (гл.5)CC6.1-2A.8.5Req 8Art.32b
PAM/JIT (гл.6)CC6.3A.8.2Req 7Art.25.2
Устройства (гл.8)CC6.4A.8.1—Art.32b
EDR (гл.9)CC6.8—Req 5—
Микросег (гл.10)CC6.6A.8.22Req 1Art.32b
ZTNA (гл.11)CC6.6A.8.20—Art.32b
mTLS (гл.12)CC6.7A.8.21Req 4Art.32a
Supply chain (гл.13)CC6.8A.8.25Req 6—
CI/CD (гл.15)CC8A.8.25——
Данные (гл.16-17)CC6.7A.8.12Req 3Art.25.2
Мониторинг (гл.18)CC7.2A.8.16Req 10Art.32d
Policy (гл.19)CC5A.8.9Req 12—
IR (гл.20)CC7.3-5—Req 12Art.32c

21.3 Как: непрерывный комплаенс ​

Архитектура непрерывного комплаенса ​

Три компонента:

  1. Evidence Collector — автоматический сбор доказательств из облачных API, логов, конфигураций
  2. Policy Evaluator — оценка соответствия через Policy as Code (глава 19)
  3. Drift Detector — обнаружение отклонений от базовой конфигурации

AWS Audit Manager ​

AWS Audit Manager предоставляет 29 предустановленных фреймворков, включая SOC 2 (SSAE-18), PCI DSS v4.0, ISO 27001:2013 Annex A, NIST 800-53 Rev 5, NIST CSF v1.1, FedRAMP, HIPAA, GDPR.

Источник: AWS Audit Manager User Guide, Supported Frameworks.

Четыре автоматических источника доказательств:

ИсточникТип доказательстваЧастота
CloudTrailАктивность пользователей (API-вызовы)Непрерывно
AWS ConfigСоответствие конфигурации ресурсовПо триггеру правила
Security HubРезультаты проверок безопасности (CSPM)По расписанию
API callsСнимки конфигурации ресурсовЕжедневно/еженедельно/ежемесячно

Пример: маппинг Zero Trust-контролей на SOC 2 CC6.1:

yaml
# AWS Audit Manager Custom Control
control_name: "ZT-CC6.1-Identity-Based-Access"
data_sources:
  - type: AWS_Config
    rule: iam-root-access-key-check          # Нет root-ключей
  - type: AWS_Config
    rule: mfa-enabled-for-iam-console-user   # MFA для всех
  - type: AWS_Security_Hub
    check: IAM.6                             # MFA для root
  - type: AWS_CloudTrail
    event: ConsoleLogin                      # Логи входа
  - type: AWS_Config
    rule: iam-policy-no-statements-with-admin-access  # Минимальные привилегии

Важно: Audit Manager собирает доказательства, но не оценивает комплаенс самостоятельно. Финальную оценку выполняет профессиональный аудитор.

Стоимость: $1.25 за 1 000 оценок ресурсов. Free tier: 35 000 оценок/месяц первые 2 месяца.

Microsoft Purview Compliance Manager ​

Microsoft Purview Compliance Manager предлагает 360+ шаблонов регуляторных оценок, включая SOC 2, ISO 27001:2022, PCI DSS v4.0, GDPR, NIST 800-53, FedRAMP, HIPAA, а также NIST SP 800-207 Zero Trust Architecture.

Источник: Microsoft Learn, Compliance Manager Regulations List.

Система скоринга — баллы по типам действий:

Тип действияБаллы
Preventative mandatory27
Preventative discretionary9
Detective mandatory3
Detective discretionary1
Corrective mandatory3
Corrective discretionary1

Технические действия (Technical improvement actions) тестируются автоматически через:

  • Microsoft Secure Score — проверка конфигурации M365/Azure
  • Defender for Cloud — оценка облачной безопасности

Обновление статуса — в течение 24 часов. Нетехнические действия (политики, процедуры) оцениваются вручную.

GCP Assured Workloads ​

GCP Assured Workloads обеспечивает соответствие на уровне папки (folder) через ограничения:

ПакетУровеньНаценка
FedRAMP ModerateРегуляторныйБесплатно
FedRAMP HighРегуляторный+20%
IL2 / IL4 / IL5Регуляторный+20%
CJISРегуляторный+20%
ITARРегуляторный+20%
US HealthcareРегуляторныйБесплатно
Региональные (EU, US, AU, ...)Data boundaryБесплатно / +5%

Источник: GCP Assured Workloads Control Packages. 11 регуляторных + 23+ региональных пакетов. Имена пакетов обновлены в июне 2025.

Механизм принуждения:

  • Резидентность данных — ресурсы ограничены определёнными регионами
  • CMEK — обязательное шифрование клиентскими ключами
  • VPC Service Controls — сетевая изоляция
  • Access Transparency — логирование доступа персонала Google
  • Personnel controls — проверки биографии, гражданства, локации

21.4 Инструменты сканирования ​

Prowler ​

Prowler — ведущий open-source инструмент для проверки облачной безопасности:

ХарактеристикаЗначение
Версия5.18.1 (февраль 2026)
Провайдеры13 (AWS, Azure, GCP, Kubernetes, GitHub, M365 и др.)
Проверки AWS585
Проверки Azure169
Проверки GCP100
Проверки Kubernetes84
Фреймворки40+ для AWS (CIS, NIST, PCI DSS, SOC 2, GDPR)

Источник: github.com/prowler-cloud/prowler. v5.0 представлен на AWS re:Invent 2024.

Пример проверки Zero Trust-контролей:

bash
# Проверка соответствия CIS AWS Benchmark
prowler aws --compliance cis_3.0_aws

# Проверка конкретных сервисов Zero Trust
prowler aws --service iam vpc kms cloudtrail \
  --output-formats json-ocsf \
  --output-directory ./evidence/

# Kubernetes: проверка RBAC и NetworkPolicy
prowler kubernetes --compliance cis_1.9_eks

Prowler v5 поддерживает вывод в формате OCSF (глава 18), что позволяет отправлять результаты в AWS Security Lake для единой аналитики.

ComplianceAsCode (OpenSCAP) ​

Для серверной инфраструктуры — OpenSCAP v1.4.3 с профилями ComplianceAsCode v0.1.79:

bash
# Проверка RHEL 9 по CIS Benchmark
oscap xccdf eval \
  --profile cis \
  --results results.xml \
  --report report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Генерация Ansible-плейбука для ремедиации
oscap xccdf generate fix \
  --fix-type ansible \
  --profile cis \
  --output remediation.yml \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Источник: github.com/OpenSCAP/openscap (v1.4.3, Nov 2024), github.com/ComplianceAsCode/content (v0.1.79, Nov 2024). Профили: CIS, DISA STIG, PCI-DSS, NIST 800-171.

21.5 Governance: реестр рисков и жизненный цикл политик ​

Реестр рисков Zero Trust-программы ​

NIST CSF 2.0 GV.RM-06 требует стандартизированный метод расчёта и категоризации рисков. Для Zero Trust-программы реестр включает:

yaml
# risk-register.yaml
risks:
  - id: ZT-RISK-001
    title: "Неполное покрытие микросегментацией"
    category: network
    cisa_pillar: Network
    current_maturity: Initial           # CISA ZTMM v2
    target_maturity: Advanced
    likelihood: High
    impact: High
    inherent_risk: Critical
    controls:
      - "Cilium NetworkPolicy для всех namespaces (гл.10)"
      - "Deny-all default policy (гл.14)"
    residual_risk: Medium
    owner: "Platform Security Team"
    review_date: "2026-Q2"

  - id: ZT-RISK-002
    title: "Сервисные аккаунты без ротации"
    category: identity
    cisa_pillar: Identity
    current_maturity: Traditional
    target_maturity: Advanced
    likelihood: High
    impact: Critical
    inherent_risk: Critical
    controls:
      - "SPIFFE/SPIRE для workload identity (гл.7)"
      - "Vault dynamic secrets (гл.6)"
    residual_risk: Low
    owner: "Identity Team"
    review_date: "2026-Q1"

  - id: ZT-RISK-003
    title: "Отсутствие классификации данных"
    category: data
    cisa_pillar: Data
    current_maturity: Traditional
    target_maturity: Initial
    likelihood: Medium
    impact: High
    inherent_risk: High
    controls:
      - "Microsoft Purview sensitivity labels (гл.16)"
      - "GCP Sensitive Data Protection (гл.16)"
    residual_risk: Medium
    owner: "Data Governance Team"
    review_date: "2026-Q1"

Каждый риск привязан к:

  • Столпу CISA ZTMM v2 — Identity, Devices, Networks, Applications, Data
  • Текущему и целевому уровню зрелости — Traditional → Initial → Advanced → Optimal
  • Конкретным контролям — со ссылками на главы книги
  • Владельцу и дате пересмотра

Жизненный цикл политик ​

GV.PO-01 и GV.PO-02 определяют: политики создаются, доводятся до исполнителей, применяются, пересматриваются при изменении требований.

В Zero Trust-архитектуре политики = код (глава 19):

21.6 Автоматизация сбора доказательств ​

Платформы непрерывного комплаенса ​

Для организаций, проходящих регулярные аудиты (SOC 2, ISO 27001), специализированные платформы автоматизируют сбор доказательств:

ПлатформаИнтеграцииФреймворкиМеханизм
Vanta400+SOC 2, ISO, PCI, HIPAA, GDPR1 200 тестов/час, реальное время
Drata270+SOC 2, ISO, PCI, HIPAA, NISTЕжедневный CCM
Secureframe300+20+ фреймворковНепрерывный мониторинг

Механизм работы:

  1. Интеграция — подключение к облачным провайдерам, IdP (Okta, Entra ID), MDM (Jamf, Intune), CI/CD (GitHub, GitLab), ITSM (Jira)
  2. Маппинг контролей — каждый контроль фреймворка связан с автоматическими тестами
  3. Непрерывный мониторинг — тесты выполняются по расписанию, результаты сохраняются как timestamped-доказательства
  4. Обнаружение дрифта — при нарушении контроля (S3-бакет стал публичным, пользователь потерял MFA) создаётся алерт
  5. Аудит — доказательства организованы по контролям, с метками времени, экспортируются для аудиторов

В контексте Zero Trust эти платформы проверяют:

  • MFA enforcement через IdP
  • Least privilege через анализ IAM-политик
  • Шифрование через проверку конфигураций облака
  • Сегментация через анализ VPC/security groups
  • Endpoint compliance через интеграцию с MDM

21.7 Lab: Prowler + маппинг на SOC 2 ​

Цель ​

Запустить Prowler для проверки AWS-аккаунта, отфильтровать результаты по SOC 2 CC6 (логический доступ) и сформировать отчёт для аудитора.

Предварительные условия ​

  • AWS CLI v2 с настроенным профилем
  • Python 3.9+ или Docker
  • Prowler 5.x

Шаг 1: Установка и запуск ​

bash
# Установка через pip
pip install prowler

# Или через Docker
docker pull toniblyx/prowler:latest

# Проверка SOC 2 CC6 (логический доступ)
prowler aws \
  --compliance soc2_aws \
  --output-formats csv json-ocsf html \
  --output-directory ./audit-evidence/soc2/ \
  --verbose

Шаг 2: Фильтрация по CC6 ​

bash
# Извлечь только CC6-контроли из результатов
cat ./audit-evidence/soc2/*.csv | \
  head -1 > cc6-controls.csv && \
cat ./audit-evidence/soc2/*.csv | \
  grep -i "CC6" >> cc6-controls.csv

# Подсчёт результатов
echo "=== SOC 2 CC6 Summary ==="
echo "PASS:  $(grep -c ",PASS,"  cc6-controls.csv)"
echo "FAIL:  $(grep -c ",FAIL,"  cc6-controls.csv)"
echo "TOTAL: $(wc -l < cc6-controls.csv)"

Шаг 3: Пример OPA-политики для валидации ​

Политика из главы 19 дополняется маппингом на SOC 2:

hcl
# policy/soc2-cc6.rego
package soc2.cc6

import rego.v1

# CC6.1: Identity-based access architecture
deny contains msg if {
    input.resource_type == "aws_iam_user"
    not input.mfa_enabled
    msg := sprintf(
        "CC6.1 FAIL: IAM user %s without MFA [SOC2-CC6.1]",
        [input.resource_id]
    )
}

# CC6.3: Least privilege
deny contains msg if {
    input.resource_type == "aws_iam_policy"
    input.policy_document.Statement[_].Effect == "Allow"
    input.policy_document.Statement[_].Action == "*"
    input.policy_document.Statement[_].Resource == "*"
    msg := sprintf(
        "CC6.3 FAIL: Policy %s grants admin access [SOC2-CC6.3]",
        [input.resource_id]
    )
}

# CC6.7: Encryption in transit
deny contains msg if {
    input.resource_type == "aws_lb_listener"
    input.protocol != "HTTPS"
    input.port == 443
    msg := sprintf(
        "CC6.7 FAIL: Listener %s uses %s instead of HTTPS [SOC2-CC6.7]",
        [input.resource_id, input.protocol]
    )
}

Шаг 4: Генерация отчёта ​

bash
# Создание отчёта для аудитора
cat <<'EOF' > audit-report-template.md
# SOC 2 Type II — Zero Trust Evidence Report

## Assessment Period
$(date -d '-90 days' +%Y-%m-%d) — $(date +%Y-%m-%d)

## Framework
AICPA Trust Services Criteria (2017, with 2022 Points of Focus)

## Scope
AWS Account: [ACCOUNT_ID]
Region: eu-west-1

## Evidence Sources
- Prowler v5.x automated scan (OCSF format)
- AWS CloudTrail logs (continuous)
- AWS Config rules (continuous)
- OPA/Rego policy evaluation (GitOps)

## CC6 — Logical and Physical Access Controls
- Total checks: [TOTAL]
- Passed: [PASS]
- Failed: [FAIL]
- Compliance rate: [RATE]%

## Detailed Findings
[CSV attachment: cc6-controls.csv]

## Remediation Plan
[For each FAIL — action item, owner, deadline]
EOF

Ожидаемый результат ​

После выполнения:

  • ./audit-evidence/soc2/ — полные результаты Prowler в CSV, JSON (OCSF), HTML
  • cc6-controls.csv — отфильтрованные CC6-контроли для аудитора
  • Каждая строка содержит: проверку, статус, описание, ресурс, маппинг на SOC 2 критерий

Резюме ​

СтандартZero Trust-покрытиеКлючевые контроли
SOC 2CC6 (доступ), CC7 (операции) → 13 из 13 критериевIdP, MFA, ABAC, микросегментация, мониторинг
ISO 2700114+ из 34 технологических контролейDevice trust, PAM, DLP, mTLS, SDLC
PCI DSSReq 1, 7, 8, 10, 11 → 5 из 12 требованийСегментация CDE, MFA, логирование
GDPRArt. 25, 32 → by design + securityШифрование, минимизация, мониторинг

Главный вывод: Zero Trust — не альтернатива комплаенсу, а его техническая реализация. Каждый контроль, описанный в главах 5-20, является доказательством соответствия одному или нескольким стандартам. Непрерывный комплаенс — это побочный эффект правильно реализованной Zero Trust-архитектуры.

Следующая глава переходит к продвинутым сценариям: мультиоблачная архитектура с федерацией SPIRE между AWS, GCP и Azure.

Опубликовано под лицензией CC BY-SA 4.0

© 2026 Владимир Радкевич