Daten aus Google Cloud in ein gesichertes BigQuery-Data Warehouse importieren

Last reviewed 2021-12-16 UTC

Viele Organisationen stellen Data Warehouses bereit, in denen vertrauliche Informationen 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 Sicherheits-Blueprints, das aus folgenden Elementen besteht:

  • Einem GitHub-Repository, das eine Reihe von Terraform-Konfigurationen und -Skripts enthält. 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, die Sie mit diesem Blueprint implementieren (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 für die Data Governance beim Erstellen, Bereitstellen und Ausführen eines Data Warehouse in Google Cloud, einschließlich der De-Identifikation von Daten, differenzieller Verarbeitung vertraulicher Daten und Zugriffssteuerung auf Spaltenebene.

In diesem Dokument wird davon ausgegangen, dass Sie bereits einen grundlegenden Satz von Sicherheitskontrollen konfiguriert haben, wie unter Blueprint für Google Cloud-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:

  • Steuerungen konfigurieren, die den Zugriff auf vertrauliche Daten sichern
  • Steuerungen zum Schutz der Datenpipeline konfigurieren
  • Geeignete Aufgabentrennung für verschiedene Identitäten konfigurieren
  • Vorlagen einrichten, um vertrauliche Daten zu finden und zu de-identifizieren
  • geeignete Sicherheitskontrollen und Logging einrichten, um vertrauliche Daten zu schützen
  • Datenklassifizierung und Richtlinien-Tags verwenden, um den Zugriff auf bestimmte Spalten im Data Warehouse zu beschränken

Architektur

Zum Erstellen eines vertraulichen Data Warehouse müssen Sie Daten als vertraulich und nicht vertraulich kategorisieren und dann die Daten in separaten Perimetern speichern. Die folgende Abbildung zeigt, wie aufgenommene Daten kategorisiert, de-identifiziert und gespeichert werden. Außerdem erfahren Sie, wie Sie vertrauliche Daten bei Bedarf zur Analyse re-identifizieren.

Architektur des vertraulichen Data Warehouse

Die Architektur verwendet eine Kombination der folgenden Google Cloud-Dienste und -Features:

  • Die 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.

  • VPC Service Controls erstellt Sicherheitsperimeter, die Dienste und Ressourcen isolieren, indem es Autorisierung, Zugriffssteuerung und sicheren Datenaustausch einrichtet. Die Perimeter sind folgende:

    • Ein Datenaufnahmeperimeter, der eingehende Daten (als Batch oder Stream) akzeptiert und de-identifiziert. Eine separate Landing Zone trägt zum Schutz der übrigen Arbeitslasten vor eingehenden Daten bei.

    • Ein vertraulicher Datenperimeter, der die vertraulichen Daten re-identifizieren und in einem eingeschränkten Bereich speichern kann.

    • 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.

  • Cloud Storage und Pub/Sub empfangen Daten so:

  • Durch zwei Dataflow-Pipelines werden vertrauliche Daten so 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.

    Zum Schutz der Daten verwendet Dataflow für jede Pipeline ein spezielles Dienstkonto und einen speziellen Verschlüsselungsschlüssel sowie Zugriffssteuerungen. Um die Ausführung von Pipelines zu sichern, verschiebt Dataflow sie mit Streaming Engine zum Backend-Dienst. Weitere Informationen finden Sie unter Sicherheit und Berechtigungen in Dataflow.

  • Mit Vertraulicher Datenschutz werden vertrauliche Daten während der Aufnahme de-identifiziert.

    Mit Sensitive Data Protection werden strukturierte und unstrukturierte Daten anhand der erkannten infoTypes oder Datensätze de-identifiziert.

  • Cloud HSM hostet den Schlüsselverschlüsselungsschlüssel (KEK). Cloud HSM ist ein cloudbasierter HSM-Dienst (Hardware Security Module).

  • Data Catalog kategorisiert während der Aufnahme automatisch vertrauliche Daten mit Metadaten. Diese werden auch als Richtlinien-Tags bezeichnet. Data Catalog verwendet auch Metadaten, um den Zugriff auf vertrauliche Daten zu verwalten. Weitere Informationen finden Sie in der Data Catalog-Übersicht. Zur Kontrolle des Zugriffs auf Daten im Data Warehouse wenden Sie Richtlinien-Tags auf Spalten an, die vertrauliche Daten enthalten.

  • BigQuery speichert die vertraulichen Daten im Perimeter für vertrauliche Daten.

    BigQuery verwendet verschiedene Sicherheitskontrollen zum Schutz von Inhalten, einschließlich Zugriffssteuerungen, Sicherheit auf Spaltenebene für vertrauliche Daten und Datenverschlüsselung.

  • Security Command Center überwacht und prüft Sicherheitsergebnisse aus Ihrer Google Cloud-Umgebung an einem zentralen Ort.

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.

Das folgende Diagramm zeigt eine Ressourcenhierarchie mit Ordnern, die verschiedene Umgebungen darstellen, z. B. „Bootstrap“, „Common“, „Production“, „Non-Production“ (oder „Staging“) und „Development“. Sie stellen die meisten Projekte im Blueprint im Production-Ordner und das Data Governance-Projekt im Common-Ordner bereit, der für die Governance verwendet wird.

Ressourcenhierarchie für ein vertrauliches Data Warehouse

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 diesem Blueprint verwendet werden

Ordner Beschreibung
Prod Enthält Projekte mit Cloud-Ressourcen, die getestet wurden und einsatzbereit sind.
Verbreitet Enthält zentralisierte Dienste für die Organisation, z. B. das Governance-Projekt.

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 Google Cloud-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 Enthält Dienste, die zum Empfangen von Daten und zum De-Identifizieren vertraulicher Daten erforderlich sind.
Governance Enthält Dienste, die Funktionen für Schlüsselverwaltung, Logging und Datenkatalogisierung bereitstellen.
Nicht vertrauliche Daten Enthält Dienste, die zum Speichern von de-identifizierten Daten erforderlich sind.
Vertrauliche Daten Enthält Dienste, die zum Speichern und Re-Identifizieren vertraulicher 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 Blueprint-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. Für diese Gruppe sind Rollen in verschiedenen Projekten erforderlich, wie in der folgenden Tabelle beschrieben.

Projektzuordnung Rollen
Datenaufnahme

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

Vertrauliche Daten
  • roles/bigquery.dataViewer
  • roles/bigquery.jobUser
  • roles/bigquery.user
  • roles/dataflow.viewer
  • roles/dataflow.developer
  • roles/logging.viewer
Nicht vertrauliche Daten
  • roles/bigquery.dataViewer
  • roles/bigquery.jobUser
  • roles/bigquery.user
  • roles/logging.viewer

Gruppe der Data Engineers

Data Engineers richten die Datenpipeline und das Warehouse ein. Für diese Gruppe sind Rollen in verschiedenen Projekten erforderlich, wie in der folgenden Tabelle beschrieben.

Projektzuordnung Rollen
Datenaufnahme
Vertrauliche Daten
  • roles/bigquery.dataEditor
  • roles/bigquery.jobUser
  • roles/cloudbuild.builds.editor
  • roles/cloudkms.viewer
  • roles/compute.networkUser
  • roles/dataflow.admin
  • roles/logging.viewer
Nicht vertrauliche Daten
  • roles/bigquery.dataEditor
  • roles/bigquery.jobUser
  • roles/cloudkms.viewer
  • 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:

Gruppe der Sicherheitsadministratoren

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:

Informationen zu den nötigen Sicherheitseinstellungen

In diesem Abschnitt werden die Sicherheitskontrollen in Google Cloud erläutert, mit denen Sie Ihr Data Warehouse schützen können. Dies sind die wichtigsten Sicherheitsgrundsätze, die zu berücksichtigen sind:

  • Sichern Sie den Zugriff durch Prinzip der geringsten Berechtigung.

  • Sichern Sie die Netzwerkverbindungen durch Segmentierungsdesign und -richtlinien.

  • Sichern Sie die Konfiguration für jeden Dienst.

  • Klassifizieren und schützen Sie Daten gemäß ihres Risikoniveaus.

  • Beachten Sie die Sicherheitsanforderungen für die Umgebung, in der das Data Warehouse gehostet wird.

  • Konfigurieren Sie ein ausreichendes Monitoring und Logging für Erkennung, Untersuchung und Reaktion.

Sicherheitskontrollen für die Datenaufnahme

Zum Erstellen Ihres Data Warehouse müssen Sie Daten aus einer anderen Google Cloud-Quelle übertragen (z. B. einem Data Lake). 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 Firewallregeln, Zugriffsrichtlinien und Verschlüsselung verwenden.

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 private 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.

Sie müssen 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 Datei im dwh-networking-Modul-Repository definiert. Weitere Informationen finden Sie unter Internetzugriff und Firewallregeln konfigurieren.

Wenn Sie verhindern möchten, dass Ressourcen externe IP-Adressen verwenden, wird die compute.vmExternalIpAccess-Organisationsrichtlinie auf „Alle ablehnen“ gesetzt.

Perimetersteuerungen

Wie im Architekturdiagramm dargestellt, platzieren Sie die Ressourcen für das vertrauliche 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 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.

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.

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

Beide Aufnahmeoptionen verwenden Cloud HSM zum Verwalten des CMEK. 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. Der Aufnahmeprozess wird manchmal als ETL-Prozess (Extrahieren, Transformieren, Laden) bezeichnet.

  • 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 Cloud verwalten, 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.

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 definiert. Es 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

Dataflow-Controller

Dieses Konto wird zur Re-Identifikation verwendet.

sa-dataflow-controller-reid Vertrauliche Daten
Cloud Storage sa-storage-writer Datenaufnahme
  • roles/storage.objectViewer
  • roles/storage.objectCreator
Beschreibungen dieser Rollen finden Sie unter IAM-Rollen für Cloud Storage.
Pub/Sub sa-pubsub-writer Datenaufnahme
  • roles/pubsub.publisher
  • roles/pubsub.subscriber
Beschreibungen dieser Rollen finden Sie unter IAM-Rollen für Pub/Sub.
Cloud Scheduler sa-scheduler-controller Datenaufnahme
  • roles/compute.viewer
  • roles/dataflow.developer

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.

Sicherheitskontrollen für die Datenspeicherung

Sie konfigurieren die folgenden Sicherheitskontrollen, um Daten im BigQuery-Warehouse zu schützen:

  • Zugriffssteuerung auf Spaltenebene

  • Dienstkonten mit eingeschränkten Rollen

  • Organisationsrichtlinien

  • VPC Service Controls-Perimeter zwischen dem vertraulichen Projekt und dem nicht vertraulichen Projekt mit entsprechenden Perimeter-Bridges

  • Verschlüsselung und Schlüsselverwaltung

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.

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 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 roles/iam.serviceAccountTokenCreator herunterladen können.

Organisationsrichtlinien

Dieser Blueprint 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 definiert sind:

Richtlinie Name der Einschränkung Empfohlener Wert
Ressourcenbereitstellungen auf bestimmte physische Standorte beschränken. Weitere Werte finden Sie unter Wertgruppen. gcp.resourceLocations
Einer der folgenden:
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. Weitere Informationen finden Sie unter OS Login in einer Organisation verwalten und unter OS Login. compute.requireOsLogin true
Neue Weiterleitungsregeln auf Basis der IP-Adresse als intern festlegen. compute.restrictProtocolForwardingCreationForTypes INTERNAL
Gruppe freigegebener VPC-Subnetzwerke definieren, die von Compute Engine-Ressourcen verwendet werden können. compute.restrictSharedVpcSubnetworks projects/PROJECT_ID/regions/REGION/s ubnetworks/SUBNETWORK-NAME.

Ersetzen Sie SUBNETWORK-NAME durch die Ressourcen-ID des privaten Subnetzes, das der Blueprint verwenden soll.
Logging der Ausgabe des seriellen Ports für Cloud Logging deaktivieren. compute.disableSerialPortLogging true

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 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.

Operative Steuerungen

Sie können Logging und Security Command Center-Features der Premium-Stufe wie Sicherheitsstatusanalysen 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.

  • Dem Vorfallsmanagement und den operativen Teams die Reaktion auf mögliche Probleme ermöglichen.

Access Transparency

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

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 konfiguriert die folgenden Best Practices:

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 den Blueprint bereitgestellt haben, können Sie Benachrichtigungen einrichten, um Ihr Sicherheitscenter zu informieren, dass ein Sicherheitsvorfall auftreten könnte. 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 von Security Command Center veröffentlicht werden, können Sie Benachrichtigungen mit Cloud Monitoring einrichten.

Zusätzliche Sicherheitsaspekte

Die Sicherheitskontrollen in diesem Blueprint wurden vom Google-Team für Internetsicherheit und von einem externen Sicherheitsteam geprüft. Wenn Sie im Rahmen einer Vertraulichkeitsvereinbarung Zugriff sowohl auf ein STRIDE-Bedrohungsmodell als auch auf den zusammenfassenden Bewertungsbericht anfordern möchten, senden Sie eine E-Mail an secured-dw-blueprint-support@google.com.

Zusätzlich zu den in dieser Lösung 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. Dazu gehört Folgendes:

  • Der Code, den Sie zum Konfigurieren, Bereitstellen und Ausführen von Dataflow-Jobs verwenden.

  • Die Datenklassifizierungstaxonomie, die Sie mit dieser Lösung verwenden.

  • 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, die 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 den Blueprint 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. Lesen Sie die Readme-Datei für den Blueprint und achten Sie darauf, dass Sie alle Voraussetzungen erfüllen.

  3. 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. Verwenden Sie Security Command Center, um die neu erstellten Projekte gemäß Ihren Compliance-Anforderungen zu scannen.

    2. Fügen Sie Ihre eigenen Beispieldaten zum BigQuery-Warehouse hinzu.

    3. 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.

  4. Stellen Sie den Blueprint in Ihrer Produktionsumgebung bereit.

Nächste Schritte