Freigeben über

Konfigurieren von isoliertem Zugriff für benannte Hyperscale-Replikate

  • Artikel

Gilt für: Azure SQL-Datenbank

In diesem Artikel erfahren Sie, wie Sie Zugriff auf ein benanntes Hyperscale-Replikat in Azure SQL-Datenbank gewähren, ohne Zugriff auf das primäre Replikat oder auf andere benannte Replikate zu gewähren. Dieses Szenario ermöglicht die Ressourcen- und Sicherheitsisolation eines benannten Replikats, da zum Ausführen des benannten Replikats ein eigener Computeknoten verwendet wird. Dies ist immer dann hilfreich, wenn isolierter schreibgeschützter Zugriff auf eine Azure SQL Hyperscale-Datenbank erforderlich ist. Isoliert bedeutet in diesem Kontext, dass CPU und Arbeitsspeicher nicht gemeinsam vom primären und benannten Replikat genutzt werden. Bei Abfragen, die für das benannte Replikat ausgeführt werden, werden keine Computeressourcen des primären Replikats oder eines anderen Replikats beansprucht, und Prinzipale, die auf das benannte Replikat zugreifen, können nicht auf andere Replikate zugreifen (auch nicht auf das primäre).

Hinweis

Microsoft Entra ID war zuvor als Azure Active Directory (Azure AD) bekannt.

Erstellen einer Anmeldung auf dem primären Server

Führen Sie in der master-Datenbank auf dem logischen Server, der die primäre Datenbank hostet, Folgendes aus, um eine neue Anmeldung zu erstellen.

Verwenden Sie Ihr eigenes sicheres und eindeutiges Kennwort und ersetzen Sie strong_password_here durch Ihr sicheres Kennwort.

CREATE LOGIN [third-party-login] WITH PASSWORD = 'strong_password_here';

Rufen Sie den Hexadezimalwert der SID für die erstellte Anmeldung aus der Systemansicht sys.sql_logins ab:

SELECT SID FROM sys.sql_logins WHERE name = 'third-party-login';

Deaktivieren Sie die Anmeldung. Dadurch wird sichergestellt, dass mit dieser Anmeldung auf keine Datenbank auf dem Server zugegriffen werden kann, auf dem das primäre Replikat gehostet wird.

ALTER LOGIN [third-party-login] DISABLE;

Erstellen eines Benutzers in der primären Datenbank mit Lese-/Schreibzugriff

Stellen Sie nach Erstellung der Anmeldung eine Verbindung mit dem primären Lese-/Schreibreplikat Ihrer Datenbank her – beispielsweise mit „WideWorldImporters“. (Ein Beispielskript für die Wiederherstellung finden Sie unter Wiederherstellen einer Datenbank in Azure SQL.) Erstellen Sie anschließend einen Datenbankbenutzer für diese Anmeldung:

CREATE USER [third-party-user] FROM LOGIN [third-party-login];

Optional können Sie nach dem Erstellen des Datenbankbenutzers die im vorherigen Schritt erstellte Serveranmeldung löschen, um zu verhindern, dass der Anmeldename in irgendeiner Weise reaktiviert werden kann. Stellen Sie eine Verbindung mit der master-Datenbank auf dem logischen Server her, der die primäre Datenbank hostet, und führen Sie das folgende Beispielskript aus:

DROP LOGIN [third-party-login];

Erstellen eines benannten Replikats auf einem anderen logischen Server

Erstellen Sie einen neuen logischen Azure SQL-Server. Dieser wird verwendet, um den Zugriff auf das benannte Replikat zu isolieren. Gehen Sie dazu wie unter Erstellen und Verwalten von Servern und Einzeldatenbanken in Azure SQL-Datenbank beschrieben vor. Wenn Sie ein benanntes Replikat erstellen möchten, muss sich dieser Server in der gleichen Azure-Region befinden wie der Server, der das primäre Replikat hostet.

Ersetzen Sie im folgenden Beispiel strong_password_here durch Ihr sicheres Kennwort. Zum Beispiel, unter Verwendung der Azure CLI:

az sql server create -g MyResourceGroup -n MyNamedReplicaServer -l MyLocation --admin-user MyAdminUser --admin-password strong_password_here

