Teilen über

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

  • Artikel

Gilt für: SQL Server Azure 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 betreffen den Authentifizierungsprozess USER WITH PASSWORD, durch den die Authentifizierungsgrenze von der Datenbank-Engine-Ebene auf die Datenbankebene verschoben wird.

Benutzer in einer eigenständigen Datenbank, die über die Berechtigung BELIEBIGEN BENUTZER ÄNDERN verfügen (z. B. Mitglieder der festen Datenbankrollen db_owner und db_acessadmin), können ohne Wissen und Erlaubnis des SQL Server-Administrators den Zugriff auf die Datenbank 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 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 eigenständigen Datenbank in regelmäßigen Abständen ü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 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 eigenständigen Datenbank mit Kennwort erstellt wird und dabei ein Name angegeben wird, der einer SQL Server-Anmeldung entspricht und mit der SQL Server-Anmeldung eine Verbindung unter Angabe der eigenständigen Datenbank als Anfangskatalog hergestellt wird, kann mit der SQL Server-Anmeldung keine Verbindung hergestellt werden. 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 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. Der Administrator kann nun mit der Anweisung USE<database> zur eigenständigen 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 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 eigenständige Datenbanken vorhanden sind, sollten Benutzer von Datenbanken, die keine eigenständigen Datenbanken darstellen, ohne Verwendung eines Anfangskatalogs oder unter Angabe des Namens einer abhängigen Datenbank als Anfangskatalog eine Verbindung mit dem Datenbank-Engine herstellen. 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 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 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 eigenständigen 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 unsichere Kennwörter zulässt, an ein System mit einer strengeren Kennwortrichtlinie können Administratoren Kennwörter für Datenbank-Engine zulassen, die 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 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 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.

Weitere Informationen

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