Wieso braucht es ein sauberes Identity Management?

Identity Management ist immer dann relevant, wenn Individuen identifiziert werden müssen – unabhängig davon, ob Endnutzer, Administratoren oder Maschinen miteinander kommunizieren. In den letzten Jahren hat sich in diesem Kontext das Konzept “Zero Trust” etabliert. Es beschreibt eine Architektur oder Umgebung, in der grundsätzlich kein Vertrauen zwischen zwei (oder mehr) Entitäten besteht. So wird eine durchgehende Sicherheit gewährleistet [1], da jede durchgeführte Aktion vorher authentifiziert wird.

Eine Zero-Trust-Umgebung stellt also die grundsätzliche Anforderung, zu jedem Zeitpunkt zu wissen:

• • Wer, also welche Systeme oder User kommunizieren?
  • Warum, also in welchem Kontext (Nutzerinteraktion, Batch-Job, administrative Aktion) wird kommuniziert?

Warum ist das notwendig? Klassischerweise erlaubt Software es Usern, sich direkt einzuloggen. Im Enterprise-Umfeld wird beispielsweise oft ein Active Directory (mithilfe des LDAP-Protokolls) angebunden, um Mitarbeiter zentral zu verwalten.[2]

Rechte- und Rollenmanagement finden aber oft in der Applikation selbst statt, und der Mitarbeiter gewöhnt sich daran, überall sein Passwort einzugeben.

Hinzu kommt, dass Serversysteme mit statischen Keys provisioniert werden, und dass für die Administration von Systemen, in denen auch Kunden unterwegs sind, oft auf eine Anbindung an interne Directory Server verzichtet wird, um Security Controls zur Netzwerksegmentierung einzuhalten.

Moderne IT-Projekte setzen häufig auf verteilte, stateless Microservices und bestehen aus vielen individuellen Komponenten, die von unterschiedlichen Teams entwickelt wurden. Gerade in moderner IT-Infrastruktur ist es daher notwendig, die Fragen nach Wer und Warum der Zugriffe zu jedem Zeitpunkt beantworten zu können, um Security Controls zu implementieren und mögliche Angriffe verhindern. Sauberes Identity Management hilft zudem, zentral Zugriffe zu entziehen, und verhindert so das Karteileichen existieren.

Was ist OpenID Connect und OAuth2.0?

Identitäten zentral verwalten – das erfordert ein modernes Protokoll zur Identifizierung von Nutzern. In den letzten Jahren hat sich OAuth2.0 bewährt, um Zugriffstokens (Access Tokens) auszustellen. Da OAuth aber keine Identifizierung mitbringt, wurde OpenID Connect als Erweiterung entworfen: Es legt einen “Userinfo”-Endpunkt fest und führt ein ID-Token ein, das maschinenlesbar Identitätsinformationen vorhält und kryptografisch abgesichert wird.[3]

Ursprünglich war OAuth nicht primär zur Identifizierung der Endnutzer konzipiert, sondern sollte die Interaktion der Access Tokens mit dem ausstellenden System ermöglichen. Daher gibt es auch keine Spezifizierung, wie ein Access Token auszusehen hat, und wie dieser zu verarbeiten ist. (Ausblick: In OAuth 2.1 wird der Access Token ein JWT, also ein maschinenlesbares JSON Web Token, werden, analog zum ID-Token, das bereits ein JWT ist.[4])

Propagating Identity:

Wenn Systeme miteinander Kommunizieren ist es wichtig die Identität des aufrufenden weiterzugeben. So muss auch ein Backend System, das in einer Aufruf-Kette weit hinten steht, wissen, welche Berechtigungen der User hat der aktuell die Funktionsaufrufe in dem System auslöst und mit dem System arbeitet.

Generell sieht der Ablauf so aus:

1. Ein User ruft eine Applikation, bzw. ein Applikationsfrontend, auf.
2. Die Applikation hat keinen Token/keine Session des Users, und leitet diesen an den OpenID Connect Server weiter.
3. Der OpenID Connect Server stellt die Identität fest. Hierzu können Benutzername und Passwort, aber auch Zertifikate, Active Directory, 2-Factor oder biometrische Informationen genutzt werden.
4. Der OpenID Connect Server schickt den User zurück zur Applikation – mit einem One-Time-Token, das an die Applikation übermittelt wird.
5. Mithilfe dieses One-Time-Tokens kann der Applikationsserver nun einen Identity Token abrufen, der die Identität des End Users kodiert und verifizierbar macht.

Im einfachsten Fall hat der Applikationsserver jetzt die Information, um welchen User es sich handelt, und weiß, dass die Verbindung aus einem öffentlichen Netz kommt, dem Client also nicht vertraut wird.

