Daten sind das wertvollste Gut eines Unternehmens – doch mit großen Datenmengen kommt auch große Verantwortung. Datenschutz, Compliance und Zugriffskontrolle sind entscheidend, um sensible Informationen zu schützen und gesetzliche Vorgaben wie GDPR, HIPAA oder DSGVO einzuhalten.

Doch wie kann man sicherstellen, dass nur autorisierte Personen auf bestimmte Daten zugreifen dürfen? Und wie verhindert man, dass sensible Informationen in falsche Hände geraten?

Hier kommen zwei zentrale Techniken ins Spiel:

✅ Data Masking → Dynamisches Verbergen sensibler Daten, basierend auf Benutzerrechten
✅ Row-Level Security (RLS) → Zugriff auf bestimmte Datenzeilen basierend auf Nutzerrollen

Mit diesen Methoden kannst du sicherstellen, dass nur die richtigen Nutzer die richtigen Daten sehen – ein entscheidender Baustein für Datenschutz und Governance in Databricks.

In diesem Artikel erfährst du:
📌 Wie Data Masking funktioniert und welche Techniken es gibt
📌 Wie du Row-Level Security mit Unity Catalog umsetzt
📌 Best Practices für sicheres Datenmanagement in Databricks

Lass uns direkt starten! 🚀

Was ist Data Masking?

Data Masking ist eine Technik, mit der sensible Daten verfälscht oder verborgen werden, sodass sie für nicht autorisierte Benutzer unkenntlich sind. Dabei bleibt die Struktur der Daten erhalten, sodass Anwendungen weiterhin funktionieren, ohne dass die echten Werte preisgegeben werden.

🔹 Warum ist Data Masking wichtig?

✔ Schutz sensibler Informationen → Verhindert unbefugten Zugriff auf personenbezogene Daten (PII), Finanzdaten oder Geschäftsgeheimnisse
✔ Einhaltung von Compliance-Vorgaben → GDPR, HIPAA, DSGVO & Co. fordern oft, dass Daten anonymisiert oder geschützt werden
✔ Sicheres Arbeiten mit Test- und Entwicklungsumgebungen → Entwickler und Analysten können mit realistischen Daten arbeiten, ohne Zugriff auf echte Werte zu haben

🔹 Unterschied zwischen Data Masking & Verschlüsselung

👉 Kurz gesagt: Data Masking sorgt dafür, dass sensible Daten lesbar bleiben, aber nicht ihre echten Werte zeigen. Verschlüsselung schützt Daten vollständig, indem sie nur mit einem Schlüssel wiederhergestellt werden können.

🔹 Anwendungsfälle für Data Masking

📌 E-Commerce & Zahlungsdaten → Maskierung von Kreditkartennummern für Kundensupport-Teams
📌 Gesundheitswesen → Verbergen von Patientendaten für nicht autorisierte Mitarbeiter
📌 Finanz- & HR-Daten → Teilweise oder vollständige Maskierung von Gehaltsinformationen

Im nächsten Kapitel schauen wir uns verschiedene Techniken für Data Masking in Databricks an – inklusive dynamischem Masking, Hashing und Tokenisierung. 🚀

Techniken für Data Masking in Databricks

Data Masking sorgt dafür, dass sensible Daten nur für berechtigte Benutzer sichtbar sind. In Databricks gibt es mehrere Möglichkeiten, dies umzusetzen – von dynamischem Masking bis zur Nutzung von Masking-Funktionen mit Unity Catalog.

🔹 Dynamisches Masking mit SQL-Funktionen

Dynamisches Masking passt die angezeigten Daten basierend auf der Benutzerrolle an. Nicht autorisierte Nutzer sehen nur maskierte Werte, während autorisierte Nutzer die echten Daten sehen können.

📌 Beispiel: Teilweise Maskierung von E-Mail-Adressen

SELECT 
    user_id, 
    CASE 
        WHEN is_account_group_member('admins') THEN email 
        ELSE CONCAT(LEFT(email, 3), '****@****.com') 
    END AS masked_email
FROM users;

