Zero Trust архитектура

Краткое резюме

Zero Trust (ZT) — это модель безопасности, в которой сетевой периметр больше не считается доверенной зоной. Каждый запрос (user→app, service→service, device→network) проходит явную аутентификацию, авторизацию и шифрование с учетом контекстных сигналов (идентичность, состояние устройства, местоположение, риск, поведение). Цель — минимизация blast radius, снижение риска lateral movement и упрощение комплаенса.

Базовые принципы Zero Trust

1. Явное доверие отсутствует: доверие не наследуется от сети/VPN/ASN.
2. Доступ минимально необходимый: политика «предоставить только то, что нужно сейчас».
3. Непрерывная верификация: сессии и токены регулярно переоценивать по риску и контексту.
4. Предположение компрометации: сегментация, наблюдаемость, быстрый containment и ротации ключей.
5. Шифрование везде: TLS 1.2+/1.3 и mTLS внутри дата-планes, защищенный DNS, секреты в KMS/HSM.

Целевой ландшафт и домены контроля

Идентичность: люди (IdP: SSO, MFA, passkeys/FIDO2), машины (SPIFFE/SVID, x509/mTLS).
Устройства: соответствие политикам (MDM/EDR, диск шифрован, патчи, jailbreak/root — запрещены).
Сеть: микросегментация L3/L7, ZTNA/SDP-шлюзы, сервис-меш (Envoy/Istio/Linkerd).
Приложения/API: mTLS, OIDC/JWT, подписи запросов (HMAC), rate limits, DLP/маскирование.
Данные: классификация (Public/Confidential/Restricted), токенизация/шифрование на уровне полей.
Наблюдаемость: централизованные логи аутентификации/авторизации, поведенческая аналитика, SLO/SLA.

Референс-архитектура (в разрезе плоскостей)

Control Plane: IdP/CIAM, PDP/PEP (OPA/Envoy), каталоги политик, PKI/CA, аттестация устройств.
Data Plane: прокси-доступа (ZTNA), sidecar-прокси (Envoy) для mTLS и политика L7, сервисные шлюзы/API GW.
Management Plane: каталог сервисов, CMDB, CI/CD, секрет-менеджмент (Vault/KMS), централизованный аудит.

1. Идентификация (SSO + phishing-resistant MFA) → 2) Оценка устройства (MDM posture) → 3) ZTNA-прокси устанавливает mTLS к приложению → 4) PDP (политики) принимает решение на основе атрибутов (ABAC/RBAC) → 5) непрерывная переоценка риска (время, гео, аномалии).

Идентичность и авторизация

IdP/SSO: OIDC/SAML, MFA по умолчанию, предпочтительно FIDO2 (passkeys).
RBAC/ABAC: роли + атрибуты контекста (статус устройства, отдел, риск-профиль).
Just-In-Time (JIT) доступ: временные привилегии с автоматическим отзывом; break-glass — строго регламентирован.
mTLS для машин: SPIFFE/SVID или внутренняя PKI с краткоживущими сертификатами; автоматический ротационный выпуск.

Устройства и контекст

Проверка соответствия (posture): версия OS/EDR, включенный диск-энкрипт, firewall; non-compliant → доступ к минимуму или блок.
Аттестация: device identity + signed attestations (MDM/Endpoint).
Сетевые ограничения: блок сторонних туннелей, принудительный корпоративный DNS, защита от DNS/WebRTC утечек.

Сеть и микросегментация

Отказ от «плоских» VLAN: вместо этого — сегменты/VRF и политика на L7.
Service Mesh: sidecar-прокси обеспечивают mTLS, авторизацию по политики (OPA/EnvoyFilter), телеметрию.
ZTNA/SDP: доступ к конкретному приложению, а не к сети; клиент↔брокер↔апп, политика в PDP.
Remote Access: замена «толстого» VPN на апп-прокси; fallback-туннели ограничены по маршрутам/портам.

Политики и движок решений

PDP/PEP: Policy Decision Point (OPA/Styra, Cedar и пр.) + Policy Enforcement Point (Envoy/Istio/Gateway).
Модель политики: декларативные правила (Rego/Cedar), статические и контекстные атрибуты, оценка риска.

rego package access. http

default allow = false

allow {
input. user. role == "support"
input. request. path == "/admin/tickets"
input. device. compliant == true time. now_hh >= 8 time. now_hh <= 20
}

Трассировка решений: логируйте `input`/`result`/`explain` для аудита.

Шифрование и доверие по умолчанию

TLS 1.2+/1.3 везде, строгие шифросюиты, HSTS, OCSP stapling.
mTLS внутри: сервис↔сервис только по взаимным сертификатам; ключи краткоживущие (часы/дни).
Секреты: KMS/HSM, dynamic secrets (Vault), короткие TTL, least-privilege для приложений.

Наблюдаемость, SLO и реагирование

• Успех аутентификации и авторизации (%), p95 времени принятия решения PDP, p95 TLS-handshake.
• Процент запросов, заблокированных политикой (аномалии/ложные).
• Доступность ZTNA брокеров и Mesh-контроллера.
• Доля compliant устройств и тренды.

• «Доступность ZTNA ≥ 99.95%/мес; p95 authZ decision ≤ 50 мс».
• «Доля запросов с mTLS ≥ 99.9%».
• «Не более 0.1% ложных отказов в доступе/сутки».

Алартинг: всплески deny, деградация p95 рукопожатия, невалидные цепочки, падение доли compliant устройств, аномалии географии/ASN.

