Unity Catalog Data Governance: Security, Lineage und Audit

Die meisten Teams führen Unity Catalog wegen des einheitlichen Namespace ein. Sie bleiben wegen der Governance. Row-Level-Security, Column-Masking, system-level Audit-Logs und automatische Data-Lineage sind alle eingebaut — aber keines davon ist Zero-Config. Hier ist, was tatsächlich aufgesetzt werden muss und wie.

TL;DR

• Three-Level-Namespace: catalog.schema.table mit hierarchischen Permissions
• Row Filters als SQL-Functions auf Tabellen für Row-Level-Security
• Column Masking transparent über Functions, die Group-Membership prüfen
• Tags als Basis für Policy-driven Governance über Tabellen, Spalten, Schemas
• System Tables (system.access.audit, system.access.table_lineage) für Compliance-Auswertungen — DSGVO-relevant

Das Unity-Catalog-Security-Modell

Unity Catalog (UC) nutzt einen Three-Level-Namespace: catalog.schema.table. Permissions sind hierarchisch — USE CATALOG auf einem Catalog erlaubt implizit Schema- und Table-Navigation, aber keinen Daten-Zugriff. Du brauchst immer separat SELECT auf Table-Ebene.

-- Spark SQL (Unity Catalog dialect)
-- Grant read access to a table
GRANT USE CATALOG ON CATALOG analytics TO `data-analysts`;
GRANT USE SCHEMA ON SCHEMA analytics.silver TO `data-analysts`;
GRANT SELECT ON TABLE analytics.silver.customer_events TO `data-analysts`;

-- Or at schema level (covers all current + future tables)
GRANT SELECT ON SCHEMA analytics.silver TO `data-analysts`;

Die zweite Form (Schema-Level-Grant) ist für die meisten Teams bevorzugt — sie vermeidet ständiges Re-Granting, wenn neue Tabellen hinzukommen.

Row-Level-Security mit Row Filters

Row Filters lassen dich einschränken, welche Zeilen ein:e User:in oder Group sieht, ohne Tabellen zu duplizieren. Sie sind als SQL-Functions implementiert, die an eine Tabelle gehängt werden.

-- Step 1: Create the filter function
CREATE OR REPLACE FUNCTION analytics.governance.region_filter(region_col STRING)
RETURNS BOOLEAN
RETURN IS_ACCOUNT_GROUP_MEMBER('emea-analysts') AND region_col = 'EMEA'
    OR NOT IS_ACCOUNT_GROUP_MEMBER('emea-analysts');

-- Step 2: Apply the filter to a table
ALTER TABLE analytics.silver.sales
SET ROW FILTER analytics.governance.region_filter ON (sales_region);

Jetzt sehen EMEA-Analyst:innen nur EMEA-Zeilen. Alle anderen sehen alle Zeilen. Der Filter wird auf Engine-Ebene durchgesetzt — er kann nicht durch direkte Delta-Reads aus DBFS umgangen werden (ein Grund, DBFS direkt nicht mehr zu nutzen, sobald du auf Unity Catalog bist).

Unterstützt in: Databricks Runtime 12.2 LTS+ mit aktiviertem Unity Catalog. Row Filters werden pro Query evaluiert — sei dir der Performance-Implikationen bei großen Tabellen ohne Partition-Pruning bewusst.

Column Masking

Column Masking versteckt oder transformiert sensible Werte für User:innen ohne die passende Rolle. Typische Use-Cases: PII-Felder, Kreditkartennummern, interne Cost-Center.

-- Create a masking function
CREATE OR REPLACE FUNCTION analytics.governance.mask_email(email STRING)
RETURNS STRING
RETURN CASE
    WHEN IS_ACCOUNT_GROUP_MEMBER('pii-cleared') THEN email
    ELSE CONCAT(LEFT(email, 2), '***@***.***')
END;

-- Apply the mask to a column
ALTER TABLE analytics.silver.customers
ALTER COLUMN email SET MASK analytics.governance.mask_email;

