28. Dezember 2020
Get in touch
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, da jede durchgeführte Aktion vorher authentifiziert wird.
Eine Zero-Trust-Umgebung stellt also die grundsätzliche Anforderung, zu jedem Zeitpunkt zu wissen:
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
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.
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.
Ursprünglich war OAuth nicht primär zur Identifizierung der Endnutzer:innen 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.)
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:
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:
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.
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:
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 Benutzer:innenkontext 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.
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
Denn so kennt jedes angerufene System den aktuellen Kontext und die Benutzer:inneninformationen ü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.
Dieser Artikel ist zuerst im Magazin "DIGITALE WELT" erschienen. Wir freuen uns über Ihr Feedback und das Teilen des Artikels.
