🟡 Intermediate

Zero Trust Security — Bezpečnostný model bez implicitnej dôvery

Zero Trust je bezpečnostný model založený na princípe „nikdy nedôveruj, vždy overuj". Tradičný perimeter-based prístup (firewall okolo siete = bezpečné vnútro) nefunguje v ére cloudu, mikroslužieb a remote práce. Zero Trust predpokladá, že útočník už je vo vašej sieti, a každý request musí byť autentifikovaný, autorizovaný a šifrovaný — bez ohľadu na to, odkiaľ prichádza.

Prečo tradičný perimeter nefunguje

V klasickom modeli existuje jasná hranica: vnútorná sieť je dôveryhodná, vonkajšia nie. Tento model zlyháva keď:

  • Cloud a hybrid — workloady bežia na viacerých miestach, perimeter je rozmazaný
  • Mikroslužby — desiatky služieb komunikujú navzájom, east-west traffic dominuje
  • Remote práca — zamestnanci pristupujú z domácich sietí, kaviarní, telefónov
  • Supply chain attacks — kompromitovaná závislosť je už vnútri perimetra
  • Lateral movement — útočník prelomí jeden systém a voľne sa pohybuje ďalej

Perimeter vs Zero Trust

Aspekt Perimeter model Zero Trust
Dôvera Vnútorná sieť = dôveryhodná Žiadna implicitná dôvera
Overovanie Na hranici siete Pri každom requeste
Šifrovanie Len externý traffic Všetok traffic (mTLS)
Prístup Sieťová poloha Identita + kontext
Segmentácia Hrubá (VLANy) Jemná (per-service)
Predpoklad Útočník je vonku Útočník je už vnútri

Piliere Zero Trust

1. Silná identita

Každý subjekt (používateľ, služba, zariadenie) musí mať overiteľnú identitu:

# SPIFFE identita pre workload v Kubernetes
# URI: spiffe://cluster.example.com/ns/payments/sa/payment-api
apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterSPIFFEID
metadata:
  name: payment-api
spec:
  spiffeIDTemplate: "spiffe://{{ .TrustDomain }}/ns/{{ .PodMeta.Namespace }}/sa/{{ .PodSpec.ServiceAccountName }}"
  podSelector:
    matchLabels:
      app: payment-api

Nástroje: SPIFFE/SPIRE, cert-manager, cloud IAM, OAuth2/OIDC

2. Microsegmentácia

Namiesto plochej siete — granulárne pravidlá pre komunikáciu medzi služieb:

# Kubernetes NetworkPolicy — payment-api môže hovoriť len s orders-db
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: payment-api-policy
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: payment-api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: api-gateway
          podSelector:
            matchLabels:
              app: api-gateway
      ports:
        - port: 8080
          protocol: TCP
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: orders-db
      ports:
        - port: 5432
          protocol: TCP
    - to:  # DNS
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - port: 53
          protocol: UDP

Pokročilejšie s Cilium:

# Cilium L7 politika — povolí len GET /api/v1/orders
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: payment-api-l7
  namespace: payments
spec:
  endpointSelector:
    matchLabels:
      app: payment-api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: api-gateway
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: GET
                path: "/api/v1/orders.*"
              - method: POST
                path: "/api/v1/payments"

3. Mutual TLS (mTLS)

Každá komunikácia je šifrovaná a obojstranne autentifikovaná:

# Istio PeerAuthentication — vynútiť mTLS v namespace
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: payments
spec:
  mtls:
    mode: STRICT
---
# Istio AuthorizationPolicy
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payment-api-authz
  namespace: payments
