none
SQL Server 2014 mit Dienstkonten sinnvoll installieren RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo an alle,

    ich möchte mich dem Thema SQL Server2014 SP1 widmen. Dazu brauche ich natürlich erst mal einen! An statt mit der Taktik "Weiter Weiter Fertigstellen" vorzugehen möchte ich einmal das Thema Sicherheit und Konfiguration über Servicekonten nachdenken. Dazu suche ich die Hilfe erfahrener SQL Server Haudegen.  ich würde gern (für die bessere Administration)folgenden Vorschlag unterbreiten.

    Servername: zb. SQL2k14Test

    Dienst:                                                        Servicekonto:

    SQL Server-Agent                                              srv-SQL2K14Test

    SQL Server-Datenbankmodul                               srv-SQL2K14Test

    SQL Server Analysis Services                               srv-SQL2K14Test-SSAS

    SQL Server Reporting Services                              srv-SQL2K14Test-SSRS

    SQL Server Integration Services 12.0                     srv-SQL2K14Test-SSIS

    SQL Server Distributed Replay Client                      srv-SQL2K14Test

    SQL Server Distributed Replay Controller                srv-SQL2K14Test

    Startprogramm für SQL-Volltextfilterdaemon           default

    SQL Server-Browser                                              default

    Macht diese Aufteilung Sinn? Sollte man zwischen SQL Server Agent und SQL Server-Datenbankmodul noch mal unterscheiden? Hintergrund ist wenn ein Konto gesperrt wird durch den SSIS SSAS oder SSRS Service soll der eigentlich SQL Server weiterlaufen.

    Aber vielleicht ergibt sich Sicherheitstechnisch noch ein ganz anderes Szenario?

    Bin für jede Kritik oder Hilfe dankbar.

    Montag, 8. Februar 2016 10:10
    |

Antworten

  • Question
    Anmelden
    3
    Anmelden

    Hallo

    das ist eine gute Frage. Schön, dass es Dir wichtig ist :)

    Das Prinzip hast Du erkannt: Kontentrennung (Hintergrund ist das Sicherheitsprinzip "Separation oder auch Segregation of Duties", welches wiederum eng mit dem Prinzip "Least Privilege" verbandelt ist.)

    Dadurch ergibt sich, dass ich Deinen Vorschlag gern wie folgt verbessern würde:

    • Trennung SQL Server und SQL Server Agent Konten
    • Distributed Replay Konten ebenso - sollte nicht das gleiche wie SQL Server+Agent sein

    Die Integration Services würde ich nicht bemängeln, wenn sie auf dem Standard (NT Service\MsDtsServer120) bleiben. Die Pakete werden ja nicht unter diesem Account ausgeführt.



    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Montag, 8. Februar 2016 10:53
    |

