De-Identifikation sensibler Cloud Storage-Daten

Auf dieser Seite wird beschrieben, wie Sensitive Data Protection de-identifizierte Kopien von Daten erstellen kann, die in Cloud Storage gespeichert sind. Außerdem werden die Einschränkungen dieses Vorgangs und die Punkte aufgeführt, die Sie beachten sollten, bevor Sie beginnen.

Informationen dazu, wie Sie mit Sensitive Data Protection de-identifizierte Kopien Ihrer Cloud Storage-Daten erstellen, finden Sie hier:

De-Identifikation

De-Identifikation ist der Prozess, bei dem personenidentifizierbare Informationen aus Daten entfernt werden. Ziel ist es, die Nutzung und Weitergabe personenbezogener Daten wie Gesundheits-, Finanz- oder demografischer Daten zu ermöglichen und gleichzeitig die Datenschutzanforderungen zu erfüllen. Weitere Informationen zur De-Identifikation finden Sie unter Sensible Daten de-identifizieren.

Ausführlichere Informationen zu Transformationen zur De-Identifikation in Sensitive Data Protection finden Sie in der Transformationsreferenz. Weitere Informationen dazu, wie Sensitive Data Protection sensible Daten aus Bildern unkenntlich macht, finden Sie unter Bildinspektion und Unkenntlichmachung.

Wann sollte die Speicherdepersonalisierung verwendet werden?

Im Folgenden sind einige gängige Anwendungsfälle aufgeführt:

  • Anonymisierte Datasets für Nichtproduktionsumgebungen generieren: Erstellen Sie de-identifizierte Kopien von Produktionsdateien, die in Cloud Storage gespeichert sind, bevor Sie Daten in Entwicklungs-, Test- oder Trainingsumgebungen bereitstellen.
  • Bereinigte Dateirepositories für Dritte freigeben: Sensible Felder in Massendokumenten und unstrukturierten Dateien werden verschleiert, während die ursprüngliche Ordnerhierarchie für externe Geschäftspartner oder Prüfer beibehalten wird.
  • Datenschutz-Pipelines für aufgenommene Dokumente automatisieren: Sensible Daten in neu hochgeladenen Dateien in einen bestimmten Ausgabebucket transformieren, ohne Quelldateien zu ändern oder Upstream-Pipelines zu unterbrechen.
  • Datenstandort und ‑segmentierung erzwingen: Speichern Sie de-identifizierte Spiegelkopien sensibler Assets in separaten Cloud Storage-Buckets mit unterschiedlichen Identity and Access Management-Zugriffssteuerungen.

Prozess der De-Identifikation

In diesem Abschnitt wird der De-Identifikationsprozess in Sensitive Data Protection für Inhalte in Cloud Storage beschrieben.

Wenn Sie dieses Feature verwenden möchten, erstellen Sie einen Prüfjob (DlpJob), der so konfiguriert ist, dass de-identifizierte Kopien der Cloud Storage-Dateien erstellt werden. Sensitive Data Protection scannt die Dateien am angegebenen Speicherort und untersucht sie gemäß Ihrer Konfiguration. Beim Überprüfen jeder Datei werden alle Daten, die Ihren Kriterien für sensible Daten entsprechen, anonymisiert und dann in eine neue Datei geschrieben. Die neue Datei hat immer denselben Dateinamen wie die Originaldatei. Die neue Datei wird in einem von Ihnen angegebenen Ausgabeverzeichnis gespeichert. Wenn eine Datei in Ihren Scan einbezogen wird, aber keine Daten Ihren Anonymisierungskriterien entsprechen und bei der Verarbeitung keine Fehler auftreten, wird die Datei unverändert in das Ausgabeverzeichnis kopiert.

Das von Ihnen festgelegte Ausgabeverzeichnis muss sich in einem Cloud Storage-Bucket befinden, der sich von dem Bucket mit Ihren Eingabedateien unterscheidet. Im Ausgabeverzeichnis wird durch Sensitive Data Protection eine Dateistruktur erstellt, die der Dateistruktur des Eingabeverzeichnisses entspricht.

Angenommen, Sie haben die folgenden Ein- und Ausgabeverzeichnisse festgelegt:

  • Eingabeverzeichnis: gs://input-bucket/folder1/folder1a
  • Ausgabeverzeichnis: gs://output-bucket/output-directory

Während der De-Identifikation speichert Sensitive Data Protection die de-identifizierten Dateien in gs://output-bucket/output-directory/folder1/folder1a.

Wenn im Ausgabeverzeichnis eine Datei mit demselben Dateinamen wie eine anonymisierte Datei vorhanden ist, wird diese Datei überschrieben. Wenn Sie nicht möchten, dass vorhandene Dateien überschrieben werden, ändern Sie das Ausgabeverzeichnis, bevor Sie diesen Vorgang ausführen. Alternativ können Sie die Objektversionsverwaltung für den Ausgabebucket aktivieren.

Die ACLs (Access Control Lists) auf Dateiebene für die Originaldateien werden in die neuen Dateien kopiert, unabhängig davon, ob sensible Daten gefunden und anonymisiert wurden. Wenn der Ausgabebucket jedoch nur für einheitliche Berechtigungen auf Bucket-Ebene und nicht für detaillierte Berechtigungen (auf Objektebene) konfiguriert ist, werden die ACLs nicht in die anonymisierten Dateien kopiert.

Das folgende Diagramm zeigt den Prozess der De-Identifizierung für vier Dateien, die in einem Cloud Storage-Bucket gespeichert sind. Jede Datei wird kopiert, unabhängig davon, ob Sensitive Data Protection sensible Daten erkennt. Jede kopierte Datei hat denselben Namen wie das Original.

