Cloud Enabling: Identitätsmanagement als Basis

Hinweis: Die Autoren sind Christof Dornbierer und Thomas Zweifel. Dornbierer ist CEO und Zweifel Senior IT Consultant bei Adnovum.

Cloud-Dienste sind in aller Munde und werden insbesondere für die Erhöhung der Flexibilität und Skalierbarkeit der IT-Infrastruktur beworben. Firmen erwarten, Teile der eigenen Infrastruktur relativ einfach an Cloud-Dienste auslagern und so ihre eigenen Services schneller und unkompliziert bereitstellen zu können, also deren Time-to-Market zu verkürzen. Doch wie wird entschieden, wer wann und wo auf die ausgelagerten Daten zugreifen darf? Und wie erreicht man, dass die Vorteile der Auslagerung nicht durch einen Mehraufwand im Identitäts- und Zugriffsmanagement zunichtegemacht werden?

Vielfalt und Vielzahl generiert Aufwand

Für Firmen ist es aufwendig, die gesamten Prozesse zur Verwaltung von Kunden-Logins zu etablieren, da hierbei unterschiedlichste Ansprüche berücksichtigt werden müssen: Ein Webshop benötigt validierte Identitäten und Adressen. Ein Supportforum zum Beispiel sollte hingegen möglichst niederschwellig sein und den Kunden nicht unnötig abschrecken: die Kundendaten müssen nicht validiert werden oder können gar anonym sein. Für Kunden wiederum ist es mühsam, die Übersicht über die verschiedensten Logins und Passwörter zu behalten – besonders, wenn Dienstleistungen nur sporadisch bezogen werden.

Die verbreiteten Mechanismen zur Verwaltung der eigenen Kundendaten entlasten zwar Firmen und Kunden, ändern jedoch nichts am Grundproblem der Vielzahl von Identitäten und Passwörtern. Erfolgversprechender ist es, die an verschiedenen Orten eingesetzten IAM-Services zu standardisieren. Breit abgestützte Standards würden es ermöglichen, IAM-Services auszulagern und als standardisierte Basisdienste zum Beispiel aus der Cloud zu beziehen. Welche Vorteile hätte dies für Unternehmen und Benutzer?

Geteilter Aufwand ist halber Aufwand

Der Unterhalt einer Identity- und Access-Management-Infrastruktur ist aufwendig. Den höchsten Aufwand verursacht nicht der technische Betrieb der Infrastruktur, sondern der Identifizierungsprozess, durch den eine Person zu einer digitalen Identität gelangt. Digitale Identitäten können sehr unterschiedliche Ausprägungen haben (siehe Grafik oben). Ist im einen Fall eine vollständige Selbstregistrierung ausreichend, erfordern andere Geschäfte beim Erstellen der digitalen Identität einen physischen Kontakt inklusive Identifizierung mittels Ausweis. Gerade da ist das Potenzial einer zentralen Lösung offensichtlich: Sie erspart den Anbietern des Geschäfts den Aufbau eines jeweils eigenen «Registrierungsbüros». In der Schweiz wird dieser Service zum Beispiel im Rahmen der SuisseID bereits angeboten.

Ein weiterer aufwendiger Faktor ist die Ausstattung der Benutzer mit Authentisierungsmerkmalen. Für den Zugriff auf sicherheitskritische Funktionen wird häufig eine 2-Faktor-Authentisierung gefordert. Dazu muss dem Benutzer meist eine Art physisches Token zugestellt werden, ein logistisch anspruchsvoller Prozess, insbesondere bei Erneuerung oder Verlust des Tokens. Dieser kann beim Einsatz eines zentralen IAM-Dienstes ebenfalls ausgelagert oder sogar ein bestehender Prozess genutzt werden, zum Beispiel die Verbreitung von SIM- oder Bankkarten.

Ein zentraler IAM-Dienst hat aber noch weitere Vorteile. Die Authentisierung findet ausserhalb der Anwendung statt, und die Identität wird danach auf sichere Art und Weise zur Anwendung propagiert. Die Anwendung muss dadurch keinerlei Authentisierungslogik implementieren. Der Benutzer wiederum hat eine zentrale Anlaufstelle für sämtliche Authentisierungsfragen (Passwort vergessen, Token verloren etc.) und kann im Sinne eines benutzerzentrierten Ansatzes klar definieren, wer seine Identität inklusive möglicher Attribute verwenden darf. Wenn der IAM-Dienst auch verifizierte Anonymität und andere Identitätsausprägungen anbietet, sind weitere Use-Cases denkbar, zum Beispiel eine Altersverifikation ohne Offenlegung des Geburtsdatums.

