Wie Microsoft mit dem SQL Server Business Intelligence auf die DSGVO einstimmt

Die EU hat ein neues Datenschutzrecht erarbeitet, die "EU-Datenschutzgrundverordnung". Diese ist seit dem Mai 2018 in Kraft und noch immer herrscht bei vielen Unternehmen und ihren Datenschutzbeauftragten Verunsicherung darüber, was von den neuen Regularien tatsächlich gefordert wird und wie sie sich konkret auf ihre Datenverarbeitungsprozesse auswirken werden. Insbesondere im Big Data und Business-Intelligence-Umfeld ergeben sich grundlegende Interessenkonflikte und weit verbreitete Paradigmen zur Datenhaltung und -analyse müssen möglicherweise hinterfragt werden.

Der folgende Artikel gibt einen Überblick über die grundlegenden Forderungen der DSGVO und die Pflichten, die sich daraus für Unternehmen und die Datenschutzbeauftragten ergeben und skizziert ein mögliches Vorgehen, um diesen Verpflichtungen gerecht zu werden. Darüber hinaus werden die Auswirkungen der Verordnung im Business-Intelligence-Kontext diskutiert und am Beispiel der Microsoft SQL Server Platform gezeigt, wie sich die Anforderungen der neuen EU-Richtlinie durch Features moderner Datenbank-Managementsysteme abdecken lassen.

Konzepte und Forderungen der DSGVO

Die im Mai 2016 in Kraft getretene EU-Datenschutz-Grundverordnung (DSGVO), international auch als EU General Data Protection Regulation (GDPR) bekannt, hat im Mai 2018 ihre volle Gültigkeit erlangt und ist damit rechtlich vollständig durchsetzbar geworden. Es vergingen mehrere Jahre, ehe sich die EU-Kommission, das EU-Parlament und der EU-Ministerrat Ende 2015 darauf einigen konnten, eine umfassende Reform zur Stärkung und Vereinheitlichung des Datenschutzes für alle Mitgliedstaaten der EU auf den Weg zu bringen. Viele Unternehmen nutzten die 2-jährige Übergangszeit bereits intensiv und investierten beträchtliche Aufwände, sich mit der neuen Rechtslage vertraut zu machen und ihre Datenverarbeitungsprozesse aus organisatorischer sowie technischer Perspektive an die neuen gesetzlichen Rahmenbedingungen anzupassen. Auch wenn diese gesetzlichen Rahmenbedingungen im Vergleich zum Bundesdatenschutzgesetz oftmals nicht gänzlich neu sind, so ergibt sich eine ganz neue Motivation für die Umsetzung durch den Anstieg der angekündigten Bußgelder, die bis zu 20 Millionen oder 4 % des weltweiten Jahresumsatzes betragen können.

Personenbezogene Daten

Aus der EU-Datenschutz-Grundverordnung ergeben sich eine Reihe von Anforderungen und Pflichten für Unternehmen, die personenbezogene Daten verarbeiten. Dabei gelten Daten als personenbezogen, sofern sie sich eindeutig einer natürlichen Person zuordnen lassen (z. B. Name, Anschrift, Telefonnummer). Dies umfasst aber ebenso Daten, die sich mittelbar zuordnen lassen und daher oftmals als personenbeziehbare Daten bezeichnet werden (z. B. IP-Adresse, KFZ-Kennzeichen). Einige Kategorien personenbezogener Daten (z.B. Daten zu rassischer/ethnischer Herkunft, politischen Meinungen, religiösen Überzeugungen, Gewerkschaftszugehörigkeiten, Gesundheit, sexueller Orientierung etc.) werden als besonders schützenswert hervorgehoben und ihre Verarbeitung außerhalb der in Artikel 9 beschriebenen Ausnahmefälle grundsätzlich untersagt.

Umsetzung der DSGVO

Ein erster Schritt zur Einhaltung der Verordnung ist die Identifizierung der im Unternehmen verarbeiteten personenbezogenen Daten und der zugehörigen Datenverarbeitungsprozesse und -systeme. Im Hinblick auf die neuen gesetzlichen Rahmenbedingungen müssen die identifizierten Prozesse ggf. adaptiert und neu definiert werden. Die weiteren Schritte befassen sich anschließend mit der Ergreifung von Maßnahmen für die korrekte Verwaltung und den Schutz der personenbezogenen Daten. Letztlich müssen auch interne Datenschutzvorschriften etabliert werden, um über die Einhaltung oder auch Nicht-Einhaltung der Verordnung adäquat berichten zu können.

