Daten in ein gesichertes BigQuery-Data Warehouse importieren

Viele Organisationen stellen Data Warehouses bereit, in denen vertrauliche Daten gespeichert werden, damit sie die Daten für verschiedene geschäftliche Zwecke analysieren können. Dieses Dokument richtet sich an Data Engineers und Sicherheitsadministratoren, die Data Warehouses mit BigQuery bereitstellen und schützen. Sie ist Teil eines Blueprints, das aus folgenden Elementen besteht:

• Zwei GitHub-Repositories (terraform-google-secured-data-warehouse und terraform-google-secured-data-warehouse-onprem-ingest), die Terraform-Konfigurationen und ‑Scripts enthalten. Mit der Terraform-Konfiguration wird eine Umgebung in Google Cloud eingerichtet, die ein Data Warehouse unterstützt, in dem vertrauliche Daten gespeichert werden.
• Einer Anleitung zu den Architektur-, Design- und Sicherheitskontrollen dieses Blueprints (dieses Dokument).
• Eine Schritt-für-Schritt-Anleitung zum Bereitstellen einer Beispielumgebung.

In diesem Dokument wird Folgendes behandelt:

• Die Architektur und Google Cloud Dienste, mit denen Sie ein Data Warehouse in einer Produktionsumgebung schützen können.
• Best Practices zum Importieren von Daten aus einem externen Netzwerk, z. B. einer lokalen Umgebung in BigQuery.

• Best Practices für die Data Governance beim Erstellen, Bereitstellen und Ausführen eines Data Warehouse inGoogle Cloud, darunter:

  • De-Identifikation von Daten

  • differenzielle Behandlung vertraulicher Daten

  • Verschlüsselung auf Spaltenebene

  • Zugriffssteuerung auf Spaltenebene

In diesem Dokument wird davon ausgegangen, dass Sie bereits einen grundlegenden Satz von Sicherheitskontrollen konfiguriert haben, wie im Blueprint für Unternehmensgrundlagen beschrieben. Es hilft Ihnen, zusätzliche Kontrollen über Ihre vorhandenen Sicherheitskontrollen zu legen, um vertrauliche Daten in einem Data Warehouse zu schützen.

Anwendungsfälle: Data Warehouses

Dieser Blueprint unterstützt die folgenden Anwendungsfälle:

• Mit dem Repository terraform-google-secured-data-warehouse Daten aus Google Cloud in ein BigQuery-Data Warehouse importieren
• Mit dem Repository terraform-google-secured-data-warehouse-onprem-ingest Daten aus einer lokalen Umgebung oder einer anderen Cloud in ein BigQuery-Data Warehouse importieren

Übersicht

Mit Data Warehouses wie BigQuery können Unternehmen ihre Geschäftsdaten analysieren. Die Analysten greifen auf die in Data Warehouses gespeicherten Geschäftsdaten zu, um Erkenntnisse zu gewinnen. Wenn Ihr Data Warehouse vertrauliche Daten enthält, müssen Sie Maßnahmen ergreifen, um die Sicherheit, Vertraulichkeit, Integrität und Verfügbarkeit der Geschäftsdaten zu erhalten, während sie gespeichert, übertragen oder analysiert werden. In diesem Blueprint tun Sie Folgendes:

• Verschlüsseln Sie beim Importieren von Daten aus externen Datenquellen Daten, die sich außerhalb von Google Cloud befinden(z. B. in einer lokalen Umgebung), und importieren Sie sie in Google Cloud.
• Steuerungen konfigurieren, die den Zugriff auf vertrauliche Daten sichern
• Steuerungen zum Schutz der Datenpipeline konfigurieren
• Geeignete Aufgabentrennung für verschiedene Identitäten konfigurieren
• Wenn Sie Daten aus anderen Quellen in Google Cloud importieren(auch interne Datenquellen genannt), richten Sie Vorlagen ein, um vertrauliche Daten zu finden und zu de-identifizieren.
• geeignete Sicherheitskontrollen und Logging einrichten, um vertrauliche Daten zu schützen
• Verwenden Sie Datenklassifizierung, Richtlinien-Tags, dynamische Datenmaskierung und Verschlüsselung auf Spaltenebene, um den Zugriff auf bestimmte Spalten im Data Warehouse einzuschränken.

Architektur

Zum Erstellen eines vertraulichen Data Warehouse müssen Sie Daten sicher importieren und dann in einem VPC Service Controls-Perimeter speichern.

Architektur beim Importieren von Daten aus Google Cloud

Die folgende Abbildung zeigt, wie aufgenommene Daten kategorisiert, de-identifiziert und gespeichert werden, wenn Sie Quelldaten aus Google Cloud mithilfe desterraform-google-secured-data-warehouse-Repositories importieren. Außerdem erfahren Sie, wie Sie vertrauliche Daten bei Bedarf zur Analyse re-identifizieren.

Architektur beim Importieren von Daten aus externen Quellen

Auf der folgenden Abbildung ist dargestellt, wie Daten aufgenommen und gespeichert werden, wenn Sie Daten aus einer lokalen Umgebung oder einer anderen Cloud mithilfe des terraform-google-secured-data-warehouse-onprem-ingest-Repositories in ein BigQuery-Warehouse importieren.

Google Cloud -Dienste und ‐Funktionen

Die Architekturen verwenden eine Kombination der folgenden Google Cloud Dienste und Funktionen:

Dienst oder Funktion	Beschreibung
BigQuery	Gilt sowohl für interne als auch für externe Datenquellen. Es gibt jedoch verschiedene Speicheroptionen: Beim Importieren von Daten aus Google Cloudspeichert BigQuery die vertraulichen Daten im Perimeter für vertrauliche Daten. Beim Importieren von Daten aus einer externen Quelle speichert BigQuery die verschlüsselten Daten und den verpackten Verschlüsselungsschlüssel in separaten Tabellen. BigQuery verwendet verschiedene Sicherheitskontrollen zum Schutz von Inhalten, einschließlich Zugriffssteuerungen, Sicherheit auf Spaltenebene für vertrauliche Daten und Datenverschlüsselung.
Cloud Key Management Service (Cloud KMS) mit Cloud HSM	Gilt sowohl für interne als auch für externe Quellen. Es gibt jedoch einen zusätzlichen Anwendungsfall für externe Datenquellen. Cloud HSM ist ein cloudbasierter HSM-Dienst (Hardware Security Module), der den Schlüsselverschlüsselungsschlüssel (KEK) hostet. Wenn Sie Daten aus einer externen Quelle importieren, generieren Sie mit Cloud HSM den Verschlüsselungsschlüssel, mit dem Sie die Daten in Ihrem Netzwerk verschlüsseln, bevor Sie sie an Google Cloudsenden.
Cloud Logging	Gilt sowohl für interne als auch für externe Quellen. Cloud Logging erfasst alle Logs aus Google Cloud Diensten zum Speichern und Abrufen durch Ihre Analyse- und Prüftools.
Cloud Monitoring	Gilt sowohl für interne als auch für externe Quellen. Cloud Monitoring erfasst und speichert Leistungsinformationen und Messwerte zu Google Cloud -Diensten.
Cloud Run Functions	Gilt nur für externe Datenquellen. Cloud Run-Funktionen werden von Cloud Storage ausgelöst und schreiben die Daten, die Cloud Storage in den Aufnahme-Bucket hochlädt, in BigQuery.
Cloud Storage und Pub/Sub	Gilt sowohl für interne als auch für externe Quellen. Cloud Storage und Pub/Sub empfangen Daten so: Cloud Storage:empfängt und speichert Batchdaten. Standardmäßig verwendet Cloud Storage TLS zum Verschlüsseln von Daten bei der Übertragung und AES-256 zum Verschlüsseln von Daten im Speicher. Der Verschlüsselungsschlüssel ist ein vom Kunden verwalteter Verschlüsselungsschlüssel (CMEK). Weitere Informationen zur Verschlüsselung finden Sie unter Datenverschlüsselungsoptionen. Sie können den Zugriff auf Cloud Storage-Buckets mithilfe von Sicherheitskontrollen wie Identity and Access Management, ACLs (Access Control Lists) und Richtliniendokumenten sichern. Weitere Informationen zu unterstützten Zugriffssteuerungen finden Sie unter Übersicht über die Zugriffssteuerung. Pub/Sub: empfängt und speichert Streamingdaten vor der De-Identifikation. Pub/Sub verwendet Authentifizierung, Zugriffssteuerungen und Verschlüsselung auf Nachrichtenebene mit einem CMEK, um Ihre Daten zu schützen.
Datenprofiler für BigQuery	Gilt sowohl für interne als auch für externe Quellen. Data Profiler für BigQuery sucht automatisch in allen BigQuery-Tabellen und -Spalten in der gesamten Organisation nach sensiblen Daten, auch in allen Ordnern und Projekten.
Dataflow-Pipelines	Gilt sowohl für interne als auch externe Quellen. Es gibt jedoch unterschiedliche Pipelines. In Dataflow-Pipelines werden Daten so importiert: Beim Importieren von Daten aus Google Cloudwerden vertrauliche Daten in zwei Dataflow-Pipelines de-identifiziert und re-identifiziert. Die erste Pipeline de-identifiziert vertrauliche Daten mithilfe von Pseudonymisierung. Die zweite Pipeline re-identifiziert vertrauliche Daten, wenn autorisierte Nutzer Zugriff benötigen. Beim Importieren von Daten aus einer externen Quelle schreibt eine Dataflow-Pipeline Streamingdaten in BigQuery.
Dataplex Universal Catalog	Gilt sowohl für interne als auch für externe Quellen. Dataplex Universal Catalog kategorisiert während der Aufnahme automatisch vertrauliche Daten mit Metadaten. Diese werden auch als Richtlinien-Tags bezeichnet. Dataplex Universal Catalog verwendet auch Metadaten, um den Zugriff auf vertrauliche Daten zu verwalten. Zur Kontrolle des Zugriffs auf Daten im Data Warehouse wenden Sie Richtlinien-Tags auf Spalten an, die vertrauliche Daten enthalten.
Dedicated Interconnect	Gilt nur für externe Datenquellen. Mit Dedicated Interconnect können Sie Daten zwischen Ihrem Netzwerk und Google Cloudübertragen. Sie können eine andere Verbindungsoption verwenden, wie unter Network Connectivity-Produkt wählen beschrieben.
IAM und Ressourcenmanager	Gilt sowohl für interne als auch für externe Quellen. Identity and Access Management (IAM) und Resource Manager beschränken den Zugriff und segmentieren Ressourcen. Die Zugriffssteuerung und die Ressourcenhierarchie folgen dem Prinzip der geringsten Berechtigung.
Security Command Center	Gilt sowohl für interne als auch für externe Quellen. Security Command Center überwacht und prüft Sicherheitsergebnisse aus Ihrer Google Cloud-Umgebung an einem zentralen Ort.
Sensitive Data Protection	Gilt sowohl für interne als auch externe Quellen. Es werden jedoch unterschiedliche Scans durchgeführt. Der Schutz sensibler Daten scannt Daten so: Beim Importieren von Daten aus Google Cloudwerden vertrauliche Daten mithilfe von Sensitive Data Protection während der Datenaufnahme de-identifiziert. Mit Sensitive Data Protection werden strukturierte und unstrukturierte Daten anhand der erkannten infoTypes oder Datensätze de-identifiziert. Beim Importieren von Daten aus einer externen Quelle werden mit dem Schutz sensibler Daten Daten in BigQuery gescannt, um nicht geschützte sensible Daten zu finden. Weitere Informationen finden Sie unter Schutz sensibler Daten zum Scannen von BigQuery-Daten verwenden.
VPC Service Controls	Gilt sowohl für interne als auch externe Quellen. Es gibt jedoch unterschiedliche Perimeter. VPC Service Controls erstellt Sicherheitsperimeter, die Dienste und Ressourcen isolieren, indem Autorisierung, Zugriffssteuerung und sicherer Datenaustausch eingerichtet werden. Die Perimeter sind folgende: Ein Datenaufnahmeperimeter akzeptiert eingehende Daten (als Batch oder Stream) und de-identifiziert sie. Eine separate Landing Zone trägt zum Schutz der übrigen Arbeitslasten vor eingehenden Daten bei. Beim Importieren von Daten aus Google Cloudkann ein Perimeter für vertrauliche Daten die vertraulichen Daten re-identifizieren und in einem eingeschränkten Bereich speichern. Beim Importieren externer Daten werden die Verschlüsselungsdaten durch einen Datenperimeter von anderen Arbeitslasten isoliert. Ein Governance-Perimeter, in dem die Verschlüsselungsschlüssel gespeichert werden und definiert wird, was als vertrauliche Daten gilt. Diese Perimeter sind zum Schutz eingehender Inhalte konzipiert, isolieren vertrauliche Daten durch die Einrichtung von zusätzlichen Zugriffssteuerungen und Monitoring und trennen Ihre Governance von den eigentlichen Daten im Warehouse. Ihre Governance umfasst Schlüsselverwaltung, die Datenkatalogverwaltung und das Logging.

Organisationsstruktur

Sie gruppieren die Ressourcen Ihrer Organisation, damit Sie sie verwalten und Ihre Testumgebungen von der Produktionsumgebung trennen können. Mit Resource Manager können Sie Ressourcen logisch nach Projekt, Ordner und Organisation gruppieren.

Die folgenden Diagramme zeigen eine Ressourcenhierarchie mit Ordnern, die verschiedene Umgebungen darstellen, z. B. „Bootstrap“, „Common“, „Production“, „Non-Production“ (oder „Staging“) und „Development“. Sie stellen die meisten Projekte in der Architektur im Production-Ordner und das Data Governance-Projekt im Common-Ordner bereit, der für die Governance verwendet wird.

Organisationsstruktur beim Importieren von Daten aus Google Cloud

Das folgende Diagramm zeigt die Organisationsstruktur beim Importieren von Daten ausGoogle Cloud mithilfe des terraform-google-secured-data-warehouse-Repositories.

Organisationsstruktur beim Importieren von Daten aus externen Quellen

Das folgende Diagramm zeigt die Organisationsstruktur beim Importieren von Daten aus einer externen Quelle mithilfe des terraform-google-secured-data-warehouse-onprem-ingest-Repositories.

Ordner

Mithilfe von Ordnern isolieren Sie Ihre Produktionsumgebung und Governance-Dienste von Ihren Nicht-Produktionsumgebungen und Testumgebungen. In der folgenden Tabelle werden die Ordner aus dem Unternehmensgrundlagen-Blueprint beschrieben, die von dieser Architektur verwendet werden.

Ordner	Beschreibung
Bootstrap	Enthält Ressourcen, die zum Bereitstellen des Unternehmensgrundlagen-Blueprints erforderlich sind.
Verbreitet	Enthält zentralisierte Dienste für die Organisation, z. B. das Data Governance-Projekt.
Produktion	Enthält Projekte mit Cloud-Ressourcen, die getestet wurden und einsatzbereit sind. In dieser Architektur enthält der Ordner „Produktion“ das Projekt für die Datenaufnahme und andere datenbezogene Projekte.
Nicht-Produktion	Enthält Projekte mit Cloud-Ressourcen, die getestet und zur Veröffentlichung bereitgestellt werden. In dieser Architektur enthält der Ordner „Nicht-Produktion“ das Datenaufnahmeprojekt und andere datenbezogene Projekte.
Entwicklung	Enthält Projekte mit Cloud-Ressourcen, die derzeit entwickelt werden. In dieser Architektur enthält der Ordner „Development“ das Datenaufnahmeprojekt und andere datenbezogene Projekte.

Sie können die Namen dieser Ordner an die Ordnerstruktur Ihrer Organisation anpassen. Wir empfehlen jedoch, eine ähnliche Struktur beizubehalten. Weitere Informationen finden Sie im Blueprint für Unternehmensgrundlagen.

Projekte

Sie isolieren Teile Ihrer Umgebung mithilfe von Projekten. In der folgenden Tabelle werden die Projekte beschrieben, die innerhalb der Organisation benötigt werden. Sie erstellen diese Projekte, wenn Sie den Terraform-Code ausführen. Sie können die Namen dieser Projekte ändern. Wir empfehlen jedoch, eine ähnliche Projektstruktur beizubehalten.

Projekt	Beschreibung
Datenaufnahme	Gemeinsames Projekt für interne und externe Quellen. Enthält Dienste, die zum Empfangen von Daten und zum De-Identifizieren vertraulicher Daten erforderlich sind.
Data Governance	Gemeinsames Projekt für interne und externe Quellen. Enthält Dienste, die Funktionen für Schlüsselverwaltung, Logging und Datenkatalogisierung bereitstellen.
Nicht vertrauliche Daten	Projekt nur für interne Quellen. Enthält Dienste, die zum Speichern von de-identifizierten Daten erforderlich sind.
Vertrauliche Daten	Projekt nur für interne Quellen. Enthält Dienste, die zum Speichern und Re-Identifizieren vertraulicher Daten erforderlich sind.
Daten	Projekt nur für externe Quellen. Enthält Dienste, die zum Speichern von Daten erforderlich sind.

