Anforderungen an ein IAM

Die Notwendigkeit bzw. der Zwang sich mit dem Thema einer zentralen Verwaltung aller Personen zu befassen, die in irgendeiner Weise Ressourcen eines Unternehmens oder sonstiger Institutionen nutzen, in der Gesamtheit und über alle Ressourcen zu verwalten und auch zu kontrollieren, hat verschiedene Gründe beziehungsweise Ursachen.

1. Zunehmende gesetzliche und sonstige regulatorische Vorgaben. Diese können generell (etwa KRITIS aus dem IT-Sig 2.0, DSGVO) oder branchenbezogen (MaRisk für Banken) gelten.
2. Die Ausweitung der Kategorien von Personen, die in diese Betrachtungen einzubeziehen sind. In der Vergangenheit wurden nur interne Mitarbeiter und evtl. noch externe Mitarbeiter betrachtet. Jetzt müssen auch Personen anderer Unternehmen (Kunden. Lieferanten usw.) in  diese Verwaltung und Kontrolle mit einbezogen werden.
3. Die zunehmende mobile Arbeitsweise löst die IT-Grenzen um die Ressourcen des Unternehmens weitgehend auf. 
4. Letztlich sind die Daten eines Unternehmens zunehmend auch relevante Ressourcen, die eines besonderen Schutzes bedürfen. 

Rechenzentren müssen sich mit der Tendenz der IT-Nutzung aus der Cloud auseinandersetzen und ihren Kunden weitergehende Services bereit stellen, wenn sie in der Zukunft wettbewerbsfähig bleiben wollen.

Der Druck, ein IAM einzusetzen bzw. einen erweiterten Einsatz vorzusehen, kommt also aus verschiedenen Richtungen, womit sich dann auch die für das Unternehmen entscheidenden Ziele definieren und differenziert bewerten lassen.

Ein leistungsfähiges IAM  sollte insbesondere diese Anforderungsbereiche optimal abdecken:

• IT- Automatisierung / Aufwands- und Kostenreduzierung
• Security, Compliance, Reporting
• Spezialfall: KRITIS-Unternehmen
• Usability und Erweiterung der Userklassen
• Serviceportal und ESM-Strategie

Alle diese Anforderungen und IAM-Ausprägungen können nicht isoliert voneinander betrachtet werden. Da sie aber im Projekt sinnvoller Weise schrittweise nach einem Phasenkonzept eingeführt werden, bestimmt die Wertung dieser Bereiche durch das Management den Phasenplan der Einführung.

Aktuelle technologische und Marktentwicklungen

Bei einer Einsatzplanung für ein IAM sind die Entwicklungen der Technologie und die sich daraus ableitende Marktentwicklung unbedingt zu berücksichtigen.  Die Nutzung vieler Systeme aus der Cloud muß durch ein IAM gut abbildbar sein und letztlich sollte ein IAM auch aus der Cloud nutzbar sein.

Dazu kommen Entwicklungen im Access-Management, die etwa die Nutzung eines ID-Providers im Rahmen eines IAM als sehr sinnvoll erscheinen lassen. Aus den Anforderungen an ein sicheres Access-Management insbesondere für externe User sind einige Anbieter sog. C-IAM-Lösungen am Markt erschienen.

Ein IAM unterstützt auch die Tendenz, die alten Applikations-Silos aufzulösen und mit bestimmten Funktionen in diese „einzudringen“. Das betrifft insbesondere die zeitnahe Synchronisation des
User-Life-Cycles. Wenn ein User das Unternehmen verläßt oder auch nur den Bereich wechselt muß diese Information nicht nur vom IAM sondern auch von allen anderen Applikationen verarbeitet werden. 

Im folgenden werden diese aktuellen Anforderungen durch die dafür erforderlichen Funktionen untersetzt.

Allgemeine Architektur-Anforderungen an ein IAM

Das IAM basiert auf einer professionellen Datenbank und die Kernfunktionen wie die Workflow-Engine, der Transaktionsmanager und weitere interne Kern-Funktionen, wie das Regelwerk usw. sind serverbasiert und agieren mittels Connectoren mit den Zielsystemen. Die Verwaltungsfunktionen werden berechtigungs-gesteuert in einem Web-Client zur Verfügung gestellt. Die interne Programmlogik muß eine hohe Transaktionssicherheit bieten.