Die wesentlichen aus der Verordnung abgeleiteten Pflichten, die es im Rahmen des zuvor beschriebenen Vorgehens zu berücksichtigen gibt, werden im Folgenden näher erläutert.

Die "Grundsätze für die Verarbeitung personenbezogener Daten" sind in Artikel 5 DSGVO wie folgt definiert:

1. Personenbezogene Daten müssen

a. […] in einer für die betroffene Person nachvollziehbaren Weise verarbeitet werden („Rechtmäßigkeit, Verarbeitung nach Treu und Glauben, Transparenz“);

b. für festgelegte, eindeutige und legitime Zwecke erhoben werden […] („Zweckbindung“);

c. […] auf das für die Zwecke der Verarbeitung notwendige Maß beschränkt sein („Datenminimierung“);

d. sachlich richtig und […] auf dem neuesten Stand sein; […] personenbezogene Daten, die im Hinblick auf die Zwecke ihrer Verarbeitung unrichtig sind, unverzüglich gelöscht oder berichtigt werden („Richtigkeit“);

e. in einer Form gespeichert werden, die die Identifizierung der betroffenen Personen nur so lange ermöglicht, wie es für die Zwecke, für die sie verarbeitet werden, erforderlich ist; […] („Speicherbegrenzung“);

f. in einer Weise verarbeitet werden, die eine angemessene Sicherheit der personenbezogenen Daten gewährleistet, einschließlich Schutz vor unbefugter oder unrechtmäßiger Verarbeitung und vor unbeabsichtigtem Verlust, unbeabsichtigter Zerstörung oder unbeabsichtigter Schädigung durch geeignete technische und organisatorische Maßnahmen („Integrität und Vertraulichkeit“);

2. Der Verantwortliche ist für die Einhaltung des Absatzes 1 verantwortlich und muss dessen Einhaltung nachweisen können („Rechenschaftspflicht“).

Dokumentationspflichten der DSGVO

Gemäß den in Artikel 5 definierten Grundsätzen für die Verarbeitung personenbezogener Daten müssen Unternehmen ihre datenverarbeitenden Prozesse kritisch analysieren und dokumentieren (Rechtmäßigkeit, Verarbeitung nach Treu und Glauben, Transparenz) und dabei für alle zu verarbeitenden personenbezogenen Daten hinterfragen, ob ein klarer Zweckbezug ausgewiesen werden kann (Zweckbindung) und die sachliche Richtigkeit der Daten für den Zweck zutrifft (Richtigkeit), ob die Daten eventuell in anonymisierter Form bereits den Zweck erfüllen und somit nicht länger als personenbezogene Daten deklariert werden müssen, ob die Daten in dem Umfang benötigt werden (Datenminimierung) und ob die Dauer der Speicherung entsprechend begründet werden kann (Speicherbegrenzung). Zusätzlich sind Maßnahmen zu ergreifen, um die Einhaltung der zuvor genannten Grundsätze jederzeit nachweisen zu können (Rechenschaftspflicht) - eine anspruchsvolle Aufgabe für alle Datenschutzbeauftragten.

Informations- und Auskunftspflichten

Neben der detaillierten Dokumentation dieser Überlegungen sind zudem betroffene Personengruppen über die Art und Weise der Speicherung und Verarbeitung ihrer Daten zu informieren und entsprechend "alle Informationen […], die sich auf die Verarbeitung beziehen, in präziser, transparenter, verständlicher und leicht zugänglicher Form in einer klaren und einfachen Sprache zu übermitteln" (Artikel 12). Diese Informationen sind ebenso auf Verlangen gemäß dem Auskunftsrecht betroffener Personen bereitzustellen (Artikel 15).

Pflichten zur Wahrung der Rechte betroffener Personen

Seit Mai 2018 müssen in der EU Unternehmen Prozesse vorhalten, die als Reaktion auf die Geltendmachung der in Kapitel 3 (Art. 12 -23) definierten Rechte betroffener Personen geeignet sind. Gemeint sind das Recht auf Berichtigung, das Recht auf Löschung, das Recht auf Einschränkung der Verarbeitung, das Recht auf Datenübertragbarkeit und das Widerspruchsrecht, die zu Anpassungen der im Unternehmen definierten und umgesetzten Datenverarbeitungsprozesse führen können. Insbesondere die Löschung von personenbezogenen Daten kann für die Datenschutzbeauftragten zu einer nicht zu unterschätzenden Herausforderung werden, da die Daten nicht nur primär aus den Datenbanken der verarbeitenden Systeme zu entfernen sind, sondern auch sekundär aus möglicherweise existierenden Backups, Log Files, existierenden Berichten.

Datensicherungspflichten

