Daten aus einem externen Netzwerk in ein gesichertes BigQuery-Data Warehouse importieren

Last reviewed 2023-08-15 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. Es ist Teil eines Sicherheits-Blueprints, das Folgendes enthält:

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

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 in Google Cloud, einschließlich der Verschlüsselung auf Spaltenebene, der differenziellen Verarbeitung vertraulicher Daten und der 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 Daten enthält, die Sie als vertraulich betrachten, müssen Sie Maßnahmen ergreifen, um die Sicherheit, Vertraulichkeit, Integrität und Verfügbarkeit der Geschäftsdaten zu erhalten, während diese importiert und gespeichert, übertragen oder analysiert werden. In diesem Blueprint tun Sie Folgendes:

  • Verschlüsselung von Quelldaten außerhalb von Google Cloud (z. B. in einer lokalen Umgebung) und deren Import in BigQuery.
  • Steuerungen konfigurieren, die den Zugriff auf vertrauliche Daten sichern
  • Steuerungen zum Schutz der Datenpipeline konfigurieren
  • Geeignete Aufgabentrennung für verschiedene Identitäten konfigurieren
  • 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. Die folgende Abbildung zeigt, wie Daten aufgenommen und gespeichert werden.

Architektur des gesicherten Data Warehouse für externe Netzwerke

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

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

  • Die Identity and Access Management (IAM) und der 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 sie Autorisierung, Zugriffssteuerung und sicheren Datenaustausch einrichten. Die Perimeter sind folgende:

    • Ein Datenaufnahmeperimeter, der eingehende Daten (als Batch oder Stream) akzeptiert. Ein separater Perimeter trägt zum Schutz der übrigen Arbeitslasten vor eingehenden Daten bei.
    • Ein Datenperimeter, der die Verschlüsselungsdaten 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.

  • Cloud Storage und Pub/Sub empfangen Daten so:

  • Cloud Run-Funktionen werden von Cloud Storage ausgelöst und schreibt die Daten, die Cloud Storage in den Aufnahme-Bucket in BigQuery hochlädt.

  • Eine Dataflow-Pipeline schreibt Streamingdaten in BigQuery. Zum Schutz der Daten verwendet Dataflow ein spezielles Dienstkonto und spezielle 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.

  • Cloud Data Loss Prevention (Cloud DLP) scannt Daten, die in BigQuery gespeichert sind, um sensible Daten zu finden, die nicht geschützt sind. Weitere Informationen finden Sie unter Cloud DLP zum Scannen von BigQuery-Daten verwenden.

  • Cloud HSM hostet den Schlüsselverschlüsselungsschlüssel (KEK). Cloud HSM ist ein cloudbasierter HSM-Dienst (Hardware Security Module). Sie verwenden Cloud HSM, um den Verschlüsselungsschlüssel zu generieren, mit dem Sie die Daten in Ihrem Netzwerk verschlüsseln, bevor Sie sie an Google Cloud senden.

  • Data Catalog kategorisiert vertrauliche Daten, die in BigQuery gefunden werden, automatisch mit Metadaten, die auch als Richtlinien-Tags bezeichnet werden. 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 verschlüsselten Daten und den verpackten Verschlüsselungsschlüssel in separaten Tabellen.

    BigQuery verwendet verschiedene Sicherheitskontrollen zum Schutz von Inhalten, darunter: Zugriffssteuerung ,Verschlüsselung auf Spaltenebene ,Sicherheit auf Spaltenebene und die Datenverschlüsselung.

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

  • Cloud Logging erfasst alle Logs aus Google Cloud-Diensten zum Speichern und Abrufen durch Ihre Analyse- und Prüftools.

  • Cloud Monitoring erfasst und speichert Leistungsinformationen und Messwerte zu Google Cloud-Diensten.

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

Organisationsstruktur

Sie gruppieren die Ressourcen Ihrer Organisation, damit Sie sie verwalten und Ihre Testumgebungen von der Produktionsumgebung trennen können. Mit dem 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“. Diese Hierarchie entspricht der Organisationsstruktur, die im Blueprint für Unternehmensgrundlagen verwendet wird. 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 gesichertes Data Warehouse für externe Netzwerke.

