CDMC Key Controls Framework in einem BigQuery-Data-Warehouse implementieren

Viele Organisationen stellen Cloud Data Warehouses zum Speichern vertraulicher Informationen bereit, damit sie die Daten für verschiedene geschäftliche Zwecke analysieren können. In diesem Dokument wird beschrieben, wie Sie das vom Enterprise Data Management Council verwaltete CDMC Key Controls Framework (Cloud Data Management Capabilities) in einem BigQuery-Data-Warehouse implementieren können.

Das CDMC Key Controls Framework wurde hauptsächlich für Cloud-Dienstanbieter und Technologieanbieter veröffentlicht. Das Framework beschreibt 14 Schlüsselkontrollen, die Anbieter implementieren können, damit ihre Kunden vertrauliche Daten in der Cloud effektiv verwalten und steuern können. Die Kontrollen wurden von der CDMC Working Group geschrieben, an der mehr als 300 Fachleute aus 100 Unternehmen beteiligt sind. Beim Erstellen des Frameworks hat die CDMC-Working Group viele der rechtlichen und behördlichen Anforderungen berücksichtigt.

Diese BigQuery- und Data Catalog-Referenzarchitektur wurde hinsichtlich des CDMC Key Controls Framework als CDMC Certified Cloud Solution bewertet und zertifiziert. In der Referenzarchitektur werden verschiedene Google Cloud-Dienste und -Features sowie öffentliche Bibliotheken verwendet, um die CDMC-Schlüsselkontrollen und die empfohlene Automatisierung zu implementieren. In diesem Dokument wird erläutert, wie Sie die Schlüsselkontrollen implementieren, um vertrauliche Daten in einem BigQuery-Data-Warehouse zu schützen.

Architektur

Die folgende Google Cloud-Referenzarchitektur entspricht den Testspezifikationen des CDMC Key Controls Framework v1.1.1. Die Zahlen im Diagramm stellen die Schlüsselkontrollen dar, die mit Google Cloud-Diensten behandelt werden.

Die Referenzarchitektur baut auf dem gesicherten Data-Warehouse-Blueprint auf, der eine Architektur zum Schutz eines BigQuery-Data-Warehouse mit vertraulichen Informationen bereitstellt. Im obigen Diagramm sind Projekte oben im Diagramm (grau) Teil des gesicherten Data-Warehouse-Blueprints und das Data-Governance-Projekt (blau) enthält die Dienste, die hinzugefügt werden, um die Anforderungen des CDMC Key Controls Framework zu erfüllen. Die Architektur erweitert das Data-Governance-Projekt, um das CDMC Key Controls Framework zu implementieren. Das Data-Governance-Projekt bietet Kontrollen wie Klassifizierung, Lebenszyklusverwaltung und Datenqualitätsmanagement. Das Projekt bietet auch eine Möglichkeit, die Architektur zu prüfen und Berichte zu Ergebnissen zu erstellen.

Weitere Informationen zur Implementierung dieser Referenzarchitektur finden Sie in der Google Cloud CDMC-Referenzarchitektur auf GitHub.

Übersicht über das CDMC Key Controls Framework

In der folgenden Tabelle ist das CDMC Key Controls Framework zusammengefasst.

#	CDMC-Schlüsselkontrolle	CDMC-Kontrollanforderung
1	Compliance mit der Datenkontrolle	Cloud-Datenverwaltungs-Geschäftsfälle werden definiert und gesteuert. Alle Daten-Assets, die vertrauliche Daten enthalten, müssen mithilfe von Messwerten und automatisierten Benachrichtigungen auf die Compliance mit den CDMC-Schlüsselkontrollen überwacht werden.
2	Dateninhaberschaft wird sowohl für migrierte als auch für in der Cloud generierte Daten eingerichtet	Das Feld Inhaberschaft in einem Datenkatalog muss für alle vertraulichen Daten gefüllt oder anderweitig an einen definierten Workflow gemeldet werden.
3	Datenbeschaffung und -nutzung werden durch Automatisierung gesteuert und unterstützt	Für alle Daten-Assets, die vertrauliche Daten enthalten, muss ein Register mit autoritativen Datenquellen und Bereitstellungspunkten ausgefüllt werden. Andernfalls müssen sie einem definierten Workflow gemeldet werden.
4	Datenhoheit und grenzüberschreitende Datenübertragungen werden verwaltet	Die Datenhoheit und die grenzüberschreitende Übertragung vertraulicher Daten müssen gemäß der definierten Richtlinie aufgezeichnet, geprüft und gesteuert werden.
5	Datenkataloge werden implementiert und verwendet und sind interoperabel	Die Katalogisierung muss für alle Daten zum Zeitpunkt der Erstellung oder Aufnahme in allen Umgebungen konsistent automatisiert sein.
6	Datenklassifizierungen werden definiert und verwendet	Die Klassifizierung muss für alle Daten zum Zeitpunkt der Erstellung oder Aufnahme automatisiert und immer aktiviert sein. Die Klassifizierung ist für Folgendes automatisiert: Personenidentifizierbare Informationen (personally identifiable information, PII) Klassifizierung der Informationsvertraulichkeit Relevante nicht öffentliche Informationen (MNPI) Clientidentifizierbare Informationen Organisationsdefinierte Klassifizierung
7	Datenberechtigungen werden verwaltet, erzwungen und nachverfolgt	Für diese Kontrolle ist Folgendes erforderlich: Berechtigungen und Zugriff auf vertrauliche Daten müssen standardmäßig dem Ersteller und dem Inhaber entsprechen, bis sie ausdrücklich und autoritativ gewiesen werden. Der Zugriff muss für alle vertraulichen Daten verfolgt werden.
8	Zugriff, Verwendung und Ergebnisse von Daten nach ethischen Maßstäben werden verwaltet	Der Zweck der Datennutzung muss für alle Datenfreigabevereinbarungen zu vertraulichen Daten angegeben werden. Der Zweck muss die erforderlichen Datentypen und – für globale Organisationen – den Geltungsbereich in Bezug auf Land oder Rechtspersönlichkeit angeben.
9	Daten werden gesichert und Kontrollen werden nachgewiesen	Für diese Kontrolle ist Folgendes erforderlich: Für vertrauliche Daten müssen angemessene Sicherheitskontrollen aktiviert werden. Nachweise zur Sicherheitskontrolle müssen im Datenkatalog für alle vertraulichen Daten aufgezeichnet werden.
10	Ein Datenschutz-Framework ist definiert und betriebsbereit	Datenschutz-Folgenabschätzungen (DSFAs) müssen automatisch für alle personenbezogenen Daten gemäß der jeweiligen Rechtsprechung ausgelöst werden.
11	Der Datenlebenszyklus wird geplant und verwaltet	Datenaufbewahrung, -archivierung und -löschung müssen nach einem festgelegten Aufbewahrungsplan verwaltet werden.
12	Datenqualität wird verwaltet	Die Messung der Datenqualität muss für vertrauliche Daten mit verfügbaren Messwerten aktiviert werden.
13	Die Grundsätze des Kostenverwaltung werden festgelegt und angewendet	Technische Designprinzipien werden festgelegt und angewendet. Kostenmesswerte, die direkt mit der Datennutzung, -speicherung und -übertragung verknüpft sind, müssen im Katalog verfügbar sein.
14	Datenherkunft wird verstanden	Informationen zur Herkunft von Daten müssen für alle vertraulichen Daten verfügbar sein. Diese Informationen müssen mindestens die Quelle enthalten, aus der die Daten aufgenommen wurden oder in der sie in einer Cloud-Umgebung erstellt wurden.