Zusätzlich zu diesen Projekten muss Ihre Umgebung auch ein Projekt enthalten, das einen flexiblen Dataflow-Vorlagenjob hostet. Der flexible Vorlagenjob ist für die Streamingdaten-Pipeline erforderlich.

Rollen und Gruppen Projekten zuordnen

Sie müssen verschiedenen Nutzergruppen in Ihrer Organisation Zugriff auf die Projekte gewähren, aus denen das vertrauliche Data Warehouse besteht. In den folgenden Abschnitten werden die Architekturempfehlungen für Nutzergruppen und Rollenzuweisungen in den von Ihnen erstellten Projekten beschrieben. Sie können die Gruppen an die vorhandene Struktur Ihrer Organisation anpassen. Wir empfehlen jedoch, eine ähnliche Aufgabentrennung und Rollenzuweisung beizubehalten.

Gruppe der Datenanalysten

Datenanalysten analysieren die Daten im Warehouse. Im Repository terraform-google-secured-data-warehouse-onprem-ingest kann diese Gruppe Daten aufrufen, nachdem sie in das Data Warehouse geladen wurden, und dieselben Vorgänge wie die Gruppe Verschlüsselte Datenbetrachter ausführen.

In der folgenden Tabelle werden die Rollen der Gruppe in verschiedenen Projekten für das terraform-google-secured-data-warehouse-Repository beschrieben (nur interne Datenquellen).

Projektzuordnung	Rollen
Datenaufnahme	Dataflow-Entwickler (roles/dataflow.developer) Dataflow-Betrachter (roles/dataflow.viewer) Loganzeige (roles/logging.viewer) Zusätzliche Rolle für Datenanalysten, die Zugriff auf vertrauliche Daten benötigen: Detaillierter Lesezugriff (roles/datacatalog.categoryFineGrainedReader)
Vertrauliche Daten	BigQuery Data Viewer (roles/bigquery.dataViewer) BigQuery-Jobnutzer (roles/bigquery.jobUser) BigQuery-Nutzer (roles/bigquery.user) Dataflow-Entwickler (roles/dataflow.developer) Dataflow-Betrachter (roles/dataflow.viewer) Loganzeige (roles/logging.viewer)
Nicht vertrauliche Daten	BigQuery Data Viewer (roles/bigquery.dataViewer) BigQuery-Jobnutzer (roles/bigquery.jobUser) BigQuery-Nutzer (roles/bigquery.user) Loganzeige (roles/logging.viewer)

In der folgenden Tabelle sind die Rollen der Gruppe in verschiedenen Projekten für das terraform-google-secured-data-warehouse-onprem-ingest-Repository beschrieben (nur externe Datenquellen).

Umfang der Aufgabe	Rollen
Datenaufnahmeprojekt	Dataflow-Entwickler (roles/dataflow.developer) Dataflow-Betrachter (roles/dataflow.viewer) Loganzeige (roles/logging.viewer)
Datenprojekt	BigQuery Data Viewer (roles/bigquery.dataViewer) BigQuery-Jobnutzer (roles/bigquery.jobUser) BigQuery-Nutzer (roles/bigquery.user) Dataflow-Entwickler (roles/dataflow.developer) Dataflow-Betrachter (roles/dataflow.viewer) DLP-Administrator (roles/dlp.admin) Loganzeige (roles/logging.viewer)
Datenrichtlinienebene	Maskierter Leser (roles/bigquerydatapolicy.maskedReader)

Gruppe der Betrachter verschlüsselter Daten (nur externe Quellen)

Die Gruppe der Betrachter verschlüsselter Daten im Repository terraform-google-secured-data-warehouse-onprem-ingest kann verschlüsselte Daten aus BigQuery-Berichtstabellen über Looker Studio und andere Berichterstellungstools wie SAP-Business Objects einsehen. Die Gruppe der Betrachter verschlüsselter Daten kann keine Klartextdaten aus verschlüsselten Spalten aufrufen.

Für diese Gruppe ist die Rolle BigQuery-Nutzer (roles/bigquery.jobUser) im Datenprojekt erforderlich. Für diese Gruppe ist außerdem die Rolle Maskierter Leser (roles/bigquerydatapolicy.maskedReader) auf Datenrichtlinienebene erforderlich.

Gruppe: Klartext-Leser (nur externe Quellen)

Die Klartext-Lesegruppe im Repository terraform-google-secured-data-warehouse-onprem-ingest hat die erforderliche Berechtigung zum Aufrufen der benutzerdefinierten Entschlüsselungsfunktion, um Klartextdaten aufzurufen, sowie die zusätzliche Berechtigung zum Lesen nicht maskierter Daten.

Für diese Gruppe sind im Datenprojekt folgende Rollen erforderlich:

• BigQuery-Nutzer (roles/bigquery.user)
• BigQuery-Nutzer (roles/bigquery.jobUser)
• Cloud KMS-Betrachter (roles/cloudkms.viewer)

Außerdem ist für diese Gruppe die Rolle Detaillierter Lesezugriff (roles/datacatalog.categoryFineGrainedReader) auf Dataplex Universal Catalog-Ebene erforderlich.

Gruppe der Data Engineers

Data Engineers richten die Datenpipeline und das Warehouse ein.

In der folgenden Tabelle sind die Rollen der Gruppe in verschiedenen Projekten für das Repository terraform-google-secured-data-warehouse beschrieben.

Punktzahl der Aufgabe	Rollen
Datenaufnahmeprojekt	Cloud Build-Bearbeiter (roles/cloudbuild.builds.editor) Cloud KMS-Betrachter (roles/cloudkms.viewer) Composer-Nutzer (roles/composer.user) Compute-Netzwerknutzer (roles/compute.networkUser) Dataflow Admin (roles/dataflow.admin) Loganzeige (roles/logging.viewer)
Projekt mit vertraulichen Daten	BigQuery Data Editor (roles/bigquery.dataEditor) BigQuery-Jobnutzer (roles/bigquery.jobUser) Cloud Build-Bearbeiter (roles/cloudbuild.builds.editor) Cloud KMS-Betrachter (roles/cloudkms.viewer) Compute-Netzwerknutzer (roles/compute.networkUser) Dataflow Admin (roles/dataflow.admin) Loganzeige (roles/logging.viewer)
Projekt mit nicht vertraulichen Daten	BigQuery Data Editor (roles/bigquery.dataEditor) BigQuery-Jobnutzer (roles/bigquery.jobUser) Cloud KMS-Betrachter (roles/cloudkms.viewer) Loganzeige (roles/logging.viewer)

In der folgenden Tabelle sind die Rollen der Gruppe in verschiedenen Projekten für das Repository terraform-google-secured-data-warehouse-onprem-ingest beschrieben.

Umfang der Aufgabe	Rollen
Datenaufnahmeprojekt	Cloud Build-Bearbeiter (roles/cloudbuild.builds.editor) Cloud KMS-Betrachter (roles/cloudkms.viewer) Composer-Nutzer (roles/composer.user) Compute-Netzwerknutzer (roles/compute.networkUser) Dataflow Admin (roles/dataflow.admin) Loganzeige (roles/logging.viewer)
Datenprojekt	BigQuery Data Editor (roles/bigquery.dataEditor) BigQuery-Jobnutzer (roles/bigquery.jobUser) Cloud Build-Bearbeiter (roles/cloudbuild.builds.editor) Cloud KMS-Betrachter (roles/cloudkms.viewer) Compute-Netzwerknutzer (roles/compute.networkUser) Dataflow Admin (roles/dataflow.admin) DLP-Administrator (roles/dlp.admin) Loganzeige (roles/logging.viewer)

Gruppe der Netzwerkadministratoren

Netzwerkadministratoren konfigurieren das Netzwerk. In der Regel sind sie Mitglieder des Netzwerkteams.

Netzwerkadministratoren benötigen auf Organisationsebene die folgenden Rollen:

• Compute-Administrator (roles/compute.networkAdmin)
• Loganzeige (roles/logging.viewer)

Gruppe der Netzwerkadministratoren

Sicherheitsadministratoren verwalten Sicherheitskontrollen wie Zugriff, Schlüssel, Firewallregeln, VPC Service Controls und das Security Command Center.

Sicherheitsadministratoren benötigen die folgenden Rollen auf Organisationsebene:

• Access Context Manager-Administrator (roles/accesscontextmanager.policyAdmin)
• Cloud-Asset-Betrachter (roles/cloudasset.viewer)
• Cloud KMS-Administrator (roles/cloudkms.admin)
• Compute-Sicherheitsadministrator (roles/compute.securityAdmin)
• Data Catalog-Administrator (roles/datacatalog.admin)
• DLP-Administrator (roles/dlp.admin)
• Logging-Administrator (roles/logging.admin)
• Organizationsadministrator (roles/orgpolicy.policyAdmin)
• Sicherheitsadministrator (roles/iam.securityAdmin)

