Skalierende Sicherheit: ABAC, Tags & automatische Policies mit Unity Catalog

Wer heute sensible Daten in einer modernen Analytics-Plattform nutzbar machen will, merkt schnell: Klassische Einzel-Freigaben skalieren schlecht. Genau hier setzt ABAC in Unity Catalog an. Statt Berechtigungen Objekt für Objekt nachzupflegen, können Sie Sicherheitslogik stärker an Datenklassifikation, Kontext und wiederverwendbaren Regeln ausrichten. Das ist nicht nur eleganter, sondern vor allem verlässlicher.

Für viele Teams beginnt das Problem schleichend. Erst gibt es ein paar Tabellen, ein paar Gruppen und ein paar Grants. Dann kommen neue Domänen, Self-Service-Use-Cases, externe Partner, Data Products und sensible Attribute dazu. Spätestens dann entsteht das, was ich gern „Grant-Spaghetti“ nenne: ein Berechtigungsmodell, das historisch gewachsen ist, aber kaum noch sauber erklärbar, wartbar oder auditierbar bleibt.

Gerade in SAP-nahen Organisationen ist das heikel. Dort ist man zu Recht gewohnt, dass Datenbewirtschaftung verlässlich, nachvollziehbar und kontrolliert abläuft. Moderne Plattformen brauchen aber zusätzlich Agilität. Die Kunst besteht also nicht darin, Sicherheit gegen Nutzung auszuspielen. Die Kunst besteht darin, Sicherheit so zu gestalten, dass sie Nutzung überhaupt erst auf ein stabiles Fundament stellt.

Warum ABAC skaliert – und Grant-Spaghetti nicht

Viele Berechtigungsmodelle starten rollenbasiert und enden improvisiert. Das ist kein Zeichen von Inkompetenz, sondern oft einfach ein Wachstumsproblem. Solange wenige Teams mit wenigen Datenobjekten arbeiten, funktionieren direkte Grants noch ordentlich. Mit zunehmender Plattformreife kippt das Modell jedoch.

Typische Symptome von Grant-Spaghetti sind:

• Einzelrechte auf Tabellen- oder Spaltenebene ohne klare Systematik
• Sonderfreigaben für Einzelfälle, die nie wieder aufgeräumt werden
• unklare Ownership zwischen Plattformteam, Fachbereich und Security
• hoher manueller Pflegeaufwand
• schwierige Auditierbarkeit
• grosse Unsicherheit bei Änderungen

ABAC steht für Attribute-Based Access Control. Im Databricks-Kontext bedeutet das vereinfacht: Zugriff wird nicht nur über starre Rollen vergeben, sondern stärker über Attribute, Klassifikationen und Regeln gesteuert. Diese Attribute können sich auf Datenobjekte, Nutzerkontexte oder organisatorische Merkmale beziehen.

Wichtig ist dabei: Attribute-Based Access Control in Databricks ist kein Ersatz für jedes rollenbasierte Modell. ABAC ist eher die Skalierungslogik über dem Grundgerüst. Rollen bleiben sinnvoll. Aber wenn jede Ausnahme nur über zusätzliche Grants gelöst wird, wächst das Modell wie ein Keller, in dem man seit zehn Jahren „nur kurz etwas abstellt“.

RBAC ist der Start. ABAC ist oft die Skalierung.

Ein pragmatisches Bild:

• RBAC beantwortet: Welche Rolle darf grundsätzlich was?
• ABAC beantwortet: Unter welchen Bedingungen, an welchen Daten, in welchem Kontext?

Das ist besonders wertvoll, wenn Sie mit sensiblen Daten arbeiten, etwa:

• personenbezogene Daten
• Finanzdaten
• interne oder vertrauliche Informationen
• länderspezifisch eingeschränkte Daten
• domänenspezifische Datenprodukte

In solchen Umgebungen ist es effizienter, Regeln wiederverwendbar zu definieren, statt jede Tabelle einzeln zu behandeln.

Warum das für Self-Service entscheidend ist

Self-Service scheitert selten nur an Technik. Er scheitert oft an fehlender Sicherheitslogik. Wenn jede neue Datenfreigabe einen manuellen Abstimmungsprozess mit zehn Sonderfällen auslöst, wird aus Self-Service schnell „Service-Ticket mit Hoffnung“.

ABAC hilft, diesen Widerspruch aufzulösen:

• mehr Standardisierung
• weniger Einzelfallpflege
• bessere Nachvollziehbarkeit
• konsistentere Durchsetzung
• geringeres Restrisiko bei Wachstum

Governed Tags in Unity Catalog: Was sie leisten und wie Sie sie sinnvoll einsetzen

Wenn ABAC die Logik ist, dann sind Governed Tags ein wichtiger Teil der Sprache. Tags helfen dabei, Datenobjekte einheitlich zu klassifizieren und daraus wiederverwendbare Sicherheitsregeln abzuleiten.

Ein Tag ist zunächst nur ein Merkmal. Der Unterschied entsteht durch Governance: Wer darf Tags vergeben? Welche Werte sind erlaubt? Welche Policies hängen daran? Und wie wird kontrolliert, ob die Klassifikation vollständig und konsistent ist?

Genau deshalb sind Tags in Unity Catalog mehr als nur hübsche Etiketten. Richtig eingesetzt werden sie zum Bindeglied zwischen Datenklassifikation, Sicherheitsmodell und Auditierbarkeit.

Typische Governed Tags

Sinnvolle Beispiele für Governed Tags sind:

• PII – für personenbezogene oder personenbeziehbare Daten
• financial – für finanzrelevante Daten, etwa Ist-Werte, Forecasts, Margen oder Planungsdaten
• internal – für intern nutzbare Daten, die nicht für externe Partner oder offene Nutzung gedacht sind

Weitere nützliche Tags können sein:

confidential, restricted, public, country_scope=CH, country_scope=DE, retention_class=7y, domain=finance, domain=supply_chain

Gute Tags sind nicht beliebig

Ein häufiger Fehler: Teams starten mit zu vielen freien Tags und wundern sich später über Chaos in neuer Verpackung. Dann haben Sie keine Grant-Spaghetti mehr, sondern Tag-Spaghetti. Das ist kein Fortschritt.

Pragmatische Regeln für Governed Tags:

• wenige, klare Klassifikationskategorien
• definierte Owner
• dokumentierte Bedeutung
• verbindliche Schreibweise
• klare Policy-Zuordnung
• regelmässige Qualitätskontrolle

SAP-nahe Übersetzungshilfe

Für SAP-erfahrene Teams lässt sich das so einordnen: Governed Tags sind keine 1:1-Entsprechung zu bekannten Berechtigungsobjekten, aber sie erfüllen einen ähnlichen Zweck auf moderner Plattformebene: Sie standardisieren die Einordnung von Daten, damit Sicherheitsentscheidungen nicht jedes Mal neu erfunden werden müssen.

Oder anders gesagt: Statt Sonderlocken pro Objekt bauen Sie eine verlässliche Klassifikationslogik für die Datenbewirtschaftung.

Governed-Tag-Referenz (kompakt)

Tag-Policy-Templates: Von Tags zu Row Filters und Column Masking

Der eigentliche Mehrwert entsteht nicht durch Tags allein, sondern durch die Verbindung von Tags und Policies. Erst wenn aus Klassifikation eine automatisch durchsetzbare Regel wird, skaliert das Modell.

Dafür brauchen Sie Policy Templates – wiederverwendbare Muster, die festlegen, was bei bestimmten Tags passieren soll.

Warum Templates besser sind als Einzelfallregeln

Ein Template schafft:

• Konsistenz
• Wiederverwendbarkeit
• geringeren Pflegeaufwand
• bessere Auditierbarkeit
• schnelleren Rollout über mehrere Domänen hinweg

Wenn zum Beispiel jede PII-Spalte individuell behandelt wird, steigt die Fehlerquote. Wenn dagegen ein standardisiertes Template definiert, wie PII maskiert wird, wird Sicherheit planbarer.

Typische Policy-Muster

Sinnvolle Policy-Muster sind zum Beispiel:

• PII → Column Masking
• financial → Zugriff nur für definierte Gruppen oder Kontexte
• internal → Ausschluss externer Nutzung
• country_scope → Zugriff nach regionalem Kontext
• restricted → zusätzliche Freigabe oder engerer Zugriffspfad

Pseudocode: Tag-Policy-Templates

Hinweis: Die folgenden Beispiele sind bewusst als Pseudocode formuliert. Sie dienen der Sicherheitslogik, nicht als produktgenaue Syntax.

