Datenprofile

Auf dieser Seite wird der Dienst zur Erkennung sensibler Daten beschrieben. Mit diesem Dienst können Sie ermitteln, wo sich sensible und risikoreiche Daten in Ihrer Organisation befinden.

Überblick

Mit dem Erkennungsdienst können Sie Daten in Ihrer gesamten Organisation schützen. Dazu ermitteln Sie, wo sich sensible und risikoreiche Daten befinden. Wenn Sie eine Konfiguration für Discovery-Scans erstellen, scannt der Schutz sensibler Daten Ihre Ressourcen, um die Daten zu identifizieren, die für die Profilerstellung infrage kommen. Dann werden Profile Ihrer Daten erstellt. Solange die Erkennungskonfiguration aktiv ist, erstellt der Schutz sensibler Daten automatisch ein Profil für die Daten, die Sie hinzufügen und ändern. Sie können Datenprofile für die gesamte Organisation, einzelne Ordner und einzelne Projekte generieren.

Jedes Datenprofil besteht aus einer Reihe von Statistiken und Metadaten, die der Erkennungsdienst beim Scannen einer unterstützten Ressource erfasst. Die Statistiken umfassen die vorhergesagten infoTypes sowie die berechneten Datenrisiko- und Vertraulichkeitsstufen Ihrer Daten. Verwenden Sie diese Informationen, um fundierte Entscheidungen darüber zu treffen, wie Sie Ihre Daten schützen, freigeben und verwenden.

Datenprofile werden mit verschiedenen Detailebenen generiert. Wenn Sie beispielsweise Profile für BigQuery-Daten erstellen, werden Profile auf Projekt-, Tabellen- und Spaltenebene generiert.

In der folgenden Abbildung sehen Sie eine Liste von Datenprofilen auf Spaltenebene. Klicken Sie auf das Bild, um es zu vergrößern.

Screenshot von Spaltendatenprofilen

Eine Liste der in den einzelnen Datenprofilen enthaltenen Statistiken und Metadaten finden Sie unter Messwertreferenz.

Weitere Informationen zur Google Cloud-Ressourcenhierarchie finden Sie unter Ressourcenhierarchie.

BigQuery-Datenerkennung

Wenn Sie Profil für BigQuery-Daten erstellen, werden Datenprofile auf Projekt-, Tabellen- und Spaltenebene generiert. Nachdem Sie ein Profil für eine BigQuery-Tabelle erstellt haben, können Sie die Ergebnisse durch eine gründliche Prüfung weiter untersuchen.

Weitere Informationen zu BigQuery finden Sie in der BigQuery-Dokumentation.

Cloud SQL-Datenerkennung

Wenn Sie Profil für Cloud SQL-Daten erstellen, werden Datenprofile auf Projekt-, Tabellen- und Spaltenebene generiert. Bevor die Erkennung beginnen kann, müssen Sie die Verbindungsdetails für jede Cloud SQL-Instanz angeben, für die ein Profil erstellt werden soll.

Weitere Informationen zu Cloud SQL finden Sie in der Cloud SQL-Dokumentation.

Datenprofilerstellung

Zum Generieren von Datenprofilen erstellen Sie eine Discovery-Scankonfiguration (auch Datenprofilkonfiguration genannt). In dieser Scankonfiguration legen Sie den Bereich des Erkennungsvorgangs und den Datentyp fest, für den ein Profil erstellt werden soll. In der Scankonfiguration können Sie Filter festlegen, um Teilmengen von Daten anzugeben, für die Sie ein Profil erstellen oder überspringen möchten. Sie können auch den Zeitplan für die Profilerstellung festlegen.

Beim Erstellen einer Scankonfiguration legen Sie auch die zu verwendende Inspektionsvorlage fest. In der Inspektionsvorlage geben Sie die Typen sensibler Daten (auch als infoTypes bezeichnet) an, die vom Schutz sensibler Daten gescannt werden sollen.

