Grenzen zwischen Catalog und Control Plane

Ein Datenkatalog macht Datenbestände, verantwortliche Rollen, Regeln, Herkunft und Status auffindbar. Eine technische Kontrollebene setzt Identität, Zugriff, Maskierung, Netzwerk- oder Laufzeitregeln durch. Der Katalog ersetzt diese Durchsetzung nicht; lokale Plattformkontrollen sind umgekehrt keine gemeinsame Quelle für fachliche Bedeutung.

Drei Ebenen statt Tool-Verwirrung

Trenne fachliche Regel, technische Durchsetzung und Nachweis. Die für eine Regel verantwortliche Rolle legt fest, wer welche Daten zu welchem Zweck und unter welchen Bedingungen nutzen darf. Lokale Plattformkontrollen setzen dies mit Identitäten, Rollen, Maskierung, Netzwerk- oder Laufzeitregeln um. Der Katalog verbindet Produkt, verantwortliche Rolle, Regel, Herkunftskette, Kontrollstatus und Nachweis.

Der Catalog darf einen Zugriff anstoßen oder einen Workflow anzeigen, ist dadurch aber nicht automatisch der Durchsetzungspunkt. Umgekehrt kann eine Plattform Zugriffe zuverlässig blockieren, ohne autoritative Quelle für Geschäftsbedeutung oder Risikoakzeptanz zu sein. Eine klare System-of-Record-Matrix benennt je Attribut genau eine Quelle und erlaubte Replikate.

Gearbeitetes Beispiel: sensible Personaldaten

Eine HR-Domain klassifiziert Gehaltsdaten als streng vertraulich. Die Policy erlaubt Zugriff für aktive Compensation Analysts mit genehmigtem Zweck; Exporte müssen protokolliert werden. Daten liegen in zwei analytischen Stacks. Snowflake, Fabric oder Databricks wären mögliche Beispiele, ohne dass ihre Produktfunktionen bewertet oder gerankt werden.

Im Catalog stehen Produkt-ID, Klassifikation, Policy-ID, verantwortliche Rolle, Nutzende und Lineage. Stack A erzwingt Zugriff über eine Rolle und Maskierungsregel, Stack B über eine Gruppe und eine lokale Policy. Der Crosswalk verknüpft beide Durchsetzung-Objekte mit derselben Policy-ID. Alle vier Stunden melden Tests Status, getesteten Umfang, Ergebnis, Zeitpunkt und Evidenz-Link zurück.

Ein Administrator ändert versehentlich die Gruppe in Stack B. Der nächste Test erkennt Drift. Der Catalog zeigt nicht einfach weiterhin „geschützt“, sondern „nicht konform, zuletzt getestet 10:15“. Platform Security behebt die Gruppe; der für die Regel verantwortliche Rolle muss den fachlichen Intent nicht neu entscheiden. Falls die Plattform eine Anforderung technisch nicht erfüllen kann, geht eine befristete Ausnahme an denselben für die Regel verantwortliche Rolle.

System-of-Record-Matrix

Das Governance-Register oder der vereinbarte Datenkatalog ist die maßgebliche Quelle für Regel-ID, Geschäftsbedeutung, fachlich verantwortliche Rolle und Ausnahmeentscheidung. Der Identitätsdienst ist maßgeblich für Personen und Gruppen. Lokale Plattformen sind maßgeblich für technische Konfiguration und Laufzeitereignisse. Geschützte Nachweisablagen halten detaillierte Testergebnisse. Der Katalog darf diese Zustände spiegeln, muss aber Quelle, Aktualität und Synchronisationsfehler anzeigen.

Vermeide bidirektionale Synchronisation ohne Konfliktregel. Wenn zwei Systeme dasselbe Verantwortungsfeld bearbeiten dürfen, entsteht Twin Ops auf Metadatenebene. Definiere Schreibrechte, Richtung, Frequenz, Fehlerqueue und Recovery.

Sizing nach Organisationsgröße

SMB/SME: Dokumentiere für eine kritische Policy eine Seite mit Intent, verantwortliche Rolle, zwei Durchsetzungspunkten und Test. Der Catalog findet; IAM oder Datenplattform erzwingt. Ein täglicher Test und eine sichtbare Zeitangabe reichen häufig.

Mid-Market: Baue eine System-of-Record-Matrix für Policy-, Identity-, Inventory- und Nachweis-Metadaten. Platform Security pflegt Control-Mappings, Governance den Intent. Automatisiere Drift-Checks für priorisierte Policies und triagiere Fehler in einer gemeinsamen Queue.

Enterprise: Nutze föderierte Control Planes mit gemeinsamer Policy- und Control-ID. Definiere Non-Goals je Tool, Ereignisschema, Freshness-SLO und Ausnahmeprozess. Zentralisiert werden Intent, Mindestnachweis und Assurance; Durchsetzung bleibt dort, wo Identität und Daten technisch kontrolliert werden können.

Umsetzungsschritte

