Viele Unternehmen haben erkannt oder – durch rechtliche Vorgaben – erkennen müssen, dass ein unternehmensweites Konzept für Identity- und Access-Management (IAM) notwendig und sinnvoll ist. Die Umsetzung dieses Gedankens birgt einige Fußangeln, die bei entsprechender Ausgestaltung aber umgangen werden können.
Identity- und Access-Management (IAM) hat sich mittlerweile als Sammelbegriff für eine Reihe von Funktionen etabliert, allerdings versteht nicht jeder dasselbe hierunter. Mit Identity-Management bezeichnet die Autorin die Verwaltung derjenigen Informationen, die für Identifikation, Authentifizierung und Autorisierung eines Nutzers notwendig sind. Access-Management umfasst hingegen die Durchführung der Identifikation, die Authentifizierung und Autorisierungsprüfung bei einem Zugriffswunsch unter Nutzung vorhandener Informationen über den Anwender sowie seine Rechte und Rollen.
Zu beiden Bereichen gehören jeweils noch eine Protokollierungs-Komponente, welche durchgeführte Aktionen nachvollziehbar aufzeichnet, und eine Reporting-Komponente, die nutzerbezogene Auskünfte über Anwenderkonten, Rollen und Rechte in einer übersichtlichen Form liefert.
Zu den Kernkomponenten eines Identity- und Access-Management (IAM) gehören neben der technischen Infrastruktur auch unternehmensinterne Prozesse und Regelungen (Policies).
Weitere Begriffe, die in Zusammenhang mit IAM verwendet werden, sind unter anderem Provisioning, Self-Services und Web Single Sign-On. Der Kasten "Glossar" liefert Begriffserklärungen für die Funktionen oder Dienste des IAM, die im Folgenden Verwendung finden; für weitergehende Erläuterungen sei auf [1] verwiesen.
Zu IAM gehört aber mehr als nur Technik (vgl. Abb.): Die Erfahrung zeigt, dass für ein effizientes, unternehmensweites Identity- und Access-Management relevante Prozesse, dazugehörende Randbedingungen in Form von Regelungen (Policies) und unterstützende Infrastruktur sowie deren Zusammenspiel aufeinander abgestimmt und optimiert werden müssen. Beispielsweise ist ein Workflow-Tool nur dann effizient und in einem größeren Rahmen einsetzbar, wenn die damit zu unterstützenden Prozesse – etwa die Berechtigungsvergabe – einem vorgegebenen (Unternehmens-)Standard genügen.
----------Anfang Textkasten----------
----------Ende Textkasten----------
Auf die Gründe, warum ein unternehmensweites IAM sinnvoll ist und welchen Nutzen es bringt, soll hier nur insofern eingegangen werden, als daran die unterschiedlichen Beteiligten und Interessenvertreter sowie ihre Wünsche und Forderungen erkennbar werden. Für den Erfolg eines IAM-Projekts ist es entscheidend, alle diese beteiligten Gruppen von Anfang an einzubeziehen.
In den Anfängen des IAM, als es diesen Begriff noch gar nicht gab, ging es vor allem um die Verwaltung von Zugriffsberechtigungen zu einzelnen Systemen – so wie beispielsweise über RACF die Zugriffsberechtigungen zum Großrechner verwaltet wurden (und werden). Diese Aufgabe hat sich über die Jahre in verschiedene Dimensionen ausgedehnt und zu dem entwickelt, was wir heute unter IAM verstehen. Anhand dieser Dimensionen lässt sich gut der aktuelle Stand beschreiben und die zukünftige Entwicklung darstellen.
Allgemein zeigt sich eine Tendenz zur Standardisierung und zu generischen Sets, die sich auch in Zukunft fortsetzen wird. Diese Entwicklung ist zum Beispiel den Reports der verschiedenen Analystenhäuser wie Gartner, Forrester, IDC, Burton Group und (im deutschsprachigen Raum) Kuppinger & Cole zu entnehmen, die in regelmäßigen Abständen zu IAM erscheinen. Die folgenden Abschnitte geben die wesentlichen Punkte dieser Reports, vorhandener Best Practices und den weltweiten Erfahrungen von CSC wieder.
Berechtigungsstrukturen sind Teil der Kernkomponente "Regelungen". Waren in den Anfängen des IAM vor allem Berechtigungsstrukturen vorherrschend, in denen die Zugriffe von Subjekten auf Objekte auf der Basis von Identitäten beschrieben wurden, so sind daraus zunächst Berechtigungsstrukturen basierend auf Kategorien (Rollen) entstanden. Die Entwicklung der vergangenen Jahre sind kontextabhängige Berechtigungsstrukturen (vgl. Glossar und [1,2]).
Schon recht früh, Ende der neunziger Jahre, gab es erste Bestrebungen, Berechtigungskonzepte basierend auf Kategorien zu standardisieren, wobei 2004 ein Standard des American National Standards Institute (ANSI) zur rollenbasierten Zugriffskontrolle (Role Based Access Control – RBAC) verabschiedet wurde [3].
Erweiterungen auf kontextbasierte Berechtigungskonzepte wurden parallel dazu von verschiedenen Seiten verfolgt. Hier seien beispielhaft die Ergebnisse der Organization for the Advancement of Structured Information Standards (OASIS) [4] und von amerikanischen Behörden [5] genannt. Eine gute Einführung in RBAC und praxisnahe Beispiele – auch für kontextabhängige Modelle – sind in [6] zu finden.
Da es in zunehmendem Maße Werkzeuge gibt, die sowohl das Auffinden von kontextbasierten Berechtigungsstrukturen in Unternehmen als auch das Rollenmanagement in geeigneter Form unterstützen, wird sich diese Berechtigungsstruktur mittel- und langfristig durchsetzen, auch wenn vorhandene, anwendungs- und systemabhängige Berechtigungsstrukturen wie beispielsweise Gruppen in Microsofts Active Directory (AD) oder SAP-Rollen dadurch nicht ersetzt werden (können).
Aktuell gibt es zudem Ansätze, generische und industriespezifische Rollensets auf der Basis von Best Practices vorzukonfigurieren. Hier stehen endgültige Ergebnisse aber noch aus.
Auch wenn seit Längerem bekannt ist, dass klar definierte und beschriebene IAM-Prozesse die Grundlage für eine effiziente Gestaltung sind, so haben sich Arbeiten hierzu nicht in gleicher Weise entwickelt wie zum Beispiel zu Berechtigungsstrukturen. Die Ursache hierfür ist unter anderem darin zu sehen, dass sich diese Prozesse über verschiedene Bereiche innerhalb und möglicherweise auch außerhalb eines Unternehmens erstrecken, einzelnen Einheiten jedoch meist nur Ausschnitte des Gesamtprozesses bekannt sind.
Es gibt zwar etliche Werkzeuge, welche die Umsetzung von Prozessen durchaus gut unterstützen – dies enthebt ein Unternehmen aber dennoch nicht von der Notwendigkeit der Definition dessen, was implementiert werden soll. Wie jede (Geschäfts-)Prozessanalyse und -definition ist dies in vielen Unternehmen bisher kein einfaches Unterfangen gewesen.
Hier hat sich in den letzten Monaten durchaus einiges verändert: Seit etwa einem Jahr gibt es eine Arbeitsgruppe ( www.genericiam.org), bestehend aus rund 25 Anwendern, Herstellern, Analysten, Forschungsinstituten und Beratungshäusern, die sich zum Ziel gesetzt hat, die Erfahrungen der Beteiligten in Standards für IAM-Prozesse umzusetzen. Die Zusammensetzung dieser Arbeitsgruppe gewährleistet die Umsetzbarkeit und Praxisnähe der erzielten Ergebnisse, die zudem auch einem internationalen Umfeld gerecht werden. Erste Resultate befinden sich derzeit in der Qualitätssicherung und sollen demnächst für die Öffentlichkeit freigegeben werden.
Für IAM-Funktionen wie Provisioning, Rollenmanagement, Reporting pder Web Single Sign-on gibt es etliche Produkte, die diese Funktionen unterstützen. Hier wird die Entwicklung vor allem in Richtung der Benutzerfreundlichkeit und Kompatibilität mit anderen Produkten gehen.
In Sachen Identity Federation ist der deutschsprachige Raum allerdings noch nicht so weit entwickelt, wie er von einigen Herstellern gerne gesehen würde. Es gibt durchaus einige Musterbeispiele, eine weitere Verbreitung wird aber noch etwas auf sich warten lassen. Dies liegt unter anderem an der Schwierigkeit, die notwendigen vertraglichen Grundlagen zwischen Unternehmen und die technischen Voraussetzungen in den Unternehmen zu schaffen. Viele sind aktuell noch mit einem internen IAM-Programm weitgehend ausgelastet. In der Zwischenzeit schreitet die Standardisierung der für Federation notwendigen technischen Schnittstellen voran (siehe Kasten und [9]) – langfristig wird es sicherlich einen erhöhten Bedarf hierfür geben.
Im Zusammenhang mit IAM wird in letzter Zeit häufig auch der Begriff Service Oriented Architecture (SOA) verwendet. Wenn man sich die Definition von SOA anschaut (vgl. Glossar), so ist ein Zusammenhang leicht erkennbar. IAM-Funktionen können durchaus als Dienste im Sinne einer SOA verstanden werden, zum Beispiel kann die Nutzerverwaltung als anwendungsunabhängiger Dienst mit den entsprechenden Service-Vereinbarungen von zentraler Stelle in einem Unternehmen angeboten werden, an die sich neue Anwendungen und System anbinden lassen. Es wird aber – insbesondere von Herstellern – durchaus auch diskutiert, ob IAM-Funktionen die Grundlage für eine unternehmensweite SOA darstellen; hier sind noch weiterführende Untersuchungen notwendig.
Die Sichten auf für IAM relevante Informationen entwickeln sich derzeit von einer systemzentrierten Sicht (z. B. wer hat welche Rechte auf dem Host?) über eine applikationzentrierte Sicht (z. B. wer hat welche Rechte und Rollen in SAP?) hin zu einer auf den einzelnen Nutzer bezogenen Sicht (welche Rechte und Rollen hat Kollege Meier in welchen Anwendungen des Unternehmens – und warum?).
Diese Veränderung der Sichtweise hat zur Folge, dass für ein entsprechendes Reporting die notwendigen Informationen zumindest virtuell an einer zentralen Stelle zusammengeführt werden müssen. Sofern andere Dienste des IAM wie Provisioning von zentraler Stelle angeboten werden, lassen sich die relevanten Informationen natürlich hierüber gewinnen. Dies gilt allerdings nur für die an diese Dienste angebundenen Anwendungen und Systeme. Aufgrund regulatorischer Anforderungen werden nutzerzentrierte Berichte in Zukunft zwingend notwendig sein.
Mit den Veränderungen zum Beispiel bei den Berechtigungsstrukturen wurden und werden auch neue Werkzeuge notwendig, welche die entsprechenden Funktionen unterstützen. Eine CSC Studie zum Identity-Management [7] hat bei den Produkten namhafter Hersteller untersucht, wie gut diese kontextabhängige Berechtigungsstrukturen und die Durchführung von Prozessen für IAM unterstützen; ein aussagekräftiges nutzerzentriertes Reporting stand ebenso auf dem Prüfstand. Die Ergebnisse zeigen, dass es heute durchaus solide Werkzeuge gibt, aber auch noch Potenzial für Verbesserungen vorhanden ist.
Hier war gerade in den letzten Monaten bei vielen Herstellern ein richtiger Schub zu beobachten: Die Trennung zwischen den Produktsuiten einiger Hersteller und den Produkten kleinerer Hersteller für einzelne IAM-Dienste verschwimmt zusehends, da die Zusammenarbeit, zumindest der großen mit den kleineren, in starkem Maße zunimmt. Ein Beispiel hierfür sind Integrationen von Rollenmanagement-Produkten kleiner Hersteller und Provisioning-Werkzeuge großer Hersteller. Durch diese Entwicklung lassen sich benötigte Komponenten baukastenartig den jeweiligen Bedürfnissen entsprechend zusammensetzen und mit bestehenden Infrastrukturelementen integrieren.
Einen weiteren guten Überblick über Produktsuiten und Produkte für einzelne Dienste gibt der Burton Group Research Report von M. Neuenschwander [8].
----------Anfang Textkasten----------
----------Ende Textkasten----------
Das Themenfeld IAM haben nahezu alle Unternehmen als wesentlich für die weitere Unternehmensentwicklung erkannt; einige haben das Thema sogar als strategisch relevant für ihren Unternehmenserfolg identifiziert. Aus der Sicht von CSC und aktuellen Best Practices lassen sich die folgenden Handlungsempfehlungen für ein erfolgreiches IAM-Programm herleiten.
Was banal klingen mag, erweist sich als wesentlich für den Erfolg: eine Analyse der gegenwärtigen Situation des IAM hinsichtlich der drei Kernkomponenten Prozesse, Regelungen und IT-Infrastruktur im Unternehmen durchzuführen! Initiiert werden kann eine solche Untersuchung aus verschiedenen Bereichen heraus, möglich sind hier unter anderem die IT-Abteilung, der CISO oder die IT-Revision.
Ein guter Ansatz für diese Analyse ist es, die wesentlichen IAM-Prozesse für die geschäftskritischen Anwendungen im Unternehmen beziehungsweise für dessen Zugriffsverwaltungssysteme durchzuspielen. Neben den Basisprozessen wie "ein neuer Mitarbeiter kommt ins Unternehmen" sollten dies auch Prozesse sein wie "eine Abteilung beschäftigt einen externen Mitarbeiter in einem Projekt" oder "ein Lieferant mit Zugriff zur Applikation XYZ stellt einen neuen Mitarbeiter ein".
Die Auswahl aus einigen Basisprozessen und bis zu mehreren Dutzenden weiteren Prozessen sollte angemessen an die Anforderungen des Unternehmens und der beteiligten Bereiche erfolgen. Neben den bereits genannten Abteilungen gehören dazu die Personalabteilung und ausgesuchte Mitarbeiter und Vorgesetzte in wichtigen Geschäftsfeldern. Zusätzlich sind vorhandene ausländische Niederlassungen in die Analysen mit einzubeziehen.
So wird effizient der aktuelle Stand der Prozesse, Regelungen und vorhandenen IT-Infrastruktur ermittelt. Dabei stellt sich häufig heraus, dass gerade in global agierenden Unternehmen bereits gute Strukturen, Initiativen und Projekte vorhanden, aber nur einem kleinen Kreis bekannt sind. Auf diesen können die späteren IAM-Schritte aufgebaut werden! Natürlich werden sich auch Defizite zeigen, diese lassen sich aber mit den nachfolgenden Maßnahmen beseitigen.
Wichtig für die Gestaltung des IAM-Programms ist eine Vorstellung davon, wie IAM zukünftig in der Organisation aussehen soll. Dabei bilden die Standpunkte der verschiedenen Beteiligten die Basis. Dies können zum Beispiel Aussagen sein wie: "Wenn ein Mitarbeiter neue Rollen benötigt, so kann er diese über eine zentrale Stelle beantragen (Mitarbeiter)" oder "Die Zufriedenheit der Nutzer mit dem Service IAM kann durch eine Automatisierung des Beantragungsprozesses messbar gesteigert werden (IT-Abteilung)" oder "Die Kosten für den IT-Dienstleister werden durch eine Automatisierung des Provisioning um 25 % gesenkt (Geschäftsführung)".
Viele weitere solcher Visionen und Ziele sind denkbar. Welche davon realisierbar sind, wird auf der Basis der Analyse und von Best Practices bestimmt. Hierzu gehört in einem tragfähigen Gesamtkonzept die Definition der Soll-Prozesse und der Regelungen ebenso wie die Entwicklung einer IT-Architektur, in welche die vorhandenen Systeme sinnvoll eingebunden sind und die Möglichkeiten bietet, neue IAM-Dienste durch weitere Komponenten zu integrieren.
Für die verschiedenen Anteile der Lösung sind die Verantwortlichkeiten zu den Geschäftbereichen, der IT und der Personalabteilung entsprechend den Aufgaben und Kompetenzen festzulegen. Als sehr hilfreich hat sich zudem erwiesen, ein gemeinsames Forum im Unternehmen für die vorhandenen Strukturen, Initiativen und Projekte zur Verfügung zu stellen, das einem Erfahrungsaustausch und der kontinuierlichen Weiterentwicklung des IAM dient.
Aufbauend auf dem Gesamtkonzept sollte dann ein Stufenplan für die Umsetzung festgelegt werden. Welche Prioritäten man dabei wählt, hängt durchaus von unternehmensspezifischen Faktoren ab: Auch wenn inhaltlich manchmal eine andere Reihenfolge in der Entwicklung wünschenswert wäre, so gibt es doch Nebenbedingungen wie etwa Anforderungen durch Wirtschaftsprüfer, gewisse Aktivitäten vorzuziehen.
Von Beginn an sollte begleitend ein Paket definiert werden, das die Akzeptanz der Beteiligten erhöht – und das werden zu einem gewissen Zeitpunkt alle Mitarbeiter des Unternehmens sein.
Viele Unternehmen sind sich heute des Themas IAM bewusst und haben entsprechende Initiativen gestartet. Erfolgsfaktoren für ein IAM-Programm sind neben dem beschriebenen Vorgehen eine entsprechende Unterstützung des Managements, die angemessene Einbindung aller Beteiligten über die IT hinaus sowie eine solide Ist-Analyse und eine akzeptierte IAM-Vision. Der Markt unterstützt IAM-Programme heute schon durch eine Vielzahl nützlicher Werkzeuge; für die nahe Zukunft sind weitere Verbesserungen und Hilfen bereits abzusehen.
Dr. Angelika Steinacker (asteinac@csc.com) ist Solution Architect Security bei der CSC Deutschland Solutions GmbH.
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2007#3, Seite 15
tag:kes.info,2007:art:2007-3-015