Eigenständige Datenbankbenutzer - machen Sie Ihre Datenbank portabel

Gilt für: SQL Server (alle unterstützten Versionen) Azure SQL-Datenbank Azure SQL Managed Instance Azure Synapse Analytics

Verwenden Sie eigenständige Datenbankbenutzer, um SQL Server - und SQL-Datenbank -Verbindungen auf Datenbankebene zu authentifizieren. Eine eigenständige Datenbank ist eine Datenbank, die von anderen Datenbanken und von der Instanz von SQL Server/SQL-Datenbank (und der Masterdatenbank) isoliert ist, die die Datenbank hostet. 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-Datenbankeigenständige Datenbankbenutzer mit den Firewallregeln auf Datenbankebene. In diesem Thema werden die Unterschiede und 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.

Hinweis

Bei der Entwicklung des Microsoft -Diensts durch SQL-Datenbank und dem Wechsel zu stärker garantierten SLAs, müssen Sie möglicherweise zum eigenständigen Datenbankbenutzermodell und den datenbankbezogenen Firewallregeln wechseln, um die SLA für höhere Verfügbarkeit sowie höhere maximale Anmelderaten für eine bestimmte Datenbank zu erreichen. Microsoft ermutigt Sie, solche Änderungen noch heute zu berücksichtigen.

Herkömmliches Anmelde- und Benutzermodell

Beim herkömmlichen Verbindungsmodell stellen Windows-Benutzer oder Mitglieder der Windows-Gruppen eine Verbindung mit dem Datenbank-Engine durch die Bereitstellung von Benutzer- oder Gruppenanmeldeinformationen her, die von Windows authentifiziert werden. Sie können auch 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 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. Um eine Verbindung mit einer Benutzerdatenbank herzustellen, muss die Anmeldung einem Datenbankbenutzer in der Benutzerdatenbank zugeordnet (d. h. zugeordnet sein). Die Verbindungszeichenfolge kann auch angeben, dass eine Verbindung mit einer bestimmten Datenbank hergestellt werden soll, was in SQL Server optional und in SQL-Datenbankerforderlich ist.

Das wichtige Prinzip ist, dass sowohl die Anmeldung (in der Masterdatenbank) als auch der Benutzer (in der Benutzerdatenbank) vorhanden sein müssen und miteinander verknüpft werden können. Dies bedeutet, dass die Verbindung mit der Benutzerdatenbank eine Abhängigkeit von der Anmeldung in der Masterdatenbank hat und dies die Möglichkeiten zum Verschieben der Datenbank auf einen anderen SQL Server - oder Azure SQL-Datenbank -Hostingserver einschränkt. Wenn aus irgendeinem Grund eine Verbindung mit der Masterdatenbank nicht verfügbar ist (z. B. wenn ein Failover läuft), wird die Gesamtdauer der Verbindung erhöht oder es tritt ggf. ein Timeout auf. Dies kann folglich die Verbindungsskalierbarkeit beeinträchtigen.

Eigenständiges Datenbankbenutzermodell

Die Anmeldung in der Masterdatenbank ist im eigenständigen Datenbankbenutzermodell nicht vorhanden. Stattdessen findet der Authentifizierungsprozess in der Benutzerdatenbank statt, und in der Masterdatenbank ist keine zugeordnete Anmeldung für den Datenbankbenutzer in der Benutzerdatenbank vorhanden. Das eigenständige Datenbankbenutzermodell unterstützt sowohl die Windows-Authentifizierung als auch die SQL Server -Authentifizierung und kann sowohl in SQL Server als auch in SQL-Datenbankverwendet werden. Um als eigenständiger Datenbankbenutzer eine Verbindung herzustellen, muss die Verbindungszeichenfolge immer einen Parameter für die Benutzerdatenbank enthalten, damit das Datenbank-Engine weiß, welche Datenbank für die Verwaltung des Authentifizierungsprozesses verantwortlich ist. Die Aktivität des eigenständigen Datenbankbenutzers ist auf den Authentifizierungsserver beschränkt. Beim Herstellen einer Verbindung als eigenständiger Datenbankbenutzer muss das Datenbankbenutzerkonto also unabhängig in jeder Datenbank erstellt werden, die der Benutzer benötigt. 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.

