SQL Server 2008

Sicherheit

Rick Byham

Kurz zusammengefasst:

• Verbesserungen bei der Verschlüsselung
• Verbesserungen bei der Authentifizierung
• Sicherheitsüberwachung
• Richtlinienbasierte Verwaltung

SQL Server 2008 bietet viele Verbesserungen und neue Features, die dafür entwickelt wurden, die Sicherheit Ihrer Datenbankumgebung insgesamt zu verbessern. In SQL Server 2008 sind wichtige Verschlüsselungs- und Authentifizierungsfunktionen hinzugekommen, und es wird ein neues Überwachungssystem eingeführt, um

Ihnen zu helfen, Berichte zum Benutzerverhalten zu generieren und Ihre rechtlichen Anforderungen zu erfüllen.

In diesem Artikel werde ich Ihnen einen Überblick über die wichtigsten Änderungen vermitteln, die zur Verbesserung der Sicherheit in SQL Server® 2008 integriert wurden. Eines der ersten Dinge, die Ihnen auffallen werden, ist die Tatsache, dass das SQL Server 2005-Tool zur Oberflächenkonfiguration entfernt wurde. Die Protokolloptionen, die durch das Tool zur Oberflächenkonfiguration bereitgestellt wurden, stehen jetzt im Konfigurations-Manager zur Verfügung. Das Aktivieren und Deaktivieren von Features erfolgt jetzt allerdings über das neue Framework für die richtlinienbasierten Verwaltung von SQL Server 2008.

Verbesserungen bei der Verschlüsselung

Im Bereich der Verschlüsselung wurden vor allem zwei wichtige Verbesserungen vorgenommen. Erstens kann SQL Server jetzt Verschlüsselungsschlüssel verwenden, die auf einem externen Hardwaresicherheitsmodul eines Drittanbieters gespeichert sind. Zweitens können Daten, die in SQL Server gespeichert sind, nach einer Methode verschlüsselt werden, die für Anwendungen, von denen eine Verbindung zur Datenbank hergestellt wird, transparent ist. Dies bedeutet, dass Datenbankadministratoren problemlos alle in einer Datenbank gespeicherten Daten verschlüsseln können, ohne vorhandenen Anwendungscode ändern zu müssen.

Die erste Verbesserung wird durch das neue EKM-Feature (Extensible Key Management, Erweiterbare Schlüsselverwaltung) möglich, das in den Enterprise-, Developer- und Evaluation-Editionen von SQL Server 2008 verfügbar ist. EKM ermöglicht es Drittanbietern von Lösungen zur Unternehmensschlüsselverwaltung und Hardwaresicherheitsmodul-Lösungen, ihre Geräte in SQL Server zu registrieren. Sobald diese Geräte registriert wurden, können die Benutzer die auf diesen Modulen gespeicherten Verschlüsselungsschlüssel verwenden.

Diese Anbieter können in diesen Modulen sogar erweiterte Verschlüsselungsfeatures wie z. B. Schlüsselalterung und Schlüsselrotation verfügbar machen. In einigen Konfigurationen macht dies es möglich, Daten vor Datenbankadministratoren zu schützen, die nicht Mitglieder der sysadmin-Gruppe sind. Danach können die kryptografischen T-SQL-Anweisungen die Daten unter Verwendung der auf dem externen EKM-Gerät gespeicherten Schlüssel ver- und entschlüsseln.

Ein weiteres neues Feature – die transparente Datenverschlüsselung – ermöglicht Ihnen, Datenbankdateien zu verschlüsseln, ohne eine einzige Ihrer Anwendungen ändern zu müssen. Dieses Feature führt eine E/A-Verschlüsselung und -Entschlüsselung der Daten- und Protokolldateien in Echtzeit durch. Zur Verschlüsselung wird ein DEK (Database Encryption Key, Datenbankverschlüsselungsschlüssel) verwendet, der im Datenbankstartdatensatz gespeichert wird, um bei einer Wiederherstellung verfügbar zu sein. Der DEK wird durch ein Zertifikat geschützt, das in der master-Datenbank des Servers gespeichert ist. Das Diagramm in Abbildung 1 veranschaulicht die Architektur, die diese transparente Datenverschlüsselung ermöglicht.

