Data Governance auf GCP 2026: Wer darf diese Daten sehen?

“Wer darf diese Daten sehen?” klingt wie eine Frage in einer Zeile. In einer echten Organisation sind es vier Fragen im Trenchcoat, und wer nicht alle vier beantworten kann, hat keine Data Governance — sondern eine Tabelle voller guter Vorsätze.

Jedes regulierte Audit, jedes “Darf Marketing die Kundentabelle abfragen”-Ticket, jede Breach-Nachbetrachtung führt auf dieselben vier Dinge zurück:

1. Welche Daten haben wir überhaupt?
2. Wo darin liegt das Sensible?
3. Wer darf es sehen?
4. Kann es das System verlassen?

Die gute Nachricht auf Google Cloud: Jede Frage hat eine dedizierte, ausgereifte Antwort — und der Trick besteht darin, zu wissen, welcher Dienst welche Frage beantwortet und wie sie ineinandergreifen. Dies ist eine praxisnahe, aktuelle Landkarte für Platform- und Data-Engineers, die Governance ausliefern müssen, nicht nur darüber reden.

Das Fundament: IAM ist keine Governance (aber alles steht darauf)

Vor den vier Fragen eine Erinnerung: Identity and Access Management ist der Boden, nicht das Gebäude. IAM entscheidet, wer welche API aufrufen und welches Dataset anfassen darf. Es ist notwendig, es ist der Ort, an dem sich jede Zugriffsentscheidung letztlich auflöst — und für sich allein viel zu grob. “Gib dem Analytics-Team die Rolle BigQuery Data Viewer auf diesem Dataset” ist eine Alles-oder-nichts-Vergabe: Sie sehen jede Spalte, auch die mit den Ausweisnummern darin.

Governance ist das, was Sie auf IAM aufbauen, um Zugriff präzise, auffindbar, klassifiziert und eingedämmt zu machen. Also los.

Frage 1 — Welche Daten haben wir? (Knowledge Catalog)

Man kann nicht steuern, was man nicht sieht. Die erste Säule jedes Governance-Programms ist ein Katalog: ein einziges, durchsuchbares Inventar jeder Tabelle, View, jedes Streams und jeder Datei über den gesamten Bestand, angereichert mit fachlicher Bedeutung.

Auf Google Cloud ist das Knowledge Catalog — der Dienst, der früher Dataplex Universal Catalog hieß (umbenannt im April 2026; die gcloud dataplex-Befehle, APIs und IAM-Namen sind unverändert, bestehende Setups laufen weiter). Er ingestiert automatisch technische Metadaten aus BigQuery, Spanner, Bigtable, Pub/Sub, Cloud Storage, AlloyDB, Cloud SQL, Vertex AI und mehr und bietet:

• Einen durchsuchbaren Katalog mit facettierter und natürlichsprachlicher Suche über den gesamten Bestand.
• Ein Business-Glossar, damit “Lifetime Value” oder “aktiver Kunde” eine einzige, einmal definierte Bedeutung hat.
• Automatische Datenqualität und Profiling — Regeln, die prüfen, ob Lieferadressen vollständig sind oder die Werte einer Spalte driften.
• Durchgängige Data Lineage — ein Graph, der zeigt, wie eine Spalte in einem Dashboard über jede Transformation zurück zur Quelltabelle führt, Gold für Pipeline-Debugging und Compliance-Nachweise.

Den Lineage-Graph unterschätzen die meisten. Wenn ein Auditor fragt “Woher kommt diese Zahl?” oder ein Engineer “Was bricht, wenn ich diese Spalte lösche?”, antwortet Lineage in Sekunden statt in einer Woche Archäologie.

Frage 2 — Wo liegen die sensiblen Daten? (Sensitive Data Protection)

Ein Katalog sagt Ihnen, dass eine Tabelle customers existiert. Er sagt Ihnen nicht, dass die Freitext-Spalte notes voller Telefonnummern steckt und der einen oder anderen Kreditkartennummer, die ein Support-Mitarbeiter hineinkopiert hat. Das zu finden ist eine andere Aufgabe und gehört zu Sensitive Data Protection — dem Dienst, der früher Cloud DLP hieß (die API ist weiterhin die Cloud Data Loss Prevention API).

Drei Aufgaben lohnen sich zu kennen:

• Discovery erzeugt Datenprofile über eine Organisation, einen Ordner oder ein Projekt — eine laufend aktualisierte Karte, welche Tabellen und Spalten sensible, risikoreiche Daten enthalten, nach Sensitivität bewertet. Das ist der Scan, den Sie zuerst fahren.
• Inspection führt einen Tiefenscan einer Ressource nach bestimmten infoTypes durch (SSN, E-Mail, Kreditkartennummer und Hunderte mehr) und meldet Ort und Anzahl jedes Treffers. Nützlich für unstrukturierten Text, in dem PII sporadisch versteckt ist.
• De-Identification verschleiert die Daten selbst — Maskierung, Redaction, Bucketing, Date-Shifting oder Tokenisierung — sodass Sie eine sicher teilbare Kopie erzeugen oder zur Abfragezeit de-identifizieren können.

