Die Ermittlung eines umfassenden Überblicks über die Zugriffsrechte in einem Microsoft-Netzwerk kann eine schwierige Aufgabe sein - das kann jeder bestätigen, der sich kürzlich einem Audit unterzogen hat. Die Sammlung und Organisation von Sicherheitsdaten in detaillierten Berichten kann viel Zeit und Mühe kosten. Es gibt mehrere Gründe, warum das Sammeln der Daten schwierig und zeitaufwändig ist, aber der gemeinsame Faktor ist, dass die Sicherheitsinformationen über mehrere Sicherheitsspeicher verteilt sind.
In einer Windows-Umgebung werden die Informationen des Sicherheitsspeichers mit den folgenden Methoden verteilt:
- Sicherheitsprinzipale (Benutzer und Gruppen) sind über Active Directory und Sicherheitsdatenbanken der Mitgliedsserver (SAM) verteilt.
- Gruppen können tief verschachtelt sein (z. B. Gruppe A ist in Gruppe B ist in Gruppe C ist in ....)
- Die Gruppenzugehörigkeit kann sich über Sicherheitsdatenbanken erstrecken (z. B. ist domain\domain admins in server\Administrators)
- Eine Windows-Domäne kann anderen Windows-Domänen und externen Kerberos-Realms vertrauen
- Zugriffskontrolllisten (ACLs) existieren für ein zu sicherndes Objekt
Während es effizient ist, die Informationen in einem einzigen Speicher zu speichern, kann es eine Herausforderung darstellen, über die Informationen zu berichten. Den heutigen Verwaltungstools mangelt es an der nötigen Raffinesse, um echte Zugriffsberichte zu erstellen, da sie ein oder zwei Schritte davon entfernt sind, einen ganzheitlichen Überblick über den Zugriff zu bieten. Die folgenden Ausführungen verdeutlichen einige der Einschränkungen der Verwaltungstools, die eine effektive Berichterstattung über den Zugang verhindern.
- Verwaltungstools bieten eine eingeschränkte Sicht auf den Verwaltungsprozess und konzentrieren sich auf die unmittelbare Aufgabe statt auf den gesamten Lebenszyklus der Identitäts- und Zugangsverwaltung. Dadurch bleibt es den Administratoren überlassen, die Einstellungen in einem anderen Tool zu validieren oder darauf zu vertrauen, dass die anderen Prozesse korrekt ausgeführt wurden.
- Die Verwaltungstools bieten nicht die notwendige Verknüpfung, um über die Identitätsnutzung in der Umgebung zu berichten.
- Verwaltungstools setzen voraus, dass andere Bereitstellungsfunktionen korrekt ausgeführt wurden. (z. B. ermöglicht das Hinzufügen einer Gruppe zu einer ACL dem Administrator nicht, die Gruppenmitgliedschaft anzupassen, da dies ein separates Tool mit einem separaten Zweck erfordert)
Da die derzeitigen Verwaltungstools nicht über den aktuellen Sicherheitskontext hinausgehen, müssen die Verwaltungsmitarbeiter jede Filiale aufsuchen, die Daten extrahieren und sie manuell zu aussagekräftigen Berichten zusammenführen.
Lösung der Herausforderung(en)
Bei der Entwicklung einer Lösung, die CSS letztes Jahr als software unter dem Namen Distributed Authorization Reporting Tool (DART) veröffentlicht hat, stieß ich auf zahlreiche Herausforderungen, die es zu lösen galt. Die Gruppenfindung war vielleicht das größte Hindernis bei der Entwicklung der Lösung. Einige der Dinge, die den Kodierungsprozess wirklich interessant machten, waren zum Beispiel die Art und Weise, wie die Gruppen funktionierten und interagierten:
Es gibt mehrere Arten von Gruppen (lokal, global und universell) und sie können sicherheitsaktiviert werden.
- Gruppen können (Unter-)Gruppen als Mitglieder haben
- Gruppen können tief verschachtelt werden. Mit zunehmender Verschachtelungstiefe steigt die Anzahl der Gruppen, denen ein Benutzer in den Berichten zugeordnet werden muss, exponentiell an. Eine Domäne mit 20.000 Benutzern und 12.000 Gruppen kann zum Beispiel schnell zu 1.600.000 Sicherheitsbeziehungen werden.
- Gruppen können über Sicherheitsdatenbanken hinweg verschachtelt werden (z. B. Domänenadministratoren in der Gruppe "Administratoren" eines Mitgliedsservers)
- Gruppen können mehr als 5.000 Mitglieder haben, was eine besondere Behandlung bei der Aufzählung der Mitglieder erfordert.
- Die Zugehörigkeit eines Benutzers zu einer Gruppe wird nicht zwangsläufig durch die "Mitgliedschaft" in einer Gruppe gewährt. Die Gruppenzugehörigkeit kann auch berechnet werden.
Nicht alle Benutzer sind Teil der berechneten Gruppe "Domänenbenutzer". Die primäre Gruppe eines Benutzers kann einer anderen Gruppe zugewiesen werden. Die Lehre daraus ist, dass man nicht alle Benutzer als Mitglied der Gruppe behandeln kann, nur weil sie zu dieser Domäne gehören.
Als ich mich mit den einzelnen Problemen befasste, wurde mir schnell klar, dass die Beziehungen zwischen den Sicherheitsdaten für die Entwicklung einer Lösung von entscheidender Bedeutung sein würden. Wie sich herausstellte, bestand der Schlüssel zur Lösung darin, eine Tabelle zu erstellen, die die Beziehungen zwischen Benutzern und Gruppen aufzeigte und leicht mit einer ACL abgeglichen werden konnte. Ich bezeichne diese Verknüpfungen gerne als "Sicherheitsketten", da sie den Benutzer und seine Zugehörigkeit zu einer bestimmten Gruppe zeigen.
Bleiben Sie dran für meinen nächsten Blogbeitrag in dieser Serie: Der SID bleibt derselbe...
