none
NTFS Berechtigungen für SQL Server RRS feed

  • Frage

  • Nachdem die Sache mit dem Übertragen von Daten auf den neuen Server geklärt wurde - vielen Dank für die ausführliche Hilfe - gibt es hier noch eine weitere offene Frage und zwar die Berechtigungen für den SQL Server auf Dateiebene.

    Installiert habe ich einen SQL Server 2008 R2 Express SP2. Dieser hat sich bei der Installation selbst sehr großzügig mit Rechten ausgestattet. Im von mir angegebenen Ordner für Daten und Logfiles hat sich der Benutzer SQLServerMSSQLUser$[Machinname]$SQLEXPRESS einfach mal eben alle Berechtigungen bis zum Vollzugriff erteilt, was etwas viel erscheint.

    Es wird ja empfohlen den SQL Server mit einem selbst erstellten Benutzer unter niedrigen Rechten laufen zu lassen, also hab ich ein Konto angelegt, nennen wir hier es einfach mal "SQLKonto", unter dem der SQL Server läuft. Die oben genannten Rechte hab ich komplett gelöscht und dem SQLKonto "lesen" und "schreiben" in den angegebenen Ordnern der Daten, Logfiles und dem Zielordner für die Backups gegeben. Funktioniert auch alles gut und so war es auch auf der alten Maschine mit SQL 2005 Express.

    Ich konnte mich allerdings noch erinnern, dass auf der alten Maschine der Baseline Security Analyser Beschwerde eingelegt hat, weil der SQL Server in seinen Programm Ordnern immer noch zu viele Berechtigungen hat. Damals aus Zeitgründen nicht angegangen, hab ich mir das jetzt mal angeschaut und folgendes festgestellt: SQLServerMSSQLUser$[Machinname]$SQLEXPRESS darf im gesamten Ordner "MSSQL", der in c:\Programme ... MSSQL10_50.SQLExpress\ liegt, lesen und ausführen. In einigen Unterordnern, wo z.B. die TempDB, etc. liegen hat er überall wieder Vollzugriff eingetragen, einschließlich das Ändern von Berechtigungen selbst?

    Muss das sein? Wie ist die minimale Berechtigung, die SQL Server in seinen Stammordnern braucht?

    Danke schon für alle Antworten ;)

    Montag, 8. April 2013 09:11

Antworten

  • Hallo Jan Alexander,

    ja, das muss sein - siehe  Einrichten von Windows-Dienstkonten

    "Großzügig" ist der SQL Server Setup dabei nicht.
    Es werden nur die notwendigen Berechtigungen auf die Daten- und Protokollverzeichnisse, Registry  sowie Dienstberechtigungen erteilt.

    Bevor man daran etwas verändert, sollte man sich über die Konsequenzen klar sein, denn sehr schnell verhindert man ein korrektes Funktionieren.

    Den vollen Zugriff auf Daten-/Protokoll-/Backup-Verzeichnisse braucht der SQL Server Dienst
    damit er neue Datenbanken anlegen, verschieben und löschen kann.

    (Im übrigen brauchen Administratoren auf viele der Verzeichnisse keinen Zugriff -
    auch wenn sie oft meinen ihn haben zu müssen ;)

    Gruß Elmar

    Montag, 8. April 2013 09:54
    Beantworter
  • Wenn jetzt aber die meisten Admins die Rechte in den System Ordnern nicht ändern und das allgemein so gelassen wird, würde ich es auch lassen

    Hallo Jan,

    Ja, die meistem bis fast alle belassen die Berechtigungen, so wie sie bei der Installation vergeben werden. Ich hatte bisher jetzt nur bei SQL Server 2012 den Fall, das die Berechtigungen für den SSAS Service account auf den vom Standard abweichenden Log-Ordner nicht richtig eingerichtet wurden und deshalb die Flightrecorder Datei nicht angelegt wurde; hier hatte ich dann einmal manuell bei den Berechtigungen nachgeholfen, damit alles funktioniert.

    BTW, solltest Du mal nachträglich einen Service Account ändern wollen, dann auf keinen Fall über den normalen Windows Dienstmanager, sondern nur über den "SQL Server Configuration Manager", den nur der richtet dabei auch wieder die Berechtigungen aufs Filesystem, Registry etc ein.


    Olaf Helper

    Blog Xing

    Dienstag, 9. April 2013 06:20