✅ Einfache Implementierung – direkt in SQL
✅ Daten bleiben intakt – keine Änderungen an der Originaltabelle

🔹 Masking mit Hashing & Tokenisierung

Bei dieser Technik werden die Daten durch irreversible Werte ersetzt, sodass sie anonymisiert bleiben.

📌 Beispiel: Hashing mit SHA2

SELECT user_id, SHA2(email, 256) AS masked_email FROM users;

📌 Beispiel: Tokenisierung mit Mapping-Tabelle

CREATE TABLE tokenized_users AS 
SELECT user_id, UUID() AS token FROM users;

🔹 Hashing → ideal für Vergleiche, ohne echte Daten offenzulegen
🔹 Tokenisierung → ersetzt Werte durch zufällige IDs, um Datenschutz zu gewährleisten

🔹 Masking mit Views & Unity Catalog

Mit Unity Catalog lassen sich zentral gesteuerte Masking-Richtlinien umsetzen. Dabei wird ein View erstellt, der je nach Benutzer die Daten unterschiedlich darstellt.

📌 Beispiel: Maskierter View für Kreditkartennummern

CREATE VIEW masked_transactions AS
SELECT 
    transaction_id, 
    user_id,
    CASE 
        WHEN is_account_group_member('finance_admin') THEN credit_card_number
        ELSE CONCAT('****-****-****-', RIGHT(credit_card_number, 4)) 
    END AS masked_credit_card
FROM transactions;

✅ Keine Änderungen an der Originaltabelle nötig
✅ Zentrale Verwaltung von Zugriffsbeschränkungen

🔹 Masking mit benutzerdefinierten Funktionen (UDFs) & Unity Catalog

Eine sichere und skalierbare Methode für Data Masking in Databricks ist die Nutzung von benutzerdefinierten Masking-Funktionen, die in Unity Catalog registriert werden.

📌 Erstellen einer Masking-Funktion in SQL

CREATE FUNCTION catalog.security.mask_credit_card(credit_card STRING) 
RETURNS STRING 
RETURN 
    CASE 
        WHEN is_account_group_member('finance_team') 
        THEN credit_card 
        ELSE CONCAT('****-****-****-', RIGHT(credit_card, 4)) 
    END;

🔹 Flexible Steuerung der Maskierung durch Gruppenmitgliedschaften
🔹 Benutzer erhalten nur SELECT-Berechtigungen, während Maskierung automatisch greift

Mit diesen Masking-Techniken kannst du sicherstellen, dass sensible Daten nur für berechtigte Nutzer sichtbar sind. Doch manchmal reicht es nicht aus, nur bestimmte Spalten zu maskieren – manchmal dürfen Nutzer auch nur auf bestimmte Datenzeilen zugreifen.

👉 Wie du das mit Row-Level Security in Databricks umsetzt, erfährst du im nächsten Kapitel! 🚀

Was ist Row-Level Security (RLS)?

Row-Level Security (RLS) ist eine Technik, mit der du steuern kannst, welche Datenzeilen ein Nutzer in einer Tabelle sehen darf. Während Data Masking verhindert, dass bestimmte Werte sichtbar sind, sorgt RLS dafür, dass bestimmte Zeilen für nicht autorisierte Nutzer gar nicht erst angezeigt werden.

🔹 Warum ist Row-Level Security wichtig?

✔ Granulare Zugriffskontrolle → Nutzer sehen nur die Daten, die für sie relevant sind
✔ Verbesserte Datensicherheit → Verhindert unbefugten Zugriff auf kritische Informationen
✔ Einhaltung von Compliance-Vorgaben → GDPR, HIPAA, DSGVO erfordern oft eine eingeschränkte Datennutzung
✔ Effiziente Performance → Kein Overhead durch Filtern in der Anwendung, sondern direkt in der Datenbank

🔹 Anwendungsfälle für Row-Level Security

📌 Unternehmensdaten → Ein Vertriebsmitarbeiter soll nur Kundendaten aus seiner Region sehen
📌 HR-Daten → Ein Manager darf nur Gehaltsinformationen seiner Abteilung abrufen
📌 Finanzberichte → Investoren sehen nur ihre eigenen Portfolios, nicht die anderer Kunden