Das eigentliche Potenzial der Auslagerung von Identitätsprozessen besteht aber in den Synergien. Verfolgen nämlich mehrere Unternehmen den gleichen Ansatz, braucht ein Benutzer nur noch ein Authentisierungsmittel für diverse Serviceanbieter. Die Serviceanbieter müssen nicht mehr für jeden Benutzer ein dediziertes Authentisierungsmittel finanzieren und die Gesamtkosten teilen sich unter ihnen auf. Schliesslich ist es sogar denkbar, dass der Benutzer selbst ein Authentisierungsmittel finanziert, weil er den Mehrwert für sich als signifikant erachtet. Doch trotz des enormen Potenzials werden Identitätsprozesse heute noch kaum ausgelagert. Wie lässt sich das erklären?

Kein Fortschritt ohne Standardisierung

Wird IAM von den einzelnen Cloud-Diensten und Anwendungen entkoppelt und eventuell sogar verteilt durch mehrere gekoppelte IAM-Dienste angeboten, braucht es Mechanismen zum Abgleich und zur Kontrolle. Sonst kann die Datenkonsistenz nicht gewährleistet und können regulatorische Vorgaben in den unterschiedlichen Systemen nicht erfüllt werden. Ein zentrales Erfolgskriterium ist dabei die Übertragung der Benutzerdaten zwischen den beteiligten Systemen, sei es durch bedarfsbasierte Weiterleitung in Echtzeit (Föderierung) oder durch proaktive Weiterleitung (Provisionierung).

Zur dezentralen Anmeldung bei Cloud-Diensten zur Laufzeit mittels Föderierung existieren diverse Standards wie etwa SAML 2.0, WS-Federation oder openID. Die reine Anzahl der Standards bedeutet hier eine gewisse Varianz. Viele Cloud-Anbieter unterstützen jedoch bereits heute die gängigsten Methoden. Der Föderierungsvorgang per se gilt als technisch durchaus gut realisierbar.

Für eine erfolgreiche Anmeldung mittels Föderierung verlangen jedoch viele Cloud-Dienste, dass der Benutzer im Cloud-Dienst bereits über einen Account verfügt. In den meisten Fällen ist dies durchaus legitim, etwa wenn für die Benutzer persönliche Datenraumautorisierungen angeboten werden sollen. In anderen Fällen reicht eine reine Rollen-Propagierung aus. Wird der Benutzer-Account vorausgesetzt, existieren prinzipiell zwei Strategien: Der Benutzer-Account wird entweder beim ersten Zugriff on-the-fly erzeugt oder er wird explizit beim Cloud-Dienst erfasst beziehungsweise idealerweise automatisch aus bestehenden Benutzerverzeichnissen provisioniert.

Bei der On-the-fly-Erstellung stellt sich die Frage, wie der Benutzer-Account auch nach dem ersten Zugriff aktuell gehalten und wie eine globale Übersicht erreicht werden kann. Hier bietet die explizite Provisionierung eindeutig Vorteile. Sie setzt aber eine entsprechende Schnittstelle beim Cloud-Anbieter voraus. Zwar existieren auch dafür einige Standards wie SPML oder SCIM, durchgesetzt hat sich jedoch noch keiner.

Wegen dieses Mangels an einem breit unterstützten Provisionierungs-API wird der Abgleich von vielen Cloud-Anbietern mittels manueller Benutzerverwaltung oder aber direkten Zugriffs auf Directory-Systeme beim Cloud-Dienst-Anwender über VPN umgesetzt. Der manuelle Abgleich birgt vor allem die Gefahr von Inkonsistenzen, etwa wenn ein Mitarbeiter die Firma verlässt, sein Account aber zum Beispiel in Salesforce nicht deaktiviert wird und er weiterhin auf die Kundendaten der Firma inklusive Opportunitäten oder Umsatzzahlen zugreifen kann. Der VPN-Ansatz wiederum erfordert einen direkten Zugriff vom Cloud-Anbieter in das Unternehmen hinein, wie er selten erwünscht und häufig gar nicht machbar ist.

Cloud-Anbieter in der Pflicht

Ist der Ansatz, Identity- und Access-Management als Basis-Service auszulagern, also gescheitert? Nein. Als Erstes müssen allerdings die Anbieter der Cloud-Dienste darauf vorbereitet sein, auch mit externen Identitätsverwaltungen umgehen zu können. Föderierungsprotokolle werden bereits heute verbreitet angeboten. Wird demnächst auch die Provisionierung von Identitäten mittels eines Standardprotokolls breiter unterstützt, kann die Identitätsverwaltung selbst als Cloud-Dienst bereitgestellt und genutzt werden. Besonders für KMUs dürften solche Cloud-Identity-Management-Lösungen aufgrund der geringen Investitionskosten sehr attraktiv werden.