Sicherheitsprinzip: Separation of Privilege

(Teil 4 meiner Artikelserie zu Sicherheitsprinzipien in Microsoft SQL Servers & Databases)

Das Prinzip „Separation of Privilege“ (Trennung von Privilegien), oder auch „Privilege Separation“ verlangt, dass eine einzelne Kontrollkomponente nicht ausreicht, um eine Aufgabe zu erledigen. Eine andere, allgemeinere Beschreibung ist, dass mehrere Bedingungen erfüllt sein müssen, um Zugriff auf einen bestimmten Prozess oder ein Objekt zu erhalten. Ein Kontrollelement könnte z. B. eine Berechtigung sein.

Privilege Separation wird manchmal (aber nicht notwendigerweise) mit einer Art von Vier-Augen-Prinzip implementiert und erfordert ein gewisses Maß an Abschottung eines Prozesses oder Programms, um mehrfache Zugriffskontrollen zu ermöglichen.

Dieser Ansatz in Verbindung mit dem „“ reduziert den sogenannten blast radius eines erfolgreichen Angriffs und verringert auch die Möglichkeiten für einen erfolgreichen Angriff erheblich.

– Geschichtsaffine Leute mögen „Divide et conquer“ oder im Original: „divide et impera“ als Gedächtnisstütze verwenden 🙂 .