Wenn der Schutz sensibler Daten Datenprofile erstellt, werden Ihre Daten anhand Ihrer Scankonfiguration und Inspektionsvorlage analysiert.

Unterstützte Ressourcen

In diesem Abschnitt werden die Ressourcen beschrieben, für die der Schutz sensibler Daten ein Profil erstellen kann.

BigQuery und BigLake

Der Schutz sensibler Daten erstellt Profile für Tabellen, die von der BigQuery Storage Read API unterstützt werden, darunter:

  • Standard-BigQuery-Tabellen
  • In Cloud Storage gespeicherte BigLake-Tabellen

Folgendes wird nicht unterstützt:

  • BigQuery Omni-Tabellen:
  • Tabellen, in denen die serielle Datengröße einzelner Zeilen die von der BigQuery Storage Read API unterstützte maximale serielle Datengröße von 128 MB überschreitet.
  • Externe Tabellen, die nicht von BigLake stammen, z. B. Google Tabellen.

Cloud SQL

Der Schutz sensibler Daten kann Profile für Cloud SQL-Tabellen erstellen.

Rollen, die zum Konfigurieren und Aufrufen von Datenprofilen erforderlich sind

In den folgenden Abschnitten sind die erforderlichen Nutzerrollen nach ihrem Zweck kategorisiert. Je nachdem, wie Ihre Organisation eingerichtet ist, können Sie unterschiedliche Personen verschiedene Aufgaben ausführen lassen. Beispielsweise kann sich die Person, die Datenprofile konfiguriert, von der Person unterscheiden, die sie regelmäßig überwacht.

Rollen, die für die Arbeit mit Datenprofilen auf Organisations- oder Ordnerebene erforderlich sind

Mit diesen Rollen können Sie Datenprofile auf Organisations- oder Ordnerebene konfigurieren und aufrufen.

Achten Sie darauf, dass diese Rollen den richtigen Personen auf Organisationsebene zugewiesen werden. Alternativ kann Ihr Google Cloud-Administrator benutzerdefinierte Rollen erstellen, die nur die relevanten Berechtigungen haben.

Zweck Vordefinierte Rolle Relevante Berechtigungen
Scankonfiguration erstellen und Datenprofile ansehen DLP Administrator (roles/dlp.admin)
  • dlp.inspectTemplates.create
  • dlp.jobs.create
  • dlp.jobTriggers.create
  • dlp.columnDataProfiles.list
  • dlp.jobs.list
  • dlp.jobTriggers.list
  • dlp.projectDataProfiles.list
  • dlp.tableDataProfiles.list
Projekt erstellen, das als Dienst-Agent-Container verwendet werden soll1 Projektersteller (roles/resourcemanager.projectCreator)
  • resourcemanager.organizations.get
  • resourcemanager.projects.create
Zugriff auf die Datenprofilerstellung gewähren2 Eine der folgenden:
  • Organisationsadministrator (roles/resourcemanager.organizationAdmin)
  • Sicherheitsadministrator (roles/iam.securityAdmin)
  • resourcemanager.organizations.getIamPolicy
  • resourcemanager.organizations.setIamPolicy
Datenprofile ansehen (schreibgeschützt) Leser von DLP-Datenprofilen (roles/dlp.dataProfilesReader)
  • dlp.columnDataProfiles.list
  • dlp.projectDataProfiles.list
  • dlp.tableDataProfiles.list
DLP-Leser (roles/dlp.reader)
  • dlp.jobs.list
  • dlp.jobTriggers.list

1 Wenn Sie die Rolle „Projektersteller“ (roles/resourcemanager.projectCreator) nicht haben, können Sie trotzdem eine Scankonfiguration erstellen. Der von Ihnen verwendete Dienst-Agent-Container muss jedoch ein vorhandenes Projekt sein.

2 Wenn Sie nicht die Rolle „Organisationsadministrator“ (roles/resourcemanager.organizationAdmin) oder Sicherheitsadministrator“ (roles/iam.securityAdmin) haben, können Sie trotzdem eine Scankonfiguration erstellen. Nachdem Sie die Scankonfiguration erstellt haben, muss eine Person in Ihrer Organisation, die eine dieser Rollen hat, dem Dienst-Agent Erkennungszugriff auf den Dienst-Agent gewähren.