Gruppe der Sicherheitsanalysten

Sicherheitsanalysten achten auf Sicherheitsvorfälle und Probleme beim Schutz sensibler Daten und reagieren auf solche Ereignisse.

Sicherheitsanalysten benötigen auf Organisationsebene die folgenden Rollen:

• Access Context Manager-Leser (roles/accesscontextmanager.policyReader)
• Compute-Netzwerkbetrachter (roles/compute.networkViewer)
• Data Catalog-Betrachter (roles/datacatalog.viewer)
• Cloud KMS-Betrachter (roles/cloudkms.viewer)
• Loganzeige (roles/logging.viewer)
• Organisationsrichtlinien-Betrachter (roles/orgpolicy.policyViewer)
• Sicherheitscenter-Admin-Betrachter (roles/securitycenter.adminViewer)
• Sicherheitscenter-Ergebnisbearbeiter(roles/securitycenter.findingsEditor)
• Eine der folgenden Security Command Center-Rollen:
  • Bearbeiter von Bulk-Ausblendungen von Ergebnissen im Sicherheitscenter (roles/securitycenter.findingsBulkMuteEditor)
  • Sicherheitscenter-Ausblendungs-Festleger (roles/securitycenter.findingsMuteSetter)
  • Sicherheitscenter-Ergebniszustand-Festleger (roles/securitycenter.findingsStateSetter)

Beispiele für Gruppenzugriffsabläufe für externe Quellen

In den folgenden Abschnitten werden Zugriffsabläufe für zwei Gruppen beschrieben, die Daten aus externen Quellen über das terraform-google-secured-data-warehouse-onprem-ingest-Repository importieren.

Zugriffsablauf für die Gruppe „Ansicht verschlüsselter Daten“

Das folgende Diagramm zeigt, was passiert, wenn ein Nutzer aus der Gruppe: Ansicht verschlüsselter Daten versucht, auf verschlüsselte Daten in BigQuery zuzugreifen.

So greifen Sie auf Daten in BigQuery zu:

1. Ein Betrachter verschlüsselter Daten führt folgende Abfrage in BigQuery aus, um auf vertrauliche Daten zuzugreifen:

   SELECT ssn, pan FROM cc_card_table
   

2. In BigQuery wird der Zugriff so überprüft:

   • Der Nutzer wird mit gültigen, nicht abgelaufenen Google Cloud-Anmeldedaten authentifiziert.
   • Die Nutzeridentität und die IP-Adresse, von der die Anfrage stammt, sind Teil der Zulassungsliste in der Zugriffsebene oder der Regel für eingehenden Traffic im VPC Service Controls-Perimeter.
   • IAM prüft, ob der Nutzer die entsprechenden Rollen hat und berechtigt ist, auf die ausgewählten verschlüsselten Spalten in der BigQuery-Tabelle zuzugreifen.

BigQuery gibt die vertraulichen Daten im verschlüsselten Format zurück.

Zugriffsablauf für die Gruppe „Klartext-Leser“

Das folgende Diagramm zeigt, was geschieht, wenn ein Nutzer aus der Klartext-Leser-Gruppe versucht, in BigQuery auf verschlüsselte Daten zuzugreifen.

So greifen Sie auf Daten in BigQuery zu:

1. Der Klartext-Leser führt folgende Abfrage in BigQuery aus, um auf vertrauliche Daten im entschlüsselten Format zuzugreifen:

   SELECT decrypt_ssn(ssn) FROM cc_card_table
   

2. BigQuery ruft in der Abfrage die benutzerdefinierte Funktion (User -Defined Function, UDF) für die Entschlüsselung auf, um auf geschützte Spalten zuzugreifen.

3. Der Zugriff wird so verifiziert:

   • IAM prüft, ob der Nutzer die entsprechenden Rollen hat und berechtigt ist, auf die UDF für die Entschlüsselung in BigQuery zuzugreifen.
   • Die UDF ruft den verpackten Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) ab, der zum Schutz sensibler Datenspalten verwendet wurde.

4. Die entschlüsselte UDF ruft in Cloud HSM den Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) auf, um den DEK zu entpacken. Die UDF zum Entschlüsseln verwendet die BigQuery-AEAD-Entschlüsselungsfunktion, um die Spalten mit sensiblen Daten zu entschlüsseln.

5. Dem Nutzer wird Zugriff auf die Klartextdaten in den Spalten mit sensiblen Daten gewährt.

Gängige Sicherheitsmaßnahmen

In den folgenden Abschnitten werden die Steuerelemente beschrieben, die sowohl für interne als auch für externe Quellen gelten.

Einstellungen für die Datenaufnahme

Zum Erstellen Ihres Data Warehouse müssen Sie Daten aus einer anderenGoogle Cloud Quelle (z. B. einem Data Lake), Ihrer lokalen Umgebung oder einer anderen Cloud übertragen. Sie können eine der folgenden Optionen verwenden, um Ihre Daten in das Data Warehouse in BigQuery zu übertragen:

• Einen Batchjob, der Cloud Storage verwendet.
• Einen Streamingjob, der Pub/Sub verwendet.

Zum Schutz der Daten während der Aufnahme können Sie clientseitige Verschlüsselung, Firewallregeln und Richtlinien für die Zugriffsebene verwenden. Der Aufnahmeprozess wird manchmal als ETL-Prozess (Extrahieren, Transformieren, Laden) bezeichnet.

Netzwerk- und Firewallregeln

VPC-Firewallregeln (Virtual Private Cloud) steuern den Datenfluss in die Perimeter. Sie erstellen Firewallregeln, die den gesamten ausgehenden Traffic ablehnen, mit Ausnahme bestimmter Verbindungen über TCP-Port 443 von den speziellen restricted.googleapis.com-Domainnamen. Die restricted.googleapis.com-Domain hat folgende Vorteile:

• Sie reduziert die Netzwerkangriffsfläche durch Verwendung des privater Google-Zugriff, wenn Arbeitslasten mit Google APIs und Diensten kommunizieren.
• Es wird gewährleistet, dass Sie nur Dienste verwenden, die VPC Service Controls unterstützen.

Weitere Informationen finden Sie unter Privaten Google-Zugriff konfigurieren.

Wenn Sie das terraform-google-secured-data-warehouse-Repository verwenden, müssen Sie für jeden Dataflow-Job separate Subnetze konfigurieren. Durch separate Subnetze wird gewährleistet, dass die zu de-identifizierenden Daten ordnungsgemäß von den Daten getrennt werden, die re-identifiziert werden.

Für die Datenpipeline müssen Sie TCP-Ports in der Firewall öffnen, wie in der Datei dataflow_firewall.tf in den jeweiligen Repositories definiert. Weitere Informationen finden Sie unter Internetzugriff und Firewallregeln konfigurieren.

Wenn Sie verhindern möchten, dass Ressourcen externe IP-Adressen verwenden, wird die Organisationsrichtlinie Zulässige externe IPs für VM-Instanzen definieren (compute.vmExternalIpAccess) auf „Alle ablehnen“ gesetzt.

Perimetersteuerungen

Wie im Architekturdiagramm dargestellt, platzieren Sie die Ressourcen für das Data Warehouse in separaten Perimetern. Damit Dienste in verschiedenen Perimetern Daten gemeinsam nutzen können, erstellen Sie Perimeter-Bridges.

Perimeter-Bridges ermöglichen geschützten Diensten das Senden von Anfragen für Ressourcen außerhalb ihres Perimeters. Diese Bridges stellen die folgenden Verbindungen für das Repository terraform-google-secured-data-warehouse her:

• Sie verbinden das Datenaufnahmeprojekt mit dem Governance-Projekt, sodass die De-Identifikation während der Aufnahme erfolgen kann.
• Sie verbinden das nicht vertrauliche Datenprojekt und das vertrauliche Datenprojekt, sodass vertrauliche Daten re-identifiziert werden können, wenn ein Datenanalyst sie anfordert.
• Sie verbinden das vertrauliche Projekt mit dem Data-Governance-Projekt, sodass eine Re-Identifikation erfolgen kann, wenn ein Datenanalyst sie anfordert.

Diese Bridges stellen die folgenden Verbindungen für das Repository terraform-google-secured-data-warehouse-onprem-ingest her:

