Konfigurieren der Sicherheit für SQL Server Protokollversand

  • Artikel

In diesem Artikel wird beschrieben, wie Sie die Sicherheit für SQL Server Protokollversand konfigurieren, und enthält Informationen zu dem Problem, das auftreten kann, wenn Sie die Sicherheit für SQL Server Protokollversand konfigurieren.

Ursprüngliche Produktversion: SQL Server
Ursprüngliche KB-Nummer: 321247

Zusammenfassung

Dieser Artikel enthält Informationen zum Konfigurieren der Sicherheit für den Protokollversand. Beim Konfigurieren der Sicherheit für SQL Server Protokollversand sind mehrere Probleme zu berücksichtigen, die vom Startkonto für SQL Server bis zur Freigabe von Berechtigungen für die Netzwerkfreigabe reichen, in der sich die Transaktionsprotokollsicherungen befinden. Diese Probleme werden in diesem Artikel beschrieben.

Domänenkonto

Wenn Sie SQL Server in einer Domäne platziert haben, empfiehlt Microsoft, dass Sie ein Domänenkonto verwenden, um SQL Server-Dienste zu starten. Sie sollten ein Domänenkonto verwenden, wenn Sie SQL Server für die Ausführung als virtueller Server unter Windows Clustering konfigurieren möchten. Ein Domänenkonto bietet den Vorteil einer minimalen Wartung bei Kennwortänderungen. Sie können SQL jedoch möglicherweise nicht unter einem Domänenkonto starten, wenn sich SQL Server auf einem Server befindet, der sich in einer Arbeitsgruppe befindet.

Lokales Netzwerkkonto

Sie können SQL Server verwenden, um unter einem lokal erstellten Netzwerkkonto zu beginnen. Wenn für einen SQL Server-Prozess Netzwerkzugriff erforderlich ist( wenn Sie SQL Server für die Verwendung des Protokollversands konfiguriert haben), können Sie die Netzwerk-Passthrough-Sicherheit verwenden. Bei passthrough-Sicherheit müssen alle Computer, auf die von SQL Server zugegriffen wird, über dasselbe Netzwerkkonto mit demselben Kennwort und den entsprechenden Berechtigungen verfügen, die lokal konfiguriert sind. Wenn die SQL Server Ressourcen vom zweiten Computer anfordert, wird außerdem die herkömmliche Netzwerksicherheit umgangen, wenn dasselbe Konto (unter dem der anfordernde SQL Server Dienst gestartet wird) mit demselben Kennwort vorhanden ist. Solange das Konto auf dem zweiten Computer mit ausreichend Berechtigungen für die Ausführung der Aufgabe konfiguriert ist, die durch den Aufruf von SQL Server angefordert wird, ist die Aufgabe erfolgreich.

Lokales Systemkonto

Sie können SQL Server auch so konfigurieren, dass sie unter dem Lokalen Systemkonto gestartet werden. Das Ändern des Kennworts für das LocalSystem-Konto kann zum Ausfall einiger Dienste führen, die für die Systemstabilität von entscheidender Bedeutung sind. Dieses Konto befindet sich lokal auf dem Computer, auf dem es sich befindet. Dies bedeutet, dass der Sicherheitskontext, den SQL Server Dienste verwendet, lokal ist. Wie im Abschnitt Lokales Netzwerkkonto angegeben, können Sie keine Netzwerkpassthroughsicherheit verwenden, wenn Sie SQL Server unter dem Konto LocalSystem starten, da die Kennwörter für das LocalSystem-Konto auf verschiedenen Computern unterschiedlich sind. Der Beginn von SQL Server unter diesem Konto, wenn der Zugriff auf Netzwerkressourcen erforderlich ist, führt höchstwahrscheinlich zum nicht erfolgreichen Abschluss von Aufgaben.

Informationen zu den minimal erforderlichen Rechten für ein Netzwerkkonto zum erfolgreichen Starten und Ausführen von SQL Server- und SQL Server-Agent-Diensten finden Sie unter Einrichten von Windows-Dienstkonten.

Grundlegendes zum SQL Server Sicherheitsmodell

Um die Auswirkungen auf die Sicherheit vollständig zu verstehen, ist es wichtig, das Sicherheitsmodell zu verstehen, das Microsoft in SQL Server 2000 implementiert hat. Wenn Sie einen Anmeldenamen erstellen, wird er der syslogins Tabelle in der MASTER-Datenbank hinzugefügt. Für jede Datenbank, auf die dieser neu hinzugefügte Anmeldename Zugriff erhält, wird sie der Tabelle in dieser sysusers Datenbank hinzugefügt. Die Zuordnung zwischen syslogins Tabelle und sysusers Tabelle erfolgt im SID-Feld.