Rollen, die für die Arbeit mit Datenprofilen auf Projektebene erforderlich sind

Mit diesen Rollen können Sie Datenprofile auf Projektebene konfigurieren und ansehen.

Achten Sie darauf, dass diese Rollen den richtigen Personen auf Projektebene zugewiesen werden. Alternativ kann Ihr Google Cloud-Administrator benutzerdefinierte Rollen erstellen, die nur die relevanten Berechtigungen haben.

Zweck Vordefinierte Rolle Relevante Berechtigungen
Datenprofile konfigurieren und ansehen DLP Administrator (roles/dlp.admin)
  • dlp.inspectTemplates.create
  • dlp.jobs.create
  • dlp.jobTriggers.create
  • dlp.columnDataProfiles.list
  • dlp.jobs.list
  • dlp.jobTriggers.list
  • dlp.projectDataProfiles.list
  • dlp.tableDataProfiles.list
Datenprofile ansehen (schreibgeschützt) Leser von DLP-Datenprofilen (roles/dlp.dataProfilesReader)
  • dlp.columnDataProfiles.list
  • dlp.projectDataProfiles.list
  • dlp.tableDataProfiles.list
DLP-Leser (roles/dlp.reader)
  • dlp.jobs.list
  • dlp.jobTriggers.list

Konfiguration des Erkennungsscans

Eine Discovery-Scankonfiguration oder eine Datenprofilkonfiguration gibt an, für welche Ressource (Organisation, Ordner oder Projekt) ein Profil erstellt werden soll, welche Inspektionsvorlage verwendet werden soll und was mit den Ergebnissen geschehen soll. Sie enthält auch administrative Details wie den Dienst-Agent-Container, mit dem der Scan verknüpft werden soll und welches Rechnungskonto verwendet werden soll.

Erkennungstypen

Der Erkennungsdienst unterstützt die folgenden Arten von Vorgängen:

Bereiche der Scankonfiguration

Sie können eine Scankonfiguration auf den folgenden Ebenen erstellen:

  • Organisation
  • Ordner
  • Projekt
  • Tabelle (Testmodus)

Wenn zwei oder mehr aktive Scankonfigurationen auf Organisations- und Ordnerebene dasselbe Projekt haben, bestimmt der Schutz sensibler Daten, welche Scankonfiguration Profile für dieses Projekt generieren kann. Weitere Informationen finden Sie auf dieser Seite unter Scankonfigurationen überschreiben.

Bei einer Scankonfiguration auf Projektebene kann immer ein Profil für das Zielprojekt erstellt werden und sie konkurriert nicht mit anderen Konfigurationen auf Ebene des übergeordneten Ordners oder der übergeordneten Organisation.

Eine Scankonfiguration auf Tabellenebene soll Ihnen helfen, die Profilerstellung für eine einzelne Tabelle zu untersuchen und zu testen.

Speicherort der Scankonfiguration

Wenn Sie eine Scankonfiguration zum ersten Mal erstellen, geben Sie an, wo sie vom Schutz sensibler Daten gespeichert werden soll. Alle nachfolgenden Scankonfigurationen, die Sie erstellen, werden in derselben Region gespeichert.

Wenn Sie beispielsweise eine Scankonfiguration für Ordner A erstellen und in der Region us-west1 speichern, wird jede Scankonfiguration, die Sie später für andere Ressourcen erstellen, auch in dieser Region gespeichert.

Metadaten zu den Daten, für die ein Profil erstellt werden soll, werden in dieselbe Region wie die Scankonfigurationen kopiert. Die Daten selbst werden jedoch weder verschoben noch kopiert. Weitere Informationen finden Sie unter Überlegungen zum Datenstandort.

Inspektionsvorlage

