End-to-End-Governance-Architektur

Begriffe vor dem Lesen

• dbt (data build tool) organisiert SQL-basierte Datentransformationen als versionierten Code.
• Metadaten beschreiben Daten, etwa durch Definition, Herkunft, Verantwortung, Qualität und Schutzklasse.
• Ein Datenkatalog macht solche Metadaten auffindbar; er setzt Regeln nicht automatisch technisch durch.
• PII bezeichnet personenbezogene Daten, die eine Person direkt oder zusammen mit weiteren Angaben identifizierbar machen.
• BI (Business Intelligence) umfasst Berichte und Analysen, die governte Datenprodukte nutzen.

Die Beispiele sind Lehrfälle und enthalten keine Kundendaten. Tabellen-, Report-, Pfad- und Toolnamen müssen an die eigene Umgebung angepasst werden.

Governance ist eine Architektur — kein Katalog neben der Plattform

KMU/SMB — ein Produktpfad von Owner-Metadata über Transform, Protection und BI-Evidenz. Mid-Market — explizites führendes System je Metadata-Typ über zwei Plattformen. Enterprise — verbundene Data-/Metadata-/Control-Planes mit Incident-Feedback-Loop.

Ein Katalog und eine Richtlinien-PDF erzeugen noch keine End-to-End-Governance. Merke die Trennung: Metadata beschreibt und steuert; ein Katalog macht Metadata auffindbar und bearbeitbar; ein Dashboard konsumiert trusted Ergebnisse — es ist nicht der Katalog. Operativ wird es erst, wenn eine fachliche Regel in Metadaten, Transformation, Schutz und BI nachvollziehbar ankommt.

Katalog, Klassifikation und Richtlinie sind nützlich. Keines davon erzeugt allein die durchgängige Kette.

Governance wird erst operativ, wenn eine fachliche Entscheidung durch die technische Plattform verfolgt werden kann:

Fachliche Richtlinie
→ freigegebene Metadaten
→ implementierte Transformation
→ Laufzeitkontrolle
→ operativer Nachweis
→ Governance-Review

Endet die Kette nach der Dokumentation, kann die Plattform wissen, dass eine Spalte personenbezogene Daten enthält, ohne diese tatsächlich zu schützen.

Beginnt die Kette erst bei der Laufzeitsicherheit, kann eine Spalte maskiert sein, ohne den fachlichen Grund, die Verantwortung oder den Freigabestatus hinter dieser Kontrolle zu erhalten.

End-to-End-Governance verbindet Entscheidungen, Metadaten, Code, Schutz, Zugriff und Nachweise zu einem kontrollierten System.

Dieser Artikel definiert dieses System. Die folgenden Parts vertiefen einzelne Mechanismen.

Mit einer klaren Verantwortungsgrenze beginnen

Die erste Architekturentscheidung ist einfach, aber wichtig:

Die Ingestion lädt Daten in die Plattform. dbt transformiert Daten, die bereits dort vorhanden sind.

Ein typischer Ablauf lautet:

Quellsysteme
→ Ingestion oder Replikation
→ Landing-Tabellen
→ dbt-Transformation
→ governte Warehouse-Layer
→ governte Nutzung

Der Ingestion-Mechanismus kann ein Managed Connector, ein CDC-Service, eine Orchestrierungspipeline, ein File Loader oder ein eigener Prozess sein.

Zu seinen Verantwortlichkeiten gehören:

• Verbindung zu Quellsystemen;
• Extraktion und Laden von Datensätzen;
• Erhalt technischer Liefermetadaten;
• Wiederholungen und Checkpoints;
• Erkennung fehlgeschlagener oder verspäteter Loads;
• Erstellung oder Aktualisierung physischer Landing-Objekte.

dbt beginnt, nachdem diese physischen Landing-Objekte existieren.

Zu den dbt-Verantwortlichkeiten gehören:

• Deklaration von Sources;
• Transformation quellsystemnaher Daten;
• Tests und Vereinbarungen;
• Lineage;
• Dokumentation und Artefakte;
• Materialisierung governter Modelle;
• Bereitstellung von Metadaten für nachgelagerte Automatisierung.

Werden beide Themen in einer gemeinsamen Prozessbox zusammengefasst, werden Verantwortung und Fehleranalyse unnötig unklar.

Die Architektur besteht aus drei verbundenen Ebenen