1. Compliance mit der Datenkontrolle

Bei dieser Kontrolle müssen Sie prüfen, ob alle vertraulichen Daten mithilfe von Messwerten auf die Compliance mit diesem Framework überwacht werden.

Die Architektur verwendet Messwerte, die angeben, inwieweit die einzelnen Schlüsselontrollen betriebsbereit sind. Die Architektur enthält auch Dashboards, die angeben, wenn die Messwerte nicht die definierten Grenzwerte erfüllen.

Die Architektur enthält Detektoren, die Ergebnisse und Abhilfeempfehlungen veröffentlichen, wenn Daten-Assets die Anforderungen einer Schlüsselkontrolle nicht erfüllen. Diese Ergebnisse und Empfehlungen liegen im JSON-Format vor und werden in einem Pub/Sub-Thema veröffentlicht, um an Abonnenten verteilt zu werden. Sie können Ihre internen Service-Desk- oder Service-Management-Tools in das Pub/Sub-Thema einbinden, damit Vorfälle automatisch in Ihrem Ticketsystem erstellt werden.

Die Architektur verwendet Dataflow, um einen Beispielabonnenten für die Ergebnisereignisse zu erstellen, die dann in einer BigQuery-Instanz gespeichert werden, die im Data-Governance-Projekt ausgeführt wird. Mit einer Reihe von bereitgestellten Ansichten können Sie die Daten mit BigQuery Studio in der Google Cloud Console abfragen. Sie können Berichte auch mit Looker Studio oder anderen BigQuery-kompatiblen Business-Intelligence-Tools erstellen. Die Berichte sind verfügbar:

• Zusammenfassung der Ergebnisse der letzten Ausführung
• Details zu den Ergebnissen der letzten Ausführung
• Metadaten der letzten Ausführung
• Daten-Assets der letzten Ausführung im Geltungsbereich
• Dataset-Statistiken zur letzten Ausführung

Das folgende Diagramm zeigt die Dienste, die für diese Kontrolle gelten.

Die Architektur verwendet die folgenden Dienste, um die Anforderungen dieser Kontrolle zu erfüllen:

• Pub/Sub veröffentlicht Ergebnisse.
• Dataflow lädt die Ergebnisse in eine BigQuery-Instanz.
• BigQuery speichert die Ergebnisdaten und bietet zusammenfassende Ansichten.
• Looker Studio bietet Dashboards und Berichte.

Der folgende Screenshot zeigt ein Beispiel für ein Zusammenfassungs-Dashboard in Looker Studio.

Der folgende Screenshot zeigt eine Beispielansicht für Ergebnisse nach Daten-Asset.

2. Dateninhaberschaft wird sowohl für migrierte als auch für in der Cloud generierte Daten eingerichtet

Zur Erfüllung der Anforderungen dieser Kontrolle prüft die Architektur automatisch die Daten im BigQuery-Data-Warehouse und fügt Datenklassifizierungs-Tags hinzu, die angeben, dass Inhaber für alle vertraulichen Daten identifiziert wurden.

Data Catalog, ein Feature von Dataplex, verarbeitet zwei Arten von Metadaten: technische Metadaten und geschäftliche Metadaten. Für ein bestimmtes Projekt katalogisiert Data Catalog automatisch BigQuery-Datasets, -Tabellen und -Ansichten und füllt die technischen Metadaten aus. Die Synchronisierung zwischen Katalog und Daten-Assets erfolgt nahezu in Echtzeit.

Die Architektur verwendet Tag Engine, um einer CDMC controls-Tag-Vorlage in Data Catalog die folgenden geschäftlichen Metadaten-Tags hinzuzufügen:

• is_sensitive: gibt an, ob das Daten-Asset vertrauliche Daten enthält (siehe Kontrolle 6 zur Datenklassifizierung)
• owner_name: der Inhaber der Daten
• owner_email: die E-Mail-Adresse des Inhabers

Die Tags werden mithilfe von Standardeinstellungen gefüllt, die in einer BigQuery-Referenztabelle im Data-Governance-Projekt gespeichert sind.

Standardmäßig legt die Architektur die Inhabermetadaten auf Tabellenebene fest. Sie können diese Architektur jedoch so ändern, dass die Metadaten auf der Spaltenebene festgelegt werden. Weitere Informationen finden Sie unter Data Catalog-Tags und Tag-Vorlagen.

Das folgende Diagramm zeigt die Dienste, die für diese Kontrolle gelten.

Die Architektur verwendet die folgenden Dienste, um die Anforderungen dieser Kontrolle zu erfüllen:

• Zwei BigQuery-Data-Warehouses: Eines speichert die vertraulichen Daten und das andere die Standardeinstellungen für die Inhaberschaft von Daten-Assets.
• Data Catalog speichert Inhaberschafts-Metadaten über Tag-Vorlagen und Tags.
• Zwei Cloud Run-Instanzen:
  • Eine Instanz führt Report Engine aus, das prüft, ob Tags angewendet werden, und veröffentlicht Ergebnisse.
  • Eine andere Instanz führt Tag Engine aus, das die Daten im gesicherten Data Warehouse mit Tags versieht.
• Pub/Sub veröffentlicht Ergebnisse.

Die Architektur prüft, ob vertraulichen Daten ein Inhabernamens-Tag zugewiesen ist, um Probleme im Zusammenhang mit dieser Kontrolle zu erkennen.

3. Datenbeschaffung und -nutzung werden durch Automatisierung gesteuert und unterstützt

Diese Kontrolle erfordert eine Klassifizierung von Daten-Assets und ein Datenregister von autoritativen Quellen und autorisierten Distributoren. Die Architektur verwendet Data Catalog, um das Tag is_authoritative der Tag-Vorlage CDMC controls hinzuzufügen. Dieses Tag definiert, ob das Daten-Asset autoritativ ist.

Data Catalog katalogisiert BigQuery-Datasets, -Tabellen und -Ansichten mit technischen und geschäftlichen Metadaten. Technische Metadaten werden automatisch ausgefüllt und enthalten die Ressourcen-URL, also den Ort des Bereitstellungspunkts. Geschäftliche Metadaten sind in der Tag Engine-Konfigurationsdatei definiert und enthalten das Tag is_authoritative.

Bei der nächsten geplanten Ausführung füllt Tag Engine das Tag is_authoritative in der Tag-Vorlage CDMC controls mit Standardwerten, die in einer Referenztabelle in BigQuery gespeichert sind.

Das folgende Diagramm zeigt die Dienste, die für diese Kontrolle gelten.

Die Architektur verwendet die folgenden Dienste, um die Anforderungen dieser Kontrolle zu erfüllen:

• Zwei BigQuery-Data-Warehouses: Eines speichert die vertraulichen Daten und das andere die Standardeinstellungen für die autoritative Datenquelle.
• Data Catalog speichert autoritative Quellmetadaten über Tags.
• Zwei Cloud Run-Instanzen:
  • Eine Instanz führt Report Engine aus, das prüft, ob Tags angewendet werden, und veröffentlicht Ergebnisse.
  • Eine andere Instanz führt Tag Engine aus, das die Daten im gesicherten Data Warehouse mit Tags versieht.
• Pub/Sub veröffentlicht Ergebnisse.