Sind die personenbezogenen Daten identifiziert und deren Verarbeitung unter Einhaltung der zuvor genannten Grundsätze definiert und dokumentiert (siehe hierzu auch Art. 30 Verzeichnis von Verarbeitungstätigkeiten), gilt es für die Datenschutzbeauftragten, diese Grundsätze nach Artikel 25 Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen durch "geeignete technische und organisatorische Maßnahmen […] wirksam umzusetzen" und insbesondere, gemäß des Grundsatzes der Integrität und Vertraulichkeit, "die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste im Zusammenhang mit der Verarbeitung auf Dauer sicherzustellen". Welche Maßnahmen im jeweiligen Kontext als "geeignet" bezeichnet werden können, ist nicht eindeutig spezifiziert und ist laut Artikel 25 abhängig von "der Technik, den Implementierungskosten und der Art des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere der mit der Verarbeitung verbundenen Risiken". Artikel 32 Sicherheit der Verarbeitung wird hierzu nur unwesentlich konkreter und fordert, die "Risiken zu berücksichtigen, die mit der Verarbeitung – insbesondere durch Vernichtung, Verlust oder Veränderung, ob unbeabsichtigt oder unrechtmäßig, oder unbefugte Offenlegung von beziehungsweise unbefugten Zugang zu personenbezogenen Daten, die übermittelt, gespeichert oder auf andere Weise verarbeitet wurden – verbunden sind". Explizit werden als mögliche geeignete Maßnahmen die Pseudonymisierung und die Verschlüsselung genannt. Die Bewertungen der Datenschutzgrundsätze und der jeweiligen Risiken bei der Verarbeitung personenbezogener Daten, die Wahl der damit verbundenen Schutzniveaus und der geplanten Abhilfemaßnahmen sind im Rahmen der in Artikel 35 geforderten Datenschutz-Folgenabschätzung zu betrachten und zu dokumentieren.

Rechenschaftspflichten und Meldepflichten

Kommt es zu Verstößen bzgl. des Schutzes personenbezogener Daten und ergibt sich daraus ein erhöhtes Risiko bezüglich der Rechte und Freiheiten natürlicher Personen, greift die in den Grundsätzen verankerte Rechenschaftspflicht sowie die in Artikel 33 geregelte Meldepflicht, wonach Unternehmen "unverzüglich und möglichst binnen 72 Stunden, nachdem […] die Verletzung bekannt wurde, diese der […] zuständigen Aufsichtsbehörde" melden müssen. "Verletzungen des Schutzes personenbezogener Daten einschließlich aller im Zusammenhang mit der Verletzung des Schutzes personenbezogener Daten stehenden Fakten, von deren Auswirkungen und der ergriffenen Abhilfemaßnahmen" sind zu dokumentieren und bereitzustellen. Dies umfasst unter anderem die "Beschreibung der Art der Verletzung des Schutzes personenbezogener Daten, soweit möglich mit Angabe der Kategorien und der ungefähren Zahl der betroffenen Personen, der betroffenen Kategorien und der ungefähren Zahl der betroffenen personenbezogenen Datensätze".

Auswirkungen der DSGVO auf Business Intelligence

Im Business-Intelligence-Umfeld können sich bei Betrachtung der Datenschutz-Grundverordnung erhebliche Konfliktpotenziale ergeben. Wird hier doch gerade versucht, durch den Einsatz von Data-Warehouse-Lösungen einen integrierten und zentralen Datenspeicher aufzubauen, der möglichst alle relevanten, teilweise bis weit in die Vergangenheit reichenden Daten langfristig vorhält und sich vielfältig auswerten lässt. Vor allem die Datenschutzgrundsätze zur Zweckbindung, zur Datenminimierung und zur Speicherbegrenzung können sich hierbei als problematisch herausstellen. In vielen Data-Warehouse- und Big-Data-Umgebungen gilt der Grundsatz "lieber zu viel, als zu wenig" und es werden Daten eher nach dem Grundsatz der Datenmaximierung als der Datenminimierung und teilweise ohne klaren Zweckbezug vorgehalten mit der Aussicht, dass diese Daten möglicherweise zukünftig Relevanz besitzen könnten und somit ein zukünftiger Zweckbezug hergestellt werden könnte.

Daten, die einmal in das Data Warehouse geladen wurden, werden in den seltensten Fällen wieder aus diesem gelöscht. Vielmehr werden Mechanismen eingesetzt, um Daten, die an Relevanz verloren haben, auszulagern und zu archivieren, um im Zweifelsfall auf sie zurückgreifen zu können. Stammdaten, beispielsweise Kunden-, Lieferanten- oder Mitarbeiterstammdaten, liegen oftmals in historisierter Form vor, um möglichst viele Auswertungsszenarien abzudecken.

