De-Identifikation sensibler Cloud Storage-Daten

Auf dieser Seite wird beschrieben, wie mit dem Schutz sensibler Daten de-identifizierte Kopien von Daten erstellt werden können, die in Cloud Storage gespeichert sind. Außerdem werden die Einschränkungen dieses Vorgangs und die Punkte aufgeführt, die Sie vor Beginn berücksichtigen sollten.

Informationen zum Erstellen de-identifizierter Kopien Ihrer Cloud Storage-Daten mit dem Schutz sensibler Daten finden Sie hier:

De-Identifikation

Die De-Identifikation ist der Prozess, bei dem identifizierende Informationen aus Daten entfernt werden. Ziel ist es, die Verwendung und Weitergabe personenbezogener Daten wie Gesundheits-, Finanz- oder demografischen 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 des Schutzes sensibler Daten finden Sie in der Transformationsreferenz. Weitere Informationen dazu, wie sensible Daten aus Bildern entfernt werden, finden Sie unter Bildinspektion und Entfernen von Daten aus Bildern.

Wann sollte diese Funktion verwendet werden?

Diese Funktion ist nützlich, wenn die Dateien, die Sie in Ihrem Unternehmen verwenden, sensible Daten wie personenidentifizierbare Informationen enthalten. Mit dieser Funktion können Sie Informationen im Rahmen Ihrer Geschäftsprozesse verwenden und weitergeben, während sensible Daten ausgeblendet bleiben.

De-Identifikationsprozess

In diesem Abschnitt wird der De-Identifikationsprozess im Rahmen des Schutzes sensibler Daten für Inhalte in Cloud Storage beschrieben.

Wenn Sie diese Funktion verwenden möchten, erstellen Sie einen Prüfjob (DlpJob), der so konfiguriert ist, dass de-identifizierte Kopien der Cloud Storage-Dateien erstellt werden. Der Schutz sensibler Daten scannt die Dateien am angegebenen Speicherort und prüft sie gemäß Ihrer Konfiguration. Bei der Prüfung jeder Datei werden alle Daten, die Ihren Kriterien für sensible Daten entsprechen, de-identifiziert und der Inhalt in eine neue Datei geschrieben. 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 eingeschlossen ist, aber keine Daten Ihren De-Identifikationskriterien entsprechen und keine Fehler bei der Verarbeitung 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 den Schutz sensibler Daten eine Dateistruktur erstellt, die der Dateistruktur des Eingabeverzeichnisses entspricht.

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

Die Zugriffssteuerungslisten (Access Control Lists, ACLs) auf Dateiebene für die ursprünglichen Dateien 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 Vorgang der De-Identifikation für vier Dateien, die in einem Cloud Storage-Bucket gespeichert sind. Jede Datei wird unabhängig davon kopiert, ob der Schutz sensibler Daten sensible Daten erkennt. Jede kopierte Datei hat denselben Namen wie das Original.

De-Identifikation von Dateien, die in Cloud Storage gespeichert sind.
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 dem Schutz sensibler Daten können die folgenden Dateitypgruppen de-identifiziert werden:

  • CSV
  • Bild
  • Text
  • TSV

Standardverhalten der De-Identifikation

Wenn Sie festlegen möchten, wie die Ergebnisse mit dem Schutz sensibler Daten transformiert werden, können Sie Vorlagen zur De-Identifikation für die folgenden Dateitypen bereitstellen:

  • Unstrukturierte Dateien wie Textdateien mit freiem Text
  • Strukturierte Dateien wie CSV-Dateien
  • Images

Wenn Sie keine De-Identifikationsvorlage angeben, werden die Ergebnisse vom Schutz sensibler Daten so transformiert:

  • In unstrukturierten und strukturierten Dateien ersetzt Sensitive Data Protection alle Ergebnisse durch den entsprechenden infoType, wie unter Ersetzen von infoTypes beschrieben.
  • In Bildern werden alle Ergebnisse durch den Schutz sensibler Daten mit einem schwarzen Feld ausgeblendet.

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 vom Schutz sensibler Daten geprüft wird. Die ursprünglichen Inhalte werden dabei 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 beim Schutz sensibler Daten eine Kopie der Originaldateien erstellt wird, muss der Dienstagent Ihres Projekts Schreibzugriff auf den Cloud Storage-Ausgabe-Bucket haben.

Stichprobenerhebung und Limits für Ergebnisse festlegen

Bei diesem Vorgang wird keine Stichprobenerhebung unterstützt. Insbesondere können Sie nicht einschränken, wie viel von jeder Datei mit dem Schutz sensibler Daten gescannt und de-identifiziert wird. Wenn Sie also 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.

Daten müssen geprüft werden

Beim Ausführen des Prüfjobs werden die Daten zuerst gemäß Ihrer Prüfkonfiguration geprüft, bevor die De-Identifikation durchgeführt wird. Der Prüfvorgang kann nicht übersprungen werden.

Verwendung von Dateiendungen

Der Schutz sensibler Daten verwendet Dateiendungen, um die Dateitypen der Dateien in Ihrem Eingabeverzeichnis zu identifizieren. Dateien ohne Dateiendung werden möglicherweise nicht de-identifiziert, auch wenn sie zu den unterstützten Dateitypen gehören.

Übersprungene Dateien

Bei der De-Identifikation 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 Blöcke aufteilen.
  • Dateien mit nicht unterstützten Typen Eine Liste der unterstützten Dateitypen finden Sie auf dieser Seite unter Unterstützte Dateitypen.
  • Dateitypen, die Sie bewusst von der De-Identifikationskonfiguration ausgeschlossen haben. Wenn Sie die DLP API verwenden, werden die Dateitypen, die Sie aus dem Feld file_types_to_transform der Aktion Deidentify Ihrer DlpJob ausgeschlossen haben, übersprungen.
  • 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 die entsprechenden Zeilen nicht anhand der Zeilennummer identifizieren. Wenn Sie Zeilen der Tabellen vergleichen möchten, müssen Sie jeden Datensatz mit einer eindeutigen Kennung identifizieren.

Transiente Schlüssel

Wenn Sie als Transformationsmethode eine kryptografische Methode 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. Transiente (rohe) Schlüssel werden nicht unterstützt.

Nächste Schritte