Eine Inspektionsvorlage gibt an, nach welchen Informationstypen (oder infoTypes) der Schutz sensibler Daten beim Scannen Ihrer Daten sucht. Hier geben Sie eine Kombination aus integrierten infoTypes und optionalen benutzerdefinierten infoTypes an.

Sie können auch eine Wahrscheinlichkeitsstufe angeben, um einzugrenzen, was der Schutz sensibler Daten als Übereinstimmung betrachtet. Sie können Regelsätze hinzufügen, um unerwünschte Ergebnisse auszuschließen oder zusätzliche Ergebnisse einzubeziehen.

Wenn Sie eine Inspektionsvorlage ändern, die von Ihrer Scankonfiguration verwendet wird, werden die Änderungen standardmäßig nur auf zukünftige Scans angewendet. Ihre Aktion führt nicht zu einer Profiländerung bei Ihren Daten.

Wenn Sie möchten, dass Änderungen an der Prüfungsvorlage Vorgänge zur Profiländerung für die betroffenen Daten auslösen, fügen Sie Ihrer Scankonfiguration einen Zeitplan hinzu oder aktualisieren Sie ihn und aktivieren Sie die Option, ein neues Profil für die Daten zu erstellen, wenn sich die Inspektionsvorlage ändert. Weitere Informationen finden Sie unter Häufigkeit der Datenprofilerstellung.

Sie müssen in jeder Region, in der Daten erstellt werden sollen, eine Inspektionsvorlage haben. Wenn Sie eine einzelne Vorlage für mehrere Regionen verwenden möchten, können Sie eine Vorlage verwenden, die in der Region global gespeichert ist. Wenn Sie aufgrund von Organisationsrichtlinien keine global-Inspektionsvorlage erstellen können, müssen Sie für jede Region eine eigene Inspektionsvorlage festlegen. Weitere Informationen finden Sie unter Überlegungen zum Datenstandort.

Inspektionsvorlagen sind ein zentraler Bestandteil der Plattform zum Schutz sensibler Daten. Für Datenprofile werden die gleichen Inspektionsvorlagen verwendet, die Sie für alle Dienste zum Schutz sensibler Daten verwenden können. Weitere Informationen zu Inspektionsvorlagen finden Sie unter Vorlagen.

Dienst-Agent-Container und Dienst-Agent

Wenn Sie eine Scankonfiguration für Ihre Organisation oder einen Ordner erstellen, müssen Sie für den Schutz sensibler Daten einen Dienst-Agent-Container bereitstellen. Ein Dienst-Agent-Container ist ein Google Cloud-Projekt, mit dem Sensitive Data Protection die Gebühren für Profilerstellungsvorgänge auf Organisations- und Ordnerebene verfolgt.

Der Dienst-Agent-Container enthält einen Dienst-Agent. Dabei handelt es sich um ein von Google verwaltetes Dienstkonto, das vom Schutz sensibler Daten verwendet wird, um in Ihrem Namen ein Profil für Daten zu erstellen. Sie benötigen einen Dienst-Agent, um sich beim Schutz sensibler Daten und anderen APIs zu authentifizieren. Der Dienst-Agent muss alle erforderlichen Berechtigungen für den Zugriff auf und Profilerstellung für Ihre Daten haben. Die ID des Dienst-Agents hat das folgende Format:

service-PROJECT_NUMBER@dlp-api.iam.gserviceaccount.com

Hier ist PROJECT_NUMBER die numerische Kennung des Dienst-Agent-Containers.

Beim Festlegen des Dienst-Agent-Containers können Sie ein vorhandenes Projekt auswählen. Wenn das ausgewählte Projekt einen Dienst-Agent enthält, gewährt Sensitive Data Protection diesem Dienst-Agent die erforderlichen IAM-Berechtigungen. Wenn das Projekt keinen Dienst-Agent hat, erstellt der Schutz sensibler Daten einen und gewährt ihm automatisch Berechtigungen zur Datenprofilerstellung.

