Suchen...
Generic filters
Exact matches only
Search in title
Search in excerpt
Search in content

Anonymisierung von kundenspezifischen Daten

In letzter Zeit kommt es immer wieder zu großen Diskussionen bezüglich der Weitergabe von persönlichen Daten und Verletzungen von Datenschutzbestimmungen. Vor allem in unserer Branche werden Geheimhaltungsvereinbarungen immer strenger und der Umgang mit Kundendaten ist kritischer denn je.
Typischerweise erhalten wir Daten von Interessenten oder Kunden, um daraus mithilfe des DeltaMaster Modeler ein Demo-Datenmodell zu erstellen. Wenn das fertige Demomodell präsentiert wird, dürfen dabei in der Regel keine kundenspezifischen Bezeichnungen oder tatsächliche Werte verwendet werden: es gilt, die Daten zu anonymisieren.
Aus diesem Grund muss das Vorkommen dieser Informationen an folgenden Stellen geprüft werden:

1. DeltaMaster Modeler
2. Microsoft SQL Server
3. Microsoft Analysis Services
4. DeltaMaster Analysesitzung

Der folgende Beitrag zeigt, auf welche konkreten Stellen man bei der Anonymisierung achten muss.

DeltaMaster Modeler

Anmeldedialog

Beim Start der Analysesitzung von DeltaMaster Modeler öffnet sich der Dialog zur Anmeldung an die relationale Datenbank. Bereits hier ist zu beachten, dass der Server und die relationale Datenbank keine kundenspezifischen Bezeichnungen enthalten.

Überprüfung des Anmeldedialogs
Abb. 1: Überprüfung des Anmeldedialogs

Innerhalb der Analysesitzung gilt es an verschiedenen Stellen auf die anonymisierte Verwendung von Parametern und Bezeichnungen zu achten.

Ordner „Configuration“

Bericht „Parameter“

Hier müssen die folgenden Bezeichnungen hinsichtlich kundenspezifischer Informationen geprüft und ggf. anonymisiert werden:

  • Model Name, da die Bezeichnung des Model Name im weiteren Verlauf in der OLAP Datenbank unter Datenquellen (DataSource) und Datenquellensichten (DataSource View) eingesehen werden kann.
  • OLAP Server
  • OLAP Database
  • Writeback table Database

Überprüfung der Parametereinstellungen
Abb. 2: Überprüfung der Parametereinstellungen

Ordner „Model“

Berichte „Dimensions“, „Levels“, „Level Source Columns“ und „Level Attribute”

Alle Informationen, die kundenspezifische Hinweise geben könnten, gilt es zu ändern. Dies betrifft in der Regel die Bezeichnungen von:

  • Dimensionen und All-Elementen
  • Ebenen und zugehörigen Attributen
  • Quelltabellen bzw. -views inkl. deren Spalten
  • Cubes
  • MeasureGroups und den zugehörigen Measures

Überprüfung der Modeleinstellungen am Beispiel der Ebenen
Abb. 3: Überprüfung der Modeleinstellungen am Beispiel der Ebenen

Überprüfung der Modeleinstellungen am Beispiel der MeasureGroups
Abb. 4: Überprüfung der Modeleinstellungen am Beispiel der MeasureGroups

Überprüfung der Modeleinstellungen am Beispiel der Measures
Abb. 5: Überprüfung der Modeleinstellungen am Beispiel der Measures

Bericht „MeasGrp Info“

Um später auch den SQL-Durchgriff bedenkenlos zeigen zu können, werden auch Spalten- und Infobezeichnungen geändert.

Überprüfung der Spaltenbezeichnungen im SQL-Durchgriff
Abb. 6: Überprüfung der Spaltenbezeichnungen im SQL-Durchgriff

Ordner „Advanced Modeling“

Additional Hierarchy

Einträge in den Additional Hierarchies und deren Ebenen müssen ebenfalls überprüft werden, beispielsweise die Branchenbezeichnung.

Überprüfung der erweiterten Modeleinstellungen
Abb. 7: Überprüfung der erweiterten Modeleinstellungen

Microsoft SQL Server

Strukturen

Um einen Blick auf die Daten zu werfen, betrachten wir unser Demomodell Chair. Für die Wiederherstellung von relationalen Datenbanken gibt es die Dateien mit Endung mdf und ldf. Auch diese können Hinweise auf kundenspezifische Informationen enthalten.

Dateinamen bei der Wiederherstellung relationaler Datenbanken
Abb. 8: Dateinamen bei der Wiederherstellung relationaler Datenbanken

Stammdaten

Die Bezeichnungen der Dimensionselemente müssen verfälscht werden. Dabei reicht es, die Einträge in der Tabelle T_DIM_XXX umzubenennen, wenn anschließend kein Transform_All ausgeführt werden muss.

Bewegungsdaten

Im Blogbeitrag „Für Präsentationszwecke: Daten kräftig durchmischen“ (http://crew.bissantz.de/updatetablewithrandomfactor) wird beschrieben, wie Bewegungsdaten verfälscht werden ohne den Zusammenhang zu verlieren. Diese Prozedur kann noch erweitert werden, um die Veränderung von mehreren Spalten (Bsp. 4 Kennzahlenspalten) gleichzeitig zu ermöglichen. Mit folgendem Statement ist das möglich:

Zu beachten ist hierbei, dass alle ausgewählten Spalten mit dem gleichen Faktor multipliziert werden.

Microsoft Analysis Services

Auch in der OLAP Datenbank sind die Namen von Datenquelle, Datenquellensicht, Cube, Measuregroups, Dimensionen und Kennzahlen zu prüfen.

Überprüfung der Einstellungen in Microsoft Analysis Service am Beispiel der Datenquelleneigenschaften
Abb. 9: Überprüfung der Einstellungen in Microsoft Analysis Service am Beispiel der Datenquelleneigenschaften

Zudem müssen die Rollen und möglicherweise die mittels Berechnungen per MDX erzeugten Dimensionselemente und Kennzahlen geprüft werden.

Überprüfung von Struktur und Rollen
Abb. 10: Überprüfung von Struktur und Rollen

In der Datenquellensicht sieht man den Modellnamen. Dieser wurde wie oben beschrieben, im DeltaMaster Modeler definiert.

Überprüfung der Datenquelle
Abb. 11: Überprüfung der Datenquelle

DeltaMaster Analysesitzung

Ist bereits eine Analysesitzung vorhanden, werden diese und die darin enthaltenen Ordner, Cockpits und Berichte, Berechnete Elemente und Kennzahlen umbenannt. Mithilfe des Modellbrowsers erhält man unter Modell einen schnellen Überblick über Dimensionen und Analysewerte. Übersetzungen sind unter Alias Sets definiert.

Überprüfung mittels Modellbrowser
Abb. 12: Überprüfung mittels Modellbrowser