Sicherheit auf dem PrüfstandSubjekte und Sicherheitsprinzipale

Jesper M. Johansson

Inhalt

Das Subjekt/Objekt/Aktion-Tupel
Arten von Sicherheitsprinzipalen
Dienste
Zusammenfassung

Auf der grundlegendsten Ebene geht es bei Sicherheitsfragen letzten Endes um Subjekte und Objekte. Unter Objekte fällt alles, was Sie schützen, und unter Subjekte fällt alles, wovor Sie Objekte schützen. Diese beiden Konstrukte werden in der Authentifizierung (sich ausweisen), Autorisierung (Zugriff auf etwas gewähren) und Überwachung (nachverfolgen, wer auf was zugegriffen hat) verwendet. Im Grunde sind diese Konzepte sehr einfach (siehe Abbildung 1).

Abbildung 1 Ein Benutzer versucht, eine Datei zu lesen

Subjekte tun etwas, während Objekte das sind, mit dem die Subjekte etwas tun. Außerdem sind die Objekte, mit denen Subjekte etwas tun, manchmal selbst Subjekte.

Windows unterstützt eine äußerst umfangreiche Semantik, wenn es um die Sicherheit geht, und hat die Definitionen von Subjekten und Objekten erheblich erweitert. Ein Subjekt kann sehr viel mehr sein als nur ein Benutzer, und die Darstellung ist weit komplexer als nur eine einfache Benutzer-ID.

Im Windows-Sprachgebrauch umfasst ein Sicherheitsprinzipal nicht nur das typische Subjekt (das Sie als einen Benutzer ansehen würden), sondern auch Gruppen und Computer. Ein Sicherheitsprinzipal ist alles, dem eine Sicherheits-ID (SID) und eine bestimmte Berechtigung zugewiesen werden kann, auf etwas zuzugreifen.

In dieser Ausgabe von „Sicherheit auf dem Prüfstand“ erhalten Sie eine Einführung dazu, wie Subjekte in Windows dargestellt und verwendet werden.

Das Subjekt/Objekt/Aktion-Tupel

Beim Verwalten von Sicherheit geht es im Grunde oft um das Subjekt/Objekt/Aktion-Tupel. Das Subjekt ist der Akteur, der versucht, eine Aktion an einem Objekt durchzuführen. Zum Beispiel versucht ein Benutzer, auf eine Datei zuzugreifen (siehe Abbildung 1). Wenn ein Benutzer versucht, die Datei zu lesen, muss das Betriebssystem prüfen, ob für das Objekt (die Datei) Berechtigungen festgelegt sind, die dem Subjekt (dem Benutzer) gestatten, die Aktion (das Lesen) für das jeweilige Objekt durchzuführen. Wenn die Berechtigungen in Ordnung sind, ist die Zugriffsanforderung erfolgreich. Wenn die Berechtigungen nicht in Ordnung sind, wird die Zugriffsanforderung verweigert. So weit ist alles sehr einfach.

Groß- und Kleinschreibung

Wenn in englischer Windows-Literatur die Wörter „Administrator“ oder „Administrators“ mit dem Großbuchstaben „A“ geschrieben werden, wird in der Regel auf den Benutzer bzw. die Gruppe Bezug genommen. Wenn das Wort nur aus Kleinbuchstaben besteht, wie in „administrator“, bezeichnet es ein Benutzerkonto oder eine Person, das bzw. die über Administratorrechte verfügt. Dasselbe gilt für andere Entitäten, wie z. B. „Guest“ (Gast) und „guest“.

Arten von Sicherheitsprinzipalen

Subjekte (oder Sicherheitsprinzipale, wie sie im Folgenden in einem Windows-basierten System bezeichnet werden sollen) und damit ein Windows-basiertes Netzwerk können viel mehr sein als nur Benutzer. Der Benutzer ist jedoch immer noch das grundlegendste Konzept.