🔹 Unterschied zwischen Row-Level Security & Column-Level Security

👉 Kurz gesagt: Row-Level Security beschränkt den Zugriff auf Datenzeilen, während Column-Level Security bestimmte Spaltenwerte ausblendet.

Im nächsten Kapitel zeige ich Dir, wie du Row-Level Security mit Unity Catalog in Databricks umsetzt! 🚀

Implementierung von Row-Level Security in Databricks

Row-Level Security (RLS) in Databricks kann mit Views, benutzerdefinierten Funktionen (UDFs) und Unity Catalog umgesetzt werden. Die wichtigste Methode ist die Filterung von Datenzeilen basierend auf der Gruppenzugehörigkeit eines Nutzers.

🔹 Umsetzung mit dynamischen Views

Eine der einfachsten Möglichkeiten, RLS zu implementieren, ist die Verwendung von dynamischen Views. Dabei wird überprüft, ob der aktuelle Nutzer zu einer bestimmten Gruppe gehört und die Ergebnisse entsprechend gefiltert.

📌 Beispiel: RLS für eine Vertriebsliste

CREATE VIEW sales_region_filtered AS
SELECT 
    customer_id, 
    customer_name, 
    region, 
    sales_amount 
FROM sales_data
WHERE region IN (
    CASE 
        WHEN is_account_group_member('sales_europe') THEN 'Europe'
        WHEN is_account_group_member('sales_asia') THEN 'Asia'
        WHEN is_account_group_member('sales_usa') THEN 'USA'
        ELSE NULL -- Nutzer ohne Berechtigung sehen keine Zeilen
    END
);

✅ Vorteil: Kein direkter Zugriff auf die Originaltabelle nötig, alle Nutzer greifen nur über den View zu
✅ Automatische Filterung der Daten je nach Benutzerrolle

🔹 Umsetzung mit benutzerdefinierten Funktionen (UDFs) in Unity Catalog

Eine skalierbare Alternative ist die Verwendung einer benutzerdefinierten Filterfunktion (UDF) in Unity Catalog. Diese Funktion kann dann in mehreren Tabellen wiederverwendet werden.

📌 Erstellen der RLS-Funktion

CREATE FUNCTION catalog.security.check_region_access(region STRING) 
RETURNS BOOLEAN 
RETURN 
    CASE 
        WHEN is_account_group_member('sales_europe') AND region = 'Europe' THEN TRUE
        WHEN is_account_group_member('sales_asia') AND region = 'Asia' THEN TRUE
        WHEN is_account_group_member('sales_usa') AND region = 'USA' THEN TRUE
        ELSE FALSE
    END;

✅ Vorteil: Zentrale RLS-Steuerung über Unity Catalog
✅ Skalierbar & wiederverwendbar für mehrere Tabellen

🔹 Umsetzung mit Policy Tables (Zugriffssteuerungstabellen)

Eine noch flexiblere Methode ist die Speicherung von Berechtigungen in einer separaten Policy-Tabelle.

📌 Schritt 1: Erstellen der Policy-Tabelle

CREATE TABLE access_policies (
    user STRING,
    region STRING
);

📌 Schritt 2: Befüllen mit Berechtigungen

INSERT INTO access_policies VALUES ('user1@databricks.com', 'Europe');
INSERT INTO access_policies VALUES ('user2@databricks.com', 'Asia');

📌 Schritt 3: Anwenden der Policy-Tabelle in einer Abfrage oder UDF

SELECT s.* 
FROM sales_data s
JOIN access_policies p ON s.region = p.region
WHERE p.user = current_user();

✅ Dynamisch & wartungsfreundlich – Berechtigungen können jederzeit angepasst werden
✅ Trennung von Daten und Sicherheitsregeln – mehr Flexibilität

Mit diesen Methoden kannst du sicherstellen, dass Nutzer nur die Daten sehen, die für sie bestimmt sind. Welche Methode die richtige ist, hängt von den Anforderungen deines Unternehmens ab:

📌 Für einfache Fälle → Dynamische Views sind oft ausreichend
📌 Für skalierbare Lösungen → UDFs in Unity Catalog bieten eine flexible Steuerung
📌 Für komplexe Berechtigungen → Policy-Tabellen ermöglichen maximale Flexibilität

Im nächsten Kapitel schauen wir uns die Best Practices für eine sichere und effiziente Implementierung von RLS in Databricks an. 🚀

Best Practices für Row-Level Security in Databricks

Die Implementierung von Row-Level Security (RLS) erfordert eine durchdachte Strategie, um Sicherheit, Performance und Wartbarkeit zu gewährleisten. Hier sind einige bewährte Best Practices, die du in deinen Databricks-Workflows berücksichtigen solltest.

🔹 Nutze Unity Catalog für zentrale Zugriffskontrolle

✅ Warum?
Unity Catalog ermöglicht eine zentrale Verwaltung von Berechtigungen auf Catalog-, Schema- und Tabellenebene. Das hilft dabei, Sicherheitsrichtlinien an einem Ort zu definieren, anstatt sie über mehrere Workspaces hinweg zu duplizieren.

📌 Beispiel: Zugriff auf einen Catalog nur für eine bestimmte Gruppe erlauben

GRANT USAGE ON CATALOG company_data TO `sales_team`;
GRANT USAGE ON SCHEMA sales TO `sales_team`;
GRANT SELECT ON TABLE sales_data TO `sales_team`;

🚀 Tipp: Nutze Datenmaskierung & RLS in Kombination, um ein ganzheitliches Sicherheitsmodell zu schaffen.

🔹 Verwende UDFs in Unity Catalog für eine skalierbare RLS-Implementierung

✅ Warum UDFs statt dynamischer Views?
Dynamische Views sind in einfachen Szenarien nützlich, haben jedoch Nachteile bei Skalierbarkeit und Wartung. Eine bessere Alternative ist die Nutzung von benutzerdefinierten Funktionen (UDFs) in Unity Catalog, da diese:

• Wiederverwendbar für mehrere Tabellen und Szenarien sind

• Bessere Performance bieten als verschachtelte Views

• Zentrale Verwaltung von Zugriffskontrollen ermöglichen

📌 Beispiel: UDF für eine flexible Row-Level Security

CREATE FUNCTION catalog.security.check_region_access(region STRING) 
RETURNS BOOLEAN 
RETURN 
    CASE 
        WHEN is_account_group_member('sales_europe') AND region = 'Europe' THEN TRUE
        WHEN is_account_group_member('sales_asia') AND region = 'Asia' THEN TRUE
        WHEN is_account_group_member('sales_usa') AND region = 'USA' THEN TRUE
        ELSE FALSE
    END;

✅ Vorteil: Flexible und skalierbare Lösung, die für mehrere Tabellen nutzbar ist

🚀 Tipp: Die UDF kann jederzeit erweitert werden, ohne bestehende Abfragen anpassen zu müssen!

🔹 Nutze Policy-Tabellen für komplexe Berechtigungen

✅ Warum?
Policy-Tabellen erlauben eine dynamische und leicht anpassbare Zugriffskontrolle, ohne den Code der Abfragen oder UDFs zu ändern.

📌 Beispiel: Zugriffsbeschränkung durch eine Policy-Tabelle

SELECT s.* 
FROM sales_data s
JOIN access_policies p ON s.region = p.region
WHERE p.user = current_user();

🚀 Tipp: Trenne Daten und Zugriffskontrolle, indem du Policy-Tabellen in einem separaten Schema speicherst.

🔹 Performance optimieren: RLS effizient umsetzen

❌ Vermeide:

• Nested Queries & Subqueries, die RLS-Abfragen verlangsamen

• Unnötige Joins, die Abfragen komplexer und langsamer machen

✅ Bessere Lösungen:

• RLS-Filter UDFs direkt auf die Tabellen anwenden, um Joins zu minimieren

• Delta Lake verwenden, um Zugriffsbeschränkungen direkt auf große Datensätze anzuwenden

🚀 Tipp: Teste die Performance von RLS-Abfragen mit EXPLAIN, um Engpässe frühzeitig zu erkennen.