Diese Paradigmen müssen nun nicht grundsätzlich hinterfragt werden, jedoch ist im Hinblick auf personenbezogene Daten besondere Vorsicht geboten.

Es gilt kritisch zu hinterfragen, ob personenbezogene Daten in dem jeweiligen Detaillierungsniveau vorgehalten werden müssen, um letztlich den Auswertungszwecken zu genügen. Meist werden diese Daten entlang unterschiedlicher Dimensionen oder Perspektiven aggregiert betrachtet und eine detaillierte Auswertung auf Basis von Einzelpersonen ist nicht zwingend erforderlich. Demnach kann in vielen Situationen durch Anwendung von Datenreduzierung und Anonymisierung der Personenbezug entfernt werden, sodass die Daten im Hinblick auf die DSGVO nicht mehr explizit zu berücksichtigen sind. Hierzu kann beispielsweise darauf verzichtet werden, personenbezogene Daten, wie Namen, Identifizierungsnummern, E-Mail-Adressen, Geburtsdatum, Adressen, etc. in das Data Warehouse zu übertragen und es kann sich darauf beschränkt werden, die zur Kategorisierung und Aggregation verwendeten charakterisierenden Merkmale, wie Alter oder Geburtsjahr, Wohnort, Kundengruppe, Berufsgruppe, etc. zu übernehmen.

Ist der Zweckbezug zur Verarbeitung personenbezogener Daten gegeben und eine Anonymisierung ausgeschlossen, sind der Umfang und die Verweildauer der Daten im Data Warehouse gemäß den Grundsätzen zur Datenminimierung und Speicherbegrenzung auf ein Mindestmaß zu beschränken und Vorkehrungen zu treffen, dass Daten nach der definierten Verweildauer wieder entfernt werden. Ebenso kann es für die Datenschutzbeauftragten ratsam sein, bereits vorab Vorkehrungen zur Wahrung der Rechte betroffener Personen zu treffen und beispielsweise ein Löschkonzept zu definieren und ggfl. entsprechende Prozeduren zu implementieren.

Letztlich sind für die personenbezogenen Daten die unterschiedlichen Schutzniveaus und die damit verbundenen Schutzmaßnahmen, wie Zugriffsberechtigungen, Pseudonymisierung und Verschlüsselung, zu betrachten. Welche Möglichkeiten von führenden Datenbanksystemen geboten werden, um die geforderten Schutzmaßnahmen datenbankseitig abzubilden, soll im Folgenden am Beispiel des Microsoft SQL Servers vorgestellt werden.

Umsetzung der DSGVO mit dem Microsoft SQL Server

Microsoft hat in den vergangenen Jahren das Angebot der mit dem SQL Server ausgelieferten Sicherheitsfunktionen stetig erweitert. So sind insbesondere mit der Veröffentlichung des SQL Server 2016 eine ganze Reihe innovativer Funktionen wie Always Encrypted, Dynamic Data Masking und Row-Level-Security zu den bestehenden Funktionen, wie Authentifizierung, Autorisierung, Transparent Data Encryption, gesicherte Datenbankverbindungen, SQL Server Audit und Policies, hinzugekommen.

Härtung

Bevor auf die einzelnen Features des Microsoft SQL Server eingegangen wird, sei an dieser Stelle darauf hingewiesen, dass eine sichere Datenbanklösung zunächst maßgeblich von den grundlegenden Konfigurationen des Betriebssystems und des Microsoft SQL Servers abhängt. Die Härtung von Betriebssystem und Datenbankmanagementsystem sollte demnach den ersten Schritt zur Schaffung einer sicheren Infrastruktur darstellen. Hierbei kann auf Best Practices (beispielsweise das von Microsoft veröffentlichte SQL_Server_2012_Security_Best_Practice_Whitepaper_Apr2012.docx) und Standards zurückgegriffen werden, um beispielsweise Rechte für Service Accounts zu minimieren, nicht benötigte Features bzw. Services abzuschalten, Patches einzuspielen, Ports zu konfigurieren und Richtlinien (Policies), z. B. Passwortrichtlinien, zu definieren.

Authentifizierung & Autorisierung

