Das Principle of Least Privilege (POLP)

(Teil 1 meiner Artikelserie über Sicherheitsprinzipien in Microsoft SQL-Servern & Datenbanken)

Das erste Sicherheitsprinzip, das ich besprechen werde, ist eines, das den meisten Systemadministratoren bekannt ist: das Principle of Least Privilege (= „Prinzip der geringsten Privilegien“) (kurz: POLP). Es besagt, dass die erforderlichen Berechtigungen für eine Aufgabe nur den Zugriff auf die benötigten Informationen oder Ressourcen gewähren sollen, die eine Aufgabe erfordert. Bei der Vergabe von Berechtigungen sollen so wenig Privilegien wie möglich vergeben werden.

POLP ist deshalb so wichtig, weil es zunächst die Privilegien sind, auf die es jeder Angreifer abgesehen hat. Bei der Entwicklung einer Anwendung ist die Verwendung eines Benutzerkontos mit den geringsten Privilegien (LUA) die erste Einsatzregel.

Hinweis
Die Benutzerkontensteuerung (User Account Control, UAC) in Windows ist eine Funktion, die Microsoft entwickelt hat, um Administratoren dabei zu unterstützen, standardmäßig mit den niedrigsten Berechtigungen zu arbeiten und diese nur bei Bedarf auf höhere Berechtigungen zu erweitern.

Sie wissen vielleicht auch, dass Microsoft empfiehlt, Dienstkonten zu trennen. Diese bewährte Sicherheitspraxis wird allgemein als service account isolation (= „Isolierung von Dienstkonten“) bezeichnet und hängt mit POLP zusammen: Die Verwendung getrennter Dienstkonten verhindert eine Erhöhung der Berechtigungen, was leicht passiert, wenn ein Konto für mehrere Zwecke gemeinsam genutzt wird und infolgedessen die Berechtigungen vermischt werden. – Dies würde gegen das Prinzip des geringsten Privilegs verstoßen.

Sowohl POLP als auch die Isolierung von Dienstkonten helfen dabei, die Angriffsfläche zu reduzieren (attack surface reduction).

– Lesen Sie mehr zu diesem Thema hier: SQL Server Sicherheit – SQL Server | Microsoft Docs

und hier: Oberflächenkonfiguration – SQL Server | Microsoft Docs

Die Isolierung von Dienstkonten verhindert auch laterale Bewegungen (lateral movement) zwischen Diensten, wenn sich ein Angreifer Zugriff auf einen Dienst verschafft hat. Sehen Sie, wie in der Sicherheit das eine mit dem anderen verbunden ist?

Hinweis
Lateral movement ist eine gängige Angriffsstrategie, um von einem Ziel zum nächsten zu gelangen: Wenn in das Hauptziel (z. B. den Datenbankserver) nicht direkt eingedrungen werden kann, versuchen Angreifer, in einem anderen Server des Systems im selben Netzwerk Fuß zu fassen und dann weitere Angriffe zu starten, um zum endgültigen Ziel zu gelangen, und zwar Server für Server oder Dienst für Dienst.

Das Principle of Least Privilege im SQL-Umfeld

Schauen wir uns einige Beispiele innerhalb der SQL Server-Engine an (gilt sowohl für On-Prem- als auch für unsere Azure SQL-Produkte):

Beispiel 1, Lese-Zugriff auf Daten

Ein typisches Beispiel innerhalb von SQL Server wäre: Um einem Benutzer zu erlauben, nur Daten aus einer kleinen Menge von Tabellen zu lesen, die idealerweise durch eine Schema-Grenze definiert sind, haben wir die SELECT-Berechtigung, die auf Schema- (oder sogar Tabellen-) Ebene gewährt werden kann. Es besteht keine Notwendigkeit, SELECT auf die gesamte Datenbank zu gewähren, oder etwas anderes als SELECT zu gewähren.

Im folgenden Code-Schnipsel sehen wir, dass es in der Datenbank WideWorldImporters viele Tabellen in verschiedenen Schemata (Application, Purchasing, Sales) gibt. Anstatt Select in der gesamten Datenbank zu gewähren, haben wir uns dafür entschieden, dem Benutzer Shakti das Recht im Schemabereich zu gewähren. Solange dieses Schema wirklich nur Objekte enthält, auf die Shakti Zugriff benötigt, ist dies eine optimale Vorgehensweise, da es den Verwaltungs- und Berichtsaufwand im Vergleich zur Erteilung von Berechtigungen auf Objektebene erheblich reduziert.

POLP-Example

Tipp
Eine Alternative ist es, gespeicherte Prozeduren für alle Datenzugriffe zu verwenden, was eine noch bessere Kontrolle ermöglicht und das Schema komplett vor den Benutzern verbirgt.

Das war doch einfach, oder?

Beispiel 2, Anlegen von Benutzerkonten