Benutzer Ein Benutzer ist eine eindeutige Entität, die sich bei einem Computer anmeldet. Grundsätzlich hängen alle Sicherheitsprinzipale zumindest ein wenig mit Benutzern zusammen. In Windows kann es zwei Arten von Benutzern geben: lokale Benutzer und Domänenbenutzer. Ein lokaler Benutzer ist in der lokalen Datenbank der Sicherheitskontenverwaltung (Security Accounts Manager, SAM) auf einem Computer definiert. Jeder Windows-basierte Computer hat eine lokale SAM, die alle Benutzer auf diesem Computer enthält.

Im Allgemeinen wird angenommen, dass Domänencontroller (DCs) keine lokale Sicherheitskontenverwaltung und deshalb keine lokalen Benutzer haben. Dies ist aber falsch. Sogar ein DC hat eine lokale SAM, aber die Konten in seiner Sicherheitskontenverwaltung können nur in der Verzeichnisdienstwiederherstellung verwendet werden.

Die lokale Sicherheitskontenverwaltung enthält immer mindestens zwei Benutzerkonten: den Administrator und den Gast, und das Gastkonto ist immer standardmäßig deaktiviert.

Unter allen Versionen von Windows Server 2008 (ausgenommen Windows Small Business Server 2008) ist das Administratorkonto standardmäßig aktiviert, und Sie müssen dieses Konto bei der ersten Anmeldung beim Computer verwenden. Unter Windows Vista ist das Administratorkonto standardmäßig deaktiviert und kann nur unter sehr eingeschränkten Umständen verwendet werden.

Auf jeden Fall sollten Sie für jede Person, die einen Computer verwaltet, mindestens zwei Konten erstellen. Falls Sie sich an Richtlinien welcher Art auch immer halten müssen (was wahrscheinlich der Fall ist), ist dies eine Anforderung. Für jeden Benutzer sollte ein Konto das eigene persönliche Administratorkonto des Benutzers sein. Das andere Konto ist das persönliche Nichtadministratorkonto des Benutzers für nicht administrative Aufgaben.

Benutzer, die keine lokalen Domänenbenutzer sind Diese Benutzer sind auf den Domänencontrollern für die Domäne definiert. Der Unterschied zwischen lokalen Konten und Domänenkonten ist hauptsächlich der Kontobereich. Domänenkonten können auf jedem Computer in der Domäne verwendet werden, während lokale Konten nur auf dem Computer gültig sind, auf dem sie definiert wurden. Außerdem kann Domänenkonten im Vergleich zu einem lokalen Konto eine wesentlich größere Anzahl von Eigenschaften zugeordnet sein (zum Vergleich siehe Abbildungen 2 und 3).

Abbildung 2 Eigenschaftenfenster für ein lokales Konto

Abbildung 3 Eigenschaftenfenster für ein Domänenkonto

Domänenkonten haben eine umfangreichere Semantik, von der verschiedene Attribute in einer Organisationsumgebung, wie z. B. Telefonnummern, Verwaltungsbeziehungen und E-Mail-Konten, abgedeckt werden. Domänenkonten sind außerdem in einem Netzwerk weit nützlicher, weil sie netzwerkübergreifend auf Computern verwendet und mit Berechtigungen versehen werden können. Außerdem vereinfacht das Definieren von Konten in der Domäne die Verwaltung, da Sie Konten jetzt nur an einem Ort verwalten müssen.

Computer Ein Computer ist nur eine andere Art von Benutzer. Dies trifft insbesondere in Active Directory zu und wird durch das Vererbungsmodell bestätigt. Die Vererbungsstruktur, die zu einem Computer führt, ist in Abbildung 4 dargestellt.

Abbildung 4 Die Vererbungshierarchie in Active Directory zeigt die Beziehung zwischen Benutzern und Computern

In Abbildung 4 werden einige sehr interessante Dinge gezeigt. Erstens sind, wie Sie sehen können, alle Klassen in Active Directory von einer Stammklasse namens „Top“ abgeleitet. Selbst Top wird als Unterklasse von Top angesehen. Zweitens ist die User-Klasse von der organizationalPerson-Klasse abgeleitet. Drittens (und das ist der interessanteste Punkt) ist die Computer-Klasse von der User-Klasse abgeleitet. Anders gesagt, ist ein Computer im objektorientierten Sprachgebrauch eine Art von Benutzer. Computer auf diese Weise zu vermenschlichen, ist eigentlich sehr logisch, weil Computer als Subjekte behandelt werden müssen und fast die gleichen Attribute haben wie eine Person.

