Share via

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

  • Artikel

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 eigenständigen Datenbank, die über die ALTER ANY USER Berechtigung verfügen, z. B. Mitglieder der db_owner und db_securityadmin festen Datenbankrollen, können zugriff auf die Datenbank ohne das Wissen oder die Berechtigung gewähren, wenn der SQL Server Administrator. 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 Serverkann ein Benutzer der eigenständigen Datenbank auf andere Datenbanken in Datenbank-Enginezugreifen, 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 TRUSTWORTHY-Option 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 TRUSTWORHTY-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. Anschließend kann der Administrator mithilfe der Datenbank-Anweisung> in die<USE 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 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 dann den USE Befehl aus, um in die enthaltene 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 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 db_owner festen Datenbankrolle, können die Eindämmungseinstellung einer Datenbank ändern. Wenn die Kapselungseinstellung einer Datenbank von NONE in PARTIAL oder FULL geä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. Um zu verhindern, dass Datenbanken enthalten sind, legen Sie die Option Datenbank-Enginecontained database authentication 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 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-Enginezugreifen.

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-Enginezulassen, 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