Eine geeignete Systemüberwachung stellt den kontinuierlichen Betrieb sicher und generiert Alerts bei System-Problemen. Das IAM muß sowohl aus der Cloud nutzbar sein als auch Cloud-Anwendungen selbst provisionieren (Salesforce, Azure, Amazon…)

Ziel eines IAM ist es, die Ebene der Fachlichkeit von der Systemtechnik eindeutig zu trennen. 

Einem Mitarbeiter und seinem Leiter steht im IAM die Funktionalität des sog. Business Layers zur Verfügung. Die Systemtechnik stellt die Applikationen und deren Berechtigungen dem Business-Layer zur Verfügung.

Durch die technische Skalierbarkeit kann das IAM an wachsende Anforderungen (Performance, Transaktionssicherheit und Verfügbarkeit) angepaßt werden können. Diese technische Skalierbarkeit ist in zwei Dimensionen zwingend erforderlich:

1.Parallelisierung der Prozesse

Durch das reale mengenhafte Auftreten von Prozess-Aktivitäten (etwa mehreren Tausend Usern eine Rolle zuordnen) kann ein singulär arbeitendes IAM sehr schnell zu einem internen Deadlock kommen, da die Abarbeitung dieser Prozesse intern extrem Ressourcen benötigt und somit das System für Stunden nur diese Prozesse abarbeitet und eine evtl. wichtige Passwort-Aktion so lange warten muß, bis diese Prozesse alle abgearbeitet sind. 

Eine Prozess-Engine muß also in mehreren Instanzen laufen, um alle anstehenden Prozesse schneller abarbeiten zu können als auch eine weitere Instanz für andere Aktionen offen zu halten.

2. Priorisierung

Die verschiedenen Operationen eines IAM müssen priorisiert werden können, um deren sequentielle Abarbeitung so zu ordnen, daß bestimmte Operationen vorrangig bearbeitet werden. Dies betrifft etwa Passwort-Operationen. Hier kann ein User nicht Minuten warten, bis sein PW gewechselt ist und er weiterarbeiten kann.

3. Batch-Prozesse

Eine Art der internen Skalierung ist es auch anstehende und damit planbare Mengenoperationen in einer Art Batch-Prozess dem System zu übergeben. Diese werden dann zeitgesteuert evtl. in betriebsarmen Zeiten oder in einer separaten Instanz abgearbeitet

4. Predefined operations

Bestimmte Operationen lassen sich gewissermaßen vorbereitend ausführen. Im Ergebnis werden die Operationen zwar komplett ausgeführt, stehen jedoch in einem Status, der die Nutzung noch nicht ermöglicht. Der Wechsel dieses Status auf „verfügbar“ ist dann sehr schnell und für große Mengen von Objekten und Ressourcen durchführt. Dieses Verfahren ist etwa bei umfassenden Strukturveränderungen im Unternehmen zwingend notwendig. 

In einer Evaluierung von IAM-Produkten ist diesen technischen Möglichkeiten ein bedeutendes Kriterium.

Produkt-Skalierbarkeit

Ein IAM sollte aus Sicht der Funktions-Architektur als ein Framework bereitgestellt werden.

Bild1: IAM-internes Framework.

 

Im Rahmen dieses Frameworks sollten dem Kunden die IAM-Services möglichst granular geboten werden, so daß er seine IAM-Lösung bzw. sein IAM-Projekt so zusammen stellen kann, wie es seinen vorrangigen Unternehmenszielen entspricht und dies dann im Rahmen der Projektplanung auch in ein entsprechendes Phasenkonzept so einzupassen, daß die wichtigsten Funktionen relativ kurzfristig produktiv bereit stehen.

Ein IAM, das nach diesem SOA-Ansatz konzipiert ist, stellt je nach funktioneller Breite 200-300 Services zur Verfügung.

Der Vorteil eines solchen Systems liegt auf der Hand:

• Schnelle Reaktivierung der Investition
• Anforderungsgerechte Kundenbezogene Installation
• Trotz der Standardisierung der Services wird eine Individualisierung beim Kunden möglich

1. Versionierbarkeit

Ein IAM soll intern so weit standardisiert sein, daß ein Kunde im günstigsten Fall keinerlei Anpassungs-Programmierung fordern muß, da er die Integration in seine IT-Systemwelt weitgehend mit den Mitteln der Modellierung und Konfiguration erreichen kann.

Dies hat beim Versionswechsel den ganz wesentlichen Vorteil, daß dieser Wechsel weitgehend „geräuschlos“ im Laufe eines Wochenendes realisiert werden kann.