• Sie verbinden das Datenaufnahmeprojekt mit dem Datenprojekt, damit Daten in BigQuery aufgenommen werden können.
• Sie verbinden das Datenprojekt mit dem Data-Governance-Projekt, damit der Schutz sensibler Daten BigQuery auf ungeschützte vertrauliche Daten scannen kann.
• Sie verbinden das Datenaufnahmeprojekt mit dem Data-Governance-Projekt, um den Zugriff auf Logging, Monitoring und Verschlüsselungsschlüssel zu ermöglichen.

Neben Perimeter-Bridges verwenden Sie Regeln für ausgehenden Traffic, um Ressourcen, die durch Dienstperimeter geschützt sind, den Zugriff auf Ressourcen außerhalb des Perimeters zu ermöglichen. In dieser Lösung konfigurieren Sie Regeln für ausgehenden Traffic, um die externen flexiblen Dataflow-Vorlagenjobs abzurufen, die sich in Cloud Storage in einem externen Projekt befinden. Weitere Informationen finden Sie unter Zugriff auf eine Google Cloud Ressource außerhalb des Perimeters.

Zugriffsrichtlinie

Damit nur bestimmte Identitäten (Nutzer oder Dienste) auf Ressourcen und Daten zugreifen können, aktivieren Sie IAM-Gruppen und -Rollen.

Damit nur bestimmte Quellen auf Ihre Projekte zugreifen können, aktivieren Sie eine Zugriffsrichtlinie für Ihre Google-Organisation. Es wird empfohlen, eine Zugriffsrichtlinie zu erstellen, die den zulässigen IP-Adressbereich für Anfragen angibt und nur Anfragen von bestimmten Nutzern oder Dienstkonten zulässt. Weitere Informationen finden Sie unter Zugriffsebenenattribute.

Dienstkonten und Zugriffssteuerung

Dienstkonten sind Identitäten, mit denen Google Cloud API-Anfragen in Ihrem Namen ausgeführt werden können. Dienstkonten sorgen dafür, dass Nutzeridentitäten keinen direkten Zugriff auf Dienste haben. Um eine Aufgabentrennung zu ermöglichen, erstellen Sie für bestimmte Zwecke Dienstkonten mit unterschiedlichen Rollen. Diese Dienstkonten sind in jeder Architektur im data-ingestion-Modul und im confidential-data-Modul definiert.

Für das Repository terraform-google-secured-data-warehouse sind folgende Dienstkonten vorhanden:

• Ein Dataflow-Controller-Dienstkonto für die Dataflow-Pipeline, die vertrauliche Daten de-identifiziert.
• Ein Dataflow-Controller-Dienstkonto für die Dataflow-Pipeline, die vertrauliche Daten re-identifiziert.
• Ein Cloud Storage-Dienstkonto, um Daten aus einer Batchdatei aufzunehmen.
• Ein Pub/Sub-Dienstkonto, um Daten aus einem Streamingdienst aufzunehmen.
• Ein Cloud Scheduler-Dienstkonto, um den Dataflow-Batchjob auszuführen, der die Dataflow-Pipeline erstellt.

Die folgende Tabelle zeigt die Rollen, die den einzelnen Dienstkonten zugewiesen sind:

Dienstkonto	Name	Projekt	Rollen
Dataflow-Controller Dieses Konto wird zur De-Identifikation verwendet.	sa-dataflow-controller	Datenaufnahme	BigQuery Admin roles/bigquery.admin Cloud KMS-Administrator (roles/cloudkms.admin) Cloud KMS CryptoKey-Entschlüsseler (roles/cloudkms.cryptoKeyDecrypter) Compute-Betrachter (roles/compute.viewer) Dataflow-Worker (roles/dataflow.worker) DLP-Administrator (roles/dlp.admin) Pub/Sub-Abonnent (roles/pubsub.subscriber) Storage-Administrator (roles/storage.admin) Dataflow-Dienstagent (roles/dataflow.serviceAgent)
Dataflow-Controller Dieses Konto wird zur Re-Identifikation verwendet.	sa-dataflow-controller-reid	Vertrauliche Daten	BigQuery Admin roles/bigquery.admin Cloud KMS-Administrator (roles/cloudkms.admin) Cloud KMS CryptoKey-Entschlüsseler (roles/cloudkms.cryptoKeyDecrypter) Compute-Betrachter (roles/compute.viewer) Dataflow-Worker (roles/dataflow.worker) DLP-Administrator (roles/dlp.admin) Pub/Sub-Abonnent (roles/pubsub.subscriber) Storage-Administrator (roles/storage.admin) Dataflow-Dienstagent (roles/dataflow.serviceAgent)
Cloud Storage	sa-storage-writer	Datenaufnahme	Storage-Objekt-Ersteller (roles/storage.objectCreator) Storage-Objekt-Betrachter (roles/storage.ObjectViewer)
Pub/Sub	sa-pubsub-writer	Datenaufnahme	Pub/Sub Publisher (roles/pubsub.publisher) Pub/Sub-Abonnent (roles/pubsub.subscriber)
Cloud Scheduler	sa-scheduler-controller	Datenaufnahme	Compute-Betrachter (roles/compute.viewer) Dataflow-Entwickler (roles/dataflow.developer)

Für das Repository terraform-google-secured-data-warehouse-onprem-ingest sind folgende Dienstkonten vorhanden:

• Das Cloud Storage-Dienstkonto führt den automatisierten Upload von Batch-Daten in den Aufnahmespeicher-Bucket aus.
• Mit einem Pub/Sub-Dienstkonto können Daten an den Pub/Sub-Dienst gestreamt werden.
• Das Dataflow-Controller-Dienstkonto wird von der Dataflow-Pipeline verwendet, um Daten aus Pub/Sub in BigQuery zu transformieren und zu schreiben.
• Das Cloud Run-Funktionskonto schreibt nachfolgende Batch-Daten, die aus Cloud Storage in BigQuery hochgeladen wurden.
• Mit dem Dienstkonto für den Speicherupload kann die ETL-Pipeline Objekte erstellen.
• Mit dem Pub/Sub-Schreibdienstkonto kann die ETL-Pipeline Daten in Pub/Sub schreiben.

Die folgende Tabelle zeigt die Rollen, die den einzelnen Dienstkonten zugewiesen sind:

Name	Rollen	Umfang der Aufgabe
Dataflow-Controller-Dienstkonto	BigQuery Data Editor (roles/bigquery.dataEditor) BigQuery-Jobnutzer (roles/bigquery.jobUser) Dataflow-Entwickler (roles/dataflow.developer) Dataflow-Worker (roles/dataflow.worker) Pub/Sub-Bearbeiter (roles/pubsub.editor) Pub/Sub-Abonnent (roles/pubsub.subscriber) Service Usage Consumer (roles/serviceusage.serviceUsageConsumer) Storage-Objekt-Betrachter (roles/storage.ObjectViewer)	Datenaufnahmeprojekt
	BigQuery Data Editor (roles/bigquery.dataEditor) BigQuery Metadata Viewer (roles/bigquery.metadataViewer)	Datenprojekt
	Leser von DLP-Prüfungsergebnissen (roles/dlp.deidentifyTemplatesReader) Bearbeiter von DLP-Prüfungsvorlagen (roles/dlp.inspectTemplatesReader) DLP-Nutzer (roles/dlp.user)	Data Governance
Cloud Run-Funktionen-Dienstkonto	BigQuery Data Editor (roles/bigquery.dataEditor) BigQuery-Jobnutzer (roles/bigquery.jobUser) Cloud Run-Aufrufer (roles/run.invoker) Eventarc-Ereignisempfänger (roles/eventarc.eventReceiver)	Datenaufnahmeprojekt
	BigQuery Data Editor (roles/bigquery.dataEditor) BigQuery Metadata Viewer (roles/bigquery.metadataViewer)	Datenprojekt
Storage Upload-Dienstkonto	Storage-Objekt-Ersteller (roles/storage.objectCreator) Storage-Objekt-Betrachter (roles/storage.ObjectViewer)	Datenaufnahmeprojekt
Pub/Sub-Schreibdienstkonto	Pub/Sub Publisher (roles/pubsub.publisher) Pub/Sub-Abonnent (roles/pubsub.subscriber)	Datenaufnahmeprojekt

Organisationsrichtlinien

Diese Architektur enthält die Einschränkungen für Organisationsrichtlinien, die vom Unternehmensgrundlagen-Blueprint verwendet werden, und fügt zusätzliche Einschränkungen hinzu. Weitere Informationen zu den vom Unternehmensgrundlagen-Blueprint verwendeten Einschränkungen finden Sie unter Einschränkungen für Organisationsrichtlinien.

In der folgenden Tabelle werden die zusätzlichen Einschränkungen für Organisationsrichtlinien beschrieben, die im org_policies-Modul für die jeweiligen Repositories definiert sind:

Richtlinie	Name der Einschränkung	Empfohlener Wert
Ressourcenbereitstellungen auf bestimmte physische Standorte beschränken. Weitere Werte finden Sie unter Wertgruppen.	gcp.resourceLocations	Eine der folgenden Optionen: in:us-locations in:eu-locations in:asia-locations
Erstellen von Dienstkonten deaktivieren	iam.disableServiceAccountCreation	true
Aktivieren Sie OS Login für VMs, die im Projekt erstellt wurden.	compute.requireOsLogin	true
Neue Weiterleitungsregeln auf Basis der IP-Adresse als intern festlegen.	compute.restrictProtocolForwardingCreationForTypes	INTERNAL
Definieren Sie die Gruppe freigegebene VPC-Subnetzwerke, die von Compute Engine-Ressourcen verwendet werden können.	compute.restrictSharedVpcSubnetworks	projects//regions//s ubnetworks/. Ersetzen Sie durch die Ressourcen-ID des privaten Subnetzes, das die Architektur verwenden soll.
Deaktivieren Sie das Logging der Ausgabe des seriellen Ports für Cloud Logging.	compute.disableSerialPortLogging	true
CMEK-Schutz verlangen (nur terraform-google-secured-data-warehouse-onprem-ingest)	gcp.restrictNonCmekServices	bigquery.googleapis.com
Erstellen von Dienstkontoschlüsseln deaktivieren (terraform-google-secured-data-warehouse-onprem-ingest only)	disableServiceAccountKeyCreation	wahr
OS Login für VMs aktivieren, die im Projekt erstellt wurden (terraform-google-secured-data-warehouse-onprem-ingest only)	compute.requireOsLogin	wahr
Automatische Rollenzuweisungen für Standarddienstkonten deaktivieren (terraform-google-secured-data-warehouse-onprem-ingest only)	automaticIamGrantsForDefaultServiceAccounts	wahr
Zulässige Einstellungen für ausgehenden Traffic (Cloud Run-Funktionen) (terraform-google-secured-data-warehouse-onprem-ingest only)	cloudfunctions.allowedIngressSettings	ALLOW_INTERNAL_AND_GCLB

Sicherheitskontrollen für externe Datenquellen

In den folgenden Abschnitten werden die Steuerelemente beschrieben, die für die Datenaufnahme aus externen Quellen gelten.

Verschlüsselte Verbindung zu Google Cloud

Wenn Sie Daten aus externen Quellen importieren, können Sie Cloud VPN oder Cloud Interconnect verwenden, um alle Daten zu schützen, die zwischen Google Cloudund Ihrer Umgebung übertragen werden. Für diese Unternehmensarchitektur wird Dedicated Interconnect empfohlen, da dies eine direkte Verbindung und einen hohen Durchsatz bietet, was wichtig ist, wenn Sie viele Daten streamen.

Wenn Sie den Zugriff auf Google Cloud von Ihrer Umgebung aus zulassen möchten, müssen Sie in den Richtlinienregeln für Zugriffsebenen zugelassene IP-Adressen definieren.

Clientseitige Verschlüsselung

Bevor Sie sensible Daten in Google Cloudverschieben, verschlüsseln Sie Ihre Daten lokal, um sie bei Inaktivität und während der Übertragung zu schützen. Sie können die Verschlüsselungsbibliothek Tink oder andere Verschlüsselungsbibliotheken verwenden. Die Tink-Verschlüsselungsbibliothek ist mit der BigQuery-AEAD-Verschlüsselung kompatibel. Mit dieser wird in der Architektur verschlüsselte Daten auf Spaltenebene nach dem Import entschlüsselt.

Die Tink-Verschlüsselungsbibliothek verwendet DEKs, die Sie lokal oder über Cloud HSM generieren können. Zum Umschließen oder Schützen des DEK können Sie einen KEK verwenden, der in Cloud HSM generiert wird. Der KEK ist ein symmetrischer CMEK-Verschlüsselungs-Schlüsselsatz, der sicher in Cloud HSM gespeichert und mit IAM-Rollen und -Berechtigungen verwaltet wird.

Während der Datenaufnahme werden sowohl der verschlüsselte DEK als auch die Daten in BigQuery gespeichert. BigQuery enthält zwei Tabellen: eine für die Daten und eine für die verpackte DEK. Wenn Analysten vertrauliche Daten aufrufen müssen, kann BigQuery die AEAD-Entschlüsselung verwenden, um den DEK mit dem KEK zu entpacken und die geschützte Spalte zu entschlüsseln.

Außerdem werden Ihre Daten durch die clientseitige Verschlüsselung mit Tink zusätzlich geschützt, da sensible Datenspalten in BigQuery verschlüsselt werden. Die Architektur verwendet die folgenden Cloud HSM-Verschlüsselungsschlüssel:

• Einen CMEK-Schlüssel für den Aufnahmeprozess, der auch von Pub/Sub, der Dataflow-Pipeline für Streaming, dem Cloud Storage-Batch-Upload und von Cloud Run-Funktionen-Artefakten für nachfolgende Batch-Uploads verwendet wird.
• Der von Cloud HSM verpackte kryptografische Schlüssel für die Daten, die in Ihrem Netzwerk mit Tink verschlüsselt werden.
• Den CMEK-Schlüssel für das BigQuery-Warehouse im Datenprojekt.

Sie geben den CMEK-Standort an. Dieser bestimmt den geografischen Standort, an dem der Schlüssel gespeichert wird und für den Zugriff verfügbar ist. Sie müssen darauf achten, dass sich Ihr CMEK am selben Speicherort wie Ihre Ressourcen befindet. Standardmäßig wird der CMEK alle 30 Tage rotiert.

Wenn die Complianceverpflichtungen Ihrer Organisation erfordern, dass Sie Ihre eigenen Schlüssel extern über Google Cloudverwalten, können Sie Cloud External Key Manager aktivieren. Wenn Sie externe Schlüssel verwenden, sind Sie für die Schlüsselverwaltungsaktivitäten einschließlich der Schlüsselrotation verantwortlich.

Dynamische Datenmaskierung

Um Daten in großem Maßstab freizugeben und Richtlinien für den Datenzugriff anzuwenden, können Sie die dynamische Datenmaskierung konfigurieren. Bei der dynamischen Datenmaskierung können vorhandene Abfragen Spaltendaten automatisch gemäß folgender Kriterien maskieren:

• Maskierungsregeln, die zur Abfragelaufzeit auf die Spalte angewendet werden.
• Rollen, die dem Nutzer zugewiesen sind, der die Abfrage ausführt. Für den Zugriff auf nicht maskierte Spaltendaten müssen Datenanalysten die Rolle Detaillierter Lesezugriff haben.

Um den Zugriff für Spalten in BigQuery zu definieren, erstellen Sie Richtlinien-Tags. Beispiel: Die im eigenständigen Beispiel erstellte Taxonomie ersdtellt das Richtlinien-Tag 1_Sensitive für Spalten mit Daten, die nicht veröffentlicht werden dürfen, z. B. das Kreditlimit. Die Standardregel für die Datenmaskierung wird auf diese Spalten angewendet, um den Wert der Spalte auszublenden.

Alles, was nicht gekennzeichnet ist, steht allen Nutzern zur Verfügung, die Zugriff auf das Data Warehouse haben. Diese Zugriffssteuerungen sorgen dafür, dass Daten in vertraulichen Feldern auch nach dem Schreiben der Daten in BigQuery erst gelesen werden können, nachdem einem Nutzer explizit Zugriff gewährt wurde.

Ver- und Entschlüsselung auf Spaltenebene

Mit der Verschlüsselung auf Spaltenebene können Sie Daten in BigQuery detaillierter verschlüsseln. Statt eine ganze Tabelle zu verschlüsseln, wählen Sie in BigQuery die Spalten aus, die sensible Daten enthalten. BigQuery verwendet AEAD-Ver- und -Entschlüsselungsfunktionen, die Keysets erstellen, die Schlüssel für die Ver- und Entschlüsselung enthalten. Diese Schlüsseln werden dann zur Ver- und Entschlüsselung einzelner Werte in einer Tabelle sowie zur Rotation von Schlüsseln innerhalb eines Schlüsselsatzes genutzt. Die Verschlüsselung auf Spaltenebene bietet eine doppelte Zugriffssteuerung für verschlüsselte Daten in BigQuery, da Nutzer sowohl für die Tabelle als auch für den Verschlüsselungsschlüssel Berechtigungen zum Lesen von Daten als Klartext benötigen.

Datenprofiler für BigQuery mit Schutz sensibler Daten