Informationen zu alternativen Ressourcenhierarchien finden Sie unter Ressourcenhierarchie für Ihre Google Cloud-Landing-Zone festlegen.

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
Bootstrap Enthält Ressourcen, die zum Bereitstellen des Unternehmensgrundlagen-Blueprints erforderlich sind.
Allgemein 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 diesem Blueprint enthält der Produktionsordner das Datenaufnahmeprojekt und das Datenprojekt.
Nicht-Produktion Enthält Projekte mit Cloud-Ressourcen, die derzeit getestet und zur Veröffentlichung bereitgestellt werden. In diesem Blueprint enthält der Nicht-Produktionsordner das Datenaufnahmeprojekt und das Datenprojekt.
Entwicklung Enthält Projekte mit Cloud-Ressourcen, die derzeit entwickelt werden. In diesem Blueprint enthält der Entwicklungsordner das Datenaufnahmeprojekt und das Datenprojekt.

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 und Schreiben von Daten in BigQuery erforderlich sind.
Data Governance Enthält Dienste, die Funktionen für Schlüsselverwaltung, Logging und Datenkatalogisierung bereitstellen.
Daten 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 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 sehen und analysieren die Daten im Warehouse. Diese Gruppe kann in das Data Warehouse geladene Daten aufrufen und dieselben Vorgänge wie die Verschlüsselte Datenbetrachtergruppe ausführen. Für diese Gruppe sind Rollen in verschiedenen Projekten erforderlich, wie in der folgenden Tabelle beschrieben.

Umfang der Aufgabe Rollen
Datenaufnahmeprojekt
Datenprojekt
Datenrichtlinienebene Maskierter Leser (roles/bigquerydatapolicy.maskedReader)

Gruppe der Betrachter verschlüsselter Daten

Die Gruppe der Betrachter verschlüsselter Daten kann verschlüsselte Daten aus BigQuery-Berichtstabellen, Cloud Looker Studio und anderen 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 im Datenprojekt die Rolle „BigQuery-Nutzer“ (roles/bigquery.jobUser) erforderlich. Diese Gruppe benötigt auch den "Maskierter Leser" (roles/bigquerydatapolicy.maskedReader) auf Datenrichtlinienebene.

Gruppe: Klartext-Leser

Die Klartext-Lesegruppe 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 Rollen im Datenprojekt erforderlich, wie in folgender Tabelle beschrieben.

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 Data Catalog-Ebene erforderlich.

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.