Alternativ können Sie festlegen, dass der Schutz sensibler Daten automatisch den Dienst-Agent-Container und den Dienst-Agent erstellt. Der Schutz sensibler Daten gewährt dem Dienst-Agent automatisch Berechtigungen zur Datenprofilerstellung.

Wenn der Schutz sensibler Daten dem Dienst-Agent keinen Zugriff auf die Datenprofilerstellung gewährt, wird in beiden Fällen ein Fehler angezeigt, wenn Sie die Details der Scankonfiguration aufrufen.

Für Scankonfigurationen auf Projektebene benötigen Sie keinen Dienst-Agent-Container. Das Projekt, für das Sie ein Profil erstellen, dient dem Zweck des Dienst-Agent-Containers. Zum Ausführen von Profilerstellungsvorgängen verwendet Sensitive Data Protection den eigenen Dienst-Agent dieses Projekts.

Zugriff auf die Datenprofilerstellung auf Organisations- oder Ordnerebene

Wenn Sie die Profilerstellung auf Organisations- oder Ordnerebene konfigurieren, versucht Sensitive Data Protection, dem Dienst-Agent automatisch Zugriff auf die Datenprofilerstellung zu gewähren. Wenn Sie jedoch nicht die Berechtigungen zum Gewähren von IAM-Rollen haben, kann der Schutz sensibler Daten diese Aktion nicht in Ihrem Namen ausführen. Ein Nutzer mit diesen Berechtigungen in Ihrer Organisation, z. B. ein Google Cloud-Administrator, muss Ihrem Dienst-Agent Zugriff auf die Datenprofilerstellung gewähren.

Häufigkeit der Datenprofilerstellung

Standardmäßig erstellt der Schutz sensibler Daten ein Profil für Ihre Daten:

  1. Nachdem Sie eine Scankonfiguration für eine bestimmte Ressource erstellt haben, führt der Schutz sensibler Daten einen ersten Scan durch und erstellt für die Daten im Bereich der Scankonfiguration ein Profil. Nach dem ersten Scan werden die Daten kontinuierlich auf Ergänzungen oder Änderungen überwacht.

  2. Der Schutz sensibler Daten erstellt Profile für neue Tabellen, die Sie kurz nach dem Hinzufügen hinzufügen.

  3. Alle 30 Tage erstellt der Schutz sensibler Daten ein neues Profil für vorhandene Tabellen, bei denen in den letzten 30 Tagen Schemaänderungen vorgenommen wurden.

In der Scankonfiguration können Sie die Häufigkeit der Profilerstellung anpassen, indem Sie einen oder mehrere Zeitpläne für verschiedene Teilmengen Ihrer Daten erstellen. Sie können Teilmengen von Daten angeben, für die nie ein Profil erstellt werden soll. Sie können auch die Ereignistypen angeben, die Vorgänge zur Profilneuerstellung auslösen sollen. Beispiele für solche Ereignisse sind Aktualisierungen von Tabellenschemas und Aktualisierungen von Inspektionsvorlagen.

Die folgenden Optionen für die Profilneuerstellung sind verfügbar:

  • Profil nicht neu erstellen: Erstellen Sie nie ein neues Profil, nachdem die ersten Profile erstellt wurden.
  • Profil täglich neu erstellen: Warten Sie 24 Stunden, bevor Sie für aktualisierte Daten ein neues Profil erstellen.
  • Profil wöchentlich neu erstellen: Warten Sie sieben Tage, bevor Sie für aktualisierte Daten ein neues Profil erstellen.
  • Profil monatlich neu erstellen: Warten Sie 30 Tage, bevor Sie für aktualisierte Daten ein neues Profil erstellen.

Der Zeitplan gibt an, wie lange der Schutz sensibler Daten höchstens auf Aktualisierungen wartet, bevor ein Profil für die Daten neu erstellt wird. Wenn innerhalb des angegebenen Zeitraums keine anwendbaren Änderungen wie Schemaänderungen oder Änderungen der Prüfungsvorlage auftreten, wird kein neues Profil für Daten erstellt. Wenn die nächste anwendbare Änderung eintritt, wird für die betroffenen Daten bei der nächsten Gelegenheit ein neues Profil erstellt. Dies wird durch verschiedene Faktoren wie die verfügbare Maschinenkapazität oder die erworbenen Aboeinheiten bestimmt. Der Schutz sensibler Daten wartet dann darauf, dass sich gemäß Ihrem festgelegten Zeitplan wieder Aktualisierungen ansammeln.