Wenn eine Benutzerdatenbank auf einen anderen Server verschoben wird, werden die SID-Werte vom vorherigen Server übernommen. Entweder wird die Datenbanksicherheit unterbrochen, wenn Anmeldungen auf dem zweiten Server nicht mit den gleichen SID-Werten erstellt werden oder wenn die Sicherheit aufgrund nicht übereinstimmender SID-Werte nicht ordnungsgemäß konfiguriert ist.

Weitere Informationen finden Sie unter Beheben von Berechtigungsproblemen beim Verschieben einer Datenbank zwischen Servern, auf denen SQL Server ausgeführt wird.

Sicherheitsanforderungen

  • Sicherungsfreigabe

    Konfigurieren Sie die Netzwerkfreigabe, die für die Transaktionsprotokollsicherungen konfiguriert ist, mit Lese-/Änderungsberechtigungen für das Konto, unter dem SQL Server Dienste (auf dem sekundären Server, der für den Protokollversand konfiguriert ist) gestartet werden.

    Die Netzwerkfreigabe, die für die Sicherungen des Transaktionsprotokolls konfiguriert ist, sollte mit Lese-/Änderungsberechtigungen für das Konto konfiguriert werden, unter dem SQL Server Dienste auf dem sekundären Server, der für den Protokollversand konfiguriert ist, gestartet werden. Auf diese Freigabe wird vom Kopierauftrag auf dem sekundären Server zugegriffen, um die Transaktionsprotokollsicherungen in den lokalen Ordner auf dem jeweiligen sekundären Server zu kopieren. Der Load-Auftrag lädt diese Sicherungen dann aus dem lokalen Ordner.

  • Domänenübergreifender Protokollversand

    Wenn Computer, auf denen SQL Server ausgeführt werden, in einer Umgebung mit mehreren Domänen platziert werden, empfiehlt Microsoft, bidirektionale Vertrauensstellungen zwischen allen Domänen einzurichten, die am Protokollversand beteiligt sind. Wenn Sie jedoch keine Vertrauensstellungen zwischen Domänen einrichten können, können Sie die Netzwerk-Passthrough-Sicherheit für den Protokollversand verwenden. Lesen Sie den Abschnitt dieses Artikels, in dem die Startoption LocalSystem-Netzwerkkonto für SQL Server-bezogene Dienste erläutert wird.

  • Auswählen des Authentifizierungsmodus zum Herstellen einer Verbindung mit dem Überwachungsserver

    Sie können entweder Windows-Authentifizierung- oder SQL-Authentifizierung (nach primären und sekundären Servern) auswählen, um eine Verbindung mit dem Überwachungsserver herzustellen und die Überwachungstabellen zu aktualisieren. Sie können dies entweder beim Einrichten des Protokollversands oder nach dem Einrichten des Protokollversands auswählen, der funktionsfähig ist. Standardmäßig verwendet SQL Server Windows-Authentifizierung. Wenn Sie jedoch die SQL-Authentifizierung auswählen, wird auf dem primären, sekundären und Monitorserver ein neuer SQL-Anmeldenamen log_shipping_monitor_probe erstellt, falls kein server vorhanden ist. Wenn Sie zu diesem Zweck die SQL-Authentifizierung auswählen, konfigurieren Sie SQL Server so, dass die Option SQL und Windows-Authentifizierung verwendet wird.

Sicherheitskonfiguration auf dem sekundären Server für Standbydatenbanken

Wenn Sie die sekundäre Datenbank im Standbymodus konfigurieren, können Sie im schreibgeschützten Zustand auf diese Datenbank zugreifen. Durch das Wiederherstellen der sekundären Datenbank in diesem Modus kann dies eine Möglichkeit zum Ausführen von Offlineberichten bieten, wodurch ein Teil der Arbeit aus dem Produktionssystem ausgelagert wird. Damit die Standbydatenbank jedoch schreibgeschützte Funktionen unterstützt, müssen Sie möglicherweise dieselben Sicherheitseinstellungen auf den sekundären Server anwenden. Da sich die Datenbank im Standbyzustand befindet, können Sie zum Konfigurieren der Sicherheit keine Änderungen vornehmen. In diesem Fall müssen Sie alle SQL Server Anmeldungen mit den gleichen SID-Werten auf dem sekundären Server erstellen. Windows-Anmeldungen behalten automatisch dieselben SIDs bei, da die Windows-GUID global eindeutig ist, auch wenn mehrere Domänen verwendet werden.

