Computerpartner

  
Sie befinden sich hier: HOMENachrichtenServiceIm Gespräch
02.12.2016

Pragmatisch gelöst

Die effektive und effiziente Verwaltung von Identitäten und ihren Berechtigungen gewinnt für die Sicherheit der Daten und Abläufe in der öffentlichen Verwaltung immer mehr an Bedeutung; von Hadi Stiel *)

Mathias Hein

Zur Vergrößerung anklicken

Andreas Martin

Das Management von Identitäten und Berechtigungen muss nicht kostspielig und aufwendig sein. Wäre da nicht der große Nachteil klassischer , über die Jahre gewachsener IAM (Identity and Access Management)-Offerten. Sie sind mittlerweile so komplex, funktionsreich und durch zu viele Synchronisationsprozesse so fehleranfällig geworden, dass sie, wenn überhaupt, nur äußerst aufwendig und kostspielig geplant, umgesetzt, betrieben und weiterentwickelt werden können.

Hinzu kommt bei diesen Offerten eine Lizenzpolitik der Hersteller, die die Realisierungs-, Betriebs- und Weiterentwicklungskosten weiter in die Höhe treibt. Weitere Folgen bleiben nicht aus: IAM, als gesamtheitlicher Ansatz angedacht, ist in den meisten Verwaltungen bis heute Stückwerk geblieben, auf Kosten der Sicherheit von Daten und Abläufen sowie der nachweislichen Einhaltung von IT-Governance- und IT-Compliance-Vorgaben. Dies alles muss nicht sein.

Im Gespräch Andreas Martin, Vorstand und CEO des Consulting-Unternehmens FirstAttribute AG. Er gibt wertvolle Anregungen, wie Verwaltungen den vielen Nachteilen klassischer IAM-Systeme von vornherein aus dem Weg gehen können. Er zeigt auf, wie eine schlanke, zeitgemäße Lösung zur Verwaltung von Identitäten und ihren Berechtigungen sowie zum Mitschnitt (Logging) und zur Auswertung (Auditing) sämtlicher Zugriffe auf Anwendungen und Systeme konzipiert und aufgebaut sein sollte.

Wie sollte das grundsätzliche Konzept einer solchen Lösung aussehen?

Andreas Martin: Die Benutzer sollten im Mittelpunkt einer solchen Lösung stehen, demzufolge das Portal als Benutzerschnittstelle.  Daraus ergeben sich weitere Anforderungen an die Lösung: eine selbsterklärende Benutzeroberfläche, unter der sich sowohl die normalen Benutzer in Eigeninitiative (Self-Service) als auch die  Administratoren schnell zurecht finden. Dazu sollte aus dem Blickwinkel der Benutzer auch ein einfach und dennoch sicher handhabbarer Passwort-Self-Service zählen.

… und unterhalb dieses Portals als Benutzerschnittstelle, um damit die grundsätzliche Architektur der Lösung anzusprechen?

Martin: Darunter sollten die Module "Active Directory Provider", "Power Shell Provider" und der "Logging-/Auditing-Service" als Standardimplementation angesiedelt sein.  Das Modul "Active Directory Provider" trägt der Tatsache Rechnung, dass in den meisten Verwaltungen ohnehin das Microsoft-Verzeichnis Active Directory im Einsatz ist, zudem darüber auch andere Microsoft-Dienste wie Office 365 respektive AzureAD einfach eingebunden werden können. Wieso also nicht den Defakto-Standard Active Directory oder AzureAd als zentralen Verzeichnisdienst nutzen und die bestehenden Funktionen der Microsoft-Welt wie Active Directory Federation Service (ADFS) und Microsoft Identity Manager (MIM)-Konnektoren verwenden. Zumal Active Directory und solche Funktionen in der Regel in den bestehenden Microsoft-Kundenlizenzen bereits enthalten sind. Diese Strategie erspart, auf andere, kostenintensive Implementationen setzen zu müssen.

Welche Vorteile birgt der Power Shell Provider für Verwaltungen in sich?

