Identity-Management-Architektur

Ordnungsmerkmale

erschienen in: <kes> 2006#6, Seite 34

Rubrik: Management und Wissen

Schlagwort: Identity Management

Schlagwort-2: Architektur

Zusammenfassung: Wie so oft, lohnt auch beim Identity Management (IdM) der "Schritt zurück", um mit mehr Überblick eine klare Struktur zu schaffen. Eine wohlüberlegte Architektur statt einer Sammlung von Ad-hoc-Lösungen liefert solide und zukunftssichere IdM-Prozesse.

Autor: Von Martin Kuhlmann, Berlin

"Stabilität, Nützlichkeit und Anmut" sind für den antiken römischen Baumeister Vitruv die bedeutendsten Prinzipien der Architektur. Für IT-Verantwortliche, die heute unter dem Druck stehen, rasch Lösungen für drängende Compliance-Probleme zu finden oder Kosten für Benutzerverwaltung und Helpdesk zu reduzieren, klingt das wie ferne Musik. Sie laufen schnell Gefahr, dass Maßnahmen zum Identity Management (IdM) zu einer Taktik des Löcherstopfens oder zu neuen Insellösungen führen. Von einer stabilen, nützlichen IdM-Architektur ist die betriebliche Praxis nämlich oft weit entfernt.

Der Gesamtblick auf verschiedene Aspekte des Identity Management, das Zusammenspiel und den Betrieb der technischen Komponenten sowie auf die organisatorischen Prozessabläufe zahlt sich jedoch durch mehr Transparenz und Sicherheit aus. Eine solche Architektursicht einzunehmen heißt nicht, dass hier die Stunde der Theoretiker schlägt, sondern sie ermöglicht vielmehr eine Antwort auf die Frage, durch welche Konstellation von Komponenten und Prozessen man konkrete Probleme am gezieltesten lösen kann.

Hauptmotive für IdM

Ein Hauptgrund für den Aufwind des IdM ist der Kostendruck in der IT, der Standardisierung und Automatisierung von IT-Sicherheit fordert. Ein anderer wichtiger Treiber ist der zunehmende Ruf nach systematischem Risikomanagement, nicht zuletzt für Risiken durch flexible Reaktionen auf Marktanforderungen, häufige Umstellungen von Angebotsportfolio oder Geschäftsmodellen oder durch die Folgen von Mergers and Acquisitions.

Auf technischer Ebene werden Netzwerke immer offener, die Verfahren und Systeme vielfältiger, komplexer und damit unübersichtlicher. Auf organisatorischer Ebene gilt es zudem, zahlreiche gesetzliche und branchenspezifische Regulierungen einzuhalten. Eine IdM-Architektur steht somit im Spannungsfeld von Sicherheitsrichtlinien des Unternehmens und externer Regulierung. Sie wird zudem beeinflusst von der Komplexität der bestehenden IT-Infrastruktur sowie vom Geschäftsmodell des Unternehmens: Die Sicherheitsproblematik eines industriellen Fertigungsunternehmens unterscheidet sich beispielsweise beträchtlich von dem eines Internethandels.

[Illustration]
Abbildung 1: Einflüsse auf eine Identity-Management-Architektur

Fachliche Aufgaben

Bei IdM geht es hauptsächlich um Informationen zu Mitarbeitern, Partnern und Kunden im Hinblick auf deren Nutzung von IT-Systemen. Die zugehörigen Benutzerinformationen müssen zunächst schnell und korrekt überall dort zur Verfügung stehen, wo sie benötigt werden: für IT-Systeme, Applikationen und auch als Information für Menschen (etwa im Telefonbuch). Die Verwaltung dieser Informationen muss zudem möglichst kostengünstig sein. Auf der operativen Ebene ist darüber hinaus die sichere Authentifizierung und Autorisierung zu gewährleisten – auch über Systemgrenzen hinweg in serviceorientierten Architekturen, webbasierten Systemen und Mainframe-Anwendungen.

Wie Mitarbeiter IT-Systeme nutzen sollen, ist eine Frage der Betriebsorganisation. Fachabteilungen sollten in der Lage sein, möglichst ohne Intervention von IT-Spezialisten ihre Arbeitsumgebung einzurichten und zu verwalten. Gleichzeitig müssen die Prozesse der Verwaltung von Benutzerinformationen und Zugriffsrechten sowie die Zugriffsrechte selbst gemäß den Sicherheitsrichtlinien des Unternehmens definiert sein. Dies ist nur durch eine entsprechende systemübergreifende Harmonisierung der Benutzeradministration und Zugriffsrechteverwaltung sowie durch die Etablierung zentraler Kontrollfunktionen zu erreichen. Ein standardisiertes Identity Management hat darüber hinaus den Vorteil, dass man schnell auf organisatorische Änderungen wie etwa in Merger&Acquisition-Szenarien reagieren kann.

