BigQuery als Governance-Einstieg

Begriffe vor dem Lesen

• Transferprüfung — Transfer Impact Assessment: Prüfung, ob ein Datentransfer in ein Drittland mit Schutzmaßnahmen vertretbar ist.

Herausforderung

BigQuery kann ein starker Governance-Einstieg sein, wenn die vorhandene Landschaft GCP-nativ ist und der erste governede Use Case auf serverloser analytischer Verarbeitung, governeden Datasets, SQL Products, Data Sharing oder BI Consumption basiert. Google Cloud stellt dafür eine breite Control Surface bereit: Resource Hierarchy, BigQuery Datasets und Objects, IAM, Row- und Column-Level Controls, Data Masking, Audit Logs, Knowledge Catalog, Lineage, Data Quality, Reservations und Service Perimeters.

Diese Fähigkeiten entfernen keine Governance-Entscheidungen. Serverless Operation reduziert Infrastrukturadministration; sie entscheidet nicht über Business Purpose, Data Verantwortung, Permitted Use, Residency, Export Boundaries, Incident Verantwortung oder Kostenverantwortung.

Die relevante Frage lautet deshalb nicht:

Kann BigQuery analytische Daten speichern, abfragen und schützen?

Sondern:

Kann die Organisation ein wertvolles Dataset oder Analytics Product von der Quelle bis zum Consumer governen und dabei Verantwortung, Effective Access, Region, Export, Quality Evidence und Kostenverantwortung explizit halten?

Vier Fehlmuster treten regelmäßig auf.

Project Structure wird mit einem Governance-Modell verwechselt

Google Cloud Organizations, Folders und Projects sind wichtige administrative und Policy Boundaries. BigQuery ergänzt Datasets als weitere Gruppierungs- und Location-Grenze. Keines dieser Objects etabliert automatisch eine Business Domain, einen verantwortlichen Data Owner oder einen freigegebenen Product Scope. Ein Project kann unabhängige Workloads enthalten, und ein Business Product kann mehrere Projects überspannen.

Technischer Zugriff wird mit Permitted Use verwechselt

IAM, Dataset Permissions, Authorized Views, Row-Level Access Policies, Column-Level Access Control und Masking können einschränken, was eine Identity abfragen darf. Sie entscheiden nicht, ob der Purpose genehmigt ist, ob ein Export erlaubt ist, ob eine Downstream Copy aufbewahrt werden darf oder ob ein neuer Consumer Context eine Recertification benötigt.

Serverless wird mit ownerless verwechselt

BigQuery entfernt Capacity Planning für On-Demand Workloads und kann Reservation-basierte Capacity skalieren. Jobs verbrauchen trotzdem Geld, Quotas und operative Aufmerksamkeit. Production Datasets, Reservations, Assignments, Exports und wiederkehrende Transformationen benötigen benannte Owner und Eskalationspfade.

Native Lineage wird mit vollständiger Evidenz verwechselt

Knowledge Catalog und BigQuery können Lineage für unterstützte Services und Processing Paths erfassen und anzeigen. Externe Quellen, lokale Dateien, unmanaged Exports, nicht integrierte Transformation Tools, Semantic Models und Downstream Consumers können außerhalb des Graphen bleiben. Fehlende Kanten müssen integriert, dokumentiert oder als explizite Gaps akzeptiert werden.

Das Governance Design muss drei Ebenen verbinden:

BigQuery implementiert und belegt Controls. Verantwortliche Rollen bleiben für die zugrunde liegenden Entscheidungen zuständig.

Ansatz

Nutze BigQuery als Governance-Einstieg, wenn der erste governede Use Case von GCP-nativer serverloser Analytics profitiert und die Organisation Cloud-, Dataset-, Identity-, Protection-, Evidence-, Region-, Export- und Cost Boundaries als ein zusammenhängendes Modell betreiben kann.

Eine positive Entscheidung hat normalerweise die meisten der folgenden Merkmale:

• Google Cloud ist bereits eine akzeptierte strategische oder operative Umgebung.
• Das erste Product ist SQL-, BI-, Sharing- oder Analytics-zentriert.
• Google Cloud Zugriffsverwaltung Groups und Service Accounts können über einen zuverlässigen Lifecycle governed werden.
• Organization-, Folder-, Project-, Dataset- und Environment-Grenzen können bewusst entworfen werden.
• Dataset Locations und verbundene Services erfüllen Residency- und Processing-Anforderungen.
• Fine-Grained Access und Masking können mit echten Identities und Consumption Paths getestet werden.
• Knowledge Catalog kann die erforderlichen Business- und technischen Metadaten halten oder synchronisieren.
• Lineage und Quality Nachweis decken die relevante Source-to-Nutzer-Kette ab.
• Exports, Copies und Sharing werden governed statt als unsichtbares Downstream-Verhalten behandelt.
• On-Demand Spend oder Reservation Capacity kann Products, Teams oder Cost Centern zugeordnet werden.

