Daten in ein gesichertes BigQuery-Data Warehouse importieren

Last reviewed 2025-06-15 UTC

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, der aus folgenden Elementen besteht:

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, einschließlich der folgenden:

    • De-Identifikation von Daten

    • unterschiedliche 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:

Ü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:

  • Wenn Sie Daten aus externen Datenquellen importieren, verschlüsseln Sie die 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 als interne Datenquellen bezeichnet), richten Sie Vorlagen ein, um vertrauliche Daten zu finden und zu de-identifizieren.
  • Geeignete Sicherheitskontrollen und Logging einrichten, um vertrauliche Daten zu schützen
  • Datenklassifizierung, Richtlinien-Tags, dynamische Datenmaskierung und Verschlüsselung auf Spaltenebene verwenden, 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 mit dem terraform-google-secured-data-warehouse-Repository importieren. Außerdem erfahren Sie, wie Sie vertrauliche Daten bei Bedarf zur Analyse re-identifizieren.

Architektur des Data Warehouse für vertrauliche Daten für interne Quellen

Architektur beim Importieren von Daten aus externen Quellen

Das folgende Bild zeigt, wie Daten aufgenommen und gespeichert werden, wenn Sie Daten aus einer lokalen Umgebung oder einer anderen Cloud in ein BigQuery-Warehouse mit dem terraform-google-secured-data-warehouse-onprem-ingest-Repository importieren.

Architektur des Data Warehouse für sensible Daten für externe Netzwerke

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 umschlossenen Verschlüsselungsschlüssel in separaten Tabellen.

BigQuery verwendet verschiedene Sicherheitskontrollen zum Schutz von Inhalten, darunter 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. Beim Importieren von Daten aus einer externen Quelle verwenden Sie Cloud HSM, um den Verschlüsselungsschlüssel zu generieren, 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 durch 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.

Data Profiler 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 für interne und externe Quellen. Es gibt jedoch unterschiedliche Pipelines.

Dataflow-Pipelines importieren Daten so:

  • Beim Importieren von Daten aus Google Cloudwerden vertrauliche Daten durch zwei Dataflow-Pipelines de-identifiziert und re-identifiziert. In der ersten Pipeline werden vertrauliche Daten mithilfe von Pseudonymisierung anonymisiert. 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 Resource Manager

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 für interne und 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 mit Sensitive Data Protection während der Aufnahme 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 scannt der Schutz sensibler Daten Daten, die in BigQuery gespeichert sind, um sensible Daten zu finden, die nicht geschützt sind. Weitere Informationen finden Sie unter Schutz sensibler Daten zum Scannen von BigQuery-Daten verwenden.

VPC Service Controls

Gilt für interne und externe Quellen, es gibt jedoch unterschiedliche Perimeter.

VPC Service Controls erstellt Sicherheitsperimeter, die Dienste und Ressourcen isolieren, indem sie Autorisierung, Zugriffssteuerung und sicheren Datenaustausch einrichten. 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 vertraulicher Datenperimeter die vertraulichen Daten re-identifizieren und in einem eingeschränkten Bereich speichern.
  • Beim Importieren externer Daten wird durch einen Datenperimeter die Verschlüsselung von anderen Arbeitslasten isoliert.
  • In einem Governance-Perimeter werden die Verschlüsselungsschlüssel gespeichert und es wird definiert, 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 mit dem terraform-google-secured-data-warehouse-Repository.

Ressourcenhierarchie für ein Data Warehouse für vertrauliche Daten für interne Quellen.

Organisationsstruktur beim Importieren von Daten aus externen Quellen

Das folgende Diagramm zeigt die Organisationsstruktur beim Importieren von Daten aus einer externen Quelle mit dem terraform-google-secured-data-warehouse-onprem-ingest-Repository.

Ressourcenhierarchie für ein Data Warehouse für vertrauliche Daten für externe Quellen.

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 „Production“ das Projekt für die Datenaufnahme und datenbezogene Projekte.

Nicht-Produktion

Enthält Projekte mit Cloud-Ressourcen, die derzeit getestet und zur Veröffentlichung bereitgestellt werden. In dieser Architektur enthält der Ordner „Non-production“ das Projekt für die Datenaufnahme und datenbezogene Projekte.

Entwicklung

Enthält Projekte mit Cloud-Ressourcen, die derzeit entwickelt werden. In dieser Architektur enthält der Ordner „Development“ das Projekt für die Datenerfassung und 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 Architektur-Empfehlungen 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 terraform-google-secured-data-warehouse-onprem-ingest-Repository kann diese Gruppe in das Data Warehouse geladene Daten aufrufen 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