POLICY TEMPLATE mask_pii_columns
IF column.tag == 'PII'
THEN
  APPLY MASKING RULE
  ALLOW FULL VALUE ONLY FOR user.role IN ('privacy_admin', 'authorized_analyst')
  OTHERWISE RETURN masked_value()
END

POLICY TEMPLATE finance_access
IF table.tag == 'financial'
THEN
  ALLOW SELECT ONLY IF user.department IN ('Finance', 'Controlling')
  OR user.role IN ('cfo_office', 'finance_data_steward')
END

POLICY TEMPLATE internal_only
IF object.tag == 'internal'
THEN
  DENY ACCESS IF user.context == 'external_partner'
END

Pseudocode: Row Filter

Row Filters sind sinnvoll, wenn nicht alle Nutzer alle Datensätze sehen sollen, obwohl sie auf dieselbe Tabelle zugreifen.

ROW FILTER regional_scope_filter
ON table sales_orders
IF table.tag == 'financial'
THEN
  RETURN rows WHERE region = user.region_scope
END

Beispiel: Ein Nutzer mit Verantwortung für die Schweiz sieht nur Datensätze für CH. Das ist besonders nützlich, wenn organisatorische Zuständigkeiten regional oder mandantenbezogen getrennt sind.

Pseudocode: Column Masking

Column Masking eignet sich, wenn Tabellen grundsätzlich nutzbar bleiben sollen, aber sensible Spalten geschützt werden müssen.

COLUMN MASK customer_email_mask
ON table customers.email
IF column.tag == 'PII'
THEN
CASE
WHEN user.role IN ('privacy_admin', 'customer_service_lead') THEN email
ELSE 'masked'
END

COLUMN MASK salary_mask
ON table payroll.salary
IF column.tag == 'financial'
THEN
  CASE
    WHEN user.role IN ('hr_finance_lead', 'cfo_office') THEN salary
    ELSE NULL
  END

Der Punkt ist nicht die exakte Syntax, sondern die Logik: Klassifikation → Policy → automatische Durchsetzung. Genau so heben Sie Sicherheit von einer Sammlung einzelner Freigaben auf ein skalierbares Betriebsmodell.

Wann Row Filters und wann Column Masking?

Eine einfache Daumenregel:

• Column Masking, wenn die Tabelle breit nutzbar sein soll, aber einzelne Felder sensibel sind
• Row Filters, wenn derselbe Datenbestand je nach Nutzerkontext unterschiedlich eingeschränkt werden soll
• beides kombiniert, wenn Datensätze und Spalten gleichzeitig geschützt werden müssen

Das ist oft der Punkt, an dem Sicherheit erwachsen wird. Nicht mehr „darf jemand auf die Tabelle zugreifen?“, sondern: Was genau darf diese Person in welchem Kontext sehen?

Auditierbarkeit in der Praxis: System Tables, Audit Queries und Compliance Reporting

Sicherheitsmodelle wirken auf Folien oft sauber. Im Betrieb zeigt sich dann, ob sie belastbar sind. Deshalb gilt: ABAC ohne Audit ist nur ein schönes Versprechen.

Wenn Sie mit Tags, Policies, Filtern und Maskierung arbeiten, brauchen Sie Antworten auf Fragen wie:

• Welche sensiblen Objekte haben wir überhaupt?
• Wo sind Tags gesetzt, wo fehlen sie?
• Welche Policies greifen wo?
• Wer hat auf sensible Daten zugegriffen?
• Wo gibt es Ausnahmen oder Lücken?

Genau hier kommen Audit-Telemetrie, System Tables und auswertbare Logs ins Spiel. Je nach verfügbarer Plattform- und Audit-Konfiguration können Sie diese Informationen für Governance und Compliance Reporting nutzen.

Beispielhafte Audit-Auswertungen

Die folgenden Beispiele sind sinngemässe Audit Queries. Sie zeigen, welche Art von Auswertung sinnvoll ist.

Welche Objekte tragen sensible Tags?

SELECT
  catalog_name,
  schema_name,
  object_name,
  tag_name,
  tag_value
FROM governance_tag_inventory
WHERE tag_name IN ('PII', 'financial', 'internal', 'restricted')
ORDER BY catalog_name, schema_name, object_name;

Nutzen: Transparenz über klassifizierte Datenobjekte, Grundlage für Stewardship und Kontrolllisten, Startpunkt für Policy-Abdeckung.

