Identity Management

Irrtümer über IdM und seine Komponenten

 

1. „Jeder IT-Mitarbeiter kann das IdM-Projekt leiten!“

Die Einführung eines Identity-Management-Systems (SIAM) ist ein hochkomplexes Projekt:

  • IT und Fachbereich definieren gemeinsam neue Verfahren, um Accounts und Berechtigungen einfacher zu verwalten.
  • IT und Revision definieren Auditverfahren.
  • Viele unterschiedliche Applikationen werden mit ihren Benutzerverwaltungen in das IdM integriert.

Um diese Prozesse leiten zu können, muss der Projektleiter des Kunden das Unternehmen inklusive seiner Organisation intensiv kennen. Er muss eine Vorstellung davon haben, wie die einzelnen Applikationen verwaltet werden, und sollte in der Lage sein, Sprachbarrieren zwischen IT und Fachabteilungen abzubauen.

2. „Unsere Sicherheitslücken sind durch Security Software gestopftt!“

Ohne Zweifel sind Virenscanner oder Firewall wichtige Elemente der IT-Security. Aber sie helfen nicht, wenn es um Lücken im Authorisierungsmanagement (Zugangs- und Zugriffssteuerung) geht. Die Praxis zeigt aber, dass gerade im AD in der Regel ¼ aller Einträge (Accounts und Berechtigungen) fehlerhaft sind und die ideale Angriffsfläche für Datenmissbrauch, auch von internen Mitarbeitern, bilden. Führt dann eine Sicherheitslücke zum Schadensfall, ist das Unternehmen haftbar.

3. „Missbrauch finde ich, indem ich ungenutzte Accounts suche!“

Ein gefährlicher Trugschluss, der nur für Nicht-ITler beruhigend wirkt, denn: Accounts, deren Status „unbenutzt“ sind, werden im Moment nicht missbraucht (trotzdem sollten sie entfernt werden!). Accounts, die missbraucht werden, sind dagegen aktiv!

4. „Wer LDAP einsetzt, hat IdM bereits im Griff!“

Ein System, das LDAP als Protokoll nutzt, kann die Authentisierung (Anmeldung) oder ein zentrales Repository für Identitätsdaten darstellen. Ein SIAM (Secure Identity & Access Management) bietet dagegen zusätzlich

  • ein Workflowmanagement-System (Anträge, Freigabe, etc.),
  • eine solide Regel-Engine mit erweitertem Busninessrollenmanagement,
  • eine Audit-Funktionalität mit Historisierung (reine Directory-basierende Systeme können das nicht).

Ausserdem fehlt dem LDAP die hochintegrative Systemanbindung zur Provisionierung anderer Systeme.

5. „Account-Informationen mit dem Directory austauschen reicht!“

Die Konsolidierung der Benutzersteuerung, beispielsweise mit einem Active Directory, reicht nicht. So bleibt die Prozessteuerung (Workflowmanagement) unberücksichtigt und es werden nur Teilbereiche (einzelne Systeme) der Berechtigungsvergabe abgedeckt. Dem Active Directory fehlen Audit, Business-Rollenmanagement und eine hochintegrative Systemanbindung zur Provisionierung anderer Systeme.

6. „Eine Zentralisierung der Systemadministration ist ein Gewinn!“

Sicherlich ist die Zentralisierung von Services ein Gewinn – schon allein um die ITIL-Funktionen Incident-, Change- und Demand Management zu erfüllen. Aber ein SPOC (single point of contract) besitzt nur reaktive Funktion, d.h. er reagiert nur auf Bestellungen. Eines der grössten Probleme im IT-Security-Management stellen aber die fehlenden Abbestellung von Berechtigungen dar. Ein IdM (SIAM-)-System ist dagegen in der Lage, auch den Entzug zu unterstützen.

7. „IdM ist SSO, und SSO einzuführen ist eine ‚low hanging fruit‘.“

Single Sign-On ist nur eine Teilkomponente eines IdM- (SIAM-) Frameworks. Es vereinfacht NUR die Authentisierung der Anwender und bietet ein rudimentäres Password-Management. Die Erstinstallation ist zwar überschaubar, die notwendige Managementkomponente („Wer darf SSO nutzen?“, „Welche Applikationen darf welcher User nutzen?“, etc.) ist dagegen schon aufwändiger. Darüber hinaus ist eine Zwei-Faktor-Authentisierung, z.B. per Smartcard, kaum zu umgehen, weil ein mögliches Ausspähen eines SSO-Passwortes unter Umständen den Komplettzugang ermöglichen würde. Dann stehen aber die hohen Lizenzkosten meist in keinem Verhältnis zum Nutzen. Ein echtes „Single Sign-On“ lässt sich oft aufgrund der technischen Komplexität der vielfältigen Systeme (AD, LINUX, HOST, SAP, Mobile Devices, Web-Applikationen, gehostete Systeme) und der Masse der Systeme schwer bis gar nicht erreichen.

8. „Ein ‚Webshop‘ liefert ein IdM!“

Dies denken viele – dabei vergessen Sie, dass sich der Webshop nicht für die Aberkennung von Rechten eignet. Die Praxis zeigt aber: Auch mit den besten Richtlinien lässt sich nicht garantieren, dass sich der verantwortliche Fachbereich um die Aberkennung der Rechte kümmert. IdM-Systeme arbeiten dagegen präventiv und verlässlich.

9. „Durch IdM ist die Compliance automatisch gewährleistet!“