BigQuery sollte nicht nur gewählt werden, weil es serverless ist oder bereits in einem Google Cloud Account verfügbar ist. Ein vorhandenes Warehouse, eine Semantic Layer oder eine BI Platform kann die bessere No-New-Platform-Alternative sein, wenn die eigentlichen Lücken bei Verantwortung, Metric Governance, Dokumentation oder Operating Discipline liegen.

1. Resource- und Dataset-Hierarchie vor dem Laden entwerfen

BigQuery übernimmt die Google Cloud Resource Hierarchy und ergänzt Datasets unterhalb von Projects. Die Hierarchie soll Operating Decisions übersetzen und nicht mechanisch ein Organigramm spiegeln.

Eine Dataset Location wird bei der Erstellung gewählt und kann nicht einfach in place geändert werden. Location gehört deshalb in die Readiness-Entscheidung – zusammen mit Source Location, Transformation Services, Reservations, Policy Resources, Sharing Patterns und Downstream Tools.

Environment Separation kann Projects, Datasets oder eine kontrollierte Kombination nutzen. Die Auswahl muss auf Isolation, Deployment, IAM, Evidence, Billing und Recovery beruhen und nicht nur auf Naming Conventions.

2. Business Verantwortung von Cloud Administration trennen

Ein minimales Operating Model unterscheidet diese Verantwortungen:

Eine Person kann mehrere Rollen halten, aber die Entscheidungen müssen unterscheidbar bleiben. Der Principal, der eine Role vergeben kann, darf nicht stillschweigend zum Genehmiger des Business Purpose werden.

3. Effective Access über alle Control Levels prüfen

Die Access Chain ist breiter als eine Table Permission:

Identity und Groups
→ Organization-, Folder- und Project-Roles
→ Dataset Access
→ Table- oder Authorized-View-Access
→ Row-Level Access Policy
→ Column Policy oder Masking
→ Query- und Export-Pfad
→ Audit Evidence

Für jedes governede Product werden dokumentiert:

• genehmigter Business Purpose;
• Human Groups und Service Accounts;
• verantwortliche Person jeder Group;
• Project- und Dataset-Inheritance;
• Direct Grants und Authorized Resources;
• Row-Richtlinie-Conditions;
• Richtlinie Tags, Data Richtlinien oder Masking Rules;
• privilegierte administrative Pfade;
• Export-, Exportdatei-, Copy- und Sharing-Permissions;
• Exception Approver und Expiry;
• Recertification Trigger.

Effective-Access-Tests müssen benannte Test Identities und erwartete Ergebnisse nutzen. Ein Role Inventory ohne Query-Path-Validierung ist keine ausreichende Evidenz.

4. Klassifizierung, Protection und Export als einen Workflow behandeln

Eine governede Protection Chain muss explizit sein:

Business Classification
→ freigegebener Metadata Term oder Tag
→ Policy Selection
→ IAM- und Data-Policy-Implementation
→ Row Restriction, Column Access oder Masking
→ Effective-Query-Test
→ Export- und Sharing-Test
→ Audit Evidence
→ Recertification

Column-Level Access Control kann Zugriff über Policy Tags beschränken, und Dynamic Data Masking kann ausgewählte Werte für definierte Principals verschleiern. Row-Level Access Policies können Zeilen anhand von Identity Conditions filtern. Diese Controls ergänzen sich, governen aber Exports oder Downstream Copies nicht automatisch.

VPC Service Controls können einen von IAM unabhängigen Service Perimeter ergänzen und Ingress- sowie Egress-Pfade einschließlich ausgewählter Export-Szenarien beschränken. Perimeter, unterstützte Services, Dry-Run-Validierung, Exceptions und Operational Verantwortung müssen Teil des Designs sein. Der Perimeter ersetzt weder Least-Privilege IAM noch Permitted-Use-Freigaben.

5. End-to-End-Evidenz statt isolierter Plattform-Screenshots aufbauen

Die Evidence Chain sollte abdecken:

Source
→ Ingestion oder Federation
→ Transformation
→ governed Dataset
→ Analytical Product oder Semantic Model
→ BI-, API-, Sharing- oder AI-Consumer

An jeder Stufe werden aufbewahrt:

• stabiler Asset Identifier;
• Owner und Steward;
• Source Authority und fachliche Ebene;
• Classification und Permitted Use;
• Access-Richtlinie-Referenz;
• Lineage Link;
• Quality Rules und aktueller Status;
• Deployment- oder Job-Version;
• Location und Retention Rule;
• Incident Route;
• Cost Attribution;
• Change Approval.

Knowledge Catalog kann zentrale Discovery, Business Glossary, Metadata, Lineage und Data Quality bereitstellen. Diese Funktionen müssen mit einem Operating Workflow verbunden werden: Wer schlägt Metadata vor, wer validiert sie, wer genehmigt sie, wie werden Konflikte aufgelöst und wann erfolgt das Review?

Audit Logs beantworten, wer was wann und wo getan hat. INFORMATION_SCHEMA Views beantworten operative und Usage-Fragen. Quality Results zeigen, ob vereinbarte Rules bestanden wurden. Diese Evidenztypen ergänzen sich und dürfen nicht in einer generischen Aussage wie „Monitoring vorhanden“ zusammenfallen.