Mit dem Data Profiler können Sie Speicherorte sensibler und riskanter Daten in BigQuery-Tabellen identifizieren. Data Profiler scannt und analysiert automatisch alle BigQuery-Tabellen und -Spalten in der gesamten Organisation, einschließlich aller Ordner und Projekte. Der Data Profiler gibt dann Messwerte wie die vorhergesagten infoTypes, die bewerteten Datenrisiko- und Empfindlichkeitsstufen sowie Metadaten zu Ihren Tabellen aus. Anhand dieser Informationen können Sie fundierte Entscheidungen darüber treffen, wie Sie Ihre Daten schützen, freigeben und verwenden.

Sicherheitskontrollen für interne Datenquellen

In den folgenden Abschnitten werden die Steuerelemente beschrieben, die für die Datenaufnahme ausGoogle Cloud -Quellen gelten.

Schlüsselverwaltung und Verschlüsselung für die Aufnahme

Bei beiden Aufnahmeoptionen (Cloud Storage oder Pub/Sub) wird Cloud HSM zum Verwalten des CMEK verwendet. Die CMEKs werden von Ihnen verwendet, um Ihre Daten während der Aufnahme zu schützen. Die Sensitive Data Protection schützt Ihre Daten zusätzlich, wozu vertrauliche Daten mit den von Ihnen konfigurierten Detektoren verschlüsselt werden.

Um Daten aufzunehmen, verwenden Sie die folgenden Verschlüsselungsschlüssel:

• Einen CMEK für den Aufnahmeprozess, der auch von der Dataflow-Pipeline und dem Pub/Sub-Dienst verwendet wird.
• Den mit Sensitive Data Protection von Cloud HSM verpackten kryptografischen Schlüssel für den Daten-De-Identifikationsprozess.
• Zwei CMEK-Schlüssel, einer für das BigQuery-Warehouse im nicht vertraulichen Datenprojekt und einer für das Warehouse im vertraulichen Datenprojekt. Weitere Informationen finden Sie unter Schlüsselverwaltung.

Sie geben den CMEK-Standort an. Dieser bestimmt den geografischen Standort, an dem der Schlüssel gespeichert wird und für den Zugriff verfügbar ist. Sie müssen darauf achten, dass sich Ihr CMEK am selben Speicherort wie Ihre Ressourcen befindet. Standardmäßig wird der CMEK alle 30 Tage rotiert.

Wenn die Complianceverpflichtungen Ihrer Organisation erfordern, dass Sie Ihre eigenen Schlüssel extern über Google Cloudverwalten, können Sie Cloud EKM aktivieren. Wenn Sie externe Schlüssel verwenden, sind Sie für die Schlüsselverwaltungsaktivitäten einschließlich der Schlüsselrotation verantwortlich.

Daten-De-Identifikation

Sie verwenden Sensitive Data Protection, um strukturierte und unstrukturierte Daten während der Aufnahmephase zu de-identifizieren. Bei strukturierten Daten verwenden Sie Datensatztransformationen basierend auf Feldern, um Daten zu de-identifizieren. Ein Beispiel für diesen Ansatz finden Sie im Ordner /examples/de_identification_template/. In diesem Beispiel werden strukturierte Daten auf Kreditkartennummern und Kreditkarten-PINs geprüft. Bei unstrukturierten Daten verwenden Sie Informationstypen, um Daten zu de-identifizieren.

Zum De-Identifizieren von als vertraulich gekennzeichneten Daten verwenden Sie Sensitive Data Protection und eine Dataflow-Pipeline, um diese zu tokenisieren. Diese Pipeline übernimmt Daten aus Cloud Storage, verarbeitet sie und sendet sie dann an das BigQuery-Data-Warehouse.

Weitere Informationen zum De-Identifikationsprozess von Daten finden Sie unter Data Governance.

Zugriffssteuerung auf Spaltenebene

Zum Schutz vertraulicher Daten verwenden Sie Zugriffssteuerungen für bestimmte Spalten im BigQuery-Warehouse. Damit auf die Daten in diesen Spalten zugegriffen werden kann, muss ein Datenanalyst die Rolle „Detaillierter Lesezugriff“ haben.

Um den Zugriff für Spalten in BigQuery zu definieren, erstellen Sie Richtlinien-Tags. Durch die Datei taxonomy.tf im bigquery-confidential-data-Beispiel werden beispielsweise die folgenden Tags erstellt:

• Ein 3_Confidential-Richtlinien-Tag für Spalten, die sehr vertrauliche Informationen wie Kreditkartennummern enthalten. Nutzer mit Zugriff auf dieses Tag haben auch Zugriff auf Spalten, die mit dem Richtlinien-Tag 2_Private oder 1_Sensitive gekennzeichnet sind.
• Ein 2_Private-Richtlinien-Tag für Spalten, die vertrauliche personenidentifizierbare Informationen enthalten, z. B. den Vornamen einer Person. Nutzer, die Zugriff auf dieses Tag haben, haben auch Zugriff auf Spalten, die mit dem Richtlinien-Tag 1_Sensitive gekennzeichnet sind. Nutzer haben keinen Zugriff auf Spalten, die mit dem Richtlinien-Tag 3_Confidential gekennzeichnet sind.
• Ein 1_Sensitive-Richtlinien-Tag für Spalten, die nicht zu veröffentlichende Daten enthalten, z. B. das Kreditlimit. Nutzer mit Zugriff auf dieses Tag haben keinen Zugriff auf Spalten, die mit dem Richtlinien-Tag 2_Private oder 3_Confidential gekennzeichnet sind.

Alles, was nicht gekennzeichnet ist, steht allen Nutzern zur Verfügung, die Zugriff auf das Data Warehouse haben.

Diese Zugriffssteuerungen sorgen dafür, dass die Daten selbst nach ihrer Re-Identifikation nicht gelesen werden können, bis dem Nutzer explizit Zugriff gewährt wird.

Hinweis: Sie können die Beispiele mit den Standarddefinitionen ausführen. Weitere Best Practices finden Sie unter Best Practices für die Verwendung von Richtlinien-Tags in BigQuery.

Dienstkonten mit eingeschränkten Rollen

Sie müssen den Zugriff auf das vertrauliche Datenprojekt beschränken, damit nur autorisierte Nutzer die vertraulichen Daten sehen können. Dazu erstellen Sie ein Dienstkonto mit der Rolle Dienstkontonutzer (roles/iam.serviceAccountUser), deren Identität autorisierte Nutzer annehmen müssen. Die Identitätsübertragung für Dienstkonten hilft Nutzern, Dienstkonten zu verwenden, ohne die Dienstkontoschlüssel herunterzuladen. Dadurch wird die allgemeine Sicherheit Ihres Projekts verbessert. Die Identitätsübertragung erstellt ein kurzfristiges Token, das autorisierte Nutzer mit der Rolle Ersteller von Dienstkonto-Tokens (roles/iam.serviceAccountTokenCreator) herunterladen können.

Schlüsselverwaltung und Verschlüsselung für Speicherung und Re-Identifikation

Sie verwalten separate CMEK-Schlüssel für Ihre vertraulichen Daten, damit Sie die Daten re-identifizieren können. Sie verwenden Cloud HSM zum Schutz Ihrer Schlüssel. Verwenden Sie die folgenden Schlüssel, um Ihre Daten zu re-identifizieren:

• Einen CMEK-Schlüssel, den die Dataflow-Pipeline für den Re-Identifikationsprozess verwendet.
• Den ursprünglichen kryptografischen Schlüssel, mit dem Sensitive Data Protection Ihre Daten de-identifiziert.
• Einen CMEK-Schlüssel für das BigQuery-Warehouse im Projekt mit vertraulichen Daten.

Wie bereits unter Schlüsselverwaltung und Verschlüsselung für die Aufnahme erwähnt, können Sie den CMEK-Standort und die Rotationszeiträume angeben. Sie können Cloud EKM verwenden, wenn es für Ihre Organisation erforderlich ist.

Vorgänge

Sie können Logging und Security Command Center-Features der Premium- oder Enterprise-Stufe wie Security Health Analytics und Bedrohungserkennung aktivieren. Mit diesen Steuerungen können Sie Folgendes tun:

• Überwachen, wer auf Ihre Daten zugreift.
• Sicherstellen, dass eine ordnungsgemäße Prüfung erfolgt.
• Ergebnisse für falsch konfigurierte Cloud-Ressourcen generieren
• Dem Vorfallsmanagement und den operativen Teams die Reaktion auf mögliche Probleme ermöglichen.

Access Transparency

