Microsoft: SQL-Server 2008 mit verbesserter Verschlüsselung
SQL Server 2008 – Mehr Sicherheit für die Datenbankumgebung

Transparente Datenverschlüsselung

Microsoft hat den SQL Server 2008 in Punkto Sicherheit erweitert. Damit soll der Schutz der Daten vor Verlust oder Diebstahl unterbunden werden. Die Grundlage dafür liefert weiterhin die Benutzer-Authentifizierung. Nur wenn Benutzer und Passwort korrekt sind, erhält der Benutzer Zugang zu dem System. Dieses Verfahren schützt vor unberechtigten Benutzern. Hinterlegt sind die Benutzerdaten entweder im SQL Server oder im Active Directory.

Neu im SQL Server 2008 nun ist die Verschlüsselung der Daten durch die „Transparent Data Encryption“. Diese Funktion verschlüsselt sowohl die Datentabellen als auch Protokolldateien. Damit erfolgt im SQL Server eine Codierung der Daten ähnlich wie es Bitlocker für das Windows Dateisystem macht.

Die Verschlüsselung läuft implizit durch den SQL Server ab und erfordert keine Änderungen an den Applikationen. Somit lassen sich sehr schnell große Datenbestände im nach hinein vor unberechtigten Zugriffen schützen. Eingeschlossen sind auch bestehende Datenbanken und deren Protokolldateien.

Schutz vor Datendiebstahl

Die Verschlüsselung dient in erster Linie vor einem Diebstahl des Mediums, wie des gesamten Rechners oder der Festplatten auf denen sich die Datenbank und ihre Tabellen befinden. Durch die transparente Datenverschlüsselung wird dabei verhindert, dass unbefugte Benutzer auf eine Datenbank zugreifen können.

Die Aktivierung der „Transparent Data Encryption“ erfolgt auf der Seite der Datenbank-Einstellungen unter den Eigenschaften (Properties) des Servers. Durch diese Einstellung wird die Encryption generell für alle Datenbanken auf diesem Server aktiviert und wird dann, wenn keine anderen Angaben bei der jeweiligen Datenbank getroffen werden, dementsprechend durchgeführt.

Daneben lassen sich aber auch spezifische Einstellungen für eine Datenbank vornehmen. Um die Verschlüsselung für eine Datenbank zu aktivieren oder auch wieder zu deaktivieren, ist die Datenbank anzuwählen. Anschließend muss der Administrator über das Kontext-Menü der selektierten Datenbank die Option „Manage Database Encryption“ im Task-Menü aufrufen.

Mehrere Wege der Verschlüsselung

Im anschließenden Dialog ist der Codier-Algorithmus (Encryption Algorithm) zu selektieren. Hier bietet der SQL Server 2008 die Auswahl aus den folgenden vier Möglichkeiten: AES128, AES192, AES256 und Triple DES. Die Verfahren unterscheiden sich in der Sicherheit der Verschlüsselung. So hat beispielsweise AES256 gegenüber den AES128 einen doppelt so langen Schlüssel und gilt daher als sicherer.

Die Verschlüsselung und Entschlüsselung benötigt aber auch mehr CPU-Ressourcen. Die zur Verschlüsselung notwendigen Schlüssel werden direkt im Kontext des SQL Servers verwaltet. Hierzu stellt der SQL Server die Funktionen des “Extensible Key Management” bereit. Dies ermöglicht es Drittanbietern sich in die Schlüsselverwaltung zu integrieren.

Die Grundlage für das “Extensible Key Management” stellt wiederum die Microsoft Cryptography API dar. Diese erlaubt die Bereitstellung eigener Schüssel für die Codier-Funktionen. Nach der Registrierung der Schüssel können die Anwender die in diesen Modulen gespeicherten Verschlüsselungsschlüssel und die von den Modulen unterstützten Features für die erweiterte Verschlüsselung nutzen, wie beispielsweise die Massenverschlüsselung und -entschlüsselung sowie zahlreiche Schlüssel-Verwaltungsfunktionen.

Sicherheitsüberwachungen der SQL Server-Operationen

