Archives for: "June 2014"
SQL Server Database Ownership: survey results & recommendations
Jun 23rd
SQL Server Datenbankbesitz: Umfrageergebnisse und Empfehlungen
(en) In the following, I am now presenting the results and giving my official recommendation for a best practice for security in terms of database ownership. |
(de) |
Server 1: http://j.mp/13_SQL_DBO_Survey
Server 2: gallery.technet.microsoft.com/scriptcenter/Database-Owners-role-3af181f5/
Now first the results. Many thanks to all those who submitted! |
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% of all databases belong to sa himself. Actually, this is better than expected. But let’s dive further – what’s the server role behind the remaining 42%? |
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, that changes the picture quite a bit. Almost 80% of all Database owners are sysadmin. So that is by no means any better than sa. So in other words: only 7% of all those databases have been looked at with security in mind by only using low privileged accounts as owners. If you are interested in the plain numbers, here they go: |
Ok, das verändert das Bild schon entscheidend. Fast 80% aller Datenbankenbesitzer sind sysadmin. Das ist also keineswegs besser als sa. 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: |
I did include some of the security-wise critical database- & server configurations:
Those are actually the even more important results. Since the system databases need to have a different setting by default, I am excluding them, making it a total of 847 User databases. |
Ich habe einige der sicherheitstechnisch kritischen Datenbank- und Serverkonfigurationen mit eingeschlossen:
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. |
In the interest of time I will focus this post on recommendation rather than explaining all the risks involved. At the end though I will provide some links for further reading. |
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. |
Possibilities So what are the general variations of database ownership?
A first improvement(? – really?): 4. Any of the above with Status = Disabled And then: 5. A ”shared” account without any special server role or permissions (aka “1 Account per Server”) 6. 1 Account per Database 7. 1 Account per Application 8. 1 Account per Group of databases + all of them not only Disabled but with a Denied Connect-Permission |
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 ;-) ):
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 |
My Recommendation: Depending on your environment: Any of 5, 6, 7 or 8: Create a specific Login without any extra permissions + Deny Connect. The most simple approach and yet better than sa is: one database owner per server.
Simple and self-explanatory. The other extreme and most secure is: per database.
Some applications use a number of different databases. For them it’s perfectly fine to use the same database owner account. So create an account per application. Example for (7):
Another approach is kind of a compromise between 1 Database-Owner Account per Server and One per database: Define the level of security needed per database. Then create a dedicated account for the most critical Databases. And for the others use a shared owner/account, possibly divided in 2 or more groups. Example for (8):
I hope my samples give you an idea. :-) So why this effort? It may not matter a lot, if everything else is tightened, but that’s hardly a thing to rely on especially in bigger environments where things change and many people have access and permissions to. And since the attack starts from inside, it really doesn’t matter whether the sa/sysadmin account is disabled as you may now realize. Having a dedicated account with zero special permissions as database owner prevents database principals from gaining system level permissions as a sysadmin has, even in the case of the database being trustworthy. |
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):
Einfach und selbsterklärend. Das andere Extrem und dabei die sicherste ist: pro Datenbank. Beispiel für (6):
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):
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):
Ich hoffe, meine Beispiele geben euch eine Vorstellung. :-) Aber warum diese Mühe? 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. 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. |
Call for actions: Check your databases. You can find my script here: Security-Check-Script & Survey: SQL Server Security - Database-Owners, critical Permissions and role membership Also make sure you fully understand your environment and possibly application needs before you just change the owner of your databases. You can start by reading through the links at the bottom. Vote for an improvement in SQL Server: |
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: |
I hope this was helpful. If you have any questions feel free to comment. |
Ich hoffe, das war hilfreich. Wenn ihr noch Fragen habt, kommentiert gern. |
Highly recommended reading:
Dringend empfohlen:
More on Disabling and Deny Connect:
Mehr zu…
DISABLE and DENY LOGIN, DENY USER & Effect on Impersonation and Permissions
More on trustworthy:
The TRUSTWORHY bit database property in SQL Server 2005
Extending Database Impersonation by Using EXECUTE AS
Discussions:
Database/Object Ownership Misalignment
database ownership - sa disabled
Happy Securing
Andreas