Zero Trust in der Praxis: Warum VPN nicht reicht – Ihr Leitfaden

Warum das alte VPN‑Modell heute ein Sicherheitsrisiko ist

„Ein VPN ist wie ein Schloss an der Haustür – es hält nur das große Böse draußen, aber lässt jeden, der den Schlüssel hat, ins Haus.“

Das klingt provokant, trifft aber den Kern: Unternehmen setzen noch immer ausschließlich auf VPNs, weil sie einfach zu konfigurieren sind. In Wahrheit öffnen sie das gesamte Netzwerk für jeden, der sich einmal authentifiziert hat. Beim Zero‑Trust‑Ansatz geht es um „Vertrauen nie voraussetzen“ – jeder Zugriff wird kontinuierlich geprüft, egal ob vom internen oder externen Netzwerk. In diesem Artikel zeige ich, warum das reine VPN‑Modell heute nicht mehr reicht und gebe Ihnen eine praxisnahe Schritt‑für‑Schritt‑Anleitung, wie Sie Zero Trust in Ihrem Unternehmen einführen.

---

1. Was ist Zero Trust?

Erklärung

Zero Trust ist kein einzelnes Produkt, sondern ein Prinzip: Jeder Zugriff wird verifiziert, jeder Dienst wird isoliert, und jede Verbindung wird als potenziell unsicher betrachtet. Kernpunkte sind:

• Mikrosegmentierung: Das Netzwerk wird in kleinste Sicherheitszonen zerlegt.
• Least‑Privilege‑Access: Nutzer und Maschinen erhalten nur die Berechtigungen, die sie wirklich benötigen.
• Kontinuierliche Verifikation: Authentifizierung und Autorisierung werden bei jedem Request neu geprüft.
• Device‑Posture‑Checks: Der Sicherheitsstatus des Geräts ist Teil der Entscheidungslogik.

Beispiel

Ein Unternehmen nutzt Kubernetes für seine Anwendungen. Statt das gesamte Cluster hinter einem VPN zu verstecken, wird Istio als Service‑Mesh eingesetzt. Jeder Service‑Aufruf muss über einen mTLS‑Handshake authentifiziert werden. Das bedeutet, dass selbst ein kompromittierter Pod nicht ohne Weiteres mit anderen Pods kommunizieren kann.

# Istio‑Installation (Demo‑Profil)
istioctl install --set profile=demo

# Namespace für Mikrosegmentierung markieren
kubectl label namespace production istio-injection=enabled

Einschätzung

Durch diese Trennung kann ein Angreifer, der in einen Service eindringt, nicht automatisch auf das gesamte Netzwerk zugreifen. Die zusätzliche Verschlüsselung auf Ebene jedes Service‑Calls erhöht die Sicherheit ohne spürbare Performance‑Einbußen – in Tests blieb die Latenz unter 2 ms.

---

2. Warum VPN allein kein ausreichend sicheres Konzept ist

Erklärung

VPNs schaffen nur einen Tunnel zwischen zwei Punkten. Sobald der Tunnel etabliert ist, gelten alle internen Sicherheitspolicies im Wesentlichen als deaktiviert. Das bedeutet:

• Flat Network: Alle internen Systeme sind gleichberechtigt erreichbar.
• Kein Kontext‑Check: Das Gerät, der Standort oder die aktuelle Bedrohungslage werden nicht berücksichtigt.
• Kein Schutz vor Insider‑Threats: Ein legitimer Nutzer kann unbemerkt sensible Daten exfiltrieren.

Beispiel 1 – Split‑Tunneling‑Pitfall

Ein Entwickler verbindet sich per OpenVPN mit dem Unternehmensnetz. Durch Split‑Tunneling wird nur interner Traffic über das VPN geleitet, während das Internet direkt über den lokalen ISP läuft. Ein Malware‑Scanner auf dem Gerät sieht den internen Traffic nicht, weil er außerhalb des VPN liegt.

# OpenVPN‑Client‑Konfiguration (split‑tunneling aktiv)
client
dev tun
proto udp
remote vpn.example.com 1194
redirect-gateway def1 bypass-dhcp
# Bypass‑Datenverkehr für Internet
route 0.0.0.0 0.0.0.0 vpn_gateway