Zur Erkennung von Problemen im Zusammenhang mit dieser Kontrolle prüft die Architektur, ob vertraulichen Daten das autoritativen Quelltag zugewiesen ist.

4. Datenhoheit und grenzüberschreitende Datenübertragungen werden verwaltet

Bei dieser Kontrolle muss die Architektur die Daten-Registry auf regionsspezifische Speicheranforderungen prüfen und Nutzungsregeln erzwingen. In einem Bericht wird der geografische Standort von Daten-Assets beschrieben.

Die Architektur verwendet Data Catalog, um das Tag approved_storage_location der Tag-Vorlage CDMC controls hinzuzufügen. Mit diesem Tag wird der geografische Standort definiert, an dem das Daten-Asset gespeichert werden darf.

Der tatsächliche Speicherort der Daten wird als technische Metadaten in den BigQuery-Tabellendetails gespeichert. Mit BigQuery können Administratoren den Speicherort eines Datasets oder einer Tabelle nicht ändern. Wenn Administratoren den Speicherort der Daten ändern möchten, müssen sie stattdessen das Dataset kopieren.

Die Einschränkung der Ressourcenstandorte durch den Organisationsrichtliniendienst definiert die Google Cloud-Regionen, in denen Sie Daten speichern können. Standardmäßig legt die Architektur die Einschränkung für das Projekt mit vertraulichen Daten fest, aber Sie können die Einschränkung auf Organisations- oder Ordnerebene festlegen, wenn Sie dies bevorzugen. Tag Engine repliziert die zulässigen Speicherorte in der Data Catalog-Tag-Vorlage und speichert den Speicherort im Tag approved_storage_location. Wenn Sie die Premium-Stufe von Security Command Center aktivieren und jemand die Einschränkung der Ressourcenstandorte durch den Organisationsrichtliniendienst aktualisiert, generiert Security Command Center Sicherheitslückenergebnisse für Ressourcen, die außerhalb der aktualisierten Richtlinie gespeichert sind.

Access Context Manager definiert den geografischen Standort, an dem sich Nutzer befinden müssen, bevor sie auf Daten-Assets zugreifen können. Mit Zugriffsebenen können Sie angeben, aus welchen Regionen die Anfragen stammen dürfen. Anschließend fügen Sie die Zugriffsrichtlinie dem VPC Service Controls-Perimeter für das Projekt mit vertraulichen Daten hinzu.

BigQuery hat für jeden Job und jede Abfrage jedes Datasets einen vollständigen Audit-Trail, um die Datenübertragung zu verfolgen. Der Audit-Trail wird in der Ansicht INFORMATION_SCHEMA.JOBS von BigQuery gespeichert.

Das folgende Diagramm zeigt die Dienste, die für diese Kontrolle gelten.

Die Architektur verwendet die folgenden Dienste, um die Anforderungen dieser Kontrolle zu erfüllen:

• Der Organisationsrichtliniendienst definiert und erzwingt die Einschränkung der Ressourcenstandorte.
• Mit Access Context Manager werden die Standorte definiert, von denen Nutzer auf Daten zugreifen können.
• Zwei BigQuery-Data-Warehouses: Eines speichert die vertraulichen Daten und das andere hostet eine Remote-Funktion, mit der die Standortrichtlinie geprüft wird.
• Data Catalog speichert genehmigte Speicherorte als Tags.
• Zwei Cloud Run-Instanzen:
  • Eine Instanz führt Report Engine aus, das prüft, ob Tags angewendet werden, und veröffentlicht Ergebnisse.
  • Eine andere Instanz führt Tag Engine aus, das die Daten im gesicherten Data Warehouse mit Tags versieht.
• Pub/Sub veröffentlicht Ergebnisse.
• Cloud Logging schreibt die Audit-Logs.
• Security Command Center meldet alle Ergebnisse, die sich auf den Ressourcenstandort oder den Datenzugriff beziehen.

Um Probleme im Zusammenhang mit dieser Kontrolle zu erkennen, enthält die Architektur ein Ergebnis darüber, ob das genehmigte Standort-Tag den Standort der vertraulichen Daten enthält.

5. Datenkataloge werden implementiert und verwendet und sind interoperabel

Für diese Kontrolle ist ein Datenkatalog erforderlich. Die Architektur kann neue und aktualisierte Assets scannen, um bei Bedarf Metadaten hinzuzufügen.

Die Architektur verwendet Data Catalog, um die Anforderungen dieser Kontrolle zu erfüllen. Data Catalog protokolliert automatisch Google Cloud-Assets, einschließlich BigQuery-Datasets, -Tabellen und -Ansichten. Wenn Sie eine neue Tabelle in BigQuery erstellen, werden von Data Catalog automatisch die technischen Metadaten und das Schema der neuen Tabelle registriert. Wenn Sie eine Tabelle in BigQuery aktualisieren, aktualisiert Data Catalog die Einträge fast sofort.

Das folgende Diagramm zeigt die Dienste, die für diese Kontrolle gelten.

Die Architektur verwendet die folgenden Dienste, um die Anforderungen dieser Kontrolle zu erfüllen:

• Zwei BigQuery-Data-Warehouses: In einem sind die vertraulichen Daten gespeichert, im anderen die nicht vertraulichen Daten.
• Data Catalog speichert die technischen Metadaten für Tabellen und Felder.

In dieser Architektur speichert Data Catalog standardmäßig technische Metadaten aus BigQuery. Bei Bedarf können Sie Data Catalog in andere Datenquellen einbinden.

6. Datenklassifizierungen werden definiert und verwendet

Bei dieser Bewertung müssen Daten anhand ihrer Vertraulichkeit klassifiziert werden können, z. B. ob es sich bei ihnen um personenidentifizierbare Informationen handelt, ob sie Clients identifizieren oder ob sie sonstige von Ihrer Organisation definierte Standards erfüllen. Die Architektur erstellt einen Bericht über Daten-Assets und ihre Vertraulichkeit, um die Anforderungen dieser Kontrolle zu erfüllen. Mit diesem Bericht können Sie prüfen, ob die Einstellungen für die Vertraulichkeit korrekt sind. Darüber hinaus führt jede neue Datenressource oder Änderung an einem vorhandenen Daten-Asset zu einer Aktualisierung des Datenkatalogs.

Klassifizierungen werden im Tag sensitive_category in der Data Catalog-Tag-Vorlage auf Tabellen- und auf Spaltenebene gespeichert. Mit einer Klassifizierungsreferenztabelle können Sie die verfügbaren Sensitive Data Protection-Informationstypen (infoTypes) einstufen, wobei vertraulichere Inhalte ein höheres Ranking erhalten.

Zur Erfüllung der Anforderungen dieser Einstellung verwendet die Architektur Sensitive Data Protection, Data Catalog und Tag Engine, um vertraulichen Spalten in BigQuery-Tabellen die folgenden Tags hinzuzufügen:

• is_sensitive: gibt an, ob das Daten-Asset vertrauliche Informationen enthält
• sensitive_category: eine der folgenden Datenkategorien:
  • Vertrauliche personenidentifizierbare Informationen
  • Personenidentifizierbare Informationen
  • Vertrauliche personenbezogene Daten
  • Personenbezogene Daten
  • Öffentliche Informationen

Sie können die Datenkategorien entsprechend Ihren Anforderungen ändern. Sie können beispielsweise die MNPI-Klassifizierung (Material Non-Public Information) hinzufügen.

