Gerade BI-Landschaften bieten eine hohe Datenverfügbarkeit fürs Business. Die Komplexität der Systeme, ihre historisch gewachsenen Strukturen und ihre Kritikalität als zentrale Informationspools für die Unternehmen machen den Umgang mit dem Thema Datenschutz nicht gerade einfach.
Im Rahmen des Datenschutzes ist es in jedem Fall sinnvoll, die zu schützenden Daten voneinander zu unterscheiden. Zunächst lassen sich Kunden-, Mitarbeiter- und unternehmenskritische Daten einfach voneinander trennen. Geht der Datenschutz in eine weitere Granularitätsstufe, sind etwa besondere Arten personenbezogener Daten auszudifferenzieren.
Das Datenschutzgesetz befasst sich ausschließlich mit personenbezogenen Daten, nicht mit den mindestens ebenso wichtigen kritischen Daten, die das Know-how vieler Unternehmen ausmachen. Da den Gesetzgeber weder die technische Landschaft noch hierarchische Strukturen in den Unternehmen kümmern, ist die Erfüllung eben dieser gesetzlichen Vorgaben nicht immer einfach.
Ein Beispiel hierfür sind etwa die Verbindungsdaten (Call Detail Records: CDR) der Telekommunikationsbranche: Der Datensatz über ein Telefonat von München nach Warschau enthält nicht nur die Nummer des Anrufers und die des Angerufenen sowie die Dauer des Gespräches, sondern eine Vielzahl weiterer Informationen wie beispielsweise die Laufstrecke des Gespräches oder die Kennung des Mobiltelefons.
So umfasst solch ein Datensatz deutlich mehr Informationen als zur Abrechnung des Gespräches unbedingt vonnöten. Technisch aber sind alle diese Angaben notwendig und dürfen auch erhoben werden. Bei einer Auswertung aber, etwa zum Zwecke der Diensteoptimierung, müssen die Kundendaten im ersten Teil des CDR anonymisiert werden.
3 Sicherheitsebenen: Technik, Prozesse und Organisation
An diesem Beispiel lässt sich die Funktionsweise von "operativem Datenschutz" gut verfolgen. Auf den drei Ebenen der Technik, der Prozesse und der Organisation müssen die einzelnen Zahnräder so gestellt sein, dass sie optimal ineinandergreifen, um ein sinnvolles und gesetzeskonformes Handeln zu gewährleisten.
So muss die Technik in der Lage sein, die Anonymisierung der Kundendaten durchzuführen und darf auf dieselben nur Berechtigten Zugriff gewähren. In einem weiteren Prozess muss wiederum die Vergabe dieser Berechtigungen in regelmäßigen Intervallen geprüft werden. Gleichzeitig muss die Organisation sicherstellen, dass das Vieraugenprinzip für eben diese Vergabe und die Verantwortlichkeit geregelt ist.
Ein Data Warehouse (DWH) bezieht stets auch Daten aus Quellen, die in verschiedenen fachlichen Kontexten für Analysen verwendet werden sollen. Damit die gespeicherten Informationen datenschutzkonform verwendet werden können, lässt sich durch eine geeignete Kombination von Datenmodellierung, Berechtigungskonzept und Datenimportregeln eine Lösung schaffen, die keine Analysebedarfe verhindert.
Mögliche Ansätze hierzu umfassen etwa die logische oder physikalische Trennung von kundenbezogenen Daten und Unternehmensdaten, die Kontrolle des Zugriffs auf kundenbezogene Daten sowie das Aufsplitten der Daten beim Import in kunden- und unternehmensbezogene Daten.
Regelmäßig werden die kundenbezogenen Daten im DWH für Analysen wie etwa Kampagenenselektionen, Erfolgsanalysen von Tarifen und Produkten oder die Suche nach zusätzlichen Vertriebspotenzialen verwendet. Damit diese wichtigen Analysen nicht durch die Anforderungen des Datenschutzes unmöglich gemacht werden, ist eine saubere Trennung der Kundendaten von ihren - für die Analysen relevanten - Nebendaten vorzunehmen.
Datenmodellierung und Zugriffsberechtigungen im Data Warehouse
Dies erfolgt durch die Bildung eines durch die Datenmodellierung und die Zugriffsberechtigungen abgeschlossenen Kundendatenpools im Data Warehouse (Restricted Area). Diese Daten sind mit den anderen, offenen Bereichen des Data Warehouse über anonyme Schlüssel verbunden, so dass übergreifende Analysen weiter möglich sind, ohne dass ein Anwender auf einen konkreten Kunden zurück schließen kann.
Technische (Datenmodellierung, Anonymisierungen) und organisatorische (Berechtigungskonzepte) Maßnahmen reichen alleine nicht aus, um ein rechtskonformes Data Warehouse aufzusetzen. Gerade Power User, die eigene Analysen auf den Informationen des Data Warehouse frei aufsetzen, benötigen Transparenz über die Verwendungszwecke der verfügbaren Daten. Hierzu sollte ein Datenfeldkatalog erstellt werden, der zu jedem Datenattribut im Data Warehouse Auskunft über dessen Herkunft (Quellsystem) und damit auch den Verwendungszweck, für den es erhoben wurde, gibt.
Ein solcher Datenfeldkatalog bringt als sogenannte Paperware in der Praxis keinen Nutzen. Vielmehr sollten die verfügbaren Möglichkeiten der Analysetools genutzt werden. So kann der Datenfeldkatalog einfach in das semantische Datenmodell integriert werden und ist damit in der Datenzugriffsschicht des Power Users (z.B. im Universum von Business Objects oder im Transformer Model von Cognos) verfügbar.
Der Anwender kann so gezielt die "richtigen" Daten für seine Analyse heraussuchen. Durch die Erweiterung der Metadaten um datenschutzrelevante Informationen in der Analyseplattform ist sichergestellt, dass Anwender ihre Analysen auf Basis rechtskonformer Daten aufbauen.
Um ein DWH stets im Einklang mit dem Gesetz zu betreiben, braucht es einen Prozess, der auch bei Änderungen an dieser Gesetzeslage greift. Schon durch die Novellen des Bundesdatenschutzgesetzes (BDSG) 2009 hat sich vielfach gezeigt, dass der Prozess, Informationen aus der neuen Gesetzeslage an den richtigen Stellen im Unternehmen zu verankern, nicht überall reibungslos funktionierte. So sind etwa IT-Dienstleister auf ihre Vertragspartner zugegangen mit der Bitte, den geänderten Paragraphen 11 BDSG (Outsourcing) auf ihre Verträge anzuwenden; eigentlich hätte der Prozess genau andersherum verlaufen sollen.
Konsequenzen der Gesetzesänderung zum Arbeitnehmerdatenschutz einschätzen
Ein Ausblick auf die anstehende Änderung des BDSG § 32a ff. (Arbeitnehmerdatenschutz) mag ein gutes Beispiel für die Hol- und Bringschuld innerhalb der Unternehmen sein: Hier wie sonst reicht es nicht, wenn der betriebliche Datenschutzbeauftragte die Gesetzesänderung in das Intranet stellt, den CIO darüber informiert und sich auf der sicheren Seite wähnt.
Er sollte vielmehr in der Lage sein, die Konsequenzen der Gesetzesänderung für das DWH soweit abzuschätzen, dass er die betroffenen Applikations- und fachlich Verantwortlichen informiert. Im Sinne einer ITIL/ISO-konformen Organisation sollte der Datenschutzbeauftragte wie ein Anforderungssteller im DWH-Changeboard agieren und dafür Sorge tragen, dass die von ihm zu verantwortenden Datenschutzbelange nicht nur berücksichtigt, sondern auch umgesetzt werden.
Datenschutz und DWH sind keine Gegensätze. Der Gesetzgeber will nicht die freien Analysemöglichkeiten des DWH einschränken, sie wohl aber auf ein datenschutzkonformes Maß beschränken. Ein intelligent aufgebautes, gut gepflegtes und sauber strukturiertes DWH erfüllt sowohl die Anforderungen des Datenschutzes wie es auch weiterhin als unverzichtbare Quelle für alle Arten von Anfragen und Recherchen über die gesamte Informationslandschaft des Unternehmens dient.
Heiko Gronwald, Senior Manager, Steria Mummert Consulting
Robert Hilgers, Principal Consultant, Steria Mummert Consulting