Das Auditing des SQL Servers 2008 gehört ebenso in die Gruppe der Sicherheitsfunktionen. Durch die Überwachung der Datenbankfunktionen soll damit die Sicherheit weiter erhöht werden. Das Auditing dient der Überwachung, wer welche Operationen mit der Datenbank, dessen Inhalten oder der Konfiguration ausführt. Dabei lässt sich genau überwachen, welche SQL-Kommandos abgesetzt werden oder wer wann eine Kopie der Datenbank erzeugt, ändert oder löscht.

Notwendig sind die Auditing-Funktionen insbesondere im Umgang mit personenbezogenen Daten, wie etwa im Personalwesen, bei Finanzdaten oder in sonstigen Segmenten, die einer verstärkten Überwachung unterliegen.

Der SQL Server umfasst eine Vielzahl an Audit-Optionen.

Auditing direkt im Kontext des SQL Servers

Das Auditing wurde direkt in die Engine des SQL Servers 2008 integriert und kann somit als Garant für hohe Performance des Auditing gelten. Gleichzeitig ist es sehr selektiv einzustellen. Ferner erlaubt es eine flexible Anpassung an die Aktionen und Operationen. Dies hilft, die Audit-Logs klein zu halten und ermöglicht die Fokussierung auf das wirklich wichtige in diesem Zusammenhang.

Das Auditing im SQL Server 2008 genügt nun auch den Compliance-Anforderungen. Wird beispielsweise nun das Auditing selbst verändert oder abgeschaltet, so sind diese Änderungen später jederzeit nachvollziehbar. Dies gilt auch für Änderungen am Schema der Datenbank oder ihren Inhalten.

Welche Aktionen oder Änderungen durch das Auditing zu überwachen sind, wird entweder über das Management Studio oder direkt über T-SQL eingestellt. Durch die Richtlinien-Verwaltung sind diese Auditing-Vorgaben dann auf alle Ziel-Datenbanken auszurollen und können dort auch nicht verändert werden.

In zwei Schritten zum Audit

Die Konfiguration des Auditings im  SQL Servers ist ein zweistufiger Prozess. Im ersten Schritt ist das Audit-Objekt einzustellen. Es bestimmt den Speicherplatz der Audit-Log-Inhalte, also wohin die Logs gespeichert werden. Dabei kann es sich beispielsweise um eine Datei im Dateisystem, Einträgen in der Windows Application Log oder auch der Windows Security Log handeln.

Das Windows Application Log oder auch das Windows Security Log als Basis für die Log-Inhalte zu verwenden, ist zwar sehr einfach, aber in der Regel nicht anzuraten. Zum einen erfüllt das Windows Applikation Log kaum die Sicherheitsanforderungen und ferner sind Auswertungen darin nur schwer durchzuführen. Das Windows Security Log ist zwar sicherer und kann nicht von jedem Benutzer gelesen werden. Hinsichtlich der Auswertung gilt aber das gleiche wie beim Windows Applikation Log. Generell sollte man natürlich daran denken, dass die Log-Daten sich nicht im Zugriff von Benutzern befinden, die nicht explizit dafür vorgesehen sind, denn dann ist das ganze Verfahren wieder ad absurdum geführt.

Das zweite Element für das Auditing ist die Audit Spezifikation. Sie bestimmt, was durch das Auditing überwacht werden soll. Die Grundlage für das Auditing wird durch die Extended Events gebildet. Sie bieten einen effizienten Weg auf Ereignisse des SQL Servers zu reagieren und an diese Ereignisse Aktionen zu knüpfen.

Prinzipiell werden dabei zwei unterschiedliche Gruppen unterschieden. In der Server-Aktionsgruppe erfolgt die Überwachung eines SQL Servers und dessen allgemeinen Einstellungen und Aktionen. Hierbei sind beispielsweise die Anmelde- und Abmeldevorgänge eines Benutzers zu überwachen, ferner die Änderungen an den Konfigurationen oder am Eigentümer einer Datenbank, sowie Änderungen an den Mitgliedschaften von Benutzer, ihren Rollen und ähnliche Kriterien.