Nachdem Sensitive Data Protection die Daten geprüft hat, liest Tag Engine die DLP results-Tabellen pro Asset, um die Ergebnisse zu kompilieren. Wenn eine Tabelle Spalten mit einem oder mehreren vertraulichen infoTypes enthält, wird der wichtigste infoType ermittelt. Sowohl die vertraulichen Spalten als auch die gesamte Tabelle werden als die Kategorie mit dem höchsten Rang getaggt. Tag Engine weist der Spalte auch ein entsprechendes Richtlinien-Tag zu und weist der Tabelle das boolesche Tag is_sensitive zu.

Sie können Cloud Scheduler verwenden, um die Sensitive Data Protection-Prüfung zu automatisieren.

Das folgende Diagramm zeigt die Dienste, die für diese Kontrolle gelten.

Die Architektur verwendet die folgenden Dienste, um die Anforderungen dieser Kontrolle zu erfüllen:

• Vier BigQuery-Data-Warehouses speichern folgende Informationen:
  • Vertrauliche Daten
  • Informationen zu den Sensitive Data Protection-Ergebnissen
  • Referenzdaten zur Datenklassifizierung
  • Informationen zum Tag-Export
• Data Catalog speichert die Klassifizierungs-Tags.
• Sensitive Data Protection prüft Assets auf vertrauliche infoTypes.
• Compute Engine führt das Script "Datasets prüfen" aus, das für jedes BigQuery-Dataset einen Sensitive Data Protection-Job auslöst.
• Zwei Cloud Run-Instanzen:
  • Eine Instanz führt Report Engine aus, das prüft, ob Tags angewendet werden, und veröffentlicht Ergebnisse.
  • Eine andere Instanz führt Tag Engine aus, das die Daten im gesicherten Data Warehouse mit Tags versieht.
• Pub/Sub veröffentlicht Ergebnisse.

Die Architektur enthält die folgenden Ergebnisse, um Probleme im Zusammenhang mit dieser Kontrolle zu erkennen:

• Gibt an, ob vertraulichen Daten ein Tag der vertraulichen Kategorie zugewiesen ist.
• Gibt an, ob vertraulichen Daten ein Vertraulichkeits-Tag auf Spaltenebene zugewiesen ist.

7. Datenberechtigungen werden verwaltet, erzwungen und nachverfolgt

Standardmäßig werden nur Erstellern und Inhabern Berechtigungen und Zugriff auf vertrauliche Daten zugewiesen. Darüber hinaus erfordert diese Kontrolle, dass die Architektur den gesamten Zugriff auf vertrauliche Daten erfasst.

Zur Erfüllung der Anforderungen dieser Kontrolle, verwendet die Architektur die cdmc sensitive data classification-Richtlinien-Tag-Taxonomie in BigQuery, um den Zugriff auf Spalten zu steuern, die vertrauliche Daten in BigQuery-Tabellen enthalten. Die Taxonomie umfasst die folgenden Richtlinien-Tags:

• Vertrauliche personenidentifizierbare Informationen
• Personenidentifizierbare Informationen
• Vertrauliche personenbezogene Daten
• Personenbezogene Daten

Mit Richtlinien-Tags können Sie steuern, wer sich vertrauliche Spalten in BigQuery-Tabellen ansehen kann. Die Architektur ordnet diese Richtlinien-Tags Vertraulichkeitsklassifizierungen zu, die von Sensitive Data Protection-infoTypes abgeleitet wurden. Beispiel: Das Richtlinien-Tag sensitive_personal_identifiable_information und die vertrauliche Kategorie werden infoTypes wie AGE, DATE_OF_BIRTH, PHONE_NUMBER und EMAIL_ADDRESS zugeordnet.

Die Architektur verwendet die Identity and Access Management (IAM), um die Gruppen, Nutzer und Dienstkonten zu verwalten, die Zugriff auf die Daten benötigen. IAM-Berechtigungen werden einem bestimmten Asset für Zugriff auf Tabellenebene gewährt. Darüber hinaus ermöglicht der auf Richtlinien-Tags basierende Spaltenzugriff einen differenzierten Zugriff auf vertrauliche Datenressourcen. Standardmäßig haben Nutzer keinen Zugriff auf Spalten mit definierten Richtlinien-Tags.

Damit nur authentifizierte Nutzer auf Daten zugreifen können, verwendet Google Cloud Cloud Identity, das Sie mit Ihren vorhandenen Identitätsanbietern zur Authentifizierung von Nutzern verbinden können.

Diese Kontrolle erfordert auch, dass die Architektur regelmäßig auf Daten-Assets prüft, für die keine Berechtigungen definiert sind. Der von Cloud Scheduler verwaltete Detektor prüft auf die folgenden Szenarien:

• Ein Daten-Asset enthält eine vertrauliche Kategorie, aber es gibt kein entsprechendes Richtlinien-Tag.
• Eine Kategorie stimmt nicht mit dem Richtlinien-Tag überein.

In diesen Szenarien generiert der Detektor Ergebnisse, die von Pub/Sub veröffentlicht und dann von Dataflow in die Tabelle events in BigQuery geschrieben werden. Die Ergebnisse können Sie dann an Ihr Abhilfetool verteilen, wie unter 1. Compliance mit der Datenkontrolle beschrieben.

Das folgende Diagramm zeigt die Dienste, die für diese Kontrolle gelten.

Die Architektur verwendet die folgenden Dienste, um die Anforderungen dieser Kontrolle zu erfüllen:

• Ein BigQuery-Data-Warehouse speichert die vertraulichen Daten und die Richtlinien-Tag-Bindungen für eine detaillierte Zugriffssteuerung.
• IAM verwaltet den Zugriff.
• Data Catalog speichert die Tags auf Tabellen- und Spaltenebene für die vertrauliche Kategorie.
• Zwei Cloud Run-Instanzen:
  • Eine Instanz führt Report Engine aus, das prüft, ob Tags angewendet werden, und veröffentlicht Ergebnisse.
  • Eine andere Instanz führt Tag Engine aus, das die Daten im gesicherten Data Warehouse mit Tags versieht.

Zur Erkennung von Problemen im Zusammenhang mit dieser Kontrolle prüft die Architektur, ob vertrauliche Daten ein entsprechendes Richtlinien-Tag haben.

8. Zugriff, Verwendung und Ergebnisse von Daten nach ethischen Maßstäben werden verwaltet

Für diese Kontrolle ist es erforderlich, dass die Architektur Datenfreigabevereinbarungen sowohl vom Datenanbieter als auch von Datennutzern speichert, einschließlich einer Liste genehmigter Nutzungszwecke. Der Nutzungszweck für die vertraulichen Daten wird dann in BigQuery mithilfe von Abfragelabels den Berechtigungen zugeordnet. Wenn ein Nutzer vertrauliche Daten in BigQuery abfragt, muss er einen gültigen Zweck angeben, der mit seiner Berechtigung übereinstimmt (z. B. SET @@query_label = “use:3”;).

Die Architektur verwendet Data Catalog, um der Tag-Vorlage CDMC controls die folgenden Tags hinzuzufügen. Diese Tags stellen die Datenfreigabevereinbarung mit dem Datenanbieter dar:

• approved_use: die genehmigte Nutzung oder die Nutzer des Daten-Assets
• sharing_scope_geography: die Liste der geografischen Standorte, an denen das Daten-Asset freigegeben werden kann
• sharing_scope_legal_entity: die Liste der vereinbarten Entitäten, die das Daten-Asset gemeinsam nutzen können