6. Kosten- und Capacity-Verantwortung in die Readiness aufnehmen

BigQuery kann On-Demand Pricing oder Reservation-basierte Capacity nutzen. Reservations können Production-, Test-, Business-Unit- oder andere Workloads isolieren, und Assignments verbinden Projects, Folders oder eine Organization mit Capacity Pools.

Das Governance-Modell definiert:

• Billing Project und Cost verantwortliche Person;
• On-Demand- oder Reservation-Entscheidung;
• Edition- und regionale Anforderungen;
• Reservation Administration Project;
• Project-, Folder- oder Organization-Assignments;
• Baseline- und Autoscaling-Limits, wenn genutzt;
• Isolation von Production und Development;
• Labels oder einen anderen Attribution-Mechanismus;
• Budget Thresholds und Eskalation;
• verantwortliche Person für fehlgeschlagene, ineffiziente oder runaway Workloads.

Eine serverlose Query ohne Cost Owner bleibt eine unmanaged Production Activity.

Checkliste

Kontext und Scope

• Ist der erste governede Use Case benannt und begrenzt?
• Sind Dataset, Analytical Product und Nutzer explizit?
• Ist der aktuelle Organization-, Folder-, Project- und Region-Kontext dokumentiert?
• Wurde die No-New-Platform-Alternative bewertet?

Verantwortung und Metadata

• Sind Data Owner, Steward, technischer Betreiber und FinOps verantwortliche Person benannt?
• Ist eine Authority für Business Terms und Classifications definiert?
• Kann Knowledge Catalog oder ein anderer Catalog autoritative Metadata synchronisieren statt duplizieren?
• Sind fachliche Ebene des Produkts, Freshness, Quality und Permitted Use für Nutzer sichtbar?

Identity und Protection

• Werden Access Grants nach Möglichkeit über Groups vergeben?
• Sind Service Accounts owned, monitored und revocable?
• Sind Row-, Column- und Masking Kontrollregeln mit freigegebenen Classifications verbunden?
• Sind Administrator-, Break-Glass-, Export- und Sharing-Pfade in den Tests enthalten?

Evidence und Operations

• Deckt Lineage jeden materiellen Handoff ab?
• Werden Quality Failures gespeichert und an einen Incident verantwortliche Person geroutet?
• Werden Audit Logs für den erforderlichen Zeitraum und Umfang aufbewahrt?
• Sind nicht unterstützte oder externe Kanten als Gaps dokumentiert?

Region, Lifecycle und Kosten

• Sind Dataset-, Reservation- und Connected-Service-Locations kompatibel?
• Sind Retention-, Deletion-, Export- und Downstream-Copy-Rules explizit?
• Ist Workload Spend einem Product, Team oder Cost Center zugeordnet?
• Sind Reservation-, Edition- und regionale Annahmen vor Approval validiert?

Artefakt

Dokumentiere das Ergebnis mit dem Tool Governance Starting-Point Decision.

Fülle die Readiness Card in einem Workshop aus. Das Ergebnis wird nicht vorab eingetragen.

Die Karte dokumentiert vier Bereiche:

1. Decision Context – erster governeder Use Case, Success Criteria, Dataset- und Consumer Scope, Organization-/Project-/Region-Kontext und Decision Owner.
2. Governance and Platform Design – Dataset- und Environment Model, Data Owner und Steward, Metadata Authority, IAM und Fine-Grained Access, PII Controls, Lineage, Audit, Quality, Analytical Verantwortung, Retention, Exports, Reservations und Cost Accountability.
3. Validation, Gaps and Exceptions – Evidence Location, Proof-of-Value-Tests, bekannte Gaps, Assumptions und zeitlich begrenzte Exceptions.
4. Decision Record – Ready, Conditional oder Not Ready; bevorzugtes Starting Pattern; Alternative; Blocker; Current-Stack-Option; No-Regret Next Step; Implementation Owner; Review Date.

Das Artefakt ist Decision Evidence und kein Product Scorecard. Approval benötigt eine getestete Control Chain für einen realen Use Case.

Tools

• BigQuery Governance Readiness Decision Card
• Governed Dataset Vereinbarung
• Effective Access Test Matrix
• Classification-to-Richtlinie Map
• Source-to-Nutzer Nachweis Register
• Export and Downstream-Copy Register
• Data Quality and Incident Register
• Reservation and Cost Accountability Map

Ressourcen

BigQuery Governance und Hierarchie

• Introduction to data governance in BigQuery
• Organizing BigQuery resources
• BigQuery locations
• BigQuery Zugriffsverwaltung roles and permissions

Fine-Grained Protection und Exports

• Introduction to BigQuery row-level security
• Introduction to column-level access control
• Introduction to data masking
• VPC Service Kontrollregeln for BigQuery
• Export query results to a file

Catalog, Lineage, Quality und Evidence

• Knowledge Catalog overview
• Manage a business glossary
• About data lineage
• Automatic data quality overview
• Introduction to audit logs in BigQuery

Capacity und Kosten

• Understand reservations
• Manage workload reservations