Teilen über

Machen Sie Ihre Datenbank portabel, indem Sie eigenständige Datenbanken verwenden

  • Artikel

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance Azure Synapse Analytics

Verwenden Sie eigenständige Datenbankbenutzer, um SQL Server und Azure SQL Database-Verbindungen auf Datenbankebene zu authentifizieren. Eine eigenständige Datenbank ist eine Datenbank, die von anderen Datenbanken und der SQL Server-Instanz oder SQL Database (und der master-Datenbank), die die Datenbank hostet, isoliert ist.

SQL Server unterstützt eigenständige Datenbankbenutzer sowohl für die Windows- als auch für die SQL Server-Authentifizierung. Kombinieren Sie bei Verwendung von SQL-Datenbank eigenständige Datenbankbenutzer mit den Firewallregeln auf Datenbankebene.

In diesem Artikel werden die Vorteile der Verwendung von einem eigenständigen Datenbankmodell im Vergleich zum herkömmlichen Anmelde-/Benutzermodell sowie zu Firewallregeln für Windows bzw. auf Serverebene vorgestellt. Bestimmte Szenarien, Verwaltbarkeit oder Anwendungsgeschäftslogik können dennoch den Einsatz des herkömmlichen Anmelde-/Benutzermodells und von Firewallregeln auf Serverebene erfordern.

Herkömmliches Anmelde- und Benutzermodell

Beim herkömmlichen Verbindungsmodell stellen Windows-Benutzer oder Mitglieder der Windows-Gruppen eine Verbindung mit der Datenbank-Engine durch die Bereitstellung von Benutzer- oder Gruppenanmeldeinformationen her, die von Windows authentifiziert werden. Oder die Benutzer können sowohl einen Namen als auch ein Kennwort bereitstellen und die Verbindung über die SQL Server-Authentifizierung herstellen. In beiden Fällen muss in der Masterdatenbank eine Anmeldung vorhanden sein, die den Anmeldeinformationen zur Verbindungsherstellung entspricht.

Nachdem die Datenbank-Engine die Anmeldeinformationen für die Windows-Authentifizierung bestätigt oder SQL Server-Anmeldeinformationen authentifiziert, versucht die Verbindung in der Regel eine Verbindung zu einer Benutzerdatenbank herzustellen. Zum Herstellen einer Verbindung mit einer Benutzerdatenbank muss die Anmeldung einem Datenbankbenutzer in der Datenbank zugeordnet werden. Die Verbindungszeichenfolge kann auch die Verbindung zu einer bestimmten Datenbank angeben, was bei SQL Server optional ist, bei SQL Database jedoch erforderlich.

Das wichtige Prinzip ist, dass sowohl die Anmeldung (in der master Datenbank) als auch der Benutzer (in der Benutzerdatenbank) vorhanden sein müssen und miteinander verknüpft werden können. Die Verbindung mit der Benutzerdatenbank hängt von der Anmeldung in der master Datenbank ab. Diese Abhängigkeit beschränkt die Möglichkeit der Datenbank, auf eine andere Host-SQL Server-Instanz oder Azure SQL-Datenbank Server verschoben zu werden.

Wenn eine Verbindung zur master-Datenbank nicht verfügbar ist (z. B. bei einem Failover), verlängert sich die Gesamtzeit der Verbindung, oder die Verbindung wird unter Umständen unterbrochen. Eine nicht verfügbare Verbindung kann die Skalierbarkeit der Verbindung beeinträchtigen.

Eigenständiges Datenbankbenutzermodell

Die Anmeldung in der master Datenbank ist im eigenständigen Datenbankbenutzermodell nicht vorhanden. Stattdessen erfolgt der Authentifizierungsprozess in der Benutzerdatenbank. Der Datenbankbenutzer in der Benutzerdatenbank verfügt nicht über eine zugeordnete Anmeldung in der master Datenbank.

Das eigenständige Datenbankbenutzermodell unterstützt sowohl die Windows-Authentifizierung als auch die SQL Server-Authentifizierung. Sie können sie sowohl in SQL Server als auch in SQL-Datenbank verwenden.

Um als eigenständiger Datenbankbenutzer eine Verbindung herzustellen, muss die Verbindungszeichenfolge immer einen Parameter für die Benutzerdatenbank enthalten. Die Datenbank-Engine verwendet diesen Parameter, um zu wissen, welche Datenbank für die Verwaltung des Authentifizierungsprozesses verantwortlich ist.