Angenommen, Ihre Scankonfiguration ist so eingestellt, dass das Profil bei einer Schemaänderung monatlich neu erstellt wird. Die Datenprofile wurden erstmals an Tag 0 erstellt. An Tag 30 werden keine Schemaänderungen vorgenommen, sodass kein neues Profil für Daten erstellt wird. An Tag 35 erfolgt die erste Schemaänderung. Beim Schutz sensibler Daten wird für die aktualisierten Daten bei der nächsten Gelegenheit ein neues Profil erstellt. Das System wartet dann weitere 30 Tage, bis sich Schemaaktualisierungen angesammelt haben, bevor aktualisierte Daten neu Profil erstellt werden.

Ab Beginn der Profilerstellung kann es bis zu 24 Stunden dauern, bis der Vorgang abgeschlossen ist. Wenn die Verzögerung länger als 24 Stunden dauert und Sie sich im Abopreismodus befinden, prüfen Sie, ob Sie noch Kapazität für den Monat haben.

Beispielszenarien finden Sie unter Preisbeispiele für Datenprofilerstellung.

Leistungsprofilerstellung

Die Zeit für die Profilerstellung Ihrer Daten hängt von mehreren Faktoren ab, einschließlich, aber nicht beschränkt auf:

  • Anzahl der Tabellen, für die ein Profil erstellt wird
  • Größen der Tabellen
  • Anzahl der Spalten in den Tabellen
  • Datentypen in den Spalten

Daher ist die Leistung des Schutzes sensibler Daten bei einer früheren Prüfungs- oder Profilerstellung kein Hinweis darauf, wie er bei zukünftigen Profilerstellungsaufgaben abschneidet.

Aufbewahrung von Datenprofilen

Beim Schutz sensibler Daten wird die neueste Version eines Datenprofils 13 Monate lang aufbewahrt. Wenn der Schutz sensibler Daten ein neues Profil für eine aktualisierte Tabelle erstellt, werden die vorhandenen Datenprofile dieser Tabelle durch neue ersetzt.

Sehen Sie sich die folgenden Szenarien an:

  • Am 1. Januar erstellt der Schutz sensibler Daten ein Profil in Tabelle A. Tabelle A ändert sich mehr als ein Jahr lang nicht und daher wird kein neues Profil dafür erstellt. In diesem Fall werden die Datenprofile für Tabelle A vom Schutz sensibler Daten 13 Monate lang aufbewahrt, bevor sie gelöscht werden.

  • Am 1. Januar erstellt der Schutz sensibler Daten ein Profil in Tabelle A. Innerhalb des Monats aktualisiert jemand in Ihrer Organisation das Schema dieser Tabelle. Aufgrund dieser Änderung erstellt der Schutz sensibler Daten im folgenden Monat automatisch ein neues Profil für Tabelle A. Die im Januar erstellten Datenprofile werden von den neu generierten Datenprofilen überschrieben.

Weitere Informationen zu den Gebühren für die Erstellung von Profilen für neue und geänderte Tabellen für den Schutz sensibler Daten finden Sie unter Preise für die Datenprofilerstellung.

Wenn Sie Datenprofile auf unbestimmte Zeit aufbewahren oder die vorgenommenen Änderungen aufzeichnen möchten, sollten Sie die Datenprofile bei der Konfiguration der Profilerstellung in BigQuery speichern. Sie wählen, in welchem BigQuery-Dataset die Profile gespeichert werden sollen und steuern die Ablaufrichtlinie für dieses Dataset.

Scankonfigurationen überschreiben

