Viele Unternehmen sind historisch mit einem simplen Modell gewachsen: Wer im Firmennetz ist (oder per VPN verbunden), gilt als „vertrauenswürdig“. In modernen Cloud- und Hybrid-Umgebungen funktioniert dieses Prinzip immer schlechter. Apps liegen verteilt, Geräte sind mobil, Identitäten sind das neue Perimeter – und Angreifer zielen genau darauf. Deshalb setzen immer mehr Teams auf Zero Trust: Zugriff wird nicht pauschal gewährt, sondern pro Anfrage geprüft – basierend auf Identität, Gerät, Kontext und Risiko.
Warum das klassische VPN-Modell bröckelt
VPN war dafür gedacht, einen „Tunnel“ ins interne Netz zu bauen. Das Problem: Sobald ein Gerät drin ist, hat es oft zu viel Sicht und zu viele Möglichkeiten. Bei kompromittierten Accounts oder Endgeräten wird VPN schnell zum Sprungbrett für laterale Bewegung.
- Zu breiter Zugriff: ein Login öffnet oft mehr als nötig.
- Schwache Geräte-Signale: VPN prüft selten, ob ein Gerät gesund/managed ist.
- Cloud-Realität: viele Systeme sind ohnehin nicht „im LAN“, sondern SaaS oder public cloud.
- Angriffsfläche: VPN-Gateways sind ein prominentes Ziel für Exploits und Credential-Stuffing.
Was Zero Trust wirklich bedeutet
Zero Trust ist kein Produkt, sondern ein Sicherheitsmodell: „Never trust, always verify“. Jede Zugriffsanfrage wird bewertet – z. B. anhand von:
- Identität: wer ist es? (SSO, MFA/Passkeys, Rollen)
- Gerätezustand: managed? verschlüsselt? aktueller Patch-Stand?
- Kontext: Standort/Region, Uhrzeit, Risiko-Signale, Netzwerk.
- Ressource: welche App, welche Datenklasse, welcher Admin-Level?
- Verhalten: ist das Muster normal oder auffällig?
Zero Trust ersetzt „im Netz = vertraut“ durch „jede Anfrage muss sich verdienen“.
Die Bausteine, die sich in der Praxis durchsetzen
1) Identity als Perimeter
SSO ist die Basis, MFA/Passkeys der nächste Schritt. Besonders wichtig: starke Policies für Admins, Schutz von Recovery-Mechanismen und klare Rollenmodelle.
2) Device Trust
Viele Unternehmen erlauben Zugriff auf sensible Systeme nur von verwalteten Geräten (MDM/Endpoint-Management), mit Verschlüsselung und Compliance-Signalen. Das reduziert Risiko durch private oder kompromittierte Geräte.
3) Least Privilege & Segmentierung
Statt „ein VPN und alles sichtbar“ werden Zugriffe feingranular: pro App, pro Rolle, pro Umgebung (Prod vs. Dev). Segmentierung begrenzt den Schaden, wenn ein Account kompromittiert wird.
4) Continuous Verification
Risiko ist dynamisch. Deshalb werden Sessions und Tokens stärker kontrolliert: Step-up Auth für kritische Aktionen, kurze Laufzeiten, erneute Checks bei Standortwechsel oder auffälligem Verhalten.
Der typische Fehler: Zero Trust „zu groß“ starten
Viele Projekte scheitern, weil sie sofort alles umstellen wollen. Erfolgreicher ist ein iterativer Rollout: erst die kritischsten Anwendungen und privilegierten Zugriffe absichern, dann ausweiten. Häufige Reihenfolge:
- Admins & privilegierte Konten (Passkeys/Hardware-Keys, strengste Policies).
- Cloud-Console & Identity-Provider (Conditional Access, Device Trust).
- Produktionssysteme (Segmentierung, Just-in-Time Access).
- Standard-Apps (SaaS, interne Tools, Dev-Plattformen).
Fazit
Zero Trust ist eine Antwort auf eine Welt, in der Cloud, Remote-Work und Account-Angriffe normal geworden sind. VPN kann dabei weiterhin eine Rolle spielen – aber nicht als „alles oder nichts“-Schlüssel. Wer Identity, Device Trust und feinere Zugriffskontrollen kombiniert und schrittweise ausrollt, baut eine Infrastruktur, die resilienter ist – und in der ein kompromittierter Account nicht automatisch „das ganze Netz“ bedeutet.
