Bei Teams, die Cloudflare Zero Trust einführen, herrscht immer wieder Verwirrung: Sie behandeln Access und Tunnel als austauschbare Teile desselben Systems, obwohl es sich in der Praxis um Produkte mit völlig unterschiedlichen Verantwortlichkeiten handelt. Ein Techniker, der den Tunnel konfiguriert und davon ausgeht, dass die Authentifizierung gelöst ist, veröffentlicht einen privaten Dienst ohne Identitätstore. Zu verstehen, was die einzelnen Teile bewirken – und wann es sich lohnt, das eine ohne das andere zu verwenden – unterscheidet eine gut strukturierte Implementierung von einer Lücke, die nur darauf wartet, ausgenutzt zu werden.
Was Cloudflare Access macht
Access ist ein Identitäts-Proxy. Es sitzt vor einem Hostnamen – zum Beispiel app.empresa.com – und fängt jede Anfrage ab, bevor sie den Ursprung erreicht. Wenn der Benutzer keine gültige Sitzung hat, leitet Access zum konfigurierten Identitätsanbieter weiter. Nach erfolgreicher Authentifizierung wertet Access die dieser Anwendung zugeordnete Richtlinie aus: Gehört der Benutzer zur zugelassenen Gruppe? Wurde bei der Authentifizierung MFA verwendet? Ist das Gerät konform? Wenn alle Bedingungen erfüllt sind, gibt Access ein Sitzungs-JWT aus und die Anfrage geht an den Ursprung.
Die Quelle kann alles sein – ein Server mit einer öffentlichen IP, ein interner Dienst, ein Tunnel. Access ist es egal, wo sich die Quelle befindet. Er kümmert sich um jeden, der versucht, dorthin zu gelangen. Diese Unterscheidung ist wichtig, da sie bedeutet, dass Access vor Anwendungen funktioniert, die bereits über eine öffentliche IP verfügen, ohne dass ein Tunnel erforderlich ist. Wenn Sie eine Anwendung mit einer öffentlichen IP haben, die eine Zugriffskontrolle basierend auf der Unternehmensidentität benötigt, löst Access dieses Problem, ohne die Anwendung zu verschieben oder cloudflared zu installieren.
Was Cloudflare Tunnel macht
Tunnel löst ein anderes Problem: wie man einen privaten Server über das Internet erreichbar macht, ohne Gateways in der Firewall zu öffnen. Der cloudflared-Daemon, der auf dem Server oder in einem Container im selben Netzwerk installiert ist, stellt eine verschlüsselte ausgehende Verbindung zum Cloudflare-Edge her. Von dort aus fungiert Cloudflare als Vermittler – eingehender Datenverkehr erreicht den Edge und gelangt über den bereits eingerichteten Tunnel zum internen Dienst.
Das Ergebnis ist, dass der interne Server keine öffentliche IP hat, keinen offenen Port 80 oder 443 für das Internet hat und keine Eintragsregel in der Sicherheitsgruppe oder Firewall benötigt. Der einzige Datenverkehr, der eingeht, ist der, der vom cloudflared-Prozess selbst stammt, der lokal ausgeführt wird. Ein Server, der vollständig vom direkten externen Zugriff isoliert ist, ist jetzt für autorisierte Benutzer über den Cloudflare-Edge erreichbar.
cloudflared kann als systemd-Dienst, Docker-Container oder Kubernetes-Bereitstellung konfiguriert werden. Moderne Setups verwenden das Cloudflare-Dashboard zur Verwaltung des Tunnels – keine lokale YAML-Datei, mit Konfiguration, die über die API weitergegeben wird. Ein einzelner Prozess cloudflared kann mehrere Dienste auf verschiedenen Hostnamen verfügbar machen: app1.empresa.com geht lokal zu Port 3000, app2.empresa.com geht zu Port 4000, db-admin.empresa.com geht zu pgAdmin auf Port 5050.
Wann Tunnel ohne Zugriff verwendet werden sollte
Tunneln ohne Zugriff ist ein gültiges und häufiges Szenario: Sie möchten Datenverkehr von einer öffentlichen Anwendung ohne zusätzliche Authentifizierung über den Cloudflare-Edge zum DDoS- und CDN-Schutz leiten. Der Dienst ist öffentlich zugänglich, der Datenverkehr erreicht den Server jedoch nur über Cloudflare – ohne direkte Offenlegung der Ursprungs-IP. Cloudflare schützt vor volumetrischen Angriffen und der Server ist verborgen.
Andere Verwendung: gemeinsame lokale Entwicklung. Ein Entwickler möchte jemandem außerhalb des Netzwerks einen lokal ausgeführten Prototyp zeigen. cloudflared tunnel --url localhost:3000 erstellt eine öffentlich zugängliche temporäre URL ohne DNS- oder Firewall-Konfiguration. Kein Zugriff, keine Authentifizierung – aber im Einzelfall sinnvoll.
Das Risiko besteht darin, anzunehmen, dass Tunnel Schutz bedeutet. Das bedeutet nicht. Tunnel ist Konnektivität. Ohne Zugriff an der Front erreicht jede Anfrage, die den in Cloudflare konfigurierten Hostnamen erreicht, Ihren internen Dienst.
Wann sollte Access ohne Tunnel verwendet werden?
Zugriff ohne Tunnel ist sinnvoll, wenn die Quelle bereits über eine öffentliche IP verfügt – ein Server auf EC2 mit einer elastischen IP, eine Anwendung auf einem PaaS, ein API-Endpunkt mit einer öffentlichen Adresse. Access fungiert als Identitäts-Proxy vor dieser öffentlichen Adresse, ohne dass cloudflared erforderlich sind.
Das entscheidende Betriebsdetail in diesem Szenario: Der Ursprung muss nur Datenverkehr vom Cloudflare-Edge akzeptieren. Wenn der Server weiterhin Anfragen von einer beliebigen IP akzeptiert, kann der Zugriff umgangen werden, indem einfach direkt auf die IP zugegriffen wird. Die richtige Vorgehensweise besteht darin, den Server so zu konfigurieren, dass er nur Datenverkehr aus den IP-Bereichen von Cloudflare akzeptiert, oder einen authentifizierten Header zu verwenden, den Access einfügt und den die Anwendung überprüft.
Die Kombination, die wirklich Zero Trust liefert
Durch die Kombination der beiden wird das vollständige Zero-Trust-Modell umgesetzt: Der Tunnel macht den privaten Server über Cloudflare erreichbar; Der Zugriff erfordert eine Authentifizierung und Richtlinienbewertung, bevor eine Anfrage den Tunnel passieren kann. Der interne Server ist niemals direkt mit dem Internet verbunden und empfängt niemals nicht authentifizierte Anfragen.
Der Ablauf: Benutzer greift auf den Hostnamen zu → Access prüft die Sitzung, leitet bei Bedarf zum IdP weiter → nach Authentifizierung und Richtlinienprüfung leitet Access die Anfrage an den Edge weiter → Edge geht durch den Tunnel → cloudflared liefert sie an den lokalen Prozess. Der interne Server sieht nur Datenverkehr, der bereits von Access autorisiert wurde.
Für den Maschine-zu-Maschine-Zugriff – CI/CD-Pipelines, Überwachungsagenten, Integrationen – stellt Access Service-Tokens aus: eine Client-ID und ein Geheimnis, die den menschlichen SSO-Ablauf ersetzen. Der automatisierte Dienst fügt diese Token in den Anforderungsheader ein und Access erkennt sie als vertrauenswürdige Dienstidentität und wendet die zugehörige Richtlinie an. Jeder Zugriff per Service-Token generiert auch ein Audit-Ereignis.
Die Vision derjenigen, die das System entwerfen
Ein Punkt, der während der Entwurfsphase übersehen wurde: Für Tunnel fallen bei Cloudflare keine Ausstiegskosten an. Für den Datenverkehr über cloudflared wird im Team-Plan keine Bandbreitengebühr erhoben. Dies hat erhebliche Auswirkungen auf die Kosten im Vergleich zu Alternativen, die pro übertragenes GB abrechnen – und beeinflusst die Entscheidung, Cloudflare Tunnel im Vergleich zu ähnlichen Tunnellösungen zu verwenden.
Die zentrale Architekturentscheidung bei der Übernahme beider Komponenten lautet: Wo sind die Zugriffsrichtlinien? Mit Access können Sie granulare Richtlinien pro Anwendung erstellen – eine Gruppe hat Zugriff auf das Admin-Panel, eine andere hat nur Lesezugriff auf die Überwachung, externe Mitarbeiter greifen nur auf das Dokumentationsportal zu. Diese Granularität gibt es bei herkömmlichen VPNs nicht. Die Kosten für die Aufrechterhaltung dieser Granularität entstehen durch die fortlaufende Verwaltung von Richtlinien, wenn sich Teams ändern und Anwendungen weiterentwickeln. Die Automatisierung über Terraform oder die API von Cloudflare ist der Schritt, der die Zugriffsverwaltung von einer manuellen Aufgabe in einen kontrollierten Prozess verwandelt.