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í.
Co je „Zero Trust” v praxi (a co to není)¶
„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í.
Referenční architektura podle NIST SP 800-207¶
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.
Principy Zero Trust, které v roce 2026 opravdu rozhodují¶
1
Phishing-resistant identity (passkeys, FIDO2) místo „MFA jako checkbox”¶
Nejčastější cesta k breachi je kompromitovaná identita. SMS a TOTP MFA už v roce 2026 často nestačí. Cíl je phishing-resistant autentizace: FIDO2 security keys / passkeys, případně certificate-based. U privilegovaných účtů kombinujte s device bound přihlášením a JIT/JEA.
2
Device posture jako „vstupenka” do systému¶
Zero Trust bez důvěry v zařízení je poloviční. V praxi to znamená MDM enrollment, EDR agent, šifrování disku, patch compliance, a zákaz přístupu z unmanaged zařízení (nebo alespoň výrazně omezený režim).
3
Microsegmentation pro east-west provoz (nejen north-south)¶
Útočník uvnitř sítě je váš výchozí předpoklad. Mikrosegmentace má bránit laterálnímu pohybu: v cloudu přes SG/NACL, v Kubernetes přes network policies (default-deny), a mezi službami přes service mesh (mTLS + authz).
4
Policy-as-code a auditovatelnost¶
Jakmile máte desítky aplikací a stovky pravidel, ruční klikání v konzoli je neudržitelné. Politiky definujte deklarativně, verzujte v Gitu, testujte (unit testy pravidel) a nasazujte přes CI/CD. To výrazně zvyšuje konzistenci i compliance.
5
Kontinuální vyhodnocování (continuous access evaluation)¶
„Jednou přihlášen = navždy důvěryhodný” je starý svět. V roce 2026 prosazujte krátké životnosti tokenů, revokaci sessions při změně risku a korelaci signálů (UEBA + EDR + IdP). Když endpoint zčervená, přístup se má změnit během minut.
Implementace krok za krokem (roadmapa, která funguje)¶
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).
0 — Předstart
Definujte „protect surface” a cílový výsledek¶
Vyberte konkrétní aktivum (např. „internet banking admin”, „datový sklad s PII”, „produkční Kubernetes cluster”) a nastavte metriky: kdo přistupuje, z jakých zařízení, jaká je tolerance výpadku, jaké jsou regulatorní požadavky.
1 — Identity
SSO všude, privilegia pod kontrolou¶
Zaveďte jednotný IdP (Entra ID/Okta/Keycloak), vynucenou MFA (ideálně passkeys), a omezte privilegované účty přes PIM/PAM + JIT. U servisních účtů přejděte na workload identity (OIDC federation) a rotujte secrets.
2 — Zařízení
MDM/EDR + pravidla pro přístup¶
Definujte baseline (šifrování, patching, EDR, screen lock, zakázané aplikace) a promítněte ji do conditional access. Rozlišujte režimy: plný přístup (managed + compliant), omezený přístup (managed, ale non-compliant) a blokace (unmanaged).
3 — Přístup k aplikacím
Nahraďte „VPN do celé sítě” za ZTNA/SSE¶
U interních webů a API použijte ZTNA proxy/Identity-Aware Proxy. PEP pak vynucuje autentizaci i autorizaci pro konkrétní aplikaci (ne pro celý subnet). Užitečné je začít jedním „high value” systémem a postupně migrovat další.
4 — Mikrosegmentace
Default-deny a explicitní toky¶
Segmentujte kolem aplikací a dat, ne kolem VLAN. V Kubernetes nastavte network policies (default-deny) a service-to-service authz. V tradiční síti používejte segmentační gateway a pravidla založená na identitě/workloadu (ne jen IP).
5 — Data
Klasifikace, šifrování, DLP a „least privilege” na úrovni datových operací¶
Zero Trust není jen o síti. Důležité je RBAC/ABAC u databází a datových skladů, tokenizace/šifrování PII, audit přístupů a DLP pro exfiltraci do SaaS. Bez datové vrstvy zůstává ZTA „pěkná brána” s otevřeným skladem.
6 — Telemetrie
SIEM + korelace signálů + automatizace¶
Sbírejte logy z IdP, PEP, EDR a cloud providerů. Postavte základní playbooky: zablokování session při kompromitaci, izolace endpointu, dočasné snížení oprávnění. Bez automatizace bude Zero Trust „pomalejší” než útočník.
Praktický stack: nástroje, které se v Zero Trust projektech opakují¶
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)¶
Microsoft Entra ID
SSO, Conditional Access, Identity Protection, PIM
Okta
SSO, adaptive MFA, lifecycle management
Keycloak
Open-source IdP pro self-hosted scénáře
ZTNA / SSE (PEP pro uživatelský přístup)¶
Cloudflare Zero Trust
ZTNA, SWG, CASB, WARP klient
Zscaler
SSE platforma, rozsáhlé enterprise nasazení
Google IAP / BeyondCorp
Identity-aware access k webům a API
Workload & east-west (microsegmentation)¶
Cilium / Calico
Kubernetes network policies, segmentace
Istio / Linkerd
mTLS, authz, traffic policy, observability
Illumio
Mikrosegmentace pro hybridní prostředí
Zařízení (posture)¶
Intune / Jamf
MDM, compliance, policy enforcement
CrowdStrike / SentinelOne
EDR/XDR, detekce a izolace zařízení
osquery / Kolide
Granulární posture signály, audit
Policy-as-code & autorizační vrstva¶
Open Policy Agent (OPA)
Unifikovaná autorizace a policy testování
HashiCorp Vault
Secrets, PKI, dynamic creds
SPIFFE/SPIRE
Workload identity (zejména pro mesh)
Case příklady: jak vypadá Zero Trust nasazení v různých firmách¶
Zero Trust není jedna šablona. Níže jsou tři typické scénáře, které v praxi vídáme.
1) Banka / regulované prostředí¶
Priorita: auditovatelnost, separace rolí, JIT privilegia, segmentace core systémů. Praktický pattern: Entra ID + PIM, ZTNA pro admin rozhraní, mikrosegmentace kolem core banking, SIEM korelace (IdP + EDR + firewall) a playbooky pro okamžité „session kill”.
2) Výroba / OT + IT¶
Priorita: oddělit OT a IT, minimalizovat laterální pohyb, řízený přístup dodavatelů. Pattern: jump host / ZTNA do servisních zón, allow-list komunikace, identity-based přístup pro techniky, dlouhý životní cyklus zařízení řešit kompenzačními kontrolami (monitoring, izolace, protokolové brány).
3) SaaS firma / cloud-native¶
Priorita: workload identity, service-to-service authz, ochrana API a dat. Pattern: service mesh (mTLS), OPA pro autorizaci, krátkožijící tokeny, secrets ve Vaultu, CSPM/CNAPP pro cloud posture a detekce misconfigurations.
Co si odnést (a kde začít zítra)¶
- Vyberte 1 protect surface a udělejte end-to-end průchod (IdP + posture + PEP + logy).
- Zvedněte laťku identity (phishing-resistant MFA / passkeys) a privilegia přepněte na JIT.
- Ukončete „VPN do celé sítě” — přejděte na per-app access (ZTNA/IAP).
- Default-deny segmentace (Kubernetes network policies / mesh / SG).
- 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.
Závěr¶
Zero Trust Architecture v roce 2026 je především o konzistenci rozhodování: stejná pravidla pro uživatele i workloady, stejné signály, stejné audity — bez ohledu na to, jestli jste on-prem, v cloudu nebo na cestách. Nejlepší implementace nejsou „nejvíc restriktivní”, ale nejlépe automatizované a založené na kvalitních signálech (identity + posture + telemetrie).