Zero Trust Architektura

Proč Zero Trust¶

Tradiční security model předpokládá, že síťový perimetr odděluje důvěryhodné od nedůvěryhodného. Realita 2025:

• Cloud-native — Služby běží v Azure, AWS, on-premise. Kde je perimetr?
• Remote work — Zaměstnanci pracují odkudkoliv. VPN nestačí.
• Supply chain — Third-party integrace, SaaS nástroje, external API. Kdo je „uvnitř”?
• Lateral movement — Útočník kompromituje jeden endpoint a pohybuje se volně po síti.

Zero Trust říká: žádná implicitní důvěra. Každý request se ověřuje — nezáleží odkud přichází.

Pilíře implementace¶

1. Identita & Autentizace¶

Uživatelé: - SSO přes identity provider (Azure AD, Okta, Auth0) - MFA povinné pro všechny — FIDO2/WebAuthn preferované (phishing-resistant) - Conditional access policies — kontext rozhoduje (zařízení, lokace, risk score) - Passwordless kde je to možné

Služby (workload identity): - SPIFFE/SPIRE pro workload identity — každá služba má kryptograficky ověřitelnou identitu - Service accounts s minimálními oprávněními - Managed identities (Azure MI, AWS IAM roles) místo long-lived credentials - Certificate rotation automatická, bez downtime

2. Mutual TLS (mTLS)¶

Service-to-service komunikace šifrovaná a oboustranně autentizovaná:

• Service mesh (Istio, Linkerd) — mTLS transparentně pro všechny služby v clusteru
• Certificate management — Automatická rotace, short-lived certifikáty (24h)
• No plaintext — Žádná nešifrovaná komunikace, ani v interní síti
• Observability — Vidíte kdo s kým komunikuje, kolik dat teče

3. Mikrosegmentace¶

Síťové politiky na úrovni workloadu:

• Kubernetes NetworkPolicy — Default deny, explicitní allow rules
• Cilium — eBPF-based enforcement, L7 policy (HTTP method, path)
• Service mesh policies — AuthorizationPolicy v Istio (kdo smí volat koho)
• East-west firewall — Kontrola laterálního trafficu, ne jen north-south

Příklad: order-service smí komunikovat s inventory-service a payment-service. Žádná jiná služba. Útočník, který kompromituje notification-service, se nedostane k objednávkám.

4. Least Privilege & JIT Access¶

RBAC granularita: - Role definované per služba, per prostředí (dev/staging/prod) - Žádné wildcard oprávnění (*:*:*) - Pravidelné access reviews — kdo má přístup kam a proč

Just-in-Time (JIT) access: - Administrátor nepotřebuje permanentní prod přístup - Požádá o access → schválení → time-boxed oprávnění (2-4h) → automatický revoke - Audit trail každého přístupu - PAM (Privileged Access Management) pro kritické systémy

5. Continuous Verification¶

Zero Trust nekončí autentizací:

• Device posture — Je zařízení spravované? Aktuální OS? Endpoint protection běží?
• Behavioral analytics — Anomálie v chování uživatele (unusual login time, location, access pattern)
• Session re-evaluation — Risk score se přepočítává průběžně, ne jen při loginu
• Adaptive policies — Zvýšené riziko → požadavek na step-up autentizaci

Implementační roadmapa¶

Fáze 1: Visibility (Měsíc 1-2)¶

• Inventarizace všech služeb, uživatelů, data flows
• Monitoring east-west traffic — kdo s kým komunikuje
• Baseline pro normální chování
• Gap analýza proti Zero Trust principům

Fáze 2: Identity Foundation (Měsíc 2-3)¶

• SSO + MFA pro všechny uživatele
• Workload identity (SPIFFE/SPIRE nebo managed identities)
• Service mesh deployment (mTLS v permissive mode — loguje, neblokuje)

Fáze 3: Enforcement (Měsíc 3-5)¶

• mTLS strict mode — nešifrovaná komunikace blokována
• NetworkPolicy / AuthorizationPolicy enforcement
• JIT access pro admin operace
• Least privilege audit a remediation

Fáze 4: Continuous (Ongoing)¶

• Behavioral analytics a anomaly detection
• Quarterly access reviews
• Policy-as-code — GitOps pro security policies
• Red team exercises zaměřené na lateral movement

Technologie¶

Istio, Linkerd, Cilium, SPIFFE/SPIRE, Azure AD / Entra ID, Okta, HashiCorp Vault, Kubernetes NetworkPolicy, Open Policy Agent (OPA), Falco, CrowdStrike, Microsoft Defender for Cloud.