Warum diese Säule für die Zugriffskontrolle zählt, liegt an der Übergabe: Die Spalten-Datenprofile von Sensitive Data Protection sagen Ihnen genau, welche Spalten gesperrt werden müssen. Sie raten nicht, welche Spalten sensibel sind; Sie lassen Discovery sie finden und taggen sie dann. Das ist Frage 3.

Frage 3 — Wer darf es sehen? (BigQuery Spaltensicherheit)

Hier ist das Herz von “Wer darf diese Daten sehen”. In BigQuery erzwingen Sie Zugriff auf Spaltenebene mit einer Taxonomie aus Policy Tags plus IAM.

Der Ablauf hat vier Schritte:

1. Taxonomie und Policy Tags definieren. Ein Data Steward erstellt eine Klassifizierungshierarchie — etwa eine Taxonomie Business criticality mit Knoten High und Medium und Leaf-Tags wie employee_ssn. Eine Taxonomie kann bis zu fünf Ebenen tief sein.
2. Policy Tags Spalten zuweisen. Im Tabellenschema hängen Sie jeder sensiblen Spalte ein Policy Tag an. Eine Spalte trägt genau ein Policy Tag.
3. Zugriffskontrolle aktivieren auf der Taxonomie, damit die Einschränkungen wirksam werden.
4. Zugriff mit IAM verwalten. Vergeben Sie die Rolle Data Catalog Fine-Grained Reader (datacatalog.categoryFineGrainedReader) auf jedem Policy Tag an die Gruppen, die diese Spalten lesen dürfen.

Die Durchsetzung ist der wichtige Teil. Der Zugriff auf Spaltenebene wird zusätzlich zur Dataset-ACL geprüft — ein Nutzer braucht sowohl Dataset-Berechtigung als auch die Fine-Grained-Reader-Rolle auf dem Tag. Hat er Dataset-Zugriff, aber nicht das Tag, scheitert ein SELECT * mit einem Fehler, der genau die Spalten auflistet, die er nicht lesen kann, und er muss sie entweder ausschließen (SELECT * EXCEPT (ssn)) oder Zugriff anfordern.

So bindet die Schema-Annotation eine Spalte an ein Policy Tag:

[
  { "name": "customer_id", "type": "STRING", "mode": "REQUIRED" },
  { "name": "email",       "type": "STRING", "mode": "NULLABLE" },
  {
    "name": "ssn",
    "type": "STRING",
    "mode": "NULLABLE",
    "policyTags": {
      "names": [
        "projects/PROJECT_ID/locations/us/taxonomies/TAXONOMY_ID/policyTags/POLICYTAG_ID"
      ]
    }
  }
]

# Schema (mit Policy Tag) auf eine bestehende Tabelle anwenden
bq update PROJECT_ID:dataset.customers schema.json

# Einer Gruppe Fine-Grained-Read auf das "High"-Policy-Tag geben
gcloud data-catalog taxonomies policy-tags add-iam-policy-binding POLICYTAG_ID \
  --taxonomy=TAXONOMY_ID --location=us \
  --member="group:pii-approved@example.com" \
  --role="roles/datacatalog.categoryFineGrainedReader"

Dynamische Datenmaskierung ist das sanftere Geschwister. Statt eines harten Fehlers konfigurieren Sie eine Maskierungsregel auf einem Policy Tag, sodass unbefugte Nutzer einen NULL-, Default- oder Hash-Wert anstelle des echten erhalten. Das lässt einen Betrugsanalysten eine gehashte Kartennummer für Joins sehen, ohne je die echten Ziffern zu kennen — teilweiser Zugriff statt Alles-oder-nichts. Jeder Lesezugriff auf eine getaggte Spalte wird in Cloud Logging geschrieben, sodass Auditoren rekonstruieren können, wer auf welche Klasse sensibler Daten zugegriffen hat.

Frage 4 — Kann es das System verlassen? (VPC Service Controls)

Die ersten drei Fragen steuern Zugriff innerhalb Ihres Projekts. Die letzte betrifft die Mauer darum. Selbst mit perfektem IAM und perfekten Policy Tags kann ein gestohlener Service-Account-Schlüssel oder eine zu breite Vergabe jemanden ein ganzes Dataset in ein privates Projekt kopieren lassen. VPC Service Controls existiert, um genau das unmöglich zu machen.

Es zieht einen Service-Perimeter um Ihre Google-verwalteten Ressourcen (BigQuery, Cloud Storage und viele weitere). Innerhalb des Perimeters ist Kommunikation frei; über ihn hinweg ist standardmäßig alles verweigert. Konkret blockiert es genau die Exfiltrationszüge, die IAM zulassen würde:

• Ein bq-Copy oder gcloud storage cp in einen Bucket oder eine Tabelle außerhalb des Perimeters scheitert.
• Ein Client mit gestohlenen Credentials aus einem nicht autorisierten Netzwerk wird abgewiesen, weil Zugriff an Netzwerkherkunft und Kontext gebunden ist, nicht nur an Identität.
• Ingress- und Egress-Regeln und Access Levels (über Access Context Manager) lassen Sie präzise, kontextbewusste Öffnungen schaffen — dieser IP-Bereich, diese Identität, dieser Gerätezustand — ohne die Mauer fallen zu lassen.

Das von Google empfohlene Modell ist Defense in Depth: IAM ist identitätsbasierte Zugriffskontrolle; VPC Service Controls ist kontextbasierte Perimeterkontrolle. Sie wollen beides. Und Sie können es sicher ausrollen mit dem Dry-Run-Modus, der protokolliert, was blockiert würde, ohne tatsächlich zu blockieren, sodass Sie jeden legitimen Datenfluss finden, bevor Sie durchsetzen.

Das Gesamtbild, eine Tabelle

Jede Säule beantwortet eine andere Frage. So ordnen sie sich ein:

Beachten Sie die Arbeitsteilung: Katalog und Profiler informieren, IAM und Policy Tags autorisieren, der Perimeter dämmt ein. Lassen Sie eines weg, und Sie haben eine sichtbare Lücke — ein unkatalogisierter Data Lake, unklassifizierte PII, Alles-oder-nichts-Spalten oder eine offene Tür zur Exfiltration.

Wo anfangen (eine Entscheidungshilfe)

Sie deployen nicht alle vier auf einmal. Governance ist ein Reifepfad, und der richtige erste Schritt hängt davon ab, was heute am meisten weh tut.

• “Wir wissen nicht mal, was wir haben.” Starten Sie mit Knowledge Catalog. Schalten Sie automatische Metadaten-Ingestion ein, bringen Sie den Bestand an einen durchsuchbaren Ort und aktivieren Sie Lineage. Alles andere wird leichter, sobald Sie die Karte sehen.
• “Wir kennen unsere Tabellen, aber nicht, wo die PII ist.” Fahren Sie Sensitive-Data-Protection-Discovery über die Organisation. Lassen Sie jede Tabelle profilieren und die Hochrisiko-Spalten auftauchen. Jetzt haben Sie eine priorisierte Liste dessen, was zu schützen ist.
• “Zugriff ist Alles-oder-nichts und das Audit hasst es.” Implementieren Sie BigQuery Spaltensicherheit. Bauen Sie eine kleine Taxonomie (starten Sie mit zwei oder drei Klassifizierungsebenen), taggen Sie die von Discovery markierten Spalten und vergeben Sie Fine-Grained-Read an die richtigen Gruppen. Ergänzen Sie dynamische Maskierung, wo teilweiser Zugriff nützlich ist.
• “Unser echtes Risiko ist, dass Daten aus der Tür spazieren.” Stellen Sie VPC Service Controls im Dry-Run-Modus auf, kartieren Sie jeden legitimen Fluss und setzen Sie dann durch. Das ist die Kontrolle, die einen gestohlenen Schlüssel überlebt.

Die meisten Teams machen am Ende alle vier, ungefähr in dieser Reihenfolge — weil Sie Daten sehen müssen, bevor Sie sie klassifizieren, sie klassifizieren, bevor Sie sie präzise einschränken, und sie einschränken, bevor ein Perimeter mehr ist als eine stumpfe Mauer.

Das ehrliche Fazit

Data Governance auf Google Cloud ist kein Produkt, das Sie kaufen; es ist eine Haltung, die Sie zusammensetzen aus IAM, Knowledge Catalog, Sensitive Data Protection, BigQuery Policy Tags und VPC Service Controls. Die Plattformen sind ausgereift und greifen sauber ineinander — der Discovery-Profiler reicht der Zugriffsebene buchstäblich eine Liste zu schützender Spalten, und der Perimeter deckt IAM ab, wenn IAM unweigerlich einen schlechten Tag hat.

Der häufigste Fehler, den ich sehe, ist, Governance als einzelne Zugriffskontrollaufgabe zu behandeln — “setz einfach die IAM-Rollen”. Das beantwortet eine der vier Fragen. Beantworten Sie alle vier, verdrahten Sie sie über SSO und Gruppen mit Ihrer Unternehmensidentität, und “Wer darf diese Daten sehen?” ist kein Gerangel mehr vor jedem Audit, sondern eine Eigenschaft der Plattform. Genau darum geht es.

Wenn Ihnen das gefallen hat: Die Begleitartikel zu Secure-by-Default GKE und benutzerbezogener MCP-Tool-Zugriffskontrolle wenden dieselbe Idee “Kontrolle folgt der Identität” auf Compute und KI-Tooling an.