Abbildung 1** Architektur der transparenten Datenverschlüsselung **(Klicken Sie zum Vergrößern auf das Bild)

Dies hilft, ruhende Daten zu schützen. Obwohl Sie mehrere Vorsichtsmaßnahmen ergreifen können, um Ihre Datenbank zu schützen, indem Sie beispielsweise vertrauliche Ressourcen verschlüsseln und die Datenbankserver mit einem Firewall umgeben, stellen die physischen Medien, auf denen die Datenbank gespeichert ist (selbst die Sicherungsbänder), eine ganz andere Art von Sicherheitsrisiko dar. Ein böswilliger Benutzer könnte diese Medien stehlen und unter Umständen auf die gespeicherten Daten zugreifen.

Bei der transparenten Datenverschlüsselung dagegen können Sie die vertraulichen Daten in der Datenbank verschlüsseln und die Schlüssel, die zum Verschlüsseln der Daten verwendet werden, mit einem Zertifikat schützen. Dies kann Ihrem Unternehmen helfen, viele Gesetze, Bestimmungen und Branchenrichtlinien zu erfüllen, die den angemessenen Schutz von Daten betreffen.

Die transparente Datenverschlüsselung ermöglicht Softwareentwicklern, Daten mit AES (Advanced Encryption Standard, erweiterter Verschlüsselungsstandard)- und 3DES (Dreifach-DES)-Verschlüsselungsalgorithmen zu verschlüsseln. Die Verschlüsselung der Datenbankdatei wird auf Seitenebene durchgeführt, indem die Seiten verschlüsselt werden, bevor sie auf den Datenträger geschrieben werden, und später beim Einlesen in den Speicher wieder entschlüsselt werden. Sicherungsdateien von Datenbanken, für die transparente Datenverschlüsselung aktiviert wurde, werden ebenfalls mit dem Datenbankverschlüsselungsschlüssel verschlüsselt.

Zur Wiederherstellung einer verschlüsselten Datenbank benötigen Sie Zugriff auf das Zertifikat oder den asymmetrischen Schlüssel, das bzw. der zum Verschlüsseln der Datenbank verwendet wurde. Ohne das Zertifikat oder den asymmetrischen Schlüssel kann die Datenbank nicht wiederhergestellt werden. Achten Sie also darauf, alle Schlüssel aufzubewahren, solange Sie Zugriff auf die mit ihnen verknüpften Datensicherungen benötigen.

Verbesserungen bei der Authentifizierung

Wie Sie wahrscheinlich wissen, ist Kerberos ein Netzwerkauthentifizierungsprotokoll, das verwendet wird, um eine äußerst sichere Methode für das gegenseitige Authentifizieren von Client- und Serverentitäten (oder Sicherheitsprinzipalen) in einem Netzwerk bereitzustellen. Kerberos hilft Benutzern, Sicherheitsrisiken wie z. B. die Anfälligkeit für Lockangriffe und Man-in-the-Middle-Angriffe zu verringern. Im Vergleich zur NTLM-Authentifizierung von Windows® ist Kerberos sicherer, stabiler und leistungsfähiger.

Um mit Kerberos eine Verbindung in beiden Richtungen zu authentifizieren, müssen die Dienstprinzipalnamen (SPN, Service Principal Names) einer SQL Server-Instanz in Active Directory® registriert werden, und es muss ein Clienttreiber beim Herstellen einer Verbindung einen registrierten SPN angeben. In SQL Server 2008 wurde die Kerberos-Authentifizierung auf alle Netzwerkprotokolle einschließlich TCP, Named Pipe, Shared Memory und VIA (Virtual Interface Adapter) erweitert. Standardmäßig leitet der Clienttreiber für eine SQL Server-Instanz, zu der er eine Verbindung herstellt, automatisch einen richtigen SPN ab. Sie können einen SPN auch explizit im Verbindungszeichenfolgenparameter angeben, um eine höhere Sicherheit, mehr Kontrolle und eine bessere Problembehandlung zu erzielen.

IIS (Internet Information Services, Internetinformationsdienste) bietet keinen Zugriff mehr auf ASP.NET, Berichts-Manager oder den Berichtsserver-Webdienst. In SQL Server 2008 verarbeiten die Reporting Services alle Authentifizierungsanforderungen über ein neues Authentifizierungssubsystem, das sowohl Windows-basierte als auch benutzerdefinierte Authentifizierungen unterstützt.