Eine der grundlegendsten Anforderungen der EU-DSGVO in Bezug auf die Sicherheit verarbeitender Systeme ist die Zugriffskontrolle. Im Microsoft SQL Server erfolgt die Zugriffskontrolle über die SQL Server-Authentifizierung, welche zwei Modi unterstützt. Zum einen ist dies die Windows- Authentifizierung, sodass die Authentifizierungsmechanismen des Windows Servers herangezogen werden und auf Windows User und Windows Gruppen zurückgegriffen werden kann. Hierbei bietet der Einsatz eines Active Directory erhebliche Vorteile im Sinne einer zentralisierten Verwaltung von Usern, Gruppen und Richtlinien. Zum anderen lassen sich im Mixed Mode zusätzlich zur Windows Authentifizierung dedizierte SQL Logins im SQL Server verwalten, die eine Authentifizierung über einen Benutzernamen und ein Passwort ermöglichen.

Die Autorisierung erfolgt über die den Logins und Usern im SQL Server zugewiesenen Berechtigungen auf Objektebene. Zur Vereinfachung bei der Verwaltung von Zugriffsrechten kann auf ein Rollenkonzept zurückgegriffen werden, um Berechtigungen mit serverweiten und datenbank-spezifischen Rollen zu kapseln. Die im SQL Server vordefinierten Rollen sowie benutzerdefinierte Rollen und Rechtezuweisungen auf Objektebene sollten Benutzern derart zugewiesen werden, dass ihnen lediglich die für die Ausübung ihrer Tätigkeiten entsprechenden minimalen Rechte zur Verfügung stehen (principle of least privilege).

Dynamic Data Masking

Dynamic Data Masking ist ein Feature, welches seit Erscheinen des SQL Server 2016 für alle Editionen zur Verfügung steht. Es erlaubt, den Lesezugriff auf Tabellenspalten mit sensiblen Daten weiter einzuschränken. Für privilegierte Benutzer mit der UNMASK-Berechtigung ist kein Unterschied erkennbar und sie erhalten weiterhin vollen Zugriff auf die Originaldaten. Für nicht-privilegierte Benutzer mit einer herkömmlichen SELECT-Berechtigung hingegen liefert die Datenbank die angefragten Daten lediglich in maskierter Form (z.B. "mxx.xxxxxxxxx@xxxxxxxxxx.de" statt "max.mustermann@mustermann.de") und die Benutzer erhalten keinen Einblick auf die sensiblen Daten. Die bei der Maskierung angewandten Muster sind zuvor über eine Maskierungsfunktion zu definieren.

Dynamic Data Masking unterstützt die in der Datenschutz-Grundverordnung explizit erwähnte Pseudonymisierung von sensiblen Daten. Das Feature findet im Data-Warehouse-Kontext häufig Verwendung, wenn Produktionsdaten für Entwicklungs- und Testzwecke herangezogen werden sollen, die sensiblen Daten Entwicklern und Testern jedoch vorenthalten werden und lediglich in pseudonymisierter Form angezeigt werden sollen.

Die Verwendbarkeit von Dynamic Data Masking zur Einschränkung des Zugriffs durch Endanwender eines Data Warehouses ist stark abhängig von der gewählten Architektur. Werden Abfragen von Endbenutzern direkt oder indirekt unter dem jeweiligen Benutzerkontext an die Datenbank gestellt (z. B. über Microsoft Power BI und Microsoft SQL Server Analysis Services im DirectQuery Modus), kann der Benutzerkontext entsprechend vom Microsoft SQL Server ausgewertet werden und das Feature zum Einsatz kommen. Werden die Daten hingegen von einer zwischengelagerten Applikation mit Hilfe eines dedizierten privilegierten Accounts unmaskiert geladen, verarbeitet und vorgehalten und werden Benutzeranfragen unmittelbar von der Applikation beantwortet, ohne auf die Datenbank zurückzugreifen (z. B. Microsoft SQL Server Analysis Services im In-Memory-Modus), so erweist sich das Sicherheitsfeature des Microsoft SQL Servers als zwecklos und es muss auf entsprechende Sicherheitskonzepte der jeweiligen Applikation zurückgegriffen werden.

Row-Level-Security

Ein weiteres Feature, das seit dem SQL Server 2016 mit allen Editionen genutzt werden kann, um den Zugriff auf sensible Daten weiter einzuschränken, ist Row-Level-Security. Hierbei lassen sich Berechtigungen auf Zeilenebene definieren, sodass Benutzer lediglich Zugriff auf die für sie relevanten Datensätze in einer Tabelle erhalten. Für die Umsetzung sind mit tSQL eine Funktion (CREATE FUNCTION) und eine Sicherheitsrichtlinie (CREATE SECURITY POLICY) zu erzeugen. Die Funktion beinhaltet die Filterlogik und definiert, anhand welcher Tabellenspalte die Tabelle, in welcher Art und Weise entsprechend des Benutzerkontexts der aktuellen Datenbankverbindung gefiltert werden soll. Die Sicherheitsrichtlinie bindet schließlich die Filterfunktion an die Tabelle und schränkt somit den Zugriff zeilenbasiert ein.

