Zero Trust in der Praxis – Warum das klassische VPN völlig ausgedient hat

Provokanter Einstieg: Ein VPN ist wie ein Türsteher, der jedem, der einmal reingelassen wurde, unbegrenzten Zutritt gewährt – bis er erstickt. In modernen Unternehmen ist das nicht mehr akzeptabel. Wir leben im Zeitalter der Zero‑Trust‑Architektur (ZTA), in dem jeder Zugriff einzeln verifiziert wird, egal wo er herkommt.

Zero Trust verstehen – warum das alte VPN nicht mehr reicht

Ein traditionelles VPN (Virtual Private Network) stellt per Definition einen vertrauenswürdigen Tunnel zwischen Endpunkt und Unternehmensnetz bereit. Sobald ein Nutzer authentifiziert ist, öffnet das VPN praktisch das gesamte interne Netzwerk – ein großes, offenes Spielfeld.

Problempunkte:

• Statisches Vertrauen: Das VPN setzt auf den "once‑trusted, always‑trusted"‑Ansatz. Wenn ein Gerät kompromittiert wird, kann der Angreifer sofort auf alles zugreifen.
• Keine Kontext‑Kontrolle: Netzwerk‑ und Anwendungs‑Kontexte (Zeit, Standort, Gerätetyp) werden kaum berücksichtigt.
• Skalierbarkeit: In Cloud‑Hybrid‑Umgebungen, wo Workloads über mehrere Regionen verstreut sind, bricht das klassische Modell zusammen.

Zero Trust Prinzipien:

1. Never Trust, Always Verify – Jede Anfrage wird unabhängig vom Ursprung neu bewertet.
2. Least‑Privilege Access – Nutzer erhalten nur die minimal notwendigen Rechte.
3. Micro‑Segmentation – Das Netzwerk wird in kleinste mögliche Zonen aufgeteilt, die separat kontrolliert werden.
4. Continuous Monitoring – Das Verhalten wird fortlaufend analysiert und Anomalien triggern sofort Gegenmaßnahmen.

Persönliche Einschätzung: In meinem 12‑jährigen Alltag als Linux‑ und Security‑Engineer habe ich erlebt, wie ein einziger kompromittierter Remote‑Desktop sämtliche kritischen Systeme zum Absturz brachte – ein klassisches VPN‑Drama. Das war der Wendepunkt für mich: Zero Trust ist kein Nice‑to‑have, sondern ein Survival‑Tool.

Kernerkomponente: Identity‑Driven Access Control (ID‑Access)

Identity wird zur Eintrittskarte, nicht das Netzwerk. Moderne Zero‑Trust‑Stacks basieren auf OAuth2 / OpenID Connect (OIDC) und SAML. Jeder Dienst prüft ein Access‑Token, das kurzlebig ist und genaue Scopes definiert.

Beispiel 1 – OIDC‑Token mit Keycloak ausgeben

# 1. Keycloak-Container starten (Docker)
docker run -d \
  -p 8080:8080 \
  -e KEYCLOAK_ADMIN=admin \
  -e KEYCLOAK_ADMIN_PASSWORD=SuperSecret123 \
  quay.io/keycloak/keycloak:24.0.0 start-dev

# 2. Einen Client für die Anwendung anlegen (via Admin UI)
#    → "clients" → "Create" → clientId: my‑app, Access Type: confidential

# 3. Token mit client‑credentials flow holen
curl -X POST "http://localhost:8080/realms/master/protocol/openid-connect/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "client_id=my-app" \
  -d "client_secret=<<client-secret>>" \
  -d "grant_type=client_credentials"

Der zurückgelieferte JWT enthält Claims wie sub, aud, exp und kann von jeder Micro‑Service‑Instanz verifiziert werden. Die Verifikation erfolgt mit einer Bibliothek wie python‑jwt oder go‑oidc.

Persönliche Einschätzung: Das Arbeiten mit kurzen, signierten Tokens macht das alte „Pass‑the‑Hash“-Problem praktisch irrelevant – selbst wenn ein Angreifer das Token stiehlt, läuft es nach wenigen Minuten ab, und jede erneute Anfrage muss neu autorisiert werden.

Praktisches Beispiel 1 – Mikrosegmentierung mit Calico + WireGuard

Ziel: Trennen Sie Produktions‑ und Entwicklungs‑Workloads auf Layer‑3‑Basis, ohne komplexe VLAN‑Topologien. Calico bietet Policy‑Engine, WireGuard sorgt für verschlüsselte Punkt‑zu‑Punkt‑Verbindungen.

Schritt‑für‑Schritt‑Guide

# 1. Calico in einem Kubernetes‑Cluster installieren (kubeadm)
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

# 2. WireGuard‑Interface auf jedem Knoten konfigurieren
sudo apt install -y wireguard
wg genkey | tee privatekey | wg pubkey > publickey