Sie können für jede Kombination aus Bereich und Erkennungstyp nur eine Scankonfiguration erstellen. Sie können beispielsweise nur eine Scankonfiguration auf Organisationsebene für die BigQuery-Datenprofilerstellung und eine Scankonfiguration auf Organisationsebene für die Secret-Erkennung erstellen. Ebenso können Sie nur eine Scankonfiguration auf Projektebene für die BigQuery-Datenprofilerstellung und eine Scankonfiguration auf Projektebene für die Erkennung von Secrets erstellen.

Wenn zwei oder mehr aktive Scankonfigurationen dasselbe Projekt und denselben Erkennungstyp haben, gelten die folgenden Regeln:

  • Bei Scankonfigurationen auf Organisations- und Ordnerebene kann diejenige, die dem Projekt am nächsten ist, die Erkennung für dieses Projekt ausführen. Diese Regel gilt auch dann, wenn eine Scankonfiguration auf Projektebene mit demselben Erkennungstyp auch vorhanden ist.
  • Der Schutz sensibler Daten behandelt Scankonfigurationen auf Projektebene unabhängig von Konfigurationen auf Organisations- und Ordnerebene. Eine auf Projektebene erstellte Scankonfiguration kann eine Konfiguration, die Sie für einen übergeordneten Ordner oder eine übergeordnete Organisation erstellen, nicht überschreiben.

Im folgenden Beispiel gibt es drei aktive Scankonfigurationen. Angenommen, alle diese Scankonfigurationen sind für die BigQuery-Datenprofilerstellung bestimmt.

Diagramm einer Ressourcenhierarchie mit einer Scankonfiguration, die auf eine Organisation, einen Ordner und ein Projekt angewendet wird

Hier gilt Scankonfiguration 1 für die gesamte Organisation, Scankonfiguration 2 gilt für den Team B-Ordner und Scankonfiguration 3 gilt für das Projekt Produktion. In diesem Fall gilt Folgendes:

  • Der Schutz sensibler Daten erstellt für alle Tabellen in Projekten, die sich nicht im Ordner Team B befinden, gemäß Scankonfiguration 1 ein Profil.
  • Der Schutz sensibler Daten erstellt Profile für alle Tabellen in Projekten im Ordner Team B – einschließlich Tabellen im Projekt Production – gemäß Scankonfiguration 2.
  • Der Schutz sensibler Daten erstellt für alle Tabellen im Produktionsprojekt ein Profil gemäß Scankonfiguration 3.

In diesem Beispiel generiert der Schutz sensibler Daten zwei Arten von Profilen für das Projekt Produktion – ein Profil für jede der folgenden Scankonfigurationen:

  • Scankonfiguration 2
  • Scankonfiguration 3

Obwohl es zwei Profilsätze für dasselbe Projekt gibt, können Sie sie jedoch nicht alle zusammen im Dashboard sehen. Sie sehen nur die Profile, die in der Ressource – Organisation, Ordner oder Projekt – und der angezeigten Region generiert wurden.

Weitere Informationen zur Ressourcenhierarchie von Google Cloud finden Sie unter Ressourcenhierarchie.

Snapshots von Datenprofilen

Jedes Datenprofil enthält einen Snapshot der Scankonfiguration und die Inspektionsvorlage, die zum Generieren verwendet wurde. Mit diesem Snapshot können Sie die Einstellungen prüfen, die Sie zum Generieren eines bestimmten Datenprofils verwendet haben.

Überlegungen zum Datenstandort

Der Schutz sensibler Daten wurde für den Datenstandort entwickelt. Beachten Sie die folgenden Punkte, wenn Sie Anforderungen an den Datenstandort erfüllen müssen:

Prüfregionen

Sensitive Data Protection prüft Ihre Daten in derselben Region, in der sie gespeichert sind. Ihre Daten verlassen also nicht ihre aktuelle Region.

Außerdem können mit einer Inspektionsvorlage nur Profile für Daten erstellt werden, die sich in derselben Region wie diese Vorlage befinden. Wenn Sie den Datenprofiler beispielsweise so konfigurieren, dass er eine Inspektionsvorlage verwendet, die in der Region us-west1 gespeichert ist, kann der Schutz sensibler Daten nur Profile für Daten in dieser Region erstellen.