Access Transparency bietet Ihnen Echtzeitbenachrichtigungen, wenn Google-Mitarbeiter Zugriff auf Ihre Daten benötigen. Access Transparency-Logs werden generiert, wenn ein Mensch auf Inhalte zugreift. Nur Google-Mitarbeiter mit gültigen geschäftlichen Begründungen (z. B. ein Supportfall) können Zugriff erhalten.

Logging

Damit Sie die Prüfungsanforderungen erfüllen und Informationen zu Ihren Projekten erhalten können, konfigurieren Sie Google Cloud Observability mit Datenlogs für Dienste, die Sie verfolgen möchten. Das centralized-logging-Modul in den Repositories konfiguriert die folgenden Best Practices:

• Zusammengefasste Logsenke für alle Projekte erstellen
• Logs in der entsprechenden Region speichern
• CMEKs der Logging-Senke hinzufügen

Ihre Logs müssen für alle Dienste in den Projekten Informationen zu Datenlese- und -schreibvorgängen sowie Informationen zu von Administratoren gelesenen Daten enthalten. Weitere Best Practices für das Logging finden Sie unter Erkennungskontrollen.

Benachrichtigungen und Monitoring

Nachdem Sie die Architektur bereitgestellt haben, können Sie Benachrichtigungen einrichten, um das Sicherheitscenter über mögliche Sicherheitsvorfälle zu informieren. Sie können beispielsweise Benachrichtigungen verwenden, um dem Sicherheitsanalysten mitzuteilen, wenn sich eine IAM-Berechtigung geändert hat. Weitere Informationen zum Konfigurieren von Security Command Center-Benachrichtigungen finden Sie unter Ergebnisbenachrichtigungen einrichten. Für zusätzliche Benachrichtigungen, die nicht vom Security Command Center veröffentlicht werden, können Sie Benachrichtigungen mit Cloud Monitoring einrichten.

Zusätzliche Sicherheitsaspekte

Zusätzlich zu den in diesem Dokument beschriebenen Sicherheitskontrollen sollten Sie die Sicherheit und die Risiken in Schlüsselbereichen, die sich mit Ihrer Verwendung dieser Lösung überschneiden, prüfen und verwalten. darunter:

• Die Sicherheit des Codes, mit dem Sie Dataflow-Jobs und Cloud Run-Funktionen konfigurieren, bereitstellen und ausführen.
• Die Datenklassifizierungstaxonomie, die Sie mit dieser Lösung verwenden.
• Das Erzeugen und Verwalten von Verschlüsselungsschlüsseln.
• Inhalt, Qualität und Sicherheit der Datasets, die Sie im Data Warehouse speichern und analysieren.
• Die gesamte Umgebung, in der Sie die Lösung bereitstellen, einschließlich Folgendem:
  • Design, Segmentierung und Sicherheit der Netzwerke, die Sie mit dieser Lösung verbinden.
  • Sicherheit und Governance der IAM-Steuerungen Ihrer Organisation.
  • Authentifizierungs- und Autorisierungseinstellungen für die Akteure, denen Sie Zugriff auf die Infrastruktur gewähren, die Teil dieser Lösung ist, und die Zugriff auf die Daten haben, die in dieser Infrastruktur gespeichert und verwaltet werden.

Zusammenfassung

So implementieren Sie die in diesem Dokument beschriebene Architektur:

1. Prüfen Sie, ob Sie die Architektur zusammen mit dem Unternehmensgrundlagen-Blueprint oder für sich allein bereitstellen möchten. Wenn Sie den Blueprint zu Unternehmensgrundlagen nicht bereitstellen möchten, muss Ihre Umgebung eine ähnliche Sicherheits-Baseline haben.
2. Wenn Sie Daten aus externen Quellen importieren möchten, richten Sie eine Dedicated Interconnect-Verbindung mit Ihrem Netzwerk ein.
3. Lesen Sie die terraform-google-secured-data-warehouse README oder die terraform-google-secured-data-warehouse-onprem-ingest README und achten Sie darauf, dass Sie alle Voraussetzungen erfüllen.

4. Prüfen Sie, ob Ihre Nutzeridentität die Rollen Nutzer des Dienstkontos (roles/iam.serviceAccountUser) und Ersteller von Dienstkonto-Tokens (roles/iam.serviceAccountTokenCreator) für den Entwicklungsordner Ihrer Organisation hat, wie unter Organisationsstruktur beschrieben. Wenn Sie keinen Ordner für Tests haben, erstellen Sie einen Ordner und konfigurieren Sie den Zugriff auf diesen.

5. Notieren Sie sich die Rechnungskonto-ID, den Anzeigenamen der Organisation, die Ordner-ID für Ihren Test- oder Demoordner und die E-Mail-Adressen für die folgenden Nutzergruppen:

   • Datenanalysten
   • Betrachter verschlüsselter Daten
   • Klartextlesegerät
   • Data Engineers
   • Netzwerkadministratoren
   • Sicherheitsadministratoren
   • Sicherheitsanalysten

6. Erstellen Sie die Projekte. Eine Liste der APIs, die Sie aktivieren müssen, finden Sie in der README-Datei.

7. Erstellen Sie das Dienstkonto für Terraform und weisen Sie allen Projekten die entsprechenden Rollen zu.

8. Richten Sie die Zugriffssteuerungsrichtlinie ein.

9. Bei Google Cloud Datenquellen, die das Repository terraform-google-secured-data-warehouse verwenden, können Sie in Ihrer Testumgebung die Anleitung bereitstellen, um die Lösung in Aktion zu sehen. Berücksichtigen Sie im Rahmen des Testverfahrens Folgendes:

   1. Fügen Sie Ihre eigenen Beispieldaten zum BigQuery-Warehouse hinzu.
   2. Arbeiten Sie mit einem Datenanalysten in Ihrem Unternehmen zusammen, um seinen Zugriff auf die vertraulichen Daten zu testen und zu prüfen, ob er wie erwartet mit den Daten aus BigQuery interagieren kann.

10. Für externe Datenquellen, die das terraform-google-secured-data-warehouse-onprem-ingest-Repository verwenden, implementieren Sie die Lösung in Ihrer Testumgebung:

    1. Klonen und führen Sie die Terraform-Scripts aus, um eine Umgebung inGoogle Cloudeinzurichten.

    2. Installieren Sie die Tink-Verschlüsselungsbibliothek in Ihrem Netzwerk.

    3. Richten Sie Standardanmeldedaten für Anwendungen ein, damit Sie die Tink-Bibliothek in Ihrem Netzwerk ausführen können.

    4. Erstellen Sie Verschlüsselungsschlüssel mit Cloud KMS.

    5. Verschlüsselte Schlüsselsätze mit Tink generieren

    6. Verschlüsseln Sie Daten mit Tink mit einer der folgenden Methoden:

       • Deterministische Verschlüsselung.
       • Hilfsskript mit Beispieldaten.

    7. Sie können verschlüsselte Daten per Streaming oder Batch-Upload in BigQuery hochladen.

11. Prüfen Sie bei externen Datenquellen, ob autorisierte Nutzer mithilfe der BigQuery-Entschlüsselungsfunktion für AEAD unverschlüsselte Daten aus BigQuery lesen können. Führen Sie beispielsweise folgende Funktion zum Erstellen einer Entschlüsselung aus:

    Führen Sie die Abfrage zum Erstellen der Ansicht aus:

    CREATE OR REPLACE VIEW `{project_id}.{bigquery_dataset}.decryption_view` AS
    
    SELECT
     Card_Type_Code,
     Issuing_Bank,
     Card_Number,
     `bigquery_dataset.decrypt`(Card_Number) AS Card_Number_Decrypted
    FROM `project_id.dataset.table_name`
    

    Führen Sie die Auswahlabfrage aus der Ansicht aus:

    SELECT
      Card_Type_Code,
      Issuing_Bank,
      Card_Number,
      Card_Number_Decrypted
    FROM
    `{project_id}.{bigquery_dataset}.decrypted_view`
    

    Weitere Abfragen und Anwendungsfälle finden Sie unter Verschlüsselung auf Spaltenebene mit Cloud KMS.

12. Verwenden Sie Security Command Center, um die neu erstellten Projekte gemäß Ihren Compliance-Anforderungen zu scannen.

13. Stellen Sie die Architektur in Ihrer Produktionsumgebung bereit.

Nächste Schritte

• Lesen Sie den Blueprint zu Unternehmensgrundlagen für eine sichere Referenzumgebung.
• Details zur Architektur finden Sie in der Terraform-Konfigurations-README für interne Datenquellen (terraform-google-secured-data-warehouse-Repository) oder in der Terraform-Konfigurations-README für externe Datenquellen (terraform-google-secured-data-warehouse-onprem-ingest-Repository).