Eine governte Plattform wird verständlicher, wenn sie in drei Ebenen aufgeteilt wird.

1. Data Plane

Die Data Plane enthält die physischen und logischen Datenprodukte:

Landing
→ RAW
→ Conform
→ Analytics
→ Anwendungen

Jeder Layer besitzt eine andere Verantwortung.

Die Bezeichnungen können je Plattform abweichen. Entscheidend ist die Trennung der Verantwortlichkeiten.

2. Metadata Plane

Die Metadata Plane beschreibt die Data Plane.

Sie enthält unter anderem:

• physische Schemas und Datentypen;
• Source- und Modellbeschreibungen;
• Verantwortung und Domäne;
• Spaltenklassifikation;
• Sensitivität und Aufbewahrung;
• Lineage und Abhängigkeiten;
• Data-Quality-Ergebnisse;
• Freshness und Betriebsstatus;
• generierte Dokumentation;
• Warehouse-Tags und Richtlinie-Referenzen.

Metadaten können über dbt-YAML, dbt-Artefakte, Warehouse-Tags, Kataloge, Berechtigungstabellen und operative Systeme verteilt sein.

Die Architektur benötigt deshalb einen expliziten Vertrag, der festlegt, welches System für welche Metadatenart führend ist.

3. Control Plane

Die Control Plane überführt Entscheidungen in erzwungenes Verhalten.

Sie umfasst:

• Richtlinien und Standards;
• Freigabeprozesse;
• CI-Validierung;
• Datentests und Vereinbarungen;
• Deployment-Kontrollen;
• Masking Richtlinien;
• Row Access Richtlinien;
• Rollen und Berechtigungs;
• Qlik Section Access;
• Audit- und Incident-Prozesse.

Ein Katalog kann eine Kontrolle beschreiben. Die Control Plane setzt sie um und überprüft sie.

Governance-Entscheidungen benötigen einen technischen Vertrag

Eine Richtlinie wie „Die E-Mail-Adresse des Kunden ist vertrauliche personenbezogene Information“ ist für Automatisierung zu abstrakt.

Die Plattform benötigt eine maschinenlesbare Darstellung:

columns:
  - name: email
    config:
      meta:
        pii: true
        pii_category: email
        sensitivity: confidential
        classification_status: approved
        masking_policy: email_mask
        data_owner: customer_operations
        steward: data_governance

Diese Metadaten schützen die Spalte nicht selbstständig.

Sie bilden einen technischen Vertrag, der:

• in Git geprüft;
• in CI validiert;
• in dbt-Artefakte kompiliert;
• in der Dokumentation angezeigt;
• durch Generierungs- und Propagierungslogik verwendet;
• auf Warehouse-Tags und Richtlinien abgebildet;
• mit der Laufzeitimplementierung verglichen;
• als Review-Nachweis genutzt werden kann.

Part 2 definiert diesen Vertrag im Detail.

Klassifikation und Durchsetzung sind unterschiedliche Verantwortlichkeiten

Eine Klassifikation beantwortet:

Welche Art von Daten ist das?
Wie sensibel sind sie?
Wer verantwortet die Entscheidung?
Welche Behandlung wurde freigegeben?

Die Durchsetzung beantwortet:

Was darf die aktuelle Identität sehen?
Welche Zeilen sind erlaubt?
Welche Werte müssen maskiert werden?
Welche Anwendung darf die Daten nutzen?

Beides muss verbunden werden, darf aber nicht verwechselt werden.

Eine belastbare Architektur trennt mindestens zwei Schutzdimensionen.

Spaltenschutz

Der Spaltenschutz steuert die Darstellung sensibler Werte.

Beispiele:

• vollständige Maskierung;
• Teilmaskierung;
• Hashing;
• Tokenisierung;
• Ersetzung durch null;
• rollenabhängiger Klartext.

Snowflake Dynamic Data Masking wendet Masking Policies zur Abfragezeit auf Spalten an. Tag-basiertes Masking kann Object Tags und Masking Policies verbinden, sodass markierte Spalten entsprechend der gültigen Policy und des Datentyps geschützt werden.

Zeilenbasierter Zugriff

Zeilenbasierter Zugriff entscheidet, welche Datensätze sichtbar sind.

Beispiele:

• Region;
• Gesellschaft;
• Abteilung;
• Kundenportfolio;
• Mandant;
• Vertragsbereich.

Snowflake Row Access Policies können diese Filterung zentral im Warehouse erzwingen.

