Cloudflare Zero Trust: Zugriff auf interne Anwendungen ohne VPN

Das Unternehmens-VPN ist nicht an der schlechten Implementierung gescheitert. Es scheiterte, weil es auf einer Prämisse basierte, die nicht mehr zutrifft: dass es ausreicht, im Netzwerk des Unternehmens zu sein, um jemandem zu vertrauen. Wenn sich ein Mitarbeiter von zu Hause, einem Hotelnetzwerk oder einem Café mit demselben VPN wie das Büroteam verbindet, ist der Netzwerkperimeter als Sicherheitskonzept nicht mehr vorhanden. Was bleibt, ist eine Illusion von Kontrolle, die durch betriebliche Trägheit gestützt wird.

Cloudflare Zero Trust geht von einer anderen Prämisse aus: Identität, Gerät und Anfragekontext bestimmen den Zugriff – nicht die ursprüngliche IP-Adresse. Die konkrete Umsetzung davon umfasst drei Komponenten, die unterschiedliche Rollen haben und selbst von denen, die sie bereits in Produktion gebracht haben, oft verwechselt werden.

Access, Tunnel und WARP: was jeder einzelne tut

Cloudflare Access ist ein Identitäts-Gateway für Anwendungen. Wenn eine Anfrage bei der über Cloudflare veröffentlichten internen Domäne eintrifft, fängt Access sie ab, bevor die Anfrage den Ursprung erreicht. Der Benutzer authentifiziert sich beim konfigurierten Identitätsanbieter – Okta, Azure AD, Google Workspace oder einem beliebigen SAML 2.0- und OIDC-Anbieter. Erst nach Authentifizierung und Richtlinienauswertung wird der Datenverkehr zum Ursprung weitergeleitet. Die Anwendung erhält niemals eine nicht authentifizierte Anfrage.

Cloudflare Tunnel, der vom cloudflared-Daemon ausgeführt wird, arbeitet auf der Serverseite. Es erstellt eine verschlüsselte ausgehende Verbindung vom Server zum Cloudflare-Edge, ohne eingehende Firewall-Ports zu öffnen. Der vollständige Ablauf: Benutzer authentifiziert sich über Access → Cloudflare-Edge-Validierung → Datenverkehr gelangt über den Tunnel zum internen Dienst. Der interne Server benötigt keine öffentliche IP, keine Sicherheitsgruppeneintragsregel und ist nicht direkt dem Internet ausgesetzt.

WARP ist der Geräte-Client. Im Zero-Trust-Modus leitet es den Geräteverkehr über das WireGuard-Protokoll über den Cloudflare-Edge. Dies ermöglicht Statusprüfungen – Festplattenverschlüsselung, Betriebssystemversion, installierter Sicherheitsagent – und ermöglicht es Zugriffsrichtlinien, den Gerätestatus als Bedingung einzubeziehen. Für Webanwendungen, auf die über den Browser zugegriffen wird, ist WARP häufig nicht erforderlich. Für Nicht-HTTP-Protokolle wie SSH und RDP, die über den Tunnel geroutet werden, ist dies obligatorisch.

So funktioniert der Authentifizierungsablauf

Der konkrete Ablauf für einen Entwickler, der auf einen internen Dienst zugreift: Der Benutzer greift auf app.empresa.com zu. Access erkennt, dass keine gültige Sitzung vorliegt und leitet zum Identitätsanbieter weiter. Benutzer authentifiziert sich – mit MFA, wenn die Richtlinien dies erfordern. Der IdP kehrt mit bestätigten Identitäts- und Gruppenattributen zu Access zurück. Access wertet die Richtlinie aus: Gehört dieser Benutzer zu der Gruppe mit Berechtigungen für diese App? Bei Genehmigung wird ein Sitzungs-JWT ausgegeben, und die Anforderung wird an den Rand weitergeleitet und durch den Tunnel zum Dienst im internen Netzwerk weitergeleitet.

Bei Nicht-HTTP-Protokollen – zum Beispiel SSH – läuft der Stream über WARP. Der Kunde richtet den WireGuard-Tunnel ein, die Statusrichtlinie wird überprüft und der SSH-Verkehr wird über Cloudflare über den Tunnel zum Ziel weitergeleitet.

Identität und unterstützte Anbieter

