Zero Trust Architecture
«Никогда не доверяй, всегда проверяй». Современный подход к безопасности, заменяющий старую модель «крепости с рвом» (perimeter security).
Откуда это пришло
2009: Google внутри запустил инициативу BeyondCorp после китайской атаки Operation Aurora. Идея: «корпоративная сеть не безопаснее интернета». Каждый запрос проверяется заново на каждом ресурсе.
2020: NIST оформил это в стандарт SP 800-207. Сейчас — стандарт de facto в облаке.
Старая модель vs Zero Trust
| Perimeter (старое) | Zero Trust | |
|---|---|---|
| Допущение | Внутри сети — доверяю | Никому не доверяю по умолчанию |
| Защита | VPN на входе, firewall | Identity + контекст на каждый запрос |
| Доступ | «Ты в офисе» → можно | «Кто ты + откуда + с какого устройства + что хочешь» |
| Lateral movement | Лёгкое | Заблокировано |
| VPN | Обязателен | Заменён на ZTNA |
Семь принципов NIST 800-207
- Все источники данных и сервисы — это resources
- Все коммуникации защищены независимо от расположения сети
- Доступ к ресурсам выдаётся на per-session основе
- Доступ определяется динамической политикой: identity + device + behavior + контекст
- Мониторинг integrity всех активов
- Аутентификация и авторизация — динамические и строгие, перед каждым доступом
- Сбор телеметрии для улучшения политик безопасности
Что это значит на практике
1. Идентичность вместо IP
Не «10.0.5.42 имеет доступ к БД». А «сервис orders-api с сертификатом X имеет доступ к таблице orders на чтение».
- SPIFFE / SPIRE — стандарт workload identity
- mTLS между всеми сервисами (Service Mesh)
- OIDC для людей и CI/CD
- IAM roles вместо access keys
2. ZTNA вместо VPN
Вместо «VPN → доступ ко всей внутренней сети» — точечный доступ к конкретным приложениям.
- Tailscale — WireGuard mesh с identity
- Cloudflare Access / Zero Trust
- Zscaler Private Access
- Google IAP (Identity-Aware Proxy)
3. Microsegmentation
В Kubernetes — NetworkPolicy default deny, потом явные allow. Каждый pod общается только с теми, с кем нужно.
# Запретить всё входящее по умолчанию в namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes: [Ingress]4. Continuous verification
Не «один раз залогинился — на 8 часов твой». А «каждый запрос проверяется». Сессии короткие, токены rotated.
- JWT с коротким TTL (15 минут)
- Refresh tokens с проверкой device fingerprint
- Re-authentication для чувствительных операций
5. Минимальные привилегии
Сервис получает токен с минимальным scope для конкретной операции. Не root role «делай что хочешь».
Внедрение в облаке
AWS
- IAM Identity Center + временные credentials
- SCPs на уровне Organizations
- IAM Roles Anywhere — для on-prem нагрузок
- Verified Access — managed ZTNA для приложений
- GuardDuty + Security Hub для detection
Kubernetes
- Service Mesh (Istio/Linkerd) с mTLS
- AuthorizationPolicy для service-to-service
- NetworkPolicy default deny
- OIDC к API server вместо kubeconfig
- External Secrets Operator + Vault
Разработка
- GitHub Actions OIDC к AWS — никаких access keys
- Cosign keyless signing через OIDC identity
- Signed commits
Типичные ошибки внедрения
- ❌ Купить «Zero Trust продукт» и думать что готово
- ❌ Применить ZT только на периметре, оставив plain HTTP внутри
- ❌ Сложные policies → разработчики обходят
- ❌ Нет observability → не видишь что блокирует
- ❌ Внедрять разом, а не итеративно
Внедряй ZT итеративно: сначала один критичный сервис, потом расширяй. Параллельно — observability (Falco, audit logs, SIEM), иначе ничего не увидишь.
Ресурсы
- NIST SP 800-207
- Google BeyondCorp papers
- SPIFFE / SPIRE
- Книга: «Zero Trust Networks» — Evan Gilman, Doug Barth