Warum die wirksamen Berechtigungen im IAM-System unsichtbar bleiben

In unseren IAM-Projekten haben wir regelmäßig mit Prüfer/-innen der internen Revision zu tun. Insbesondere während der ersten Projektschritte ereilen uns immer wieder die Fragen 

• Woran erkenne ich denn jetzt im IAM-System, ob Herr Meier auf das Share XYZ Zugriff hat? 
• Was sind aktuell seine wirksamen Berechtigungen? 

Die korrekten Antworten darauf „gar nicht, weiß nicht“ erstaunen meist ein wenig. Dabei handelt es sich um einen klassischen Fall von Erwartungsmanagement: Was erwartet eine Organisation von der Einführung eines IAM-Systems (schließlich ist das Projekt vielleicht komplex oder teuer - oder sogar beides)? Was ist das fertige System tatsächlich zu leisten imstande?

Viele IAM-Systeme auf dem Markt orientieren sich an dem schon etwas älteren NIST-Standard „Role-Based Access Control“ (RBAC), wenn es um die Betrachtung der Berechtigungen einer Organisation und der sinnvollen, handhabbaren Modellierung und Neuordnung geht. Der RBAC-Ansatz geht davon aus, dass ein Mitarbeiter eines Unternehmens in einem IT-System, auf das er Zugriff benötigt, grundsätzlich dort auch einen Account und Zuordnungen von Berechtigungen braucht. Zur Abstrahierung empfiehlt der RBAC-Standard, diese Berechtigungen schon im IT-System zu bündeln und zusammenzufassen. Die meisten heutigen IT-Systeme beherrschen dies und erlauben es, konkrete Einzelrechte auf Ressourcen (z.B. Shares, Drucker, Transaktionen) in Gruppen zu bündeln. Diese „Gruppen“ heißen oft auch genauso und stellen ein zentrales Berechtigungsobjekt im RBAC-Standard dar.

Nun geht der RBAC-Standard noch einen Schritt weiter und proklamiert ein weiteres Berechtigungsobjekt „Rolle“, das außerhalb der betrachteten IT-Systeme in einem Verwaltungswerkzeug wie dem IAM-System lebt. Diese Rollen haben folgende Eigenschaften:

• Ihnen werden im IAM-System Gruppen aus IT-Systemen zugeordnet.
• Es können einer einzelnen Rolle Gruppen aus mehreren IT-Systemen zugeordnet werden.
• Es können Rollen ineinander verschachtelt werden, bspw. um verschiedene logische Rollen-Ebenen im IAM-System zu etablieren (typisch: Applikationsrollen, Fachrollen, Funktionsrollen).
• Rollen können Meta-Informationen tragen, die in Gruppen nicht gepflegt werden könnten, bspw. Daten zur Funktionstrennung (Segregation of Duties, SoD), Eigentümern, Genehmigungsstufen, umfangreichen, redaktionell erfassten Beschreibungen.
• Rollen werden Mitarbeitern zugeordnet und das IAM-System stellt sicher, dass die Gruppen der Rolle dem/den Account(s) des Mitarbeiters in den betrachteten IT-Systemen daraufhin ebenfalls zugeordnet werden. Wir sprechen in diesem Fall davon, dass im IAM-System die Gruppen der Accounts „unter Rollenkontrolle gestellt werden“.

Auf diese Weise entsteht eine Berechtigungs-Vererbungs-Hierarchie über mehrere Ebenen. 

Hier ist wichtig zu wissen, dass das RBAC-Modell sich auf die Ebenen 1 bis 5 bezieht: Per RBAC modellieren wir im IAM-System die Beziehungen zwischen Mitarbeiter und den Applikations- oder Fachrollen bis hin zu den Gruppen, die dem Account des Mitarbeiters direkt zugeordnet sind. Alle höheren Ebenen sind für ein IAM-System, das das RBAC-Modell unterstützt, unsichtbar.

Zurück zur ersten der beiden Eingangsfragen: Woran erkenne ich denn jetzt im IAM-System, ob Herr Meier auf das Share XYZ Zugriff hat? Die Antwort war: „gar nicht“, und jetzt wird auch klar, warum. Ob Herr Meier tatsächlich Zugriff auf ein Share hat, also, ob er über die diversen Rollen- und Gruppen-Ebene hinweg unmittelbar oder mittelbar in einer ACL eines Shares berechtigt ist, kann man in einem RBAC-System nicht sehen, denn es hält nicht alle dafür nötigen Daten vor.

Bisher haben wir uns mit einer statischen Sicht auf die Berechtigungshierarchie befasst, die dazu führt, dass ein Mitarbeiter Berechtigungen auf eine Ressource hat. Diese statische Sicht beinhaltet nur die Aussage, dass der Mitarbeiter aufgrund seiner Berechtigungsstruktur potenziell Zugriff hat. Ob er den Zugriff tatsächlich genutzt hat, ob also die Berechtigungsstruktur wirksam ist, entscheidet sich zur Laufzeit. Hier tritt ein wesentlicher Unterschied zweier Systeme zutage:

1. Das Berechtigungsmanagement-System, bestehend aus IAM-System, Active-Directory, den Gruppen-in-Gruppen-Verschachtelungen und den Access Control Lists auf den Ressourcen, legt die potenziellen Berechtigungen fest (statische Sicht)
2. Das Zugriffskontrollsystem prüft zur Laufzeit, ob ein konkreter Zugriffsversuch zulässig ist oder nicht. Erst durch diese Instanz wird eine Berechtigung wirksam.