Erstellen Sie anschließend ein benanntes Replikat für die primäre Datenbank auf diesem Server. Zum Beispiel, unter Verwendung der Azure CLI:

az sql db replica create -g MyResourceGroup -n WideWorldImporters -s MyPrimaryServer --secondary-type Named --partner-database WideWorldImporters_NR --partner-server MyNamedReplicaServer

Erstellen einer Anmeldung auf dem Server des benannten Replikats

Stellen Sie eine Verbindung mit der Datenbank master auf dem logischen Server her, der das benannte Replikat hostet, das im vorherigen Schritt erstellt wurde. Ersetzen Sie strong_password_here durch Ihr sicheres Kennwort. Fügen Sie die Anmeldung unter Verwendung der SID hinzu, die vom primären Replikat abgerufen wurde:

CREATE LOGIN [third-party-login] WITH PASSWORD = 'strong_password_here', sid = 0x0...1234;

An diesem Punkt können Benutzer und Anwendungen, die third-party-login oder bob@contoso.com verwenden, sich zwar eine Verbindung mit dem benannten Replikat herstellen, aber nicht mit dem primären Replikat.

Erteilen von Berechtigungen auf Objektebene innerhalb der Datenbank

Nachdem Sie die Anmeldeauthentifizierung wie beschrieben eingerichtet haben, können Sie zum Verwalten der Autorisierung reguläre Anweisungen vom Typ GRANT, DENY und REVOKE oder Berechtigungen auf Objektebene innerhalb der Datenbank verwenden. Verweisen Sie in diesen Anweisungen auf den Namen des Benutzers, den Sie in der Datenbank erstellt haben, oder auf eine Datenbankrolle, die diesen Benutzer als Mitglied enthält. Denken Sie daran, diese Befehle für das primäre Replikat auszuführen. Die Änderungen werden an alle sekundären Replikate weitergegeben. Sie sind jedoch nur für das benannte Replikat wirksam, in dem die Anmeldung auf Serverebene erstellt wurde.

Zur Erinnerung: Einem neu erstellten Benutzer werden standardmäßig nur minimale Berechtigungen erteilt. (Er kann beispielsweise nicht auf Benutzertabellen zugreifen.) Wenn Sie third-party-user oder bob@contoso.com das Lesen von Daten in einer Tabelle erlauben möchten, müssen Sie explizit die Berechtigung SELECT erteilen:

GRANT SELECT ON [Application].[Cities] to [third-party-user];

Anstatt Berechtigungen einzeln für jede Tabelle zu erteilen, können Sie den Benutzer auch der Datenbankrolle db_datareaders hinzufügen, um ihm Lesezugriff auf alle Tabellen zu gewähren. Eine weitere Möglichkeit ist die Verwendung von Schemas zum Zulassen des Zugriffs auf alle vorhandenen und neuen Tabellen in einem Schema.

Testen des Zugriffs

Sie können diese Konfiguration mit einem beliebigen Clienttool testen und versuchen, eine Verbindung mit dem primären und dem benannten Replikat herzustellen. Mit sqlcmd können Sie beispielsweise versuchen, unter Verwendung des Benutzers third-party-login eine Verbindung mit dem primären Replikat herzustellen. Ersetzen Sie strong_password_here durch Ihr sicheres Kennwort.

sqlcmd -S MyPrimaryServer.database.windows.net -U third-party-login -P strong_password_here -d WideWorldImporters

Dies führt zu einem Fehler, da der Benutzer keine Verbindung mit dem Server herstellen darf:

Sqlcmd: Error: Microsoft ODBC Driver 13 for SQL Server : Login failed for user 'third-party-login'. Reason: The account is disabled.

Die Verbindungsherstellung mit dem benannten Replikat ist erfolgreich. Ersetzen Sie strong_password_here durch Ihr sicheres Kennwort.

sqlcmd -S MyNamedReplicaServer.database.windows.net -U third-party-login -P strong_password_here -d WideWorldImporters_NR

Es werden keine Fehler zurückgegeben, und Abfragen können gemäß den erteilten Berechtigungen auf Objektebene für das benannte Replikat ausgeführt werden.

Zugehöriger Inhalt