Sensible Daten im AD verbergen, Teil 1
26. September 2012
Explizite Berechtigungen für einzelne Objekte im Zusammenspiel mit vererbten Berechtigungen von Container-Objekten erschweren das Vergeben der Zugriffsrechte. Will der Administrator in „seinem“ Active Directory sensible Informationen vor den Augen allzu vieler Benutzer verbergen, muss er viele Details beachten. Eine mehrteilige Artikelserie des AD-Experten Guido Grillenmeier zeigt, wie man dabei den Überblick behält.
Das Active Directory (AD) verfügt über recht ordentliche Möglichkeiten, um für einzelne Objekte passende Berechtigungen zu vergeben. Damit lässt sich die Verwaltung der einzelnen Bestandteile wie Benutzer, Gruppen oder Computer, an unterschiedliche Security-Prinzipale delegieren. Wenn es aber darum geht, bestimmte Daten nur für die Benutzer sichtbar zu machen, die diese Informationen benötigen, machen die standardmäßigen Berechtigungen im AD die Sache recht komplex.
Daher kümmert sich diese mehrteilige Artikelreihe um die Frage, welche Optionen für das Verbergen von Informationen im AD zur Verfügung stehen. Diese Optionen können auf den typischen AD-Berechtigungen basieren, einem speziellen AD-Zugriffs-Feature namens „List Mode“, oder einer weniger bekannten Option: das „Confidentiality Bit“. Es wurde bereits vor einigen Jahren im Zuge des Servicepack 1 für den Windows Server 2003 eingeführt. Beim Windows Server 2008 Release 2 (R2) und beim Windows Server 2008 kamen kleinere Verbesserungen dazu, um Zugriffsrechte auf Daten im AD zu vergeben – das wird ebenfalls in der Artikelreihe beschrieben. Doch zuerst muss man die Herausforderungen beim Verbergen der Informationen im AD verstanden haben.
Die Herausforderungen
Das Verbergen von Informationen im AD erweist sich als eine Herausforderung, weil es verschiedene Standardberechtigungen gibt, die für die AD-Gesamtstruktur vergeben werden. Im Zuge des Entwurfs des AD hat sich Microsoft dazu entschieden, vielzählige Lese-Berechtigungen für alle authentifizierten Benutzer für nahezu alle neuen Objekte zu erteilen, die in einer Gesamtstruktur (einem Forest) erzeugt werden. Leider hatte man nicht den Ansatz erfolgt, die Standardeinstellungen möglichst restriktiv zu handhaben und es den Administratoren aufzuerlegen, die notwendigen Lese-Berechtigungen für die jeweilige Umgebung zu erteilen.
Wie so häufig gibt es für beide Ansätze ein Für und Wider. Man könnte sogar argumentieren, dass dieser weniger restriktive Ansatz auch ein Grund für den enormen Erfolg des AD ist: Denn weniger Aufwand bei den Administratoren ist nötig, um die Umgebung insgesamt ans Laufen zu bringen.
Standards allein reichen nicht
Die Unternehmen erkennen langsam aber sicher, welchen Umfang die standardmäßigen Lese- oder Schreibberechtigungen aufweisen, die an alle Benutzerkonten im AD eines Unternehmens vergeben werden. Denn viele Organisationen möchten unter Umständen unterscheiden – etwa zwischen Mitarbeitern, die alle Konten im AD abfragen dürfen, und externen Mitarbeitern, die womöglich nur für eine bestimmte Zeit im Unternehmen angestellt sind oder temporär für das Unternehmen arbeiten.
Zudem ändert sich der Einsatzzweck des ADs: Viele Unternehmen sehen darin nicht mehr nur ein Verzeichnis für ein Netzwerkbetriebssystem, sondern vielmehr sogar ein LDAP-basiertes Verzeichnis, das auch von anderen Applikationen benutzt wird. Damit steigen die Anforderungen: Es geht um mehr Kontrolle über die Fragestellung, „wer darf auf was zugreifen“.
Delegation von Verwaltungsaufgaben
Ein weiterer Aspekt betrifft das Delegieren der Verwaltungsaufgaben. Der Zugriff und die Sichtbarkeit von sensiblen Konten – die über mehr Berechtigungen verfügen als die üblichen Konten – ist ein wichtiger Aspekt, der genauestens zu planen ist. Das ist vor allem in Outsourcing-Umgebungen ein dominierendes Argument, wenn zum Beispiel Benutzer aus verschiedenen Unternehmen innerhalb einer AD-Gesamtstruktur liegen.
So bekommen zum Beispiel alle authentifizierten Benutzer in einer AD-Gesamtstruktur explizit das Lese-Zugriffsrecht auf jede OU (Organizational Unit, Organisationseinheit) eingeräumt, die ein Domänenadministrator oder ein Administrator (der die entsprechenden Rechte delegiert bekommen hat) erzeugt. Damit ist klar: Jeder ordnungsgemäß angemeldete Benutzer kann alle Objekte in jeder OU in einer AD-Gesamtstruktur sehen.
Diese Situation bessert sich auch nicht, wenn man sich die Standardberechtigungen für die verschiedenen Typen von AD-Objekten (wie etwa ein userClass-Objekt) ansieht. Wie es auch die Tabelle 1 verdeutlicht, verfügen die authentifizierten Benutzer über verschiedene Lese-Zugriffsrechte, aber „SELF“ (also „selbst“; sprich der Benutzer, wenn er auf sein eigenes Konto zugreift) verfügt auch über das Recht, lesend auf alle Eigenschaften (Properties) zuzugreifen und darf auch viele von ihnen beschreiben (Write-Zugriffsrecht).
Zusätzlich zu den expliziten Berechtigungen für jedes neue Objekt kommen noch weitere Berechtigungen ins Spiel. Sie stammen von den übergeordneten OUs und finden im Zuge der Vererbung Anwendung. Ziemlich kritische Standard-Berechtigungen, einschließlich der „Read All Property“ („Alle Eigenschaften lesen“) für die Benutzerobjekte, werden über die Gruppe „Pre-Windows 2000 Compatible Access“ (also die Gruppe „Prä-Windows 2000 kompatibler Zugriff“) gewährt.
Einschränkungen für authentifizierte Benutzer
Zu den großen Herausforderungen gehört das Einschränken der Berechtigungen für die authentifizierten Benutzer, so dass sie nicht alles standradmäßig zu sehen bekommen. Daher ist das Verstehen jedes noch so mühsamen Details bei den AD-Berechtigungen und das Anpassen für die Administratoren besonders wichtig.
In dem hier geschilderten Zusammenhang ist der Begriff „explizite Berechtigungen“ gefallen. Es handelt sich dabei um Berechtigungen, die direkt bei den einzelnen Objekten gesetzt werden. Im Gegensatz dazu stehen die geerbten Berechtigungen, die üblicherweise für ein Container-Objekt vergeben werden und die so konfiguriert sind, dass sie für alle Objekte in dem Container sowie für alle darunter liegenden Container Anwendung finden.
Explizite versus geerbte Berechtigungen
Um ein effizientes Modell für die Autorisierung im AD nutzen zu können, bedarf es zum einen der expliziten und zum anderen der vererbten Berechtigungen. Versucht ein Benutzer, auf ein Objekt zuzugreifen, muss der Security Reference Monitor die Liste der Berechtigungen in ACLs (Access Control Lists) auswerten und sie dann mit der SID (Security Identifier) des Benutzers vergleichen.
Damit lässt sich dann entscheiden, ob der Zugriff erlaubt oder abgewiesen werden soll. Dabei beginnt der Security Reference Monitor beim Abarbeiten der ACLs sozusagen ganz oben. Wenn er dabei genügend ACEs (Access Control Entries) findet, um zu bestimmen, dass der Zugriff erlaubt oder abgewiesen werden soll, beendet er das weitere Bearbeiten der ACL und liefert ein Ergebnis – also ein Zulassen oder Verweigern – an den anfragenden Prozess zurück. Daher bestimmt die Reihenfolge, in der die ACEs in der ACL liegen, die effektive Berechtigung. In Tabelle 2 ist die Reihenfolge der ACEs zu sehen und die Prioritäten in Bezug auf die Auswertung.
Verweigern wiegt schwerer als Zulassen
Das Verweigern (Deny) geniest dabei den Vorrang gegenüber dem Zulassen (Allow). Aber ein explizites Zulassen überschreibt ein geerbtes Verweigern. Wenn ein untergeordnetes Objekt ein explizites Zulassen vererbt bekommt, dann überschreibt diese Berechtigung auch ein „Verweigern“, das von einer OU vererbt wurde, die in der Hierarchie weiter oben steht.
Das kann zur folgenden Situation führen: Selbst wenn ein Administrator den Zugriff auf ein bestimmtes Benutzer-Attribut (wie etwa die Telefonnummer) für alle externen Benutzer auf der Ebene der obersten Domäne im AD verweigert, so würde diese Berechtigung normalerweise von der standardmäßigen, expliziten Lese-Berechtigung überschrieben, die für alle authentifizierten Benutzer in einer Gesamtstruktur gewährt wird.
In Abbildung 1 ist dazu ein Beispiel zu sehen. Obwohl die Gruppe ExtUsers keine Lese-Berechtigung für bestimmte User-Attribute auf der Ebene der obersten OU oder auf den Domänenknoten besitzt, so haben einige der untergeordnete OUs doch die Standardberechtigungen hinzugenommen und die erlauben den authentifizierten Benutzern den Lesezugriff auf die meisten Objekte und Attribute.
Diese Berechtigungen gelten auch für neu erzeugte Objekte. Und die verweigern-Berechtigung der obersten Ebene kann nicht bis ganz nach unten im Verzeichnisbaum gelangen, wenn eine OU in dieser Struktur das Vererben der Berechtigungen aus der überliegenden OU blockiert. Weitere Beiträge in dieser Reihe werden zeigen, wie man mit diesem problematischen Verhalten sauber umgehen kann.