Gruppen Ein Subjekt ist wie bereits erwähnt etwas, das versucht, auf ein Objekt zuzugreifen. Das Betriebssystem überprüft diesen Zugriffsversuch durch Prüfen der Berechtigungen des Objekts. Schon frühzeitig haben Designer von Betriebssystemen erkannt, dass es sehr unhandlich wäre, jedem einzelnen Objekt Berechtigungen für jeden einzelnen Benutzer zuzuweisen, der sie benötigt. Um dieses Problem zu lösen, haben die Designer zugelassen, dass Benutzer Mitglieder von Gruppen sind. Dies ermöglicht Ihnen, nicht nur Benutzern, sondern auch Gruppen Berechtigungen zuzuweisen.

Eine Gruppe darf kein Benutzer sein, aber eine Gruppe ist immer noch eine Art von Sicherheitsprinzipal, weil sie einen Bezeichner haben kann, ganz so wie Benutzer und Computer. In Windows kann ein Benutzer Mitglied vieler Gruppen sein, und ein Objekt kann Berechtigungen haben, die vielen Gruppen zugewiesen sind. Geschachtelte Gruppen sind ebenfalls zugelassen, aber mit einigen Einschränkungen.

Ein Nichtdomänencontroller hat nur zwei Arten von Gruppen, vordefinierte Gruppen sowie lokale Gruppen, die der Administrator definiert hat. In Active Directory werden Sie jedoch sechs verschiedene Arten von Sicherheitsgruppen finden: vordefinierte lokale Gruppen der Domäne, vordefinierte globale Gruppen, vordefinierte universelle Gruppen, benutzerdefinierte lokale Gruppen der Domäne, benutzerdefinierte globale Gruppen und benutzerdefinierte universelle Gruppen.

Lokalen Gruppen der Domäne können nur Berechtigungen für Ressourcen innerhalb der Domäne zugewiesen werden, in der sie definiert sind. Sie können aber Benutzer sowie universelle und globale Gruppen aus jeder vertrauenswürdigen Domäne oder Gesamtstruktur sowie lokale Gruppen der Domäne aus ihrer eigenen Domäne enthalten.

Eine globale Gruppe darf nur Benutzer und globale Gruppen aus der Domäne enthalten, in der sie definiert wurde, aber ihr können Berechtigungen für Ressourcen in jeder Domäne in der Gesamtstruktur, zu der die Domäne gehört, oder in jeder vertrauenswürdigen Gesamtstruktur zugewiesen werden.

Eine universelle Gruppe kann Benutzer sowie universelle und globale Gruppen aus jeder beliebigen Domäne enthalten. Einer universellen Gruppe können Berechtigungen für Ressourcen in jeder vertrauenswürdigen Domäne oder Gesamtstruktur zugewiesen werden. Anders gesagt, ist eine universelle Gruppe eine Art von Mischform zwischen lokalen Gruppen der Domäne und globalen Gruppen.

Während eine Arbeitsstation standardmäßig nur zwei Gruppen enthält (Administratoren und Gäste), enthält eine Domäne eine relativ große Anzahl von Gruppen, und zwar aller drei Typen. Abbildung 5 zeigt die Standardgruppen in einer Domäne. Alle sind als Sicherheitsgruppen festgelegt, das heißt, ihnen können Berechtigungen zugewiesen werden. (Sicherheitsgruppen dürfen nicht mit Verteilergruppen verwechselt werden, die von Microsoft Exchange Server verwendet werden, um Benutzer in E-Mail-Listen zu gruppieren. Beides wird in Active Directory definiert.) Die lokalen Gruppen, die auf allen Windows-basierten Computern vorhanden sind, werden in Active Directory auf Domänencontrollern definiert.