Das Modul Power Shell Provider ist einerseits die ideale Instanz, um weitere Microsoft-Zielsysteme ins zentrale Active Directory zu integrieren. Über sogenannte Power Shell Extensions können auch andere Zielsysteme wie NetApp, einfach in die Lösung eingebunden werden. Der Reiz dieser Einbindung besteht darin, dass er, im Gegensatz zu herkömmlichen Konnektoren, keine Lizenzkosten nach sich zieht und den Einsatz komplizierter, fehleranfälliger und zudem nur zeitversetzt arbeitender Synchronisationen erspart. Jeder Eintrag, der im Active Directory durchgeführt wird, wird parallel und automatisch über den Power Shell Provider in die betroffenen Zielsysteme geschrieben. Zudem bietet der Markt Power Shell Extensions, über die auch Nicht-Microsoft-Zielsysteme in gleicher Weise eingebunden werden können. Darüber hinaus eröffnet der "Power Shell Provider" die Verwaltung sämtlicher Identitäten und ihrer Berechtigungen mittels Rollen. Mittels Rollen können Identitätsgruppen nicht nur auf einfache Art und Weise Berechtigungen zugewiesen werden. Sie machen auch eine einfache Delegation möglich. Darüber kann unter anderem Fachabteilungen, Sekretariaten oder dem Empfang eingeräumt werden, neue Passwörter für die Mitarbeiter sicher zu vergeben.

Wie sollte der Logging-/Auditing-Service als drittes Standard-Implementierungsmodul unterhalb des Benutzer-Self-Service-Portals funktionieren und was sind die Vor- und  Nachteile dieses Service?

Martin: In der beschriebenen Form konstruiert funktioniert der Logging-/Auditing-Service über alle Zielsysteme der Microsoft-Welt sowie über andere Zielsysteme, die über Power Shell Extensions eingebunden sind. Alle Logs dieser Zielsysteme fließen in eine SQL-Datenbank, Teil des Logging-/Auditing-Service, ein und können darüber für interne Prüfungen sowie für IT-Governance- oder IT-Compliance-Nachweise auditiert werden. Dadurch wird zentral transparent, wer wann auf welches Zielsystem zugegriffen hat und welche Aktivitäten die Zugreifer darin ausgeführt haben.

Anders sieht es aus, wenn Zielsysteme außerhalb des Benutzer-Self-Service-Portals mittels MIM-Konnektoren eingebunden sind. Der Mitschnitt und die Auditierung gegenüber diesen Zielsystemen erfolgt dann über die Logging-Mechanismen der MIM-Konnektoren, die Auswertung der Logs über Microsoft-Bordmittel. Auf Anforderung der öffentlichen Verwaltung  können die Informationen aus dem MIM-Logging in die zentrale Logging-Datenbank des Portals überführt werden, um eine einheitliche Sicht auf Informationen und Auswertungen zu erreichen.

Können Sie näher auf die unterschiedlichen Einbindungsarten für die Zielsysteme eingehen, auf die Zugriffskontrolle ausgeübt werden soll?

Martin: Wichtige Vorteile des Power Shell Providers, für die Einbindung von Nicht-Microsoft-Zielsystemen kombiniert mit Power Shell Extensions, habe ich bereits angesprochen: gegenüber Konnektoren mit komplizierter Synchronisation keine Lizenzkosten, geringere Fehleranfälligkeit, keine zwischenzeitlich inaktuellen Einträge in den Zielsystemen durch zeitversetzte Synchronisationsläufe. Hinzu kommt bei einer Integration der Zielsysteme mittels Power Shell Provider eine deutlich geringere Komplexität des Gesamtsystems. Dort, wo Konnektoren mit aufwendiger und fehleranfälliger Synchronisation notwendig erscheinen, sollte vorab geprüft werden, ob nicht Text-/XML-Konnektoren ausreichen, um darüber einfache Synchronisationsanforderungen abzubilden. Microsoft-Infrastruktur-Services wie File, SharePoint, Exchange können außerdem über sogenannte virtuelle Attribute angesprochen werden. Für Dienste wie Notes, Home-Shares, NetApp-File-Services, Default-Groups, Namensbildungsregeln, Share-Anlagen und Gruppenberechtigungen bietet der Markt Muster-PS-Skripte, die leicht an die Einsatzanforderungen in der Verwaltung angepasst werden können. Nur bei komplexen Synchronisationsanforderungen zwischen Active Directory und Zielsystemen müssen MIM-Konnektoren zum Einsatz kommen. Ist das Benutzer-Self-Service-Portal durch kundenspezifische Provider erweiterbar, können darin weitere Zielsysteme mit speziellen Verzeichnissen integriert werden, ohne dass komplizierte Synchronisationen zum Einsatz kommen müssen.

