Der steigende Compliance-Druck rückt die Attestierung, also die regelmäßige Bestätigung der Korrektheit von Zugriffsberechtigungen, in den Fokus. Doch dafür ist eine ganzheitliche Sicht notwendig. Und aus den Ergebnissen der Attestierung müssen auch dauerhaft Konsequenzen gezogen werden – mit einem durchgängigen Lebenszyklusmanagement für Rollen, Benutzer, Berechtigungen.
Eines der großen Themen der IT ist derzeit die Attestierung von Zugriffsberechtigungen. Es gibt eine ganze Menge Anbieter, die mit ihren GRC-Lösungen (Governance, Risk Management, Compliance) oder Identity Provisioning-Tools auf diesen Zug aufgesprungen sind. Nur leider sind viele zu kurz gesprungen.
Denn viele der Lösungen unterstützen nur eine Ebene der Attestierung – oder zumindest nicht alle Ebenen, auf denen man eigentlich eine Attestierung vornehmen muss. Oder sie ist so gestaltet, dass sie von den definierten Verantwortlichen gar nicht sinnvoll zu leisten ist.
Dazu muss man nur einen Blick auf die vielfältigen Abhängigkeiten werfen. Es gibt Business-Rollen, es gibt Systemrollen oder -gruppen, es gibt Zugriffsberechtigungen. Und oft gibt es noch IT-funktionale Rollen als Bindeglied zwischen den Business- und den Systemrollen. Außerdem gibt es noch die Benutzer und deren Benutzerkonten.
Ein Benutzer Martin Kuppinger wird nun vielleicht Mitglied einer Business-Rolle Abteilungsleiter. Er ist gleichzeitig in der IT-funktionalen Rolle IT-Systembetrieb. Er bekommt ein Konto „MartinK“ im Active Directory. Und er wird über die IT-funktionale Rolle dort unter anderem in die Gruppe „Management Team“ provisioniert. Was diese Gruppe darf, wird faktisch von einem Systemadministrator innerhalb der Windows-Infrastruktur festgelegt. Dieser setzt beispielsweise ACLs (Access Control Lists) für ein Verzeichnis auf einem bestimmten File-Server.
Wenn man wissen möchte, ob alles korrekt ist, muss man sicherstellen, dass diese Gruppe die richtigen ACLs hat. Man muss sicherstellen, dass die richtigen Benutzer in der Gruppe sind, ebenso wie die richtigen Leute in IT-funktionalen Rollen oder Business-Rollen sein müssen. Und natürlich sollte es nur die Gruppen, Benutzerkonten, Mitarbeiter, IT-funktionalen Rollen und so weiter geben, die auch tatsächlich benötigt werden. Man muss also auf verschiedenen Ebenen verschiedene Dinge attestieren.
Manchmal muss dann jemand, der eigentlich nur weiß, dass Martin Kuppinger zur Business-Rolle Abteilungsleiter gehört, auch bestätigen, dass er zurecht bestimmte Berechtigungen im Dateisystem, in Datenbanken oder auf Transaktionen in SAP-Systemen hat. Das funktioniert natürlich nicht.
Vielmehr muss man einen mehrstufigen Ansatz wählen, der sicherstellt, dass jeder der vielen Beteiligten – der Manager für die Business-Rollen, die IT- Administratoren für die ACLs und die Identity Management-Verantwortlichen oder die Fach-IT für IT-funktionale Rollen – überprüft und bestätigt, dass alles in Ordnung ist (oder eben nicht).
Wenn man sich mit Attestierungskonzepten beschäftigt, ist die Gesamtsicht unerlässlich. Attestierung funktioniert weder, wenn jemand etwas attestieren darf, das er nicht kann (die detaillierten Zugriffsrechte, die zulässigen SAP-Transaktionen) noch wenn man nur einen Teil macht. Was bringt es zu wissen dass Martin Kuppinger zu Recht in der Gruppe „Management-Team“ ist, wenn diese längst völlig andere Zugriffsberechtigungen hat, weil ein Administrator unbemerkt oder auf Zuruf etwas geändert hat?
Attestierung ist definitiv sinnvoll. Sie muss aber richtig umgesetzt werden. Und man sollte nicht übersehen, dass man damit erst den ersten Schritt gemacht hat. Denn aus den Ergebnissen der Attestierung müssen auch Konsequenzen gezogen werden – nicht nur einmalig, sondern dauerhaft, also mit einem durchgängigen Lebenszyklusmanagement für Rollen, Benutzer, Berechtigungen. Sonst fühlt man sich zwar nach der Attestierung erst mal sicher, hat seine Probleme aber nicht wirklich gelöst. Wer also nicht auch den Schritt zu einer Steuerung, dem Autorisierungsmanagement macht, ist ebenfalls zu kurz gesprungen.