Anhand dieser Checkliste können Sie überprüfen, wie der Zugriff auf Daten in Ihrer Organisation beschränkt wird. Verwenden Sie die Checkliste, um regelmäßig zu überprüfen, wie Benutzer auf im SQL Server Database Engine (Datenbankmodul) gespeicherte Informationen zugreifen.
Zugriff auf die Instanz von SQL Server
Diese Elemente beziehen sich auf die gesamte Instanz des Database Engine (Datenbankmodul).
.gif "Boolesches Feld (Symbol)") |
- Haben Sie dem Großteil der Anmeldenamen den Zugriff über Windows-Gruppen erteilt?
Tipp: Das Konfigurieren des Zugriffs auf das Database Engine (Datenbankmodul) mit Windows-Gruppen vereinfacht die Verwaltung und Wartung des Zugriffs. Weitere Informationen zu Anmeldenamen finden Sie unter Prinzipale (Datenbankmodul).
|
|
- Wurden unnötige oder veraltete Anmeldenamen aus dem Database Engine (Datenbankmodul) entfernt?
Tipp: Hierfür müssen ggf. regelmäßig manuelle Überprüfungen durchgeführt werden. Dies kann erleichtert werden, indem der Zugriff hauptsächlich über Windows-Gruppen aktiviert wird.
|
|
- Wurde das Prinzip der geringsten Rechte implementiert?
Tipp: Prinzipalen (Anmeldenamen, Benutzer und Rollen) sollten nur Berechtigungen für die Datenbankobjekte erteilt werden, auf die sie für ihre Arbeit zugreifen müssen. Ermöglichen Sie routinemäßigen Benutzern nicht das Herstellen einer Verbindung mit einem Administratorkonto (z. B. sa). Ermöglichen Sie der Webseite, der benutzerdefinierten Anwendung oder dem SSIS-Paket nicht das Herstellen einer Verbindung mit einem Administratorkonto.
|
|
- Wurde die VIEW DEFINITION-Berechtigung selektiv auf Objekt-, Schema-, Datenbank- oder Serverebene erteilt, damit Systemmetadaten ohne die Erteilung weiterer Berechtigungen angezeigt werden können?
Tipp: Weitere Informationen erhalten Sie unter GRANT (Transact-SQL).
|
|
- Wurden Remoteserver durch Verbindungsserver ersetzt?
Tipp: Weitere Informationen finden Sie unter Konfigurieren von Remoteservern und Verbindungsserver.
|
|
- Wenn die Pass-Through-Authentifizierung für einen Verbindungsserver erforderlich ist, wurde die Delegierung eingeschränkt?
Tipp: Weitere Informationen erhalten Sie unter sp_addlinkedsrvlogin (Transact-SQL).
|
|
- Wurden Ad-hoc-Abfragen über Server deaktiviert (sofern nicht benötigt)?
Tipp: Weitere Informationen erhalten Sie unter Ad Hoc Distributed Queries (Option).
|
Verwalten der Benutzeridentität
Diese Elemente beziehen sich auf Einstellungen in allen Datenbanken.
|
- Ist das Gast-Benutzerkonto in allen Datenbanken deaktiviert, sofern es nicht für anonyme Benutzer benötigt wird?
Tipp: Deaktivieren Sie Konten, die SQL Server Management Studio oder Transact-SQL verwenden.
|
|
- Verfügen Benutzer nur über Zugriff auf erforderliche Datenbanken?
Tipp: Hierfür müssen ggf. regelmäßig manuelle Überprüfungen durchgeführt werden. Dies kann erleichtert werden, indem der Zugriff hauptsächlich über SQL Server-Rollen aktiviert wird. Weitere Informationen finden Sie unter Rollen auf Serverebene.
|
|
- Wurde dem Großteil der Benutzer Zugriff über SQL Server-Rollen erteilt?
Tipp: Das Konfigurieren des Zugriffs mit Server- und Datenbankrollen vereinfacht die Verwaltung und Wartung des Zugriffs. Weitere Informationen zu Rollen finden Sie unter Rollen auf Datenbankebene.
|
|
- Verwendet der SQL Server-Agent Anmeldeinformationen zur Ausführung von Auftragsschritten, die statt der Anpassung der Privilegien des Dienstkontos für den SQL Server-Agent spezielle Privilegien erfordern?
Tipp: Weitere Informationen erhalten Sie unter Anmeldeinformationen (Datenbankmodul).
|
|
- Wenn der Benutzer eines SQL Server-Agents einen Auftrag ausführen muss, für den unterschiedliche Windows-Anmeldeinformationen erforderlich sind, wurde ein Proxykonto zugewiesen, das über ausreichend Genehmigungen zum Ausführen des Tasks verfügt?
Tipp: Weitere Informationen erhalten Sie unter Vorgehensweise: Erstellen eines Proxykontos (SQL Server Management Studio).
|
|
- Wird der Zugriff auf Datenbankobjekte innerhalb von Modulen (z. B. gespeicherten Prozeduren, Funktionen, Triggern oder Assemblys) gekapselt?
Tipp: Das Beschränken des Zugriffs auf vordefinierte Module erschwert böswilligen Benutzern das Ausführen von willkürlichem Code. Weitere Informationen finden Sie unter Grundlegendes zu gespeicherten Prozeduren.
|
|
- Haben Sie statt der Verwendung des Standardkontexts in Modulen explizit einen Ausführungskontext festgelegt?
Tipp: Weitere Informationen erhalten Sie unter Verwenden von EXECUTE AS in Modulen.
|
|
- Sind Module zum Schutz vor Manipulation signiert?
Tipp: Weitere Informationen erhalten Sie unter Modulsignierung (Datenbankmodul).
|
|
- Verwenden Sie statt Anwendungsrollen USER WITHOUT LOGIN?
Tipp: Weitere Informationen finden Sie im Dokument mit bewährten Methoden für die SQL Server 2005-Sicherheit – betriebs- und administrationsbezogene Aufgaben.
|
|
- Verwenden Sie EXECUTE AS statt SETUSER?
Tipp: Weitere Informationen finden Sie unter EXECUTE AS im Vergleich zu SETUSER.
|
|
- Haben Sie Anwendungsrollen durch EXECUTE AS ersetzt?
Tipp: Verwenden Sie möglichst EXECUTE AS … WITH NO REVERT. Verwenden Sie bei der Schachtelung von Identitätsänderungen die Option EXECUTE AS … WITH COOKIE. Weitere Informationen finden Sie unter EXECUTE AS (Transact-SQL).
|
Objektzugriff
Diese Elemente beziehen sich auf den Zugriff auf Datenbankobjekte.
|
- Werden den öffentlichen Server- und Datenbankrollen wenige Berechtigungen erteilt (falls zutreffend)?
Tipp: Alle Anmeldenamen und Benutzer sind Mitglieder der öffentlichen Rollen und können nicht entfernt werden. Die Rollen sollten über begrenzte Berechtigungen verfügen.
|
|
- Sind gleiche Datenbankobjekte gemeinsam im gleichen Schema gruppiert?
Tipp: Erstellen Sie Schemas auf Grundlage von Geschäftsanforderungen. Verwenden Sie statt des dbo-Schemas die benutzerdefinierten Schemas. Weitere Informationen finden Sie unter Schemas (Datenbankmodul).
|
|
- Wird die Sicherheit von Datenbankobjekten durch Festlegen von Besitz und Berechtigungen auf Schemaebene verwaltet?
Tipp: Weitere Informationen erhalten Sie unter GRANT-Schemaberechtigungen (Transact-SQL).
|
|
- Sind für Schemas unterschiedliche Besitzer vorhanden, oder befinden sich alle Schemas im Besitz von dbo?
Tipp: Weisen alle Schemas denselben Besitzer auf, umgeht die Besitzverkettung möglicherweise notwendige Berechtigungsprüfungen. Weitere Informationen finden Sie unter Besitzketten.
|
|
- Verwenden Sie Codesignierung für Prozedurencodes, wenn für die Prozedur zusätzliche Privilegien erforderlich sind?
Tipp: Weitere Informationen erhalten Sie unter Modulsignierung (Datenbankmodul).
|
|
- Ist die TRUSTWORTHY-Datenbankoption deaktiviert?
Tipp: Ist die Option aktiv, können die Datenbankmodule (z. B. benutzerdefinierte Funktionen oder gespeicherte Prozeduren), die einen Identitätswechselkontext verwenden, auf Ressourcen außerhalb der Datenbank zugreifen. Verwenden Sie die ALTER DATABASE-Anweisung zum Ändern der TRUSTWORTHY-Einstellung. Weitere Informationen finden Sie unter TRUSTWORTHY-Datenbankeigenschaft.
|
|
- Werden von Modulen Schritte zum Schutz vor Einschleusung von SQL-Befehlen unternommen?
Tipp: Weitere Informationen erhalten Sie unter SQL Injection.
|
|
- Wenn Ad-hoc-Zugriff auf die Datenbank erteilt ist (statt der Kapselung von Zugriff innerhalb von Modulen), werden von Anwendungen Schritte zum Schutz vor Einschleusung von SQL-Befehlen unternommen?
Tipp: Weitere Informationen finden Sie unter den folgenden Links.
|
Überwachungsbezogener Zugriff
Siehe auch
Konzepte
Andere Ressourcen