2011-06-21

Wie erhält der SQL Server Dienst seine Rechte?

Die Botschaft ist nicht neu aber wichtig: Der SQL Server Dienst sollte mit einem Benutzerkonto ausgeführt werden, das mit minimalen Rechten ausgestattet ist. Um das zu erreichen, erstellen Sie ein Windows Benutzerkonto (lokal oder in der Domäne) und weisen mit Hilfe des Programms SQL Server Configuration Manager (SSCM) dieses Konto dem SQL Server Dienst zu. Das funktioniert einfach und sicher.

Aber was genau macht der Configuration Manager?

Der erfahrene Berater antwortet: "Das kommt drauf an..."
Es kommt auf die SQL Server Version und auf das Betriebssystem an.
  • Fall 1: SQL Server 2005 oder Betriebssystem XP / Windows 2003 Server
  • Fall 2: SQL Server 2008 (und neuer) und Betriebssystem Vista / Windows 2008 (und neuer)
Fall 1
Dieser Fall trifft immer zu, wenn Sie SQL Server 2005 installieren. Er trifft aber auch zu, wenn Sie SQL Server 2008 (und neuer) auf einem "Pre-Vista" Betriebssystem installieren (XP oder Windows 2003 Server).
In diesem Fall werden bei der Installation der SQL Server Instanz Windows Gruppen angelegt, die lange aber sprechende Namen haben, zum Beispiel: SQLServer2005MSSQLUser$AC$SQL2005
In diesem Fall ist AC der Name der Windows Maschine und SQL2005 der Name der SQL Server Instanz. Dieser Windows Gruppe werden alle Berechtigungen erteilt, die der SQL Server Dienst benötigt. Das sind Zugriffe auf Ordner, Dateien und Registry Einträge. Sie können das zum Beispiel sehen, wenn Sie sich die Berechtigungen auf die Datei sqlservr.exe ansehen:
ACL für sqlservr.exe (Fall 1)
Die Windows Gruppe SQLServer2005MSSQLUser$AC$SQL2005 hat auf diese Datei Lese- und Ausführungs-Berechtigung. Wenn Sie mit SSCM das Dienstkonto ändern, dann wird dieses Konto Mitglied der Windows Gruppe SQLServer2005MSSQLUser$AC$SQL2005 und hat somit alle erforderlichen Berechtigungen.
Der technische Ausdruck für die Erteilung der Berechtigungen heißt übrigens Access Control List (ACL). Das obige Bild ist die grafische Darstellung dieser Zugriffsliste für die Datei sqlservr.exe
Das folgende Bild zeigt, dass das Dienstkonto von SQL Server Mitglied in der Gruppe SQLServer2005MSSQLUser$AC$SQL2005 ist.
Mitglieder der Windows Gruppe MSSQLUser (Fall 1)

Fall 2
Etwas anders sieht es aus, wenn Sie SQL Server 2008 (oder neuer) auf einem aktuellen Betriebssystem (ab Vista / Windows Server 2008) installieren. Auch dann erhält die Windows Gruppe die erforderlichen Berechtigungen auf Ordner, Dateien und Registry Einträge:
ACL für sqlservr.exe (Fall 2)
In diesem Fall heißt die Windows Gruppe SQLServerMSSQLUser$LEV$MSSQLSERVER, weil der Windows Server den Namen LEV hat und die SQL Server Instanz die Standardinstanz ist. So weit, so gut. Aber wenn wir nun nachsehen, wer Mitglied dieser Windows Gruppe ist, erleben wir eine Überraschung:
Mitglieder der Windows Gruppe MSSQLUser (Fall 2)
Mitglied dieser Gruppe ist nicht das SQL Server Dienstkonto, sondern der SQL Server Dienst selbst! Man sagt auch, es handelt sich um die Service-SID. SID ist die Abkürzung für Security-ID; das ist die Nummer S-1-5-80-..., die hinter dem Namen NT Service\MSSQLSERVER steht.
Und was bedeutet diese Änderung gegenüber Fall 1?
  • Die Service-SID ändert sich nicht, wenn das Dienstkonto geändert wird. SSCM muss also nicht mehr das Dienstkonto in die Windows Gruppe aufnehmen.
  • Das Dienstkonto bekommt keine Berechtigungen mehr auf die Ordner, Dateien und Registry Einträge der SQL Server Instanz. Die Folge: höhere Sicherheit. Denn selbst wenn nun ein Eindringling das Passwort des Dienstkontos in Erfahrung bringt, erhält er damit keine Zugriffsberechtigungen auf die Dateien der SQL Server Instanz.

Änderungen bei sysadmin
Diese Änderung betrifft auch die Mitglieder in der Serverrolle sysadmin. Beim SQL Server 2005 (genauer: im Fall 1) sind die Anmeldungen der Windows Gruppen MSSQLUser und SQLAgentUser Mitglieder dieser kritischen Rolle. Wer also das Passwort des Dienstkontos von SQL Server oder SQL Server Agent errät, der kann mit der SQL Server Instanz tun und lassen, was er/sie möchte!
Mitglieder der sysadmin-Rolle (Fall 1)
Seit SQL Server 2008 (genauer: im Fall 2) sind die Service-SID von SQL Server und SQL Server Agent Mitglieder dieser Rolle. Eine Angriffsmöglichkeit weniger!
Mitglieder der sysadmin-Rolle (Fall 2)


Links
Dieser Beitrag von Dan Jones hat mir beim Lösen des Rätsels geholfen:
http://blogs.msdn.com/b/dtjones/archive/2010/12/15/changing-service-account-amp-service-account-password.aspx