Data Masking in Vertica

Data Masking in Vertica ermöglicht es Analysten, mit echten Datenstrukturen zu arbeiten, während Werte verborgen werden, die niemals im Klartext zugänglich sein sollten. Vertica ist eine leistungsstarke analytische Datenbank, die häufig für BI-Dashboards, Kundenanalysen, ML-Feature-Stores und Ad-hoc-Erkundungen großer, spaltenorientierter Datensätze eingesetzt wird. Diese Flexibilität ist für Unternehmen wertvoll, bedeutet aber auch, dass regulierte Felder wie Kartennummern, nationale Identifikationsnummern und medizinische Attribute leicht in Abfragen, Exporten oder Trainingsdatensätzen auftauchen können, wenn keine Schutzschicht angewendet wird.

Der Versuch, dies ausschließlich mit manuellen Berechtigungen, kopierten Tabellen oder handgeschriebenen SQL-Views zu lösen, wird schnell mühsam. Schemata ändern sich, neue Projektionen erscheinen, ETL-Jobs erzeugen abgeleitete Tabellen, und plötzlich ist niemand mehr sicher, welche Spalte tatsächlich sicher offengelegt werden darf. Anstatt jeder einzelnen Abfrage hinterherzujagen, benötigen Teams eine Maskierungsschicht, die automatisch für jede Vertica-Workload funktioniert.

Data Masking durch DataSunrise bietet Vertica-Anwendern genau diese Schicht. DataSunrise sitzt zwischen Vertica und den Client-Tools, erkennt sensible Felder und schreibt Abfrageergebnisse in Echtzeit so um, dass vertrauliche Werte je nach Richtlinie verborgen, tokenisiert oder teilweise angezeigt werden. Vertica kann so weiterhin seine Stärken bei schneller Analyse ausspielen, während Maskierungslogik, Prüfprotokolle und Compliance-Regeln in einer separaten, dedizierten Kontrollinstanz verwaltet werden.

Warum Vertica eine dedizierte Maskierungsschicht benötigt

Die Architektur von Vertica macht es gleichzeitig leistungsstark und komplex. Daten werden in spaltenorientierten ROS-Containern gespeichert, aktuelle Änderungen liegen im WOS, und Projektionen bieten mehrere physische Layouts für dieselbe logische Tabelle, wie in der Vertica-Architekturdokumentation beschrieben. Dieses Design ist ideal für Performance, macht es jedoch schwierig, Fragen wie „Wo genau befinden sich Kundenzahlungsdaten?“ oder „Welche Workloads greifen heute auf PHI zu?“ zu beantworten.

Typische Herausforderungen umfassen:

• Breite analytische Tabellen, die Dutzende von Attributen (einschließlich PII und PHI) in einer einzigen Struktur bündeln.
• Mehrere Projektionen, die sensible Spalten physisch über den Cluster replizieren.
• Geteilte Cluster, die gleichzeitig von BI-Tools, ETL, Notebooks und ML-Frameworks genutzt werden.
• Ad-hoc SQL von Power-Usern und Data Scientists, die kuratierte Berichtsschichten umgehen.
• Verstreute Protokolle, die es erschweren, nachzuvollziehen, wer wann welche Daten einsehen konnte.

Die rollenbasierte Zugriffskontrolle (RBAC) von Vertica steuert, wer sich verbinden kann und welche Objekte abgefragt werden dürfen. Sie erkennt jedoch nicht, ob eine Abfrage Kartennummern exportiert, HR- und CRM-Daten unsicher verknüpft oder eine Nicht-Produktionsumgebung mit Live-Kundendaten füllt. Um diese Lücken zu schließen, setzen Organisationen externe Maskierungs- und Richtlinien-Engines ein, die Sensitivität von Spalten und Benutzerkontexte verstehen.

Wie DataSunrise Data Masking in Vertica bereitstellt

DataSunrise fungiert als transparenter Proxy vor Vertica. BI-Tools, SQL-Clients, Scheduler und Data-Science-Plattformen verbinden sich mit DataSunrise, anstatt direkt mit Vertica zu sprechen. Für jede Abfrage analysiert DataSunrise das SQL, erkennt sensible Spalten, bewertet Maskierungsrichtlinien und gibt entweder die Abfrage unverändert weiter oder schreibt das Ergebnis so um, dass vertrauliche Werte die Datenbank niemals ungeschützt verlassen.

Im Hintergrund kombiniert diese Maskierungs-Engine mehrere Fähigkeiten:

• Erkennung sensibler Daten, um Spalten mit PII, PHI oder finanziellen Identifikatoren zu identifizieren.
• Dynamische Datenmaskierung, die Ergebnisdaten in Echtzeit je nach Benutzer-, Anwendungs- oder Netzwerk-Kontext ändert.
• Statische Datenmaskierung zur Erzeugung sicherer Nicht-Produktionsdatensätze.
• Prüfprotokollierung, die jede maskierte Abfrage als Compliance-Nachweis dokumentiert.