Qlik Section Access kann innerhalb einer Anwendung eine dynamische Datenreduktion anwenden, indem Benutzerberechtigungen mit Reduktionsfeldern im Datenmodell verbunden werden.

Beide Kontrollen können sich ergänzen:

Warehouse Policy
→ schützt das governte Datenprodukt zentral

Qlik Section Access
→ begrenzt die Anwendungszeilen für Nutzer und Use Case

Qlik darf nicht der einzige Ort sein, an dem sensible Daten geschützt werden. Ein Nutzer oder Service mit direktem Warehouse-Zugriff würde eine rein anwendungsseitige Kontrolle umgehen.

Governance-Verantwortlichkeiten nach Rolle

Governance scheitert, wenn jedes Team davon ausgeht, dass ein anderes Team die endgültige Entscheidung trifft.

Ein praktikables Verantwortung-Modell unterscheidet folgende Rollen.

Data Owner

Der Data Owner genehmigt die fachliche Nutzung der Daten.

Typische Entscheidungen:

• erlaubte Zwecke;
• Domänenverantwortung;
• Sensitivität;
• Aufbewahrung;
• externe Weitergabe;
• akzeptables fachliches Risiko.

Data Steward

Der Steward pflegt die Klassifikation und stellt die konsistente Verwendung des Governance-Vokabulars sicher.

Typische Verantwortlichkeiten:

• Beschreibungen und Glossar-Abgleich;
• personenbezogene Daten-Kategorie;
• Klassifikationsstatus;
• Review-Datum;
• Koordination von Issues;
• Freigabenachweise.

Data Engineering oder Platform Engineering

Engineering implementiert das governte Datenprodukt.

Typische Verantwortlichkeiten:

• Source-Deklarationen;
• Transformationen;
• Tests und Vereinbarungen;
• Metadatenintegration;
• Deployment;
• Lineage;
• technische Richtlinie-Anbindung;
• Drift-Erkennung.

Engineering kann eine wahrscheinliche PII-Spalte erkennen, darf die Klassifikation aber nicht stillschweigend freigeben.

Security und Privacy

Security und Privacy definieren Schutzstandards und genehmigen risikoreiche Kontrollen.

Typische Verantwortlichkeiten:

• Maskierungsmuster;
• Richtlinie-Administration;
• Rollendesign;
• Funktionstrennung;
• Datenschutzanforderungen;
• Access Reviews;
• Incident Handling.

BI- oder Application Owner

Der Application Owner implementiert nutzungsspezifische Zugriffskontrollen.

Typische Verantwortlichkeiten:

• App-Zugriff;
• Section Access;
• Reduktionsfelder;
• freigegebene Exporte;
• Visualisierungsverhalten;
• Nutzerkommunikation;
• Anwendungsmonitoring.

Die Übergaben zwischen diesen Rollen müssen sichtbar sein. Ein Feld kann gleichzeitig einen Business Owner, einen Custodian und einen Application Owner besitzen.

Qualität ist Teil der Governance

Governance beschränkt sich nicht auf PII und Berechtigungen.

Ein Datenprodukt ist nicht vertrauenswürdig, wenn seine Verantwortung dokumentiert ist, seine Werte aber verspätet, unvollständig oder strukturell ungültig sind.

Die Architektur sollte Governance-Metadaten deshalb verbinden mit:

• Source Freshness;
• Not-null- und Unique-Erwartungen;
• referenzieller Integrität;
• erlaubten Werten;
• Volumenanomalien;
• Vereinbarung-Prüfungen;
• Abstimmungen;
• fachlicher Regelvalidierung;
• Incident-Schweregrad;
• Quality Verantwortung.

Nicht jeder Test ist gleich wichtig.

Ein praktikables Modell weist Quality Tier oder Kritikalität zu:

config:
  meta:
    quality_tier: critical
    criticality: tier_1
    custodian: data_platform

CI und Orchestrierung können für kritische Modelle strengere Gates anwenden als für explorative Modelle.

Lineage liefert Impact — aber keine automatische Verantwortlichkeit

Lineage beantwortet Fragen wie:

• Welche Quelle speist diese Kennzahl?
• Welche Modelle hängen von dieser Spalte ab?
• Welche Anwendungen könnten von einer Änderung betroffen sein?
• Wohin muss eine Klassifikation propagiert werden?
• Welche Kontrollen sollten downstream vorhanden sein?

