Eigenständige Datenbankbenutzer - machen Sie Ihre Datenbank portabel

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 instance von SQL Server/SQL-Datenbank (und der master-Datenbank) 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. Oder die Verbindung stellt einen Namen und ein Kennwort bereit und stellt eine Verbindung mithilfe SQL Server Authentifizierung her (dies ist die einzige Option beim Herstellen einer Verbindung mit SQL-Datenbank). 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. Zum Herstellen einer Verbindung mit einer Benutzerdatenbank muss die Anmeldung einem Datenbankbenutzer in der Datenbank zugeordnet werden können. 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 Benutzermodell der eigenständigen Datenbank unterstützt sowohl Windows-Authentifizierung (in SQL Server) als auch SQL Server Authentifizierung (sowohl in SQL Server als auch SQL-Datenbank). 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.

Für SQL-Datenbank sind keine Änderungen an der Verbindungszeichenfolge erforderlich, wenn Sie vom herkömmlichen 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. 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 es keine Regel gibt, die den Zugriff auf die Datenbank ermöglicht, werden die Firewallregeln auf Serverebene geprüft, sodass der Zugriff auf eine logischer Server-Masterdatenbank erforderlich ist. 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';

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)