Row-Level-Security ist ein wertvolles Feature, um Zugriffsrechte datenbankseitig bis auf Zeilenebene definieren und kontrollieren zu können. Im Data-Warehouse-Kontext ist das Feature sinnvoll einsetzbar, solange die Zugriffe der Benutzer über eine Applikation (z. B. Microsoft Power BI und Microsoft SQL Server Analysis Services im DirectQuery Modus) tatsächlich gegen die Microsoft SQL Server Datenbank gerichtet sind und der aktuelle Benutzerkontext übergeben und bei der Bearbeitung der Abfrage ausgewertet werden kann. Werden die Benutzeranfragen hingegen nicht von der Datenbank selbst verarbeitet, sondern von einer zwischengelagerten Applikation (z. B. Microsoft SQL Server Analysis Services im In-Memory-Modus), die die Daten möglicherweise multi-dimensional aufbereitet und im Cache vorhält, so sind entsprechend auch die Zugriffskonzepte der entsprechenden Applikation zu berücksichtigen und es kann nicht auf die Row-Level-Security des SQL Servers vertraut werden.

Transport Layer Security

Neben der Zugriffskontrolle ist auch die Verschlüsselung von Daten eine explizit genannte Maßnahme, die zum Schutz der sensiblen Daten herangezogen werden kann. Im Hinblick auf die Sicherung der Kommunikationswege ist die Verschlüsselung von Datenbankverbindungen mit Transparent Layer Security ein gängiges Sicherheitsfeature, welches sich bei Unternehmen bereits seit einiger Zeit als Standard durchgesetzt hat bzw. haben sollte. Der Microsoft SQL Server unterstützt sichere Verbindungen über TLS 1.2 und hilft somit, das Risiko für unbefugten Zugriff (z. B. Man-in-the-Middle-Angriffe) auf sensible Daten während des Transports über eingehende oder ausgehende Datenbankverbindungen zu reduzieren. Die Nutzung von gesicherten Verbindungen kann über Konfiguration des SQL Servers (Einrichtung eines Zertifikats und Aktivierung des ForceEncryption Flags) sichergestellt und erzwungen werden.

Transparent Data Encryption

Während über TLS lediglich die Kommunikation verschlüsselt erfolgt, die Daten jedoch unverschlüsselt in der Datenbank vorgehalten werden, bietet das Feature Transparent Data Encryption (TDE) der Enterprise Edition die Möglichkeit, die Daten auf physischer Ebene zu verschlüsseln. Mit TDE wird das Risiko reduziert, dass Unbefugte Zugriff auf Datenbank-, Backup- oder Transaktionsprotokolldateien erhalten und eine Datenbank somit an anderer Stelle wiederherstellen können und folglich Zugang zu sensiblen Daten erhalten. Die Daten werden hierzu beim Schreiben auf den Datenträger verschlüsselt und beim Laden der Daten in den Hauptspeicher wieder entschlüsselt. Bei Aktivieren von TDE für eine Benutzerdatenbank gilt dies gleichermaßen auch für die tempdb Systemdatenbank. Im Hauptspeicher liegen die Daten letztlich wieder unverschlüsselt vor. Für auf die Datenbank zugreifende Applikationen ergibt sich kein Unterschied zu nicht-verschlüsselten Datenbanken.

Die Konfiguration von TDE beinhaltet im Wesentlichen das Erstellen eines Database Master Keys auf Basis des Service Master Keys, der bei der Installation der SQL Server-Instanz erzeugt wird, die Erzeugung eines Zertifikats mit Hilfe des Database Master Keys, die Erzeugung eines Database Encryption Keys unter Verwendung des Zertifikats und die Aktivierung der Verschlüsselung für zu schützende Datenbanken. Sorgfalt ist bei der Verwaltung des Zertifikats und dessen privatem Schlüssel geboten, um verschlüsselte Datenbanken und Backups bei potenziell erforderlichen Wartungsarbeiten wiederherstellen und entschlüsseln zu können.

Always Encrypted

