SQL Server-Anmeldekonfiguration und -automatisierung

Question

Wie können Sie SQL Server-Logins, Serverrollen und individuelle Zugriffsrechte für mehrere Datenbanken in mehreren Umgebungen verwalten und verwalten? Was sind deine besten Praktiken?

Einige Informationen über meine Situation:

• SQL Server 2005
• Wir haben N-Menge von "Client" Datenbanken mit identischem Schema (theoretisch zumindest)
• Wir haben einen zentralen „admin "Datenbank, die auf jede Client-Datenbank verweist und Konfigurationswerte enthalten kann
• Dieses" admin/client "-Muster ist über mehrere Umgebungen hinweg dupliziert (dev/qa/stage/prod)
• Einige Benutzer, wie Tester, ne ed anders auf evironment basierend Rechte
• Wir müssen häufig Client db Backups von einer Umgebung ziehen auf einen anderen für die Entwicklung oder Testzwecke
• Wir halten unsere gespeicherten Prozeduren und Skripte in der Quellcodeverwaltung und Bereitstellung in einem Build-Zyklus wiederherzustellen

Im Moment ist meine Organisation chaotisch und wir folgen keinen guten Sicherheitsvorkehrungen. Wir haben keinen formellen DBA. Wenn wir jedoch etwas komplexer werden, wäre es ein ständiger Aufwand, es ständig aufrechtzuerhalten. Ich könnte sehen, dass die Migration auf einen neuen Server oder die Wiederherstellung nach einer Katastrophe sehr zeitaufwendig ist, wenn wir versuchen, sie direkt über die Management Studio-IDE zu konfigurieren.

Answer 1

Um die Wiederherstellung einer Datenbank auf einem anderen Server zu vereinfachen, stellen Sie sicher, dass alle Logins dieselbe SID auf allen Servern haben. Verwenden Sie dazu die sp_help_revlogin stored procedure von Microsoft, um die Anmeldung auf dem ersten Server zu scripten und dann verwenden Sie das Skript, um die Anmeldung auf Ihren anderen Servern zu erstellen. Dadurch wird der Datenbankbenutzer bei der Wiederherstellung der Datenbank korrekt der Anmeldung zugeordnet.

Je nach Umgebung unterschiedliche Berechtigungen auf Datenbankebene zu haben, wird ein Problem sein, egal wie Sie das ausführen. Ich habe eine gespeicherte Prozedur im Master, die auf meinem Dev-Server als Teil meines Wiederherstellungsprozesses aufgerufen wird, der die zusätzlichen GRANTs auf der Datenbank ausführt, um den Entwicklern Zugriff auf Änderungen zu geben. Das ist das Beste, was ich mir vorstellen konnte, um ähnliche Probleme zu lösen.

Answer 2

Eine Möglichkeit, die Rechte zu erleichtern, wäre, Rollen in der Datenbank mit den Namen Dev, QA, Test, Prod zu erstellen und die korrekten Rechte für diese Rollen zu gewähren. Wenn Sie die Datenbanken in den einzelnen Umgebungen wiederherstellen, löschen Sie die Entwickler einfach in der richtigen Rolle.

Answer 3

Wir verwenden Active Directory-Gruppen und erzwingen Windows authentifizierte Logins. Innerhalb von SQL Server können wir dann den Zugriff basierend auf der AD-Gruppe definieren, in der sich der Benutzer befindet, indem Sie eine einzelne SQL Server-Anmeldung pro AD-Gruppe erstellen. Nicht sicher, ob dies besser oder schlechter als DB-Rollen ist, aber es bedeutet, dass die Rollen außerhalb jeder Datenbank verwaltet werden.

Die Weitergabe des Zugriffs auf Datenbanken ist dann entweder eine manuelle Operation oder ein kurzes SQL-Skript, um sicherzustellen, dass die Logins in der Datenbank auf eine gültige SQL Server-Anmeldung verweisen (die wiederum eine AD-Gruppe ist).

Im Allgemeinen funktioniert das gut für den allgemeinen Fall. Wir können dann DB-Rollen verwenden, um den einzelnen AD-Gruppen die eingebauten Rollen (z. B. db_datareader) zuzuweisen

Selten benötigt jemand einen bestimmten Zugriff auf eine Datenbank außerhalb dieses Modells.Wir werden es entweder für die gesamte Gruppe öffnen, wenn es nicht invasiv oder kritisch ist, oder wir erstellen ein Benutzerkonto, das separat verwaltet werden muss. Wir bemühen uns, diese auf ein absolutes Minimum zu beschränken und sie von Zeit zu Zeit aufzuräumen, damit sie nicht missbraucht/vergessen werden.