Als im Juni 2013 die amerikanische Washington Post und der britische Guardian damit begannen, geheime Dokumente eines ehemaligen Mitarbeiters des amerikanischen Auslandsgeheimdienstes NSA zu veröffentlichen, wurde der Weltöffentlichkeit klar, wie transparent scheinbar jegliche Kommunikation und damit auch die dadurch erhobenen Daten eines jeden von uns sind. Die dadurch neuentfachte Debatte um den Datenschutz schafft immer mehr Sensibilität im Umgang mit unseren privaten Daten. Auch Unternehmen, allen voran das Finanz- und Bankenwesen, haben in den meisten Fällen festgeschriebene Regeln, wie mit allgemeinen Geschäftsdaten umzugehen ist. In Deutschland werden diese Regeln vom Bundesamt für Sicherheit in der Informationstechnologie (kurz: BSI) definiert und als sogenannter IT-Grundschutz veröffentlicht. Kernziele sind dabei Vertraulichkeit, Verfügbarkeit, Integrität und Identität sicherzustellen, um dadurch Gefahren und Risiken zu minimieren. Was bedeutet dies nun aber in Business-Intelligence-Projekten? Der folgende Blogbeitrag soll die potenziellen Gefahrenquellen hinsichtlich der Vertraulichkeit aufzeigen und im Detail die Möglichkeit zur Verschlüsselung der relationalen Datenquelle mit Hilfe der sogenannten transparenten Datenverschlüsselung (kurz: TDE) des Microsoft SQL Servers aufzeigen.
Gefahrenquellen und Angriffspunkte
Eine gute schematische Übersicht kann der Architektur von üblichen DeltaMaster-Anwendungen entnommen werden, dabei repräsentiert jeder orangefarbene Pfeil einen Zugriffspunkt und damit eine potentielle Gefahrenquelle:
Abb. 1: mögliche Gefahrenquellen
Von unten nach oben gelesen ergibt sich:
- ETL-Prozess: Überführung der Daten aus den Vorsystemen in das relationale Data-Warehouse. Ein Angriffspunkt sind die Datenlade-Pakete (kurz: DTSX). Hier werden Verbindungsinformationen in Form von Benutzername und Passwort für die unterschiedlichsten Quellen und Ziele benötigt. Wie diese abgesichert werden können wird im Beitrag „SSIS Package Security“ erläutert.
- Verbindung zur Data-Warehouse-Datenbank: Das SQL-Server-Datenbankmodul (Database Engine) kann für Verbindungen mit Secure Socket Layer (kurz: SSL), also der Verschlüsselung von Verbindungen durch Absicherung des Übertragungsprotokolls, konfiguriert werden. Die notwendigen Schritte sind nicht Thema dieses Blogbeitrags, können aber im Microsoft Technet nachgelesen werden. Der entsprechende Link befindet sich am Ende dieses Beitrags.
- Data-Warehouse-Datenbank: erhält jemand unberechtigten Zugriff auf diese Datenbank, kann jeglicher Inhalt ausspioniert bzw. zweckentfremdet werden. Der Zugriff sollte über ein detailliertes Berechtigungskonzept erfolgen. Ist dieser Zugriff aber umgangen worden und die Sicherung einer solchen Datenbank in die Hände Dritter gelangt, sollten die Datenbank-Dateien mittels transparenter Verschlüsselung geschützt sein. Die notwendigen Schritte werden in diesem Blog dargestellt.
- Verbindung zwischen Analysis-Services und Data-Warehouse: Der Zugriff erfolgt zwar serverintern, aber technisch werden die Daten über die Netzwerkkarte ausgetauscht. Protokolle sind hier entweder NamedPipes, SharedMemory oder TCP/IP. Eine Absicherung ist über den ConnectionString möglich, die Eigenschaften sind:
- Persist Encrypted: Benutzername und Passwort werden verschlüsselt, Standard ist unverschlüsselt!
- Use Encryption for Data: Datenübertragungen werden verschlüsselt. Diese Eigenschaft muss explizit angegeben werden.
- Verbindung zwischen DeltaMaster und Analysis Services: Im Standard beantwortet SSAS nur verschlüsselte Anfragen von einem Client, die Daten werden ebenfalls nur verschlüsselt gesendet:
- Security\AdministrativeDataProtection\RequiredProtectionLevel
- Security\DataProtection\RequiredProtectionLevel
Transparente Datenverschlüsselung
Um SQL-Server-Datenbanken auf der untersten Stufe, sprich die eigentlichen Dateien zu verschlüsseln, existiert seit SQL Server 2008R2 die Möglichkeit, diese Dateien im Dateisystem abzusichern. Bei diesem als transparente Datenverschlüsselung bekannten Mechanismus werden die Dateien mit Hilfe eines Zertifikats verschlüsselt. Das bedeutet, alle Daten werden bei jedem Zugriff in Echtzeit entschlüsselt, wodurch natürlich die Abfrageleistungsfähigkeit negativ beeinträchtigt wird. Da aber in typischen DeltaMaster-Architekturen die meisten Schreib- und Lesezugriffe auf den relationalen Quellen im Rahmen der täglichen Verarbeitung meistens nachts erfolgen, ergibt sich lediglich für SQL-Durchgriffsberichte eine zu erwartende längere Abfragezeit für die Benutzer. Selbstverständlich gilt es dies bei einem geplanten produktiven Einsatz vorab zu testen und abzuwägen.
Die für die Konfiguration und Aktivierung notwendigen Schritte werden wir im Folgenden anhand der bekannten Demonstrationsdatenbank „Chair“ umsetzen und verdeutlichen.
- Erstellung eines Master-Keys
- Erstellung eines Zertifikats mit Hilfe des Master-Keys
- Erstellung eines Datenbank-Keys mit Hilfe des Zertifikats
- Aktivierung der Verschlüsselung auf der gewünschten Zieldatenbank
Schematische Funktionsweise
Abb. 2: Zusammenspiel beteiligter Komponenten
Konfigurationsschritte
Erstellung eines Master-Keys
Zunächst wird ein Master-Key benötigt. Dieser kann schnell und einfach mittels SQL erstellt werden. Da dieser Schlüssel serverweite Gültigkeit besitzt, wird er in der Master-Datenbank angelegt. Der Master-Key selbst wird durch den SQL Service Master-Key verschlüsselt. Dieser wird automatisch bei der Installation einer SQL-Server-Instanz angelegt.
USE master; GO CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Dies!Passwort$sollte#komplex&sein.2014'; GO
Erstellung eines Zertifikats mit Hilfe des Master-Keys
Anschließend können wir jetzt ein Server-Zertifikat erstellen. Um den korrekten Servernamen zu bekommen, sollte die Systemfunktion @@SERVERNAME abgefragt werden.
CREATE CERTIFICATE [BC-GLA-LAP-TEMP\SQL2012] WITH SUBJECT = 'TDE Zertifikat'; GO
Wichtig ist, dass ein solches eigens erstelltes Zertifikat nur ein Jahr Gültigkeit besitzt. Oftmals existiert in den Kundennetzwerken aber eine Zertifizierungsstelle, welche längerfristige Zertifikate erstellen kann. Alternativ kann man sich bei einer externen Zertifizierungsstelle ein Serverzertifikat erstellen lassen, die Kosten liegen bei ca. 100 US-Dollar und sollten kein Hinderungsgrund sein.
Erstellung eines Zertifikats mit Hilfe des Master-Keys
Nachdem ein Zertifikat erstellt ist, können wir den Schlüssel für die Datenbank generieren lassen. Bei diesem Schritt haben wir auch die Möglichkeit, den Verschlüsselungsalgorithmus auszuwählen.
USE Chair_TDE; GO CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_128 ENCRYPTION BY SERVER CERTIFICATE [BC-GLA-LAP-TEMP\SQL2012]; GO
Weitere mögliche Algorithmen sind AES_192, AES_256, TRIPLE_DES_3KEY. Möchte man später einmal die Verschlüsselungsstärke ändern, so steht auch der folgende Befehl zur Verfügung:
ALTER DATABASE ENCRYPTION KEY REGENERATE WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE [BC-GLA-LAP-TEMP\SQL2012]; GO
Dankenswerterweise weist der SQL Server nach Erstellung des Datenbankschlüssels darauf hin, dass man unbedingt eine Sicherung des Zertifikats und Schlüssels vornehmen sollte, da man sonst nicht in der Lage ist, eine Sicherung dieser Datenbank auf einem anderen Server wiederherzustellen.
BACKUP CERTIFICATE [BC-GLA-LAP-TEMP\SQL2012] TO FILE = 'C:\_Projekte\intern\_Blog_Bissantz\TDE\BC_GLA_LAP_TDE_Zertifikat' WITH PRIVATE KEY ( FILE = 'C:\_Projekte\intern\_Blog_Bissantz\TDE\SQLPrivateKeyFile', ENCRYPTION BY PASSWORD = 'Dies!Passwort$sollte#komplex&sein.2014' ); GO
Aktivierung der Verschlüsselung auf der gewünschten Zieldatenbank
Es fehlt jetzt nur noch die Aktivierung der Verschlüsselung auf der betroffenen Datenbank.
ALTER DATABASE Chair_TDE SET ENCRYPTION ON; GO
Geschafft. Ab sofort werden die Datenbank-Dateien und die übertragenden Daten verschlüsselt. Um dies zu prüfen bzw. sichtbar zu machen helfen ein paar Systemsichten weiter:
SELECT * FROM SYS.certificates
Diese Abfrage gibt Details zu den in der Master-Datenbank vorhanden Zertifikaten aus.
SELECT DEK.database_id ,DB.Name ,DEK.encryption_state ,DEK.encryptor_type ,DEK.key_algorithm ,DEK.key_length FROM SYS.dm_database_encryption_keys DEK LEFT JOIN SYS.databases DB ON DEK.database_id = DB.database_id GO
Diese Abfrage zeigt den Verschlüsselungsstatus und die Eigenschaften der Datenbanken an.
Abb. 3: Ergebnis des Verschlüsselungsstatus
Einschränkungen
Vorsicht sollte man unbedingt bei der nachträglichen Änderung der Verschlüsselung des Zertifikats walten lassen. Hat man sich im ersten Schritt dafür entschieden, das Zertifikat nur mit einem Passwort zu verschlüsseln und ändert dies nachträglich doch auf den SQL Service Master-Key (wie in diesem Blogbeitrag beschrieben), wird nach einem Neustart der Datenbank diese nicht mehr zugreifbar sein.
Administrative Tasks wie z. B. die Erstellung einer Sicherung sind während der initialen Verschlüsselung der Datenbank nicht möglich.
Wird TDE auf einer Datenbank aktiviert, so wird einmalig das Transaktionslog der Datenbank geleert und anschließend ebenfalls verschlüsselt.
Wird die zu verschlüsselnde Datenbank repliziert, so muss jede beteiligte Datenbank separat mit Hilfe von TDE verschlüsselt werden. Ein Automatismus existiert derzeit nicht.
Durch den Einsatz von TDE auf einer beliebigen Datenbank einer SQL-Server-Instanz wird automatisch auch die tempdb des Servers verschlüsselt. Dies kann also auch schlechtere Abfragezeiten für nicht-verschlüsselte Datenbank derselben Instanz zur Folge haben.
Fazit
Das gesamte Thema von Verschlüsselungen ist durchaus komplex und hat damit auch entsprechend viele Randbedingungen, die es zu prüfen gilt. Der hier aufgezeigte Weg ist lediglich eine Variante und darf niemals alleine als das Allheilmittel gegen unberechtigten Zugriff angesehen werden. Vielmehr betrachtet es einen konkreten Aspekt. Dafür ist die transparente Datenverschlüsselung schnell und einfach eingerichtet und bietet einen guten Schutz für die Datenbank-Dateien gegen Diebstahl. Auf der Demonstrationsdatenbank konnten wir keine gravierenden Performanceeinbußen feststellen, bei großen Datenbanken schätzen wir das Thema jedoch durchaus kritisch ein.
Weiterführende Links
- Verschlüsselung relationale Datenbank-Verbindung:
- SQL Server 2008R2: http://technet.microsoft.com/de-de/library/ms189067(v=sql.105).aspx
- SQL Server 2012: http://technet.microsoft.com/en-us/library/ms191192(v=sql.110).aspx
- Verschlüsselung Analysis Services Verbindung:
http://msdn.microsoft.com/de-de/library/dn140245.aspx - Relationale Datenbankverschlüsselung mit TDE:
http://technet.microsoft.com/en-us/library/bb934049(v=sql.110).aspx