Eine IdM-Architektur kann wesentlich dazu beitragen, die Einhaltung von Regulierungen (Compliance) durch das Zusammenwirken der richtigen Tools mit den richtigen Prozessdefinitionen preiswert zu ermöglichen. Der Sicherheits- und Compliance-Aspekt macht zudem das Thema Identity Audit zu einem relevanten Bestandteil der IdM-Architektur: Sicherheitsrelevante Daten müssen korreliert und für die Revision nach Compliance-Gesichtspunkten auswertbar sein, bei Schadensvorfällen muss eine forensische Analyse möglich sein, für Log-Daten sind entsprechende Aufbewahrungsfristen vorzusehen. Schließlich erfordert die sich verstärkende Zusammenarbeit über Unternehmensgrenzen hinweg den übergreifenden Austausch von Benutzer- und Berechtigungsdaten. Dies geht nur mit zentralen, standardisierten Schnittstellen und einem transparenten Autorisierungskonzept für Mitarbeiter, Partner und Kunden.

Abbildung 2 zeigt schematisch die wesentlichen Komponenten einer IdM-Architektur: Den Kern bilden User-Provisioning und die verschiedenen Verzeichnisdienste. Diese stehen in Beziehung zu steuernden Systemen wie Human Resources (HR), Organisationsdatenbanken oder Werkzeugen zur Geschäftsprozessmodellierung, mit Systemen zur Authentifizierung und Autorisierung sowie mit den inhärenten Security-Komponenten der IT-Infrastruktur. Viele dieser Beziehungen haben beim Entwurf und der Optimierung einer IdM-Architektur erhebliche Bedeutung.

[Illustration]
Abbildung 2: Skizze einer IdM-Architektur

Übersichtliche Struktur

Die zentrale Konzeption einer IdM-Architektur ist nicht zu verwechseln mit einem monolithischen Ansatz. Dies wird besonders deutlich an der Strategie für die Verzeichnisse als IdM-Kernobjekte: Weder ein "Mega-Directory" noch eine Zersplitterung in eine dreistellige Anzahl von Verzeichnissen, wie in vielen Großunternehmen, sind die Lösung. Ein separates Partnerverzeichnis statt der Vermischung von Partner- und Mitarbeiterinformationen kann schon allein wegen Strukturunterschieden der zu pflegenden Daten sinnvoll sein. Auch anhand unterschiedlicher Aufgaben ist zu überlegen, wie viele und welche Verzeichnisse man braucht: hier wären etwa Authentifizierung, Autorisierung, Personalisierungsservices in Portalen, Telefonverzeichnis, CRM oder System- und Netzwerkmanagement als Ziele zu nennen.

In der Praxis erschweren eine zu große und unübersichtliche Anzahl von Benutzerverzeichnissen und -datenbanken, komplexe Synchronisationsdatenflüsse und sukzessiv implementierte Ad-Hoc-Lösungen (z. B. aufwändige FTP-Datenübertragungen) die Verwaltung einer IdM-Infrastruktur. Die Datenqualität ist dann unzureichend und die Verwaltungsmechanismen werden teuer und unsicher. In solchen Fällen sollte man zunächst die Situation analysieren und qualitative Ziele definieren (vgl. Tab. 1). Durch den gezielten kombinierten Einsatz von Provisioning, Meta-Directory- und Virtual-Directory-Techniken kann man dann diese Ziele erreichen.

[Illustration]
Tabelle 1: Qualitative Ziele, die man bei der Verwaltung von Identitätsinformationen erreichen will, werden durch das Zusammenspiel der verschiedenen Verfahren umgesetzt.

User Provisioning

Wegen ihrer Vielfalt und des zentralen Ansatzes, der eine gute Kontrolle der Benutzerverwaltung ermöglicht, spielen in diesem Zusammenhang User-Provisioning-Funktionen eine besondere Rolle. Provisioning-Systeme automatisieren zunächst die Verwaltung von Benutzern und Zugriffsrechten. Dazu werden Änderungen im Benutzerstamm und in der Organisation aus HR-Systemen, Corporate Directories und Organisationsdatenbanken aufgenommen und konsolidiert. Die Benutzer werden dann entsprechend ihrer Position und Aufgaben in den an das Provisioning-System angebundenen Systemen, Applikationen und Verzeichnissen (Zielsysteme, Provisioning Targets) eingerichtet.

So kann etwa ein Windows-Benutzerkonto mit entsprechenden Sicherheitseinstellungen (Kennwort-Intervall, Logon-Zeiten, Home Directory usw.) und Gruppenzugehörigkeiten erstellt, ein RACF-Mainframe-Benutzerkonto mit Berechtigungen eingerichtet oder ein Telefonverzeichniseintrag erzeugt werden. Um den Provisioning-Prozess konform zu den Sicherheitsrichtlinien des Unternehmens durchführen zu können, sollten die Zielsystem-Konnektoren des Provisioning-Systems möglichst granulare Sicherheitseinstellungen und Autorisierungen ermöglichen.

