Bewährte Methoden für die Sicherheit eigenständiger Datenbanken

Gilt für:SQL ServerAzure SQL Managed Instance

Eigenständige Datenbanken bergen einige eindeutige Risiken. Diese müssen von SQL Server-Datenbank-Engine -Administratoren erkannt und gemindert werden. Die meisten Bedrohungen beziehen sich auf den USER WITH PASSWORD-Authentifizierungsprozess, der die Authentifizierungsgrenze von der Datenbank-Engine Ebene auf die Datenbankebene verschiebt.

Benutzer in einer enthaltenen Datenbank, die über die ALTER ANY-Berechtigung USER verfügen, z. B. Mitglieder der db_owner und db_accessadmin festen Datenbankrollen, können zugriff auf die Datenbank ohne Wissen oder Berechtigung oder den SQL Server Administrator gewähren. Wenn Benutzern der Zugriff auf eine eigenständige Datenbank gewährt wird, vergrößert dies die potenzielle Angriffsfläche der gesamten SQL Server-Instanz. Administratoren sollten diese Delegierung der Zugriffskontrolle verstehen und sehr vorsichtig damit sein, Benutzern in der eigenständigen Datenbank die Berechtigung ALTER ANY USER zu gewähren. Alle Datenbankbesitzer verfügen über die Berechtigung ALTER ANY USER. SQL Server-Administratoren sollten die Benutzer in einer eigenständigen Datenbank in regelmäßigen Abständen überwachen.

Zugreifen auf andere Datenbanken mit dem guest-Konto

Datenbankbesitzer und Datenbankbenutzer mit der Berechtigung ALTER ANY USER können eigenständige Datenbankbenutzer erstellen. Nach dem Herstellen einer Verbindung mit einer eigenständigen Datenbank in einer Instanz von SQL Server kann ein Benutzer der eigenständigen Datenbank auf andere Datenbanken im Datenbank-Engine zugreifen, wenn für die anderen Datenbanken das guest-Konto aktiviert ist.

Erstellen eines doppelten Benutzers in einer anderen Datenbank

Bei einigen Anwendungen muss ein Benutzer u. U. in der Lage sein, auf mehr als eine Datenbank zuzugreifen. Dazu können identische eigenständige Datenbankbenutzer in jeder Datenbank erstellt werden. Verwenden Sie die SID-Option, wenn Sie den zweiten Benutzer mit einem Kennwort erstellen. Im folgenden Beispiel werden zwei identische Benutzer in zwei Datenbanken erstellt.

USE DB1;  
GO  
CREATE USER Carlo WITH PASSWORD = '<strong password>';   
-- Return the SID of the user  
SELECT SID FROM sys.database_principals WHERE name = 'Carlo';  
  
-- Change to the second database  
USE DB2;  
GO  
CREATE USER Carlo WITH PASSWORD = '<same password>', SID = <SID from DB1>;  
GO

Um eine datenbankübergreifende Abfrage auszuführen, müssen Sie die Option TRUSTWORTHY für die aufrufende Datenbank festlegen. Wenn sich der oben definierte Benutzer (Carlo) beispielsweise in DB1 befindet und SELECT * FROM db2.dbo.Table1; ausgeführt werden soll, muss die TRUSTWORTHY -Einstellung für die Datenbank DB1 aktiviert sein. Führen Sie den folgenden Code aus, um die TRUSTWORTHY -Einstellung zu aktivieren.

ALTER DATABASE DB1 SET TRUSTWORTHY ON;

Erstellen eines Benutzers, der eine Anmeldung dupliziert

Wenn ein Benutzer einer enthaltenen Datenbank mit Kennwort erstellt wird, der denselben Namen wie eine SQL Server-Anmeldung hat, und wenn die SQL Server-Anmeldung unter Angabe der enthaltenen Datenbank als Initialkatalog eine Verbindung herstellt, kann sich die SQL Server-Anmeldung nicht verbinden. Die Verbindung wird als Benutzer der eigenständigen Datenbank mit Kennwortprinzipal für die eigenständige Datenbank und nicht als Benutzer entsprechend der SQL Server-Anmeldung ausgewertet. Dies kann einen vorsätzlichen oder versehentlichen Denial of Service-Angriff für die SQL Server-Anmeldung verursachen.

  • Als bewährte Methode sollten Mitglieder der festen Serverrolle sysadmin in Betracht ziehen, stets ohne die Option „Initialkatalog“ eine Verbindung herzustellen. Dadurch wird die Anmeldung mit der Master-Datenbank verknüpft und verhindert, dass ein Datenbankbesitzer den Anmeldevorgang missbraucht. Der Administrator kann nun mit der Anweisung USE<database> zur eigenständigen Datenbank wechseln. Sie können auch die Standarddatenbank für die Anmeldung auf die enthaltene Datenbank festlegen, wodurch die Anmeldung bei master abgeschlossen und anschließend an die enthaltene Datenbank weitergeleitet wird.

  • Als Best Practice wird empfohlen, keine Benutzer von eigenständigen Datenbanken mit Kennwörtern zu erstellen, die denselben Namen wie SQL Server-Anmeldungen aufweisen.

  • Wenn die doppelte Anmeldung vorhanden ist, stellen Sie eine Verbindung mit der master -Datenbank her, ohne einen Anfangskatalog anzugeben, und führen Sie anschließend den USE -Befehl aus, um zur eigenständigen Datenbank zu wechseln.

  • Wenn teilweise eigenständige Datenbanken vorhanden sind, sollten Benutzer von Datenbanken, die keine teilweise eigenständigen Datenbanken sind, eine Verbindung mit dem Datenbankmodul herstellen, ohne einen Initialkatalog zu verwenden, oder den Datenbanknamen einer nicht teilweise eigenständigen Datenbank als Initialkatalog angeben. Dadurch wird vermieden, dass Verbindungen mit der eigenständigen Datenbank hergestellt werden, die von Datenbank-Engine-Administratoren weniger direkt kontrolliert wird.