Access unterstützt mehrere Identitätsanbieter gleichzeitig in derselben Organisation. Eine Anwendung kann die Authentifizierung über Google Workspace für Mitarbeiter und über GitHub für externe Mitarbeiter ermöglichen. Ein anderer erfordert möglicherweise ausschließlich Okta mit obligatorischer MFA. Synchronisierte IdP-Gruppen – Technikteams, bestimmte Trupps, Abteilungen – geben Zugriffsrichtlinien direkt ein, ohne manuelle Synchronisierung von Listen.

Zusätzlich zum Menschen verwaltet Access den Zugriff von Maschine zu Maschine über Service-Token. Einer CI/CD-Pipeline, die einen authentifizierten internen Endpunkt erreichen muss, werden eine Client-ID und ein Geheimnis zugewiesen, die den menschlichen SSO-Ablauf ersetzen. Jeder Zugriff, ob menschlich oder automatisiert, generiert ein Audit-Ereignis mit Identität, Zeitstempel, IP, Gerät und getroffener Entscheidung – exportierbar über Logpush nach SIEM, Splunk oder Datadog.

Was Zero Trust nicht kann

Cloudflare Zero Trust kontrolliert, wer was erhält, ist jedoch keine Lösung für die Verschlüsselung von Daten während der Übertragung innerhalb der Anwendung – die Verantwortung dafür bleibt über HTTPS bei der Anwendung selbst. Der Zugriff ersetzt auch nicht eine Firewall für den Ost-West-Verkehr zwischen Diensten innerhalb des Rechenzentrums oder der VPC. Für die interne Kommunikation zwischen Microservices bleibt mTLS oder Service Mesh der geeignete Mechanismus.

Ein Punkt, der bei ersten Implementierungen übersehen wird: Der Tunnel schützt den Pfad zwischen dem Cloudflare-Edge und dem Ursprungsserver, aber der Server muss weiterhin nur Verbindungen vertrauen, die über cloudflared kommen. Wenn Port 443 außerhalb des Tunnels für das Internet geöffnet ist, kann der Zugriff umgangen werden. Die richtige Vorgehensweise besteht darin, den gesamten eingehenden Datenverkehr zum Server zu blockieren, mit Ausnahme des Datenverkehrs, der vom lokalen Tunnel-Daemon generiert wird.

Was sich durch die Einführung operativ ändert

Die bedeutendste Änderung ist nicht technischer Natur – sie ist das mentale Modell dessen, wer den Zugriff verwaltet. Bei VPN konfiguriert das Netzwerkteam Routen und Split-Tunnel; Bei Zero Trust konfiguriert das Identitätsteam Richtlinien pro Anwendung. Die Zugriffsverwaltung verlässt die Netzwerkebene und betritt die Identitätsebene. Für Organisationen mit separaten Netzwerk- und Sicherheitsteams bedeutet dies, die Verantwortung auszuhandeln.

Das kostenlose Kontingent – bis zu 50 Benutzer mit Access, Tunnel, WARP und Basis-Gateway – reicht für die Produktionsvalidierung aus. Der Team-Plan kostet 7 US-Dollar pro Benutzer und Monat und fügt Audit-Protokolle und Gateway mit HTTP-Filterung hinzu. Enterprise bietet zusätzlich Browser-Isolation, DLP und E-Mail-Sicherheit zu ausgehandelten Preisen. Bei Teams mit mehr als 50 Benutzern, die bereits Okta oder Azure AD konsolidiert haben, übersteigt der Bereitstellungsaufwand selten vier Wochen tatsächlicher Arbeit.

Was Sie vor der Migration bewerten sollten

Bei der Entscheidung, auf Zero Trust umzusteigen, geht es nicht um die Technologie – es geht darum, wo heute das größte Sicherheitsrisiko liegt. Wenn Ihr aktuelles VPN nach der Authentifizierung weitreichenden Netzwerkzugriff gewährt, wird durch kompromittierte Anmeldeinformationen das gesamte interne Netzwerk offengelegt. Zero Trust begrenzt den Explosionsradius: Der gefährdete Zugriff erreicht nur die explizit für diese Identität zugelassenen Anwendungen, wobei der Gerätestatus als zusätzliche Kontrolle dient.

Beginnen Sie mit der Anwendung mit dem höchsten Gefährdungsrisiko und den höchsten Kosten im Falle einer Leckage. Durch die erste Migration mit gruppenbeschränkter Richtlinie und obligatorischem Gerätestatus wird das gesamte Modell in der Produktion mit kontrollierbaren Auswirkungen validiert. Das dort getestete Muster wird für den Rest des Portfolios repliziert.