Es gibt dem gegenüber IAM-Systeme am Markt, die beim Versionswechsel monatelange Anpassungen der Skripte erforderlich machen. Deshalb sollte auch dieser Aspekt bei der Auswahl eines IAM berücksichtigt werden.

Anforderungen an die Verwaltung der User

Das IAM realisiert die zentrale Verwaltung aller Personen, die in irgendeiner Form Kompetenzen in den Prozessen des Unternehmens zugeteilt bekommen.

Dies sind in der Regel Berechtigungen definierte IT-Ressourcen zu nutzen.

Es können aber auch Funktionen in der Abwicklung definierter Prozesse sein.

Modell-Ansatz

Jede natürliche Person ist im System einmalig angelegt und wird durch eine eindeutige Identifikation geführt. Mit der Person werden Attribute verbunden, die einerseits die Person und andererseits deren Position im Unternehmen definieren.

Jeder Person (User) können dann in den IT-Systemen eine oder auch mehrere Identitäten zugeordnet werden, wobei es immer den eindeutigen Bezug jeder Identität zu der Person, die als Owner dieser Identität fungiert, gegeben sein muß. Dies ist erforderlich, um die Veränderungsprozeese im Life Cycle des Users im Unternehmen bis in die Berechtigungen an den IT-Ressourcen zeitaktuell zu projizieren.

Bild 2 verdeutlicht diesen Zusammenhang. Der User hat in 2 IT-Systemen je einen Account (Identität) und im System 3 jedoch 2 Identitäten (etwa regulärer User-Account, Admin-Account)

Bild 2: Grafische Darstellung der Zusammenhänge von User, Identität und It-Systemen.

User-Attribute

Der User wird durch einen Satz von Attributen im Detail beschrieben. Diese Attribute müssen vom Anwender frei definiert werden können.

Der User wird im Kern durch drei Attribut-Typen beschrieben:

1. persönliche Daten
2. arbeitsorganisatorische Daten
3. tätigkeitsbezogene Daten

Die persönlichen Daten sind insbesondere zur besseren Identifikation und für erweiterte Funktionen der Verwaltung (etwa Adresse) sinnvoll. Außerdem unterliegen sie einen besonderen Schutzbedarf. 

Die arbeitsorganisatorischen Daten beschreiben seine Einordnung in die Strukturen des Unternehmens.

Die tätigkeitsbezogenen Daten werden im IAM vor allem vom Regelwerk genutzt, das dem User automatisiert Berechtigungen zuordnet, die er benötigt, um seine Aufgaben wahrnehmen zu können.

Datenliefernde Systeme

In der Regel übergeben die HR Systeme die Userdaten der im Unternehmen beschäftigten Personen sowie die Änderungen am User automatisch über eine geeignete Schnittstelle an das IAM. 

Das IAM muß dann sichern, daß innerhalb des IAM diese Userattribute, die vom HR kommen, nicht verändert werden dürfen. Datenowner ist hierfür das HR-System.  In einigen Fällen können die Userdaten auch von anderen Systemen geliefert werden (etwa ein zentraler LDAP-Server).

Unabhängig von der automatischen Lieferung gibt es User (Externe, Service-Mitarbeiter, Kunden. Lieferanten), die über andere Kanäle an das IAM übergeben bzw. direkt im IAM durch eine Verwaltungsfunktion erfasst werden.

Dublettenkontrolle

Da es verschiedene Inputkanäle für Userdaten geben kann (etwa HR-System oder direkte Erfassung im IAM bzw. bei Mandantenverwaltung) ist bei jedem „Neuzugang“ eine Prüfung  erforderlich, ob es diese Person bereits im Datenbestand gibt. Diese Dublettenkontrolle muß mit hinreichender Sicherheit erkennen, ob es sich um einer Dublette handelt oder nicht. Die Auflösung einer erkannten Dublette kann in drei Richtungen erfolgen:

1. Es ist ein und dieselbe Person, dann müssen die Daten geregelt auf die bereits vorhandene Person aktualisiert werden
2. Die neu gelieferten Daten der bereits existenten Person sind u.U. trotzdem neu anzulegen und als Sonderfall (Shadow User) zu behandeln.
3. Es sind unterschiedliche Personen

Den vollständigen Fachartikel finden Sie hier im eBook “Identity & Access Management – Im Zeichen der digitalen Transformation” zum Download.