Grenzen zwischen Catalog und Control Plane

Ein Catalog macht Assets, Owner, Policies, Lineage und Status auffindbar. Eine Control Plane setzt Identität, Zugriff, Maskierung, Netzwerk- oder Laufzeitregeln durch. Der Catalog ist kein Durchsetzung-Ersatz; lokale Control Planes sind keine gemeinsame Bedeutungsquelle.

← Vorheriger Teil · Nächster Teil →

Lösung: Halte die Policy-Absicht zentral und mappe sie auf lokale Durchsetzung-Objekte.

In einem Satz: Halte die Policy-Absicht zentral und mappe sie auf lokale Durchsetzung-Objekte.

Entscheidung

Halte die Policy-Absicht zentral und mappe sie auf lokale Durchsetzung-Objekte. Synchronisiere Status und Evidenz zurück in den Catalog, ohne dort eine Durchsetzung vorzutäuschen.

Workflow

1. Policy-Intent und Decision Owner erfassen. 2. Durchsetzung-Punkte je Stack mappen. 3. IDs und Status verbinden. 4. Drift und Fehler testen. 5. Rückmeldung im Catalog mit Zeitstempel zeigen.

Handoffs

Anti-Patterns

Catalog-Tag als Zugriffskontrolle behandeln; lokale Rollen als globale Policy definieren; Status ohne Freshness anzeigen; Drift nur jährlich suchen.

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Warehouse modernisieren
• Lernpfad — Warehouse modernisieren

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

Wähle eine Zugriffspolicy, mappe sie auf zwei Durchsetzung-Punkte, verknüpfe technische IDs, simuliere Drift und zeige aktuellen Status samt Evidenz im Catalog.

Drei Ebenen statt Tool-Verwirrung

Trenne Intent, Durchsetzung und Evidence. Der Policy Owner formuliert Intent: Wer darf welche Daten zu welchem Zweck unter welchen Bedingungen nutzen? Lokale Control Planes setzen diesen Intent mit Identitäten, Rollen, Maskierung, Netzwerk- oder Laufzeitregeln um. Der Catalog verbindet Produkt, Owner, Policy, Lineage, Control-Status und Evidenz, damit Menschen den Zustand verstehen und finden können.

Der Catalog darf einen Zugriff anstoßen oder einen Workflow anzeigen, ist dadurch aber nicht automatisch der Durchsetzung-Punkt. 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, Owner, Consumer 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 Scope, 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 Policy Owner muss den fachlichen Intent nicht neu entscheiden. Falls die Plattform eine Anforderung technisch nicht erfüllen kann, geht eine befristete Ausnahme an denselben Policy Owner.

System-of-Record-Matrix

Die Governance Registry oder der vereinbarte Catalog ist autoritativ für Policy-ID, Geschäftsbedeutung, accountable Owner und Ausnahmeentscheidung. Identity Provider sind autoritativ für Personen- und Gruppenmitgliedschaft. Lokale Plattformen sind autoritativ für Durchsetzung-Konfiguration und Laufzeitereignisse. Test- oder Evidence Stores halten detaillierte Resultate. Der Catalog darf diese Zustände spiegeln, muss aber Quelle, Freshness und Synchronisationsfehler anzeigen.

Vermeide bidirektionale Synchronisation ohne Konfliktregel. Wenn zwei Systeme dasselbe Owner-Feld 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, Owner, zwei Durchsetzung-Punkten 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 Evidence-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, Scope, Policy Owner und Ausnahmebefugnis.
3. Inventarisiere reale Durchsetzung-Punkte ü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 Handoff und Eskalation mit Platform Security.
10. Entferne manuelle Statusfelder, die denselben Zustand duplizieren.

Handoffs und Fehlerwege

Der Policy Owner übergibt Intent, Scope, 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 Evidence an Catalog oder Evidence 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 Policy Owner. 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 Durchsetzung-Punkt 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 Owner oder Klassifikation. Benenne eine Write Authority und Fehlerqueue.

Prüfliste

• Intent und technische Konfiguration sind getrennt.
• Richtlinie Owner 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, Owner und Reaktionszeit.
• Ausnahmen haben Ablaufdatum und Risikoakzeptanz.
• Kein Catalog-Feld dupliziert lokale Durchsetzung-Pflege.

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Warehouse modernisieren
• Lernpfad — Warehouse modernisieren

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

Bis Tag 10 wählst du eine Zugriffspolicy und formulierst Intent sowie Owner. Bis Tag 20 mappst du zwei Durchsetzung-Punkte, IDs und Tests. Bis Tag 30 simulierst du Drift und Übertragungsfehler, zeigst den ehrlichen Status im Catalog und dokumentierst den Handoff.

Bis Tag 60 integrierst du fünf weitere kritische Policies, automatisierst Evidence und misst Freshness, Drift-Dauer sowie manuelle Eingriffe. Bis Tag 90 erweiterst du auf eine zweite Domain oder Plattform und veröffentlichst die System-of-Record-Matrix. Skaliert wird nur, wenn unbekannte Zustände sichtbar sind, Ausnahmen zentral entschieden werden und keine Schatten-Control-Plane im Catalog entsteht.

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 Owner, 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 Evidence Store. Definiere Aufbewahrung und Zugriff auch für Evidence 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.