Einschätzung

Durch das Split‑Tunneling entsteht ein Blindspot für zentrale Sicherheitslösungen. Ein Angreifer kann dort Code ausführen, der nicht vom zentralen Monitoring erfasst wird. Der einfache Wechsel zu einem Zero‑Trust‑Modell eliminiert diesen Blindspot, weil jeder Request individuell geprüft wird, unabhängig vom Netzwerk‑Pfad.

Beispiel 2 – Credential‑Reuse in VPN‑Umgebungen

Im Unternehmen wird das gleiche LDAP‑Passwort für VPN‑ und Application‑Logins verwendet. Sobald ein Angreifer das VPN‑Passwort über Phishing erlangt, kann er sich sowohl ins Netzwerk als auch in interne Anwendungen einloggen.

# Beispiel für Credential‑Reuse (falsch)
# VPN‑Passwort = Application‑Passwort
# -> Angreifer nutzt das Passwort für beide Zugriffe

Einschätzung

Zero Trust verlangt individuelle Authentifizierung pro Service. Durch den Einsatz von OAuth 2.0 oder OpenID Connect können Sie separate Token für VPN‑ und Anwendungs‑Zugriffe ausstellen, sodass ein kompromittiertes Passwort nicht die gesamte Infrastruktur gefährdet.

---

3. Praktische Umsetzung von Zero Trust – Schritt für Schritt

Erklärung

Die Einführung von Zero Trust lässt sich in fünf kompakte Phasen gliedern:

1. Asset‑Inventarisierung – Alle Geräte, Services und Datenquellen katalogisieren.
2. Mikrosegmentierung – Netzwerk‑ und Service‑Zonen definieren.
3. Identity‑Provider (IdP) integrieren – Einheitliche Authentifizierung mit MFA.
4. Policy‑Engine – Regeln für Zugriffe zentral verwalten.
5. Monitoring & Enforcement – Laufende Kontrolle und automatisierte Reaktion.

Beispiel 3 – Zero‑Trust‑Aufbau mit HashiCorp Boundary und Vault

Hier ein komplettes Minimalbeispiel, das einen Secure Access für SSH über Boundary erzeugt, während Vault die dynamischen Credentials bereitstellt.

# 1. Vault starten (Docker)
docker run -d --name vault -p 8200:8200 -e 'VAULT_DEV_ROOT_TOKEN_ID=root' vault server

# 2. Vault initialisieren und dynamische DB‑Credentials anlegen
export VAULT_ADDR='http://127.0.0.1:8200'
vault login root
vault secrets enable database
vault write database/config/my-postgres \
    plugin_name=postgresql-database-plugin \
    connection_url='postgresql://{{username}}:{{password}}@db.example.com:5432/postgres?sslmode=disable' \
    allowed_roles='readonly'

# 3. Rolle für read‑only Users erstellen
vault write database/roles/readonly \
    db_name=my-postgres \
    creation_statements='SELECT * FROM users;' \
    default_ttl=1h max_ttl=24h

# 4. Boundary starten (Docker)
docker run -d --name boundary -p 9200:9200 -e 'BOUNDARY_HOST=0.0.0.0' hashicorp/boundary server

# 5. Boundary Worker (SSH‑Target) konfigurieren
boundary workers create -type=ssh -scope-id=global -address=ssh.example.com:22

# 6. Access‑Grant mit Vault‑Credentials über Boundary
boundary sessions create -target-id=ssh-target-id -grant-type=authorized-user -user=alice

Durch dieses Setup erhält Alice bei jeder Session ein frisches PostgreSQL‑Passwort, das nach einer Stunde verfällt. Selbst wenn ein Angreifer das Passwort ausspioniert, ist es nach kurzer Zeit wertlos.

Einschätzung

Dieses Beispiel demonstriert, wie dynamische Secrets und Identity‑Driven Access zusammen ein wesentlich stärkeres Sicherheitsmodell ergeben, als ein statisches VPN‑Passwort je könnte. Der Aufwand ist überschaubar, weil beide Produkte (Vault & Boundary) über native Docker‑Images verfügen und sich über das CLI schnell konfigurieren lassen.

