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 vor dem Start beachten sollten.

Informationen zum Erstellen de-identifizierter Kopien Ihrer Cloud Storage-Daten mit Sensitive Data Protection finden Sie hier:

De-Identifikation

Als De-Identifikation wird der Prozess bezeichnet, 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.

Weitere Informationen zu Transformationen zur De-Identifikation im Rahmen von Sensitive Data Protection finden Sie in der Transformationsreferenz. Weitere Informationen dazu, wie Sensitive Data Protection sensible Daten aus Bildern entfernt, finden Sie unter Bildprüfung und -bearbeitung.

Wann sollte die De-Identifikation von Speicher verwendet werden?

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

  • Anonymisierte Datasets für Nicht-Produktionsumgebungen generieren: Erstellen Sie de-identifizierte Kopien von Produktionsdateien, die in Cloud Storage gespeichert sind, bevor Sie Daten in Entwicklungs-, Test- oder Trainingsumgebungen bereitstellen.
  • Bereinigte Datei-Repositories mit Dritten teilen: Sensible Felder in Bulk-Dokumenten und unstrukturierten Dateien verschleiern und gleichzeitig die ursprüngliche Ordnerhierarchie für externe Geschäftspartner oder Prüfer beibehalten.
  • Datenschutz-Pipelines für aufgenommene Dokumente automatisieren: Transformieren Sie sensible Daten in neu hochgeladenen Dateien in einen bestimmten Ausgabe-Bucket, ohne Quelldateien zu ändern oder vorgelagerte Pipelines zu unterbrechen.
  • Datenstandort und -aufteilung erzwingen: Speichern Sie de-identifizierte Spiegelkopien sensibler Assets in separaten Cloud Storage-Buckets mit unterschiedlichen Identity and Access Management-Zugriffssteuerungen.

De-Identifikationsprozess

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 Inspektionsjob (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 prüft sie gemäß Ihrer Konfiguration. Bei der Prüfung jeder Datei de-identifiziert Sensitive Data Protection alle Daten, die Ihren Kriterien für sensible Daten entsprechen, und schreibt den Inhalt dann in eine neue Datei. Die neue Datei hat immer denselben Dateinamen wie die Originaldatei. Diese neue Datei wird in einem von Ihnen angegebenen Ausgabeverzeichnis gespeichert. Wenn eine Datei in den Scan einbezogen wird, aber keine Daten Ihren De-Identifikationskriterien 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. In Ihrem Ausgabeverzeichnis erstellt Sensitive Data Protection eine Dateistruktur, die die Dateistruktur des Eingabeverzeichnisses widerspiegelt.

Angenommen, Sie legen die folgenden Eingabe- und Ausgabeverzeichnisse fest:

  • 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 de-identifizierte 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 Ausgabe-Bucket aktivieren.

Zugriffssteuerungslisten (Access Control Lists, ACLs) auf Dateiebene für die Originaldateien werden in die neuen Dateien kopiert, unabhängig davon, ob sensible Daten gefunden und de-identifiziert wurden. Wenn der Ausgabe-Bucket 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 de-identifizierten Dateien kopiert.

Das folgende Diagramm zeigt den De-Identifikationsprozess 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-Identifikation von in Cloud Storage gespeicherten Dateien.
De-Identifikation von in Cloud Storage gespeicherten Dateien (zum Vergrößern klicken).

Preise

Preisinformationen finden Sie unter Prüfung und Transformation von Daten im Speicher.

Unterstützte Dateitypen

Sensitive Data Protection kann die folgenden Dateitypgruppen de-identifizieren:

Standardverhalten der De-Identifikation

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

  • Unstrukturierte Dateien, z. B. Textdateien mit Freiformtext
  • Strukturierte Dateien wie CSV-Dateien
  • Bilder

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

  • 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 von Sensitive Data Protection mit einem schwarzen Feld 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 belegen ungefähr denselben zusätzlichen Speicherplatz wie die ursprünglichen Daten.

Schreibzugriff auf den Speicher

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

Stichprobenerhebung und Festlegen von Limits für die Suche

Dieser Vorgang unterstützt keine Stichprobenerhebung. Insbesondere können Sie nicht einschränken, wie viel von jeder Datei von 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 CloudStorageOptions-Objekt Ihrer DlpJob verwenden.

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

Anforderung zur Überprüfung von Daten

Wenn Sie den Inspektionsjob ausführen, prüft Sensitive Data Protection die Daten zuerst gemäß Ihrer Inspektionskonfiguration, bevor die De-Identifikation durchgeführt wird. Der Prüfprozess kann nicht übersprungen werden.

Anforderung zur Verwendung von Dateiendungen

Sensitive Data Protection verwendet Dateiendungen, um die Dateitypen der Dateien in Ihrem Eingabeverzeichnis zu identifizieren. Dateien ohne Dateiendung werden möglicherweise nicht de-identifiziert, auch wenn sie einen unterstützten Dateityp haben.

Übersprungene Dateien

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

  • 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 absichtlich aus der De-Identifizierungskonfiguration ausgeschlossen haben. Wenn Sie die DLP API verwenden, werden die Dateitypen übersprungen, die Sie aus dem Feld file_types_to_transform der Aktion Deidentify Ihrer DlpJob ausgeschlossen haben.
  • Dateien, bei denen Transformationsfehler aufgetreten sind.

Reihenfolge der Ausgabezeilen in de-identifizierten Tabellen

Es gibt keine Garantie dafür, dass die Reihenfolge der Zeilen in einer de-identifizierten Tabelle mit der Reihenfolge der Zeilen in der ursprünglichen Tabelle übereinstimmt. Wenn Sie die ursprüngliche Tabelle mit der de-identifizierten 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 eine eindeutige Kennung verwenden, um jeden Datensatz zu identifizieren.

Kurzlebige Schlüssel

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

Nächste Schritte