Zero Trust полезен только тогда, когда перестает быть лозунгом и становится новой моделью доверия внутри системы.
Глава показывает, как explicit identity checks, policy enforcement, сегментация и поэтапная миграция переводят безопасность из слепой веры в сеть в проверяемые архитектурные решения.
Для design review это удобный способ обсуждать Zero Trust не как целевое состояние из презентации, а как последовательность шагов с UX friction, latency overhead и операционной ценой.
Практическая польза главы
Практика проектирования
Используйте материал по zero-trust подходе и проверке доверия на каждом уровне системы, чтобы формировать архитектурные security-требования до этапа реализации.
Качество решений
Проверяйте решения через модель угроз, security invariants и управляемость контролей в production, а не только через чеклист соответствия.
Interview articulation
Стройте ответ в формате threat -> control -> residual risk, показывая связь между бизнес-сценарием и техническими мерами защиты.
Trade-off framing
Явно описывайте компромиссы по zero-trust подходе и проверке доверия на каждом уровне системы: UX friction, latency overhead, стоимость сопровождения и требования compliance.
NIST
SP 800-207
Базовый референс по Zero Trust Architecture от NIST.
Zero Trust - это не «новый firewall» и не один продукт, а способ проектировать безопасность вокруг identity, контекста и постоянной проверки доступа. Главная идея: сеть сама по себе не является фактором доверия, поэтому каждый запрос должен проходить проверку по политике.
Принципы Zero Trust
Never Trust, Always Verify
Ни один запрос не считается безопасным по умолчанию: проверяйте identity, контекст и policy каждый раз.
Least Privilege
Права доступа должны быть минимальными и краткоживущими, с привязкой к конкретной задаче.
Assume Breach
Проектируйте систему так, будто злоумышленник уже внутри периметра: сегментация, наблюдаемость и быстрый revoke.
База
Identification -> AuthN -> AuthZ
Identity и authorization модель - фундамент для Zero Trust rollout.
Референс-архитектура
Identity Plane
- Workforce and workload identity (users, services, devices).
- IdP + lifecycle management + MFA/passkeys.
- Short-lived credentials вместо long-lived secrets.
Policy Plane
- Policy decision point: RBAC/ABAC/ReBAC или policy-as-code.
- Решение на основе subject + action + resource + context.
- Явный deny-by-default как базовый режим.
Enforcement Plane
- Policy enforcement points в gateway, mesh, приложениях.
- mTLS и service identity для east-west трафика.
- Полный audit trail для access decisions.
Telemetry Plane
- Continuous verification через логи, метрики и security signals.
- Risk-based access и динамические ограничения.
- Быстрый incident response и автоматизированный revoke.
Контекстные сигналы для policy decision
Identity assurance
Вопрос: Кто запрашивает доступ и насколько надежна аутентификация?
Реализация: MFA/passkeys, phishing-resistant login, device-bound credentials.
Device posture
Вопрос: Соответствует ли устройство базовым требованиям безопасности?
Реализация: EDR/MDM статус, patch level, disk encryption, root/jailbreak checks.
Workload identity
Вопрос: Как сервис подтверждает identity при service-to-service вызовах?
Реализация: Workload certificates, SPIFFE/SPIRE-подход, краткоживущие credentials.
Data sensitivity
Вопрос: Насколько критичен ресурс и требуется ли JIT-доступ?
Реализация: Классификация данных, purpose binding, read-only by default для risky-paths.
Behavioral context
Вопрос: Есть ли аномалия в географии, времени или паттерне запросов?
Реализация: Risk scoring, adaptive auth, step-up challenge и runtime throttling.
Матрица policy enforcement
| Плоскость | PEP | Проверки | Что делать при deny |
|---|---|---|---|
| Edge API (north-south) | API Gateway + WAF | AuthN/AuthZ, token claims, schema validation, rate limits. | Блокировка запроса, audit log и сигнал в SOC. |
| Service-to-service (east-west) | Service mesh / sidecar | mTLS identity, service policy, namespace segmentation. | Разрыв соединения и лог policy-decision с trace ID. |
| Data plane | DB proxy / data access layer | ABAC/ReBAC, row/column policy, time-bounded credentials. | Отклонение запроса и запуск review для high-risk access. |
| Admin operations | Privileged access gateway | JIT elevation, approvals chain, session recording. | Не выдавать elevation token и уведомить владельцев сервиса. |
| CI/CD и deploy | Policy-as-code + admission control | Подписанные артефакты, workload identity, env policy. | Остановить деплой и автоматически создать security-ticket. |
Операционные метрики Zero Trust
MFA/passkey coverage для privileged пользователей
Target: 100%
Без устойчивой аутентификации Zero Trust быстро деградирует до формальности.
Покрытие mTLS для east-west трафика
Target: >= 95%
Показывает, насколько межсервисные вызовы реально защищены, а не только edge.
Доля JIT/JEA для админских операций
Target: >= 90%
Снижает риск постоянного привилегированного доступа и lateral movement.
Mean revoke time для compromised identity
Target: < 15 минут
Чем быстрее revoke, тем меньше окно компрометации и blast radius.
Policy decision log coverage
Target: 100%
Без полного audit trail невозможно расследование и compliance-подтверждение.
Как внедрять поэтапно
1. Inventory
Соберите карту identities, сервисов, секретов, критичных путей и текущих trust assumptions.
2. Strong AuthN Baseline
Включите MFA/passkeys для пользователей и workload identity для сервисов; уберите shared credentials.
3. Policy Centralization
Вынесите правила доступа в единый policy layer и внедрите deny-by-default для новых ресурсов.
4. Segmentation + Enforcement
Разделите контуры (prod/non-prod, data tiers, admin paths) и добавьте PEP в ключевые точки трафика.
5. Continuous Validation
Настройте мониторинг access anomalies, периодический review прав и автоматическую ротацию credentials.
Антипаттерны
- Считать Zero Trust продуктом, а не архитектурным подходом и operating model.
- Ограничиться только VPN replacement без пересмотра identity и authorization модели.
- Делать 'allow all внутри кластера' и называть это zero trust.
- Не иметь процессов revoke/deprovision - даже при хорошей аутентификации.
- Оставлять админский доступ постоянным, без JIT/JEA и явного approvals flow.
Быстрый практический критерий: если после компрометации одного сервиса атакующий получает «почти все», значит Zero Trust внедрен только номинально.
References
Связанные главы
- Identification -> AuthN -> AuthZ - Фундамент Zero Trust: надежная идентификация субъекта и проверяемая модель доступа.
- Access Control Models: ACL, RBAC, ABAC, ReBAC - Определяет policy-механики, на которых строится policy decision point в Zero Trust.
- Secrets Management Patterns - Дополняет Zero Trust практикой краткоживущих credentials, ротации и контроля секретов.
- Service Mesh Architecture - Показывает техническую реализацию mTLS, service identity и policy enforcement для east-west трафика.
- API Security Patterns - Расширяет Zero Trust на север-юг периметр: token validation, abuse controls и secure API lifecycle.