Переход от периметра к Zero Trust: дорожная карта

1. Инвентаризация: приложения, потоки данных, потребители, чувствительность (PII/карточные/выплаты).
2. Идентичность и MFA: SSO и phishing-resistant MFA для всех.
3. Контекст устройств: MDM/EDR, базовые политики соответствия, блок non-compliant.
4. Микросегментация приоритетных путей: платежи, бэк-офис, админка; ввод mTLS.
5. ZTNA для пользовательского доступа: публикация приложений через прокси, убираем «широкий VPN».
6. Политики ABAC: централизованный PDP, декларативные правила, аудит.
7. Расширение на сервис-меш: S2S мTLS, политика L7, телеметрия.
8. Автоматизация и SLO: алертинг, тесты политик (политический CI), гейм-дни «что если IdP недоступен?».

Специфика для iGaming/финтех

Жесткая сегментация доменов: платежи/PII/антифрод/контент — отдельные периметры и политики; доступы только по ZTNA.
Взаимодействие с PSP/банками: allow-list по ASN/диапазонам, mTLS к PSP-эндпоинтам, мониторинг Time-to-Wallet и отказов на authZ.
Поставщики контента и партнеры: временные JIT-доступы к API, токены с короткими TTL, аудит интеграций.
Комплаенс: PCI DSS/GDPR — минимизация данных, DLP/псевдонимизация, журналирование доступов к чувствительным таблицам.

Безопасность цепочек поставки и CI/CD

Подписи артефактов (SLSA/Provenance): подписи контейнеров (cosign), политика Admission в K8s.
SBOM и уязвимости: генерация SBOM (CycloneDX), policy-gate в пайплайне.
Секреты в CI: OIDC-федерация к облачным KMS; запрет на статические ключи.
Ротации: частые, автоматические; принудительный revoke при инцидентах.

Типичные ошибки и анти-паттерны

«ZTNA = новый VPN»: публикация сети вместо приложений — не Zero Trust.
Нет проверки устройств: MFA есть, но зараженные/рутованные устройства получают доступ.
Единый супер-пользователь: отсутствие JIT и раздельных ролей.
Политики в коде сервисов: невозможность централизованного аудита/обновления.
mTLS частичный: часть сервисов без mTLS → «дырявый» контур.
Нулевой UX: избыточные запросы MFA, отсутствие SSO; итог — сопротивление командам.

Мини-гайд по выбору технологий

Доступ пользователей: ZTNA/SDP брокер + IdP (OIDC, FIDO2 MFA).
Внутрисервисная безопасность: сервис-меш (Istio/Linkerd) + OPA/Envoy authZ.
PKI: SPIFFE/SVID или Vault PKI с короткими TTL.
Политики: OPA/Rego или Cedar; хранить в Git, проверять в CI (policy-tests).
Логи и телеметрия: OpenTelemetry → централизованный анализ, детект аномалий.

Примеры конфигураций (фрагменты)

Envoy (мьютуал-TLS между сервисами)

yaml static_resources:
listeners:
- name: listener_https filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. network. http_connection_manager. v3. HttpConnectionManager route_config: { name: local_route, virtual_hosts: [] }
transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params: { tls_minimum_protocol_version: TLSv1_2 }
tls_certificates:
- certificate_chain: { filename: /certs/tls. crt }
private_key: { filename: /certs/tls. key }
validation_context:
trusted_ca: { filename: /certs/ca. crt }
require_signed_certificate: true

OPA/Rego: доступ к отчетам только из «finance», с compliant-устройств, в рабочие часы

rego package policy. reports

default allow = false

allow {
input. user. dept == "finance"
input. device. compliant == true input. resource == "reports/profit"
time. now_hh >= 8 time. now_hh <= 21
}

Чек-лист внедрения Zero Trust

1. Включить SSO и FIDO2 MFA для всех пользователей и админок.
2. Ввести device posture (MDM/EDR) с блокировкой non-compliant.
3. Перевести пользовательский доступ на ZTNA (per-app), оставить VPN лишь для узких S2S-каналов.
4. Внутри — mTLS по умолчанию + короткоживущие сертификаты.
5. Централизовать политики (PDP/OPA), хранить в Git, тестировать в CI.
6. Сегментировать чувствительные домены (платежи/PII/бэк-офис) и ограничить east-west.
7. Настроить телеметрию, SLO и алертинг на auth/authZ, mTLS-долю, posture-сигналы.
8. Провести «game days» (отказ IdP, утечка ключей, падение брокера) и зафиксировать SOP/откаты.

FAQ

Zero Trust заменяет VPN полностью?
Для пользовательского доступа — да, в пользу ZTNA. Для S2S-магистралей VPN/IPsec может остаться, но с mTLS поверх и строгими политиками.

Может ли ZT ухудшить UX?
Если бездумно. С SSO+FIDO2, адаптивной MFA и per-app доступом UX обычно улучшается.

Обязательно ли внедрять сервис-меш?
Не всегда. Но для крупной микросервисной среды mesh радикально упрощает mTLS/политику/телеметрию.

Итог

Zero Trust — это не продукт, а архитектурная дисциплина: идентичность как новый периметр, контекст устройств, приложенческий доступ (ZTNA), микросегментация и mTLS повсюду, централизованные политики и измеримая надежность. Следуя дорожной карте и чек-листу, вы уменьшите поверхность атаки, ускорите аудит и получите устойчивую безопасность без «доверия по умолчанию».