Reporting Services hostet jetzt die Technologien Microsoft® .NET Framework und ASP.NET, die in die SQL Server-CLR (Common Language Runtime) integriert sind, und verwendet auch die HTTP.SYS-Funktionen des Betriebssystems. Der Berichtsserver beinhaltet einen HTTP-Listener, der Anforderungen akzeptiert, die an eine URL und einen Port geleitet werden, die Sie während der Serverkonfiguration festlegen. URL-Reservierungen und -Registrierungen werden jetzt über HTTP.SYS direkt durch den Berichtsserver verwaltet.

Sicherheitsüberwachung

Mit dem neuen Feature „SQL Server Audit“ können Sie benutzerdefinierte Überwachungen von Datenbankmodulereignissen einrichten. Dieses Feature verwendet erweiterte Ereignisse, um Informationen für Überwachungen aufzuzeichnen, und stellt die Tools und Prozesse bereit, die Sie benötigen, um Überwachungen verschiedener Server und Datenbankobjekte zu aktivieren, zu speichern und anzuzeigen.

Darüber hinaus ist SQL Server Audit schneller als die SQL Server-Ablaufverfolgung, und SQL Server Management Studio erleichtert Ihnen die Aufgabe, die Überwachungsprotokolle zu erstellen und zu prüfen. Jetzt können Sie eine detailliertere Überwachung durchführen und auch SELECT-, INSERT-, UPDATE-, DELETE-, REFERENCES- und EXECUTE-Anweisungen einzelner Benutzer erfassen. SQL Server Audit ist zudem durch die T-SQL-Anweisungen „CREATE SERVER AUDIT“ und „CREATE SERVER AUDIT SPECIFICATION“ sowie die zugehörigen ALTER- und DROP-Anweisungen vollständig skriptfähig.

Um die Überwachung einzurichten, erstellen Sie einen Überwachungsprozess und legen den Speicherort fest, an dem die überwachten Ereignisse aufgezeichnet werden sollen. Überwachungen können im Windows-Sicherheitsprotokoll, im Windows-Anwendungsprotokoll oder in einer Datei an einem von Ihnen festgelegten Speicherort gespeichert werden. Sie weisen der Überwachung einen Namen zu und konfigurieren ihre Merkmale wie z. B. den Pfad zur Überwachungsdatei und ihre maximale Größe. Sie können auch festlegen, dass SQL Server heruntergefahren werden soll, falls die Überwachung fehlschlägt. Falls es notwendig ist, die überwachten Ereignisse an mehreren Speicherorten zu protokollieren, erstellen Sie einfach mehrere Überwachungen.

Der nächste Schritt besteht darin, eine oder mehrere Überwachungsspezifikationen zu erstellen. Eine Serverüberwachungsspezifikation sammelt Informationen über die Instanz von SQL Server und enthält für Server vorgesehene Objekte wie z. B. Anmeldungen und Serverrollenmitgliedschaften. Sie enthält auch Datenbankinformationen, die in der master-Datenbank verwaltet werden, wie z. B. die Berechtigung, auf eine Datenbank zuzugreifen. Wenn Sie eine Überwachungsspezifikation definieren, geben Sie an, welche Überwachung die überwachten Ereignisse erhalten wird. Sie können mehrere Serverüberwachungen und mehrere Serverüberwachungsspezifikationen definieren, aber in jeder Serverüberwachung kann immer nur eine einzige aktivierte Serverüberwachungsspezifikation enthalten sein.

Sie können auch Datenbanküberwachungsspezifikationen erstellen, die Ereignisse in einer einzelnen Datenbank überwachen. Sie können einer Überwachung mehrere Datenbanküberwachungsspezifikationen hinzufügen, aber eine einzige Serverüberwachung kann immer nur eine einzige Datenbanküberwachungsspezifikation pro Datenbank aktivieren.