Leider wird nicht alles so implementiert, dass POLP immer gewährleistet ist.
Lassen Sie uns ein anderes Beispiel nehmen:
Sie möchten die Fähigkeit, neue Logins in SQL Server zu erstellen, delegieren.
Die minimal verfügbare Berechtigung ist ALTER ANY LOGIN. Ok, jetzt kann diese Person also neue Logins erstellen, und vielleicht ist auch das Entfernen von Logins ok.
Aber: Mit dieser Berechtigung kommt die Möglichkeit, das Passwort eines beliebigen SQL-Logins zu ändern („ALTER LOGIN … WITH PASSWORD=’NewPassword‘).
Dies kann ein unerwünschtes Szenario sein, da es diese Person in die Lage versetzen würde, im Wesentlichen andere Konten zu übernehmen.

Hinweis
Dies würde nicht funktionieren, wenn das Konto ein Windows-Domänen- oder Azure Active Directory-Konto wäre. Hier ist eine Trennung des authentifizierenden Systems vom SQL Server von großem Vorteil. (Dies ist übrigens ein gutes Beispiel für Separation of Duties).

Beispiel 3, Ändern von Tabellenstrukturen

Wie wäre es mit folgendem Beispiel?
Angenommen, Sie möchten einem Entwickler erlauben, eine Reihe neuer Spalten zu den bestehenden Tabellen hinzuzufügen. (Zum Beispiel müssen Sie zu Protokollierungszwecken den Zeitstempel jeder neuen Zeile einfügen.)
Die geringste Berechtigung zum Ändern von Tabellen/Hinzufügen neuer Spalten ist die ALTER-Berechtigung für jede einzelne Tabelle (es kann nicht auf Schema-Ebene erfolgen).

In meinem Beispiel können Sie sehen, dass das Hinzufügen neuer Spalten problemlos funktioniert, auch das Löschen der Tabelle ist nicht erlaubt.

Aber:
Anstatt neue Spalten hinzuzufügen, könnte dieser Benutzer auch bestehende Spalten löschen. Dies fällt unter das gleiche Mindestrecht/Privileg:

Oder: Sie wollen, dass sie nur neue Tabellen erstellen, aber bestehende Tabellen nicht ändern dürfen. Da die erforderlichen Berechtigungen dafür sind: CREATE TABLE auf der Datenbank + ALTER auf dem Schema, könnten sie auch Tabellen löschen. Mit Berechtigungen allein ist das nicht zu lösen. Dies ist ein häufiger Grund für die Verwendung von DDL-Triggern als vorbeugende Kontrolle. (Ein Beispiel für einen DDL-Trigger habe ich in diesem Blog-Artikel gezeigt: Protokollierung von Schema-Änderungen in einer Datenbank mittels DDL-Trigger, der leicht angepasst werden kann, um bestimmte Anweisungen durch Rollback ganz zu verhindern).

Fazit

Je mehr Sie in dieses Thema und die praktische Umsetzung eintauchen, desto mehr werden Sie feststellen, dass dieses scheinbar einfache Sicherheitsprinzip viel schwieriger ist, als Sie vielleicht zunächst erwartet haben.
Das Berechtigungssystem von SQL Server ist sehr granular, umfangreich und wird ständig erweitert. (SQL Server 2019 bietet 248 Berechtigungen und Azure SQL Database stellt 254 Berechtigungen zur Verfügung [Stand: Dezember 2020].)
Während einige der oben genannten Beispiele sehr nachvollziehbar sind, müssen wir jede Entscheidung für jede neue Berechtigung abwägen und sie aus mehreren Blickwinkeln betrachten, wenn eine neue Funktionalität oder ein neuer Befehl implementiert wird. Zum Beispiel:

  1. Welche anderen Befehle und Aufgaben sind unter derselben Berechtigung abgedeckt?
  2. Wie hängen sie mit der vorliegenden Funktionalität zusammen?
  3. Ist die Verwendung der neuen Funktionalität/des neuen Befehls allein ein häufiges Szenario?

Berechtigungen für Teile von Tabellenstrukturen zu haben, wie z. B. das Hinzufügen von Spalten, aber nicht das Löschen, würde die Komplexität des Berechtigungssystems erhöhen und daher wurde der Kompromiss geschlossen, nur eine ALTER-Berechtigung für Tabellen-DDL zu haben.

Abgesehen davon bin ich mir bewusst, dass es Beispiele gibt, bei denen das Gleichgewicht nicht stimmt und SQL Server verbessert werden kann, z. B. TRUNCATE TABLE, das auch ALTER auf der Tabelle erfordert, und andere.

Lassen Sie mich gerne wissen, wo Ihrer Ansicht nach POLP stark unausgewogen und mehr Granularität erforderlich ist, um Konformität zu erreichen.

Viel Spaß beim Sichern

Andreas