Sie können für jede Region, in der Sie Daten haben, eine dedizierte Inspektionsvorlage festlegen. Wenn Sie eine Inspektionsvorlage angeben, die in der Region global gespeichert ist, verwendet der Schutz sensibler Daten diese Vorlage für Daten in Regionen ohne dedizierte Inspektionsvorlage.

Die folgende Tabelle enthält Beispielszenarien:

Szenario Support
Scannen Sie Daten in der Region us mit einer Inspektionsvorlage aus der Region us. Unterstützt
Scannen Sie Daten in der Region global mit einer Inspektionsvorlage aus der Region us. Nicht unterstützt
Scannen Sie Daten in der Region us mit einer Inspektionsvorlage aus der Region global. Unterstützt
Scannen Sie Daten in der Region us mit einer Inspektionsvorlage aus der Region us-east1. Nicht unterstützt
Scannen Sie Daten in der Region us-east1 mit einer Inspektionsvorlage aus der Region us. Nicht unterstützt
Scannen Sie Daten in der Region us mit einer Inspektionsvorlage aus der Region asia. Nicht unterstützt

Konfiguration von Datenprofilen

Wenn der Schutz sensibler Daten Datenprofile erstellt, wird ein Snapshot Ihrer Scankonfiguration und der Inspektionsvorlage erstellt und in jedem Tabellendatenprofil gespeichert. Wenn Sie den Daten-Profiler für die Verwendung einer Inspektionsvorlage aus der Region global konfigurieren, kopiert der Schutz sensibler Daten diese Vorlage in eine beliebige Region, in der Daten erstellt werden sollen. Die Scankonfiguration wird in diese Regionen kopiert.

Betrachten Sie dieses Beispiel: Projekt A enthält Tabelle 1. Tabelle 1 befindet sich in der Region us-west1. Die Scankonfiguration befindet sich in der Region us-west2 und die Inspektionsvorlage befindet sich in der Region global.

Wenn der Schutz sensibler Daten Projekt A scannt, erstellt er Datenprofile für Tabelle 1 und speichert sie in der Region us-west1. Das Tabellendatenprofil von Tabelle 1 enthält Kopien der Scankonfiguration und der bei der Profilerstellung verwendeten Inspektionsvorlage.

Wenn Sie nicht möchten, dass Ihre Inspektionsvorlage in andere Regionen kopiert wird, konfigurieren Sie den Schutz sensibler Daten nicht so, dass Daten in diesen Regionen gescannt werden.

Regional Storage für Datenprofile

Nach der Prüfung Ihrer Daten generiert der Schutz sensibler Daten Datenprofile. Jedes Datenprofil wird in derselben Region gespeichert, in der auch die Zieldaten gespeichert sind. Dort wird auch die Prüfung verarbeitet. Wenn Sie Datenprofile in der Google Cloud Console ansehen möchten, müssen Sie zuerst die Region auswählen, in der sie sich befinden. Wenn Sie Daten in mehreren Regionen haben, müssen Sie die Region wechseln, um jeden Satz von Profilen anzusehen.

Nicht unterstützte Regionen

Wenn sich Tabellen in einer Region befinden, die der Schutz sensibler Daten nicht unterstützt, werden diese Tabellen übersprungen und beim Aufrufen der Datenprofile wird ein Fehler angezeigt.

Multiregionen

Der Schutz sensibler Daten behandelt einen multiregionalen Standort als eine Region und nicht als eine Sammlung von Regionen. Beispiel: Die Multi-Region us und die Region us-west1 werden im Hinblick auf den Datenstandort als zwei separate Regionen behandelt.

Compliance

Informationen dazu, wie der Schutz sensibler Daten mit Ihren Daten umgeht und Sie bei der Einhaltung von Complianceanforderungen unterstützt, finden Sie unter Datensicherheit.

Nächste Schritte