Das Provisioning-System benötigt darüber hinaus Mechanismen, um Sicherheitsrichtlinien zu definieren und ihre Einhaltung zu kontrollieren. Zu den Kontrollmechanismen gehört neben einem Berichtswesen die Möglichkeit, aktuelle Zielsystemeinstellungen mit den im Provisioning-System definierten Richtlinien abzugleichen, Verstöße zu eskalieren und zu korrigieren.

Als wichtigstes Werkzeug für die Definition von Sicherheitsrichtlinien hat sich die rollenbasierte Administration (Role-Based Access Control, RBAC) etabliert. Ein klassisches Beispiel für den Nutzen von rollenbasierter Administration ist die einfache Einhaltung der Funktionstrennung (Separation of Duty, SoD). Durch eine geeignete Kombination von Geschäftsprozess-Analyse mit Data-Mining auf bestehenden Rechtestrukturen (Role Mining) lässt sich der Aufbau eines Rollenkonzeptes durchaus in wenigen Monaten bewältigen.

Mittlerweile kann man sich bei der Rollenkonzeption auch auf einen ANSI-Standard stützen (ANSI 359-2004). Große Unternehmen sollten sich jedoch nicht vornehmen, ihre gesamte Organisation in einem einzigen logischen Rollenkonzept abzubilden. Vielmehr ist es sinnvoll, dass unterschiedliche Bereiche verschiedene Konzepte realisieren, etwa im Zentralbereich eines Konzerns die Kostenstellenstruktur, im Filialbereich die Kombination aus Organisationseinheit und Funktionshierarchie. Ratsam ist es darüber hinaus, Rollen in zwei oder drei Stufen aus Teilrollen aufzubauen.

Administration und Workflow

Eine weitere wichtige Aufgabe der IdM-Architektur, die durch Provisioning-Systeme abgedeckt wird, ist die Unterstützung des Workflows für die Benutzer- und Rechteverwaltung mit zentralen und dezentralen Administrationsfunktionen sowie Genehmigungsverfahren. Eine zentrale Kontrolle ist einerseits zwar erforderlich, andererseits ist übertriebener Zentralismus bei der Administration jedoch träge, teuer und fehleranfällig.

Wo es sinnvoll erscheint (z. B. beim Passwort-Reset oder der Rechtebeantragung) sollte auch der Endbenutzer in den Identity-Management-Prozess eingebunden werden. Auf technischer Ebene gilt es daher, sowohl professionelle Administrationswerkzeuge als auch geeignete Web-Interfaces für Business-User bereitzustellen, die nur gelegentlich neue Berechtigungen beantragen wollen. Eine Einbindung dieser Interfaces in vorhandene Workflows ist dabei vorteilhaft. Eine standardisierte IdM-Architektur bietet darüber hinaus zentrale Schnittstellen, über die man beispielsweise mit Outsourcern oder Partnerunternehmen kommunizieren kann. Insgesamt am effizientesten ist ein ausgewogenes Konzept zwischen zentraler und dezentraler Ausführung administrativer Tätigkeiten; die Aufstellung eines entsprechenden Business Case ist zu empfehlen.

Um eine durchgehende "End-to-End"-Kontrolle der Zugriffsrechte vom Benutzer bis zur genutzten Ressource zu erhalten, genügt es zudem nicht, Benutzerkonten und Gruppenmitgliedschaften zu verwalten oder den Zugang zu Webseiten mit Web-Access-Management-Systemen zu schützen. Für strategische Anwendungen, wie etwa die Buchungsapplikationen einer Bank, sollten daher die Autorisierungen der Benutzer für Services und Datenobjekte (Entitlement Management bzw. Fine-grained Authorization) in die zentrale IdM-Architektur integriert werden. Diese Einbindung hat neben dem Kontrollaspekt auch den Vorteil, dass Automationsfunktionen und rollenbasierte Administration für das Entitlement Management zur Verfügung stehen.

Authentifizierung und Single Sign-on

Techniken zur Authentifizierung von Benutzern für die Nutzung von Netzwerken, Anwendungen und Systemen sind ebenfalls Teil der IdM-Architektur. Hier sollten die Anforderungen je nach Geschäfts- und Aufgabenbereich festgelegt werden: Mitarbeiter im Bereich HR oder Corporate Finance fallen beispielsweise in eine andere Risikokategorie als Sachbearbeiter, die lediglich Bestellungen abwickeln.