Alle Antworten

  • Question
    Anmelden
    3
    Anmelden

    Hallo

    das ist eine gute Frage. Schön, dass es Dir wichtig ist :)

    Das Prinzip hast Du erkannt: Kontentrennung (Hintergrund ist das Sicherheitsprinzip "Separation oder auch Segregation of Duties", welches wiederum eng mit dem Prinzip "Least Privilege" verbandelt ist.)

    Dadurch ergibt sich, dass ich Deinen Vorschlag gern wie folgt verbessern würde:

    • Trennung SQL Server und SQL Server Agent Konten
    • Distributed Replay Konten ebenso - sollte nicht das gleiche wie SQL Server+Agent sein

    Die Integration Services würde ich nicht bemängeln, wenn sie auf dem Standard (NT Service\MsDtsServer120) bleiben. Die Pakete werden ja nicht unter diesem Account ausgeführt.



    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Montag, 8. Februar 2016 10:53
    |
  • Question
    Anmelden
    0
    Anmelden

    also kurz zusammengefasst: alle wichtigen Funktionen mit einen separaten  Service-Konto ausstatten! Dein Ansatz ist halt noch etwas radikaler als meiner!

    Mich würde interessieren ob dies andere auch noch so sehen. Mal sehen vielleicht antwortet ja noch jemand.

    Aber danke erst mal an dich Andreas.

    Dienstag, 9. Februar 2016 14:05
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi,

    in meiner aktuellen Konfiguration verwende ich 3 versch. Konten:

    1. Agent

    2. Datenbankmodul

    3. SSRS, SSIS, SSAS

    Sicherheitstechnisch müsste man ausloten wieviel Rechte gerade so notwendig sind um den Dienst zu starten und um jeweilige Vorhaben auszuführen.

    Ansonsten gibts auch einen Artikel zum Thema "Sicherheitsüberegungen"

    https://msdn.microsoft.com/de-de/library/ms144228%28v=sql.120%29.aspx#isolated_services

    Gruß, Michael

    Beste Grüsse, M. Heitmann
    ** people may doubt what you say but they will always believe what you do **

    Dienstag, 9. Februar 2016 14:08
    |
  • Question
    Anmelden
    1
    Anmelden

    also kurz zusammengefasst: alle wichtigen Funktionen mit einen separaten  Service-Konto ausstatten! Dein Ansatz ist halt noch etwas radikaler als meiner!

    Mich würde interessieren ob dies andere auch noch so sehen. Mal sehen vielleicht antwortet ja noch jemand.

    Aber danke erst mal an dich Andreas.

    Naja. Es wäre schon schräg, wenn ausgerechnet ich etwas anderes als Konten- und Prozesstrennung empfehlen würde. ;-)

    Reporting Services benötigen direkten Zugriff auf SQL Server aufgrund ihrer Systemdatenbanken, die Analysis Services direkt jedoch (eigentlich auch) nicht.

    Alles andere sind Kompromisse, die man abwägen kann.

    Abgesehen von den unbestreitbaren Sicherheitsaspekten ist das übrigens auch beim Troubleshooting hilfreich.

    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Dienstag, 9. Februar 2016 14:30
    |
  • Question
    Anmelden
    0
    Anmelden
    das Troubleshooting ist genau der Grund warum ich das unbedingt umsetzen will. Die Sicherheit ist aber auch ein wichtiger Gedanke, da der Server auch von außen(Port80 Kommunikation) erreichbar sein soll.
    Dienstag, 9. Februar 2016 17:01
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo,

    gerade hier wäre die Trennung der Dienstkonten mir mich von Vorteil. Ich setzte für alle Dienstkonten die (gruppen)verwalteten Dienstkonten des Active Directory ein. https://technet.microsoft.com/library/ff641731(v=ws.10).aspx

    Jeder Dienst bekommt sein eigenes Konto und bei Mehr-Instanzsystem habe ich auch für die Server und Agent Dienste jeder Instanz eigene Konten.

    Man macht sich auch automatisch mehr Gedanken welcher Dienst welche Rechte braucht da man ja alle Rechte separat erstellt. Hier kann man sich ggf. damit behelfen die Rechte an Gruppen zu binden und die Dienstkonten als Mitglied aufnehmen. Nur bitte nicht alle Rechte an eine Gruppe sondern für jedes Recht eine separate Gruppe. Über diesen Weg sieht man umgekehrt sofort welche Rechte (über die Gruppenmitgliedschaft) ein Account/Dienstkonto hat. - Sicherheit bedeutet arbeit -

    Gruß Benjamin

    Benjamin Hoch
    MCSE: Data Platform,
    MCSA: Windows Server 2012

    Dienstag, 9. Februar 2016 20:56
    |
  • Question
    Anmelden
    0
    Anmelden

    erst einmal noch ein dickes Dankeschön an alle beteiligten für die Hilfe. Mein Konzept mit den Servicekonten steht erst einmal soweit. Nun soll es aber auch noch um die Rechte der einzelnen Servicekonten gehen.

    Ganz plump gefragt gibt es hier irgendwo einen Leitfaden oder best practice wie die Rechte der Servicekonten aussehen müssen?

    Aktuell ist der vor mir stehende Server mit Domainadmin Rechten ausgestattet. Welches ich als äußerst Fatal einstufe und unbedingt bei der Umstellung auf SQL Server 2014 ändern möchte.   

    Auch hier gilt für mich ich bin über jeden Ratschlag, Tipp oder Kritik sehr dankbar.

    Freitag, 12. Februar 2016 08:47
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Toot,

    ich gehe ihr einen eher praktischen Ansatz nach. Im Testsystem anfangen und erstmal alles an Rechten wegnehmen. Domain Admin ist das schlimmste was geht.

    Rechte geben für Sicherungsziele, Ordner und Laufwerke für Import/Export sowie Prozessrechte wie "Sperren von Seiten im Speicher" oder Durchführen von Volumenverwaltungsaufgaben" setzten sofern gewünscht. 

    Dann einfach das Testsystem laufen lassen und sehen wo es zu Fehlern kommt. Die Rechte anpassen und weiter im Test und die Dokumentation nicht vergessen.

    Wenn alles im Testsystem läuft dann die Dokumentation nehmen und auf das Produktivsystem übertragen.

    Gruß

    Benjamin Hoch
    MCSE: Data Platform,
    MCSA: Windows Server 2012,

    Freitag, 12. Februar 2016 08:58
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi,
    was verstehst Du unt "Server mit Domain-Admin-Rechten"?

    Keines der im Windows Server für den SQL Server genutzten Konten benötigt Domain-Admin-Rechte. Lediglich ein einfaches Domain-Konto ist für lokale administrative Aufgaben in die Gruppe der lokalen Administratoren einzuordnen. Dieses Konto kann dann für die Installation des SQL Servers und ggf. spätere Update-Arbeiten genutzt werden. Alle anderen vom SQL Server genutzten Konten benötigen keine Domain-Admin-Rechte.

    --
    Viele Grüsse
    Peter Fleischer (MVP, Partner)
    Meine Homepage mit Tipps und Tricks
    Kommas richtig setzen!
    Schüler sagen, Lehrer haben es gut.
    Schüler, sagen Lehrer, haben es gut

    Freitag, 12. Februar 2016 09:10
    |
  • Question
    Anmelden
    1
    Anmelden

    Hey Toot,

    schau mal unter diesem Link:

    Dienstberechtigungen MSSQL 2014

    Hinzufügen der Berechtigung "Starten als Dienst"

    ist einiges zu lesen, aber kurz und knapp probier es mal mit einem Standard-Konto, wenn das funktioniert oder auch nicht kann man immer noch Rechte entfernen bzw. hinzufügen. (Ähnlich Vorschlag Benjamim)

    Gruß, Michael


    Beste Grüsse,

    Michael Heitmann
    MCSE: Data Platform

    ** people may doubt what you say but they will always believe what you do **

    Sonntag, 14. Februar 2016 10:22
    |
  • Question
    Anmelden
    0
    Anmelden

    So ich kam nun wieder dazu mich in dem Thema etwas zu belesen.

    Eine Möglichkeit den SQL Server und den damit verbundenen Dienstkonten sicherer zu machen sind verwaltete Dienstkonten. Da der SQL Server sowieso in eine Server 2012 Domain läuft würde ich sogar auf die Technik Gruppenverwaltete Dienstkonten gehen.

    Ist dies Ratsam? Hat hier jemand schon einen Erfahrungswert?

    Donnerstag, 18. Februar 2016 07:22
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Toot,

    dies hatte ich weiter oben schon als Möglichkeit erwähnt. Die verwalteten Dienstkonten funktionieren sehr gut. Da ich persönlich die Konten trenne (jede Instanz ein eigenes Konto) braucht man die gruppenverwalteten Dienstkonten nicht. Technisch spricht aber nichts dagegen sie zu nutzen.

    Benjamin Hoch
    MCSE: Data Platform,
    MCSA: Windows Server 2012,

    Donnerstag, 18. Februar 2016 07:27
    |
  • Question
    Anmelden
    1
    Anmelden
    Group Managed Service Accounts haben halt den Charm der automatischen Passwortverwaltung, und steigern damit die Sicherheit meist.

    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Donnerstag, 18. Februar 2016 08:18
    |
  • Question
    Anmelden
    0
    Anmelden
    die einfachen Managed Service Accounts (ohne Group) natürlich auch.

    Benjamin Hoch
    MCSE: Data Platform,
    MCSA: Windows Server 2012,

    Donnerstag, 18. Februar 2016 08:21
    |
  • Question
    Anmelden
    1
    Anmelden

    Das stimmt

    eine kleine Übersicht, was dabei vor SQL2016 jeweils unterstützt ist, und was nicht, steht auch noch hier:

    https://social.msdn.microsoft.com/Forums/sqlserver/en-US/acb2048c-ffce-4d44-b882-6aafc7eb689d/managed-service-accounts-to-run-sql-server-service?forum=sqlsecurity

    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Donnerstag, 18. Februar 2016 08:34
    |
  • Question
    Anmelden
    0
    Anmelden

    und weiter geht's.

    auf dem Weg zum sicheren SQL Server habe ich mich mit den gMSA (Group managed Service account )Konten auseinander zu setzen. Jedoch stelle ich fest wenn ich das Konto weiß muss ich ja nirgends mehr das Passwort angeben. soll heißen wer das Konto kennt brauch sich um das Passwort nicht kümmern oder anders rum der jenige weiß es nicht. Somit kann ich manche Software von 3.Anbietern nicht unter gMSA laufen lassen da jene ja nicht installiert werden können, da bei der Installation ein Passwort angegeben werden soll.

    Damit bin ich doch wieder bei den alten Konten?! Oder verstehe ich etwas falsch?  

    Mittwoch, 2. März 2016 12:14
    |
  • Question
    Anmelden
    0
    Anmelden

    Grüße

    Bei dem gMSA musst du zuerst einmal die Server berechtigen welche das Konto überhaupt nutzen dürfen. Also das Konto auf irgend einem Server mal eben nutzen geht nicht. Dann kann das Konto nur für Dienste verwendet werden. Ein Login als Nutzer geht damit nicht. Aber ja der Admin kann das gMSA für beliebige Dienste auf dem berechtigten Server verwenden. Aber da du ja die Berechtigungen für das Dienstkonto so gering wie möglich halten sollst, könnte man damit nichts anderes anfangen wie es der Orginaldienst (SQL) darf. Für die Installation sind die Konten nicht vorgesehen.

    Gruß Benjamin

    Benjamin Hoch
    MCSE: Data Platform,
    MCSA: Windows Server 2012,

    Mittwoch, 2. März 2016 12:48
    |