Ein separates BigQuery-Data-Warehouse enthält das Dataset entitlement_management mit den folgenden Tabellen:

• provider_agreement: die Datenfreigabevereinbarung mit dem Datenanbieter, einschließlich des vereinbarten Rechtssubjekts und des geografischen Geltungsbereichs. Diese Daten sind die Standardeinstellungen für die Tags shared_scope_geography und sharing_scope_legal_entity.
• consumer_agreement: die Datenfreigabevereinbarung mit dem Datennutzer, einschließlich des vereinbarten Rechtssubjekts und des geografischen Geltungsbereichs. Jede Vereinbarung ist einer IAM-Bindung für das Daten-Asset zugeordnet.
• use_purpose: der Nutzungszweck, z. B. die Nutzungsbeschreibung und die zulässigen Vorgänge für das Daten-Asset
• data_asset: Informationen zum Daten-Asset, z. B. der Asset-Name und Details zum Dateninhaber

Zur Prüfung von Datenfreigabevereinbarungen hat BigQuery für jeden Job und jede Abfrage einen vollständigen Audit-Trail. Der Audit-Trail wird in der Ansicht INFORMATION_SCHEMA.JOBS von BigQuery gespeichert. Nachdem Sie einer Sitzung ein Abfragelabel zugeordnet und Abfragen innerhalb der Sitzung ausgeführt haben, können Sie Audit-Logs für Abfragen mit diesem Abfragelabel erfassen. Weitere Informationen finden Sie in der Referenz zu Audit-Logs für BigQuery.

Das folgende Diagramm zeigt die Dienste, die für diese Kontrolle gelten.

Die Architektur verwendet die folgenden Dienste, um die Anforderungen dieser Kontrolle zu erfüllen:

• Zwei BigQuery-Data-Warehouses: Eines speichert die vertraulichen Daten und das andere die Berechtigungsdaten, einschließlich der Vereinbarungen zu Anbieter- und Nutzerdatenfreigaben und des genehmigten Verwendungszwecks.
• Data Catalog speichert die Informationen der Anbieterdatenfreigabevereinbarung als Tags.
• Zwei Cloud Run-Instanzen:
  • Eine Instanz führt Report Engine aus, das prüft, ob Tags angewendet werden, und veröffentlicht Ergebnisse.
  • Eine andere Instanz führt Tag Engine aus, das die Daten im gesicherten Data Warehouse mit Tags versieht.
• Pub/Sub veröffentlicht Ergebnisse.

Die Architektur enthält die folgenden Ergebnisse, um Probleme im Zusammenhang mit dieser Kontrolle zu erkennen:

• Ob es im Dataset entitlement_management einen Eintrag für ein Daten-Asset gibt.
• Ob ein Vorgang für eine vertrauliche Tabelle mit einem abgelaufenen Anwendungsfall ausgeführt wird (z. B. ist das valid_until_date in der consumer_agreement table verstrichen).
• Ob ein Vorgang für eine vertrauliche Tabelle mit einem falschen Labelschlüssel ausgeführt wird.
• Ob ein Vorgang für eine vertrauliche Tabelle mit einem leeren oder nicht genehmigten Anwendungsfall-Labelwert ausgeführt wird.
• Ob eine vertrauliche Tabelle mit einer nicht genehmigten Vorgangsmethode abgefragt wird (z. B. SELECT oder INSERT).
• Ob der aufgezeichnete Zweck, den der Nutzer beim Abfragen der vertraulichen Daten angegeben hat, mit der Datenfreigabevereinbarung übereinstimmt.

9. Daten werden gesichert und Kontrollen werden nachgewiesen

Diese Kontrolle erfordert die Implementierung der Datenverschlüsselung und De-Identifikation, um vertrauliche Daten zu schützen und eine Aufzeichnung dieser Kontrollen bereitzustellen.

Diese Architektur baut auf der Standardsicherheit von Google auf, einschließlich der Verschlüsselung ruhender Daten. Darüber hinaus können Sie mit der Architektur Ihre eigenen Schlüssel mithilfe von vom Kunden verwalteten Verschlüsselungsschlüsseln (Customer-Managed Encryption Keys, CMEKs) verwalten. Mit Cloud KMS können Sie Ihre Daten mit softwaregestützten Verschlüsselungsschlüsseln oder gemäß FIPS 140-2 Level 3 validierten Hardwaresicherheitsmodulen (HSMs) verschlüsseln.

Die Architektur verwendet die dynamische Datenmaskierung auf Spaltenebene, die über Richtlinien-Tags konfiguriert wird, und speichert vertrauliche Daten in einem separaten VPC Service Controls-Perimeter. Sie können auch eine De-Identifikation auf Anwendungsebene hinzufügen, die Sie entweder lokal oder als Teil der Datenaufnahme-Pipeline implementieren können.

Standardmäßig implementiert die Architektur die CMEK-Verschlüsselung mit HSMs, unterstützt aber auch Cloud External Key Manager (Cloud EKM).

In der folgenden Tabelle wird die beispielhafte Sicherheitsrichtlinie beschrieben, die die Architektur für die Region us-central1 implementiert. Sie können die Richtlinie an Ihre Anforderungen anpassen, indem Sie beispielsweise verschiedene Richtlinien für verschiedene Regionen hinzufügen.

Vertraulichkeit der Daten	Standardverschlüsselungsmethode	Weitere zulässige Verschlüsselungsmethoden	Standard-De-Identifikationsmethode	Weitere zulässige De-Identifikationsmethoden
Öffentliche Informationen	Standardverschlüsselung	Beliebig	–	Beliebig
Vertrauliche personenidentifizierbare Informationen	CMEK mit HSM	EKM	Auf null setzen	SHA-256-Hash oder Standardmaskierungswert
Personenidentifizierbare Informationen	CMEK mit HSM	EKM	SHA-256-Hash	Auf null setzen oder Standardmaskierungswert
Vertrauliche personenbezogene Daten	CMEK mit HSM	EKM	Standardmaskierungswert	SHA-256-Hash oder auf null setzen
Personenbezogene Daten	CMEK mit HSM	EKM	Standardmaskierungswert	SHA-256-Hash oder auf null setzen

Die Architektur verwendet Data Catalog, um das Tag encryption_method der Tag-Vorlage CDMC controls auf Tabellenebene hinzuzufügen. encryption_method definiert die vom Daten-Asset verwendete Verschlüsselungsmethode.

Darüber hinaus erstellt die Architektur ein security policy template-Tag, um zu ermitteln, welche De-Identifikationsmethode auf ein bestimmtes Feld angewendet wird. Die Architektur verwendet die platform_deid_method, die mit dynamischer Datenmaskierung angewendet wird. Sie können die app_deid_method hinzufügen und mit den Dataflow- und Sensitive Data Protection-Datenaufnahme-Pipelines füllen, die im Blueprint des gesicherten Data Warehouse enthalten sind.

Das folgende Diagramm zeigt die Dienste, die für diese Kontrolle gelten.

Die Architektur verwendet die folgenden Dienste, um die Anforderungen dieser Kontrolle zu erfüllen:

• Zwei optionale Instanzen von Dataflow, wobei eine die De-Identifikation auf Anwendungsebene und die andere die Re-Identifikation ausführt.
• Drei BigQuery-Data-Warehouses: Eines speichert die vertraulichen Daten, eines die nicht vertraulichen Daten und das dritte die Sicherheitsrichtlinie.
• Data Catalog speichert die Tag-Vorlagen für die Verschlüsselung und De-Identifikation.
• Zwei Cloud Run-Instanzen:
  • Eine Instanz führt Report Engine aus, das prüft, ob Tags angewendet werden, und veröffentlicht Ergebnisse.
  • Eine andere Instanz führt Tag Engine aus, das die Daten im gesicherten Data Warehouse mit Tags versieht.
• Pub/Sub hat Ergebnisse veröffentlicht.

Die Architektur enthält die folgenden Ergebnisse, um Probleme im Zusammenhang mit dieser Kontrolle zu erkennen:

• Der Wert für das Tag der Verschlüsselungsmethode stimmt nicht mit den zulässigen Verschlüsselungsmethoden für die angegebene Vertraulichkeit und den angegebenen Standort überein.
• Eine Tabelle enthält vertrauliche Spalten, aber das Tag für die Sicherheitsrichtlinienvorlage enthält eine ungültige De-Identifikationsmethode auf Plattformebene.
• Eine Tabelle enthält vertrauliche Spalten, aber das Tag für die Sicherheitsrichtlinienvorlage fehlt.

10. Ein Datenschutz-Framework ist definiert und betriebsbereit

Bei dieser Kontrolle muss die Architektur den Datenkatalog und die Klassifizierungen prüfen, um festzustellen, ob Sie einen DSFA-Bericht (Datenschutz-Folgenabschätzung) oder einen PIA-Bericht (Privacy Impact Assessment, Privatsphäre-Folgenabschätzung) erstellen müssen. Die Privatsphäre-Abschätzungen variieren je nach Region und Aufsichtsbehörden erheblich. Zur Bestimmung, ob eine Folgenabschätzung erforderlich ist, muss die Architektur den Datenstandort und den Standort der betroffenen Person berücksichtigen.

Die Architektur verwendet Data Catalog, um der Tag-Vorlage Impact assessment die folgenden Tags hinzuzufügen:

• subject_locations: der Standort der betroffenen Personen, auf die in den Daten in diesem Asset verwiesen wird.
• is_dpia: gibt an, ob für dieses Asset eine Datenschutz-Folgenabschätzung (DSFA) durchgeführt wurde.
• is_pia: gibt an, ob für dieses Asset eine Privatsphäre-Folgenabschätzung (PIA) durchgeführt wurde.
• impact_assessment_reports: externer Link zum Speicherort des Berichts zur Folgenabschätzung.
• most_recent_assessment: das Datum der letzten Folgenabschätzung.
• oldest_assessment: das Datum der ersten Folgenabschätzung.

Tag Engine fügt diese Tags jedem vertraulichen Daten-Asset hinzu, wie in Kontrolle 6 definiert. Der Detektor validiert diese Tags anhand einer Richtlinientabelle in BigQuery, die gültige Kombinationen aus Datenstandort, Standort der betroffenen Person und Datenvertraulichkeit enthält (z. B. ob es sich um personenidentifizierbare Informationen handelt) und angibt, welche Art von Folgenabschätzung (entweder PIA oder DSFA) erforderlich ist.

Das folgende Diagramm zeigt die Dienste, die für diese Kontrolle gelten.

Die Architektur verwendet die folgenden Dienste, um die Anforderungen dieser Kontrolle zu erfüllen:

• Vier BigQuery-Data-Warehouses speichern folgende Informationen:
  • Vertrauliche Daten
  • Nicht vertrauliche Daten
  • Richtlinie zur Folgenabschätzung und Zeitstempel von Berechtigungen
  • Tag-Exporte, die für das Dashboard verwendet werden
• Data Catalog speichert die Folgenabschätzungsdetails in Tags in Tag-Vorlagen.
• Zwei Cloud Run-Instanzen:
  • Eine Instanz führt Report Engine aus, das prüft, ob Tags angewendet werden, und veröffentlicht Ergebnisse.
  • Eine andere Instanz führt Tag Engine aus, das die Daten im gesicherten Data Warehouse mit Tags versieht.
• Pub/Sub veröffentlicht Ergebnisse.

Die Architektur enthält die folgenden Ergebnisse, um Probleme im Zusammenhang mit dieser Kontrolle zu erkennen:

• Vertrauliche Daten sind ohne Vorlage für die Folgenabschätzung vorhanden.
• Vertrauliche Daten sind ohne Link zu einem DSFA- oder PIA-Bericht vorhanden.
• Tags erfüllen nicht die Anforderungen der Richtlinientabelle.
• Die Folgenabschätzung ist älter als die zuletzt genehmigte Berechtigung für das Daten-Asset in der Nutzervereinbarungstabelle.

11. Der Datenlebenszyklus wird geplant und verwaltet

Diese Kontrolle erfordert die Möglichkeit, alle Daten-Assets zu prüfen, um festzustellen, ob eine Datenlebenszyklus-Richtlinie vorhanden ist und eingehalten wird.

Die Architektur verwendet Data Catalog, um der Tag-Vorlage CDMC controls die folgenden Tags hinzuzufügen:

• retention_period: die Zeit in Tagen, für die die Tabelle aufbewahrt werden soll
• expiration_action: gibt an, ob die Tabelle nach Ablauf der Aufbewahrungsdauer archiviert oder dauerhaft gelöscht werden soll

Standardmäßig verwendet die Architektur die folgende Aufbewahrungsdauer und die folgende Ablaufaktion:

Datenkategorie	Aufbewahrungsdauer in Tagen	Ablaufaktion
Vertrauliche personenidentifizierbare Informationen	60	Dauerhaft löschen
Personenidentifizierbare Informationen	90	Archivieren
Vertrauliche personenbezogene Daten	180	Archivieren
Personenbezogene Daten	180	Archivieren

Record Manager, ein Open-Source-Asset für BigQuery, automatisiert das dauerhafte Löschen und das Archivieren von BigQuery-Tabellen anhand der oben genannten Tag-Werte und einer Konfigurationsdatei. Das dauerhafte Löschen legt ein Ablaufdatum für eine Tabelle fest und erstellt eine Snapshot-Tabelle mit einer Ablaufzeit, die in der Record Manager-Konfiguration definiert ist. Standardmäßig beträgt die Ablaufzeit 30 Tage. Während des vorläufigen Löschens können Sie die Tabelle abrufen. Das Archivierungsverfahren erstellt eine externe Tabelle für jede BigQuery-Tabelle, die die Aufbewahrungsdauer überschreitet. Die Tabelle wird im Parquet-Format in Cloud Storage gespeichert und auf eine BigLake-Tabelle aktualisiert. Damit kann die externe Datei mit Metadaten in Data Catalog getaggt werden.

Das folgende Diagramm zeigt die Dienste, die für diese Kontrolle gelten.

Die Architektur verwendet die folgenden Dienste, um die Anforderungen dieser Kontrolle zu erfüllen:

• Zwei BigQuery-Data-Warehouses: In einem sind die vertraulichen Daten gespeichert, im anderen die Richtlinien zur Datenaufbewahrung.
• Zwei Cloud Storage-Instanzen: Eine bietet Archivspeicher und die andere speichert Datensätze.
• Data Catalog speichert die Aufbewahrungsdauer und die Aktion in Tag-Vorlagen und den Tags.
• Zwei Cloud Run-Instanzen: eine führt Record Manager aus und die andere stellt die Detektoren bereit.
• Drei Cloud Run-Instanzen:
  • Eine Instanz führt Report Engine aus, das prüft, ob Tags angewendet werden, und veröffentlicht Ergebnisse.
  • Eine andere Instanz führt Tag Engine aus, das die Daten im gesicherten Data Warehouse mit Tags versieht.
  • Auf der dritten Instanz wird Record Manager ausgeführt, das das dauerhafte Löschen und das Archivieren von BigQuery-Tabellen automatisiert.