De-Identifizierung von in Cloud Storage gespeicherten Dateien
De-Identifikation von in Cloud Storage gespeicherten Dateien (zum Vergrößern klicken).

Preise

Preisinformationen finden Sie unter Daten im Speicher prüfen und transformieren.

Unterstützte Dateitypen

Mit Sensitive Data Protection können die folgenden Dateitypgruppen de-identifiziert werden:

  • CSV
  • Bild
  • Text
  • TSV

Standardverhalten der De-Identifikation

Wenn Sie festlegen möchten, wie Sensitive Data Protection die Ergebnisse transformiert, können Sie Vorlagen zum De-Identifizieren für die folgenden Dateitypen bereitstellen:

  • Unstrukturierte Dateien wie Textdateien mit Freiformtext
  • Strukturierte Dateien wie CSV-Dateien
  • Bilder

Wenn Sie keine De-Identifikationsvorlage angeben, werden die Ergebnisse von Sensitive Data Protection so transformiert:

  • In unstrukturierten und strukturierten Dateien ersetzt Sensitive Data Protection alle Ergebnisse durch den entsprechenden infoType, wie unter InfoType-Ersetzung beschrieben.
  • In Bildern werden alle Ergebnisse des Schutzes sensibler Daten mit einem schwarzen Rechteck abgedeckt.

Einschränkungen und Überlegungen

Beachten Sie die folgenden Punkte, bevor Sie de-identifizierte Kopien von Cloud Storage-Daten erstellen.

Speicherplatz

Dieser Vorgang unterstützt nur in Cloud Storage gespeicherte Inhalte.

Bei diesem Vorgang wird eine Kopie jeder Datei erstellt, während sie von Sensitive Data Protection geprüft wird. Die Originalinhalte werden dadurch nicht geändert oder entfernt. Die kopierten Daten benötigen ungefähr genauso viel zusätzlichen Speicherplatz wie die Originaldaten.

Schreibzugriff auf den Speicher

Da Sensitive Data Protection eine Kopie der Originaldateien erstellt, muss das Dienstkonto Ihres Projekts Schreibzugriff auf den Cloud Storage-Ausgabe-Bucket haben.

Stichprobenerhebung und Festlegen von Limits für die Suche

Für diesen Vorgang wird keine Stichprobenerhebung unterstützt. Sie können insbesondere nicht einschränken, wie viel von jeder Datei durch Sensitive Data Protection gescannt und de-identifiziert wird. Wenn Sie die Cloud Data Loss Prevention API verwenden, können Sie bytesLimitPerFile und bytesLimitPerFilePercent nicht im Objekt CloudStorageOptions Ihres DlpJob verwenden.

Außerdem können Sie die maximale Anzahl der zurückzugebenden Ergebnisse nicht festlegen. Wenn Sie die DLP API verwenden, können Sie in Ihrem DlpJob kein FindingLimits-Objekt festlegen.

Anforderung zur Überprüfung von Daten

Wenn Sie Ihren Prüfjob ausführen, prüft Sensitive Data Protection die Daten zuerst gemäß Ihrer Prüfkonfiguration, bevor die De-Identifikation erfolgt. Der Inspektionsprozess kann nicht übersprungen werden.

Anforderungen an die Verwendung von Dateiendungen

Der Schutz sensibler Daten stützt sich auf Dateiendungen, um die Dateitypen der Dateien in Ihrem Eingabeverzeichnis zu identifizieren. Dateien ohne Dateiendung werden möglicherweise nicht anonymisiert, auch wenn sie einen unterstützten Typ haben.

Übersprungene Dateien

Beim De-Identifizieren von Dateien im Speicher werden die folgenden Dateien von Sensitive Data Protection übersprungen:

  • Dateien,die größer als 60.000 KB sind. Wenn Sie große Dateien haben, die dieses Limit überschreiten, sollten Sie sie in kleinere Teile aufteilen.
  • Dateitypen, die auf dieser Seite nicht unter Unterstützte Dateitypen aufgeführt sind.
  • Dateitypen, die Sie bewusst aus der Konfiguration für die De-Identifizierung ausgeschlossen haben. Wenn Sie die DLP API verwenden, werden die Dateitypen, die Sie im Feld file_types_to_transform der Aktion Deidentify Ihres DlpJob ausgeschlossen haben, übersprungen.
  • Dateien, bei denen Transformationsfehler aufgetreten sind.

Reihenfolge der Ausgaberow in anonymisierten Tabellen

Es gibt keine Garantie dafür, dass die Reihenfolge der Zeilen in einer anonymisierten Tabelle mit der Reihenfolge der Zeilen in der Originaltabelle übereinstimmt. Wenn Sie die Originaltabelle mit der anonymisierten Tabelle vergleichen möchten, können Sie sich nicht auf die Zeilennummer verlassen, um die entsprechenden Zeilen zu identifizieren. Wenn Sie Zeilen der Tabellen vergleichen möchten, müssen Sie einen eindeutigen Bezeichner verwenden, um jeden Datensatz zu identifizieren.

Kurzlebige Schlüssel

Wenn Sie eine kryptografische Methode als Transformationsmethode auswählen, müssen Sie zuerst einen zusammengefassten Schlüssel mit Cloud Key Management Service erstellen. Geben Sie diesen Schlüssel dann in Ihrer De-Identifikationsvorlage an. Temporäre (Roh-)Schlüssel werden nicht unterstützt.

Nächste Schritte