Abbildung 5 Im Benutzercontainer in Active Directory definierte Standardgruppen

Wie Domänencontroller haben auch einige Nichtdomänencontroller eine große Anzahl von Gruppen. Abbildung 6 zeigt 16 vordefinierte Gruppen auf einem Testcomputer. Die genaue Zahl der Gruppen auf einem bestimmten Computer wird sich in Abhängigkeit von den Rollen, die Sie auf diesem Computer installiert haben, unterscheiden.

Abbildung 6 Vordefinierte Gruppen auf einem Nicht-DC (zum Vergrößern auf das Bild klicken)

Wenn Sie versuchen würden, einem Objekt Berechtigungen zuzuweisen, würden Sie immer noch mehr Gruppen finden, als hier bislang angegeben wurden. Genau genommen, würden Sie auf einem einfachen DC mindestens 63 Gruppen und vordefinierte Sicherheitsprinzipale finden (siehe Abbildung 7).

Viele der 63 Gruppen, die Sie in Abbildung 7 sehen, sind abstrakte Konzepte, die manchmal auch als „Sonderidentitäten“ bezeichnet werden und eine dynamische Gruppe von Sicherheitsprinzipalen darstellen. Sie werden manchmal auch als Anmeldegruppen bezeichnet.

Anmeldegruppen Anmeldegruppen sind Gruppen, die einen dynamischen Aspekt eines Sicherheitsprinzipals darstellen, z. B. wie ein Benutzer oder ein anderer Sicherheitsprinzipal sich angemeldet hat. Zum Beispiel umfasst die Gruppe INTERAKTIV in Abbildung 7 alle Benutzer, die sich bei der Konsole des Computers und über die Terminaldienste angemeldet haben. Im Gegensatz dazu enthält die Gruppe NETZWERK alle Benutzer, die sich über das Netzwerk angemeldet haben. Definitionsgemäß kann ein Benutzer immer nur Mitglied einer dieser Gruppen sein, und die Gruppenmitgliedschaft wird zur Anmeldezeit zugewiesen. Sie können diese Gruppen verwenden, um allen Benutzern, die sich auf eine bestimmte Art anmelden, Berechtigungen zu gewähren, aber Sie können nicht kontrollieren, wer Mitglied dieser Gruppen wird.

Abbildung 7 Ein grundlegender DC enthält mindestens 63 Gruppen und verdefinierte Sicherheitsprinzipale

Es gibt auch andere Gruppen dieser Art. Vor allem soll auf die Gruppe „Jeder“ und die Gruppe „Authentifizierte Benutzer“ hingewiesen werden. Die Gruppe „Jeder“ enthält, so wie der Name impliziert, jeden Benutzer, der auf diesen Computer zugreift, mit der Ausnahme, dass ab Windows XP vollständig anonyme, nicht authentifizierte Benutzer ausgeschlossen werden. Anders gesagt, ist der berüchtigte NULL-Benutzer unter einem beliebigen unterstützten Windows-basierten Betriebssystem nicht in der Gruppe „Jeder“ enthalten. Gäste sind jedoch enthalten.

Die Gruppe „Authentifizierte Benutzer“ wird zwar auch dynamisch aufgefüllt, enthält aber nur die Benutzer, die tatsächlich authentifiziert sind. Folglich sind Gäste in der Gruppe „Authentifizierte Benutzer“ nicht enthalten. Das ist der einzige Unterschied zwischen diesen beiden Gruppen. Da aber das einzige unter dem Betriebssystem vorhandene Gastkonto deaktiviert ist, gibt es keinen funktionalen Unterschied zwischen „Authentifizierte Benutzer“ und „Jeder“, es sei denn, Sie haben das Gastkonto manuell aktiviert. In diesem Fall wollen Sie vermutlich Gästen den Zugriff auf Ressourcen ermöglichen und benötigen deshalb die intakte Gruppe „Jeder“.

