Durch das Definieren von genau auf die jeweilige Anwendung, den jeweiligen Nutzer und das jeweilige Geräte abgestimmten Kontrollen und Autorisierungsrichtlinien wird das Fundament für Zero Trust geschaffen. Damit die Vorschriften und Sicherheitsvorgaben eingehalten werden können, muss ein System über ausreichend umfangreiche Möglichkeiten zur Feinabstimmung verfügen. Eine große Zahl von Kontrollen hat unter Umständen aber einen Haken: Um Nutzerprobleme zu beheben, muss ein Administrator eine komplexe Kombination von Variablen in Bezug auf Anwendungen, Nutzeridentität und Geräteinformationen berücksichtigen. Das kann bedeuten, dass Protokolle sorgfältig überprüft werden müssen.
Unserer Meinung nach gibt es dafür aber einen besseren Weg. Ab heute können Administratoren alle aktiven Nutzersitzungen und die damit verbundenen Daten, die von ihren Cloudflare One-Richtlinien verwendet werden, einfach kontrollieren. Dadurch erhält man das Beste aus beiden Welten: extrem fein justierte Kontrollen und gleichzeitig verbesserte Fehlerbehebungs- und Diagnosemöglichkeiten für Zero Trust-Implementierungen mit einer einzigen, einfachen Steuerungsebene. Damit können Administratoren nun auf Informationen zugreifen, die zuvor im Browser des Nutzers gespeichert wurden oder sich dynamisch geändert haben, ohne einen Endnutzer zu belästigen oder Protokolle durchforsten zu müssen.
Eine kurze Einführung in die Authentifizierung und Autorisierung bei Anwendungen
Authentifizierung und Autorisierung sind die beiden Komponenten, die von einer Zero Trust-Richtlinie ausgewertet werden, bevor diese einem Nutzer den Zugriff auf eine Ressource erlaubt.
Bei der Authentifizierung wird die Identität eines Nutzers, eines Geräts oder eines Systems überprüft. Zu den üblichen Authentifizierungsmethoden gehören die Eingabe von Benutzernamen und Kennwörtern, die Vorlage eines digitalen Zertifikats oder sogar biometrischer Daten wie Fingerabdrücke oder Gesichtsscans. Bei der Multi-Faktor-Authentifizierung (MFA) werden zwei oder mehr separate Authentifizierungsmethoden vorgeschrieben, um die Sicherheit zu erhöhen, z. B. ein Security-Token in Kombination mit einem Passwort.
Unter Autorisierung versteht man das Gewähren oder Verweigern des Zugriffs auf bestimmte Ressourcen oder der erforderlichen Berechtigungen nach erfolgreicher Authentifizierung. Dabei wird festgelegt, was die authentifizierte Einheit innerhalb des Systems tun darf und was nicht.
Mechanismen der Authentifizierung/Autorisierung bei Anwendungen
Im Fall von Webanwendungen, auf die hier der Fokus gelegt werden soll, werden im Allgemeinen HTTP-Cookies zur Durchführung sowohl der Authentifizierung als auch der Autorisierung verwendet.
Authentifizierung:
- Login: Meldet sich ein User bei einer Webanwendung durch Eingabe seines Benutzernamens und seines Kennworts an, gleicht die Applikation diese Anmeldedaten mit ihrer Datenbank oder einem Identitätsanbieter (IdP) ab. Bei der Authentifizierung können auch zusätzliche Faktoren einbezogen werden. Wird eine Übereinstimmung festgestellt, erachtet der Server oder der externe Sicherheitsdienst (z. B. Cloudflare Access) den Nutzer als authentifiziert.
- Cookie/Token-Erstellung: Der Server erstellt dann eine Sitzung für den Nutzer in Form eines Cookies oder JSON-Web-Token. Das Cookie ist für einen bestimmten Zeitraum gültig, nach dessen Ablauf sich der Nutzer erneut authentifizieren muss.
- Senden und Speichern von Cookies: Der Server sendet eine Antwort an den Browser des Nutzers zurück, die die Sitzungs-ID und andere identifizierende Informationen zu dem Nutzer in dem Cookie enthält. Der Browser speichert dann dieses Cookie. Damit kann der Nutzer bei weiteren Anfragen wiedererkannt werden.
Autorisierung:
- Folgende Anfragen: Bei allen folgenden Anfragen an die Webanwendung fügt der Browser des Nutzers automatisch das Cookie (mit der Sitzungs-ID und anderen identifizierenden Informationen) in die Anfrage ein.
- Serverseitige Verifizierung: Der Server erhält die Nutzerdaten aus dem Cookie und prüft, ob die Sitzung gültig ist. Ist das der Fall, ruft er auch die Nutzerdaten und die mit der Sitzungs-ID verbundenen Zugriffsberechtigungen ab.
- Berechtigungsentscheidung: Auf Grundlage der Zugriffsberechtigungen des Nutzers entscheidet der Server, ob der Nutzer berechtigt ist, die angeforderte Operation durchzuführen oder auf die angeforderte Ressource zuzugreifen.
So bleibt die Authentifizierung des Nutzers bei allen folgenden Anfragen bestehen (und seine Berechtigung kann überprüft werden), bis die Sitzung abläuft oder er sich ausloggt.
In modernen Webanwendungen wird dieser Sitzungsstatus in der Regel in Form eines JSON-Web-Token (JWT) gespeichert.
Fehlersuche bei JWT-basierter Authentifizierung
JWT werden in vielen modernen Webanwendungen und Zero Trust Network Access (ZTNA)-Lösungen wie Cloudflare Access zur Authentifizierung und Autorisierung verwendet. Ein JWT enthält eine Payload, also Informationen zu dem Nutzer und möglicherweise andere Daten in verschlüsselter Form, und wird vom Server signiert, um Manipulationen zu verhindern. JWT werden häufig zustandslos verwendet, d. h. der Server speichert keine Kopie sämtlicher JWT, sondern verifiziert und entschlüsselt einfach jedes JWT, das mit Anfragen eintrifft. Aufgrund ihrer Zustandslosigkeit sind JWT für die Verwaltung von Nutzersitzungen nicht auf ein zentrales System angewiesen, wodurch Skalierungsprobleme vermieden werden, wenn die Zahl der auf ein System zugreifenden Nutzer steigt.
Allerdings erschwert die gleiche Eigenschaft die Fehlersuche bei der JWT-basierten Authentifizierung, wenn man nicht das spezifische JWT eines Nutzers erhält. Das hat folgende Gründe:
1. Spezifität des Token: Jedes JWT ist spezifisch für einen Nutzer und eine Sitzung. Es enthält Informationen (Behauptungen) bezüglich des Nutzers, der ausstellenden Instanz, der Ausstellungszeit des Token, der Ablaufzeit und möglicherweise weitere Daten. Um ein Problem beheben zu können, wird deshalb oft genau das JWT benötigt, das es verursacht.
2. Keine serverseitigen Aufzeichnungen: Da JWT zustandslos sind, werden Sitzungen vom Server standardmäßig nicht gespeichert. Er kann keine früheren Token oder deren zugehörigen Status zum Abgleich abrufen – es sei denn, er wurde speziell dafür entwickelt, sie zu protokollieren, was aus Gründen des Datenschutzes und der Datenminimierung normalerweise nicht der Fall ist.
3. Vorübergehende Probleme: JWT-Probleme treten unter Umständen nur vorübergehend auf und hängen daher möglicherweise mit dem spezifischen Zeitpunkt zusammen, zu dem das Token verwendet wurde. Wenn beispielsweise ein Token abgelaufen war, als ein Nutzer versucht hat, es zu verwenden, benötigt man genau dieses Token zur Behebung des Problems.
4. Datenschutz und Sicherheit: JWT können sensible Informationen enthalten, deshalb sollte man damit sorgfältig umgehen. Erhält man ein JWT von einem Nutzer, werden dabei eventuell dessen personenbezogene Informationen oder Sicherheitsdaten demjenigen offengelegt, der das Problem behebt. Wenn ein Nutzer sein JWT auf unsicherem Weg an einen Entwickler oder ein IT-Helpdesk sendet, könnte es außerdem abgefangen werden. (Cloudflare hat kürzlich das kostenlose Tool HAR Sanitizer auf den Markt gebracht, um das zu verhindern.)
Diese Faktoren erschweren die Fehlersuche bei Problemen mit JWT-basierter Authentifizierung, wenn man keinen Zugriff auf das fragliche Token hat.
Eine bessere Methode zur Fehlerbehebung bei Problemen mit der Identitätsüberprüfung
Wir haben uns vorgenommen, eine bessere Lösung für Probleme im Zusammenhang mit der Nutzeridentität bei Cloudflare Zero Trust anzubieten, für die keine JWT oder HAR-Dateien hin und her geschickt werden müssen. Administratoren können sich jetzt die Registry-Identität eines Nutzers (die für Gateway-Richtlinien verwendet wird) und alle aktiven Access-Sitzungen anzeigen lassen.
Diese Sitzungsinformationen umfassen die vollständige Identität, die von unserer Zero Trust-Lösung ausgewertet wird, einschließlich Identitätsanbieter-Anforderungen, Informationen zum Gerätestatus, Netzwerkkontext und mehr. Durch die Verwendung von Cloudflare Workers KV ist es uns gelungen, diese Funktion ohne zusätzliche Belastung der Authentifizierungslogik von Access zu entwickeln. Wenn sich ein Nutzer bei Access authentifiziert, wird die zugehörige Identität sofort in einem Schlüssel-Wert-Paar in Workers KV gespeichert. Dies geschieht alles im Kontext des Ereignisses der Nutzerauthentifizierung, sodass die Auswirkungen auf die Latenz oder die Abhängigkeit von einem externen Dienst minimal sind.
Diese Funktion ist für alle Kunden und sämtliche Zero Trust-Tarife verfügbar. Wenn Sie mit Cloudflare Zero Trust loslegen möchten, melden Sie sich noch heute für ein kostenloses Konto an, das von bis zu 50 Nutzern verwendet werden kann. Oder arbeiten Sie mit Cloudflare-Experten zusammen, um über eine SSE- oder SASE-Lösung für Ihr Unternehmen zu sprechen und Ihre Zero Trust-Anwendungsfälle Schritt für Schritt anzugehen.