Die für Serverüberwachungsspezifikationen verwendeten SQL Server-Überwachungsaktionsereignisse werden in Sammlungen verwandter Überwachungsaktionsereignisse gruppiert. Diese Sammlungen werden als Überwachungsaktionsgruppen verfügbar gemacht. Wenn Sie der Überwachungsspezifikation eine Gruppe hinzufügen, überwachen Sie alle in dieser Gruppe enthaltenen Ereignisse. So gibt es beispielsweise eine Überwachungsaktionsgruppe namens „DBCC_GROUP“, die die DBCC-Befehle verfügbar macht. Die DBCC-Befehle sind jedoch nicht einzeln für eine Überwachung verfügbar.

Für den Server stehen 35 Überwachungsaktionsgruppen zur Verfügung, von denen einige nahe miteinander verwandt sind. Es gibt zum Beispiel eine SUCCESSFUL_LOGIN_GROUP, eine FAILED_LOGIN_GROUP und eine LOGOUT_GROUP. Ferner gibt es einen Überwachungsaktionstyp namens „AUDIT_ CHANGE_GROUP“, den Sie verwenden können, um den Überwachungsprozess zu überwachen.

Datenbanküberwachungsspezifikationen können auch Gruppen von Überwachungsaktionsereignissen festlegen, die in Überwachungsaktionsgruppen auf Datenbankebene gesammelt werden. Zusätzlich zu den Überwachungsaktionsgruppen kann eine Datenbanküberwachungsspezifikation einzelne Überwachungsaktionsereignisse enthalten, um Anweisungen der Datenbearbeitungssprache zu überwachen. Diese Ereignisse können dafür konfiguriert werden, die gesamte Datenbank oder nur bestimmte Datenbankobjekte zu überwachen. Beispielsweise kann die Überwachungsaktion „SELECT“ dazu verwendet werden, SELECT-Abfragen für eine einzige Tabelle oder ein ganzes Schema zu überwachen. Diese Ereignisse können auch dafür konfiguriert werden, Aktionen bestimmter Benutzer oder Rollen (z. B. aller Inhaber der Rolle „db_writer“) zu überwachen.

Sie können beispielsweise die Überwachungsaktion „SELECT“ dafür verwenden, SELECT-Abfragen des Benutzers „Mary“, der Datenbankrolle „FINANCE_DEPT“ oder der öffentlichen Datenbankrolle für eine einzige Tabelle zu überwachen. Dies gibt Ihnen viel Kontrolle und Flexibilität, um genau die Überwachungen zu erstellen, die Sie benötigen.

Abhängigkeitsberichterstattung

Die Abhängigkeitsberichterstattung wurde durch eine neue Katalogansicht und neue Systemfunktionen verbessert. Wenn Sie „sys.sql_expression_dependencies“, „sys.dm_sql_referencing_entities“ und „sys.dm_sql_referenced_entities“ verwenden, können Sie Berichte zu serverübergreifenden und datenbankübergreifenden Abhängigkeiten sowie zu Datenbank-SQL-Abhängigkeiten für schemagebundene und nicht schemagebundene Objekte generieren.

Neue Datenbankrollen

Es wurden Änderungen an den in der msdb-Datenbank enthaltenen Datenbankrollen vorgenommen. Die Rolle „db_dtsadmin“ wurde in „db_ssisadmin“, die Rolle „db_dtsltduser“ in „db_ssisltduser“ und die Rolle „db_dtsoperator“ in „db_ssisoperator“ umbenannt. Um Abwärtskompatibilität zu unterstützen, werden die alten Rollen beim Aktualisieren der Server als Mitglieder der neuen Rollen hinzugefügt.

Zusätzlich zu diesen Änderungen wurden zur Unterstützung neuer Features von SQL Server 2008 neue Datenbankrollen hinzugefügt. Insbesondere enthält die msdb-Datenbank neue Rollen für Servergruppen („ServerGroupAdministratorRole“ und „ServerGroupReaderRole“), für die richtlinienbasierte Verwaltung („PolicyAdministratorRole“) und für den Datensammler („dc_admin“, „dc_operator“ und „dc_proxy“). Auch die Datenbank des Verwaltungs-Data Warehouse enthält neue Rollen für den Datensammler („mdw_admin“, „mdw_writer“ und „mdw_reader“).

FILESTREAM-Sicherheit