Trotzdem haben viele Administratoren schlaflose Nächte mit dem Gedanken verbracht, dass „jeder in der Welt über Berechtigungen für meinen Server verfügt“, und haben sehr drastische Schritte unternommen, die Berechtigungen zu ändern, um diese Situation zu korrigieren. In der Regel führen diese Änderungen zu äußerst verheerenden Ergebnissen. Sie haben überhaupt keinen Grund dazu, die Berechtigungen für „Jeder“ durch „Authentifizierte Benutzer“ zu ersetzen. Entweder wollen Sie, dass Gäste über Berechtigungen für Ihren Computer verfügen, und aktivieren das Gastkonto, oder Sie unterlassen dies and lassen das Gastkonto deaktiviert. Wenn Gäste Berechtigungen haben sollen, benötigen Sie die Berechtigungen für „Jeder“. Wenn Sie dies nicht wünschen, besteht kein Unterschied zwischen der Gruppe „Jeder“ und der Gruppe „Authentifizierte Benutzer“.

Einige argumentieren, dass es um eine „Tiefenverteidigung“ geht, wenn diese Änderungen vorgenommen werden. Das wäre wahr, wenn Sie „Tiefenverteidigung“ als „anders nicht zu rechtfertigende Änderungen“ definieren. Tatsache ist, dass solche Änderungen nur eine geringe oder keine Sicherheitsverbesserung bieten, aber ein sehr großes Risiko bergen. Lassen Sie die Standardeinstellungen also in Ruhe.

Wenn dieses Argument nicht überzeugend genug war, verweise ich auf den Microsoft Knowledge Base-Artikel 885409 (Empfehlungen zur Sicherheitskonfiguration). Darin wird kurz gesagt erklärt, dass das pauschale Ersetzen von Berechtigungen Ihren Supportvertrag außer Kraft setzen kann. Wenn Sie dies tun, erstellen Sie im Grunde Ihr eigenes Betriebssystem, und Microsoft kann nicht mehr garantieren, dass es funktioniert.

Es ist außerdem wichtig, auf den Unterschied zwischen „Benutzer“, wobei es sich um eine verdefinierte Gruppe handelt, und „Authentifizierte Benutzer“ hinzuweisen. Der Unterschied ist die recht offensichtliche Tatsache, dass die Gruppe „Authentifizierte Benutzer“ jeden Benutzer enthält, der auf dem Computer authentifiziert wird, einschließlich Benutzern in anderen Domänen, Benutzern, die Mitglieder lokaler Gruppen (außerhalb der Gruppe „Benutzer“) sind, sowie Benutzern, die überhaupt keine Mitglieder von Gruppen sind (das ist tatsächlich möglich). Dies bedeutet, dass die Gruppe „Benutzer“ sehr viel eingeschränkter ist als die Gruppe „Authentifizierte Benutzer“.

Trotz dieser Tatsache habe ich miterlebt, wie Organisationen ihre Netzwerke zerstören in dem Versuch, Berechtigungen für die Gruppe „Benutzer“ durch Berechtigungen für die Gruppe „Authentifizierte Benutzer“ zu ersetzen, „um ihre Systeme abzusichern“. Ich habe endlose Diskussionen mit ratlosen PCI/DSS-Prüfern geführt, die behaupten, dass die Zahlungskartenbranche erfordert, dass Sie alle Berechtigungen für „Benutzer“ durch „Authentifizierte Benutzer“ ersetzen. Dies ist jedoch nicht der Fall.

Ich habe außerdem Organisationen in der ganzen Welt vor Beratern bewahrt, die das pauschale Ersetzen der Zugriffssteuerungsliste (access control list, ACL) als großartige Möglichkeit ansehen, Arbeitsstunden anzuhäufen. Es versteht sich von selbst, dass Sie davon ausgehen können, dass alle Versuche, „Benutzer“ durch „Authentifizierte Benutzer“ zu ersetzen, sowohl in Bezug auf Sicherheit als auch hinsichtlich der Stabilität größtenteils erfolglos bleiben.

Dienste