Lineage entscheidet nicht, ob eine nachgelagerte Transformation die Klassifikation erhält oder verändert.

Beispiel:

email
→ lower(email)

bleibt üblicherweise personenbezogen.

Dagegen kann:

email
→ count(distinct email)

ein nicht personenbezogenes Aggregat erzeugen — abhängig von Granularität, Filtern und Offenlegungsrisiko.

Part 4 behandelt genau dieses Propagierungs- und Auflösungsproblem.

Nachweise schließen den Governance-Regelkreis

Eine Policy-Implementierung muss Nachweise erzeugen.

Nützliche Nachweise sind:

• freigegebene Pull Requests;
• Ergebnisse der Metadatenvalidierung;
• dbt-Testergebnisse;
• Manifest- und Katalog-Artefakte;
• Lineage-Snapshots;
• Richtlinie-Referenzen;
• Access Reviews;
• Query- und Zugriffslogs;
• Schema-Drift-Ereignisse;
• Incidents und Ausnahmen;
• Review-Daten.

Die Nachweise sollten drei Fragen beantworten:

Was wurde freigegeben?
Was wurde implementiert?
Was ist zur Laufzeit geschehen?

Können diese Antworten nicht verbunden werden, existiert Dokumentation, aber keine auditierbare Governance.

Eine minimal tragfähige Governance-Architektur

Eine erste Umsetzung benötigt nicht jede Enterprise-Funktion.

Sie benötigt einen vollständigen Kontrollpfad.

Eine minimal tragfähige Architektur kann enthalten:

1. Definiertes Governance-Vokabular

   • Owner;
   • Domäne;
   • PII;
   • Sensitivität;
   • Klassifikationsstatus;
   • Aufbewahrungsklasse;
   • Schutz-Policy.

2. Versionierte Metadaten

   • dbt-YAML;
   • Code Review;
   • explizite Freigabeverantwortliche.

3. Automatisierte Validierung

   • Pflichtfelder;
   • erlaubte Werte;
   • PII-Policy-Prüfungen;
   • Prüfung ungeprüfter Spalten.

4. Governte Transformationen

   • Source-Deklarationen;
   • Tests;
   • Lineage;
   • klare Layer-Verantwortlichkeiten.

5. Laufzeitkontrollen

   • Warehouse-Rollen;
   • Masking;
   • zeilenbasierter Zugriff;
   • Anwendungsberechtigungen.

6. Operative Nachweise

   • Build-Ergebnisse;
   • Policy-Referenzen;
   • Access Review;
   • Incident-Prozess.

Das ist stärker als ein großer Katalog ohne Verbindung zu Delivery und Durchsetzung.

Häufige Architekturfehler

Governance-Metadaten existieren nur im Katalog

Code und Laufzeitplattform können sie nicht zuverlässig konsumieren.

Metadaten existieren nur in dbt

Fachbereiche und Stewards können sie nicht wirksam prüfen und steuern.

PII wird automatisch erkannt und als freigegeben behandelt

Erkennung ist ein Hinweis für das Review, keine Governance-Entscheidung.

Zugriff wird ausschließlich in Qlik umgesetzt

Warehouse-Zugriffe außerhalb der Anwendung bleiben unzureichend geschützt.

Jede Regel ist direkt in SQL eingebettet

Policy-Pflege wird dupliziert und schwer auditierbar.

Metadaten werden ohne Transformationsverständnis kopiert

Abgeleitete Spalten übernehmen falsche Klassifikationen oder verlieren sensible Lineage.

Ingestion, Transformation und Governance werden als eine Tool-Verantwortung betrachtet

Fehler, Verantwortung und Kontrollgrenzen werden unklar.

Die zentrale Erkenntnis

Eine governte Datenplattform ist keine Abfolge von Tools. Sie ist ein verbundenes System aus Entscheidungen, Metadatenverträgen, Transformationen, Laufzeitkontrollen und Nachweisen.

Part 2, Metadatengetriebene Governance mit dbt meta, überführt den Architekturvertrag in ein konkretes, versioniertes Metadatenmodell in dbt.

Quellen und weiterführende Dokumentation

• dbt — meta configuration
• dbt — manifest JSON
• dbt — about dbt artifacts
• Snowflake — Dynamic Data Masking
• Snowflake — Tag-based masking policies
• Snowflake — Row access policies
• Qlik Sense — Managing data security with Section Access