SQL Server unterstützt jetzt auch FILESTREAM-Speicher. Dies ermöglicht es, mit SQL Server-Anwendungen unstrukturierte Daten wie z. B. Dokumente und Bilder im Dateisystem zu speichern. Dies wiederum bedeutet, dass Clientanwendungen von den Streaming-APIs und der Leistung des Dateisystems profitieren und zugleich die Transaktionskonsistenz zwischen den unstrukturierten und den entsprechenden strukturierten Daten beibehalten können.

FILESTREAM-Daten müssen in FILESTREAM-Dateigruppen gespeichert werden. Bei diesen FILESTREAM-Dateigruppen handelt es sich um spezielle Dateigruppen, in denen nicht die Dateien selbst, sondern Dateisystemverzeichnisse enthalten sind. Diese als Datencontainer bezeichneten Verzeichnisse stellen die Schnittstelle zwischen Datenbankmodulspeicher und Dateisystemspeicher bereit.

Im Hinblick auf die Sicherheit werden FILESTREAM-Daten genau wie alle anderen Daten geschützt, indem auf Tabellen- oder Spaltenebene Berechtigungen zugeteilt werden. Das einzige Konto, dem NTFS-Berechtigungen für den FILESTREAM-Container gewährt werden, ist das Konto, unter dem der SQL Server-Dienst ausgeführt wird. Wenn eine Datenbank geöffnet wird, schränkt SQL Server den Zugriff auf die FILESTREAM-Datencontainer ein, es sei denn, der Zugriff erfolgt über die T-SQL-Transaktionen und die OpenSqlFilestream-APIs.

Richtlinienbasierte Verwaltung

Die richtlinienbasierte Verwaltung von SQL Server 2008 stellt ein neues System zum Verwalten von SQL Server bereit. Sie können Richtlinien erstellen, um viele Aspekte von SQL Server zu testen und Berichte über sie zu generieren. Richtlinien können auf eine einzelne Datenbank, auf eine einzelne Instanz von SQL Server oder auf sämtliche von Ihnen verwalteten SQL-Server angewendet werden.

Mit richtlinienbasierter Verwaltung können Sie die SQL Server-Konfigurationsoptionen und viele der Sicherheitseinstellungen testen. Außerdem können Sie für einige Sicherheitseinstellungen Richtlinien erstellen, die nichtkonforme Datenbankserver erkennen, und anschließend die nötigen Schritte unternehmen, um diese Server konform zu machen.

In SQL Server 2008 sind einige weniger wichtige Features standardmäßig deaktiviert, um die Anfälligkeit für potenzielle Angriffe zu minimieren. Sie können die richtlinienbasierte Verwaltung verwenden, um selektiv zusätzliche Features zu aktivieren, die Sie benötigen. Darüber hinaus können Sie Ihre Konfiguration nach einem Zeitplan überprüfen und sich durch Warnmeldungen informieren lassen, falls bei einer Überprüfung festgestellt wird, dass die Konfigurationseinstellungen nicht den Richtlinien entsprechen.

Die richtlinienbasierte Verwaltung fasst verwandte Eigenschaften in Gruppen zusammen und macht sie in Komponenten verfügbar, die als Facets bezeichnet werden. So enthält beispielsweise das Facet „Oberflächenkonfiguration“ Eigenschaften für Ad-hoc-Remoteabfragen, CLR-Integration, Datenbank-E-Mail, OLE-Automatisierung, Remote-DAC, SQL Mail, Web-Assistent und xp_cmdshell. Sie können eine Richtlinie erstellen, die die CLR-Integration aktiviert, aber alle anderen Features deaktiviert. Ihre Richtlinie kann komplexe Bedingungsanweisungen enthalten, wie z. B. die Anweisung, Datenbank-E-Mail in allen Instanzen von SQL Server zu deaktivieren, es sei denn, sie tragen den Namen „Customer_Response“.

Sobald Sie die Richtlinie erstellt haben, können Sie die Richtlinie auf sämtlichen Servern überprüfen lassen, um einen Bericht zu generieren, der Sie darüber informiert, welche Server nicht konform sind. Wenn Sie dann auf die Schaltfläche „Konfigurieren“ klicken, werden alle Instanzen, die nicht konform sind, mit den Richtlinieneinstellungen konfiguriert. Sie sollten auch die Richtlinie nach einem Zeitplan regelmäßig ausführen lassen, um den Status Ihrer Server zu überwachen. Für das Datenbankmodul, die Analysis Services und die Reporting Services werden Oberflächenkonfigurations-Facets bereitgestellt.