spec:
  selector:
    matchLabels:
      app: payment-api
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - cluster.local/ns/gateway/sa/api-gateway
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/v1/*"]

4. Least privilege access

Minimálne oprávnenia pre každý subjekt:

# Kubernetes RBAC — payment-api čítá len svoje secrets
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: payments
  name: payment-api-role
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    resourceNames: ["payment-db-creds", "stripe-api-key"]
    verbs: ["get"]
  - apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["payment-config"]
    verbs: ["get", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: payment-api-binding
  namespace: payments
subjects:
  - kind: ServiceAccount
    name: payment-api
roleRef:
  kind: Role
  name: payment-api-role
  apiGroup: rbac.authorization.k8s.io

5. Kontinuálne overovanie

Prístup sa neoveruje jednorázovo — kontext sa vyhodnocuje priebežne:

  • Device posture — je zariadenie patchované? Má šifrovanie disku?
  • User behavior — nezvyčajná aktivita (iná krajina, iný čas)?
  • Request context — scope, rate, payload anomálie
  • Session re-evaluation — expirujúce tokeny, step-up autentifikácia

Zero Trust pre infraštruktúru

SSH prístup bez permanentných kľúčov

# Tradičný prístup — SSH kľúč na serveri navždy
ssh -i ~/.ssh/id_rsa admin@server  # Kľúč nikdy neexpiruje

# Zero Trust — krátkodobé certifikáty cez Teleport/Boundary
tsh login --proxy=teleport.example.com --user=admin
tsh ssh root@server
# Certifikát platí 8 hodín, všetko sa loguje, session recording

HashiCorp Boundary — identity-aware access

# Boundary konfigurácia — prístup k databáze cez identity
resource "boundary_target" "production_db" {
  type                     = "tcp"
  name                     = "production-database"
  scope_id                 = boundary_scope.production.id
  session_connection_limit = 1
  default_port             = 5432

  host_source_ids = [
    boundary_host_set_static.db_servers.id
  ]

  injected_application_credential_source_ids = [
    boundary_credential_library_vault.db_creds.id
  ]
}

Vývojár nikdy nevidí reálne credentials — Boundary ich injektuje do session a po skončení revokuje.

Implementačná roadmapa

Zero Trust sa neimplementuje naraz. Odporúčaný postup:

Fáza 1: Viditeľnosť (1-2 mesiace)

  • Mapovanie communication flows medzi službami
  • Audit existujúcich prístupov a oprávnení
  • Nasadenie network monitoring (flow logs, service mesh observability)

Fáza 2: Identita a autentifikácia (2-3 mesiace)

  • SSO/OIDC pre všetky systémy
  • Service accounts a SPIFFE identiy pre workloady
  • mTLS v permissive mode (loguje, neblokuje)

Fáza 3: Autorizácia a segmentácia (3-4 mesiace)

  • NetworkPolicies — default deny, explicitné allow
  • RBAC audit a sprísnenie
  • mTLS v strict mode

Fáza 4: Kontinuálny enforcement (ongoing)

  • Policy-as-Code pre automatizované vynucovanie
  • Krátkodobé credentials a certifikáty
  • Anomaly detection a automated response

Nástroje ekosystému

Oblasť Nástroje
Identity SPIFFE/SPIRE, Keycloak, Okta, Azure AD
Network Cilium, Calico, Istio, Linkerd
Access Teleport, HashiCorp Boundary, Tailscale
Secrets HashiCorp Vault, AWS Secrets Manager, SOPS
Policy OPA/Gatekeeper, Kyverno, Sentinel
Monitoring Falco, Tetragon, Wazuh

Meranie úspešnosti

# Zero Trust KPIs
metriky:
  - name: "Percento mTLS traffic"
    cieľ: ">99%"
    meranie: "Istio/Linkerd dashboards"

  - name: "Mean time to revoke access"
    cieľ: "<15 minút"
    meranie: "IAM audit logs"

  - name: "Percento služieb s NetworkPolicy"
    cieľ: "100%"
    meranie: "kubectl get netpol --all-namespaces"

  - name: "Priemerná životnosť credentials"
    cieľ: "<24 hodín"
    meranie: "Vault audit logs"

  - name: "Lateral movement blast radius"
    cieľ: "1 služba"
    meranie: "Red team exercises"

Best practices

  1. Default deny — všetko je zakázané, pokiaľ nie je explicitne povolené
  2. Encrypt everything — mTLS pre service-to-service, TLS pre všetok externý traffic
  3. Short-lived credentials — hodiny, nie mesiace; automatická rotácia
  4. Least privilege — minimum oprávnení, pravidelný audit
  5. Log everything — každý prístup, každé rozhodnutie, full audit trail
  6. Assume breach — dizajnujte systémy tak, akoby bol útočník už vnútri
  7. Automate enforcement — manuálne pravidlá sa nedodržiavajú, automatizované áno
  8. Incrementálna adopcia — nezačínajte blokovaním, začnite monitoringom

Zhrnutie

Zero Trust nie je produkt, ktorý si kúpite — je to architektonický prístup, ktorý fundamentálne mení spôsob, akým premýšľate o bezpečnosti. V DevOps kontexte to znamená mTLS medzi službami, identity-based prístup namiesto sieťového, microsegmentáciu, krátkodobé credentials a kontinuálne overovanie. Implementácia je postupná, ale každý krok výrazne znižuje attack surface a blast radius prípadného kompromisu.