Welche sensiblen Objekte haben noch keine dokumentierte Policy-Zuordnung?

SELECT
  object_name,
  tag_name
FROM governance_tag_inventory t
LEFT JOIN policy_mapping p
  ON t.tag_name = p.tag_name
WHERE t.tag_name IN ('PII', 'financial', 'internal')
  AND p.policy_name IS NULL;

Nutzen: Lücken in der Sicherheitslogik sichtbar machen, verhindert falsches Sicherheitsgefühl, wichtig für Rollout und Qualitätssicherung.

Wer hat auf PII-nahe Objekte zugegriffen?

SELECT
  event_time,
  user_name,
  object_name,
  action_type
FROM audit_access_events
WHERE object_name IN (
  SELECT object_name
  FROM governance_tag_inventory
  WHERE tag_name = 'PII'
)
ORDER BY event_time DESC;

Nutzen: Zugriff auf sensible Daten nachvollziehen, Auffälligkeiten erkennen, Nachweis für interne Revision oder Security Reviews.

Wo wurden Maskierungen oder Filter angewendet?

SELECT
  event_time,
  user_name,
  object_name,
  policy_name,
  enforcement_type
FROM policy_enforcement_events
WHERE enforcement_type IN ('COLUMN_MASK', 'ROW_FILTER')
ORDER BY event_time DESC;

Nutzen: Wirksamkeit der Sicherheitslogik sichtbar machen, Prüfung ob Policies greifen, Grundlage für Compliance Reporting.

Welche Nutzergruppen greifen besonders häufig auf klassifizierte Daten zu?

SELECT
  user_group,
  tag_name,
  COUNT(*) AS access_count
FROM classified_data_access_summary
GROUP BY user_group, tag_name
ORDER BY access_count DESC;

Nutzen: Nutzungsmuster erkennen, Sonderfreigaben hinterfragen, Security-Massnahmen risikobasiert priorisieren.

Compliance Reporting: vom Bauchgefühl zur faktenbasierten Steuerung

Viele Unternehmen behandeln Compliance Reporting wie eine lästige Pflichtübung. Das ist verständlich, aber zu kurz gedacht. Gute Reports sind nicht nur für Auditoren da. Sie helfen auch Data Stewards, Plattformteams und Security-Verantwortlichen, den Zustand der Plattform faktenbasiert zu steuern.

Sinnvolle Compliance-Reports sind zum Beispiel:

• Übersicht aller sensiblen Datenobjekte nach Klassifikation
• Policy-Abdeckung je Tag-Kategorie
• Zugriffe auf sensible Daten nach Nutzergruppe
• Sonderfreigaben und dokumentierte Ausnahmen
• Objekte ohne vollständige Klassifikation
• Veränderungen an Sicherheitsregeln im Zeitverlauf

Beispiel: Policy-Abdeckung nach Klassifikation

SELECT
  tag_name,
  COUNT(*) AS classified_objects,
  SUM(CASE WHEN policy_attached = 'Y' THEN 1 ELSE 0 END) AS objects_with_policy
FROM governance_policy_coverage
GROUP BY tag_name;

Diese Art von Auswertung zeigt schnell, ob Ihre Sicherheitsarchitektur wirklich skaliert oder nur gut klingt.

Beispiel: Ausnahmen und Sonderfreigaben

SELECT
  object_name,
  exception_reason,
  approved_by,
  valid_until
FROM security_exceptions_register
ORDER BY valid_until;

Das ist besonders wichtig, weil Ausnahmen oft zum blinden Fleck werden. Erst sind sie temporär, dann dauerhaft, und irgendwann weiss niemand mehr, warum sie existieren.

Warum Reporting auch operativ hilft

Compliance Reporting ist nicht nur Nachweis, sondern Steuerungsinstrument:

• Data Stewards erkennen Klassifikationslücken
• SecOps sieht auffällige Zugriffsmuster
• Plattformteams erkennen technische Inkonsistenzen
• Führungskräfte bekommen Transparenz ohne Sicherheitsroman

Kurz gesagt: Reporting übersetzt Sicherheitslogik in Führungsfähigkeit.

Rollout-Plan in 7 Schritten

