Konfigurieren und Verwalten der Sicherheit von Azure SQL-Datenbank für die Geowiederherstellung oder den Failover

  • Artikel

Gilt für:Azure SQL-Datenbank

In diesem Artikel werden die Authentifizierungsanforderungen zum Konfigurieren und Steuern der aktiven Georeplikation und von Gruppen für automatisches Failover beschrieben. Außerdem werden die erforderlichen Schritte zum Einrichten des Benutzerzugriffs auf die sekundäre Datenbank festgelegt. Schließlich wird auch wird beschrieben, wie nach der Geowiederherstellung der Zugriff auf die wiederhergestellte Datenbank aktiviert wird. Weitere Informationen zu Wiederherstellungsoptionen finden Sie unter Übersicht über die Geschäftskontinuität.

Notfallwiederherstellung mit eigenständigen Benutzern

Im Gegensatz zu herkömmlichen Benutzer*innen, die Anmeldungen in der master-Datenbank zugeordnet werden müssen, werden eigenständige Benutzer*innen vollständig von der Datenbank selbst verwaltet. Dies hat zwei Vorteile. Beim Notfallwiederherstellungs-Szenario können sich die Benutzer weiter ohne zusätzliche Konfiguration mit der neuen primären Datenbank bzw. mit der Geowiederherstellung wiederhergestellten Datenbank verbinden, da die Datenbank die Benutzer verwaltet. Es gibt bei dieser Konfiguration auch vom Standpunkt der Anmeldung potenzielle Skalierbarkeits- und Leistungsvorteile. Weitere Informationen finden Sie unter Eigenständige Datenbankbenutzer – machen Sie Ihre Datenbank portabel.

Der Hauptaspekt des Kompromisses ist, dass die Verwaltung des Notfallwiederherstellungs-Prozesses im Verhältnis eine größere Herausforderung darstellt. Wenn mehrere Ihrer Datenbanken dieselben Anmeldedaten verwenden, kann sich die Verwaltung der Anmeldeinformationen anhand von eigenständigen Benutzern in mehreren Datenbanken nachteilig auswirken. Die Kennwortrotationsrichtlinie erfordert beispielsweise, dass Änderungen konsistent in mehreren Datenbanken durchgeführt werden, anstatt das Kennwort für die Anmeldung einmal in der master-Datenbank zu ändern. Wenn Sie mehrere Datenbanken mit dem gleichen Benutzernamen und Kennwort verwenden, sollten Sie darum keine eigenständigen Benutzer verwenden.

Konfigurieren von Anmeldungen und Benutzern

Wenn Sie mit Anmeldungen und Benutzer*innen (nicht mit eigenständigen Benutzer*innen) arbeiten, müssen Sie zusätzliche Schritte durchführen, um sicherzustellen, dass die gleichen Anmeldenamen in der master-Datenbank vorhanden sind. In den folgenden Abschnitten werden die entsprechenden Schritte und zusätzliche Aspekte behandelt.

Hinweis

Es ist auch möglich, über Microsoft Entra ID (früher Azure Active Directory) erstellte Anmeldungen zu verwenden, um Ihre Datenbanken zu verwalten. Weitere Informationen finden Sie unter Azure SQL-Anmeldungen und -Benutzer.

Einrichten des Benutzerzugriffs auf eine sekundäre bzw. wiederhergestellte Datenbank

Damit die sekundäre Datenbank als schreibgeschützte sekundäre Datenbank verwendet werden kann und um den ordnungsgemäßen Zugriff auf die neue primäre Datenbank bzw. mit der Geowiederherstellung wiederhergestellte Datenbank sicherzustellen, muss für die master-Datenbank des Zielservers vor der Wiederherstellung die geeignete Sicherheitskonfiguration durchgeführt werden.

Die spezifischen Berechtigungen für die einzelnen Schritte werden weiter unten in diesem Thema beschrieben.