Beispiel 4 – Mikrosegmentierung mit Calico in einem Kubernetes‑Cluster

Für Unternehmen, die bereits Kubernetes nutzen, ist Calico eine schlanke Möglichkeit, Netzwerkpolicies auf Ebene von Pods zu definieren.

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  selector: all()
  types:
  - Ingress
  - Egress
  ingress: []
  egress: []
---
apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  selector: app == "backend"
  inbound:
  - action: Allow
    source:
      selector: app == "frontend"
    protocol: TCP
    destination:
      ports: [8080]

Damit wird alle Kommunikation zwischen Pods blockiert, bis eine explizite Policy (z. B. Frontend → Backend) definiert wird. Das entspricht dem Zero‑Trust‑Prinzip: standard deny, explicit allow.

Einschätzung

Calico‑Policies lassen sich automatisiert aus CI/CD‑Pipelines heraus pflegen, wodurch sie immer im gleichen Releasestatus wie Ihre Anwendung stehen. So vermeiden Sie die Gefahr von „verwaisten“ Regeln, die im Laufe der Zeit Sicherheitslücken öffnen.

---

Häufige Fehler bei der Einführung von Zero Trust

1. „Zero Trust = Zero Access“ – Manche Unternehmen blockieren zu schnell alles und vergessen, legitime Anwendungsfälle zu berücksichtigen. Verwenden Sie Policy‑Testing‑Tools wie kuttl für Kubernetes, um Regeln zu simulieren, bevor Sie sie produktiv schalten.
2. Einmal‑Konfiguration – Zero Trust ist kein „Set‑and‑Forget“. Prozesse müssen kontinuierlich angepasst werden, wenn neue Services hinzukommen.
3. Mangelnde Sichtbarkeit – Ohne zentrales Monitoring (z. B. Grafana + Prometheus + OpenTelemetry) fehlt das Feedback, ob Ihre Policies wirksam sind. Setzen Sie Alert‑Rules für ungewöhnliche Lateral‑Movement‑Muster.
4. Kein Device‑Posture‑Check – Das Gerät muss ebenfalls geprüft werden (OS‑Patch‑Level, Antivirus‑Status). Tools wie Microsoft Defender for Endpoint oder OSQuery können hier automatisiert integriert werden.
5. Übermäßige Komplexität – Zu viele feine-grained Policies können das Netzwerk lähmen. Beginnen Sie mit einem „High‑Level“-Modell und verfeinern Sie nach Bedarf.

---

Fazit und konkreter nächster Schritt

Zero Trust ist keine Zukunfts‑Vision, sondern ein praktikabler, sofort umsetzbarer Ansatz. Durch Mikrosegmentierung, dynamische Secrets und per‑Request‑Authentifizierung schließen Sie die größten Lücken, die klassische VPN‑Modelle offenlassen. Der Schlüssel zum Erfolg liegt in iterativer Umsetzung: Starten Sie klein, messen Sie, passen Sie an und erweitern Sie das Modell schrittweise.

Ihr nächster Schritt:

1. Erstellen Sie ein Inventory‑Sheet aller Services (z. B. in einem Google‑Sheet).
2. Installieren Sie istioctl oder calico in einem Test‑Namespace.
3. Definieren Sie eine erste deny‑all‑Policy und öffnen Sie exklusiv den Zugang zu einem einzigen Service.
4. Integrieren Sie Ihren IdP (Okta, Keycloak) mit MFA und testen Sie den Zugriff über Boundary.
5. Setzen Sie ein Monitoring‑Dashboard (Grafana + Prometheus) auf, um alle Access‑Versuche zu visualisieren.

Bleiben Sie dran – Zero Trust ist ein laufendes Projekt, nicht ein einmaliges Deployment. Wenn Sie die genannten Schritte konsequent umsetzen, werden Sie schnell merken, dass Ihr Netzwerk nicht nur sicherer, sondern auch transparent und kontrollierbar wird.

Viel Erfolg beim ersten Schritt Richtung Zero Trust!