Mit Always Encrypted wurde mit dem SQL Server 2016 (ab SQL Server 2016 SP1 für alle Editionen) ein weiteres innovatives Sicherheitsfeature veröffentlicht, das eine noch striktere Trennung zwischen fachlich privilegierten und technisch privilegierten Benutzern erlaubt und auf Spaltenebene angewendet werden kann. So wird verhindert, dass Benutzer, wie beispielsweise Datenbankadministratoren, die aus technischen und weniger aus fachlichen oder inhaltlichen Gründen umfangreiche Privilegien auf Datenbankebene erhalten, Zugriff auf unverschlüsselte sensible Daten erhalten. Die Ver- und Entschlüsselung von sensiblen Daten in Spalten mit aktiviertem Always Encrypted-Feature erfolgt dabei bereits über die von Applikationen verwendeten Always Encrypted-fähigen Datenbanktreiber. Der Datenbanktreiber sorgt für eine automatische Übersetzung der ursprünglichen Datenbankabfrage und verschlüsselt alle in der Abfrage vorkommenden Werte (z. B. Filter) der zu sichernden Spalten. Ebenso wird das Ergebnis der Datenbankabfrage wieder durch den Datenbanktreiber entschlüsselt und der Applikation bzw. dem privilegierten Endbenutzer zur Verfügung gestellt. Die Datenbank selbst und auch privilegierte Datenbankbenutzer sind somit lediglich für die korrekte Verarbeitung der verschlüsselten Daten verantwortlich und haben zu keinem Zeitpunkt Zugriff auf die entschlüsselten Daten.

Für die Konfiguration von Always Encrypted wird ein Zertifikat benötigt, welches zur Erzeugung eines Column Master Keys verwendet wird. Das Zertifikat wird anschließend auf den Zielsystemen installiert, von wo aus die Applikationen über den Datenbanktreiber auf die Datenbank zugreifen. Dies kann der PC des Endbenutzers sein, falls die Applikation lokal installiert ist. Andernfalls ist dies der Server, auf dem die Applikation betrieben wird. In der Datenbank wird der Column Master Key verwendet, um Column Encryption Keys zu erzeugen, die letztlich für die Einrichtung der Verschlüsselung einzelner Spalten herangezogen werden. Für die Verschlüsselung kann zwischen der deterministischen Verschlüsselung (gleiche Ausgangswerte führen zu gleichen verschlüsselten Werten) und der zufälligen Verschlüsselung (gleiche Ausgangswerte führen zu unterschiedlichen verschlüsselten Werten) gewählt werden. Beide Varianten haben Einschränkungen bzgl. der Abfragbarkeit der verschlüsselten Spalten zur Folge. Die zufällige Verschlüsselung stellt die sicherere Variante dar, verhindert jedoch unter anderem die Filterung, Gruppierung, Sortierung, Joins und Indexe auf Basis der verschlüsselten Spalten. Auch die deterministische Verschlüsselung führt zu Einschränkungen, erlaubt jedoch noch die Verwendung von auf Gleichheit beruhenden Filtern, Joins, Gruppierungen, Sortierungen und Indexe.

Ähnlich der Einschätzung zum Dynamic Data Masking und zur Row-Level-Security ist auch die Sinnhaftigkeit eines Einsatzes von Always Encrypted in einem Data-Warehouse-Szenario stark an die gewählte Architektur gebunden. Demnach ist der Einsatz sinnvoll, wenn Abfragen direkt oder indirekt über einen kompatiblen Datenbanktreiber an die Datenbank gerichtet werden und von dieser bearbeitet werden. Werden die Daten jedoch über eine nachgelagerte Applikation geladen, entschlüsselt und zwischengespeichert, so ist das Problem der Datenhaltung unverschlüsselter Daten nicht gelöst, sondern lediglich verschoben.

Always On

Neben der Vertraulichkeit und Integrität ist ein weiteres explizit gefordertes Schutzziel der DSGVO die Verfügbarkeit der personenbezogenen Daten. Einen grundlegenden Schutz vor Datenverlust und die Möglichkeit, Daten nach einem Ausfall zeitnah wiederherzustellen, bietet der Einsatz einer wohldefinierten Sicherungs- und Wiederherstellungsstrategie. Ein höherer Schutz im Sinne von Hochverfügbarkeitslösungen (High Availability) kann mit dem SQL Server zudem über die Features AlwaysOn-Verfügbarkeitsgruppen (AlwaysOn Availability Groups) oder AlwaysOn-Failoverclusterinstanzen (AlwaysOn Failover Cluster Instances) erzielt werden.