Die Vorbereitung des Benutzerzugriffs auf eine mit Georeplikation erzeugte sekundäre Datenbank sollte im Rahmen der Konfiguration der Georeplikation erfolgen. Die Vorbereitung des Benutzerzugriffs auf mit der Geowiederherstellung wiederhergestellte Datenbanken sollte zu einem beliebigen Zeitpunkt erfolgen, wenn der ursprüngliche Server online ist (z.B. als Teil des DR-Drills).

Hinweis

Wenn Sie das Failover zu einem Server oder die Geowiederherstellung auf einem Server ausführen, für den die Anmeldenamen nicht ordnungsgemäß konfiguriert sind, beschränkt sich der Zugriff auf das Serveradministratorkonto.

Das Einrichten von Anmeldenamen auf dem Zielserver umfasst die unten beschriebenen drei Schritte:

1. Bestimmen der Anmeldungen mit Zugriff auf die primäre Datenbank

Der erste Schritt des Prozesses ist das Bestimmen, welche Anmeldungen auf dem Zielserver dupliziert werden müssen. Dies erfolgt mit zwei SELECT-Anweisungen, die auf die logische master-Datenbank auf dem Quellserver und auf die primäre Datenbank selbst angewandt werden.

Nur der Serveradministrator oder ein Mitglied der Serverrolle LoginManager kann mit der folgenden SELECT-Anweisung die Anmeldungen auf dem Quellserver bestimmen.

SELECT [name], [sid]
FROM [sys].[sql_logins]
WHERE [type_desc] = 'SQL_Login'

Nur ein Mitglied der Datenbankrolle „db_owner“, der Benutzer „dbo“ oder der Serveradministrator kann alle Datenbankbenutzerprinzipale in der primären Datenbank bestimmen.

SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'

2. Suchen der SID für die in Schritt 1 identifizierten Anmeldungen

Durch Vergleichen der Ausgabe der Abfragen aus dem vorherigen Abschnitt und Zuordnen der SIDs können Sie die Serveranmeldung dem Datenbankbenutzer zuordnen. Anmeldungen, die über einen Datenbankbenutzer mit einer entsprechenden SID verfügen, haben als Datenbankbenutzerprinzipal Benutzerzugriff auf diese Datenbank.

Die folgende Abfrage kann verwendet werden, um alle Benutzerprinzipale mit ihre SIDs in einer Datenbank anzuzeigen. Nur ein Mitglied der Datenbankrolle „db_owner“ oder Serveradministrator kann diese Abfrage ausführen.

SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'

Hinweis

Die Benutzer INFORMATION_SCHEMA und sys haben die SID NULL, und die SID von guest lautet 0x00. Die SID von dbo kann mit 0x01060000000001648000000000048454 beginnen, wenn der Datenbankersteller der Serveradministrator und kein Mitglied von DbManager war.

3. Erstellen der Anmeldenamen auf dem Zielserver

Der letzte Schritt besteht darin, auf dem oder den Zielservern die Anmeldungen mit den entsprechenden SIDs zu erstellen. Die grundlegende Syntax ist wie folgt.

CREATE LOGIN [<login name>]
WITH PASSWORD = '<login password>',
SID = 0x1234 /*replace 0x1234 with the desired login SID*/

Erstellen Sie auf dem Zielserver keine neue Anmeldung mit der Serveradministrator-SID aus der Quelle. Machen Sie stattdessen die Administratoranmeldung des Zielservers zu einem Datenbankprinzipal in der Datenbank, z. B. db_owner oder Benutzer.

Hinweis

Wenn Sie Benutzerzugriff auf die sekundäre Datenbank, aber nicht auf die primäre gewähren möchten, ändern Sie dazu die Benutzeranmeldung auf dem primären Server mithilfe der folgenden Syntax.

ALTER LOGIN [<login name>] DISABLE

DISABLE ändert nicht das Kennwort, sodass Sie sie bei Bedarf stets aktivieren können.

Nächste Schritte