Alle Antworten

  • Hallo Jan Alexander,

    ja, das muss sein - siehe  Einrichten von Windows-Dienstkonten

    "Großzügig" ist der SQL Server Setup dabei nicht.
    Es werden nur die notwendigen Berechtigungen auf die Daten- und Protokollverzeichnisse, Registry  sowie Dienstberechtigungen erteilt.

    Bevor man daran etwas verändert, sollte man sich über die Konsequenzen klar sein, denn sehr schnell verhindert man ein korrektes Funktionieren.

    Den vollen Zugriff auf Daten-/Protokoll-/Backup-Verzeichnisse braucht der SQL Server Dienst
    damit er neue Datenbanken anlegen, verschieben und löschen kann.

    (Im übrigen brauchen Administratoren auf viele der Verzeichnisse keinen Zugriff -
    auch wenn sie oft meinen ihn haben zu müssen ;)

    Gruß Elmar

    Montag, 8. April 2013 09:54
    Beantworter
  • Was die Datenordner angeht, fällt mir jetzt auf, dass Du recht hast. So wie ich es konfiguriert habe, könnten Dateien nicht gelöscht werden. Der Server kann Datenbanken aber anlegen, lesen und verändern bzw. schreiben. Das Gebot ist ja immer so wenig Rechte wie möglich, in meinem Fall scheint das zu reichen.

    Der Baseline Security Analyser kommt ja selbst von Microsoft. Warum sagt der, dass das mit dem Zugriff in den System Ordnern nicht gut ist, wenn es denn doch so sein soll? Wenn jetzt aber die meisten Admins die Rechte in den System Ordnern nicht ändern und das allgemein so gelassen wird, würde ich es auch lassen und damit glücklich sein - das wollte ich ja eben wissen, ob das nun tatsächlich ein Problem ist oder nicht.

    Montag, 8. April 2013 12:05
  • Wenn jetzt aber die meisten Admins die Rechte in den System Ordnern nicht ändern und das allgemein so gelassen wird, würde ich es auch lassen

    Hallo Jan,

    Ja, die meistem bis fast alle belassen die Berechtigungen, so wie sie bei der Installation vergeben werden. Ich hatte bisher jetzt nur bei SQL Server 2012 den Fall, das die Berechtigungen für den SSAS Service account auf den vom Standard abweichenden Log-Ordner nicht richtig eingerichtet wurden und deshalb die Flightrecorder Datei nicht angelegt wurde; hier hatte ich dann einmal manuell bei den Berechtigungen nachgeholfen, damit alles funktioniert.

    BTW, solltest Du mal nachträglich einen Service Account ändern wollen, dann auf keinen Fall über den normalen Windows Dienstmanager, sondern nur über den "SQL Server Configuration Manager", den nur der richtet dabei auch wieder die Berechtigungen aufs Filesystem, Registry etc ein.


    Olaf Helper

    Blog Xing

    Dienstag, 9. April 2013 06:20
  • Hallo Jan Alexander,

    der MBSA ist - unabhängig von der SQL Server Entwicklung -  entstanden als Microsoft die
    Sicherheitsproblematik ernst zu nehmen begann.
    Zu dem Zeitpunkt existierte u. a. SQL Server 2000, zu dessen Entwicklungszeit (vor 1999)
    man es nicht so genau genommen hatte - wie der SQL Slammer Wurm zeigte.

    Heute sind alle Microsoft-Produkte vom Betriebssystem bis hin zu den Anwendungsprogrammen
    wie dem SQL Server besser gesichert sind. Und der MBSA hat seine Bedeutung weitgehend verloren[1].

    Heute gibt es ausgenommen für "Alt-Bestände" keinen Grund den MBSA für den SQL Server zu verwenden.

    Für die aktuellen SQL Server Versionen werden die Rechte sehr detailliert gesetzt
    und durch das Konzept eines Sicherheitsgruppe abgesichert.
    Es dürfte nur wenige Fälle geben, wo man ein gehärteteres System benötigt.

    Da gilt aber auch, dass man von den Vorgaben des SQL Servers ausgehen sollte
    und gezielt Rechte entziehen bzw. zuweisen sollte.

    Die Beschreibungen des MBSA 2.2  - gerade mal angeschaut - sind teilweise irreführend
    und stammen zu guten Teilen inkl. der Verweise noch aus SQL Server 2000 Zeiten.

    Gruß Elmar

    [1] Für Windows 8 wird er nicht mehr weiter entwickelt, siehe Wikipedia

    Dienstag, 9. April 2013 07:05
    Beantworter
  • Alles klar, dann lass ich es so und mach mir keine Gedanken ;)

    Dienstag, 9. April 2013 16:41