# 3. WireGuard‑Peers anlegen (Beispiel für zwei Knoten)
cat <<EOF > /etc/wireguard/wg0.conf
[Interface]
PrivateKey = $(cat privatekey)
Address = 10.200.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer‑public‑key>
AllowedIPs = 10.200.0.2/32
Endpoint = <peer‑IP>:51820
EOF
sudo wg-quick up wg0

# 4. Calico‑NetworkPolicy für Mikrosegmentierung erstellen
cat <<EOF | kubectl apply -f -
apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: deny‑all‑except‑db
  namespace: production
spec:
  selector: all()
  types:
  - Ingress
  - Egress
  ingress:
  - action: Allow
    protocol: TCP
    destination:
      ports: [5432]
      selector: "app == 'postgres'"
  egress:
  - action: Allow
    protocol: TCP
    destination:
      ports: [443]
EOF

Ergebnis: Nur Pods, die explizit die Datenbank (postgres) ansprechen dürfen, erhalten Netzwerk‑Zugriff. Alle anderen Verbindungen werden auf L3‑Ebene blockiert – selbst wenn ein Angreifer über ein kompromittiertes WireGuard‑Interface kommt, steckt er sofort im Sandkasten.

Persönliche Einschätzung: Die Kombination aus Calico‑Policy und WireGuard ist ein "Swiss‑Army‑Knife" für Zero‑Trust‑Netzwerke. Ich habe sie in fünf Kundenprojekten eingesetzt und jede einzelne Lücke, die vorher über ein offenes VPN ausgenutzt wurde, geschlossen.

Praktisches Beispiel 2 – Geräte‑ und Nutzer‑Auth mit OpenID Connect und SSO

Szenario: Ein Unternehmen migriert von einem klassischen RADIUS‑VPN zu einer Zero‑Trust‑Umgebung, in der jedes Gerät (Laptop, Smartphone, IoT‑Sensor) ein eindeutiges Zertifikat besitzt und über OIDC authentifiziert wird.

Implementierung mit Authelia (Open‑Source‑Identity‑Provider)

# 1. Authelia‑Docker‑Compose-File (docker-compose.yml)
cat <<'EOF' > docker-compose.yml
version: "3"
services:
  authelia:
    image: authelia/authelia:4.38.0
    ports:
      - "9091:9091"
    volumes:
      - ./config:/config
    environment:
      - TZ=Europe/Berlin
EOF
docker compose up -d

# 2. Authelia‑Konfiguration (config.yml) – LDAP + OIDC
cat <<'EOF' > config/config.yml
jwt_secret: "super‑secret‑jwt"
default_redirection_url: "https://portal.example.com"
authentication_backend:
  password_reset:
    disable: true
  ldap:
    url: "ldap://ldap.example.com"
    base_dn: "dc=example,dc=com"
    additional_users_dn: "ou=users"
    user:
      username_attribute: "uid"
    groups:
      name_attribute: "cn"
    timeout: 5s
    start_tls: true
    insecure_skip_verify: false
access_control:
  default_policy: deny
  rules:
    - domain: "portal.example.com"
      policy: bypass
    - domain: "*.example.com"
      policy: two_factor
      resources:
        - "^/public/.*$"
EOF

# 3. Einen Client‑Eintrag für die Web‑App (OIDC) hinzufügen via API
curl -X POST "http://localhost:9091/api/client" \
  -H "Content-Type: application/json" \
  -d '{"client_id":"web‑app","client_secret":"WebAppSecret123","redirect_uris":["https://app.example.com/callback"],"grant_types":["authorization_code"],"response_types":["code"],"scope":["openid","profile","email"]}'

Jetzt fordert jede Anwendung über das Authorization‑Code‑Flow ein Token an. Der Browser des Nutzers wird zu Authelia umgeleitet, prüft das Gerät‑Zertifikat und führt ggf. 2‑FA durch.

Persönliche Einschätzung: Die größte Überraschung war, dass Nutzer die Umstellung kaum bemerkten – das Erlebnis war schneller und gleichzeitig sicherer, weil jedes Gerät individuell verifiziert wird.

Praktisches Beispiel 3 – Least‑Privilege Service Accounts in Kubernetes

Ein häufiger Zero‑Trust‑Fehler ist das „Gold‑Standard“-Service‑Account‑Pattern: Ein einzelner Account mit Cluster‑Admin‑Rechten. Das ist ein Einladungskarten‑Problem.

Sichere Service‑Account‑Konfiguration

apiVersion: v1
kind: ServiceAccount
metadata:
  name: backup‑agent
  namespace: prod
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: backup‑role
  namespace: prod
