Column Masking

Column Masking (deutsch: Spaltenmaskierung) ist eine Regel in der Datenbank, die den Inhalt einer einzelnen Spalte (etwa E-Mail oder Gehalt) für berechtigte Nutzer im Klartext anzeigt und für andere maskiert (zum Beispiel als Sternchen oder Hash-Wert, also eine nicht rückrechenbare Zeichenfolge). Die Originaldaten in der Tabelle bleiben unverändert; nur die Anzeige im Abfrage-Ergebnis wird abhängig von Nutzer und Rolle umgeschrieben.

Was ist Column Masking?

Column Masking ist ein Verfahren, mit dem eine Datenbank oder ein Datenkatalog (das Verzeichnis, in dem Tabellen und ihre Rechte verwaltet werden) sensible Spaltenwerte pro Nutzer unterschiedlich anzeigt. Wer berechtigt ist, sieht den Klartext; wer nicht berechtigt ist, sieht eine ersetzte Version desselben Werts. Typische Beispiele sind E-Mail-Adressen, Steuer- oder Sozialversicherungsnummern, IBAN, Gehälter und andere personenbezogene Angaben. Die Regel hängt direkt an der Spalte und ersetzt damit eine sonst nötige zweite Tabellen-Ansicht mit vorgefilterten Werten oder eine maskierte Kopie der Daten. Bei jeder Abfrage entscheidet das System anhand dieser Regel, welcher Wert im Ergebnis erscheint.

Der Begriff hat sich in den letzten Jahren im Umfeld von Cloud-Datenplattformen etabliert, findet sich aber bereits in älteren Datenbanksystemen. IBM Db2 kennt Column Masks seit Version 10 als eigenständiges Datenbank-Objekt, das eine CASE-Regel für eine Spalte hinterlegt. Snowflake führte 2020 Column-level Security mit MASKING POLICY ein. Databricks unterstützt Column Masks in Unity Catalog seit 2023, gebunden per ALTER TABLE ... ALTER COLUMN ... SET MASK. Microsoft SQL Server bietet ein verwandtes Feature unter dem Namen Dynamic Data Masking.

Eine Maskierungsfunktion ist typischerweise eine skalare SQL-UDF, die den Spaltenwert und optional Kontextinformationen (etwa current_user(), is_account_group_member()) als Argumente erhält und einen Wert desselben Typs zurückgibt. Häufige Ausprägungen sind SHA-256- oder HMAC-Hashes, partielle Maskierung mit Sternchen (etwa ***@example.com), vollständige Redaction, konstanter Ersatzwert (REDACTED), Format-erhaltende Maskierung oder Tokenisierung mit einem externen Token-Vault.

Der Mechanismus existiert, weil Datenteams ohne ihn zwei unbefriedigende Optionen haben: entweder eine View pro Rolle und Tabelle mit eigener Maskierungslogik, oder eine Maskierung im ETL, die den Rohwert dauerhaft verwirft. Column Masking trennt die Speicherung des Rohwerts von seiner sichtbaren Repräsentation. Damit wandert die Schutzlogik aus einzelnen Reports, Views und Ingest-Skripten an eine zentrale Stelle, die für alle Zugriffswege gleich wirkt: SQL, Notebooks, BI-Tools und Anwendungen sehen dieselbe maskierte Ausgabe.

Abgrenzung zu Row-Level Security, Dynamic Views und Data Encryption

Column Masking ist einer von mehreren Mechanismen zum Schutz sensibler Daten. Die Verwechslungsgefahr entsteht durch überlappende Vokabeln, obwohl die Wirkungsebene sich unterscheidet.

Row-Level Security entscheidet über die Sichtbarkeit ganzer Zeilen (etwa: Ein Nutzer der Region DACH sieht nur Zeilen mit region = 'DACH'). Column Masking lässt die Zeile sichtbar, verändert aber einzelne Werte darin. Beide Konzepte kombinieren sich häufig: Dieselbe Tabelle trägt einen Row Filter für die Mandantenlogik und mehrere Column Masks für PII-Spalten.