Auch im IT-System „Windows“ ist es wichtig, zwischen der Datenhaltung und der Zugriffskontrolle zu unterscheiden: das Active Directory ist eine Windows-Komponente, aber es ist nicht das Zugriffskontrollsystem. Vielmehr hält es die Berechtigungsdaten vor, die das Windows-Zugriffskontrollsystem zur Ausübung der Zugriffskontrolle benötigt. Wenn ich also im Active Directory manuell oder über ein IAM-System Berechtigungsstrukturen verwalten kann, sagt mir das noch nicht viel über deren Wirksamkeit. Folgende Fallstricke könnte es zwischen den Ebenen 5 und 8 in unserem Modell geben:

• Eine Gruppe ist nicht unmittelbar oder (über Verschachtelungen) in der ACL einer Ressource genutzt. Ergebnis: Gruppenmitgliedschaft des Accounts ohne jegliche Wirkung
• Überlappung mehrere Gruppen in den Einzelrechten der ACLs. Ergebnis: der Entzug einer Gruppenmitgliedschaft entzieht dem Account nicht die potenzielle Berechtigung auf die Ressource, da es für sie noch einen anderen Pfad in der Berechtigungshierarchie gibt

Darüber hinaus gibt es noch einen vor allem bei Entzügen problematischen Effekt, der sich aus einem Caching-Mechanismus in Windows ergibt, der gerne vergessen wird: das Access Token.

Das Access Token wird beim Login eines Accounts an einer Windows-Arbeitsstation vom Login-Manager ermittelt und fortan bei jeder Authentifikations- oder Autorisierungsanfrage eines anderen Windows-Rechners (bspw. eines File-Servers) vorgezeigt. Im Access Token stehen alle Berechtigungen des Accounts zum Zeitpunkt des Entstehens des Tokens, die sich aus dem Active Directory ermitteln lassen, darunter alle direkten Gruppenmitgliedschaften. Insbesondere stehen im Access Token nicht

• Mittelbare Gruppenmitgliedschaften, die sich durch Gruppen-Verschachtelungen innerhalb des Active Directories ergeben
• Mittelbare Gruppenmitgliedschaften in Server-lokalen Gruppen
• Berechtigungen in ACLs mittelbarer oder unmittelbarer Art auf den (allen) Windows-Servern und -Arbeitsstationen der Domäne

Ändern sich also Berechtigungsstrukturen im Active Directory, bspw. durch Hinzufügen von Gruppenmitgliedschaften zum Account, durch Entzug von Gruppenmitgliedschaften oder durch Änderungen an der Gruppenverschachtelung, so hat dies erst zeitverzögerte Auswirkungen auf das Access Token: erst beim nächsten Login wird es neu berechnet.

Wenden wir uns der zweiten der beiden Eingangsfragen zu: Was sind aktuell seine (Herrn Meiers) wirksamen Berechtigungen? Die aktuell wirksamen Berechtigungen eines Windows-Accounts stehen entweder direkt im Access Token oder werden von ihm abgeleitet, z.B. in dem ein File-Server das Access Token liest und sein Zugriffskontrollsystem dem Account nachfolgend einen Zugriff auf eine Ressource gewährt oder verwehrt.  Kann ich das im IAM-System sehen? Antwort: nein.

Die Einführung eines IAM-Systems ist nicht die alleinige Lösung für die Erwartungen der IT-Governance- und Revisionsabteilungen von Unternehmen. IAM-Systeme haben eine dedizierte Reichweite und insbesondere die weit verbreiteten Systeme auf Basis des RBAC-Modells (Role-Based Access Control) bringen eine klar abgegrenzte Administrationstiefe und die inhärente Beschränkung auf statische Berechtigungsdaten mit. Es ist also bei Einführungsprojekten ein klares Erwartungsmanagement erforderlich: selbst, wenn das IAM-Projekt groß, komplex und teuer sein sollte, entsteht daraus nicht die eierlegende Security-Wollmilchsau, die fortan alle möglichen und unmöglichen Fragstellungen zur IT-Security einer Organisation beantworten kann.

Sollten Organisationen also lieber gleich auf die Einführung eines IAM-Systems verzichten und ausschließlich auf technischer Ebene Berechtigungen verwalten und Security-Events monitoren? Natürlich nicht. Die Möglichkeiten,

• das Berechtigungsmanagement aus der Business-Sicht zu betrachten,
• Automationen einzuführen,
• Administratoren zu entlasten und
• die Verantwortung für Zugriffsrechte in Fachabteilungen zu übertragen, die selbst viel besser wissen, wer was warum sehen oder nicht sehen darf

liefert uns nur ein IAM-System zuverlässig und auf erprobte Art und Weise. Dennoch muss auch der Unterbau unter einem IAM-System, wie in diesem Artikel dargestellt, betrachtet und mit Maßnahmen und Lösungen begleitet werden. Dies ist allerdings weit weniger komplex als die althergebrachte Methode, den Administratoren von IT-Systemen den kompletten technischen und fachlichen Durchblick abzuverlangen und ihnen umfassende Verantwortung aufzuerlegen.

Der Vollständigkeit halber seien folgende Klarstellungen erlaubt, die im Artikel großzügig übergangen wurden:

• IAM-Systeme haben ein eigenes Zugriffskontrollsystem, sind also nicht nur mit der Datenhaltung von Berechtigungsdaten befasst. Sie sind aber kein Zugriffskontrollsystem für alle angeschlossenen IT-Systeme, sondern lediglich für sich selbst.
• Auch innerhalb des Active Directories gibt es Ressourcen, die man mit ACLs schützen kann, so dass das AD strenggenommen nicht nur ein Datenhaltungssystem ist.
• Anstelle des RBAC-Modells unterstützen manche IAM-Systeme auch die Vergabe von Berechtigungen auf Basis von Regeln oder Attributen (Attribute-Based Access Control). Die Einschränkungen bzgl. der Administrationstiefe bleiben vergleichbar.