Umfang der Aufgabe Rollen
Datenaufnahmeprojekt
Datenprojekt
  • BigQuery-Dateneditor (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 Security Command Center.

Sicherheitsadministratoren benötigen die folgenden Rollen auf Organisationsebene:

Gruppe der Sicherheitsanalysten

Sicherheitsanalysten überwachen und reagieren auf Sicherheitsvorfälle und Cloud DLP-Ergebnisse.

Sicherheitsanalysten benötigen auf Organisationsebene die folgenden Rollen:

Beispiele für Gruppenzugriff-Abläufe

In folgenden Abschnitten werden Zugriffsabläufe für zwei Gruppen innerhalb der gesicherten Data Warehouse-Lösung beschrieben.

Zugriffsablauf für die Gruppe „Betrachter 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 prü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 Regel "Zugriffsebene/Ingress" 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 verifiziert:

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

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

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

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 Quelle in Ihrer lokalen Umgebung, einer anderen Cloud oder einer anderen Google Cloud-Quelle übertragen. In diesem Dokument geht es um die Übertragung von Daten aus Ihrer lokalen Umgebung oder einer anderen Cloud. Informationen zum Übertragen von Daten aus einer anderen Google Cloud-Quelle finden Sie unter Daten aus Google Cloud in ein gesichertes BigQuery-Data-Warehouse importieren.

Sie können eine der folgenden Optionen verwenden, um Ihre Daten in das Data Warehouse in BigQuery zu übertragen:

  • Ein Batchjob, der Daten in einen Cloud Storage-Bucket lädt.
  • Einen Streamingjob, der Pub/Sub verwendet.

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

Verschlüsselte Verbindung zu Google Cloud

Sie können Cloud VPN oder Cloud Interconnect verwenden, um Daten zu schützen, die zwischen Google Cloud und Ihrer Umgebung übertragen werden. Dieser Blueprint 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 Ihre Umgebung aus zulassen möchten, müssen Sie in den Richtlinienregeln für Zugriffsebenen zugelassene IP-Adressen definieren.

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 TCP-Port-443-Verbindungen von speziellen Domainnamen (restricted.googleapis.com). Die eingeschränkte Domain "restricted.googleapis.com" hat folgende Vorteile:

  • Damit wird Ihre Netzwerkangriffsfläche reduziert, da 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.

Für die Datenpipeline müssen Sie TCP-Ports in der Firewall öffnen, wie in der Datei dataflow_firewall.tf im Repository harness-projects-Modul 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 her:

  • Sie verbinden das Datenaufnahmeprojekt mit dem Datenprojekt, sodass Daten in BigQuery aufgenommen werden können.
  • Sie verbinden das Datenprojekt mit dem Data-Governance-Projekt, sodass Cloud DLP 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 durch Perimeter geschützten Ressourcen 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 aus Ihrer lokalen Umgebung festlegt und nur Anfragen von bestimmten Nutzern oder Dienstkonten zulässt. Weitere Informationen finden Sie unter Zugriffsebenenattribute.

Clientseitige Verschlüsselung

Bevor Sie sensible Daten in Google Cloud verschieben, 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, mit der der Blueprint 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üsselungsschlüsselsatz, der sicher in Cloud HSM gespeichert und mit IAM-Rollen und -Berechtigungen verwaltet wird.

Während der Aufnahme werden sowohl der verpackte DEK als auch die Daten in BigQuery gespeichert. BigQuery enthält zwei Tabellen: eine für die Daten und eine für den verpackten 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. Der Entwurf verwendet folgende 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 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 Modul „data-ingestion-sa“ und im Modul „data-governance-sa“ definiert.

Es sind folgende Dienstkonten vorhanden:

  • Das Cloud Storage-Dienstkonto führt den automatisierten Upload von Batch-Daten in den Aufnahmespeicher-Bucket aus.
  • Das Pub/Sub-Dienstkonto ermöglicht das Streamen von Daten an den Pub/Sub-Dienst.
  • Das Dataflow-Controller-Dienstkonto wird von der Dataflow-Pipeline verwendet, um Daten aus Pub/Sub in BigQuery zu transformieren und zu schreiben.
  • Das Dienstkonto für Cloud Run-Funktionen schreibt nachfolgende Batchdaten, die aus Cloud Storage in BigQuery hochgeladen wurden.
  • Das Storage Upload-Dienstkonto 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 Datenaufnahmeprojekt
Datenprojekt
Data Governance
Cloud Run-Funktionen-Dienstkonto Datenaufnahmeprojekt
  • BigQuery-Dateneditor (roles/bigquery.dataEditor)
  • BigQuery Metadata-Betrachter (roles/bigquery.metadataViewer)
 Datenprojekt
Storage Upload-Dienstkonto Datenaufnahmeprojekt
Pub/Sub-Schreibdienstkonto Datenaufnahmeprojekt

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
  • Dynamische Datenmaskierung sensibler Felder
  • Organisationsrichtlinien
  • Automatisches Scannen und Datenprofiler: Cloud DLP
  • VPC Service Controls-Perimeter zwischen dem Datenaufnahmeprojekt und dem Datenprojekt mit entsprechenden Perimeter-Bridges
  • Verschlüsselung und Schlüsselverwaltung:
    • Verschlüsselung inaktiver Daten mit in Cloud HSM gespeicherten CMEK-Schlüsseln
    • Verschlüsselung auf Spaltenebene mit Tink- und BigQuery-AEAD-Verschlüsselung

Dynamische Datenmaskierung

Um Daten in großem Maßstab freizugeben und Datenzugriffsrichtlinien 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 Cloud DLP

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

Dienstkonten mit eingeschränkten Rollen

Sie müssen den Zugriff auf das Datenprojekt beschränken, damit nur autorisierte Nutzer Felder mit sensiblen 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 Modul organization-policies definiert sind.

Richtlinie Name der Einschränkung Empfohlener Wert
Ressourcenbereitstellungen auf bestimmte physische Standorte beschränken gcp.resourceLocations Eines der folgenden Elemente:
in:us-locations
in:eu-locations
in:asia-locations
CMEK-Schutz erzwingen gcp.restrictNonCmekServices bigquery.googleapis.com
Erstellen von Dienstkonten deaktivieren. iam.disableServiceAccountCreation true
Erstellen von Dienstkontoschlüsseln deaktivieren disableServiceAccountKeyCreation true
OS Login für VMs aktivieren, die im Projekt erstellt wurden compute.requireOsLogin true
Standarddienstberechtigungen für Standarddienstkonten deaktivieren automaticIamGrantsForDefaultServiceAccounts true
Erlaubte Einstellungen für ausgehenden Traffic (Cloud Run-Funktionen) cloudfunctions.allowedIngressSettings ALLOW_INTERNAL_AND_GCLB
Neue Weiterleitungsregeln auf Basis der IP-Adresse als intern festlegen. compute.restrictProtocolForwardingCreationForTypes INTERNAL
Logging der Ausgabe des seriellen Ports für Cloud Logging deaktivieren compute.disableSerialPortLogging true
Gruppe freigegebener VPC-Subnetzwerke definieren, die von Compute Engine-Ressourcen verwendet werden können compute.restrictSharedVpcSubnetworks projects/PROJECT_ID/regions/REGION/subnetworks/SUBNETWORK-NAME

Ersetzen Sie SUBNETWORK-NAME durch die Ressourcen-ID des privaten Subnetzes, das der Blueprint verwenden soll.

Operative Steuerungen

Sie können Logging und Security Command Center-Features der Premium-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-Supportmitarbeiter 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. 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 Harness-Logging-Modul konfiguriert folgende 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 im Blueprint für Unternehmensgrundlagen.

Benachrichtigungen und Monitoring

Nachdem Sie den Blueprint 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 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. Zu diesen Sicherheitsüberlegungen gehören:

  • 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 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. Richten Sie eine Dedicated Interconnect-Verbindung zu Ihrem Netzwerk ein.
  3. Lesen Sie die README für den Blueprint und achten Sie darauf, dass Sie alle Voraussetzungen erfüllen.
  4. Prüfen Sie, ob Ihre Nutzeridentität die Rollen iam.serviceAccountUser und 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 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
    • Klartextleser
    • Data Engineers
    • Netzwerkadministratoren
    • Sicherheitsadministratoren
    • Sicherheitsanalysten
  6. Erstellen Sie die Projekte für Daten, Data Governance-, Datenaufnahme und Flex-Vorlagen. 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 die entsprechenden Rollen für alle Projekte zu.
  8. Richten Sie die Zugriffssteuerungsrichtlinie ein.

  9. Stellen Sie die Lösung in Ihrer Testumgebung bereit:

    1. Klonen und führen Sie die Terraform-Scripts aus, um eine Umgebung in Google Cloud einzurichten.
    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 mithilfe einer der folgenden Methoden:

    7. Verschlüsselte Daten mithilfe von Streaming- oder Batch-Uploads in BigQuery hochladen.

  10. Prüfen Sie, ob autorisierte Nutzer mit der BigQuery-AEAD-Entschlüsselungsfunktion unverschlüsselte Daten aus BigQuery lesen können. Führen Sie beispielsweise folgende Funktion zum Erstellen einer Entschlüsselung aus:

    CREATE OR REPLACE FUNCTION `{project_id}.{bigquery_dataset}.decrypt`(encodedText STRING) RETURNS STRING AS
(
AEAD.DECRYPT_STRING(
KEYS.KEYSET_CHAIN('gcp-kms://projects/myProject/locations/us/keyRings/myKeyRing/cryptoKeys/myKeyName', b'\012\044\000\321\054\306\036\026…..'),
FROM_BASE64(encodedText), "")
);

    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.

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

  12. Stellen Sie den Blueprint in Ihrer Produktionsumgebung bereit.

Nächste Schritte