Dynamic Views sind das ältere Muster für dasselbe Ziel. Eine View maskiert Spalten per SQL-Ausdruck und wird pro Nutzer- oder Rollen-Sicht angelegt. Die Logik lebt in der einzelnen View und muss bei jeder neuen Tabelle, Rolle oder PII-Klassifizierung nachgezogen werden. Column Masking bindet die Regel stattdessen an das Spaltenobjekt selbst; jede Abfrage auf die Basistabelle wird geprüft, unabhängig davon, ob eine View dazwischenliegt.

Data Encryption operiert eine Ebene tiefer. Verschlüsselung schützt Daten auf dem Speicher (at rest) oder während der Übertragung (in transit) und macht sie ohne Schlüssel unbrauchbar. Column Masking wirkt erst, nachdem die Daten entschlüsselt in die Query-Engine gelangt sind, und ist deshalb kein Ersatz für Verschlüsselung. Der Rohwert bleibt für Prozesse mit direktem Storage-Zugriff (etwa Storage-Admins oder Owner der zugrunde liegenden Dateien) lesbar.

Tokenisierung geht den umgekehrten Weg: Sie ersetzt den Rohwert dauerhaft im Speicher durch ein Token und hinterlegt die Rückabbildung in einem separaten Vault. Column Masking behält den Klartext in der Tabelle und verändert nur die Ausgabe; berechtigte Nutzer sehen weiterhin den Originalwert, unberechtigte den maskierten.

Beispiel: PII-Maskierung auf einer E-Mail-Spalte in Unity Catalog

Ein Datenteam eines E-Commerce-Anbieters möchte die Spalte email in der Tabelle analytics.customer schützen. Analysten der Gruppe data-compliance sollen den Klartext sehen, alle anderen Gruppen einen Hash. Statt eine separate maskierte View pro BI-Tool und Report zu pflegen, wird eine Maskierungsfunktion in Unity Catalog angelegt und an die Spalte gebunden.

CREATE OR REPLACE FUNCTION governance.email_mask(email STRING)
RETURNS STRING
RETURN CASE
  WHEN is_account_group_member('data-compliance') THEN email
  ELSE sha2(email, 256)
END;

ALTER TABLE analytics.customer
  ALTER COLUMN email SET MASK governance.email_mask;

Die Regel greift ab dem Zeitpunkt der Bindung für jede Abfrage auf analytics.customer.email, unabhängig vom Zugriffsweg. Ein SQL-Warehouse-Query, ein Databricks-Notebook, ein Power-BI-Report und ein Python-Job über den JDBC-Treiber sehen dieselbe maskierte Ausgabe. Die Tabelle behält Namen, Schema und Ownership; keine zusätzliche View wird eingeführt.

In größeren Plattformen läuft die Bindung selten pro Tabelle, sie wird über Klassifizierungs-Tags automatisiert. Eine Governance-Konvention markiert alle PII-Spalten mit dem Tag pii=true. Eine attributbasierte Policy (ABAC) auf Account-Ebene sorgt dafür, dass jede Spalte mit diesem Tag automatisch die Standard-Maskierungsfunktion erhält. Wird eine neue Tabelle mit einer korrekt getaggten Spalte angelegt, greift die Maskierung ohne zusätzlichen Grant und ohne manuelle Bindung.

Der Wirkungsbereich hängt an der Qualität der Tag-Belegung. Fehlt der Tag an einer neuen Spalte, greift die Policy nicht, und der Klartext ist über die bestehenden RBAC-Rechte lesbar. Column Masking auf Tag-Basis setzt deshalb ein aktives Klassifizierungs-Management voraus, das entweder manuell durch Stewards oder automatisch durch Klassifizierungs-Scanner erfolgt.