Azure: SQL-Datenbank und Azure Synapse Analytics unterstützen Azure Active Directory-Identitäten als Benutzer einer eigenständigen Datenbank. SQL-Datenbank unterstützt Benutzer einer eigenständigen Datenbank mit SQL Server aber Azure Synapse Analytics dies nicht. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit SQL-Datenbank unter Verwendung der Azure Active Directory-Authentifizierung. Wird Azure Active Directory-Authentifizierung verwendet, können Verbindungen von SSMS über die universelle Active Directory-Authentifizierung hergestellt werden. 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 SSMS-Unterstützung für Azure AD MFA mit SQL-Datenbank und Azure Synapse Analytics.

Für SQL-Datenbank und Azure Synapse Analyticssind, weil der Datenbankname in der Verbindungszeichenfolge immer erforderlich ist, beim Wechseln vom traditionellen Modell auf das eigenständige Datenbankbenutzermodell keine Änderungen an der Verbindungszeichenfolge erforderlich. 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. Die Zugriffssteuerung für hoch privilegierten Serveranmeldungen reduziert und erweitert die Zugriffssteuerung, um hoch privilegierten Datenbankbenutzer zu enthalten.

Firewalls

SQL Server

Windows-Firewall-Regeln gelten 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). Bei der Verbindung mit einer Benutzerdatenbank werden zuerst die Datenbank-Firewallregeln überprüft. Wenn keine Regel vorhanden ist, die den Zugriff auf die Datenbank zulässt, werden die Firewallregeln auf Serverebene überprüft, was Zugriff auf die SQL-Datenbank Serverhauptdatenbank erfordert. Firewallregeln auf Datenbankebene können zusammen mit eigenständigen Datenbankbenutzern die Notwendigkeit beseitigen, während der Verbindung auf die Masterdatenbank des Servers zuzugreifen, was eine verbesserte Verbindungsskalierbarkeit bietet.

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

Syntaxunterschiede

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

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 das Kennwort im Kontext der Masterdatenbank:

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

ALTER USER user_name WITH PASSWORD = 'strong_password';

SQL-Datenbank-Instanz

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.

Beispiel:

Warnung

Bevor Sie das folgende Skript ausführen, sollten Sie dafür sorgen, dass keine anderen aktiven Verbindungen in der Datenbank Ihrer verwalteten Instanz vorhanden sind. Das Skript unterbricht möglicherweise andere Prozesse, die in der Datenbank ausgeführt werden.

Use MASTER;
GO 

ALTER DATABASE Test
SET RESTRICTED_USER
WITH ROLLBACK IMMEDIATE;

ALTER DATABASE Test
SET containment=partial;

ALTER DATABASE Test
SET MULTI_USER;

USE Test;  
GO 

CREATE USER Carlo  
WITH PASSWORD='Enterpwdhere*'  

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

Bemerkungen

  • In SQL Servermüssen eigenständige Datenbankbenutzer für die Instanz von SQL Serveraktiviert 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.
  • Wenn es in der Masterdatenbank eine Anmeldung unter dem Namen name1 gibt und Sie einen eigenständigen Datenbankbenutzer namens name1erstellen und ein Datenbankname in der Verbindungszeichenfolge angegeben wird, wird der Kontext des Datenbankbenutzers bei der 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 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 und ist in allen Aspekten von einem Benutzer mit demselben Namen und demselben Kennwort in einer anderen Datenbank auf demselben Server unabhängig.
  • Verwenden Sie Kennwörter derselben Stärke, wie Sie sie normalerweise für Anmeldenamen verwenden.

Weitere Informationen

Eigenständige Datenbanken
Bewährte Methoden für die Sicherheit eigenständiger Datenbanken
CREATE USER (Transact-SQL)
Herstellen einer Verbindung mit SQL-Datenbank unter Verwendung der Azure Active Directory-Authentifizierung