Windows Vista und Windows Server 2008 unterstützen eine neue Art von Sicherheitsprinzipal: einen Dienst. Um zu verstehen, wie wertvoll diese Entitäten sind, denken Sie an die aktuelle Debatte über hostbasierte Firewalls. Eifrig von den Anbietern unterstützt, die die Produkte verkaufen, argumentieren viele damit, dass hostbasierte Firewalls den ausgehenden Datenverkehr filtern müssen, damit sie sich lohnen, weil dies das restliche Netzwerk vor einem gefährdeten Computer schützt. Objektiver Denkende weisen darauf hin, dass sich die Malware bei einem beeinträchtigten Computer bereits auf dem Computer befindet und folglich die Möglichkeit hat, die hostbasierte Firewall zu umgehen oder ganz zu deaktivieren.

Um zu verstehen, warum dies der Fall ist, denken Sie an zwei Dienste, die den gleichen Sicherheitsprinzipal ausführen. Dienst A darf durch die Firewall kommunizieren, Dienst B nicht. Wenn Dienst B beeinträchtigt ist, könnte der Angreifer diese Einschränkung einfach durch Übernehmen eines anderen Prozesses, der als dieser Sicherheitsprinzipal, z. B. Dienst A, ausgeführt wird, umgehen und stattdessen von diesem Prozess aus kommunizieren.

Zur Behebung dieses Problems benötigte Microsoft eine Möglichkeit, um einem Prozess, oder genauer gesagt einem Dienst, Berechtigungen zuzuweisen. Für diesen Zweck wurden aus Diensten eigenständige Sicherheitsprinzipale. Deshalb hat jetzt jeder Dienst einen Bezeichner, der verwendet werden kann, um Berechtigungen anzuwenden. Sie können den Befehl „sc showsid“ über die Befehlszeile ausführen, um die Dienst-SID für jeden beliebigen Dienst anzuzeigen.

Mit Dienst-SIDs können Sie den Zugriff auf Ressourcen für bestimmte Prozesse, und nicht nur für bestimmte Benutzer, einschränken. Durch diese Änderung werden ausgehende hostbasierte Firewallfilter in manchen Situationen bedeutsam. Wie diese Situationen im Einzelnen aussehen, geht über den Rahmen dieser Erörterung hinaus, aber wenn Sie mehr darüber erfahren möchten, schlage ich die Lektüre des Artikels vor, den ich über die Windows Vista-Firewall in der Ausgabe des TechNet Magazins vom Juni 2008 geschrieben habe (siehe Verwalten der Windows Vista-Firewall).

Zusammenfassung

Sicherheitsprinzipale sind so eng mit der Windows-Sicherheit verbunden, dass es für alle Administratoren wichtig ist, zumindest ein grundlegendes Verständnis davon zu haben, wie die verschiedenen Arten von Sicherheitsprinzipalen funktionieren und wie sie verwendet werden. Nur durch das Verständnis dieser Themen können Sie eine Sicherheitsstrategie erstellen, die diese Sicherheitsprinzipale wirksam einsetzt. Dieses Wissen ist nützlich, wenn Sie sinnlose Argumente abwehren müssen, die nicht auf einem tiefen Verständnis der Sicherheitsprinzipale beruhen, und wenn von Ihnen erwartet wird, dass Sie die Integrität Ihres Netzwerks durch unnötige und unangebrachte Änderungen gefährden.

Dieser Artikel basiert auf Inhalten aus meinem Buch Windows Server 2008 Security Resource Kit (Microsoft Press).

Jesper M. Johansson arbeitet als Principal Security Architect für ein bekanntes Fortune 200-Unternehmen im Bereich der risikobasierten Sicherheitsvision und Sicherheitsstrategie. Er schreibt außerdem redaktionelle Beiträge für das TechNet Magazin. Seine Arbeit besteht darin, die Sicherheit in einigen der größten und am stärksten verteilten Systeme der Welt zu gewährleisten. Jesper M. Johansson hat seine Doktorarbeit zum Thema Management Information Systems geschrieben, verfügt über mehr als 20 Jahre Erfahrung auf dem Gebiet der Sicherheit und ist MVP im Bereich Unternehmenssicherheit. Sein aktuelles Buch ist das „Windows Server 2008 Security Resource Kit“.