User:innen ohne pii-cleared-Gruppe sehen jo***@***.***. User:innen in pii-cleared sehen die volle E-Mail. Das Masking ist transparent — die Spalte existiert weiter, Queries failen nicht.

-- What users without PII clearance see:
SELECT customer_id, email FROM analytics.silver.customers LIMIT 5;
-- customer_id | email
-- 1001        | jo***@***.***
-- 1002        | ma***@***.***

Tags: Daten klassifizieren und entdecken

Unity-Catalog-Tags lassen dich Catalogs, Schemas, Tables und einzelne Spalten labeln. Tags sind Free-Text-Key-Value-Paare, die an Objekte im Metastore gehängt werden.

-- Tag a table
ALTER TABLE analytics.silver.customers
SET TAGS ('pii' = 'true', 'data_domain' = 'customer', 'owner' = 'data-platform');

-- Tag a column
ALTER TABLE analytics.silver.customers
ALTER COLUMN email SET TAGS ('sensitivity' = 'high', 'pii_type' = 'email');

-- Query tags via system catalog
SELECT table_name, column_name, tag_name, tag_value
FROM system.information_schema.column_tags
WHERE tag_name = 'sensitivity' AND tag_value = 'high';

Tags integrieren mit dem Databricks-Catalog-UI und beschleunigen Discovery deutlich. Sie bilden auch die Basis für Policy-driven Governance — du kannst Row-Filter- und Masking-Functions bauen, die Tags prüfen statt Tabellennamen zu hardcoden.

Data Lineage

Unity Catalog captured automatisch Column-Level-Lineage über Notebooks, Jobs, DLT-Pipelines und Databricks SQL. Keine Instrumentierung nötig — es ist standardmäßig aktiv, wenn UC aktiv ist.

Du kannst Lineage programmatisch abfragen:

-- System table: table lineage (upstream → downstream)
SELECT
    source_table_full_name,
    target_table_full_name,
    created_by,
    event_time
FROM system.access.table_lineage
WHERE target_table_full_name = 'analytics.gold.customer_360'
ORDER BY event_time DESC
LIMIT 20;

-- Column-level lineage
SELECT
    source_table_full_name,
    source_column_name,
    target_table_full_name,
    target_column_name
FROM system.access.column_lineage
WHERE target_table_full_name = 'analytics.gold.customer_360'
    AND target_column_name = 'lifetime_value';

Lineage wird im Catalog UI als Visual Graph angezeigt. Für regulierte Branchen ist das oft das Erste, was Compliance-Teams sehen wollen — und für DSGVO-Auskunftspflichten direkt relevant.

Lineage-Einschränkungen:

• Lineage wird zur Query-Ausführungszeit erfasst — historische Lineage vor der UC-Migration ist nicht verfügbar
• Lineage aus externen Tools (dbt, Airbyte, custom JDBC) wird nicht automatisch erfasst
• Direkte Delta-Lake-Writes außerhalb von Databricks Compute tauchen nicht auf

Audit-Logs über System Tables

Unity Catalog schreibt alle Access-Events nach system.access.audit. Das ist die Single Source of Truth dafür, wer was wann und von wo zugegriffen hat.

-- Who accessed the customers table in the last 7 days?
SELECT
    user_identity.email AS user_email,
    action_name,
    request_params.full_name_arg AS table_accessed,
    event_time,
    source_ip_address
FROM system.access.audit
WHERE action_name IN ('commandSubmit', 'runCommand')
    AND request_params.full_name_arg LIKE '%customers%'
    AND event_time >= CURRENT_TIMESTAMP - INTERVAL 7 DAYS
ORDER BY event_time DESC;

-- Failed access attempts (potential security events)
SELECT
    user_identity.email,
    action_name,
    status_code,
    error_message,
    event_time
FROM system.access.audit
WHERE status_code != 200
    AND event_time >= CURRENT_TIMESTAMP - INTERVAL 24 HOURS
ORDER BY event_time DESC;

