Zero Trust Architecture concept page. "Never trust, always verify." BeyondCorp-style identity-aware proxy with device posture + MFA, microsegmentation via service mesh (sidecar PEP + SPIFFE mTLS), and contrast vs legacy VPN castle-and-moat. 3 scenarios: BeyondCorp access flow, microsegment allow/deny, Colonial Pipeline–style breach blocked by ZT. ADR on adoption strategy (BeyondCorp vs Cloudflare Access vs Tailscale vs Zscaler).
KEKey · @kuzminykh_igor_b3550a9b
0 stars
0 views
94d ago · last update
zero-trust.js·3 scenarios
Loading canvas…
Зачем
Старая модель безопасности — castle-and-moat: жирный firewall на периметре, всё внутри — trusted. Эта модель работала ровно до тех пор, пока существовал чёткий «внутри». В 2026 «внутри» больше нет: сотрудники из дома, SaaS вне периметра (Salesforce, Slack, GitHub), workloads в трёх облаках, контракторы с личных ноутбуков, supply-chain атаки приводят атакующего сразу за периметр. Один pivot point внутри trusted-сети = весь blast radius.
Каскад инцидентов это подтвердил болью:
Target 2013 — HVAC-vendor имел network access к POS-системам, 40M карт.
Sony Pictures 2014 — атакующий 100+ дней внутри сети, терабайты утекли.
NotPetya 2017 — worm через Windows SMB, $10B ущерба за часы.
Capital One 2019 — SSRF + over-permissive IAM, 106M записей.
SolarWinds 2020 — backdoored agent ушёл через trusted egress в C2.
Colonial Pipeline 2021 — VPN со старым паролем без MFA, $4.4M ransom, 6 дней простоя.
Общий паттерн один: один pivot внутри trusted-сети — и blast radius неконтролируем. Zero Trust ломает trust zones: каждый запрос verify + encrypt + authorize вне зависимости от network location. Forrester (John Kindervag) ввёл термин в 2010, Google публично описал BeyondCorp в 2014 (после Aurora 2009), NIST SP 800-207 формализовал в 2020, OMB M-22-09 обязал US federal agencies мигрировать к 2024.
Без понимания Zero Trust невозможно дизайнить современную инфраструктуру: ::concept{slug="mtls"} для workload identity, ::concept{slug="oauth-oidc"} и ::concept{slug="authn-models"} для user identity, ::concept{slug="authz-models"} для policy decisions, ::concept{slug="service-mesh-deep"} для microsegmentation, ::concept{slug="secrets-management"} для short-lived credentials — всё это кусочки одной Zero Trust картины.
Mental model
Старое: «firewall защищает trusted внутреннее от hostile внешнего». Новое: «firewall больше нет, каждый запрос — будто из интернета». Authenticate + authorize + encrypt каждое соединение, каждый раз, для пользователей и workload-ов.
Семь принципов NIST SP 800-207 в двух предложениях:
Никаких trusted zones — every resource, every request, every user, every workload — verify.
Решение per-request, не per-session — context (user + device posture + location + time + risk) считается на каждый запрос, не «вошёл утром — гуляй до вечера».
Три ключевых компонента — ездить ими в голове всё время:
PEP (Policy Enforcement Point) — точка, где запрос блокируется или пропускается. Identity-aware proxy для users (Cloudflare Access, IAP, Zscaler ZPA), sidecar Envoy/Linkerd для workload-ов.
PDP (Policy Decision Point) — мозг: «разрешено ли user X с device Y делать action Z на resource W?». Обычно OPA или AuthZ-сервис.
Zero Trust — не продукт, который покупается. Это архитектурная трансформация, обычно 12-36 месяцев, поэтапно (один application за раз, никаких big-bang).
Что на диаграмме
Канвас визуализирует новую модель и legacy-антипаттерн рядом, чтобы контраст был осязаемым:
Identity + posture (PDP inputs) — IdP (Okta/Azure AD), WebAuthn/hardware key, EDR (CrowdStrike), MDM (Jamf/Kandji). Это входы для policy decision.
ZTNA control plane (PEP + PDP) — access-proxy (identity-aware proxy), pdp (OPA), audit (per-request log). На access-proxy навешан ADR-001 с разбором, какой Zero Trust продукт выбрать в зависимости от размера и стека (Tailscale vs Cloudflare vs BeyondCorp vs Zscaler/Prisma).
Internal apps — wiki, Jira, admin console. Без public IP, доступны только через PEP.
Service mesh — microsegmentation — три pod-а (svc-a, svc-b, svc-c), каждый с Envoy sidecar. SPIRE раздаёт workload identity (SPIFFE), Vault — short-lived DB credentials. Policy: svc-a → svc-b разрешено, svc-c → svc-b запрещено.
Legacy VPN (castle-and-moat) — VPN-gateway → flat network 10.0.0.0/8 → unrestricted доступ ко всему. Это антипаттерн на канвасе, чтобы видеть, как pivot уничтожает периметр.
Edges — это физические соединения. Ответы (response) идут reverse-anim по тем же edges, новые edges для ответов не нужны (важно: identity-aware proxy — это прокси, всё ходит через него).
Сценарии
BeyondCorp-style access — full per-request check. Сотрудник из дома (без VPN) открывает internal wiki. Identity-aware proxy последовательно: проверяет OIDC-session в IdP, валидность WebAuthn-assertion, спрашивает MDM «managed/encrypted/patched?», спрашивает EDR «есть ли активные detections?», шлёт собранный context в PDP («user alice, group eng, device managed, posture clean, action read on wiki — allow?»), логирует решение в audit, и только тогда форвардит запрос с identity-headers к wiki. Каждый следующий запрос пройдёт ту же проверку (кэшированные результаты делают её дешёвой). Это и есть «никаких trusted zones, continuous re-eval».
Microsegmentation в service mesh. svc-a хочет вызвать svc-b. Sidecar-a забирает SPIFFE SVID из SPIRE (X.509 cert с TTL 1h, auto-rotated), делает mTLS-handshake к sidecar-b — обе стороны верифицируют криптографическую identity. sidecar-b шлёт authz-запрос в PDP («разрешено ли spiffe://.../svc-a → svc-b на /api/order?») — allow, forward к svc-b. svc-b забирает из Vault короткоживущий DB-пароль (TTL 1h) и работает. Параллельно показан negative case: svc-c (compromised or misconfigured) пытается вызвать svc-b — handshake проходит (у svc-c валидный SPIFFE ID), но PDP отвечает deny (svc-c не в allowlist для svc-b), 403 возвращается на sidecar-c, request не доходит до svc-b. Blast radius compromised pod-а contained.
Colonial Pipeline replay — VPN vs Zero Trust. Атакующий с украденным паролем контрактора без MFA. Через legacy VPN-gateway получает IP 10.0.5.42, full network access, curl на wiki работает, curl на admin-console работает, можно создать backdoor user — это и есть Colonial Pipeline 2021 ($4.4M ransom, 6 days down). Тот же атакующий через identity-aware proxy блокирован на трёх уровнях: (1) IdP требует fresh WebAuthn-assertion — у атакующего нет физического hardware-ключа; (2) MDM-check — устройство не enrolled в Jamf; (3) PDP получает context {mfa:fail, device:unmanaged} — deny. Не дошёл даже до wiki. Завершается happy-path для легитимного user-а: alice открывает sensitive admin-console — policy требует step-up MFA (re-prompt WebAuthn touch), каждое action атрибутировано в audit.
Trade-offs (ADR)
ADR-001: Zero Trust adoption — с чего начать, какой продукт выбрать (Tailscale vs Cloudflare vs BeyondCorp vs Zscaler)
Context. Zero Trust — многолетняя архитектурная трансформация, не покупка продукта. Forrester ввёл термин в 2010, NIST SP 800-207 формализовал в 2020, OMB M-22-09 обязал федералов мигрировать к 2024. Реальный driver — каскад инцидентов: Target 2013 (HVAC-vendor → POS), Sony 2014 (insider 100+ дней), NotPetya 2017 ($10B), SolarWinds 2020, Colonial Pipeline 2021 ($4.4M ransom через VPN с старым паролем без MFA), Uber 2022 (MFA fatigue → corp VPN). На рынке четыре основных стартовых пути: BeyondCorp Enterprise (Google IAP + Chrome, $6-20/user/мес, lock-in в Google), Cloudflare Zero Trust (Access + Tunnel + WARP, $3-7/user/мес, vendor-neutral, быстрый rollout), Tailscale/Twingate (WireGuard mesh + identity, $5-18/user/мес, минимум инфры), Zscaler ZPA / Palo Alto Prisma Access (полный SASE, $15-50/user/мес, годы внедрения, dedicated team).
Decision. Выбор зависит от размера и стека:
Pre-PMF / startup до 50 человек: Tailscale + Okta + WebAuthn hardware keys = базовый ZT за неделю, ~$1K/мес. Не покупать VPN.
Growth 50-500, разнородный стек: Cloudflare Zero Trust (Access + Tunnel + WARP) — заменяет VPN за 2-4 недели, identity-aware proxy перед internal apps, $3-7K/мес. Параллельно — service mesh (Linkerd проще Istio) с mTLS, новые сервисы onboard в mesh, legacy мигрирует за 6-12 месяцев.
Google shop: BeyondCorp Enterprise + IAP — бесшовно, если уже на Workspace.
Обязательно во всех кейсах с day 1: (1) device posture (managed + encrypted + EDR); (2) WebAuthn/hardware keys для админов (SMS/TOTP недостаточно — Uber 2022); (3) microsegmentation в k8s (NetworkPolicy + Cilium); (4) короткоживущие credentials (Vault dynamic, AWS STS, GCP impersonation); (5) audit log на каждый PEP decision. Migrate priority: SSH/RDP → internal web apps → service-to-service → egress filtering.
Trade-off.
Плюсы поэтапной миграции: низкий риск (один app сломал — откатил), value early (первые SSH/RDP под ZTNA уже дают защиту), команда учится по дороге.
Минусы: долго (12-36 месяцев), временно живёшь в гибриде (часть apps под ZTNA, часть — под VPN), нужен дисциплинированный roadmap.
Плюсы big-bang: все на одной модели сразу — нет «забытых» путей.
Минусы big-bang:не работает, никогда. Не пробовать.
ADR-002: Identity-aware proxy vs VPN
Context. Базовый выбор: оставить VPN (с MFA, лучше) или заменить на identity-aware proxy. VPN даёт network-level access (попал внутрь — гуляй по 10.0.0.0/8). Identity-aware proxy даёт application-level access (видишь только конкретные apps, разрешённые твоей policy).
Decision. Identity-aware proxy для всего user-facing. VPN — legacy.
Trade-off.
Плюсы proxy: per-request policy decision; нет flat network внутри; легко добавить step-up MFA на sensitive apps; работает с любым internet endpoint без client install (Cloudflare Access — просто браузер с SSO); audit per-request, не per-session.
Минусы proxy: требует, чтобы все apps были HTTP/HTTPS (или TCP tunnel для SSH/RDP); legacy thick-client apps мигрируются болезненно; vendor lock-in (proxy в критическом пути всего трафика); proxy сам — high-value target.
Плюсы VPN с MFA: работает с любым TCP/UDP без modification приложений; знаком сотрудникам; дешёвый OpenVPN/WireGuard self-hosted.
Минусы VPN: network-level trust (попал внутрь — full network access); pивот после compromised credential = катастрофа (Colonial Pipeline); невозможно сделать per-app policy без segmenting сети до бесконечности; MFA fatigue (Uber 2022).
Когда VPN остаётся OK: SSH к bastion для опс-команды (с hardware keys + short-lived certs через Vault SSH или Teleport), legacy thick-client apps до миграции, временные contractor scenarios. Везде остальное — proxy.
ADR-003: Workload identity (SPIFFE) vs network-based (IP allowlist)
Context. Service-to-service authz можно делать по network (NetworkPolicy в k8s, security groups в AWS — «pod с label X может звонить pod с label Y») или по cryptographic identity (SPIFFE SVID — X.509 cert у каждого workload, mTLS handshake верифицирует кто-кто).
Decision. SPIFFE + mTLS для всех новых сервисов в mesh. NetworkPolicy/security groups — defense in depth поверх, не вместо.
Trade-off.
Плюсы SPIFFE: identity не зависит от IP (pod рестартанул, IP сменился — identity та же); cryptographic, не bypassable через ARP spoofing/IP spoofing; работает cross-cluster, cross-cloud; auto-rotation (TTL 1h типично).
Минусы SPIFFE: требует SPIRE или managed (Istio с Citadel) — operational overhead; legacy apps без TLS-support не подключатся; cert distribution — failure mode, который нужно мониторить; сложнее debug (TLS-ошибки vs network-reach-ошибки).
Плюсы IP/network-based: работает с любым stack; легко понять (firewall rules); zero app changes.
Минусы IP/network-based: IP не identity (compromised pod с тем же label — выглядит как легитимный); cross-cluster — NAT-ад; pod-IP-churn в k8s; не работает в serverless (Lambda IP — random).
Hybrid в реале: SPIFFE для service-to-service authz, NetworkPolicy/security groups как defense-in-depth (если sidecar упал и не enforced — network ещё ловит).
ADR-004: Continuous re-evaluation vs session caching
Context. Принцип «per-request decision» дорогой: на каждый HTTP-request гонять полный chain (IdP + MDM + EDR + PDP) даст +50-200ms latency и нагрузку на identity providers, которая их положит.
Decision. Cache decision components с короткими TTL: IdP-session 1-8h, device posture 5-15 min, PDP decision 30-60s, EDR alert-stream — push-based (revoke on alert). Re-evaluate полностью при step-up triggers: sensitive resource access, anomaly detection, time threshold.
Trade-off.
Плюсы caching: latency приемлем (proxy добавляет <10ms на cache hit); identity providers не лежат; cost разумен.
Минусы caching: revocation lag — если IdP отозвал session, proxy может ещё несколько минут пропускать (mitigated через push-based revocation channel + short cache TTL). Если EDR detected malware на device, нужно немедленно прекратить access — нужен event-driven revoke pipeline, не «дождёмся cache expiry».
Плюсы no caching: мгновенная revocation, всегда fresh state.
Минусы no caching: latency 200ms+ на request, IdP падает под нагрузкой, dev experience страдает.
Хорошие defaults: TTL коротко, push-based revoke channel для critical events (EDR alert, IdP revoke, MDM unenroll), step-up auth для всего sensitive.
Реальные системы
Google BeyondCorp — pioneer (2014, после Aurora 2009). No VPN, all corporate access через IAP. Device inventory + cert + posture (patches, encryption). 6+ опубликованных papers (2014-2018) — обязательное чтение.
Cloudflare Zero Trust — Access (identity-aware proxy) + Tunnel (reverse tunnel к internal apps без public IP) + WARP (device agent с posture) + Gateway (SWG). $3-7/user/мес. Доминирующий выбор для mid-market.
Zscaler ZPA — enterprise ZTNA, частый выбор для Fortune 500. Полный SASE-stack (ZPA + ZIA + ZDX).
Tailscale / Twingate — WireGuard mesh + identity. Идеально для startup/dev teams 10-200 человек.
Okta Identity Engine + Device Trust — IAM-фундамент для большинства ZT-implementations.
HashiCorp Vault — dynamic secrets (DB credentials с TTL 1h), AWS/GCP IAM dynamic credentials, SSH CA для short-lived SSH certs.
SPIRE / SPIFFE — workload identity standard. Используется в Istio, Linkerd 2.x, Consul, AWS App Mesh.
Istio / Linkerd — service mesh с mTLS + AuthZ policy. Linkerd проще, Istio мощнее.
OPA (Open Policy Agent) — PDP де-факто стандарт. Rego policy language, embedded во всё (Envoy, k8s admission, Terraform, microservices).
Teleport — identity-aware proxy для SSH/RDP/k8s/DB. Short-lived certs вместо паролей.
CrowdStrike / SentinelOne — EDR с API для device posture queries. Стандарт для managed endpoints.
Jamf / Kandji / Microsoft Intune — MDM, источник truth для «managed/encrypted/patched».
Anti-patterns
«Купим Zscaler — будет Zero Trust» — продукт не равен архитектуре. Без identity hygiene + device posture + microsegmentation + short-lived credentials остаётся VPN с другим логотипом.
Big-bang migration — не работает, всегда поэтапно (app-by-app, 12-36 месяцев).
Только users, не workloads — service-to-service mTLS половина attack surface. Без него Zero Trust на 50% (SolarWinds — backdoored workload, не user).
Один PEP, не на всех путях — атакующий находит forgotten endpoint (старый admin-панель на порту 8080, dev-инстанс с public IP). Audit egress, scan publicly accessible.
Не trackать device posture — user аутентифицирован, но laptop с malware → утечка. EDR + MDM обязательны day 1.
Authentication раз в день, без re-eval — это session-trust, не Zero Trust. Continuous re-evaluation (даже с caching) обязательна.
MFA через SMS/TOTP для админов — phishable, SIM-swap, MFA fatigue. WebAuthn/hardware keys (YubiKey, Titan) для всего sensitive. Uber 2022 — MFA fatigue прямо в плакат повесить.
Долгоживущие credentials — Capital One 2019 (instance role с over-permissive IAM), SolarWinds (постоянные API keys). Vault dynamic secrets, AWS STS, GCP impersonation — credentials TTL 1h.
Логировать без alerting — audit logs есть, никто не смотрит. PEP denial = potential pivot attempt, нужен alert pipeline в SOC.
PDP-policy как «деревьев нет — позволено всё» — default-deny, не default-allow. Каждое разрешение явное.
Flat k8s namespace без NetworkPolicy — даже с service mesh, defense in depth требует NetworkPolicy (Cilium предпочтительнее calico для L7). Если sidecar не enforced (misconfigured pod), network ловит.
Сами писать IAM/PEP — не пишите свой OAuth, не пишите свой identity-aware proxy. Используйте Okta/Auth0/Cloudflare/OPA. Свой код в критическом пути auth — рецепт breach.
Когда НЕ использовать
Air-gapped окружения (defence, нефтегаз SCADA, ядерка) — там модель безопасности другая, network isolation физическая, identity-aware proxy в интернете не нужен. Микросегментация — да, но reference architecture не Zero Trust в коммерческом смысле.
Когда нет identity foundation — Zero Trust строится на identity. Без Okta/Azure AD/Google Workspace (или эквивалента) и без HR-системы как источника truth по сотрудникам — Zero Trust превращается в карго-культ. Сначала identity hygiene, потом ZT.
Когда нет executive sponsorship — 12-36 месячная трансформация без CISO/CTO backing помрёт после первой politically-painful миграции (особенно admin tools и legacy thick-client apps).
Когда нет budget на observability — ZT генерирует огромный объём audit logs. Без Datadog/Splunk/ELK/Loki + alerting pipeline это data-dump, не security.
Pre-PMF startup с 3 людьми — Tailscale + Okta + hardware keys = достаточно. Полная BeyondCorp-style архитектура — overkill, ресурсы лучше в product.
Связанные концепты: ::concept{slug="mtls"} (workload identity и encryption в transit), ::concept{slug="oauth-oidc"} (user identity protocols), ::concept{slug="authn-models"} и ::concept{slug="authz-models"} (PDP-inputs), ::concept{slug="service-mesh-deep"} (microsegmentation в проде), ::concept{slug="secrets-management"} (Vault, short-lived credentials), ::concept{slug="threat-modeling-stride"} (как находить gaps в ZT-архитектуре), ::concept{slug="owasp-top-10"} (app-level угрозы поверх ZT-фундамента), ::concept{slug="api-security"}, ::concept{slug="rbac-implementation-patterns"}, ::concept{slug="jwt-best-practices"}, ::concept{slug="csrf-xss-protection"}, ::concept{slug="supply-chain-security"} (SolarWinds — главный пример, почему egress filtering обязателен).
Discussion · 0
No discussion yet. Be the first to share an insight.