Zurück zu den Anforderungen einer Zero-Trust-Umgebung:

• • Wer? Ein unauthentifizierter Client über das Internet …
  • Warum? … spricht im Kontext eines Users, der sich über den IDP Identifiziert hat.

Jetzt kann der Server dem Nutzer die zur Verfügung stehenden Operation, Aktionen etc. anbieten. Es muss aber sichergestellt werden, dass diese Fragen auch dann weiterhin beantwortet werden können, wenn der Applikationsserver mit einem oder mehreren Backend-Systemen kommuniziert.

Wird also im Zuge einer Benutzerinteraktion ein Request gegen ein Backend-System ausgelöst, z.B. weil der Benutzer sich seinen Warenkorb anzeigen lassen möchte, muss sichergestellt werden, dass zum einen die Benutzeridentität kommuniziert wird (da der Warenkorb nur für den Besitzer anzuzeigen ist) und dass der korrekte Applikationsserver diesen Zugriff durchführt.

Das Weiterleiten des ID-Tokens ist also nicht ausreichend, da zwar der Kontext (User Identität) bekannt ist, aber noch nicht das aufrufende System.

Um die Identität des aufrufenden Systems zu prüfen, gibt es mehrere Mechanismen:

• • Anhand von Netzwerk-Policies kann geprüft werden, ob IP-Adressen, Ports etc. korrekt sind. Die große Schwierigkeit ist, dass gerade in dynamischen Umgebungen wie Kubernetes diese Merkmale hoch volatil und schwer zu verifizieren sind.
  • Mithilfe von eigenen Tokens für die Applikationen lässt sich eine einseitige Authentifizierung durchführen, es wird also an einem System bewiesen, dass ein zweites System zugreifen darf.
  • Für diesen Weg lässt sich wiederum OpenID Connect oder OAuth2 nutzen, um einen Token zu erzeugen – mit dem Nachteil, dass hier oft beide Fragestellungen gemischt werden und nicht spezifiziert ist, wie diese Identität kommuniziert werden soll.
  • mTLS, also Mutual oder beidseitiges TLS, ermöglicht die Verifizierung von Verbindungen an beiden Endpunkten, und ist gleichzeitig als Teil des unterliegenden OSI-Layers transparent für die Implementierung der Anwendungen.[5]

Neben direkter Userinteraktion kann es natürlich auch Jobs geben, also automatisierte Prozesse, die Zeit- oder Eventgesteuert ausgeführt werden. Da für solche Jobs kein Benutzerkontext existiert (es ist kein aktiver User eingeloggt), kann für das ausführende System eine Maschinenidentität mithilfe von OpenID Connect erlangt werden. Dieser Mechanismus ersetzt aber nicht das Authentifizieren der Kommunikation zwischen Maschinen.

Fazit

Sicheres Identity Management lässt sich mit ein paar wenigen Richtlinien in einem System umsetzen, und ist dank etablierter Protokolle und Bibliotheken kein Problem technisch umzusetzen.

Bei der Umsetzung im eigenen Projekt lässt sich die Identität am besten als Identity Token in einem verteilten System über den sogenannten “Authorization” HTTP Header kommunizieren.[6]

Denn so kennt jedes angerufene System den aktuellen Kontext und die Benutzerinformationen über denjenigen, der ursprünglich die aktuelle Operation ausgelöst hat.

Für reine Backend Jobs, die z.B. zeitgesteuert ausgelöst werden, wird ein ID-Token für den Job erzeugt, sodass auch hier sichtbar ist, wer den Prozess ausgelöst hat.

Um aber die reinen Maschinen/Systeme zu identifizieren und ob/wie diese miteinander kommunizieren dürfen, reichen die ID- oder Access Tokens nicht aus, sondern es muss ein zweites Merkmal kommuniziert werden. Das kann wiederum ein ID- oder Access Token sein, das potenziell auch von einem anderen System ausgestellt wurde, um eine gewisse Ausfallsicherheit zu gewährleisten, oder eine Lösung auf Infrastrukturebene mit mTLS (TLS Client Zertifikate). Um das Zertifikatsmanagement möglichst transparent umzusetzen, empfiehlt es sich auf transparente Proxies (sog. Sidecar Proxies) zu setzen wie zum Beispiel in einem Service Mesh wie Istio.[7]

Quellen und Referenzen

[1] https://csrc.nist.gov/publications/detail/sp/800-207/final

[2] https://en.wikipedia.org/wiki/Active_Directory

[3] https://openid.net/connect/

[4] https://oauth.net/2.1/

[5] https://cloud.google.com/blog/products/networking/the-service-mesh-era-securing-your-environment-with-istio “Authentication with mutual TLS”

[6] https://tools.ietf.org/html/rfc7235#section-4.2

[7] https://istio.io