Beachten Sie jedoch, dass diese richtlinienbasierte Verwaltung nicht als Methode zur Durchsetzung der Sicherheit konzipiert wurde. In den meisten Fällen kann ein Benutzer mit den erforderlichen Berechtigungen Anweisungen schreiben, die gegen eine Richtlinie verstoßen oder diese Richtlinie umgehen und Neukonfigurationsaktionen durchführen, die gegen Ihre Sicherheitsrichtlinie verstoßen könnten. Die richtlinienbasierte Verwaltung von SQL Server 2008 sollte lediglich als Hilfe bei der Überwachung Ihrer SQL Server-Sicherheitseinstellungen betrachtet werden.

Die einzelnen Facets variieren in Abhängigkeit davon, ob ihre zugehörigen DDL-Anweisungen in Modi ausgeführt werden können, die keine autocommit-Modi sind, in ihrer Fähigkeit, Einstellungen durchzusetzen. Manchmal kann ein Facet eine Konfiguration in einer Instanz des Datenbankmoduls durchsetzen, aber ein Administrator kann nach wie vor die Einstellungen wieder umkonfigurieren. Einige Facets können von einem Servertrigger durchgesetzt werden. Dadurch lässt sich verhindern, dass Benutzer mit niedriger Berechtigungsstufe die Einstellung ändern, und es lässt sich die Wahrscheinlichkeit senken, dass ein Administrator die Einstellung aus Versehen ändert. In diesem Fall müsste der Administrator zuerst die Richtlinie vorübergehend deaktivieren, bevor er die Einstellung ändert. Andere Facets können nur den Status einer Eigenschaft melden, ihn aber nicht ändern. Dies ist bei einer Richtlinie der Fall, die die Schlüssellänge eines symmetrischen oder asymmetrischen Schlüssels prüft, wie in Abbildung 2 zu sehen ist.

Abbildung 2** Facet für asymmetrische Schlüssel **(Klicken Sie zum Vergrößern auf das Bild)

Es gibt Facets für die meisten Arten von Datenbankobjekten, von denen viele für die Sicherheit eingesetzt werden. So kann beispielsweise das Facet „Anmeldung“ ermitteln, ob die Kennwortrichtlinie bei jeder Anmeldung durchgesetzt wird, und das Facet „Gespeicherte Prozedur“ kann erkennen, ob alle Prozeduren verschlüsselt sind. Andere Facets testen die Eigenschaften von Benutzern, Schemas und kryptografischen Anbietern, die Einhaltung allgemeiner Kriterien und die C2-Überwachung.

Windows Server 2008

SQL Server 2008 wurde umfassend mit Windows Server® 2008 getestet, das mit aktivierter Firewall geliefert wird. Jetzt ist der richtige Zeitpunkt, sich anzusehen, wie die Firewalleinstellungen konfiguriert werden. Außerdem stellt Windows Server 2008 auch Benutzerkontensteuerung bereit, die Sie möglicherweise bereits aus Windows Vista® kennen. Die Benutzerkontensteuerung schränkt die Berechtigungen ein, die Sie als administrativer Benutzer automatisch erhalten. Diese Features betreffen alle Versionen von SQL Server.

Zusammenfassung

Sicherheit ist ein Bereich von SQL Server, der weiterhin im Brennpunkt von Optimierungsbemühungen steht. Verbesserungen bei der Verschlüsselung und der Authentifizierung stellen neue Funktionen bereit, und das neue Überwachungssystem sowie die richtlinienbasierte Verwaltung von SQL Server 2008 bieten Ihnen neue Tools, mit denen Sie den Status der Einhaltung von Sicherheitsanforderungen überwachen können.

Rick Byham kam 1995 zu Microsoft. Er hat als SQL Server-Supporttechniker beim Microsoft-Kundendienst gearbeitet und ist danach dem SQL Server-Team bei Microsoft Learning beigetreten. 2003 kam er als technischer Redakteur zum Team der SQL Server-Onlinedokumentation, wo er für die Sicherheitsdokumentation zuständig ist. Sie erreichen Rick Byham unter rick.byham@microsoft.com.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.