Bei der Installation eines neuen SQL Servers wird man unter anderem nach den Account-Informationen der Dienstkonten gefragt. Leider geht die Frage in dem umfangreichen Installationsprozess etwas unter. Hinter der Frage verbirgt sich aber ein sehr wichtiges Thema, über welches man sich unbedingt im Vorfeld Gedanken machen sollte:
Wie viele Berechtigungen gebe ich meinem SQL Server?
Oder anders gefragt:
Welche Berechtigungen benötigt der SQL Server eigentlich, um seine Aufgaben korrekt und sicher zu erledigen?
Durch den Installationsprozess wird einem scheinbar die Beantwortung dieser Frage schon abgenommen. Hier wird ja gleich von Microsoft das Konto „LocalSystem“ vorgeschlagen. Leider ist diese Konfiguration sicherheitstechnisch sehr bedenklich und sollte so nicht übernommen werden.
In der Praxis findet man neben dem LocalSystem sehr häufig noch eine zweite Lösung. Bei dieser Variante wird ein Benutzerkonto erstellt, welches in die Gruppe der lokalen Administratoren aufgenommen wird. Die Steigerung hiervon ist dann nur noch ein Account mit Domänen-Admin-Rechten.
Dies bedeutet aber, dass der SQL Server viel zu viele Berechtigungen hat. Im einfachsten Fall darf er nur auf dem lokalen Computer einfach alles machen. Im schlimmsten Fall sogar alles in der gesamten AD-Domäne. Hier könnte der SQL Server nun schalten und walten wie er will, oder besser gesagt: wie man es ihm sagt. Bei einer schlechten SQL-Server-Konfiguration könnte wirklich jeder in wenigen Schritten zum Domänen-Admin werden. Ein sicherheitstechnischer Albtraum!
Wenn LocalSystem so schlecht ist, warum ist es dann die Default-Einstellung von Microsoft?
Microsoft hat hier ein Problem mit der realen Welt. Viele Administratoren und Entwickler sind eben keine Experten für den SQL Server und wissen oft nicht. was der beste bzw. richtige Weg ist für die SQL-Server-Installation. Um ihnen dennoch eine lauffähige (Grund-) Installation bereitstellen zu können, hat sich Microsoft auf Standardwerte beschränkt, welche in wirklich jeder Umgebung vorhanden sind. Somit wird ein SQL Server auch standardmäßig immer im Laufwerk C installiert und bekommt als Dienstkonto halt den LocalSystem-Account zugewiesen.
Was aber braucht der SQL Server nun an Berechtigungen?
Die Frage lässt sich tatsächlich sehr leicht beantworten. Bis auf wenige Ausnahmen in Windows werden alle notwendigen Berechtigungen schon während der Installation automatisch gesetzt und müssen in der Regel nicht mehr verändert werden. Eine Aufstellung der automatisch gewährten Berechtigungen findet man in der MSDN-Dokumentation unter https://msdn.microsoft.com/de-de/library/ms143504.aspx#Serv_SID
Was noch fehlt!
Ein paar Nacharbeiten sind aber dennoch notwendig. Hier liegt leider auch der Grund, warum viele Administratoren lieber mehr Rechte geben als zu wenig.
SQL-Server-Agent-Dienst
Damit der SQL Server Agent seine Aufgaben erfüllen kann, braucht er noch zusätzliche Lese- und Schreibberechtigungen auf bestimmte Ordner im Dateisystem. Hierzu zählen beispielsweise die Zielordner für die Backups. Nur mit den Lese-/Schreibrechten kann das Dienstkonto des Agenten die Backups auf die Festplatte sicheren und von dort auch wiederherstellen.
Soll der Agent zudem Daten aus Dateien importieren oder exportieren können, braucht das Dienstkonto auch auf diese Ordner entsprechende Berechtigungen.
SQL-Server-Dienst
Für den SQL-Server-Dienst gibt es noch zwei zusätzlich Windows Berechtigungen, welche aber Auswirkungen auf die Performance haben. Diese Berechtigungen sind:
· „Lock Pages in Memory“
https://msdn.microsoft.com/en-us/library/ms190730.aspx
· „Perform volume maintenance tasks“
https://msdn.microsoft.com/de-de/library/ms175935.aspx.
Beide Berechtigungen sind für den technischen Betrieb nicht zwingend notwendig, haben aber starken Einfluss auf die Leistung des SQL Server.
Wie kann man es besser machen?
Seit Windows Server 2008 R2 gibt es im Active Directory die so genannten „verwalteten Dienstkonten“. Diese speziellen AD-Konten haben gleich mehrere Vorteile bei der Nutzung als Dienstkonto.
- Kein Login als Nutzer möglich
- Kann nur auf berechtigten Maschinen genutzt werden
- Hat nur minimale Berechtigungen im Active Directory
- Das Passwort wird automatisch durch das Active Directory alle 30 Tage geändert
Durch die Verwendung von verwalteten Dienstkonten beugt man vielen Sicherheitsproblemen schon im Design vor und braucht sich hierüber später weniger Gedanken zu machen. Für den Betrieb von Clustern gibt es zusätzlich noch die „gruppenverwalteten Dienstkonten“, welche auf mehreren Servern gleichzeitig genutzt werden können. Diese Konten sind mit dem Windows Server 2016 auf für die AlwaysOn-Verfügbarkeitsgruppen zugelassen.
Weitergehende Informationen zu den verwalteten Dienstkonten findet man in der MSDN-/Technet-Dokumentation unter https://msdn.microsoft.com/de-de/library/hh831782(v=ws.11).aspx
http://faq-o-matic.net/?p=7746