Zero Trust Architecture (ZTA) už dávno není buzzword. V roce 2026 je to praktický způsob, jak provozovat bezpečný hybridní cloud, vzdálený přístup bez klasické VPN a mikrosegmentované aplikace tak, aby kompromitace jedné identity nebo jedné služby nezpůsobila dominový efekt. Tento článek je technický průvodce pro architekty, CTO a security týmy: vycházíme z NIST SP 800-207, doplňujeme trendy posledních let (passkeys, device posture, ZTNA/SSE, service mesh, policy-as-code) a ukazujeme konkrétní kroky implementace v reálném prostředí.

„Zero Trust" se často redukuje na nákup ZTNA produktu. To je omyl. NIST SP 800-207 definuje ZTA jako architekturu, která minimalizuje nejistotu při rozhodování o přístupu a předpokládá, že síť je kompromitovaná. Prakticky to znamená:

• Identita je nový perimetr — uživatel i workload musí být jednoznačně ověřen.
• Přístup je per-request / per-session — rozhodnutí se dělá pro konkrétní akci a kontext.
• Kontinuální vyhodnocování — risk se přepočítává, session může být „odříznuta" uprostřed.
• Nejmenší oprávnění — role, scope, čas, síťový tok i datová operace.

A co Zero Trust není: není to jednorázový projekt, není to synonymum pro MFA a není to „jen" segmentace sítě. Je to operační model napříč identitou, zařízeními, sítí, aplikacemi, daty a telemetrií.

NIST 800-207 popisuje logické komponenty ZTA a jejich vztahy. V praxi se typicky potkáte s těmito rolemi:

• Policy Decision Point (PDP) — rozhodovací bod v řídicí rovině (control plane):
  • Policy Engine (PE) vyhodnocuje signály (identity, device posture, riziko, kontext).
  • Policy Administrator (PA) „prosadí" rozhodnutí (např. nastaví pravidla/konfiguraci na PEP).
• Policy Enforcement Point (PEP) — v datové rovině (data plane) vynucuje povolení/deny (proxy, gateway, sidecar, firewall, agent).
• Telemetry & signal sources — IAM, EDR/MDM, SIEM, asset inventory, CMDB, vulnerability mgmt.

                    +--------------------------- Control plane ----------------------------+
                    |                                                                      |
                    |  Telemetrie & signály:                                                |
                    |  - IdP/IAM (SSO, MFA, risk)    - EDR/MDM (posture)                    |
                    |  - SIEM/UEBA (anomálie)        - CMDB/Inventory                       |
                    |  - Vuln mgmt / CSPM / CNAPP                                         |
                    |                 \                         |                          |
                    |                  \                        |                          |
                    |                   v                       v                          |
                    |              +-------------------------------+                        |
                    |              |   PDP (Policy Engine + Admin) |                        |
                    |              +-------------------------------+                        |
                    |                         | (policy decision)                            |
                    +-------------------------|----------------------------------------------+
                                              v
                    +--------------------------- Data plane --------------------------------+
                    |                                                                       |
                    |  User/Device ---->  PEP (ZTNA proxy / gateway / mesh sidecar)  ----> App/API
                    |                                                                       |
                    |                         (mTLS, authz, rate limit, logging)            |
                    +-----------------------------------------------------------------------+

Důležitý detail: NIST odděluje control plane a data plane. To je praktická rada: policy rozhodování (kde jsou citlivé signály) má být izolované a auditované, zatímco enforcement běží co nejblíž workloadům a uživatelům.

Největší riziko projektu Zero Trust je, že se z něj stane nekonečný program bez měřitelných výstupů. Doporučený postup je iterativní: vyberte 1–2 protect surfaces (kritická data/aplikace) a na nich postavte první end-to-end průchod (identity → device → enforcement → logs).

Konkrétní volba nástrojů závisí na vendor strategii a prostředí (Microsoft-centric, cloud-agnostic, on-prem). Níže je „referenční" mapa — typy komponent, které potřebujete pokrýt.

Identity (IdP, MFA, PAM)

ZTNA / SSE (PEP pro uživatelský přístup)

Workload & east-west (microsegmentation)

Zařízení (posture)

Policy-as-code & autorizační vrstva

Zero Trust není jedna šablona. Níže jsou tři typické scénáře, které v praxi vídáme.

1. Vyberte 1 protect surface a udělejte end-to-end průchod (IdP + posture + PEP + logy).
2. Zvedněte laťku identity (phishing-resistant MFA / passkeys) a privilegia přepněte na JIT.
3. Ukončete „VPN do celé sítě" — přejděte na per-app access (ZTNA/IAP).
4. Default-deny segmentace (Kubernetes network policies / mesh / SG).
5. SIEM korelace signálů a automatizované reakce (session revoke, izolace endpointu).

Pokud chcete, umíme s vámi projít rychlý workshop (2–4 hodiny) a vyrobit první realistickou roadmapu: co udělat za 30/60/90 dní, na čem to technicky postavit a jak to měřit.

• NIST SP 800-207 — Zero Trust Architecture
• CISA — Zero Trust Maturity Model (v2.0)
• Google BeyondCorp (praktická implementace ZT)