🔹 Regelmäßige Audits & Monitoring

✅ Warum?
Regelmäßige Überprüfungen stellen sicher, dass die richtigen Nutzer Zugriff haben und keine Sicherheitslücken bestehen.

📌 Beispiel: Abfrage aller vergebenen Berechtigungen in Unity Catalog

SHOW GRANTS ON TABLE sales_data;

📌 Beispiel: Logging von Benutzerzugriffen

SELECT  *
FROM  system.access.audit
WHERE  
  service_name = "unityCatalog"  
  AND action_name = "getTable"  
  AND request_params.full_name_arg = 'sales_data';

🚀 Tipp: Automatisiere Audits mit SQL Alerts in Databricks, um Sicherheitsverletzungen sofort zu erkennen.

Row-Level Security ist ein mächtiges Werkzeug, um Datenzugriff granular zu steuern. Die Nutzung von UDFs in Unity Catalog ist die empfohlene Methode, da sie:

✔ Flexibler & skalierbarer als dynamische Views ist
✔ Zentral verwaltet & für mehrere Tabellen wiederverwendbar ist
✔ Performance-Vorteile durch direkte Filterung in Abfragen bietet

💡 Kurz gesagt: Nutze UDFs in Unity Catalog statt dynamischer Views, um eine performante und zukunftssichere RLS-Strategie in Databricks aufzubauen! 🚀

Was kommt als Nächstes?
Im nächsten Kapitel fassen wir die wichtigsten Erkenntnisse zusammen und geben einen Ausblick auf weitere Sicherheitsmaßnahmen in Databricks!

Fazit & Ausblick: Sichere Datenzugriffe mit Databricks gestalten

Die Implementierung von Row-Level Security (RLS) in Databricks ist ein essenzieller Bestandteil einer sicheren und skalierbaren Datenarchitektur. In diesem Artikel haben wir verschiedene Methoden betrachtet und die Verwendung von UDFs in Unity Catalog als beste Lösung hervorgehoben.

🔹 Die wichtigsten Erkenntnisse auf einen Blick

✔ Unity Catalog nutzen → Einheitliche Zugriffskontrolle für Daten und Sicherheitsrichtlinien
✔ UDFs für RLS bevorzugen → Flexibler, skalierbarer und besser wartbar als dynamische Views
✔ Policy-Tabellen verwenden → Komplexe Berechtigungen dynamisch und nachvollziehbar verwalten
✔ Performance-Optimierung berücksichtigen → RLS effizient umsetzen, um Abfragen nicht zu verlangsamen
✔ Regelmäßige Audits & Monitoring einführen → Sicherheit durch Protokollierung und Zugriffskontrollen gewährleisten

Mit diesen Best Practices kannst du Datensicherheit und Governance in Databricks auf Enterprise-Niveau heben.

🔹 Ausblick: Weitere Sicherheitsmaßnahmen in Databricks

Row-Level Security ist nur ein Baustein einer umfassenden Sicherheitsstrategie. Weitere wichtige Aspekte, die Unternehmen in Betracht ziehen sollten, sind:

📌 Datenmaskierung (Data Masking): Schutz sensibler Informationen, z. B. durch das Verbergen von Kundennamen oder Kreditkartennummern
📌 Column-Level Security (CLS): Kontrolle, welche Nutzer bestimmte Spalten einer Tabelle einsehen dürfen
📌 Audit-Logging & Anomalieerkennung: Automatische Überwachung von Abfrageverhalten und Erkennung unautorisierter Zugriffe
📌 Automatisierte Berechtigungsverwaltung: Dynamische Zuweisung von Berechtigungen anhand von Benutzerrollen und Geschäftsprozessen

In einem zukünftigen Artikel werden wir uns detailliert mit Datenmaskierung und Column-Level Security in Databricks befassen und zeigen, wie diese Mechanismen mit RLS kombiniert werden können.

🚀 Jetzt umsetzen!

Mit den hier vorgestellten Best Practices kannst du direkt loslegen und sichere, regelbasierte Datenzugriffe in Databricks implementieren.