Zusätzliche Rolle für Datenanalysten, die Zugriff auf vertrauliche Daten benötigen:

Vertrauliche Daten

Nicht vertrauliche Daten

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

Umfang der Aufgabe Rollen

Projekt zur Datenaufnahme

Datenprojekt

Ebene der Datenrichtlinie

Maskierter Leser (roles/bigquerydatapolicy.maskedReader)

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

Die Gruppe der Betrachter verschlüsselter Daten im terraform-google-secured-data-warehouse-onprem-ingest-Repository 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 sehen.

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

Gruppe: Klartext-Leser (nur externe Quellen)

Die Gruppe „Klartext-Leser“ im terraform-google-secured-data-warehouse-onprem-ingest-Repository 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:

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 werden die Rollen der Gruppe in verschiedenen Projekten für das terraform-google-secured-data-warehouse-Repository beschrieben.

Punktzahl der Aufgabe Rollen

Projekt zur Datenaufnahme

Projekt mit vertraulichen Daten

Projekt mit nicht vertraulichen Daten

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

Umfang der Aufgabe Rollen

Projekt zur Datenaufnahme

Datenprojekt

Gruppe der Netzwerkadministratoren

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

Netzwerkadministratoren benötigen auf Organisationsebene die folgenden Rollen:

Gruppe der Netzwerkadministratoren

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

Sicherheitsadministratoren benötigen die folgenden Rollen auf Organisationsebene:

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:

Beispiele für Gruppenzugriff-Abläufe für externe Quellen

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

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.

Der Ablauf für die Gruppe "Ansicht verschlüsselter Daten".

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. BigQuery überprüft den Zugriff so:

    • Der Nutzer wird mit gültigen, nicht abgelaufenen Google Cloud-Anmeldedaten authentifiziert.
    • Nutzeridentität und IP-Adresse der Anfrage sind Teil der Zulassungsliste in der Zugriffsebene oder 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.

Der Ablauf für die Gruppe „Klartext-Leser“.

So greifen Sie auf Daten in BigQuery zu:

  1. Klartext-Leser führen 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 überprüft:

    • 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. Der Nutzer erhält Zugriff auf die Klartextdaten in den Spalten mit sensiblen Daten.

Häufige Sicherheitskontrollen

In den folgenden Abschnitten werden die Kontrollen 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 Zugriffsebenen 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:

  • Damit wird Ihre Netzwerkangriffsfläche reduziert, indem der privater Google-Zugriff verwendet wird, 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 entsprechenden 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 terraform-google-secured-data-warehouse-Repository 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 terraform-google-secured-data-warehouse-onprem-ingest-Repository 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 Sensitive Data Protection BigQuery nach ungeschützten vertraulichen Daten durchsuchen 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 ausführen kann. 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 im data-ingestion-Modul und im confidential-data-Modul in jeder Architektur definiert.

Für das terraform-google-secured-data-warehouse-Repository sind die Dienstkonten wie folgt:

  • 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

Dataflow-Controller

Dieses Konto wird zur Re-Identifikation verwendet.

sa-dataflow-controller-reid

Vertrauliche Daten

Cloud Storage

sa-storage-writer

Datenaufnahme

Pub/Sub

sa-pubsub-writer

Datenaufnahme

Cloud Scheduler

sa-scheduler-controller

Datenaufnahme

Für das terraform-google-secured-data-warehouse-onprem-ingest-Repository sind die Dienstkonten wie folgt:

  • Das Cloud Storage-Dienstkonto führt den automatisierten Batchdaten-Upload in den Ingestion-Speicher-Bucket aus.
  • Mit dem 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 zu transformieren und in BigQuery zu schreiben.
  • Das Dienstkonto für Cloud Run-Funktionen schreibt nachfolgende Batchdaten, die aus Cloud Storage hochgeladen wurden, in BigQuery.
  • Das Dienstkonto für den Storage-Upload ermöglicht der ETL-Pipeline, Objekte zu 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

Projekt zur Datenaufnahme

Datenprojekt

Data Governance

Cloud Run-Funktionen-Dienstkonto

Projekt zur Datenaufnahme

Datenprojekt

Storage Upload-Dienstkonto

Projekt zur Datenaufnahme

Pub/Sub-Schreibdienstkonto

Projekt zur Datenaufnahme

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

