Auf dieser Seite wird beschrieben, wie der Schutz sensibler Daten de-identifizierte Kopien von in Cloud Storage gespeicherten Daten erstellen kann. Außerdem werden die Einschränkungen dieses Vorgangs sowie die Punkte aufgeführt, die Sie vor Beginn berücksichtigen sollten.
Informationen zur Verwendung des Schutzes sensibler Daten zum Erstellen de-identifizierter Kopien Ihrer Cloud Storage-Daten finden Sie hier:
- Mit der Google Cloud Console de-identifizierte Kopien der in Cloud Storage gespeicherten Daten erstellen
- Mit der API de-identifizierte Kopien der in Cloud Storage gespeicherten Daten erstellen
Informationen zur De-Identifikation
Bei der De-Identifikation werden identifizierende Informationen aus Daten entfernt. Ziel ist es, die Nutzung und Weitergabe personenbezogener Daten – z. B. Gesundheits-, Finanz- oder demografische 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 De-Identifikationstransformationen beim Schutz sensibler Daten finden Sie in der Transformationsreferenz. Weitere Informationen zum Entfernen sensibler Daten aus Bildern durch den Schutz sensibler Daten finden Sie unter Imageprüfung und -entfernung.
Verwendung dieser Funktion
Diese Funktion ist nützlich, wenn die Dateien, die Sie im Rahmen Ihrer Geschäftstätigkeiten verwenden, sensible Daten wie personenidentifizierbare Informationen enthalten. Mit dieser Funktion können Sie Informationen im Rahmen Ihrer Geschäftsprozesse verwenden und teilen, während vertrauliche Daten verborgen bleiben.
De-Identifikationsprozess
In diesem Abschnitt wird der De-Identifikationsprozess im Abschnitt zum Schutz sensibler Daten für Inhalte in Cloud Storage beschrieben.
Zur Verwendung dieses Features erstellen Sie einen Inspektionsjob (DlpJob
), der für das Erstellen de-identifizierter Kopien der Cloud Storage-Dateien konfiguriert ist.
Der Schutz sensibler Daten scannt die Dateien am angegebenen Speicherort und prüft sie gemäß Ihrer Konfiguration. Bei der Prüfung jeder Datei de-identifiziert der Schutz sensibler Daten 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.
Die neue Datei wird in einem von Ihnen angegebenen Ausgabeverzeichnis gespeichert. Wenn eine Datei im Scan enthalten ist, aber keine Daten Ihren De-Identifikationskriterien entsprechen und bei ihrer 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 den Eingabedateien unterscheidet. In Ihrem Ausgabeverzeichnis erstellt der Schutz sensibler Daten 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 der Schutz sensibler Daten 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.
Access Control Lists (ACLs) auf Dateiebene für die Originaldateien werden unabhängig davon, ob sensible Daten gefunden und de-identifiziert wurden, in die neuen Dateien kopiert. 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 in einem Cloud Storage-Bucket gespeicherte Dateien. Jede Datei wird kopiert, unabhängig davon, ob der Schutz sensibler Daten sensible Daten erkennt. Jede kopierte Datei hat denselben Namen wie das Original.
Preise
Preisinformationen finden Sie unter Daten im Speicher prüfen und umwandeln.
Unterstützte Dateitypen
Durch den Schutz sensibler Daten können die folgenden Dateitypgruppen de-identifiziert werden:
- CSV
- Bild
- Text
- TSV
Standardverhalten für die De-Identifikation
Wenn Sie definieren möchten, wie der Schutz sensibler Daten die Ergebnisse transformiert, können Sie De-Identifikationsvorlagen für die folgenden Dateitypen bereitstellen:
- Unstrukturierte Dateien wie Textdateien mit freiem Text
- Strukturierte Dateien wie CSV-Dateien
- Bilder
Wenn Sie keine De-Identifikationsvorlage angeben, transformiert der Schutz sensibler Daten die Ergebnisse so:
- In unstrukturierten und strukturierten Dateien ersetzt der Schutz sensibler Daten alle Ergebnisse durch den entsprechenden infoType, wie unter Ersetzung von infoTypes beschrieben.
- In Bildern verdeckt der Schutz sensibler Daten alle Ergebnisse mit einer Blackbox.
Einschränkungen und Überlegungen
Beachten Sie die folgenden Punkte, bevor Sie de-identifizierte Kopien von Cloud Storage-Daten erstellen.
Speicherplatz
Bei diesem Vorgang werden nur in Cloud Storage gespeicherte Inhalte unterstützt.
Bei diesem Vorgang wird eine Kopie jeder Datei erstellt, die vom Schutz sensibler Daten geprüft wird. Der Originalinhalt wird nicht verändert oder entfernt. Die kopierten Daten nehmen ungefähr die gleiche Menge an zusätzlichen Speicherplatz ein wie die Originaldaten.
Schreibzugriff auf den Speicher
Da der Schutz sensibler Daten eine Kopie der Originaldateien erstellt, muss der Dienst-Agent Ihres Projekts Schreibzugriff auf den Cloud Storage-Ausgabe-Bucket haben.
Stichprobenerhebung und Ergebnislimits festlegen
Bei diesem Vorgang wird die Stichprobenerhebung nicht unterstützt. Insbesondere lässt sich nicht einschränken, in welchem Umfang bei jeder Datei der Schutz sensibler Daten gescannt und de-identifiziert wird. Wenn Sie also die Cloud Data Loss Prevention API nutzen, können Sie bytesLimitPerFile
und bytesLimitPerFilePercent
nicht im CloudStorageOptions
-Objekt Ihrer DlpJob
verwenden.
Außerdem können Sie die maximale Anzahl von Ergebnissen, die zurückgegeben werden sollen, nicht steuern.
Wenn Sie die DLP API verwenden, können Sie in DlpJob
kein FindingLimits
-Objekt festlegen.
Anforderung zur Datenprüfung
Beim Ausführen Ihres Inspektionsjobs prüft der Schutz sensibler Daten zuerst die Daten gemäß Ihrer Inspektionskonfiguration, bevor er die De-Identifikation ausführt. Die Prüfung kann nicht übersprungen werden.
Vorgabe zur Verwendung von Dateierweiterungen
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 de-identifiziert, selbst wenn diese Dateien einen unterstützten Dateityp haben.
Übersprungene Dateien
Bei der De-Identifikation von Dateien im Speicher überspringt der Schutz sensibler Daten 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 Blöcke aufteilen.
- Nicht unterstützte Dateitypen Eine Liste der unterstützten Dateitypen finden Sie auf dieser Seite unter Unterstützte Dateitypen.
- Dateitypen, die Sie absichtlich 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 AktionDeidentify
IhrerDlpJob
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 der Reihenfolge der Zeilen in der ursprünglichen Tabelle entspricht. 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 jeden Datensatz mit einer eindeutigen Kennung identifizieren.
Transiente Schlüssel
Wenn Sie eine kryptografische Methode als Transformationsmethode auswählen, müssen Sie zuerst mit dem Cloud Key Management Service einen verpackten Schlüssel erstellen. Geben Sie diesen Schlüssel dann in Ihrer De-Identifikationsvorlage an. Transiente Schlüssel (rohe Schlüssel) werden nicht unterstützt.
Nächste Schritte
- In Cloud Storage gespeicherte sensible Daten mithilfe der DLP API de-identifizieren
- In Cloud Storage gespeicherte sensible Daten mit der Google Cloud Console de-identifizieren
- Codelab zum Erstellen einer de-identifizierten Datenkopie in Cloud Storage
- Speicher auf sensible Daten prüfen