vorheriger Artikel
In Teil 1 und Teil 2 dieser Blogserie haben wir das Thema Datensicherheit in Datenplattformen dargestellt, sowie eine High-Level-Architektur und die Eignung von
Exasol herausgearbeitet. Im letzten Teil wird es nun um die Protegrity-Plattform im Detail und das Zusammenspiel mit Exasol gehen.
Die Protegrity-Plattform hat den Anspruch, einen weitreichenden Schutz der Daten entlang verschiedener Applikationen und Datenspeicher End2End zu realisieren:
Quelle: Protegrity 09/2021
Durch einen zentralen „Policy Server“ (ESA – Enterprise Security Administrator) werden die verschiedenen Schutzmechanismen (Policies-Tokenisierung, Verschlüsselung, Data Masking oder auch Anonymisierung) mit Benutzergruppen, Datenelementen und Datenspeichern verknüpft und so eine Vielzahl von Datenprotektoren konfiguriert.
D. h., für eine Vielzahl von Datentechnologien wie z. B.
- Datenbanken,
- Filesysteme,
- APIs
und weitere werden zentral User, Usergruppen, Policies etc. festgelegt. Gleichfalls werden hier auch zentral Log-Informationen zum Datenzugriff gesammelt und aufbereitet.
Für eine Nutzung der Kombination Exasol und Protegrity sind also neben den notwendigen Lizenzen auch folgende Schritte notwendig bzw. sollen hier kurz skizziert werden, siehe u. a. hier:
1. Installation Exasol und Protegrity
Beide Softwarelösungen werden als (Software) Appliance ausgeliefert, sodass sich die Installation in der Regel darauf beschränkt, Passwörter für User und OS-Konfigurationen vorzunehmen. Hierbei spielt das Thema Netzwerk eine zentrale Rolle, um einerseits die Erreichbarkeit der Exasol und der ESA zu gewährleisten und andererseits die Kommunikationen zwischen der Datenbank und der Protegrity-Lösung sicherzustellen. Für eine erste Teststellung und erste Schritte lassen sich auch beide Softwarelösungen ohne Probleme auf kleinen virtuellen Maschinen (wie z. B. einem Laptop) installieren. Für einen ausgeprägten Produktionsbetrieb empfiehlt sich allerdings eine gründliche Planung im Hinblick auf Backups und Hochverfügbarkeitsszenarien. Hierbei richtet sich das Sizing eines Exasol-Clusters und auch der ESA-Instanz nach dem Datenvolumen, der User-Anzahl und den Auditierungsanforderungen.
2. Installation Protegrity-Plugin auf dem Exasol-Cluster
Für die Nutzung der Protegrity-Lösung innerhalb von Exasol ist die Installation eines sogenannten Plugins notwendig, was die sichere und verschlüsselte Kommunikation zwischen Exasol und Protegrity gewährleistet. Hierbei werden Konfigurationen/Policies aus der ESA abgerufen sowie Log-Daten an diese versendet. Zu beachten ist, dass für eine Verschlüsselung, Maskierung etc. keine aktive Verbindung zwischen Exasol und Protegrity vorhanden sein muss – für den Versand von Log-Daten allerdings schon. Eine Plugin-Installation ist hierbei ein einfacher Upload eines entsprechenden Archivs via Exasol-Administrationskonsole. Dieses Plugin wird via XML-RPC installiert, konfiguriert (Upload Zertifikate und ESA-Konfiguration), gestartet und gestoppt.
3. Konfiguration Protegrity über ein ESA-Webfrontend:
a) Exasol-Datastore: Hier wird die Exasol als Datastore „bekannt“ gemacht (IP-Adressen der Knoten).
b) Rollen und User-Quellen: Konfiguration der Datenquelle für User und Rollen, die bei der Ver- und Entschlüsselung relevant sind. Hierbei kann es sich um ein File, eine Datenbank (diverse Datenbanken werden als Quelle unterstützt), Active Directory oder LDAP handeln. Bei den Usern handelt es sich hierbei um die gleichen User, wie sie später auf der Datenbank verwendet werden. Hier kann man allerdings im Folgenden auch Defaultverhalten für unbekannte User festlegen, was z. B. dazu führt, dass die Zahl der User in der Datenbank deutlich höher sein kann und innerhalb der ESA nur die User gepflegt/administriert werden müssen, die tatsächlich ent- und/oder verschlüsseln dürfen, während unbekannte User mit einem Defaultverhalten „bedient“ werden.
Rollen dienen dazu, das Verhalten beim Schutz der Daten auf Ebene von Gruppen zu realisieren und zu administrieren. So werden beim folgenden Beispiel die User „JOHN“ und „SYS“ der Gruppe der Business Analysten zugeordnet, während die Gruppe Fallback gegenwärtig keine „Member“ hat. An dieser Stelle werden Rollen auch Datenquellen und Policies zugeordnet. Konkret bedeutet dies z. B.:
Rolle | Member | Datastores | Policies |
BusinessAnalyst | JOHN, SYS | Exasol | DataSecurity |
Fallback | - | Exasol | DataSecurity |
c) Data Elements und Masks: In diesem Kontext wird für unterschiedliche Datenelemente die jeweilige „Behandlung“ aus Security-Sicht festgelegt:
Handelt es sich um einen strukturierten Datastore (Datenbank, Hive, API, …) oder einen unstrukturierten Store (Filesystem, …)?
Welcher Verschleierungsalgorithmus soll angewendet werden (Tokenization, 3DES, AES-256 und weitere)?
Welche Parameter möchte ich Protegrity bei Verschlüsselung/Verschleierung mitgeben? Welche Stellen sollen erhalten bleiben, welche sollen verschleiert werden etc.? Ein Erhalt der ersten 2-3 Stellen wäre z. B. bei der Postleitzahl ein sinnvolles Szenario, um allen Datenusern GDPR-konforme Informationen zukommen zu lassen.
Protegrity liefert hier eine Vielzahl von Einstellungsmöglichkeiten. Wir werden im Folgenden aber ausschließlich ein Dataelement „AlphaNumerisch“ verwenden, was wie folgt definiert ist:
Es sollen also alphanumerische Datenelemente mit einem Tokenizer verschleiert werden. Hierbei wollen wir jeweils das vollständige Attribut sowie dessen Länge des Attributs verschleiern. Auch hier zeigt sich eine große Stärke der Protegrity-Software, die eine ganze Reihe von Datentypen unterstützt:
Dies erlaubt einen „einfachen“ Einbau der Protegrity-Software, da auf diese Weise Datentypen trotz Verschleierung erhalten bleiben können, sodass Applikationen auf diesen Daten eben keine Spezialbehandlung von verschleierten Elementen umsetzen müssen.
d) Policies und Permissions: In einem letzten Schritt werden noch sogenannte Policies und Permissions gepflegt, die festlegen, wie Datenelemente, Rollen und Datastores zusammenspielen und welche Berechtigungen Rollen im Hinblick auf Datenelemente besitzen. Zusätzlich wird an dieser Stelle auch die Policy „deployed“ bzw. an die Exasol oder einen anderen Datenspeicher „ausgeliefert“. Es wird hier sozusagen festgelegt, wie das Verhalten der Datensicherheit in bestimmten Konstellationen aussehen soll:
Die Rolle Business Analyst darf in Bezug auf das Datenelement Protect und Unprotect aufrufen. Fehlgeschlagene Nutzungen von (Un-)Protect sollen geloggt werden.
Die Fallback-Rolle ist dahingehend so gestaltet, dass hier das Datenelement nur „Protected“ zurückgeliefert wird.
4. Verknüpfung Exasol mit ESA:
Nachdem die Policies in der ESA konfiguriert worden sind, ist es beim Einsatz innerhalb der Exasol noch notwendig, dass je Datenelement entsprechende UDfs implementiert und für die User der Datenbank nutzbar gemacht werden. Das folgende Skript soll eine solche Umsetzung anhand des Datenelements „AlphaNumerisch“ verdeutlichen:
Man sieht, dass die Verwendung von Protegrity rein mit Skripten und der Anwendung von UDFs in SQL vonstattengeht. Für den End User JOHN gestaltet sich die Anwendung genauso einfach: 
Spannend wird es, wenn ein User HANS, mit den entsprechenden Execute-Rechten ausgestattet, versucht, Daten zu ent- bzw. zu verschlüsseln:
Im ersten Fall (Verschlüsselung) gibt es eine Fehlermeldung, während im zweiten Fall einfach der verschlüsselte Wert zurückgeliefert wird.
Letztlich bietet Protegrity eine Vielzahl von möglichen „Verhaltensweisen“, die analog zu Rollen- und Rechte-Diskussionen innerhalb einer Datenbank entsprechend besprochen und letztlich definiert werden müssen. Der aus unserer Sicht wichtigste Punkt ist hierbei, dass es mit Protegrity sehr einfach ist, einen solchen Schutz der Daten feingranular umzusetzen. Das heißt, nicht nur einzelne Datenbankattribute werden jeweils separat behandelbar (über die Definition von z. B. Datenelement für E-Mail, Telefonnummer, Name, Geburtsdatum, Kreditkartennummer, …), sondern auch verschiedene User-Gruppen können unterschiedlich behandelt werden.
Natürlich wird eine solche Tokenisierung nicht umsonst geschehen, bzw. dies bedeutet ggf. einen Overhead für bestimmte ETL-Workloads. Der folgende Screenshot zeigt exemplarisch einen Performancetest, der als Information dient, jedoch nicht als repräsentativ angesehen werden kann:
Zu beachten ist hierbei:
a) Der Test wurde auf einem unserer b.telligent Laptops durchgeführt, auf dem neben Virtual Box, der Exasol VM und der ESA VM noch DBeaver, Word, Outlook und Teams geöffnet waren. Das heißt, in einem realen Produktionsbetrieb mit einem echten Exasol-Cluster (z. B. 5 Knoten mit 4 Kernen) kann hier durchaus ein Faktor 20 drin sein (also ist statt 1m16s für die Verschlüsselung eines Attributs und 10.000.000 Datensätzen eher von weniger als 10 Sekunden Overhead auszugehen).
b) Die Tokenisierung von Daten/Attributen findet nur bei Ablage der Daten statt, sodass hier die Performance für 10 Millionen Datensätze als sehr gut anzusehen ist, denn auch hier werden nicht fortwährend alle Sätze neu geschrieben.
c) Auch die Entschlüsselung findet in der Regel nicht fortwährend statt, sondern nur für ausgewählte Auswertungen und ETL-Prozesse, sodass auch hier der Overhead gut zu vernachlässigen ist.
Logischer Datenfluss / Nutzung von Potegrity
Zum Abschluss noch ein paar Gedanken zur Nutzung von Protegrity in ETL Prozessen und zur Einführung in bestehende DWH-Lösungen. Die Verwendung von Protegrity in ETL und Reporting gestaltet sich sehr einfach:
a) Verschlüsseln aller Attribute zum Zeitpunkt des Ladens
b) Entschlüsseln einzelner Attribute nur bei Bedarf (Zugriff oder ETL Logik, die die Daten in Rohform benötigt) und
c) Speicherung ausschließlich von verschlüsselten / verschleierten Attributen, sodass die vollständige Kontrolle dieser Daten Protegrity obliegt.
Als Projektschritte für die Umsetzung von granularem Datenschutz innerhalb eines bestehenden DWHs bieten sich folgende Schritte an:
Hierbei handelt es sich um eine Umsetzungsskizze. In der Realität sind ggf. noch parallele Umsetzungsstreams oder auch eine breitere Einführung der Protegrity-Lösung mitzuplanen.
Zusammenfassung
In dieser Blog-Serie haben wir Protegrity und das Zusammenspiel mit der Exasol-Datenbank beschrieben. Hierbei war es uns wichtig, eine Datenschutzlösung im DWH-Kontext zu skizzieren und Einblicke in eine solche Lösung zu geben. Wichtig ist hierbei, dass die Dimensionen Performanz, Verfügbarkeit und Sicherheit z. B. durch ein Zusammenspiel zwischen der Protegrity-Lösung und der Exasol-Datenbank gewährleistet werden können, wobei der Schutz von sensiblen Daten zentral gesteuert werden kann.
Tiefere architektonische und technische Diskussionen führen wir natürlich sehr gerne. Komm gerne auf uns zu, bevor Du eine eigene Lösung entwickelst!
Rückrufservice