System Tables sind mit Standard-SQL abfragbar — du kannst Dashboards direkt darauf bauen mit Databricks SQL oder in dein SIEM exportieren.

Verfügbarkeit: Audit-Logs werden standardmäßig 365 Tage aufbewahrt. Der Catalog system.access muss von einem Metastore-Admin aktiviert werden.

Governance Best Practices

Häufige Fallen

1. MODIFY auf Catalog-Level granten

Das gibt Schreibzugriff auf jede Tabelle. Fast nie die richtige Wahl. Granne minimum auf Schema-Level, präferiert Table-Level.

2. Row Filters mit zu teuren UDFs

Ein Row Filter läuft auf jeder Query. Macht deine Filter-Function eine Subquery gegen eine andere Tabelle, wird jedes SELECT zu einem Join. Halt Filter einfach und schnell.

3. Annahme, dass Column Masking alle Access-Pfade abdeckt

Column Masking gilt für Databricks SQL und Notebook Compute auf Unity Catalog. Direkter Delta-File-Zugriff (z. B. Parquet-Reads aus ADLS, die UC umgehen) setzt Masking nicht durch. Sperr auch Storage-Level-Zugriff ab.

4. System Tables nicht aktivieren

System Tables (Lineage, Audit) müssen pro Metastore explizit aktiviert werden. Das ist eine einmalige Admin-Aktion — mach das am ersten Tag.

Für Teams, die vom Legacy Hive Metastore migrieren, siehe unseren Unity Catalog Migration Guide für den praktischen Migrationspfad und Unity Catalog Best Practices für Namespace-Design-Entscheidungen.

Fazit

Unity Catalogs Governance-Fähigkeiten sind Production-Grade — Row Filters, Column Masking, Tags, Lineage und Audit-Logs decken die meisten Enterprise-Compliance-Anforderungen out-of-the-box ab. Der Haken: Nichts davon ist automatisch. Du musst Access-Patterns upfront modellieren, Tags konsistent anwenden und das Audit-Log aktiv monitoren. Die SQL-Oberfläche ist gut designt und abfragbar — behandle deine Governance-Schicht wie Code, versioniere sie, teste sie wie jedes andere Datenprodukt.

FAQ

Erfüllt Unity Catalog DSGVO-Anforderungen out-of-the-box?

Nicht automatisch, aber er liefert die Bausteine. Column-Level-Lineage hilft bei Auskunftspflichten, Audit-Logs erfüllen Nachweispflichten, Column Masking schützt PII bei Standard-Access. Du musst trotzdem dein eigenes Löschkonzept (Right to Erasure) und deine eigene Auftragsverarbeitungs-Dokumentation bauen.

Kann ich Row Filters mit Performance-Impact ausweichen?

Halte Filter-Logik simpel (keine Subqueries gegen große Tabellen). Kombinier Filter mit Partition Pruning, indem du auf dem Filter-Column auch partitionierst. Bei sehr großen Tabellen kann es günstiger sein, separate Tables pro Region/Tenant zu pflegen statt einen Row Filter.

Wie unterscheidet sich Unity Catalog von Hive Metastore?

Hive Metastore ist Workspace-lokal, kennt keine Three-Level-Namespaces, keine native Row-Level-Security, keine automatische Lineage, keine Audit-Logs. Unity Catalog ist Account-übergreifend, multi-Workspace, mit allen genannten Features. Migration ist nicht trivial — plane mehrere Wochen für Production-Workloads.

Funktioniert Column Masking auch bei Delta Sharing?

Ja, Column Masking und Row Filters werden bei Delta Sharing über Unity Catalog respektiert. Empfangende Organisationen sehen nur, was die Policies erlauben. Das macht UC zur Wahl für regulierte Datenfreigabe (z. B. DSGVO-konforme Datenkooperationen).

Weiterlesen

• Unity Catalog Best Practices
• Databricks Legacy Sunset und UC Migration
• Delta Sharing Explained

Stand: 15. Mai 2026.