Die technische Integration zwischen Cloudflare Access und einem Unternehmensidentitätsanbieter dauert in den meisten Fällen weniger als eine Stunde – Austausch von Metadaten, ein paar URLs, Authentifizierungstests. Was Wochen dauert, kommt als nächstes: Die Entscheidung, welche Gruppen Zugriff auf welche Anwendungen haben, mit welcher Sitzungsdauer, mit welchen MFA-Anforderungen und was mit externen Mitarbeitern auf einem anderen IdP geschehen soll. Die Protokollkonfiguration ist ein Dokumentationsdetail. Politische Architektur ist eine Entwurfsentscheidung.
SAML, OIDC und worauf es bei der Auswahl ankommt
Cloudflare Access unterstützt sowohl SAML 2.0 als auch OIDC. Für größere Unternehmensanbieter – Okta, Azure AD, Google Workspace, OneLogin, Ping Identity, JumpCloud – unterhält Cloudflare Integrationsleitfäden mit genauer Feldzuordnung. Die Wahl zwischen SAML und OIDC ist selten eine kritische technische Entscheidung; Beide funktionieren gleichermaßen für den Anwendungsfall der Zugriffsauthentifizierung.
Der praktische Unterschied besteht darin, dass OIDC für moderne Anbieter einfacher zu konfigurieren ist und Attribute direkt im JWT-Format zurückgibt. SAML erfordert eine Attributzuordnung im XML-Assertionsformat, was bei komplexeren Konfigurationen zu Problemen führt – insbesondere, wenn Sie benutzerdefinierte Attribute vom IdP zur Verwendung in Richtlinien übergeben möchten. Für neue Integrationen mit Okta oder Azure AD ist OIDC der Weg des geringsten Widerstands.
Mehrere Identitätsanbieter gleichzeitig
Eine Access-Fähigkeit, die in ersten Projekten unbemerkt bleibt: Die gleiche Organisation kann mehrere Anbieter konfigurieren und verschiedene Anbieter unterschiedlichen Anwendungen zuweisen. Eine Anwendung akzeptiert die Authentifizierung über Google Workspace für Mitarbeiter und über GitHub für externe Mitarbeiter. Ein anderer beschränkt sich ausschließlich auf Unternehmens-Okta. Ein drittes zeigt das Auswahlmenü an, in dem der Benutzer auswählen kann, welchen Anbieter er verwenden möchte.
Dies löst das häufige Szenario von Unternehmen mit Mitarbeitern in verschiedenen Partnerunternehmen, die jeweils über ein eigenes Azure AD oder Google Workspace verfügen. Anstatt Gastkonten bei allen Anbietern zu erstellen, akzeptiert Access mehrere Anbieter mit unterschiedlichen Richtlinien pro Anbieter. Die praktische Grenze ist nicht technischer Natur – sie liegt in der Verwaltung: Jeder zusätzliche Anbieter ist ein zu verwaltender Konfigurationspunkt und ein zu überwachender Zugriffsvektor.
Gruppen- und Berechtigungssynchronisierung
Zugriffsrichtlinien, die auf Gruppen verweisen, ziehen die Mitgliedschaft zum Zeitpunkt der Authentifizierung direkt vom IdP ab. Eine „Allow: Group Engineering“-Richtlinie ist keine statische Liste in Cloudflare – es handelt sich um eine Prüfung anhand der Gruppe in Okta oder Azure AD zum Zeitpunkt des Eintreffens des Authentifizierungstokens. Wenn ein Mitarbeiter der Gruppe auf dem IdP hinzugefügt oder daraus entfernt wird, tritt die Auswirkung sofort bei der nächsten Authentifizierung ein, ohne dass eine manuelle Synchronisierung auf der Cloudflare-Plattform erforderlich ist.
Dies hat eine wichtige betriebliche Konsequenz: Der Offboarding-Prozess muss den Benutzer vom IdP entfernen und nicht nur den Zugriff in jeder einzelnen Anwendung widerrufen. Wenn der Benutzer in Okta deaktiviert wird, funktionieren alle Zugriffsrichtlinien, die von diesem IdP abhängen, für dieses Konto nicht mehr. Die aktive Sitzung bleibt gültig, bis sie abläuft. Dies unterstreicht die Bedeutung der Konfiguration geeigneter Sitzungsdauern pro Anwendung.
Sitzungsdauer und MFA-Durchsetzung pro Anwendung
Die Sitzungsdauer wird pro Anwendung in Access konfiguriert, nicht global. Für eine Innenüberwachungsanwendung mit geringer Empfindlichkeit sind sieben Tage angemessen. Für den SSH-Zugriff auf die Produktionsumgebung erfordert eine einstündige Sitzung eine häufige Neuauthentifizierung, wodurch das Zeitfenster für einen kompromittierten Token verkürzt wird. Für ein Datenbankverwaltungspanel sind 15 Minuten möglicherweise angemessener.
MFA kann auf Zugriffsebene erforderlich sein, unabhängig davon, was der IdP tut. Wenn der IdP MFA nicht standardmäßig erzwingt, erfordert die Access-Richtlinie möglicherweise die Verwendung der Zweitfaktor-Authentifizierung. Access leitet den Benutzer weiter, um MFA beim IdP durchzuführen, wenn das Token diese Garantie nicht enthält. Verschiedene Anwendungen können unterschiedliche Anforderungen an die Authentifizierungssicherung haben, ohne dass mehrere MFA-Richtlinien auf dem IdP konfiguriert werden müssen.
Service-Token für den Maschine-zu-Maschine-Zugriff
CI/CD-Pipelines, Überwachungsagenten, Webhooks – jedes automatisierte System, das auf eine zugriffsgeschützte Ressource zugreifen muss, steht vor einem Problem: Es gibt keinen menschlichen Benutzer, der den SSO-Ablauf durchläuft. Access löst dieses Problem mit Diensttoken: einem Paar aus Client-ID und geheimem Clientschlüssel, das einen Dienst als vertrauenswürdige Entität identifiziert.
Der automatisierte Dienst enthält die Client-ID im Header CF-Access-Client-Id und das Geheimnis in CF-Access-Client-Secret. Access erkennt das Service-Token, wertet die zugehörige Richtlinie aus und erlaubt oder verweigert den Zugriff – wodurch ein Audit-Ereignis wie bei jedem anderen Zugriff generiert wird. Service-Token haben ein konfigurierbares Ablaufdatum und können einzeln widerrufen werden, ohne dass sich dies auf andere Token oder Benutzer auswirkt.
So strukturieren Sie Richtlinien vor dem Anruf
Der häufigste Entwurfsfehler bei der Einführung von Access ist die Erstellung einer anwendungsspezifischen Richtlinie ohne Hierarchiemodell. Bei Dutzenden interner Anwendungen wird die Pflege individueller Richtlinien für jede einzelne zu einer erheblichen betrieblichen Belastung. Die Alternative besteht darin, wiederverwendbare Zugriffsgruppen zu definieren – „Basiszugriff für alle Mitarbeiter“, „Erweiterter Zugriff für das Engineering-Team“, „Administratorzugriff für SRE“ – und diese als Blöcke in den einzelnen Richtlinien jeder Anwendung anzuwenden.
Die Zugriffsrichtlinie einer neuen Anwendung kann eine Basisgruppe erben und bestimmte Bedingungen hinzufügen, z. B. obligatorische Gerätestatus oder Zeitbeschränkungen. Wenn das Engineering-Team wächst und eine neue Gruppe im IdP erstellt wird, wird die wiederverwendbare Gruppenrichtlinienaktualisierung in Access automatisch an alle Anwendungen weitergegeben, die darauf verweisen.
Was muss vor der Konfiguration entschieden werden?
Die technische Integration mit dem IdP ist die geringste Herausforderung. Die größte Herausforderung besteht darin, Richtlinienentscheidungen und deren Begründung zu dokumentieren, bevor Access in der Produktion aktiviert wird. Welche Anwendungen haben automatischen Zugriff für alle Mitarbeiter? Welche erfordern eine ausdrückliche Gruppengenehmigung? Wie werden externe Mitarbeiter von Partnerunternehmen behandelt? Wer hält die Gruppen im IdP an den Zugriffsrichtlinien fest?
Auf diese Fragen gibt es keine technische Antwort – es sind Entscheidungen, die das Sicherheitsteam und das Produktteam gemeinsam treffen müssen. Teams, die zum technischen Setup kommen, ohne diese Fragen beantwortet zu haben, enden oft mit sehr freizügigen Richtlinien, die das VPN-Problem mit einer Authentifizierungsebene an der Spitze reproduzieren.