Zufälligerweise verfügt OpenSSH eine Sicherheitsoption namens UsePrivilegeSeparation (https://linux.die.net/man/5/sshd_config), die standardmäßig eingeschaltet ist und bewirkt, dass ein unprivilegierter Child-Prozess ohne Root-Rechte den eingehenden Netzwerkverkehr bearbeitet. Dies ist jedoch eher ein Fall von klassischem PoLP und Privilege Bracketing, wie hier (The Principle of Least Privilege (POLP)) und hier (Delegation of Authority) besprochen. Wie man sieht, kann man bei der Recherche leicht durcheinanderkommen. Und ich sage nicht, dass das falsch ist. Wichtig ist nur, dass man weiß, was man erreichen will und warum.

Klassischere Beispiele wären Szenarien, in denen 2 Schlüssel benötigt werden, wie z.B. bestimmte Arten von Tresoren. Sie können von verschiedenen Personen gehalten werden oder auch nicht.

Wenn wir uns den Authentifizierungsprozess ansehen, könnte die Azure AD Multifaktor-Authentifizierung (MFA) als Beispiel für mehrere beteiligte Kontrollen betrachtet werden: Selbst wenn ein Angreifer Kenntnis über das Passwort erlangt, müsste er immer noch Zugriff auf ein zusätzliches Teil, wie das (entsperrte) Telefon, erhalten.

Anmerkung zu Separation of Privilege vs. Separation of Duties

Wie einige feststellen werden, gibt es eine große Überschneidung mit Separation of Duties (SoD): Abhängig von der genauen Implementierung kann Privilege Separation direkt SoD ermöglichen.
So wie z.B. „Vier-Augen-Prinzipien“ zur Umsetzung von Privilege Separation verwendet werden können, kann ein solcher Mechanismus auch zur Umsetzung von SoD verwendet werden.

Je nachdem, welche Quellen konsultiert werden (ich werde solche sogar in den Referenzen unten angeben), mag man lesen, dass Separation of Privileges mit SoD gleichzusetzen ist. Aber ich finde es wichtig, die feine Linie zwischen diesen beiden Prinzipien zu unterscheiden und im Auge zu behalten. Und das ist, dass Separation of Duties eine getrennte Persona erfordert.

Das ist der Grund, warum meiner Meinung nach Dual Control nicht notwendigerweise Separation of Duties löst. Dual Control könnte mit 2 Geräten gelöst werden, um die Privilegientrennung zu implementieren, aber nicht unbedingt SoD.

Tipp: Will man also die SoD-Anforderung, verschiedene Persona einzubeziehen, ausdrücken, führt die Verwendung der Begriffe „Zwei-Personen-Kontrolle“ oder „4-Augen-Prinzip“ zu weniger Verwirrung als der allgemeinere Begriff „Dual Control“.

Separation of Privilege im SQL-Bereich

In SQL Server ist Separation of Privileges in der Regel nicht per Design eingebaut, aber es gibt einige Beispiele, die die Kriterien perfekt erfüllen.

Beispiel 1, Objekterzeugung

Ein Beispiel ist, dass ein Benutzer zum Erstellen von Tabellen mindestens sowohl die ALTER-Berechtigung auf dem Schema als auch die CREATE TABLE-Berechtigung auf der Datenbank haben muss. Ansonsten ist dies ein seltener Fall innerhalb der SQL-Engine.

Beispiel 2, Abfrage über Objekte

Es gibt noch eine weitere Möglichkeit, die Rechtetrennung in SQL Server und Azure SQL zu implementieren: Wenn innerhalb einer Abfrage auf mehrere Objekte zugegriffen wird, beachtet die SQL Server-Engine normalerweise die sogenannte „Ownership-Chain“ (Besitzerkette). Dies ist ein einzigartiges Konzept für SQL Server und hat den Effekt, dass, solange jedes referenzierte Objekt innerhalb einer Abfrage demselben Prinzipal gehört wie das erste in der Kette, keine weiteren Berechtigungsprüfungen stattfinden. Das bedeutet, dass eine einzige SELECT- (oder INSERT-, UPDATE-, DELETE-) Berechtigung erforderlich ist, um z. B. auf eine Sicht (View) „AggregatedSales“ zuzugreifen, wenn diese Sicht auf eine Tabelle „Orders“ zugreift und die Sicht und die Tabelle denselben Besitzer haben. Es ist nicht erforderlich, SELECT auf die Tabelle zu gewähren, wenn die Absicht darin besteht, nur den Zugriff auf die angesammelten Daten aus der Ansicht zu gewähren. Dies ist ein eingebautes Verhalten.

Man kann jedoch absichtlich diese Besitzerkette unterbrechen und den Eigentümer der Tabelle oder der Sicht ändern (z. B. indem man sie in verschiedene Schemas und mit verschiedenen Schema-Eigentümern platziert, eine empfohlene Praxis gegenüber dem Ändern von Eigentümern auf Objektebene), was dann erfordern würde, dass der aufrufende Benutzer die SELECT-Berechtigungen sowohl für die Sicht als auch für die Tabelle hat, um die Sicht zu verwenden. Mit anderen Worten, der Benutzer würde zwei Berechtigungen benötigen. Da ist also ein weiteres Szenario der technischen Privilege Separation, da eine Berechtigung allein nicht mehr ausreicht, um auf die Sicht zuzugreifen. Fairerweise muss man aber sagen, dass dies nur für den Zugriff auf die Sicht gilt: Um die Tabelle alleine abzufragen, benötigt man immer noch nur eine SELECT-Berechtigung.

Im Code sieht das folgendermaßen aus:

Wir sehen, dass die Tabelle im Besitz eines „dbo“ (principal_id =1 ) ist, während die Sicht noch im Besitz des allgemeinen Schema-Besitzers „SchemaOwner“ ist.

Daher reicht die SELECT-Berechtigung auf der Sicht allein nicht aus, damit Benutzer Jiao diesen abfragen kann, da er auf die Tabelle zugreift.

Nachdem das SELECT auch für die Tabelle gewährt wird, kann der Benutzer die Sicht verwenden:

In vielen, wenn nicht sogar den meisten Fällen ist es sinnvoll, Besitzerketten einzurichten. Aber es gibt Fälle, in denen man sie explizit aufheben will. Im Allgemeinen ist es ratsam, sich immer bewusst dafür zu entscheiden und einen anderen Eigentümer als den eingebauten dbo zu verwenden.

Ownership-Chaining an sich ist ein Thema, das sicherlich einen eigenen Artikel verdient, aber hier wird es mit Separation of Privilege verknüpft.

Teile und sei sicherer 🙂

Andreas

Danke an meine Reviewer:

 

Rohit Nayak, Senior Program Manager in SQL Security

Raul Garcia, Principal Security Program Manager

Ressourcen