ABAC erfolgreich einzuführen, ist kein Schalter, den man umlegt. Es ist ein kontrollierter Aufbau von Klassifikation, Regeln, Ownership und Nachweisfähigkeit. Ein pragmatischer Rollout kann so aussehen:

1. Schutzziele und Scope definieren

• Ziel: Klar festlegen, welche Datenklassen und Risiken zuerst adressiert werden sollen.
• Typischer Stolperstein: Zu breit starten und alles gleichzeitig absichern wollen.
• Empfehlung: Beginnen Sie mit 2–3 klaren Schutzklassen, etwa PII, financial und internal.

2. Datenklassen und Governed Tags festlegen

• Ziel: Einheitliche Klassifikation schaffen.
• Typischer Stolperstein: Zu viele Tags oder uneinheitliche Begriffe.
• Empfehlung: Wenige, klar definierte Tags mit dokumentierter Bedeutung und Ownership einführen.

3. Verantwortlichkeiten klären

• Ziel: Saubere Zusammenarbeit zwischen Data Steward, Plattformteam, Security und Fachbereich.
• Typischer Stolperstein: Niemand fühlt sich für Klassifikation oder Pflege zuständig.
• Empfehlung: Tag-Ownership und Policy-Verantwortung explizit benennen.

4. Policy Templates entwerfen

• Ziel: Wiederverwendbare Sicherheitsmuster definieren.
• Typischer Stolperstein: Einzelregeln statt Templates bauen.
• Empfehlung: Erst wenige Standardmuster definieren, etwa Maskierung für PII und Zugriffsbeschränkung für financial.

5. Pilotbereich auswählen und testen

• Ziel: Sicherheitslogik unter realen Bedingungen prüfen.
• Typischer Stolperstein: Direkt unternehmensweit ausrollen.
• Empfehlung: Mit einer Domäne starten, die relevant, aber beherrschbar ist – zum Beispiel Finance Reporting oder Customer Analytics.

6. Audit- und Compliance-Reporting aufsetzen

• Ziel: Wirkung und Lücken sichtbar machen.
• Typischer Stolperstein: Audit erst nach dem Rollout mitdenken.
• Empfehlung: Früh definieren, welche Nachweise, Reports und Kontrollabfragen regelmässig gebraucht werden.

7. Rollout skalieren und Betriebsmodell etablieren

• Ziel: ABAC in den Regelbetrieb überführen.
• Typischer Stolperstein: Gute Pilotlösung ohne Betriebsmodell.
• Empfehlung: Freigabeprozesse, Review-Zyklen, Ausnahmebehandlung und Reporting-Routinen fest im Operating Model verankern.

Security Operating Model: Warum Technik allein nicht reicht

Der vielleicht wichtigste Punkt: ABAC ist kein reines Technikprojekt. Es ist ein Operating Model.

• Wenn Tags nicht gepflegt werden, verlieren Policies ihre Grundlage.
• Wenn Policies nicht geprüft werden, entsteht Scheinsicherheit.
• Wenn Audit-Informationen nicht ausgewertet werden, fehlt die Steuerung.
• Wenn Ownership unklar ist, wird Sicherheit zum Flaschenhals.

Ein belastbares Modell verteilt Verantwortung funktional:

Das muss kein starres Organigramm sein. Aber es muss klar sein, wer entscheidet, wer prüft und wer nachweist. Sonst wird aus „automatisierter Sicherheit“ sehr schnell „automatisierte Unklarheit“.

SAP-nahe Einordnung

Für SAP-erfahrene Teams lässt sich das so übersetzen:

ABAC ist die skalierbare Antwort auf eine Welt, in der viele Einzel-Freigaben nicht mehr beherrschbar sind. Governed Tags bringen Standardisierung in die Klassifikation. Audit-Reporting liefert den Nachweis, dass Datenbewirtschaftung nicht nur geregelt, sondern auch kontrolliert stattfindet.

Mit anderen Worten: weniger Sonderlocken, mehr verlässliche Sicherheitsmechanik.

Wenn Sie Ihre Klassifikations- und Policy-Logik nicht jedes Mal neu erfinden möchten, laden Sie sich jetzt das Tagging Policy Template herunter. Es hilft Ihnen dabei,

• Governed Tags sauber zu definieren,
• Policy-Zuordnungen strukturiert aufzubauen,
• ABAC pragmatisch auszurollen,
• Audit- und Compliance-Anforderungen von Anfang an mitzudenken.