Die Anzahl genutzter Anwendungen, die Risikoklassifikation genutzter Daten und der Zugriffskanal (z. B. VPN) sind jeweils Kriterien, mit denen über den Einsatz und die Kombination von Techniken wie Zwei-Faktor-Authentifizierung, automatische Passwort-Synchronisation und Single Sign-on (SSO) entschieden werden kann. Neben diesen Sicherheitsaspekten bestimmen Benutzerproduktivität und Helpdesk-Kosten den Business Case für Authentifizierungstechniken. Benötigt der Benutzer etwa durch Passwort-Synchronisation oder Enterprise Single Sign-on weniger Passworte, so wird er diese auch seltener vergessen; das Resultat sind meist weniger Helpdesk-Anfragen.

Auch Authentifizierungssysteme speichern ihre Daten oft in Verzeichnissen. Bei der Überlegung, inwieweit bestehende Verzeichnisse nutzbar sind, ist vor allem die hohe Verfügbarkeit zu berücksichtigen. Zudem können diese Systeme auf mindestens zwei Arten sinnvoll mit dem zentralen Provisioning-System verknüpft werden: Erstens ist die Provisioning-Lösung in der Lage, Benutzer in den Authentifizierungssystemen zu verwalten. Dies ist besonders dann vorteilhaft, wenn mehrere einander nachgelagerte Authentifizierungssysteme aufeinander abgestimmt werden müssen. Zweitens ergänzen sich Provisioning und Authentifizierung beim Audit: Während das Provisioning-System Informationen über die Zugriffsrechte eines Benutzers zu einem bestimmten Zeitpunkt liefert, wird über die Protokolldatei beispielsweise des SSO-Systems sichtbar, wann der Benutzer sich an- und abgemeldet hat.

Wichtige Kontrollinstanz

Das Identity Audit ist der nächste Bereich, den eine IdM-Architektur abzudecken hat; es umfasst die Kontrolle und Nachvollziehbarkeit der identitätsbezogenen Aktivitäten im Unternehmensnetzwerk. Die typischen Fragestellungen, die in diesem Zusammenhang beantwortet werden müssen, sind: Welche Rechte hatte ein Mitarbeiter zu einem bestimmten Zeitpunkt? Wer hat wem wann welche Rechte erteilt? Wer hat wann welche Ressourcen genutzt?

Identity Audit überwacht zudem die Einhaltung von Sicherheitsrichtlinien wie etwa das Least-Privilege-Prinzip oder die bereits erwähnte Aufgabentrennung (SoD) im Zusammenhang mit rollenbasierter Administration. Konkret lassen sich beispielsweise viele Forderungen aus Kapitel 9 des Risikomanagement Frameworks ISO 17799 (Access Control) durch Identity Audit abdecken. Und auch zur Etablierung eines Kontrollkreislaufs nach ISO 27001 ("Plan-Do-Check-Act") spielt Identity Audit eine wichtige Rolle.

Möglichkeiten und Grenzen des Identity Audit sollten im Unternehmen präzise definiert und kommuniziert werden, damit im Zusammenspiel von Identity Audit und System Audit weder Lücken noch ein Übermaß an Aktivitäten entstehen.

Technisch wird Identity Audit durch Protokollierungs-, Überwachungs- und Auswertungswerkzeuge für Benutzereinstellungen und Berechtigungen, für Aktivitäten der Benutzerverwaltung und für Systemzugriffe realisiert. Da ein umfassendes Identity Audit die Korrelation von Benutzerdaten auf verschiedenen Systemen erfordert, sollte es mit dem Provisioning-System verzahnt sein, das diese Informationen enthält.

Neue Herausforderungen

Zukünftig hat die IdM-Architektur zusätzliche Herausforderungen zu meistern: Die Zusammenarbeit zwischen Unternehmen und auch serviceorientierte Architekturen (SOA) haben zur Idee einer "portablen Identität" geführt. Das serviceorientierte Konzept eines föderierten Identity Management mit Identity Providern und Identity-"Konsumenten" erfordert eine Anpassung der IdM-Architektur und stellt neue Fragen: Wie können Revisionsfähigkeit, Rollenkonzepte, die Verteilung von personenbezogenen Informationen und Fragen der Semantik gelöst werden? Unternehmen sollten die Anforderungen für ihre individuellen, konkreten Szenarien analysieren und die Einführung von neuen Föderationsstandards wie SAML (vgl. S. 38) oder SPML nicht rein technikzentriert angehen.

Hat man eine integrierte IdM-Architektur mit wenigen Schnittstellen und klaren Prozessen etabliert, so sind in jedem Fall auch Föderation und andere zukünftige Verfahren einfacher einsetzbar. Und vielleicht kann man dann in der IdM-Architektur im Vitruv'schen Sinne neben Stabilität und Nützlichkeit sogar noch etwas Ästhetisches entdecken...

Dr. Martin Kuhlmann ist Senior Product Line Manager SAM Jupiter bei der Beta Systems Software AG.