Synchronisationsvermeidung ist also angesagt?

Martin: Ja, und dies nicht nur, um die Komplexität des Gesamtsystems deutlich herunterzufahren. Unsere Strategie als Beratungs- und Lösungshaus zielt darauf ab, Synchronisationen aufgrund der vielen Nachteile für die Anwender weitgehend zu vermeiden. Da unser IDM-Portal auf Active Directory aufsetzt, können Verwaltungen meist auf den Einsatz komplexer Konnektoren verzichten. Eine ähnliche Vermeidungsstrategie fahren wir auch gegenüber Workflows, beispielsweise Berechtigungs-Workflows, die ebenfalls auf komplizierten Synchronisationen beruhen. Unter dem Benutzer-Self-Service-Portal können gemäß dem Delegierungsprinzip Aufgaben viel einfacher und zudem sicher einzelnen Personen zugewiesen werden. Danach können ihre Zugriffsaktivitäten entlang der Delegierungslogik lückenlos an zentraler Stelle auditiert werden. Weiterer positiver Nebeneffekt der einfachen Delegierung: Jeder Benutzer kann seine Berechtigungen konform der Rolle, die ihm der Administrator zugewiesen hat, selbst verwalten. Verfechter von Workflows können diese dennoch über Web-Services ins IDM-Portal einbinden.

Verwaltungen suchen für das Management von Identitäten und ihren Berechtigungen zunehmend Unterstützung bei Cloud-Anbietern, weil sie sich davon vor allem Kosteneinsparungen versprechen. Inwieweit räumt ein so konzipiertes und gebautes Benutzer-Self-Service-Portal ein Zusammenspiel mit Cloud-Anbietern ein?

Martin: Was für das verwaltungsinterne Identitäten- und Berechtigungsmanagement Active Directory als zentrales Verzeichnis ist, ist für das Zusammenspiel von eigener IT mit der von Cloud-Anbietern das Azure Active Directory. Es sollte neben Active Directory ebenfalls Standard-Implmentierungsmodul der Portal-Lösung sein. In diesem Fall muss auch für dieses Zusammenspiel keine separate Verzeichnisinfrastruktur aufgebaut werden und der Einsatz von Konnektoren mit Synchronisation entfällt weitgehend. Die Verwaltung kann direkt die Cloud-Funktionen von Azure Active Directory nutzen, um darüber beispielsweise Dienste von Drittherstellern abzurufen. Wichtig ist, dass das eigene Portal einen einfachen Zugang zum Management des Azure Active Directory erschließt. Will die Verwaltung die Dienste des entfernten Azure Active Directory nicht nutzen, bleibt immer noch die Authentisierung mittels Security Assertion Markup Language (SAML) und Microsoft ADFS. Diese Alternative hat für die Verwaltung den Charme, dass keine Passwörter an den Cloud-Anbieter übertragen werden müssen. Im Zusammenspiel mit Google-Clouds kann die Verwaltung für die Authentisierung ihrer Mitarbeiter mittels SAML auf das eigene Active Directory zurückgreifen, wodurch ebenfalls keine Passwörter an den Cloud-Anbieter übermittelt werden müssen.

Wenn die Benutzer selbst ihre Identitäten und Berechtigungen pflegen und verwalten und untereinander flexible Delegationen möglich sind, was verbleibt dann für die Administratoren unter einem so konzipierten und umgesetzten Benutzer-Self-Service-Portal noch zu tun?

Martin: Wenn die Verwaltung konsequent den Weg eines umfassenden Benutzer-Self-Service beschreiten will, dann müssen sich die Administratoren nur noch um die Konfiguration von Regeln für die Zugriffskontrolle, die Definition der Rollen für die einzelnen Benutzergruppen und die Zusammenstellung von Power Shell-Skripten und Templates für eine automatisierte Abwicklung sämtlicher Aktionen unter dem Portal kümmern.

*) Hadi Stiel ist freier Journalist und Kommunikationsberater in Bad Camberg
 +