„Nein, ich möchte keine sensiblen Daten und schon gar keine Gehaltsdaten in der Microsoft Cloud wissen!“ war eine Aufgabenstellung eines Auftraggebers bei der Initialisierung eines Power BI Berichts, „Ich traue Microsoft nicht und habe Angst vor einer Datenpanne!“.
Das war die Ausgangslage, die im Widerspruch zur Operativen stand: „Ich brauche aber schon die Identifizierung der Mitarbeiter im Bericht“. Gleichzeitig möchte man aber auch Daten vor anderen Mitarbeitern, die denselben Bericht nutzen verstecken („Aber bitte nicht für alle Berichtsnutzer!“)
Das sind drei verschiedene Ansprüche an ein und denselben Bericht:
(1) Keine Klarnamen in der Cloud und somit im Dataset (Auftraggeber)
(2) Notwendigkeit die Mitarbeiter im Bericht aber identifizieren zu können: „Ich benötige aber den Klarnamen“ (Berichtsowner)
(3) Aber bitte nicht für alle Berichtsnutzer und bitte – alles in einem Bericht
Ok! Das ist einmal eine Herausforderung! Sie vereinigt im PBI-Standard nicht zu realisierende Anforderungen:
- Klarnamen zeigen – auch wenn im Dataset keine Klarnamen enthalten sind
- Einen Bericht so generieren, das ein und dieselbe Berichtsseite im GLEICHEN Bericht nach Rolle mal einen Mitarbeiternamen zeigt oder eben nicht
Warum geht das nicht im Standard? Mal abgesehen von der Anforderung kann PowerBI zwar Rollen verwalten und Berichte nach einem Zeilenfilter einer Rolle zeigen oder vorenthalten: User 1: Sieht nur die Mitarbeiter „Sales“, User 2 sieht nur die Mitarbeiter „Adminstrative“ und Power User 3 sieht ungefiltert „Alle“). Passt aber hier nicht! PowerBI hat (noch) keinen Seitenfilter, so dass je nach Rolle „Berichtsseiten“ einmal in Klarschrift dem Power User und eine andere „entschärfte“ dem „normalen“ User gezeigt werden.
Ich habe für dieses Szenario dann keine Out-Of-The-Box Lösung entwickelt, sondern eine Lösung gefunden, die alle Anforderungen vereint.
Zunächst einmal das Ergebnis als Screenshot: (Achtung NICHT interaktiv!)
„HR-Manager“
Sieht die Mitarbeiter Daten in Klarschrift
„Business-Controller“ -> Gleiche Berichtsseite (Werte, Strukturen)
Keine Identifizierung der einzelnen Mitabeiter
Schauen Sie hin! Links sind die Mitarbeiter-Namen und Personalnummern für den Power-User „hr-manager“ sichtbar. Rechts für den normalen User „business-controller“ nicht zu identifizieren.
Wie geht das?
(1) Wir nehmen die erste Anforderung: Keine Klarnamen in der Microsoft Cloud! Das bedeutet, dass die Namen der Mitarbeiter und die Personalnummern ausschließlich verschlüsselt im Dataset vorliegen dürfen. Das bedeutet, dass die Daten im Vorsystem verschlüsselt werden müssen!
(2) Wir benötigen eine Entschlüsselung der Daten, die von der Rolle oder des Usernamen abhängen, die mal entschlüsselt und dann eben nicht. 🙂 Dazu benutzen wir einen „measure“ der die Entschlüsselung vornimmt, wenn der usaer berechtigt ist – oder eben nicht.
Mmmmh … und wie geht das beispielsweise?
<jetzt wird es technisch>
Technisch betrachtet benötigt man einen Verschlüsselungsalgorithmus im Vorsystem und seinen identischen Gegenpart im Folgesystem. Ich habe mit bei der Verschlüsselung nicht allzu viel Mühe gemacht und benutze eine einfache aber solide „Cäsar“-Verschlüsselungstechnik mit ein paar zusätzlichen Sicherheitsmerkmalen. Im Prinzip funktioniert das so: Ich verwandele zunächst den Klarnamen des Mitarbeiters in eine Ascii-Zeichenfolge (so wird bspw. aus René ein Rene). Das hat Praktikabilitätsgründe damit Problematiken aus dem Weg gegangen wird, die durch unterschiedliche Codepages und Zeichensatz-Formate in den Datentöpfen entstehen können. Anschließend nehme ich mit einem einfachen vierstelligen Code eine zeichenweise Versetzung vor, schiebe an verschiedenen Stellen Zufallswerte. Die Entschlüsselung nehme ich dann in einem measure im Bericht selber vor („live“-Dekodierung).
Blöd wäre – was niemals auszuschließen ist – , das ein Mitarbeiter seinen eigenen Datensatz identifiziert und somit in der Lage ist Rückschlüsse auf die Kodierung vornehmen kann. Um das auszuschließen habe ich noch einen zusätzlichen fixen und einen variablen Key integriert. Der fixe zusätzliche Key (der am Mitarbeiter hängt) sorgt dafür, dass identische Zeichen im Klarnamen nicht zu identischen Zeichen führen. Der variable Key ändert die Verschlüsselung komplett mit jedem Update des Berichts. Ich denke das ist schon sehr sicher! 🙂
<und jetzt geht es wieder untechnisch weiter>
Ok … der Kenner wird nun sagen. Wenn die Dekodierung im Dataset (im „semantischen Modell“ enthalten ist) kann doch jeder mit technischem Zugriff auf den Bericht (also ein Adminstrator) den Dekodierungsmeasure finden und damit die Daten entschlüsseln. Stimmt!
An dieserStelle gilt es:
* Das Dataset schützen – keinen Download ermöglichen – Keine Verlinkung in andere Modelle gestatten (ok … geklärt!)
* Und/Oder … dem Admin vertrauen (vermutlich hat er ohnehin indirekten Zugriff auf Datenbanken und sensible Daten) oder in der Fachabteilung selbst die Administration vornehmen
Benötigen Sie Unterstützung bei Ihren Berichten oder sind unsicher, wie Sie Ihre fachliche Anforderung mit Business Intelligence umsetzen können?