1. Wähle eine konkrete, risikorelevante Policy statt ein vollständiges Framework.
2. Formuliere Intent, Umfang, für die Regel verantwortliche Rolle und Ausnahmebefugnis.
3. Inventarisiere reale Durchsetzungspunkte über alle Stacks.
4. Vergib Control-IDs und verknüpfe lokale Objekt-IDs.
5. Definiere positive und negative Outcome-Tests.
6. Lege Evidenzschema, Frequenz, Freshness-SLO und Fehlerstatus fest.
7. Synchronisiere den Status einseitig in den Catalog zurück.
8. Simuliere Drift, fehlende Verbindung und veraltete Evidenz.
9. Prüfe Übergabe und Eskalation mit Platform Security.
10. Entferne manuelle Statusfelder, die denselben Zustand duplizieren.

Übergaben und Fehlerwege

Der für die Regel verantwortliche Rolle übergibt Intent, Umfang, Risikoklasse und Ausnahmeregel an Platform Security. Security übersetzt sie in eine stack-spezifische Control-Spezifikation und übergibt diese an den lokalen Custodian. Der Custodian implementiert und liefert Objekt-ID, Test und Rollback. Automatisierte Tests senden Nachweis an Catalog oder Nachweis Store. Assurance bewertet Abdeckung und Freshness.

Bei technischer Drift handelt zunächst Platform Security innerhalb des freigegebenen Intents. Bei einer echten Anforderungslücke entscheidet der für die Regel verantwortliche Rolle. Bei Synchronisationsfehlern muss der Catalog einen unbekannten oder veralteten Zustand zeigen, keinen grünen Altstatus. Fail-safe bedeutet hier ehrliche Unsicherheit und je nach Risiko zusätzlich technische Zugriffsbeschränkung.

Anti-Patterns

Tag gleich Control: Ein Label wird als Schutz interpretiert. Verlange einen verknüpften Durchsetzungspunkt und Outcome-Test.

Lokale Rolle gleich Policy: Technische Namen werden zur fachlichen Regel. Halte Intent unabhängig von Implementierung.

Catalog als Schatten-IAM: Berechtigungen werden doppelt gepflegt. Nutze Workflow und Referenzen, aber eine autoritative Identity- und Durchsetzung-Quelle.

Grün ohne Freshness: Alte Evidenz wirkt aktuell. Zeige Testzeitpunkt, SLO und stale/unknown als eigene Zustände.

Jährlicher Drift-Check: Änderungen bleiben monatelang unentdeckt. Passe Frequenz an Risiko und Änderungsrate an.

Bidirektionale Felder: Zwei Systeme überschreiben verantwortliche Rolle oder Klassifikation. Benenne eine Write Authority und Fehlerqueue.

Prüfliste

• Intent und technische Konfiguration sind getrennt.
• Richtlinie verantwortliche Rolle und Kontrollregel Custodians sind benannt.
• Jede lokale Kontrollregel referenziert eine gemeinsame Richtlinie-ID.
• System-of-Record und Synchronisationsrichtung sind dokumentiert.
• Positive und negative Tests existieren.
• Status zeigt Umfang, Ergebnis und Freshness.
• Stale und unknown werden nicht als compliant dargestellt.
• Drift besitzt Queue, verantwortliche Rolle und Reaktionszeit.
• Ausnahmen haben Ablaufdatum und Risikoakzeptanz.
• Kein Catalog-Feld dupliziert lokale Durchsetzung-Pflege.

Verwandte Playbooks

Siehe Multi-Stack Governance im Überblick, Ein Verantwortung-Modell über alle Plattformen, Geteilte Metriken über mehrere Stacks und Multi-Stack-Pilot ohne Twin Ops.

Evidenz und Audit-Paket

Für einen Audit-Nachweis exportierst du nicht nur einen Catalog-Screenshot. Das Paket enthält Policy-Version und verantwortliche Rolle, betroffene Produkte, lokale Control-IDs, Mapping-Zeitpunkt, Testdefinition, letzte Ergebnisse, Freshness-SLO, offene Ausnahmen und Korrekturhistorie. Damit lässt sich die Kette vom Intent bis zur tatsächlichen Durchsetzung prüfen.

Beschränke Rohdaten nach dem Need-to-know-Prinzip. Ein gemeinsamer Nachweisstandard verlangt nicht, dass alle Teams vollständige Zugriffslogs in einen zentralen Catalog kopieren. Häufig genügen signierte oder unveränderbare Resultate, Aggregationen und Links in einen geschützten Nachweis Store. Definiere Aufbewahrung und Zugriff auch für Nachweis selbst.

Überprüfe die Grenze bei jeder neuen Integration. Wenn ein Connector Schreibzugriff anbietet, entscheide ausdrücklich, ob er Workflow, Metadatenpflege oder Durchsetzung verändert. Dokumentiere Rollback und Verhalten bei Ausfall. Ein fehlgeschlagener Connector darf weder Zugriffe unbemerkt öffnen noch einen alten Status als aktuell präsentieren. Diese Prüfung verhindert, dass bequeme Produktfunktionen die vereinbarte Verantwortungsverteilung schleichend verschieben.