Weitere Informationen zum Erstellen von SQL-Anmeldungen mit derselben SID auf verschiedenen Servern finden Sie unter Gewähren des Zugriffs auf SQL-Anmeldungen in einer Standbydatenbank, wenn der Gast in SQL Server deaktiviert ist.

Sicherheitskonfiguration beim Durchführen einer Rollenänderung

Das Rollenänderungsverfahren für den Protokollversand umfasst das Herstufen eines sekundären Servers, der als primärer Server übernommen wird. Sie können dies mit oder ohne den primären Server tun, der online ist. Im Rahmen der Rollenänderung werden bis zu vier gespeicherte Prozeduren ausgeführt. Eine dieser gespeicherten Prozeduren, sp_resolve_logins , hilft beim Korrigieren der SID-Werte für Anmeldungen, die sich in der Standbydatenbank befinden, kurz bevor sie für die Verwendung als primäre Datenbank verfügbar gemacht wird.

Im Rahmen dieser gespeicherten Prozedur wird eine .bcp Datei der syslogins Tabelle vom ehemaligen primären Server in eine temporäre Tabelle geladen. Jede Anmeldung, die in dieser temporären Tabelle vorhanden ist, wird dann mit der Tabelle in der syslogins MASTER-Datenbank des sekundären Servers und der sysusers Tabelle der sekundären Datenbank verglichen. Für jeden Anmeldenamen in der temporären Tabelle, der über einen Anmeldenamen in der syslogins Tabelle und dieselbe SID wie in der sysusers Tabelle der sekundären Datenbank verfügt, wird die SID (in der sekundären Datenbank) korrigiert, indem verwendet sp_change_users_login wird, um mit dem in der syslogins Tabelle aufgeführten zu übereinstimmen.

Für die Sicherheitskonfiguration mit dieser gespeicherten Prozedur ist Folgendes erforderlich:

  • SQL-Anmeldungen müssen bereits auf dem sekundären Server erstellt werden. Verwenden Sie dazu die DTS-Aufgabe "Anmeldungen übertragen", die in SQL Server Onlinedokumentation erläutert wird: Einrichten und Ausführen der Änderung der Protokollversandrollen.

  • Sie sollten eine .bcp Datei der syslogins Tabelle vom primären Server bereitstellen. Diese Datei muss aktuell sein, da eine veraltete Datei dazu führen sp_resolve_logins kann, dass die Anmeldungen nicht behoben werden können.

Sie sollten die folgenden drei Bedingungen erfüllen, bevor sp_resolve_logins die Anmeldungen in der sekundären Datenbank tatsächlich behoben werden können:

  1. Der Name der Anmeldung aus der .bcp Datei der syslogins Tabelle muss mit dem Namen in der syslogins Tabelle vom primären Server übereinstimmen.

  2. Der SID-Wert muss zwischen der Anmeldung der .bcp Datei und der sysusers Tabelle in der sekundären Datenbank übereinstimmen.

  3. Der SID-Wert der sekundären Datenbank muss sich von dem SID-Wert in der syslogins Tabelle in der MASTER-Datenbank auf dem sekundären Server unterscheiden.

Wenn Sie SQL Server Anmeldungen erstellen, wie in Q303722 beschrieben, muss diese gespeicherte Prozedur nicht ausgeführt werden, da alle Anmeldungen bereits mit demselben SID-Wert in der Tabelle (in der syslogins MASTER-Datenbank auf dem sekundären Server) und der sysusers Tabelle (in der sekundären Datenbank) angezeigt wurden.

Häufig gestellte Fragen

  • Frage: Gibt der Protokollversand sicherheitsbezogene Änderungen automatisch an einen sekundären Server weiter?

    Antwort: Ja. Da alle Änderungen an den Systemtabellen protokollierte Vorgänge sind, werden diese automatisch an den sekundären Server (oder die Server) weitergegeben.

  • Frage: Können Sie zwei Anmeldungen auf dem sekundären Server mit derselben SID haben? Ich benötige dies, da ich denselben SQL Server Computer verwende, um mehrere Standbydatenbanken von mehreren Servern zu verwalten.

    Antwort: Nein. SQL Server Sicherheitsmodell lässt nicht zu, dass zwei Anmeldungen mit derselben SID verwendet werden. Wenn bei der Verwendung des Protokollversands mit mehreren Servern ein Konflikt in der SID auftritt, besteht die einzige Möglichkeit zum Korrigieren darin, die in Konflikt stehende Anmeldung auf dem primären Server zu löschen und dann mit einer SID zu erstellen, die auf dem sekundären Server nicht vorhanden ist.