Die Aktivität des enthaltenen Datenbankbenutzers ist auf die Authentifizierungsdatenbank beschränkt. Das Datenbankbenutzerkonto muss in jeder Datenbank, die der Benutzer benötigt, unabhängig erstellt werden. Um die Datenbanken zu ändern, müssen SQL–Datenbank-Benutzer eine neue Verbindung erstellen. Eigenständige Datenbankbenutzer in SQL Server können Datenbanken ändern, wenn ein identischer Benutzer in einer anderen Datenbank vorhanden ist.

In Azure unterstützen SQL-Datenbank und Azure Synapse Analytics Identitäten von Microsoft Entra ID (früher Azure Active Directory) als enthaltene Datenbankbenutzer. SQL-Datenbank unterstützt enthaltene Datenbankbenutzer, die die SQL Server-Authentifizierung verwenden, aber Azure Synapse Analytics nicht. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit SQL-Datenbank unter Verwendung der Microsoft Entra-Authentifizierung.

Wenn Sie die Microsoft Entra-Authentifizierung verwenden, können Benutzer Verbindungen mit SQL Server Management Studio herstellen, indem Sie die universelle Microsoft Entra-Authentifizierung verwenden. Administratoren können die universelle Authentifizierung so konfigurieren, dass Multi-Factor Authentication verwendet wird, bei der die Identität mit einem Telefonanruf, einer SMS, einer Smartcard mit PIN oder einer Benachrichtigung über mobile App überprüft wird. Weitere Informationen finden Sie unter Verwenden der Multi-Faktor-Authentifizierung von Microsoft Entra.

Für SQL-Datenbank und Azure Synapse Analytics ist der Datenbankname immer in der Verbindungszeichenfolge erforderlich. Sie brauchen also die Verbindungszeichenfolge nicht zu ändern, wenn Sie vom traditionellen Modell zum eigenständigen Datenbankbenutzermodell wechseln. Für SQL Server-Verbindungen muss der Name der Datenbank zur Verbindungszeichenfolge hinzugefügt werden, falls nicht bereits geschehen.

Wichtig

Wenn Sie das traditionelle Modell verwenden, können die Rollen und Berechtigungen auf Serverebene den Zugriff auf alle Datenbanken einschränken. Wenn Sie das eigenständige Datenbankmodell verwenden, können Datenbankbesitzer und Datenbankbenutzer mit der ALTER ANY USER-Berechtigung Zugriff auf die Datenbank erteilen. Diese Berechtigung reduziert die Zugriffskontrolle von hochprivilegierten Serveranmeldungen und erweitert die Zugriffskontrolle auf hochprivilegierte Datenbankbenutzer.

Firewalls

SQL Server

Für SQL Server gelten die Windows-Firewall-Regeln für alle Verbindungen und haben die gleichen Auswirkungen auf Anmeldungen (Verbindungen nach dem traditionellen Modell) und eigenständige Datenbankbenutzer. Weitere Informationen zur Windows-Firewall finden Sie unter Konfigurieren einer Windows-Firewall für Datenbank-Engine-Zugriff.

SQL-Datenbank-Firewalls

SQL-Datenbank ermöglicht separate Firewallregeln für Verbindungen auf Serverebene (Anmeldenamen) und für Verbindungen auf Datenbankebene (eigenständige Datenbankbenutzer). Wenn die SQL-Datenbank eine Verbindung zu einer Benutzerdatenbank herstellt, prüft sie zunächst die Datenbank-Firewall-Regeln. Wenn es keine Regel gibt, die den Zugriff auf die Datenbank erlaubt, überprüft die SQL-Datenbank die Firewall-Regeln auf Serverebene. Das Überprüfen von Firewallregeln auf Serverebene erfordert Zugriff auf die Datenbank des master SQL-Datenbank Servers.

Firewall-Regeln auf Datenbankebene, kombiniert mit eingeschränkten Datenbankbenutzern, können den Zugriff auf die master Datenbank des Servers während der Verbindung überflüssig machen. Das Ergebnis ist eine verbesserte Verbindungsskalierbarkeit.

Weitere Informationen zu SQL-Datenbank-Firewall-Regeln finden Sie unter den folgenden Themen:

Syntaxunterschiede

Herkömmliches Modell Eigenständiges Datenbankbenutzermodell
Bei Verbindung mit der master Datenbank:

CREATE LOGIN login_name WITH PASSWORD = 'strong_password';

Und bei anschließender Verbindung mit einer Benutzerdatenbank:

CREATE USER 'user_name' FOR LOGIN 'login_name';		 Bei Verbindung mit einer Benutzerdatenbank:

CREATE USER user_name WITH PASSWORD = 'strong_password';
Herkömmliches Modell Eigenständiges Datenbankbenutzermodell
So ändern Sie ein Kennwort im Kontext der master Datenbank:

ALTER LOGIN login_name WITH PASSWORD = 'strong_password';		 So ändern Sie ein Kennwort im Kontext der Benutzerdatenbank:

ALTER USER user_name WITH PASSWORD = 'strong_password';

SQL Managed Instance

Azure SQL Managed Instance verhält sich im Kontext von eigenständigen Datenbanken wie lokale SQL Server-Instanzen. Stellen Sie sicher, dass Sie den Kontext Ihrer Datenbank von dem der Masterdatenbank in den der Benutzerdatenbank ändern, wenn Sie Ihren eigenständigen Benutzer erstellen. Außerdem sollten keine aktiven Verbindungen mit der Benutzerdatenbank bestehen, wenn Sie die Eigenständigkeit festlegen. Orientieren Sie sich am folgenden Code.

Warnung

Das folgende Beispielskript verwendet eine kill Anweisung, um alle Benutzerprozesse in der Datenbank zu schließen. Stellen Sie sicher, dass Sie die Folgen dieses Skripts verstehen und dass es ihrem Unternehmen entspricht, bevor Sie es ausführen. Stellen Sie außerdem sicher, dass keine anderen Verbindungen in Ihrer SQL-verwalteten Instanz-Datenbank aktiv sind, da das Skript andere Prozesse stört, die in der Datenbank ausgeführt werden.

USE master;

SELECT * FROM sys.dm_exec_sessions
WHERE database_id  = db_id('Test')

DECLARE @kill_string varchar(8000) = '';
SELECT @kill_string = @kill_string + 'KILL ' + str(session_id) + '; '  
FROM sys.dm_exec_sessions
WHERE database_id  = db_id('Test') and is_user_process = 1;

EXEC(@kill_string);
GO

sp_configure 'contained database authentication', 1;  
GO
 
RECONFIGURE;  
GO 

SELECT * FROM sys.dm_exec_sessions
WHERE database_id  = db_id('Test')

ALTER DATABASE Test
SET containment=partial

USE Test;  
GO 

CREATE USER Carlo  
WITH PASSWORD='Enterpwdhere*'  

SELECT containment_desc FROM sys.databases
WHERE name='Test'

Hinweise

  • Eigenständige Datenbankbenutzer müssen für jede Instanz von SQL Server aktiviert werden. Weitere Informationen finden Sie unter Serverkonfigurationsoption für die Authentifizierung der eigenständigen Datenbank.
  • Eigenständige Datenbankbenutzer und Anmeldungen mit nicht überlappenden Namen können in Ihren Anwendungen gemeinsam vorliegen.
  • Gehen Sie davon aus, dass eine Anmeldung in der master Datenbank den Namen 1 aufweist. Wenn Sie einen eigenständigen Datenbankbenutzer namens name1 erstellen und ein Datenbankname in der Verbindungszeichenfolge angegeben wird, wird der Kontext des Datenbankbenutzers für die Datenbankverbindung über den Anmeldekontext gewählt. D. h. eigenständige Datenbankbenutzer haben Vorrang vor Anmeldungen mit demselben Namen.
  • Der Name des eigenständigen Datenbankbenutzers darf in der SQL-Datenbank nicht mit dem Namen des Serveradmin-Kontos identisch sein.
  • Das SQL-Datenbank-Server-Administratorkonto darf nie ein eigenständiger Datenbankbenutzer sein. Der Serveradministrator verfügt über ausreichende Berechtigungen zum Erstellen und Verwalten von eigenständigen Datenbankbenutzern. Der Serveradministrator kann eigenständigen Datenbankbenutzern Berechtigungen für die Benutzerdatenbanken erteilen.
  • Da enthaltene Datenbankbenutzer Prinzipale auf Datenbankebene sind, müssen Sie eigenständige Datenbankbenutzer in jeder Datenbank erstellen, die Sie verwenden möchten. Die Identität ist auf die Datenbank beschränkt. Die Identität ist (in allen Aspekten) unabhängig von einem Benutzer, der den gleichen Namen und das gleiche Passwort in einer anderen Datenbank auf demselben Server hat.
  • Verwenden Sie Kennwörter derselben Stärke, wie Sie sie normalerweise für Anmeldenamen verwenden.

Zugehöriger Inhalt