Autorisierung auf Windows-Plattformen
22. Juli 2011
Beim Windows-Autorisierungsmodell spielen einige Schlüsselkonzepte zusammen: Dazu gehören die Access Token (Zugriffstoken), die Access Masks (Zugriffsmasken), die Security Descriptor (Sicherheitsbeschreibungen) und die Impersonation (sprich der Identitätswechsel). Damit lassen sich alle Zugriffe auf die Ressourcen regeln.
Bei der Autorisierung im Windows-Umfeld sind immer zwei Einheiten involviert: Zum einen das Subject und zum anderen das Object. Die Abbildung 1 zeigt dazu das Prinzip: Das Subject versucht Zugriff auf das Object zu bekommen.
Als Subject kann ein Sicherheitsprinzipal (Security Principal) fungieren – also ein Benutzer, ein Computer oder auch eine Anwendung. Unter die Bezeichnung Object fallen zum Beispiel die Datei-Ressourcen, die auf einem Dateiserver liegen, oder aber die Drucker-Warteschlangen auf einem Druckerserver. Aber auch die Objekte im AD (Active Directory) auf einem Domänencontroller (in der AD-Datenbank) gehören zu den Objects – wie auch alle anderen Objekte, die in der Windows-basierten IT-Infrastruktur vorliegen.
Drei Einheiten sind im Spiel: Subject, Object und der SRM
Die Autorisierung zwischen Subject und Object wird von einer dritten Einheit geregelt und durchgesetzt: dem Reference Monitor. Bei den Windows-Betriebssystemen wird diese Einheit als SRM (Security Reference Monitor) bezeichnet. Sie fungiert als eine Art „Autoritätseinheit“ auf einem Windows-System. Dabei handelt es sich um einen hochprivilegierten Kernel-Modus-Prozess. Er überprüft alle Zugriffe auf Ressourcen, die über ein Windows-System zur Verfügung stehen.
Die Autorisierung bei Windows und der SRM haben mit dem Zugriff auf „sichtbare“ Windows-Objects zu tun, wie eben die Dateien, Drucker, Registry-Schlüssel und die AD-Objekte. Es geht aber auch um den Zugriff von „weniger“ sichtbaren Objekten wie etwa Systemprozesse oder einzelne Threads. Mit der Autorisierung findet auch die Kontrolle der systembezogenen Tasks statt, wie das Ändern der Systemzeit oder das Herunterfahren des Systems. Microsoft selbst bezeichnet diese systembezogenen Tasks auch als Benutzerrechte (User Rights).
Unter der Haube des Windows-Autorisierungsmodells agieren einige Schlüsselkonzepte. Dazu gehören die Access Token (Zugriffstoken), die Access Masks (Zugriffsmasken), die Security Descriptor (Sicherheitsbeschreibungen) und die Impersonation (sprich der Identitätswechsel). Das Zusammenspiel dieser Komponenten verdeutlicht die Abbildung 2.
Bei jedem Zugriff auf eine Objekt prüft der SRM die Zugriffstoken und die Zugriffsmasken gegen den Security Deskriptor des Objekts. Der Zugriffstoken und die Zugriffsmaske sind mit einem Prozess verbunden, der sozusagen als ein Benutzer agiert (das wird über die Impersonation erreicht). Hierzu noch ein Überblick zu den beteiligten Begriffen:
- Impersonation: Es verdeutlicht, dass ein Prozess anstelle eines Benutzers agiert – sprich eine Identitätsänderung wurde angestoßen.
- Access Token: Er verfügt über die Zugriffskontrollinformationen eines Benutzers – wie etwa die Gruppenmitgliedschaften und die Benutzerrechte.
- Access Mask: Diese Maske teilt dem SRM mit, was der Prozess mit der angefragten Ressource machen möchte (wie etwa das Schreiben in oder das Lesen aus einer Datei). Am Ende des Autorisierungsentscheidungsprozesses gibt der SRM eine andere Zugriffsmaske zurück, die sogenannte „granted Access Mask“. Sie verfügt über die Informationen für den zugriffswilligen Prozess, was er mit der Ressource machen darf/kann.
- Security Deskriptor: Die Sicherheitsbeschreibung für ein Objekt teilt dem SRM mit, wer was mit diesem bestimmten Objekt machen darf.
Beim Autorisierungsmodell von Windows greift ein Benutzer niemals direkt auf die Ressource zu – diese Aufgabe erledigt immer ein Server-Prozess, der stellvertretend für den Benutzer diese Aktion ausführt. Dieser Vorgang – die Impersonation – hat einen großen Vorteil: Wenn ein Prozess einen Benutzer „impersoniert“, bedeutet das: Dieser Prozess läuft im Sicherheitskontext des betreffenden Benutzers und er verwendet dazu auch die Autorisierungsattribute des Benutzers.
Um es Windows zu ermöglichen, dass es die Autorisierungsinformationen eines Benutzers (also die Benutzerrechte und die Gruppenmitgliedschaften) mit jedem Prozess verbindet, der von dem Benutzer gestartet wird, greift Windows auf ein Objekt zu: das Access Token.
Access Token bleiben lokal
Diese Zugriffstoken sind immer mit einer Anmeldesitzung eines Benutzers verknüpft. Sie werden auf jedem System erzeugt, an dem sich der Benutzer anmeldet. Ein Zugriffstoken ist daher auch immer lokal auf einem System vorhanden – es wandert sozusagen niemals über das Netzwerk. Die Local Security Authority (LSA) ist die Komponente des Betriebssystems, das die Zugriffstoken erzeugt.
Neben den Informationen für die Autorisierung des Benutzers gegenüber der Domäne (sie liegen im AD), liegen im Zugriffstoken auch die lokalen Autorisierungsdaten des Benutzers. Die letztgenannten Informationen sind die Autorisierungsdaten, die in der lokalen SAM (Security Account Manager) und somit in der lokalen Sicherheitsdatenbank abgelegt sind: Sie umfassen die lokalen Gruppenmitgliedschaften des Benutzers und die lokalen Benutzerrechte.
Um sich die Inhalte des eigenen Windows-Zugriffstoken) mit allen Gruppenmitgliedschaften und Benutzerrechten) anzeigen zu lassen, muss der Benutzer nur das Tool Whoami (mit dem Switch /all) aufrufen.
Das hauptsächliche Autorisierungsattribut auf der Seite der Objekte ist der sogenannte Security Deskriptor (die Sicherheitsbeschreibung). Er teilt dem Autorisierungssystem mit, wer was mit dem Objekt ausführen darf. Ein jedes Objekt, das einen Security Deskriptor verknüpft hat, wird als „securable object“ bezeichnet.
Diese Objekte können zwischen verschiedenen Benutzern geteilt werden – und ein jeder Benutzer kann verschiedene Autorisierungseinstellungen haben. Beispiele für „securable objects“ sind Dateien, Verzeichnisse, Netzwerkfreigaben, Drucker, Registrierungsschlüssel, ein AD-Objekt oder ein Dienst. Der Security Deskriptor für ein Dateisystem-Objekt wird im NTFS-Dateisystem abgelegt.
Der Security Deskriptor für ein AD-Objekt wird im Attribut „nTSecurityDescriptor“ für das betreffende Objekt abgelegt. Dieses Attribut wird im Rahmen des Global Catalogs (GC) repliziert. So lässt sich sicherstellen, dass der Zugriff auf die AD-Objekte auch dann abgesichert ist, wenn das Objekt außerhalb seiner Domänengrenze (also in anderen Domänen) an GCs in anderen Domänen repliziert wird.
Der Security Deskriptor eines jeden Objekts enthält einen Satz von „Access Control Lists“ (ACLs, Zugriffssteuerungslisten). Eine ACL besteht aus mehreren Access Control Entries (ACEs, Zugriffssteuerungseinträge). Ein ACE wird auch als Permission (Berechtigung) bezeichnet. Ein ACE verbindet eine Security Identity (SID; Sicherheitsidentität) mit einem Zugriffsrecht (wie zum Beispiel Schreiben, Lesen, Löschen oder Ausführen). Typische Beispiele für Berechtigungen lauten: „Joe darf den monatlichen Ausgabenbericht lesen), oder: „Alice darf auf den Drucker in der Personalabteilung ihre Daten ausdrucken“. In einem Security Deskriptor wird ein Zugriffsrecht in Form eines Hex-Wert (hexadezimalen Wertes) ausgedrückt: der Zugriffsmaske.
Jeder Security Deskriptor enthält zwei Typen von ACLs: die „Discretionary ACLs“ und die „System ACLs“:
Die „Discretionary ACLs (DACLs) enthalten ACEs, die vom Besitzer eines Objekts gesetzt werden. Sie tragen die Bezeichnung „Discretionary“, weil ihr Inhalt vom Besitzer des Objekts selbst (also „diskret“) gesetzt werden. Beim „Besitz“ (sprich der Ownership) handelt es sich um eine Schlüsselrolle des Sicherheitsmodells von Windows. Es erweist sich als sehr mächtig, da der Besitzer des Objekts immer das Recht gewährt bekommt, die Berechtigungen für das Objekt zu verwalten.
Standardmäßig ist der Besitzer des Objekts das Benutzerkonto von Windows, das dieses Objekt erzeugt hat. Wenn das Objekt von einem Mitglied der Gruppe der Domänenadministratoren oder einem lokalen Administrator erzeugt wurde, dann werden diese Gruppen zum Besitzer des Objekts. Um sich die DACLs über die grafische Oberfläche von Windows anzeigen zu lassen, kommt üblicherweise der ACL Editor zum Einsatz.
Der Zugriff darauf ist über den Reiter Sicherheit in den Eigenschaften eines Objekts zu finden. Um sich die DACLs eines Dateisystemobjekts von einem Kommandozeilenfenster aus anzeigen zu lassen, kann man das Tool cacls heranziehen.
System ACLs (SACLs): Diese ACLs enthalten die Überwachungseinstellungen für das Objekt – und die werden vom Administrator vorgegeben. Sie sind daher „nicht discretionary“ – sie beziehen sich auf keine Art auf den Besitzer des Objekts. Um sich die SACLs eines Objekts über die grafische Oberfläche von Windows anzusehen, ist ebenfalls der ACL Editor geeignet.
Zusätzlich zu den DACLs und den SACLs enthält der Security Deskriptor noch zwei weitere Felder:
- Das Feld „Owner SID“: es enthält die SID des Besitzer des Objekts und
- Das Feld „Primary Group SID“: Hier liegen die SID der primären Gruppe des Besitzers des Objekts. Diese Informationen sind für die Kompatibilität zur Zugriffskontroll-Verwaltung von Posix und Macintosh nötig.
