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 Authentifizierungsprozess VON USER WITH PASSWORD , wodurch die Authentifizierungsgrenze von der Datenbankmodulebene auf die Datenbankebene verschoben wird.

Benutzer in einer enthaltenen Datenbank, die über die BERECHTIGUNG ALTER ANY 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 sql Server-Administrator gewähren. Die Gewährung des Zugriffs auf eine enthaltene Datenbank erhöht den potenziellen Angriffsflächenbereich gegen die gesamte SQL Server-Instanz. Administratoren müssen diese Delegierung der Zugriffssteuerung verstehen, und sie sollten Benutzern die ALTER ANY USER -Berechtigung in der eigenständigen Datenbank nur mit großer Vorsicht gewähren. Alle Datenbankbesitzer verfügen über die ALTER ANY USER -Berechtigung. SQL Server-Administratoren sollten die Benutzer in einer enthaltenen Datenbank regelmäßig überwachen.

Zugreifen auf andere Datenbanken mit dem guest-Konto

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

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 enthaltener Datenbankbenutzer mit Kennwort erstellt wird, der denselben Namen wie eine SQL Server-Anmeldung verwendet, und wenn die SQL Server-Anmeldung eine Verbindung herstellt, die die enthaltene Datenbank als anfänglichen Katalog angibt, kann die SQL Server-Anmeldung keine Verbindung herstellen. Die Verbindung wird als der enthaltene Datenbankbenutzer mit Kennwortprinzipal in der enthaltenen Datenbank ausgewertet, anstatt als Benutzer basierend auf der SQL Server-Anmeldung. Dies kann zu einem absichtlichen oder versehentlichen Denial of Service für die SQL Server-Anmeldung führen.

  • Als Best Practice sollten Mitglieder der festen Serverrolle sysadmin erwägen, Verbindungen immer ohne die Option des Anfangskatalogs herzustellen. Dadurch wird die Anmeldung mit der master-Datenbank hergestellt, und Missbrauchsversuche des Anmeldeversuchs durch Datenbankbesitzer sind ausgeschlossen. Anschließend kann der Administrator mithilfe der USE-Datenbank-Anweisung<> in die enthaltene Datenbank wechseln. Sie können auch die Standarddatenbank der Anmeldung auf die eigenständige Datenbank festlegen. Dadurch wird die Anmeldung bei masterabgeschlossen, und die Anmeldung wird an die eigenständige Datenbank übertragen.

  • Als bewährte Methode erstellen Sie keine enthaltenen Datenbankbenutzer mit Kennwörtern, die denselben Namen wie SQL Server-Anmeldungen haben.

  • 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 enthaltene Datenbanken vorhanden sind, sollten Benutzer von Datenbanken, die keine Datenbanken enthalten, eine Verbindung mit dem Datenbankmodul herstellen, ohne einen anfänglichen Katalog zu verwenden, oder indem Sie den Datenbanknamen einer nicht enthaltenen Datenbank als ursprünglichen Katalog angeben. Dadurch wird keine Verbindung mit der enthaltenen Datenbank hergestellt, die von den Datenbankmoduladministratoren unter weniger direkter Kontrolle steht.

Ausweiten des Zugriffs durch Ändern des Kapselungsstatus einer Datenbank

Anmeldungen, die über die Berechtigung ALTER ANY DATABASE verfügen (z.B. Mitglieder der festen Serverrolle dbcreator ) und Benutzer in einer abhängigen Datenbank, die über die Berechtigung CONTROL DATABASE verfügen (z.B. Mitglieder der festen Datenbankrolle db_owner ), können die Kapselungseinstellung 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 könnte den Zugriff ohne Wissen oder Zustimmung der SQL Server-Administratoren ermöglichen. Um zu verhindern, dass Datenbanken enthalten sind, legen Sie die Datenbankauthentifizierungsoption auf 0 fest. 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 eigenständigen Datenbank

Durch das Anfügen einer enthaltenen Datenbank könnte ein Administrator unerwünschten Benutzern Zugriff auf die Instanz des Datenbankmoduls 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 über Anmeldungen autorisiert sind, können auf das Datenbankmodul 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 enthaltenen Datenbank, die schwache Kennwörter an ein System mit einer strengeren Kennwortrichtlinie erlaubte, könnte ein Administrator Kennwörter zulassen, die nicht der aktuellen Kennwortrichtlinie des anfügenden Datenbankmoduls 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 stets die Windows-Authentifizierung, die Vorteile der umfassenderen 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 Kennworthashs für Benutzer eigenständiger 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.

Versehen einer eigenständigen Datenbank mit Escapezeichen

Wenn eine Datenbank teilweise enthalten ist, sollten SQL Server-Administratoren die Funktionen der Benutzer und Module in enthaltenen 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.

Weitere Informationen

Eigenständige Datenbanken
Migrieren zu einer partiell eigenständigen Datenbank