Artikel
03/30/2012

Checkliste: Beschränken des Datenzugriffs

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).

...	Beschreibung
	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.

...	Beschreibung
	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.

...	Beschreibung
	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. Gewusst wie: Schutz vor Einschleusung von SQL-Befehlen in ASP.NET Microsoft Source Code Analyzer for SQL Injection Das Tool Microsoft Source Code Analyzer for SQL Injection kann zum Auffinden von auf die Einschleusung von SQL-Befehlen bezogenen Sicherheitsrisiken in ASP-Code verwendet werden. Neue SQL-Kürzungsangriffe und entsprechende Schutzmaßnahmen Stoppen Sie auf die Einschleusung von SQL-Befehlen bezogene Angriffe, bevor Sie gestoppt werden

Überwachungsbezogener Zugriff

...	Beschreibung
	Ist Überwachung szenariospezifisch? Tipp: Wägen Sie die Notwendigkeit der Überwachung gegen den Arbeitsaufwand für das Generieren zusätzlicher Daten ab. Von der SQL Server-Überwachung kann die Überwachung in einer einzelnen Datenbank und für DML für bestimmte Objekte aktiviert werden. Weitere Informationen finden Sie unter Grundlegendes zu SQL Server Audit.
	Ist die Anmeldungsüberwachung so konfiguriert, dass ein Datensatz für fehlerhafte Anmeldungen beibehalten wird? Tipp: Konfigurieren Sie die Anmeldungsüberwachung anhand der Servereigenschaften (Sicherheit) in Management Studio.
	Wenn hoch sensible Daten gespeichert werden, werden sowohl erfolgreiche als auch erfolglose Anmeldungen gespeichert? Tipp: Weitere Informationen finden Sie unter Audit Login (Ereignisklasse) und Audit Login Failed (Ereignisklasse).
	Werden DDL, DML und spezifische Serverereignisse mit der SQL Server-Überwachung bzw. der Ablaufverfolgung überwacht? Tipp: Weitere Informationen finden Sie unter Grundlegendes zu SQL Server Audit, Grundlegendes zu Ereignisbenachrichtigungen, DDL-Ereignisse und Ablaufverfolgungsereignisse für die Verwendung mit Ereignisbenachrichtigungen.
	Verwenden Sie WMI, um sich vor Notfallereignissen warnen zu lassen? Tipp: Weitere Informationen erhalten Sie unter Konzepte des WMI-Anbieters für Serverereignisse.
	Ist C2-Überwachung oder Common Criteria-Kompatibilität nur bei Bedarf aktiviert? Tipp: Legen Sie die Konfiguration gemäß Ihren Geschäftsanforderungen fest. Aktivieren Sie C2-Überwachung oder Common Criteria-Kompatibilität nur dann, wenn es für Ihr Unternehmen erforderlich ist. Weitere Informationen erhalten Sie unter Common Criteria-Zertifizierung.