AlwaysOn-Verfügbarkeitsgruppen, nutzbar mit der Enterprise Edition, erlauben es, eine Failover- Umgebung auf Datenbankebene zu konfigurieren. Es können ein oder mehrere primäre Datenbanken einer AlwaysOn-Verfügbarkeitsgruppe hinzugefügt werden und diese bis zu 8-fach als sekundäre Datenbanken repliziert werden. Ein Failover erstreckt sich jeweils über alle Datenbanken einer AlwaysOn-Verfügbarkeitsgruppe. Je nach Wahl des Synchronisationsmodus (synchronous vs. asynchronous commit mode) und der davon abhängigen Failover-Strategie (Automatic, Planned Manual, Forced Manual) kann ein Datenverlustrisiko ausgeschlossen werden oder auch geringfügig bestehen bleiben. Die Wahl begründet sich dabei im Wesentlichen durch Performanceunterschiede bei der Synchronisation von primären und sekundären Datenbanken. Weitere Vorteile des Features liegen darin, dass sich sekundäre Datenbanken für Read-Only-Zugriffe oder für das Erstellen von Backups nutzen lassen und somit für Entlastung der primären Datenbanken sorgen.  

AlwaysOn-Failoverclusterinstanzen basieren auf der Windows Server Failover Clustering (WSFC) Technologie und bieten Failover-Funktionalität auf Instanzebene für die Editionen Standard und Enterprise. Die Failoverclusterinstanz wird auf mehreren WSFC-Knoten installiert, ist nach außen jedoch lediglich als einzelne Instanz sichtbar. Kommt es zum Ausfall des aktiven Knoten wird automatisch auf einen anderen WSFC-Knoten ausgewichen.

SQL Server Audit

SQL Server Audit ist ein mächtiges Features, welches die Überwachung von Ereignissen im SQL Server ermöglicht. Für einen SQL Server Audit lassen sich serverweite (für alle Editionen) oder datenbankweite (für alle Editionen ab SQL Server 2016 SP1, zuvor nur Enterprise Edition) Spezifikationen erstellen. Die Spezifikationen beschreiben, welche Aktionen für welche Datenbankobjekte überwacht werden sollen. Die Erstellung einer Spezifikation kann auf unterschiedlichem Detaillierungsgrad auf Basis von atomaren Aktionen und Datenbankobjekten oder auch vordefinierten Aktionsgruppen erfolgen. Die bei aktivierter Überwachung gesammelten Informationen können in den Windows Application Event Log, den Windows Security Event Log oder aber in eine dedizierte Audit-Datei geschrieben werden und anschließend analysiert werden. Für die Umsetzung der EU-DSGVO kann SQL Server Audit somit eine maßgebliche Rolle einnehmen, um beispielsweise Zugriffe auf personenbezogene Daten zu überwachen, und kann durch das Logging der bei der Konfiguration als relevant befundenen Ereignisse maßgeblich zur Einhaltung der Rechenschaftspflicht beitragen.

Fazit

Die in der Europäischen Union definierten Anforderungen an den Schutz personenbezogener Daten resultieren in einer Vielzahl von Pflichten für datenverarbeitende Unternehmen. Insbesondere im Hinblick auf Big- Data- und Data-Warehouse-Lösungen scheinen diese Herausforderungen auf den ersten Blick unüberwindbar. Dabei sind die grundlegenden Überlegungen keineswegs neu, jedoch ergibt sich durch die angekündigten drastisch erhöhten Bußgelder eine ganz neue Motivation für Unternehmen, diese auch tatsächlich umzusetzen. Für Data-Warehouse-Lösungen empfiehlt es sich, zunächst personenbezogene Daten innerhalb des Systems zu identifizieren und gemäß den Grundsätzen für die Verarbeitung personenbezogener Daten zu prüfen, ob diese Daten letztlich wirklich in der angedachten Art und Weise verarbeitet werden müssen. Hierbei sollte vor allem ein klarer Zweckbezug darstellbar sein. Datenreduktionen und Anonymisierungen können helfen, den Personenbezug aus den Daten zu entfernen und somit dem Geltungsbereich der DSGVO zu entkommen. Ist die Verarbeitung personenbezogener Daten unvermeidlich, sind Maßnahmen zu definieren und umzusetzen, um den Schutz dieser Daten gewährleisten und nachweisen zu können. Moderne Datenbankmanagementsysteme, wie der Microsoft SQL Server, bieten eine Vielzahl von Funktionen, um Zugriffe auf Daten zu kontrollieren, Daten und Kommunikationswege zu verschlüsseln und eine hohe Verfügbarkeit zu garantieren. Die DSGVO macht keine konkreten Vorgaben, welche Schutzmaßnahmen in welchem Kontext zwingend erforderlich sind und fordert lediglich, geeignete Maßnahmen entsprechend des Schutzniveaus personenbezogener Daten zu treffen. Die Wahl und das Zusammenspiel der "geeigneten" Sicherheitsfunktionen ist dabei im Einzelfall zu entscheiden und oft auch abhängig von weiteren Faktoren, wie der Data-Warehouse- Architektur, funktionellen Limitationen und der Performance.