OS Login für VMs aktivieren, die im Projekt erstellt wurden

compute.requireOsLogin

true

Neue Weiterleitungsregeln auf Basis der IP-Adresse als intern festlegen.

compute.restrictProtocolForwardingCreationForTypes

INTERNAL

Gruppe freigegebene VPC-Subnetzwerke definieren, 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.

Logging der Ausgabe des seriellen Ports für Cloud Logging deaktivieren.

compute.disableSerialPortLogging

true

CMEK-Schutz erforderlich (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 eingehenden 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 Kontrollen beschrieben, die für die Aufnahme von Daten 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. Diese Unternehmensarchitektur empfiehlt Dedicated Interconnect, 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 Tink-Verschlüsselungsbibliothek oder andere Verschlüsselungsbibliotheken verwenden. Die Tink-Verschlüsselungsbibliothek ist mit der BigQuery-AEAD-Verschlüsselung kompatibel, die in der Architektur verwendet wird, um auf Spaltenebene verschlüsselte Daten nach dem Import zu entschlüsseln.

In der Tink-Verschlüsselungsbibliothek werden DEKs verwendet, die Sie lokal oder in 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üsselungsschlüsselsatz, der sicher in Cloud HSM gespeichert und mit IAM-Rollen und -Berechtigungen verwaltet wird.

Während der Aufnahme werden sowohl der zusammengefasste DEK als auch die Daten in BigQuery gespeichert. BigQuery enthält zwei Tabellen: eine für die Daten und die andere für den umschlossenen DEK. Wenn Analysten vertrauliche Daten ansehen 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 schützt die clientseitige Verschlüsselung mit Tink Ihre Daten zusätzlich, indem 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.
  • Den von Cloud HSM verpackten kryptografischen 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 das Freigeben und Anwenden von Richtlinien für den Datenzugriff in großem Maßstab zu erleichtern, 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 erstellt 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 zu verbergen.

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 auf einer detaillierteren Ebene 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.

Data Profiler für BigQuery mit Schutz sensibler Daten

Mit dem Data Profiler können Sie Speicherorte sensibler und riskanter Daten in BigQuery-Tabellen identifizieren. Der 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 Vertraulichkeitsstufen 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 Aufnahme von Daten 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. 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 CMEKs, einen für das BigQuery-Warehouse im nicht vertraulichen Datenprojekt und einen 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. Bei der Identitätsübernahme wird ein kurzfristiges Token erstellt, das autorisierte Nutzer mit der Rolle Ersteller von Dienstkonto-Tokens (roles/iam.serviceAccountTokenCreator) herunterladen dürfen.

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

Sie verwalten separate CMEKs 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, 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 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 Event Threat Detection 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:

  • Aggregierte 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 Ihr 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, den Sie zum Konfigurieren, Bereitstellen und Ausführen von Dataflow-Jobs und Cloud Run-Funktionen verwenden.
  • 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-warehouseREADME oder terraform-google-secured-data-warehouse-onprem-ingestREADME und achten Sie darauf, dass Sie alle Voraussetzungen erfüllen.

  4. Prüfen Sie, ob Ihre Nutzeridentität die Rollen Dienstkontonutzer (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 darauf.

  5. Notieren Sie sich die ID Ihres Rechnungskontos, den Anzeigenamen Ihrer 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
    • Klartext-Leser
    • 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 ihm die entsprechenden Rollen für alle Projekte zu.

  8. Richten Sie die Zugriffssteuerungsrichtlinie ein.

  9. Für Google Cloud Datenquellen, die das terraform-google-secured-data-warehouse-Repository verwenden, stellen Sie in Ihrer Testumgebung die Schritt-für-Schritt-Anleitung bereit, um die Lösung in Aktion zu sehen. Erwägen 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. Bei externen Datenquellen, die das terraform-google-secured-data-warehouse-onprem-ingest-Repository verwenden, müssen Sie die Lösung in Ihrer Testumgebung so bereitstellen:

    1. Klonen Sie die Terraform-Skripts und führen Sie sie 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. Verschlüsselungsschlüssel mit Cloud KMS erstellen.

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

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

    7. Verschlüsselte Daten per Streaming oder Batch-Upload in BigQuery hochladen

  11. Prüfen Sie bei externen Datenquellen, ob autorisierte Nutzer unverschlüsselte Daten aus BigQuery mit der BigQuery AEAD-Entschlüsselungsfunktion 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 SELECT-Abfrage 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