• Pub/Sub veröffentlicht Ergebnisse.

Die Architektur enthält die folgenden Ergebnisse, um Probleme im Zusammenhang mit dieser Kontrolle zu erkennen:

• Achten Sie bei vertraulichen Assets darauf, dass die Aufbewahrungsmethode der Richtlinie für den Speicherort des Assets entspricht.
• Achten Sie bei vertraulichen Assets darauf, dass die Aufbewahrungsdauer mit der Richtlinie für den Speicherort des Assets übereinstimmt.

12. Datenqualität wird verwaltet

Mit dieser Kontrolle kann die Qualität der Daten basierend auf Datenprofilen oder benutzerdefinierten Messwerten gemessen werden.

Die Architektur umfasst die Möglichkeit, Regeln für Datenqualität für einen einzelnen oder aggregierten Wert zu definieren und einer bestimmten Tabellenspalte Grenzwerte zuzuweisen. Sie enthält Tag-Vorlagen für Richtigkeit und Vollständigkeit. Data Catalog fügt jeder Tag-Vorlage die folgenden Tags hinzu:

• column_name: der Name der Spalte, für die der Messwert gilt
• metric: der Name des Messwerts oder der Qualitätsregel
• rows_validated: die Anzahl der validierten Zeilen
• success_percentage: der Prozentsatz der Werte, die diesen Messwert erfüllen
• acceptable_threshold: der akzeptable Grenzwert für diesen Messwert
• meets_threshold: gibt an, ob der Qualitätsfaktor (der Wert success_percentage) zum akzeptablen Grenzwert passt
• most_recent_run: der Zeitpunkt, zu dem der Messwert oder die Qualitätsregel zuletzt ausgeführt wurde

Das folgende Diagramm zeigt die Dienste, die für diese Kontrolle gelten.

Die Architektur verwendet die folgenden Dienste, um die Anforderungen dieser Kontrolle zu erfüllen:

• Drei BigQuery-Data-Warehouses: Eines speichert die vertraulichen Daten, eines die nicht vertraulichen Daten und das dritte die Messwerte der Qualitätsregel.
• Data Catalog speichert die Ergebnisse zur Datenqualität in Tag-Vorlagen und Tags.
• Cloud Scheduler definiert, wann die Cloud Data Quality Engine ausgeführt wird.
• Drei Cloud Run-Instanzen:
  • Eine Instanz führt Report Engine aus, das prüft, ob Tags angewendet werden, und veröffentlicht Ergebnisse.
  • Eine andere Instanz führt Tag Engine aus, das die Daten im gesicherten Data Warehouse mit Tags versieht.
  • Auf der dritten Instanz wird Cloud Data Quality Engine ausgeführt.
• Mit Cloud Data Quality Engine werden Datenqualitätsregeln definiert und Datenqualitätsprüfungen für Tabellen und Spalten geplant.
• Pub/Sub veröffentlicht Ergebnisse.

Im Looker Studio-Dashboard werden die Datenqualitätsberichte sowohl für die Tabellen- als auch für die Spaltenebene angezeigt.

Die Architektur enthält die folgenden Ergebnisse, um Probleme im Zusammenhang mit dieser Kontrolle zu erkennen:

• Daten sind vertraulich, aber es werden keine Tag-Vorlagen für Datenqualität angewendet (Richtigkeit und Vollständigkeit).
• Die Daten sind vertraulich, aber das Datenqualitäts-Tag wird nicht auf die vertrauliche Spalte angewendet.
• Die Daten sind vertraulich, aber die Ergebnisse zur Datenqualität liegen nicht innerhalb des in der Regel festgelegten Grenzwerts.
• Die Daten sind nicht vertraulich und die Ergebnisse zur Datenqualität liegen nicht innerhalb des Grenzwerts, der von der Regel festgelegt wurde.

Als Alternative zu Cloud Data Quality Engine können Sie Dataplex-Datenqualitätsaufgaben konfigurieren.

13. Die Grundsätze des Kostenverwaltung werden festgelegt und angewendet

Diese Kontrolle erfordert die Möglichkeit, Daten-Assets anhand der Richtlinienanforderungen und der Datenarchitektur zu prüfen, um die Kostennutzung zu bestätigen. Kostenmesswerte sollten umfassend und nicht nur auf die Speichernutzung und -übertragung beschränkt sein.

Die Architektur verwendet Data Catalog, um die folgenden Tags zur Tag-Vorlage cost_metrics hinzuzufügen:

• total_query_bytes_billed: Gesamtzahl der Abfragebyte, die für dieses Daten-Asset seit Beginn des aktuellen Monats in Rechnung gestellt wurden.
• total_storage_bytes_billed: Gesamtzahl der Speicherbyte, die für dieses Daten-Asset seit Beginn des aktuellen Monats in Rechnung gestellt wurden.
• total_bytes_transferred: Summe der Byte, die regionenübergreifend in dieses Daten-Asset übertragen wurden.
• estimated_query_cost: geschätzte Abfragekosten in US-Dollar für das Daten-Asset für den aktuellen Monat.
• estimated_storage_cost: geschätzten Speicherkosten in US-Dollar für das Daten-Asset für den aktuellen Monat.
• estimated_egress_cost: geschätzter ausgehender Traffic in US-Dollar für den aktuellen Monat, in dem das Daten-Asset als Zieltabelle verwendet wurde.

Die Architektur exportiert Preisinformationen aus Cloud Billing in eine BigQuery-Tabelle mit dem Namen cloud_pricing_export.

Das folgende Diagramm zeigt die Dienste, die für diese Kontrolle gelten.

Die Architektur verwendet die folgenden Dienste, um die Anforderungen dieser Kontrolle zu erfüllen:

• Cloud Billing bietet Zahlungsinformationen.
• Data Catalog speichert die Kosteninformationen in Tag-Vorlagen und Tags.
• BigQuery speichert die exportierten Preisinformationen und die Verlaufsinformationen zum Abfragejob über die integrierte Ansicht INFORMATION_SCHEMA.
• Zwei Cloud Run-Instanzen:
  • Eine Instanz führt Report Engine aus, das prüft, ob Tags angewendet werden, und veröffentlicht Ergebnisse.
  • Eine andere Instanz führt Tag Engine aus, das die Daten im gesicherten Data Warehouse mit Tags versieht.
• Pub/Sub veröffentlicht Ergebnisse.

Zur Erkennung von Problemen im Zusammenhang mit dieser Kontrolle prüft die Architektur, ob vertrauliche Daten-Assets vorhanden sind, ohne dass Kostenmesswerte damit verknüpft sind.

14. Datenherkunft wird verstanden

Diese Kontrolle erfordert die Möglichkeit, die Rückverfolgbarkeit des Daten-Assets aus seiner Quelle sowie Änderungen an der Herkunft des Daten-Assets zu prüfen.

Die Architektur verwendet die integrierten Features zur Datenherkunft in Data Catalog, um Informationen zur Datenherkunft zu speichern. Darüber hinaus definieren die Datenaufnahmeskripts die ultimative Quelle und fügen die Quelle als zusätzlichen Knoten zum Datenherkunftsdiagramm hinzu.