Nicht zwingend, denn: Identity-Produkte haben viele verschiedene Bausteine und können sehr unterschiedlich customized werden. Wer ein Historienführungstool in sein IdM-Systems integriert (die meisten Produkte beinhalten bereits ein solches), hat den ersten Schritt zur Compliance gemacht. Dann müssen IST- (was findet sich aktuell an Benutzerberechtigungen in den Systemen) und SOLL-Zustand (was dürfte nach Richtlinie gesetzt sein) hinterlegt werden. Damit kann das Audit Tool regelmässig die Differenz zwischen IST und SOLL anzeigen und die IT eventuelle Lücken auffinden und schliessen. Erst wenn der IST-Zustand dem SOLL-Richtwert entspricht, ist die IT-Compliance gewährleistet, vorher nicht.

10. „Reporting ist gleich Audit!“

Reporting zeigt den Zustand von Accounts und Benutzerberechtigungen in den Systemen auf. Aber die risikoreichen Berechtigungen, die von der Regel abweichen, findet man nur im Vergleich mit dem SOLL-Zustand. Diesen muss der Fachbereich definieren und kontinuierlich prüfen. Darüber hinaus ist der Vergleich von SOLL- und IST-Zustand inklusive der Markierung der Differenzen für ein Audit nötig. Nur so können Schwachstellen gefunden und behoben werden.

Um den Fachbereich zu entlasten (von Prüfungsarbeit bzgl. Berechtigungen) und den Berechtigungszustand zeitnah zu validieren sowie historisiert zu dokumentieren, kommt man um eine technische Unterstützung zur Bewältigung der Masse nicht herum. 

11. „Re-Attestierungen bzw. Audit Trails ersetzen ein IdM!“

Der Vorgesetzte kann eine Liste möglicher Berechtigungen (z.B. 15 Systeme á 1000 Berechtigungsmöglichkeiten) nicht wirklich handhaben. Daraus würde ein hoher Einarbeitungsaufwand gepaart mit geringer Bereitschaft („Ich habe Besseres zu tun!“) entstehen. Ein solches Verfahren scheitert aufgrund mangelnder Akzeptanz.

12. „Sich auf den ‚internen Mitarbeiter‘ beschränken reicht!“

Wer dies denkt, vergisst die externen Dienstleister, Servicekräfte, Lieferanten oder Outsourcer. Darüber hinaus stellt sich die Frage, wie die technischen Accounts oder Funktionsaccounts unter Kontrolle gebracht werden sollen.

13. „Zur Dokumentation der Berechtigungsvergabe genügt die Beschreibung der ‚Neu-Anlage‘!“

Die „Veränderung“ ist bei weitem die häufigste Form der Berechtigungsvergabe im User Life Cycle. Die Praxis zeigt: Mehr als 90% aller Berechtigungsanpassungen resultieren aus Funktionsänderungen, OE-Wechseln und Projektzugriffen – jeweils mit Zu- und Aberkennung. Die Neuanlage ist dagegen aus Sicht der IT-Security meist unkritisch.

14. „’Setup.exe‘ und ein paar ‚Blueprints‘ – schon steht mein IdM.“

Mit dieser Behauptung werben Hersteller. Dabei blenden sie die notwendige Einbindung der Fachbereiche, die für die Berechtigungsvergabe verantwortlich sind, aus. Managementprozesse und Workflows sind zu implementieren. Diese müssen individuell erstellt werden, weil sie sich, schon allein aufgrund der Branchenzuordnung, an unterschiedlichen Richtlinien orientieren müssen – Banken und Versicherung haben andere rechtliche Auflagen als Baustoffhändler. Man kann nicht einfach Prozesse überstülpen, da sie sonst nicht angenommen und umgangen werden.

Eine gemeinsame Prozessdefinition von IT und Fachbereich ist erforderlich. Genau das gleiche gilt für die Definition von Fachrollen und Regeln.

15. „IdM ist Aufgabe der IT-Abteilung!“

Die IT setzt operativ die Berechtigungsanforderung der Fachabteilung um (Bestellung, Abbestellung, etc). Für ein sicheres Berechtigungsmanagement braucht der Fachbereich aber Unterstützung bei der Formulierung seiner Berechtigungsanfordungen. Weil die präzise Beschreibung der nötigen Rechte nicht einfach ist, weil falsche Anforderungen nirgends korrigiert werden und weil der Fachbereich für seine Bestellungen gerade stehen muss. Der Einsatz einer Fach-Rollenmodellierung ermöglicht dem Fachbereich ein verantwortungsvollen Umgang mit seiner Aufgabe. Aber schon allein die Kombination von Bottom-up- und Top-dow-Methodiken zur Rollenmodellierung zeigt: Rollenmodellierung ist kein Kinkerlitzchen, sondern die Königsklasse für Fachbereich und IT.

16. „Ein OE-Wechsel ist trivial!“

Der Entzug der Berechtigung aus der alten Organisationseinheit kann nicht zu einer Art Stichtag gewechselt werden, da alte Aufgaben noch abgeschlossen werden müssen, obwohl der Mitarbeiter schon in der neuen Organisationseinheit arbeitet. Allein die Tatsache, dass der Mail Account weitergeführt werden muss (wer lässt sich schon gern wegen eines Abteilungswechsels die Mailbox weglöschen?), zeigt, wie praxisfremd der Ansatz „alles weg“ ist. Eine flexibles Verfahren, das über den Stichtagsgedanken hinaus geht, muss gefunden werden.