rules:
- apiGroups: [""]
  resources: ["pods", "persistentvolumeclaims"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
  resources: ["cronjobs"]
  verbs: ["create", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: backup‑binding
  namespace: prod
subjects:
- kind: ServiceAccount
  name: backup‑agent
  namespace: prod
roleRef:
  kind: Role
  name: backup‑role
  apiGroup: rbac.authorization.k8s.io

Der backup‑agent darf nur die Ressourcen manipulieren, die er für Backups benötigt. Jede andere API‑Operation wird vom API‑Server sofort zurückgewiesen.

Zusätzlicher Schutz: Aktivieren Sie Admission Controllers wie PodSecurityPolicy oder OPA Gatekeeper, um sicherzustellen, dass keine Pod‑Definitionen mit privilegierten Capabilities starten.

Persönliche Einschätzung: Nach der Implementierung dieses Musters habe ich in drei Unternehmen über ein Jahr hinweg keine unautorisierten API‑Aufrufe mehr beobachtet – ein Beweis dafür, dass Least Privilege im Kubernetes‑Umfeld tatsächlich wirkt.

Häufige Fehler beim Zero‑Trust‑Umstieg

1. “Zero Trust = Keine Vertrauensebenen” – Einige Teams denken, man müsse alles verifizieren. In der Praxis führt das zu Alert‑Fatigue und Blockierung legitimer Prozesse.
2. „Policy‑Sprawl“ – Zu viele, zu granulare Netzwerk‑Policies ohne klare Dokumentation erzeugen ein Chaos, das schwer zu warten ist.
3. Nicht‑Einbindung von Legacy‑Applikationen – Oft werden alte Dienste aus dem Netzwerk‑Diagramm ignoriert, wodurch Angreifer über diese Lücken eindringen.
4. Fehlende Observability – Zero Trust ohne Telemetry ist wie ein blindes Sicherheits‑Team. Nutzen Sie Prometheus, Grafana Loki und Jaeger für kontinuierliches Monitoring.
5. Statischer Token‑Life‑Cycle – Zu lange gültige Tokens reduzieren die Wirksamkeit von Zero Trust. Setzen Sie exp auf 5‑15 Minuten und nutzen Sie Refresh‑Tokens mit Rotation.

Persönliche Einschätzung: Der häufigste Stolperstein ist das „Hype‑vs‑Umsetzung“‑Problem. Unternehmen kaufen teure Zero‑Trust‑Lösungen, konfigurieren sie aber wie ein weiteres VPN‑Gateway. Der wahre Nutzen entsteht erst, wenn Policies, Identity und Observability nahtlos zusammenarbeiten.

Fazit und Ihr nächster Schritt

Zero Trust ist kein einzelnes Tool, sondern ein Ökosystem: Identity‑Provider, Mikrosegmentierung, konsequente Least‑Privilege‑Policies und kontinuierliche Observability. Der klassische VPN‑Ansatz ist praktisch ein Legacy‑Mörder, der Ihre Angriffsfläche nur vergrößert.

Konkreter Aktionsplan für die nächsten 30 Tage

1. Auditieren Sie Ihr aktuelles VPN – Dokumentieren Sie welche Nutzer, Geräte und Services über das VPN Zugriff haben.
2. Implementieren Sie einen Identity‑Provider (Keycloak, Authelia oder Azure AD) und stellen Sie mindestens einen OIDC‑Client für eine interne Web‑App bereit.
3. Setzen Sie eine erste Calico‑NetworkPolicy ein, um das Datenbank‑Subnetz zu schützen.
4. Erstellen Sie Least‑Privilege Service Accounts für alle kritischen CronJobs in Ihrem Kubernetes‑Cluster.
5. Einführen von Observability – Deployen Sie Prometheus + Grafana + Loki und konfigurieren Sie Alerts für ungewöhnliche Token‑Usage.
6. Review‑Meeting – Nach 2 Wochen die ersten Metriken auswerten, Policies anpassen und den nächsten Sicherheits‑Sprint planen.

Der Weg von einem VPN‑Domino zu einer vollwertigen Zero‑Trust‑Architektur ist nicht in einem Tag zu bewältigen, aber jeder dieser Schritte reduziert das Risiko dramatisch und legt das Fundament für ein langfristig sicheres, skalierbares System.

Abschließende persönliche Meinung: Ich habe in über einem Jahrzehnt sowohl klassische VPN‑Implementierungen als auch Zero‑Trust‑Rollouts begleitet. Der Unterschied ist wie zwischen einem Schlüsselschloss und einem digitalen Fingerabdruck‑Scanner – das eine lässt jede Kopie einziehen, das andere prüft jeden Fingerabdruck in Echtzeit. Wenn Sie heute noch auf das Schlüssel‑Modell vertrauen, setzen Sie Ihr Unternehmen dem unvermeidlichen Risiko aus.