In diesem Dokument wird erläutert, wie Sie mit dem Schutz sensibler Daten eine automatisierte Pipeline zur Datentransformation erstellen, um sensible Daten, beispielsweise personenidentifizierbare Informationen, zu de-identifizieren. Mit De-Identifikationstechniken wie der Tokenisierung (Pseudonymisierung) können Sie Ihre Daten weiterhin zusammenführen oder analysieren. Durch die Verschleierung der sensiblen Rohdaten reduzieren Sie gleichzeitig das mit der Verarbeitung der Daten verbundene Risiko. Wenn Sie das Risiko der Verarbeitung großer Mengen sensibler Daten minimieren möchten, können Sie mithilfe einer automatisierten Pipeline zur Datentransformation de-identifizierte Replikate erstellen. Der Schutz sensibler Daten ermöglicht Transformationen wie Entfernen, Maskieren, Tokenisierung, Bucketing und andere Methoden der De-Identifikation. Wenn ein Dataset nicht gekennzeichnet wurde, kann der Schutz sensibler Daten auch mit mehr als 100 integrierten Klassifikatoren auf vertrauliche Informationen überprüft werden.
Dieses Dokument richtet sich an eine technische Zielgruppe, deren Aufgaben in den Bereichen Datensicherheit, Datenverarbeitung oder Datenanalyse liegen. In dieser Anleitung wird vorausgesetzt, dass Sie mit den Themengebieten Datenverarbeitung und Datenschutz vertraut sind, aber Sie müssen kein Experte sein.
Referenzarchitektur
Im folgenden Diagramm wird eine Referenzarchitektur für die Verwendung von Google Cloud-Produkten dargestellt, um sensiblen Datasets mithilfe von De-Identifikationstechniken eine Sicherheitsebene hinzuzufügen.
Die Architektur besteht aus folgenden Komponenten:
Streamingpipeline zur De-Identifikation von Daten: de-identifiziert sensible Daten im Text mithilfe von Dataflow. Sie können die Pipeline für mehrere Transformationen und Anwendungsfälle wiederverwenden.
Konfigurationsverwaltung (Vorlage und Schlüssel für den Schutz sensibler Daten): eine verwaltete De-Identifikationskonfiguration, auf die nur eine kleine Gruppe von Nutzern (z. B. Sicherheitsadministratoren) zugreifen kann. Dadurch soll vermieden werden, dass De-Identifikationsmethoden und Verschlüsselungsschlüssel offengelegt werden.
Pipeline zur Datenvalidierung und Re-Identifikation: validiert Kopien der de-identifizierten Daten und verwendet eine Dataflow-Pipeline, um Daten im großen Maßstab neu zu identifizieren.
Hilfe beim Schutz sensibler Daten
Eine der wichtigsten Aufgaben jedes Unternehmens besteht darin, für die Sicherheit der Daten seiner Nutzer und Mitarbeiter zu sorgen. Google Cloud bietet integrierte Sicherheitsmaßnahmen zur einfacheren Gewährleistung der Datensicherheit. Hierzu gehören u. a. die Verschlüsselung gespeicherter Daten und die Verschlüsselung von Daten bei der Übertragung.
Verschlüsselung inaktiver Daten: Cloud Storage
Datensicherheit ist für die meisten Organisationen von entscheidender Bedeutung. Unbefugter Zugriff auf selbst mäßig sensible Daten kann das Vertrauen, die Beziehungen und den Ruf bei Ihren Kunden schädigen. Als Standardmaßnahme verschlüsselt Google inaktive Daten. So wird standardmäßig jedes Objekt, das in einen Cloud Storage-Bucket hochgeladen wird, mit einem von Google verwalteten Verschlüsselungsschlüssel verschlüsselt. Wenn Ihr Dataset eine bereits vorhandene Verschlüsselungsmethode verwendet und vor dem Hochladen eine nicht standardmäßige Option erforderlich wird, gibt es andere Verschlüsselungsoptionen von Cloud Storage. Weitere Informationen finden Sie unter Datenverschlüsselungsoptionen.
Verschlüsselung während der Übertragung: Dataflow
Wenn Ihre Daten übertragen werden, ist die Verschlüsselung inaktiver Daten nicht aktiviert. Bei der Übertragung werden Daten durch sichere Netzwerkprotokolle geschützt, die als Verschlüsselung während der Übertragung bezeichnet werden. Standardmäßig verwendet Dataflow von Google verwaltete Verschlüsselungsschlüssel. Die mit diesem Dokument verknüpften Anleitungen verwenden eine automatisierte Pipeline, die die von Google verwalteten Standardverschlüsselungsschlüssel verwendet.
Datentransformationen zum Schutz sensibler Daten
Es gibt zwei Haupttypen von Transformationen, die vom Schutz sensibler Daten ausgeführt werden:
Sowohl die Methode recordTransformations als auch infoTypeTransformations können vertrauliche Informationen in Ihren Daten de-identifizieren und verschlüsseln. Sie können beispielsweise die Werte in der Spalte US_SOCIAL_SECURITY_NUMBER so ändern, dass sie nicht identifizierbar sind, oder sie über die Tokenisierung verschleiern. Hierbei wird die referenzielle Integrität aufrechterhalten.
Mit der Methode infoTypeTransformations können Sie nach sensiblen Daten suchen und das Ergebnis transformieren. Wenn Sie beispielsweise unstrukturierte Daten oder Freitextdaten haben, können Sie mit der Methode infoTypeTransformations eine SSN in einem Satz identifizieren und den SSN-Wert verschlüsseln, während der Rest des Textes unverändert bleibt. Sie können auch benutzerdefinierte infoTypes-Methoden definieren.
Mit der Methode recordTransformations können Sie eine Transformationskonfiguration auf jedes Feld anwenden, wenn Sie strukturierte oder tabellarische Daten verwenden. Mit der Methode recordTransformations können Sie dieselbe Transformation auf jeden Wert in diesem Feld anwenden. So können Sie beispielsweise jeden Wert in einer Spalte mit einer SSN-Spalte als Feld- oder Headername hashen oder tokenisieren.
Sie können auch die Methode infoTypeTransformations, die nur für die Werte in den angegebenen Feldern gilt, mit der Methode recordTransformations verwenden. So können Sie beispielsweise eine infoTypeTransformations-Methode innerhalb einer recordTransformations-Methode für das Feld mit dem Namen comments verwenden, um Ergebnisse für US_SOCIAL_SECURITY_NUMBER zu entfernen, die sich im Text im Feld befinden.
In aufsteigender Reihenfolge der Komplexität sind die De-Identifikationsprozesse die folgenden:
- Entfernen: Die sensiblen Inhalte werden entfernt, ohne sie zu ersetzen.
- Maskieren: Die sensiblen Inhalte werden durch feste Zeichen ersetzt.
- Verschlüsselung: Die sensiblen Inhalte werden durch verschlüsselte Strings ersetzt, möglicherweise auch umkehrbar.
Mit durch Kommas getrennten Daten arbeiten
Häufig bestehen Daten aus Datensätzen, die durch ein ausgewähltes Zeichen getrennt sind und feste Typen in jeder Spalte haben – wie z. B. bei einer CSV-Datei. Auf diese Datenklasse können Sie De-Identifikationstransformationen (recordTransformations) direkt anwenden, ohne die Daten zu überprüfen. Sie können beispielsweise davon ausgehen, dass eine Spalte mit dem Label SSN nur SSN-Daten enthält. Sie müssen die Daten nicht überprüfen, um zu erkennen, dass der infoType-Detektor US_SOCIAL_SECURITY_NUMBER ist. Spalten im freien Format mit dem Label Additional Details können jedoch vertrauliche Informationen enthalten. Die Klasse infoType ist hier nicht im Voraus bekannt. Bei einer Spalte im freien Format müssen Sie den infoTypes-Detektor (infoTypeTransformations) überprüfen, bevor Sie De-Identifikationstransformationen anwenden. Mit dem Schutz sensibler Daten können beide Transformationstypen in einer einzigen De-Identifikationsvorlage gleichzeitig vorhanden sein.
Der Schutz sensibler Daten umfasst mehr als 100 integrierte infoTypes-Detektoren.
Sie können auch benutzerdefinierte Typen erstellen oder integrierte infoTypes-Detektoren ändern, um sensible Daten zu finden, die nur für Ihre Organisation bestimmt sind.
Transformationstyp bestimmen
Ob Sie die Methode recordTransformations oder infoTypeTransformations verwenden, hängt von Ihrem Anwendungsfall ab. Da für die Verwendung der Methode infoTypeTransformations mehr Ressourcen erforderlich sind und sie daher kostenintensiver ist, sollten Sie diese Methode nur verwenden, wenn der Datentyp unbekannt ist. Sie können die Kosten für die Ausführung des Schutzes sensibler Daten mit dem Google Cloud-Preisrechner einschätzen.
Als Beispiel für die Transformation bezieht sich dieses Dokument auf ein Dataset, das CSV-Dateien mit festen Spalten enthält, wie in der folgenden Tabelle dargestellt.
| Spaltenname | infoType-Prüfung (benutzerdefiniert oder integriert) |
Transformationstyp Schutz sensibler Daten |
|---|---|---|
Card Number
|
Nicht zutreffend | Deterministische Verschlüsselung (Deterministic Encryption, DE) |
Card Holder's Name
|
Nicht zutreffend | Deterministische Verschlüsselung (Deterministic Encryption, DE) |
Card PIN
|
Nicht zutreffend | Krypto-Hashing |
SSN (Social Security Number)
|
Nicht zutreffend | Maskieren |
Age
|
Nicht zutreffend | Bucketing |
Job Title
|
Nicht zutreffend | Bucketing |
Additional Details
|
Integriert:IBAN_CODE, EMAIL_ADDRESS,
PHONE_NUMBER
Benutzerdefiniert:
ONLINE_USER_ID
|
Ersetzen |
In dieser Tabelle sind die Spaltennamen aufgeführt und es wird beschrieben, welcher Transformationstyp für die jeweilige Spalte erforderlich ist. Die Spalte Card Number enthält beispielsweise Kreditkartennummern, die verschlüsselt werden müssen. Sie müssen jedoch nicht überprüft werden, da der Datentyp (infoType) bekannt ist.
Die einzige Spalte, in der eine Inspektionstransformation empfohlen wird, ist die Spalte Additional Details. Diese Spalte ist frei formatiert und kann personenidentifizierbare Informationen enthalten, die für die Zwecke dieses Beispiels erkannt und de-identifiziert werden sollten.
Die Beispiele in dieser Tabelle stellen fünf verschiedene De-Identifikationstransformationen dar:
Bidirektionale Tokenisierung: ersetzt die ursprünglichen Daten durch ein Token, das deterministisch ist. Hierbei wird die referenzielle Integrität bewahrt. Sie können das Token zum Zusammenführen von Daten bei der Aggregatanalyse verwenden. Mit demselben Schlüssel, mit dem Sie das Token erstellt haben, können Sie die Daten umkehren oder ihre Tokenisierung aufheben. Es gibt zwei Methoden für bidirektionale Tokenisierungen:
- Deterministische Verschlüsselung (Deterministic Encryption, DE): ersetzt die ursprünglichen Daten durch einen Base64-codierten verschlüsselten Wert und behält den ursprünglichen Zeichensatz oder die ursprüngliche Länge nicht bei.
- Formaterhaltende Verschlüsselung mit FFX (Format-Preserving Encryption with FFX, FPE-FFX): ersetzt die ursprünglichen Daten durch ein Token, das mithilfe der formaterhaltenden Verschlüsselung im FFX-Modus erzeugt wurde. Die Länge und der Zeichensatz des Eingabetexts werden bei der FPE-FFX standardmäßig beibehalten. Die Authentifizierung und der Initialisierungsvektor fehlen, was zu einer Längenerweiterung im Ausgabetoken führen kann. Andere Methoden wie DE bieten eine höhere Sicherheit und werden für Anwendungsfälle mit Tokenisierung empfohlen, es sei denn, die Länge und der Zeichensatz müssen unbedingt erhalten bleiben, z. B. für die Abwärtskompatibilität mit Legacy-Datensystemen.
Unidirektionale Tokenisierung mit kryptografischem Hashing: ersetzt den ursprünglichen Wert durch einen Hashwert, wodurch die referenzielle Integrität erhalten bleibt. Im Gegensatz zur bidirektionalen Tokenisierung kann ein unidirektionales Verfahren jedoch nicht rückgängig gemacht werden. Der Hashwert wird durch Verwendung eines SHA-256-basierten Message Authentication Code (HMAC-SHA-256) für den Eingabewert generiert.
Maskieren: ersetzt die ursprünglichen Daten teilweise oder vollständig durch ein angegebenes Zeichen.
Bucketing: ersetzt einen identifizierbaren Wert durch einen weniger eindeutigen Wert.
Ersetzung: ersetzt die ursprünglichen Daten durch ein Token oder den Namen des
infoType, falls dieser erkannt wird.
Methodenwahl
Die Entscheidung, welche die beste Methode zur De-Identifikation ist, kann je nach Anwendungsfall variieren. Wenn beispielsweise eine Legacy-App die de-identifizierten Datensätze verarbeitet, kann die Beibehaltung der Formatierung wichtig sein. Wenn Sie streng formatierte zehnstellige Zahlen verwenden, behält FPE die Länge (10 Ziffern) und den Zeichensatz (numerisch) einer Eingabe zur Unterstützung des Legacy-Systems bei.
Wenn jedoch für die Legacy-Kompatibilität keine strenge Formatierung erforderlich ist, wie dies bei Werten in der Spalte Card Holder's Name der Fall ist, sollten Sie die DE verwenden, da sie eine stärkere Authentifizierungsmethode bietet. Bei sowohl der FPE als auch der DE können die Tokens umgekehrt oder de-tokenisiert werden. Wenn Sie keine De-Tokenisierung benötigen, können Sie mit kryptografischem Hashing für Integrität sorgen, aber die Tokens nicht umkehren.
Andere Methoden wie Maskierung, Bucketing, Datumsverschiebung und Ersetzung eignen sich für Werte, für die die vollständige Integrität nicht erhalten bleiben muss. So können beispielsweise Daten nach dem Bucketing eines Alterswerts (z. B. 27) in eine Altersgruppe (20–30) weiterhin analysiert werden. Gleichzeitig wird aber die Eindeutigkeit reduziert, die zur Identifizierung einer Person führen könnte.
Token-Verschlüsselungsschlüssel
Für kryptografische De-Identifikationstransformationen ist ein kryptografischer Schlüssel, auch Token-Verschlüsselungsschlüssel genannt, erforderlich. Der Token-Verschlüsselungsschlüssel für die Verschlüsselung der De-Identifikation wird auch verwendet, um den ursprünglichen Wert wieder zu identifizieren. Die sichere Erstellung und Verwaltung von Token-Verschlüsselungsschlüsseln wird in diesem Dokument nicht behandelt. Es gilt jedoch einige wichtige Prinzipien zu beachten, auf die später in den zugehörigen Anleitungen eingegangen wird:
- Vermeiden Sie es, Klartextschlüssel in der Vorlage zu verwenden. Nutzen Sie stattdessen Cloud KMS, um einen verpackten Schlüssel zu erstellen.
- Verwenden Sie für jedes Datenelement separate Token-Verschlüsselungsschlüssel, um das Risiko einer Manipulation von Schlüsseln zu verringern.
- Rotieren Sie die Token-Verschlüsselungsschlüssel. Obwohl Sie den verpackten Schlüssel rotieren können, wird durch die Rotation des Token-Verschlüsselungsschlüssels die Integrität der Tokenisierung beeinträchtigt. Wenn der Schlüssel rotiert wird, müssen Sie das gesamte Dataset neu tokenisieren.
Vorlagen für den Schutz sensibler Daten
Verwenden Sie bei umfangreichen Bereitstellungen Vorlagen zum Schutz sensibler Datenschutz um Folgendes zu erreichen:
- Aktivieren Sie die Sicherheitssteuerung mit der Identitäts- und Zugriffsverwaltung (IAM).
- Konfigurationsinformationen und deren De-Identifikationsmethode von der Implementierung Ihrer Anfragen entkoppeln
- Eine Reihe von Transformationen wiederverwenden. Sie können die De-Identifikations- und Re-Identifikationsvorlagen für mehrere Datasets verwenden.
BigQuery
Die letzte Komponente der Referenzarchitektur ist das Anzeigen und Arbeiten mit den de-identifizierten Daten in BigQuery. BigQuery ist das Data Warehouse-Tool von Google, das eine serverlose Infrastruktur, BigQuery ML und die Möglichkeit umfasst, den Schutz sensibler Daten als natives Tool auszuführen. In der folgenden Referenzarchitektur dient BigQuery als Data Warehouse für die de-identifizierten Daten und als Backend für eine automatisierte Pipeline zur Daten-Re-Identifikation, die Daten über Pub/Sub freigeben kann.
Nächste Schritte
- Informationen zur Verwendung des Schutzes sensibler Daten zum Prüfen von Speicher und Datenbanken auf sensible Daten.
- Weitere Informationen zur Mustererkennung.
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center