Die Bedenken hinsichtlich der Vertraulichkeit und Integrität bei diesem Datenaustausch hielten sich in Grenzen, denn die Datenströme verließen nie das interne Netz. Die Kontrolle über die Systeme befand sich jederzeit in Unternehmenshand.
Seit sich jedoch der Cloud-Trend immer weiter von einem experimentellen Stadium hin zur erweiterten, unternehmenskritischen Infrastruktur wegbewegt, müssen die bisherigen IAM-Konzepte überdacht werden. Wie kann der Zugriff auf Everything as a Service (XaaS) auf sicherem Wege gewährleistet und zeitgleich der Betriebsaufwand für das Identitätsmanagement in vielen unterschiedlichen Cloud-Infrastrukturen minimiert werden?
Als Erstes in den Sinn kommt einem hierbei die Übertragung des bewährten Konzeptes der Kopplung zwischen Verzeichnisdienst und jeweiliger Cloud-Applikation. Dies ist jedoch in mehrfacher Hinsicht kritisch zu betrachten: Es würde einerseits voraussetzen, dass Ihr Verzeichnisdienst über interne Grenzen hinweg vertrauliche Daten an ein System schickt, welches sich außerhalb der Kontrolle des eigenen Unternehmens befindet. Außerdem würde eine Vielzahl an möglicherweise kompromittierbaren Kommunikationskanälen geöffnet, deren Manipulation sehr schädlich für Ihr Unternehmen sein könnte.
Alternativ hierzu bietet nahezu jeder Cloud-Dienst die Erstellung von Identitäten ausschließlich und spezifisch für den jeweiligen Cloud-Dienst an. Für den Endnutzer mag dies halbwegs komfortabel sein, fördert allerdings die Schaffung von Schatten-IT in der Cloud. Laut einer Umfrage von McAfee gehen Unternehmen davon aus, dass sie im Schnitt 30 Cloud-Dienste nutzen. In der Realität wurden jedoch exorbitant höhere Zahlen festgestellt: 1935 Cloud-Dienste nutzt ein Unternehmen demnach im Schnitt tatsächlich [1]. Zudem würde die Komplexität der zentralen Betreibbarkeit durch die Distribution verschiedenartiger Identitäten auf mehrere Plattformen stark ansteigen.
Entkopplung in der Cloud
Um die beschriebenen Nachteile der beiden Lösungsansätze abzumildern bzw. zu eliminieren, kann nun ein Federated Identity Management in der Cloud zum Einsatz kommen. Die grundsätzliche Idee bei diesem Ansatz besteht darin, eine zentrale Identitätsdatenbank aufzubauen (z.B. den lokalen Verzeichnisdienst), diesen mit einem Identitätsprovider / Identity Provider (IdP) aus der Cloud zu verbinden und die Authentisierung für Cloud-Dienste über ein sicheres Protokoll abzuwickeln (siehe Abbildung 1). Dies soll bestenfalls möglich sein, ohne dass der jeweilige Cloud-Dienst Kenntnis über sensible Daten wie bspw. die Anmeldedaten eines Nutzers haben muss. Informationen könnten ausschließlich bedarfsgerecht, frei nach dem „Need-to-know“-Prinzip, geteilt werden.
Abbildung 1: Schematische Darstellung der Kommunikation bei Zugriffsanfrage auf einen Cloud-Dienst
Eine solche Föderation kann bspw. dafür sorgen, dass sich die Härtungsanforderungen hinsichtlich Vertraulichkeit und Integrität der Daten auf eine überschaubare Anzahl an Systemen beschränken. Zusätzlich wird die Verwaltung der Identitäten vereinfacht, da die Komplexität durch eine zentrale Datenhaltung eingeschränkt wird. Viele solcher IdP-Lösungen bieten zudem die Möglichkeit, einen Single Sign-On (SSO) basierend auf den lokalen Nutzeridentitäten durchzuführen. Dadurch wird sogar der Komfort der User gesteigert.
Dem aufmerksamen Leser wird nicht entgangen sein, dass zur Nutzung der lokalen Identitäten in der Cloud eine Kopplung zur internen Infrastruktur erfolgen muss. Um dies auf sichere Art und Weise bewerkstelligen zu können, existieren verschiedene Ansätze, die im Folgenden näher vorgestellt werden. Voraussetzung der Nutzung ist natürlich, dass die Verfahren von beiden Parteien (Verzeichnisdienst sowie Identity Provider) unterstützt werden.
- Replikation der Nutzerdaten vom Verzeichnisdienst zum Identity Provider
Bei diesem Verfahren werden Nutzerdaten vom Verzeichnisdienst auf die Datenbank des Identitätsproviders „gespiegelt“. Kennwörter werden in der Regel jedoch ausschließlich über Hashes synchronisiert, um die Vertraulichkeit zu gewährleisten. Die Synchronisierung ist meist ausschließlich unidirektional: Änderungen der Nutzerdaten aufseiten des Identity Providers können daher nicht an den Verzeichnisdienst kommuniziert werden (sofern dies nicht aktiv unterbunden wird, können inkonsistente Datensätze die Folge sein).
- Passthrough-Authentifizierung
Bei dieser Form der Authentifizierung wird eine eingehende Authentisierungsanfrage vom Identity Provider an den Verzeichnisdienst weitergeleitet. Der Identity Provider agiert als Gateway, um Anfragen zu entkoppeln. Diese Authentifizierungsvariante macht die Speicherung von sensiblen Daten beim Identity Provider überflüssig.
- Identitätsverbund (Identity Federation)
Bei dieser Form der Authentisierung wird eine Vertrauensstellung zwischen dem Verzeichnisdienst und dem Identity Provider hergestellt. Die Synchronisierung und Datenhaltung der Identitäten erfolgen bidirektional. Der Aufbau zusätzlicher Infrastrukturen kann ggf. notwendig sein.
Die Gewährleistung der Vertraulichkeit sollte bei allen vorgestellten Varianten über die Nutzung eines abgesicherten Transportweges erfolgen und daher eine gemäß TLS 1.2 verschlüsselte Verbindung zwischen den Komponenten als Sicherheitsmindestmaß gelten.
Authentisierung gegenüber dem Cloud-Dienst
Um dem Nutzer nun die Authentisierung mit Nutzerdaten des Identity Providers gegenüber einem Cloud-Dienst zu ermöglichen, muss eine Verbindung zwischen dem IdP und dem jeweiligen Dienst etabliert werden (siehe Abbildung 1). Hierzu haben sich Token-basierte Verfahren etabliert, die es ermöglichen, einen Zugriff auf Cloud-Systeme zu erlauben, ohne dass sensible Daten wie bspw. Passwörter mit einem Cloud-Dienst geteilt werden müssen.
Die Token-basierte Authentisierung sollte erst dann erfolgen, wenn eine Vertrauensstellung zwischen dem Identity Provider und dem jeweiligen Cloud-Dienst vorhanden ist. Dies kann bspw. über den Austausch von Zertifikaten erfolgen und dadurch die Authentizität der Kommunikationspartner sicherstellen. Sobald ein gültiges Token (welches i.d.R. nur für einen begrenzten Zeitraum ausgestellt ist) durch den Client oder den Identity Provider beim Cloud-Dienst vorgewiesen werden kann, ist es möglich, Zugriff für den entsprechenden Zeitraum zu gewähren.
Abbildung 2: Kommunikationsverlauf bei Nutzung von SAML 2.0
Im Folgenden wollen wir uns die gängigsten Token-basierten Protokolle zum Austausch von Authentisierungs- und Autorisierungsinformationen genauer anschauen:
- Security Assertion Markup Language (SAML) 2.0
SAML ist ein XML-Framework, welches vom OASIS-Konsortium entwickelt wurde. Der Nachrichtenverlauf bei einer SAML-basierten Authentisierung ist in Abbildung 2 dargestellt. Bei Nutzung von SAML werden sogenannte „Assertions“, die vom IdP ausgestellt werden, per HTTP POST vom Client an den jeweiligen Cloud-Dienst gesendet. Diese Assertions dienen dem Nachweis der erfolgreichen Authentisierung beim Identity Provider. Bei der Nutzung von SAML können XML -Signaturen sowie XML -Verschlüsselung eingesetzt werden, um die Nachrichtenintegrität und -vertraulichkeit Ende-zu-Ende gewährleisten zu können. Da der Client die eigentliche Authentisierung übernimmt, muss ihm die Funktionsweise des SAML -Frameworks bekannt sein. Dies wird über eine Integration des SAML-Mechanismus in den jeweils vom Client/User genutzten Browser erreicht. SAML 2.0 wird von allen gängigen Browsern unterstützt.
- OAuth 2.0
OAuth 2.0 ist ein offenes Protokoll, welches eine Autorisierung via Programmierschnittstelle (API) gegenüber Cloud-Diensten ermöglicht. Zu diesem Zweck spezifiziert das Protokoll eine REST-API, welche sowohl vom IdP als auch vom jeweiligen Cloud-Dienst unterstützt werden muss. Zu beachten ist, dass das Protokoll lediglich zur Autorisierung genutzt werden kann, jedoch nicht zur Authentisierung. OAuth 2.0 lässt einige Implementierungsdetails bewusst offen und unspezifiziert: So lassen sich bspw. optional JSON Web Tokens (JWT) einsetzen, um eine Ende-zu-Ende-Verschlüsselung zu erreichen.
- OpenID Connect (OIDC)
OpenID Connect baut auf dem Protokoll OAuth 2.0 auf und ergänzt es um die Möglichkeit der Authentisierung. Zu diesem Zweck wird ein weiteres Datum den ausgetauschten Nachrichten hinzugefügt: Durch ein sogenanntes id_token können Transaktionen authentisiert und nachverfolgt werden. Ein beispielhafter Nachrichtenfluss ist in Abbildung 3 dargestellt.Der Unterschied zwischen SAML 2.0 und OAuth 2.0 bzw. OpenID Connect sollte bei Betrachtung der jeweiligen Abbildungen ins Auge fallen: Beim Einsatz von SAML findet eine Entkopplung der Kommunikation zwischen IdP und Cloud-Dienst über den Client statt. Bei OAuth bzw. OpenID Connect findet die Kommunikation teilweise ausschließlich zwischen IdP und Cloud-Dienst statt.
Welches Authentisierungsprotokoll eignet sich nun für welchen Anwendungszweck? Dies sollte natürlich immer für den jeweiligen Anwendungsfall entschieden werden, jedoch lässt sich als Faustregel festhalten: SAML wird i.d.R. zur Authentisierung an Diensten unter Nutzung lokaler Nutzerdaten via SSO genutzt, OAuth 2.0 zur Autorisierung für gekapselte Aktionen, die keine Authentisierung erfordern, und OpenID Connect zur Authentisierung an Diensten mit einer großen Kundendatenbank.
Ihnen sind sicher schon einmal die Login-Buttons auf verschiedenen Webseiten aufgefallen, die einen „1-Click-Login“ über Google, Facebook, Reddit, o.ä. anbieten: Hier läuft, für den Nutzer transparent, zur Autorisierung im Hintergrund das Protokoll OAuth 2.0 über einen API-Aufruf ab. Der große Vorteil besteht darin, dass die Webseite keine Kenntnis über die Passwörter o.Ä. beim jeweils anderen Anbieter haben muss. So treten Unternehmen mit großen Kundendatenbanken im Grunde in die Rolle eines Identity Providers.
Provisionierung von Nutzerdaten
Identity Provider bzw. Verzeichnisdienste haben i.d.R. Kenntnis über weitere Informationen zu Identitäten, die über das Paar „Nutzername/Passwort“ hinausgehen. Typischerweise werden in Verzeichnisdiensten bspw. auch Gruppenmitgliedschaften, Angaben zu Vor-/Nachnamen der jeweiligen Person sowie darüber hinausgehende Informationen gespeichert. Falls Cloud-Dienste auf solche Informationen zugreifen müssen oder wollen, um ihre Funktion vollumfänglich zu erfüllen, muss zusätzlich zur Authentisierung eine Provisionierung von Identitätsinformationen stattfinden. Ein Cloud-Proxy könnte so konfiguriert sein, dass er auf Basis von Gruppenmitgliedschaften eines Nutzers darüber entscheiden soll, ob ein Zugriff auf eine Webseite zu erlauben oder zu blockieren ist.
Abbildung 3: Kommunikationsverlauf bei Nutzung von OpenID Connect
Auch für die Provisionierung von Identitätsinformationen existieren verschiedene Umsetzungsmöglichkeiten:
- Auto-Provisionierung bei der Authentisierung
Bei diesem Verfahren werden Nutzerinformationen direkt bei der Authentisierung mitgesendet (siehe Abbildung 2 und Abbildung 3: „Auto-Provisioning“). Der Identity Provider muss hierfür entsprechend konfiguriert werden, sodass die benötigten Informationen in Form eines „Claims“ bereitgestellt werden.
Der Nachteil dieser Provisionierungsmethode besteht darin, dass Informationen nur dann beim Cloud-Dienst aktualisiert werden, wenn eine erneute Authentisierung stattfindet. Unter Umständen sind die Datensätze zwischen IdP und Cloud-Dienst also nach einiger Zeit inkonsistent, sofern keine Re-Authentisierung in regelmäßigen Abständen stattfindet. Im schlimmsten Fall hat ein Nutzer bspw. weiterhin Zugriff auf einen Cloud-Dienst, obwohl er aus dem Verzeichnisdienst gelöscht oder deaktiviert wurde. Die Implementierung dieser Auto-Provisionierungsvariante ist jedoch i.d.R. trivial, da bereits die Authentisierungsschnittstelle etabliert wurde.
- System for Cross-domain Identity Management (SCIM)
SCIM spezifiziert eine offene API, welche von der IETF veröffentlicht wurde. SCIM ermöglicht eine (nahezu) Echtzeit-Synchronisierung der Nutzerinformationen vom Identity Provider zum Cloud-Dienst. Zu diesem Zweck wird eine unidirektionale Kommunikation vom IdP zum Cloud-Dienst etabliert, welche Änderungen in der Datenbank des IdP (bzw. des angeschlossenen Verzeichnisdienstes) schnellstmöglich an den Cloud-Dienst kommuniziert. Dies führt dazu, dass kein inkonsistenter Datensatz aufseiten des Cloud-Dienstes existiert und dadurch bspw. gelöschten oder gesperrten Nutzern mit sofortiger Wirkung die Berechtigung entzogen werden kann.
Fazit
Vor dem Sprung in die Cloud sollte Ihr bestehendes IAM darauf untersucht werden, welche Möglichkeiten sich zur Kopplung mit Identity Providern aus der Cloud ergeben. Zusätzlich ist es ratsam, wenn Sie sich einen Überblick über die Authentisierungs- und Provisionierungsmöglichkeiten Ihrer voraussichtlich meist genutzten Cloud-Dienste verschaffen, um eine Kompatibilität mit Ihrem Cloud IAM gewährleisten zu können. Dieser Artikel hat Ihnen hoffentlich einen Eindruck darüber verschafft, welche Optionen Ihnen grundsätzlich offenstehen, um im Entscheidungsfall die Alternativen abzuwägen.
Verweise
[1] McAfee, “Are Your Employees Using Your Data in the Shadows?” https://www.mcafee.com/blogs/enterprise/cloud-security/are-your-employees-using-your-data-in-the-shadows/