Zur Erfüllung der Anforderungen dieser Kontrolle verwendet die Architektur Data Catalog, um das Tag ultimate_source zur Tag-Vorlage CDMC controls hinzuzufügen. Das Tag ultimate_source definiert die Quelle für dieses Daten-Asset.

Das folgende Diagramm zeigt die Dienste, die für diese Kontrolle gelten.

Die Architektur verwendet die folgenden Dienste, um die Anforderungen dieser Kontrolle zu erfüllen:

• Zwei BigQuery-Data-Warehouses: Eines speichert die vertraulichen Daten und das andere die Daten der ultimativen Quelle.
• Data Catalog speichert die ultimative Quelle in Tag-Vorlagen und Tags.
• Datenaufnahmeskripts laden die Daten aus Cloud Storage, definieren die ultimative Quelle und fügen die Quelle dem Datenherkunftsdiagramm hinzu.
• Zwei Cloud Run-Instanzen:
  • Eine Instanz führt Report Engine aus, das prüft, ob Tags angewendet werden, und veröffentlicht Ergebnisse.
  • Eine andere Instanz führt Tag Engine aus, das die Daten im gesicherten Data Warehouse mit Tags versieht.
• Pub/Sub veröffentlicht Ergebnisse.

Die Architektur enthält die folgenden Prüfungen, um mit dieser Kontrolle verbundene Probleme zu erkennen:

• Vertrauliche Daten werden ohne Tag zur ultimativen Quelle.
• Das Herkunftsdiagramm wird nicht für vertrauliche Daten-Assets ausgefüllt.

Tag-Referenz

In diesem Abschnitt werden die Tag-Vorlagen und Tags beschrieben, die diese Architektur verwendet, um die Anforderungen der CDMC-Schlüsselkontrollen zu erfüllen.

CDMC-Kontroll-Tag-Vorlagen auf Tabellenebene

In der folgenden Tabelle sind die Tags aufgeführt, die Teil der Vorlage für CDMC-Kontroll-Tags sind und auf Tabellen angewendet werden.

Tag	Tag-ID	Anwendbare Schlüsselkontrolle
Genehmigter Speicherort	approved_storage_location	4
Genehmigte Nutzung	approved_use	8
E-Mail-Adresse des Dateninhabers	data_owner_email	2
Name des Dateninhabers	data_owner_name	2
Verschlüsselungsmethode	encryption_method	9
Ablaufaktion	expiration_action	11
Ist autoritativ	is_authoritative	3
Ist vertraulich	is_sensitive	6
Vertrauliche Kategorie	sensitive_category	6
Region des Freigabebereichs	sharing_scope_geography	8
Rechtspersönlichkeit des Freigabebereichs	sharing_scope_legal_entity	8
Aufbewahrungsdauer	retention_period	11
Ultimative Quelle	ultimate_source	14

Tag-Vorlage für die Folgenabschätzung

In der folgenden Tabelle sind die Tags aufgeführt, die Teil der Tag-Vorlage für die Folgenabschätzung sind und auf Tabellen angewendet werden.

Tag	Tag-ID	Anwendbare Schlüsselkontrolle
Standorte der betroffenen Personen	subject_locations	10
Ist DSFA-Folgenabschätzung	is_dpia	10
Ist PIA-Folgenabschätzung	is_pia	10
Berichte zur Folgenabschätzung	impact_assessment_reports	10
Letzte Folgenabschätzung	most_recent_assessment	10
Älteste Folgenabschätzung	oldest_assessment	10

Tag-Vorlage für Kostenmesswerte

In der folgenden Tabelle sind die Tags aufgeführt, die Teil der Tag-Vorlage für Kostenmesswerte sind und auf Tabellen angewendet werden.

Tag	Tab ID	Anwendbare Schlüsselkontrolle
Geschätzte Abfragekosten	estimated_query_cost	13
Geschätzte Speicherkosten	estimated_storage_cost	13
Geschätzte Kosten für ausgehenden Traffic	estimated_egress_cost	13
Gesamtzahl der in Rechnung gestellten Abfragebyte	total_query_bytes_billed	13
Gesamtzahl der in Rechnung gestellten Speicherbyte	total_storage_bytes_billed	13
Gesamtzahl der übertragenen Byte	total_bytes_transferred	13

Tag-Vorlage für Datenvertraulichkeit

In der folgenden Tabelle sind die Tags aufgeführt, die Teil der Tag-Vorlage für die Datenvertraulichkeit sind und auf Felder angewendet werden.

Tag	Tag-ID	Anwendbare Schlüsselkontrolle
Vertrauliches Feld	sensitive_field	6
Vertraulicher Typ	sensitive_category	6

Tag-Vorlage für Sicherheitsrichtlinien

In der folgenden Tabelle sind die Tags aufgeführt, die Teil der Tag-Vorlage für Sicherheitsrichtlinien sind und auf Felder angewendet werden.

Tag	Tag-ID	Anwendbare Schlüsselkontrolle
De-Identifikationsmethode der Anwendung	app_deid_method	9
De-Identifikationsmethode der Plattform	platform_deid_method	9

Tag-Vorlagen für Datenqualität

In der folgenden Tabelle sind die Tags aufgeführt, die Teil der Datenqualitäts-Tag-Vorlagen für die Vollständigkeit und Richtigkeit sind und auf Felder angewendet werden.

Tag	Tag-ID	Anwendbare Schlüsselkontrolle
Zulässiger Grenzwert	acceptable_threshold	12
Spaltenname	column_name	12
Passt zum Grenzwert	meets_threshold	12
Messwert	metric	12
Letzte Ausführung	most_recent_run	12
Validierte Zeilen	rows_validated	12
Erfolgsprozentsatz	success_percentage	12

CDMC-Richtlinien-Tags auf Feldebene

In der folgenden Tabelle sind die Richtlinien-Tags aufgeführt, die Teil der Taxonomie von CDMC-Richtlinien-Tags sind und auf Felder angewendet werden. Diese Richtlinien-Tags schränken den Zugriff auf Feldebene ein und ermöglichen die De-Identifikation von Daten auf Plattformebene.

Datenklassifizierung	Tag-Name	Anwendbare Schlüsselkontrolle
Personenidentifizierbare Informationen	personal_identifiable_information	7
Personenbezogene Daten	personal_information	7
Vertrauliche personenidentifizierbare Informationen	sensitive_personal_identifiable_information	7
Vertrauliche personenbezogene Daten	sensitive_personal_data	7

Vorab ausgefüllte technische Metadaten

In der folgenden Tabelle sind die technischen Metadaten aufgeführt, die standardmäßig in Data Catalog für alle BigQuery-Daten-Assets synchronisiert werden.

Metadaten	Anwendbare Schlüsselkontrolle
Assettyp	–
Erstellungszeitpunkt	–
Ablaufzeit	11
Standort	4
Ressourcen-URL	3

Nächste Schritte

• Weitere Informationen zu CDMC
• Lesen Sie mehr über die Sicherheitskontrollen, die im gesicherten Data Warehouse-Blueprint verwendet werden.
• Data Catalog entdecken
• Weitere Informationen zu Dataplex
• Weitere Informationen zu Tag Engine
• Implementieren Sie diese Lösung mithilfe der Google Cloud-CDMC-Referenzarchitektur in GitHub.