Ausweiten des Zugriffs durch Ändern des Kapselungsstatus einer Datenbank

Anmeldungen, die über die ALTER ANY DATABASE-Berechtigung verfügen, z. B. Mitglieder der festen Serverrolle dbcreator, und Benutzer in einer nicht eigenständigen Datenbank, die über die CONTROL DATABASE-Berechtigung verfügen, z. B. Mitglieder der festen Datenbankrolle db_owner, können die Eigenständigkeitseinstellung einer Datenbank ändern. Wenn die Kapselungseinstellung einer Datenbank von NONE in PARTIAL oder FULLgeändert wird, kann Benutzerzugriff gewährt werden, indem Benutzer von eigenständigen Datenbanken mit Kennwörtern erstellt werden. Dies kann den Zugriff ohne Wissen oder Zustimmung der SQL Server-Administratoren ermöglichen. Legen Sie die Datenbank-Engine-Option contained database authentication auf 0 (null) fest, um zu verhindern, dass Datenbanken eigenständig sind. Um Verbindungen von Benutzern eigenständiger Datenbanken mit Kennwörtern für ausgewählte eigenständige Datenbanken zu verhindern, verwenden Sie Anmeldungstrigger, um Anmeldeversuche von Benutzern eigenständiger Datenbanken mit Kennwörtern abzubrechen.

Anfügen einer enthaltenen Datenbank

Durch Anfügen einer eigenständigen Datenbank können Administratoren auch unerwünschten Benutzern den Zugriff auf die Datenbank-Engine-Instanz gewähren. Administrator, die bezüglich dieses Risikos besorgt sind, können die Datenbank im RESTRICTED_USER -Modus online schalten, in dem die Authentifizierung für Benutzer eigenständiger Datenbanken mit Kennwörtern verhindert wird. Nur Prinzipale, die durch Anmeldungen autorisiert wurden, können auf Datenbank-Engine zugreifen.

Benutzer werden mit den zum Zeitpunkt ihrer Erstellung geltenden Kennwortanforderungen erstellt, und Kennwörter werden bei einer angefügten Datenbank nicht erneut überprüft. Durch das Anfügen einer eigenständigen Datenbank, die schwache Kennwörter zuließ, an ein System mit einer strengeren Kennwortrichtlinie konnte ein Administrator Kennwörter zulassen, die auf der anfügenden Datenbank-Engine nicht der aktuellen Kennwortrichtlinie entsprechen. Administratoren können vermeiden, dass die unsicheren Kennwörter beibehalten werden, indem sie festlegen, dass alle Kennwörter für die angefügte Datenbank zurückgesetzt werden.

Kennwortrichtlinien

Für Kennwörter in einer Datenbank ist u. U. vorgeschrieben, dass es sich um sichere Kennwörter handeln muss, sie müssen jedoch nicht durch strikte Kennwortrichtlinien geschützt sein. Verwenden Sie nach Möglichkeit die Windows-Authentifizierung, um die Vorteile der umfangreicheren Kennwortrichtlinien von Windows zu nutzen.

Kerberos-Authentifizierung

Benutzer eigenständiger Datenbanken mit Kennwörtern können die Kerberos-Authentifizierung nicht verwenden. Verwenden Sie nach Möglichkeit die Windows-Authentifizierung, um die Vorteile von Windows-Funktionen (z. B. Kerberos) zu nutzen.

Offlinewörterbuchangriff

Die Kennwort-Hashes für Benutzer in eigenständigen Datenbanken mit Kennwörtern werden in der eigenständigen Datenbank gespeichert. Jeder Benutzer mit Zugriff auf die Datenbankdateien kann einen Wörterbuchangriff auf die Benutzer eigenständiger Datenbanken mit Kennwörtern in einem nicht überwachten System ausführen. Um diese Bedrohung zu mindern, beschränken Sie den Zugriff auf die Datenbankdateien, oder lassen Sie Verbindungen mit eigenständigen Datenbanken nur mit Windows-Authentifizierung zu.

Einer eigenständigen Datenbank entkommen

Wenn eine Datenbank teilweise eigenständig ist, sollten SQL Server-Administratoren die Berechtigungen von Benutzern und Modulen in eigenständigen Datenbanken regelmäßig überwachen.

Denial-of-Service-Angriff durch AUTO_CLOSE

Konfigurieren Sie eigenständige Datenbanken nicht so, dass sie automatisch geschlossen werden. Wenn die Datenbank nach dem Schließen geöffnet wird, um einen Benutzer zu authentifizieren, werden zusätzliche Ressourcen belegt, und dies kann in einem Denial-of-Service-Angriff ausgenutzt werden.

Siehe auch

Enthaltene Datenbanken
Zu einer teilweise eigenständigen Datenbank migrieren

  • Last updated on