Die folgenden Screenshots zeigen eine typische Vertica-Maskierungskonfiguration: Definition einer Maskierungsregel, Auswahl der zu schützenden Spalten und Verifikation, dass Abfragen korrekt maskiert und protokolliert werden.

Definition einer Vertica-Maskierungsregel

Der erste Schritt besteht darin, eine Maskierungsregel anzulegen und sie mit der entsprechenden Vertica-Instanz zu verknüpfen. Im untenstehenden Beispiel zielt die Regel mit dem Namen Vertica_Masking auf eine Vertica-Datenbank ab, die über Port 5433 erreichbar ist. Die Regel legt auch fest, was bei einer Maskierung passiert – hier wird jedes Maskierungsereignis sowohl im DataSunrise-Audit-Store als auch im externen Syslog protokolliert, was die Integration in SIEM-Plattformen erleichtert.

In diesem Schritt definieren Sie das übergeordnete Verhalten:

• Für welche Vertica-Instanzen die Regel gilt.
• Ob Maskierungsereignisse protokolliert, übersprungen oder an externe Systeme weitergeleitet werden sollen.
• Beliebige globale Filter, z. B. Beschränkung der Regel auf Produktionsumgebungen.

Diese Trennung erlaubt es, eine logische „Vertica_Masking“-Richtlinie zu verwalten, auch wenn später weitere Knoten oder Cluster hinzugefügt werden. Die Maskierungslogik lebt in DataSunrise, nicht in den Vertica-Schemas.

Auswahl von Spalten und Bedingungen für die Maskierung

Sobald die Regel vorhanden ist, wählen Sie aus, welche Vertica-Spalten maskiert und unter welchen Bedingungen dies geschehen soll. DataSunrise kann Spaltenlisten direkt aus den Entdeckungsergebnissen importieren, so dass Administratoren diese nicht manuell pflegen müssen.

Maskierungsfunktionen lassen sich pro Spalte anpassen. Kartennummern zeigen beispielsweise nur die letzten vier Ziffern, Telefonnummern können die Landesvorwahl verlieren und Namen können vollständig ersetzt oder auf Initialen verkürzt werden. Das genaue Verhalten richtet sich nach internen Sicherheitsrichtlinien und den definierten Maskierungsprofilen in DataSunrise.

Eine typische Abfrage, ausgeführt von einem SQL-Client oder Notebook, könnte so aussehen:

SELECT
    id,
    full_name,
    SUBSTR(email, 1, 5) AS email_prefix,
    credit_card,
    phone
FROM customers_sensitive;

Ohne Maskierung würde diese Abfrage echte Kundennamen, Kartennummern und Telefonnummern zurückliefern. Mit aktivierter Regel sehen nicht privilegierte Nutzer pseudonymisierte Werte, während der Rest des Ergebnisdatensatzes unverändert bleibt.

Auditierung maskierter Abfragen in Vertica

Maskierung allein reicht für Regulierungs-konformität nicht aus. Organisationen müssen auch nachweisen, dass Maskierung konsequent angewendet wurde. DataSunrise protokolliert jede Abfrage, die Maskierung ausgelöst hat, inklusive Informationen über Benutzer, Anwendung, Regelname und Ausführungszeit. Diese Aufzeichnungen unterstützen Audits gemäß Vorschriften wie DSGVO, HIPAA und SOX.

Im Audit-Console können Sie:

• Nach Vertica-Regel, Benutzer oder Anwendung filtern, um Vorfälle zu untersuchen.
• Protokolle an SIEM- oder GRC-Plattformen exportieren.
• Maskierungsereignisse mit Warnungen aus der Datenbank-Aktivitätsüberwachung korrelieren.

Da alle Abfragen über dieselbe Gateway-Instanz laufen, erhalten Compliance-Teams eine einheitliche, normalisierte Prüfspur, anstatt mehrere Vertica-Systemtabellen zusammenfügen zu müssen.

Häufige Vertica-Maskierungsszenarien

Data Masking in Vertica wird in vielen operativen und analytischen Szenarien eingesetzt. Die folgende Tabelle fasst typische Anwendungsfälle und die übliche Verwendung von DataSunrise-Maskierungskontrollen zusammen.

Fazit

Richtig umgesetzt erlaubt Data Masking in Vertica Organisationen, die Plattform weiterhin als Hochgeschwindigkeits-Analyse-Engine zu verwenden, während das Risiko der Offenlegung sensibler Informationen drastisch reduziert wird. Indem Maskierungslogik, Entdeckung und Auditierung an DataSunrise ausgelagert werden, ersetzen Teams anfällige manuelle Lösungen durch konsistenten, automatisierten Schutz.

Ob für BI-Self-Service, ML-Workloads oder die Vorbereitung auf regulatorische Prüfungen – ein dediziertes Maskierungsgateway gibt Vertica die Absicherung, die es benötigt, ohne den Datenzugriff zu verlangsamen.