SQL Server Datenbankbesitz: Umfrageergebnisse und Empfehlungen
Ihr erinnert Euch vielleicht an die Umfrage zu Datenbankbesitz, die ich vor einigen Monaten gestartet habe. Hier präsentiere ich nun die Ergebnisse und gebe meine offiziellen Empfehlungen für Sicherheits-Best Practice hinsichtlich Datenbankbesitz. Zunächst, wer noch den Script benötigt:
Server 1: http://j.mp/13_SQL_DBO_Survey Server 2: gallery.technet.microsoft.com/scriptcenter/Database-Owners-role-3af181f5/
Nun zuerst einmal die Ergebnisse.
Ich habe insgesamt von 58 verschiedenen Servern und 905 Datenbanken Daten erhalten.
Das ist nicht schlecht. Und es ist ausreichend für meine Zwecke – Euch, meinen Lesern, die Gelegenheit zu gegeben herauszufinden, wie andere ihre Server konfigurieren.
Vielen Dank an alle, die ihre Daten eingereicht haben!
Ihr könnt eure Ergebnisse immer noch mit mir teilen, aber ich kann euch nicht versprechen, wie bald ich sie mit einschließen kann. (Hier sind die Umfrage sowie das Skript für die Datenerfassung.)
Nun zu den Details. Ich habe die interessantesten Daten in Diagramme gesetzt.
Die offensichtlichste Frage ist die des Kontos des externen Besitzers, das am häufigsten und nicht überraschenderweise sa ist:
57% aller Datenbanken gehören sa selbst. Dies ist sogar besser als erwartet. Aber schauen wir mal genau hin – was ist die Server-Rolle hinter den verbleibenden 42%?
Ok, das verändert das Bild schon entscheidend. Fast 80% aller Datenbankenbesitzer sind sysadmin. Das ist also keineswegs besser als sa. Es folgen einige andere Konten, das bedeutet, dass diese niedrige Privilegien (“hervorragend”) haben, und dann folgen dbcreator, securityadmin, auf die später einige andere hochprivilegierten Serverrollen folgen, doch mit weitaus weniger Privilegien.
Mit anderen Worten: nur 7% aller dieser Datenbanken wurden im Hinblick auf Sicherheit betrachtet, indem von Besitzern nur niedrigprivilegierte Konten verwendet wurden.
Wenn euch die genauen Zahlen interessieren, hier sind sie:
Ich habe einige der sicherheitstechnisch kritischen Datenbank- und Serverkonfigurationen mit eingeschlossen:
- Ist die Datenbank auf „Trustworthy“ eingestellt?
- Ist in der Datenbank „Datenbank-Verkettung an“ eingestellt?
- Ist im Server „cross database chaining on“ eingestellt?
Diese sind eigentlich die wichtigeren Ergebnisse.
Da die Systemdatenbanken standardmäßig eine andere Einstellung haben müssen, schließe ich sie in meiner Bewertung aus, so dass ich auf insgesamt 847 Nutzer-Datenbanken komme.
30 von ihnen haben das Trustworth-Bit eingestellt, und 35 haben die Datenbanken-Verkettung eingeschaltet.
Was ihr in dieser Grafik nicht sehen könnt, aber was ich aus den Rohdaten erkennen kann, ist, dass diese 30 „vertrauenswürdigen“ Datenbanken alle im Besitz von einem sysadmin sind. Und DAS ist das größte Sicherheitsloch in diesem Bereich! Hier ein Diagramm dazu:
Aus Zeitgründen werde ich diesen Eintrag auf Empfehlungen beschränken, als alle Risiken zu erklären. Am Ende werde ich jedoch einige Links für weiterführende Lektüre angeben.
Möglichkeiten
Was sind also die allgemeinen Variationen von Datenbanken-Besitztum?
Fangen wir mit den häufigsten und eigentlich SCHLECHTESTEN Möglichkeiten an (Ja, das meine ich genau so, wie es hier steht 😉 ):
- SA-Konto
- Irgendein anderes SQL-Konto mit sysadmin-Privilegien
- Windows Login mit sysadmin-Privilegien
Eine erste Verbesserung(? – wirklich?):
4. Alle der oben angegebenen mit Status = Deaktiviert
Und dann:
5. Ein „geteiltes“ Konto ohne eine spezielle Serverrolle oder Rechte (Alias „1 Konto pro Server“)
6. 1 Konto pro Datenbank
7. 1 Konto pro Anwendung
8. 1 Konto pro Datenbank-Gruppe
+ alle davon nicht nur Deaktiviert sondern mit einer verweigerten Verbindungs-Berechtigung
Meine Empfehlung:
Abhängig von eurer Umgebung: eine von 5, 6, 7 oder 8:
Ein spezifisches Login errichten ohne extra Rechte + Deny Connect.
Die einfachste Herangehensweise und doch besser als sa ist: ein Datenbankbesitzer pro Server.
Beispiel für (5):
- Datenbank1 im Besitz von DBOwner
- Datenbank2 im Besitz von DBOwner
- Datenbank3 im Besitz von DBOwner
Einfach und selbsterklärend.
Das andere Extrem und dabei die sicherste ist: pro Datenbank.
Beispiel für (6):
- Datenbank1 in Besitz von DBOwner_Database1
- Datenbank2 in Besitz von DBOwner_Database2
- Datenbank3 in Besitz von DBOwner_Database3
- Datenbank4 in Besitz von DBOwner_Database4
Einige Anwendungen verwenden eine Reihe von unterschiedlichen Datenbanken. Für sie ist es völlig ausreichend, das gleiche Datenbankbesitzerkonto zu verwenden. Erstellt also ein Konto pro Anwendung.
Beispiel für (7):
- App1Database1 in Besitz von DBOwner_App1
- App1Database2 in Besitz von DBOwner_App1
- App2Database1 in Besitz von DBOwner_App2
- App2Database in Besitz von DBOwner_App2
Eine andere Herangehensweise ist eine Art Kompromiss zwischen 1 Datenbankenbesitzerkonto pro Server und einem pro Datenbank: Definiere das Sicherheitslevel, das je Datenbank gebraucht wird. Dann erstelle ein spezielles Konto für die kritischsten Datenbanken. Und für die anderen Besitzer einen gemeinsamen Besitzer-/Konto verwenden, möglicherweise in 2 oder mehr Gruppen geteilt.
Beispiel für (8):
- CriticalDatabase1 in Besitz von DBOwner_Level1Dedicated1
- CriticalDatabase2 in Besitz von DBOwner_ Level1Dedicated2
- Level2Database1 in Besitz von DBOwner_Level2
- Level2Database2 in Besitz von DBOwner_Level2
Ich hoffe, meine Beispiele geben euch eine Vorstellung. 🙂
Aber warum diese Mühe?
Lasst es mich so ausdrücken: “Warum nicht sa?”
Zuallererst: Denkt man darüber nach, ergibt es eigentlich wenig Sinn, dass das höchstprivilegierte Konto beim SQL Server von so vielen empfohlen wird, selbst von Profis + in Whitepapers (!) – wenn Sicherheit im Fokus steht. Es ist wirklich falsch, so falsch wie es nur irgend sein kann.
Schließlich gibt es da draußen, wie ihr sehen könnt, noch andere Optionen.
Die Grund Nr. 1, warum SA immer wieder empfohlen wird, ist die Administration selbst: Es erleichtert das Einrichten für Failover und regelmäßige Datenbankenwiederherstellungen, da SA immer auf jedem Server verfügbar ist und damit ein kaputter Datenbankbesitzer mit wenig zusätzlichem Aufwand verhindert werden kann.
Aber das ist „nur“ aus Sicht der Wartung.
Was die Sicherheit angeht, steht es völlig im Gegensatz zum Prinzip des geringsten Privilegs.
Es mag nicht viel ausmachen, wenn alles andere straff sitzt, aber darauf sollte man sich nicht verlassen, besonders in größeren Umgebungen, wo sich Dinge ändern und viele Leute Zugriff und Befugnisse haben.
Besonders im Kontext der Trustworthy-Einstellung für eine Datenbank öffnet dies das System komplett für privilege escalation-Angriffe von innen. Dann ist es ein Kinderspiel, Systemlevel-Befugnisse zu erlangen, wenn man einmal z.B. in der db_owner Datenbankengruppe ist – wie es viele Anwendungen sind, wenn sie nicht bereits sysadmin sind.
Denkt dran: dem Datenbankenbesitzer kann weder innerhalb noch mit seiner Datenbank etwas verweigert werden. Er kann also die Struktur verändern, Backups erstellen, Log-Backup-Chain brechen und sie auch komplett löschen.
Und da der Angriff von innen anfängt, ist es wirklich egal, ob das sa/sysadmin Konto deaktiviert ist, wie ihr jetzt realisiert haben werdet.
Ein spezielles Konto mit Null speziellen Befugnissen als Datenbankbesitzer zu haben hindert Datenbank-Prinzipale daran, System-Level-Befugnisse zu erlangen, wie sie ein sysadmin hat, selbst in dem Fall, dass die Datenbank vertrauenswürdig ist.
Und „trustworthy“ ist eine der unsauberen kleinen Abkürzungen für Entwickler, die CLR-Code im Innern der Datenbank ausführen und sich dabei die Umstände sparen, unter bestimmten Bedingungen Zertifikate benutzen zu müssen. Dasselbe wird oft für Code gemacht, der Server-Level-Daten aus dem Innern der Datenbank erreichen muss.
Handlungsaufruf:
Überprüft eure Datenbanken. Ihr könnt meinen Skript hier finden: Sicherheitsprüfungs-Script & Umfrage: SQL Server Datenbankbesitzer, kritische Rechte und Rollenmitgliedschaft
Wenn ihr jetzt anfangt, eure Datenbanken aus der Perspektive von Datenbanken-Besitz zu sichern, müsst ihr dabei sicherstellen, dass dasselbe Konto auf jedem Server existiert, wo diese Datenbank wiederhergestellt/failed over wird. Normalerweise werdet ihr bereits eine Technik haben, wie ihr eure Server-Level-Prinzipale mit euren anderen Servern synchronisiert. Das sind also nur eine oder einige mehr davon.
Stellt außerdem sicher, dass ihr eure Umgebung und möglicherweise Anwendungsbedürfnisse vollständig versteht, bevor ihr den Besitzer eurer Datenbanken einfach ändert. Ihr könnt damit anfangen, indem ihr euch unten aufgelisteten Links durchlest.
Abstimmen für eine Verbesserung im SQL Server:
Ich habe einen Vorschlag als Connect Item erstellt, der dieses Problem behandelt. Meine Vorstellung ist es, Microsoft dazu zu bringen, standardmäßig ein spezielles „DBOwner“ Konto auf Server-Level auszuliefern, das nicht nur bereits immer vorab existiert und keine Rechte hat, sondern auch nie mit anderen vergleichbar ist. Ich denke, dass dies es viel einfacher machen würde, die allgegenwärtige Gewohnheit des „sa“ loszuwerden und es gleichzeitig auch einfach Wartbar machen würde. Bitte hier Eure Stimme abgeben: Providing a special Server principal for Database Ownership
Ich hoffe, das war hilfreich.
Wenn ihr noch Fragen habt, kommentiert gern.
Zum Abschluss einige Links für weiterführende Lektüre:
Dringend empfohlen:
Mehr zu Disabling and Deny Connect:
DISABLE and DENY LOGIN, DENY USER & Effect on Impersonation and Permissions
Mehr zu Trustworthy:
The TRUSTWORHY bit database property in SQL Server 2005
Extending Database Impersonation by Using EXECUTE AS
Diskussionen:
Database/Object Ownership Misalignment
database ownership – sa disabled
Happy Securing
Andreas
Hinterlasse einen Kommentar
An der Diskussion beteiligen?Hinterlasse uns deinen Kommentar!