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?
Role-Based Access Control
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.
Berechtigungs-Management in Windows
Berechtigungshierarchie von Mitarbeiter über Active Directoy bis zur ACL. Der Pfeil bedeutet „erbt Berechtigungen von“, z.B. „Mitarbeiter erbt Berechtigungen von App-Rolle C“
Um es konkret zu machen, schauen wir uns die mögliche Struktur am Beispiel des IT-Systems „Windows“ an, das Teil einer Microsoft-Active-Directory-basierten Domain ist.
Dabei gehen wir von einer schützenwerten Ressource aus: Hier ein geteilter Ordner (Share) auf einem Fileserver. Dieser geteilte Ordner wird geschützt durch Einzelrechte in der sogenannten „Access Control List“ (ACL). Diese ACL besteht aus einer Liste von Berechtigungsobjekten mit ihren konkreten Berechtigungen auf den Share, also bspw. „Gruppe ABC hat Vollzugriff auf den Share“, „Gruppe DEF hat Nur-Lese-Berechtigung“. Die genannten Gruppen können dabei Gruppen auf dem Server selbst (Server-lokale Gruppen) oder im Active Directory definiert sein. In Windows-Umgebungen findet man häufig Gruppen-in-Gruppen-Verschachtelungen derart, dass bestimmte Gruppen in den ACLs der Ressourcen genutzt werden („Ressource-Gruppen“), die in anderen Gruppen verschachtelt sind, in denen die Admins die Mitgliedschaften von Accounts pflegen („User-Gruppen“). Es ergibt sich auf dem Weg von der ACL in Windows zum Mitarbeiter-Objekt im IAM-System eine Hierarchie von Berechtigungsobjekten, die sich über acht Ebenen erstreckt (Abbildung rechts).
Die konkrete Ausgestaltung dieser Hierarchie ist fallspezifisch und oft Ergebnis der Vorlieben der Windows- oder Active-Directory-Administratoren. In einem IAM-Einführungsprojekt muss der gesamte Berechtigungs-Vererbungspfad vom Einzelrecht (Ebene 8) zum Mitarbeiter (Ebene 1) untersucht werden, um die Eingangsfrage „Was hat Herr Meier denn jetzt für Berechtigungen?“ beantworten zu können.
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.
Wirksamkeit von Berechtigungen
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:
- 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)
- 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.
Abhilfen
Die Administrationstiefe, die ein IAM-System erreicht, ist nicht immer auf das RBAC-Modell beschränkt. Mitunter gibt es auch innerhalb eines IAM-Systems unterschiedlich tief angebundene Standard-Systeme. So erreicht beispielsweise die Garancy IAM Suite unseres Software-Partners Beta Systems für Windows und einige Mainframe-Security-Systeme folgende Administrationstiefen:
| Standard-Zielsystem-Anbindung |
Erreichbare Ebene |
Zielsystem-Bezeichnung |
| Windows Connect |
7 |
Gruppe (server-lokal) |
| SAP Connect |
6 |
Sammelrolle (Ebene 5), Rolle (Ebene 6) |
| RACF Connect |
8 |
Datasets, Generic Datasets |
| TopSecret Connect |
8 |
Datasets, Generic Datasets |
| ACF2 Connect |
8 |
Datasets, Generic Datasets |
| Alle anderen |
5 |
|
Dies erlaubt zumindest die Sichtbarkeit, Auswertbarkeit und Änderungsverfolgung (Logging) der statischen Berechtigungsstrukturen innerhalb des IAM-Systems, teilweise auch in den Rezertifizierungsprozessen. Unverändert nicht sichtbar sind die sich ergebenden und tatsächlich genutzten Berechtigungen.
Die meisten IT-Systeme, darunter auch Windows, erlauben das Protokollieren von Änderungen an der statischen Berechtigungsstruktur. Dies gilt selbstverständlich auch für IAM-Systeme. Wie gut und einfach die Auswertung der Protokolle gelingt, ist sehr stark vom IT-System abhängig. Bei Windows landen die Änderungslogs, falls sie aktiviert sind, im Event-Log der Domain Controller, allerdings in recht technischer Form.
Darüber hinaus ist es bei vielen IT-Systemen möglich, gewährte oder verwehrte Zugriffsversuche auf Ressourcen zu protokollieren. Bei Windows landen diese Zugriffs-Logs, falls sie aktiviert sind, im Event-Log des Servers, auf dem die Ressource abgelegt ist. Auch diese Protokolle sind technischer Natur, und sie sind über die Server verteilt und nicht an einer zentralen Stelle gesammelt.
Für die Überwachung (Ebenen 4 bis 8)
- der Zugriffsrechte auf Ressourcen
- der tatsächlich unternommenen Zugriffsversuche auf eine Ressource
gibt es in der IT-Security eine eigene Disziplin „File Analysis and User and Entity Behavior Analytics“ (FA & UEBA) mit einem eigenen, großen, nicht auf Windows beschränkten Software-Katalog (Varonis, Garancy Data Access Governance, Saviynt Cloud PAM, …). Das ist ein eigenes Einführungsprojekt.
Auch die Disziplin „Privileged Access Management“ (PAM) spielt hier eine Rolle, aber aus einem anderen Blickwinkel (Account- statt Ressourcen-Sicht). Das ist ebenfalls ein eigenes Einführungsprojekt.
Security Information and Event Management stellt Konzepte und Lösungen für die Echtzeitanalyse von Sicherheitsalarmen bereit. SIEM-Systeme sind spezialisiert auf die Analyse und Korrelation von Sicherheitsalarmen aus einer großen Anzahl verschiedener Quellen.
Damit ein SIEM-System gut funktioniert, bedarf es geeigneter Quellen, die es in Echtzeit auf sicherheitskritische Vorgänge monitoren kann. Insoweit ist ein SIEM-System kein Ersatz für IAM- oder UEBA-Systeme, sondern stark darauf angewiesen, von diesen Systemen mit Daten befüttert zu werden.
Fazit
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.
Disclaimer
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.
