Datenschutz in der SAP HANA Datenbank mittels Data Masking und Data Anonymization
Endanwender können ohne Authentifizierung und Berechtigungsprüfung im SAP-ABAP-System direkt auf die Daten in der SAP HANA DB zugreifen, wie zum Beispiel auf Views in der SAP HANA DB.
Soll nun der Zugriff auf Daten aus Views nicht ungefiltert erfolgen, weil zum Beispiel nur Daten eines Werkes, eines Buchungskreises oder einer anderen organisatorischen Einheit eingesehen werden sollen, besteht die Möglichkeit einer Berechtigungsprüfung über analytische Privilegien. Die Unterschiede zwischen den einzelnen SAP HANA Privilegien wurden bereits im letzten Blog-Beitrag zu SAP HANA Privilegien aufgelistet.
Um die Daten bestimmter Spalten eines Views nicht im Klartext für jeden berechtigten Benutzer einsehbar zu machen, stehen zwei Mechanismen zur Verfügung: Daten-Anonymisierung und Daten-Maskierung.
Table of Contents
Daten-Anonymisierung
Die Daten-Anonymisierung ist Aufgabe der Entwickler:innen, welche die Views anlegen und die nicht die Aufgabe von Berechtigungsadministrator:innen. Bei der Anonymisierung wird zwischen folgenden zwei Arten unterschieden: K-Anonymität und Differential Privacy.
K-Anonymität
Bei dieser Form werden Details der Daten «unscharf» dargestellt. So wird z.B. bei einer Person mit Geburtsdatum am 01.12.1973 nur 1973 dargestellt und aus dem Wohnort Walldorf wird Wohnort Deutschland. Details, die nicht für jeden Endanwender einsehbar sein sollen, bleiben damit geschützt.
Differential Privacy
Differential Privacy, die zweite Variante der Anonymisierung, ersetzt Werte oder fügt fehlerhafte Daten ein. Statt des Namens einer Person, z.B. Anna wird „0c2187“ dargestellt. Diese Verfremdung der Daten erfolgt über einen SAP HANA DB eigenen Logarithmus.
Die Daten-Maskierung hingegen obliegt den Berechtigungsadministrator:innen, bzw. das Genehmigen des Zugriffs auf die Daten in klarer Form über Privilegien. Zunächst wird ein View mit einer Maskierung für die zu verbergende Spalte einer Tabelle angelegt. Die Tabelle heißt bspw. TEST00, die Spalte OBJECT_INCLUDE und liegt im Schema VDENEKE:
create view MASKIERT00 as select * from „VDENEKE“.“TEST00″ with MASK (OBJECT_INCLUDE USING ‚XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX‘);
Welche Art von Zeichen eingesetzt werden spielt keine Rolle. Allerdings muss die Zeichenlänge der Maskierung der Spaltenbreite entsprechen. Hat ein Benutzer nicht das Objekt Privileg für den View mit der Ausprägung «unmasked», so wird der Inhalt der Spalte OBJECT_INCLUDE mit Platzhaltern angezeigt:
SELECT TOP 1000 * FROM „VDENEKE“.“MASKIERT00”;
Nur der Ersteller des Views oder der Inhaber des Schemas, in dem der View gespeichert ist, kann das unmasked Objekt Privileg an einen Benutzer mit folgendem String vergeben:
grant UNMASKED on MASKIERT00 to <Endbenutzer>.
Die Zuweisung des unmasked Privilegs ist ausschließlich direkt an die Benutzer, jedoch nicht an eine Rolle möglich.
Das Ergebnis sieht wie folgt aus:
SELECT TOP 1000 * FROM „VDENEKE“.“MASKIERT00”;
Jetzt erscheint der Inhalt der Spalte OBJECT_INCLUDE im Klartext.
Views mit Abhängigkeit zu anderen Views
Eine weitere Möglichkeit beim Erstellen von Views ist das Verknüpfen mit anderen Views.
Benutzer 1 legt einen ersten View mit Maskierung an:
CREATE VIEW DEBITOR1 (Vorname,
Name,
MaskedCreditCard1) as SELECT
VorName,
Name,
CreditCard
From Table DEBITOREN with MASK (MaskedCreditCard1 using abc1234567890xxx);
Benutzer 2 legt einen zweiten View mit Maskierung an, basierend auf ersten View DEBITOR1:
Create VIEW DEBITOR2 (Vorname,
Name,
MaskedCreditCard2) as SELECT
Vorname,
Name,
MaskedCreditCard1
From DEBITOR1 with MASK (MaskedCreditCard2 USING xxx0987654321cba);
In dieser Konstellation werden nicht nur die Privilegien des Endbenutzers evaluiert, sondern auch die Privilegien der Inhaber der Views. Wenn ein Endbenutzer auf den zweiten View zugreift, ist die Maskierung, die angewendet wird, abhängig von den Privilegien des Inhabers des zweiten Views und des Endbenutzers. Der Endbenutzer hat das SELECT Privileg auf DEBITOR2 und der Ersteller von DEBITOR2 das SELECT Privileg mit «grant option» auf View DEBITOR1. Das Ergebnis der Abfrage vom Endbenutzer ist jetzt davon abhängig, wer das unmasked Privileg besitzt.
Fazit
Mit diesen Varianten stehen mehrere Möglichkeiten zur Verfügung, sensible Daten zu verbergen, entweder durch Daten-Anonymisierung oder Daten-Maskierung. Die Daten-Maskierungen sind dabei ohne zusätzliche Entwicklungen durch die Berechtigungsadministration zu realisieren.
Mit unserer Expertise und Workshops zu SAP HANA DB Rollen und Berechtigungen unterstützen wir Sie bei der Konzeption, Implementation oder Prüfung Ihrer SAP HANA Berechtigungen. Die Xiting Authorization Management Suite (XAMS) ermöglicht die Analyse, welche Benutzer über welche Privilegien verfügen und ob Segregation of Duties (SoD)-Verstöße vorliegen.
Erfahren Sie mehr über unsere Services im Bereich SAP HANA!
- HDI-Rollen in SAP HANA – Ist nun alles einfacher? - 9. Dezember 2022
- Analyse von Berechtigungsfehlern in SAP HANA - 9. August 2021
- Datenschutz in der SAP HANA Datenbank mittels Data Masking und Data Anonymization - 16. April 2021
