De-identifizierte Daten in BigQuery validieren und personenbezogene Daten neu identifizieren

In dieser Anleitung wird gezeigt, wie Sie das Beispiel-Dataset validieren, das Sie in der Anleitung Automatische Dataflow-Pipeline zur De-Identifikation eines Datasets personenbezogener Daten ausführen de-identifiziert haben. Nach der Validierung identifizieren Sie die Daten mithilfe der Cloud DLP-Vorlagen neu, die zuvor verwendet wurden, um personenbezogene Daten zu de-identifizieren.

Dieses Dokument ist Teil einer Reihe:

In dieser Anleitung wird davon ausgegangen, dass Sie mit Shell-Skripts, SQL, BigQuery und Dataflow vertraut sind.

Referenzarchitektur

Diese Anleitung erläutert die Datenvalidierungs- und Re-Identifikationspipeline, die in der folgenden Abbildung dargestellt ist.

Architektur der Re-Identifikationspipeline

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

Ziele

  • De-identifiziertes Dataset in BigQuery mithilfe von Standard-SQL validieren
  • Daten mithilfe einer Dataflow-Pipeline neu identifizieren

Kosten

In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Nach Abschluss dieser Anleitung können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Vorbereitung

  1. Absolvieren Sie Teil 2 der Reihe.
  2. Absolvieren Sie Teil 3 der Reihe.

De-identifiziertes Dataset in BigQuery validieren

Sie prüfen, ob die Daten in BigQuery de-identifizierte Daten enthalten, damit sie sicher freigegeben werden können, ohne personenbezogene Daten offenzulegen. Da die automatisierte Pipeline eine BigQuery-Tabelle anhand der CSV-Beispieldateien in der vorherigen Anleitung erstellt hat, können Sie die Daten durch einen Vergleich der Tabellen und Schemas in BigQuery validieren.

  1. Blenden Sie in Cloud Shell die Kopfzeile der CSV-Datei ein, mit der Sie das Schema erstellt haben:

    head -1 solution-test/CCRecords_1564602825.csv
    

    Die Ausgabe sieht so aus:

    ID,Card Type Code,Card Type Full Name,Issuing Bank,Card Number,Card Holder's Name,Issue Date,Expiry Date,Billing Date,Card PIN,Credit Limit,Age,SSN,JobTitle,Additional Details
    
  2. Rufen Sie in der Cloud Console die BigQuery-Seite des Abfrageeditors auf.

    Zum Abfrageeditor

  3. Führen Sie im Abfrageeditor die folgende Abfrage aus, um das Schema mit der Kopfzeile der CSV-Datei zu vergleichen:

    select table_name, column_name
    from `deid_dataset.INFORMATION_SCHEMA.COLUMNS`
    WHERE table_name="CCRecords_1564602825"
    

    Die Ausgabe sieht so aus:

    Ausgabe der Abfrage in einer Tabelle mit beschrifteten Spaltennamen

    Die Spaltennamen enthalten keine Leerzeichen, da durch die Pipeline dafür gesorgt wird, dass die Spalten- und Tabellennamen gemäß der BigQuery-Namenskonvention nur gültige Zeichen enthalten.

  4. Prüfen Sie, ob die Anzahl der Zeilen in der Tabelle 100.000 beträgt:

    select count(*) as number_of_rows
    from `deid_dataset.CCRecords_*` LIMIT 1
    

    In der Ausgabe enthält die Spalte number_of_rows 100000 statt 100001. In der CSV-Datei ist ein Header-Datensatz enthalten, der nicht in der Anzahl der Tabellenzeilen berücksichtigt ist.

    Ausgabe mit der Anzahl der Zeilen

  5. Prüfen Sie, ob die Bucketing-Transformation erfolgreich auf die Spalte JobTitle angewendet wurde:

    select JobTitle, count(*) as number_of_records_found
    from `deid_dataset.CCRecords_1564602825`
    group by JobTitle
    

    In der Ausgabe werden die Werte für JobTitle (Stellenbezeichnung) in drei allgemeine Gruppen unterteilt: Executive, Engineer und Manager.

    Ausgabe mit den Gruppierung nach Stellenbezeichnung

  6. Prüfen Sie, ob die Werte in der Spalte Age (Alter) in sechs verschiedene Gruppen von 60 bis 20 Jahren zusammengefasst wurden:

    select Age, count(*) as number_of_records_found
    from `deid_dataset.CCRecords_1564602825`
    group by Age
    order by Age desc
    

    Die Ausgabe sieht so aus:

    Ausgabe mit Altersgruppierungen

    Durch Zusammenfassen der Altersangaben und Stellenbezeichnungen in diesen Kategorien lässt sich die De-Identifikation personenbezogener Daten weiter vereinfachen. Stellen Sie sich beispielsweise einen bekannten jungen CEO in einem Start-up-Unternehmen vor, der einfach erkannt werden kann. Diese Person im Dataset lässt sich anhand der Quasi-Kennungen (Stellenbezeichnung und Alter) aus dem ursprünglichen Dataset ermitteln. Eine Bucketing-Transformation erschwert es nun, diese Person in den de-identifizierten Kopien des Datasets zu identifizieren.

  7. Prüfen Sie die Maskierungstransformation für die SSN:

    select SSN
    from `deid_dataset.CCRecords_*`
    where regexp_contains(SSN, "@*")
    

    In der Ausgabe sind die ersten fünf Stellen aller SSN-Einträge maskiert:

    Ausgabe der maskierten SSN

  8. Prüfen Sie, ob die kryptografische Transformation die deterministische Verschlüsselung für die Einträge card_holders_name, card_number und card_pin verwendet hat:

    select card_holders_name, card_number, card_pin
    from `deid_dataset.CCRecords_*`
    limit 1
    

    In der Ausgabe werden alle drei Einträge durch einen base64-codierten verschlüsselten String ersetzt:

    Ausgabe mit verschlüsselten Kartendetails

  9. Prüfen Sie, ob die Transformation infoType auf die Spalte Additional Details angewendet wurde:

    select additional_details
    from `deid_dataset.CCRecords_*`
    where regexp_contains(additional_details, r'(IBAN_CODE+)') or regexp_contains(additional_details, r'(EMAIL_ADDRESS+)')or regexp_contains(additional_details, r'(PHONE_NUMBER+)')or regexp_contains(additional_details, r'(ONLINE_USER_ID+)')
    

    In der Ausgabe werden sensible Werte durch Platzhalterwerte wie [IBAN_CODE], [EMAIL_ADDRESS], [PHONE_NUMBER,] und [ONLINE_USER_ID] ersetzt:

    Ausgabe mit Platzhalterwerten

  10. Fragen Sie die de-identifizierten Kopien des Datasets nach der ID 76901 ab:

    select * from `deid_dataset.CCRecords_1564602825` where id='76901'
    

    Die Ausgabe zeigt die folgenden Werte:

    "ID": "76901"
    "Card_Type_Code": "AX"
    "Card_Type_Full_Name": "American Express"
    "Issuing_Bank": "American Express"
    "Card_Number": "encrypted value"
    "Card_Holders_Name": "encrypted value"
    "Issue_Date": "03/2013"
    "Expiry_Date": "03/2015"
    "Billing_Date": "14"
    "Card_PIN": "encrypted value"
    "Credit_Limit": "57000"
    "Age": "40"
    "SSN": "***-**-9395"
    "JobTitle": "Manager"
    "Additional_Details": "[IBAN_CODE][PHONE_NUMBER] [EMAIL_ADDRESS] 102-326-2388 hugedomains.com Maggio[ONLINE_USER_ID]"
    
  11. Vergleichen Sie in Cloud Shell für die ID 76901 die Ausgabe des vorherigen Schritts mit dem ursprünglichen Dataset in der CSV-Datei:

    awk -F "," '$1 == 76901' solution-test/CCRecords_1564602825.csv
    

    Die Ausgabe sieht so aus:

    76901,AX,American Express,American Express,376467075604410,Francis U Riggs,03/2013,03/2015,14,7425,57000,43,623-12-9395,Product Manager,ES20 6871 8240 0493 0298 3587 dsumpton1nc4@reddit.com 102-326-2388 hugedomains.com Maggio:5282194096147081
    

Dataset aus BigQuery neu identifizieren

Schließlich können Sie die Daten mit den ursprünglichen Werten neu identifizieren. Dazu verwenden Sie die DLP-Vorlagen, die für die De-Identifikation genutzt wurden. Zur Re-Identifikation der Daten verwenden Sie eine automatisierte Dataflow-Pipeline, um das Dataset im großen Maßstab neu zu identifizieren. Diese Re-Identifikation ist hilfreich, wenn der Token-Verschlüsselungsschlüssel (TEK) rotiert werden muss. Sie können das Dataset vor der Schlüsselrotation neu identifizieren und dann wieder mit dem neuen TEK tokenisieren.

  1. Erstellen Sie in Cloud Shell ein Pub/Sub-Thema, in dem die re-identifizierten Werte veröffentlicht werden:

    export TOPIC_ID="reid-topic"
    gcloud pubsub topics create ${TOPIC_ID}
    
  2. Erstellen Sie ein Pub/Sub-Abo für das Thema:

    export SUBSCRIPTION_ID="reid-subscription"
    gcloud pubsub subscriptions create ${SUBSCRIPTION_ID} --topic=${TOPIC_ID}
    
  3. Exportieren Sie die BigQuery-SQL-Abfrage:

    export QUERY='select id,card_number,card_holders_name
    from `deid_dataset.CCRecords_1564602825`
    where safe_cast(credit_limit as int64)>100000 and safe_cast(age as int64)>50
    group by id,card_number,card_holders_name limit 10'
    

    Für diese Anleitung müssen Sie die Kartennummer und den Namen des Karteninhabers für alle Personen, die mindestens 50 Jahre alt sind und ein Kreditlimit von mehr als 100.000 US-Dollar haben, neu identifizieren.

  4. Laden Sie die Abfrage in den Datenspeicher-Bucket hoch:

      cat << EOF | gsutil cp - gs://${DATA_STORAGE_BUCKET}/reid_query.sql
      ${QUERY}
      EOF
    
  5. Lösen Sie die Pipeline aus:

    gcloud beta dataflow flex-template run "dlp-reid-demo" --project=${PROJECT_ID} \
        --region=${REGION} \
        --template-file-gcs-location=gs://dataflow-dlp-solution-sample-data/dynamic_template_dlp_v2.json --  parameters=^~^streaming=true~enableStreamingEngine=true~tempLocation=gs://${DATAFLOW_TEMP_BUCKET}/temp~numWorkers=1~maxNumWorkers=2 ~runner=DataflowRunner~tableRef=${PROJECT_ID}:deid_dataset.CCRecords_1564602825~dataset=deid_dataset~autoscalingAlgorithm=THROUGHPUT_BASED~workerMachineType=n1-highmem-8 ~topic=projects/${PROJECT_ID}/topics/${TOPIC_ID}~deidentifyTemplateName=${REID_TEMPLATE_NAME} ~DLPMethod=REID~keyRange=1024~queryPath=gs://${DATA_STORAGE_BUCKET}/reid_query.sql
    
  6. Rufen Sie zur Überwachung der Pipeline in der Cloud Console die Seite Dataflow auf.

    Zu Dataflow

    Nach einigen Minuten ist die Pipeline erfolgreich ausgeführt. Es wird dann Folgendes angezeigt:

    Erfolgreicher Abschluss der Pipeline mit dem Jobstatus

  7. Rufen Sie in Cloud Shell zur Validierung der neu identifizierten Daten einen beliebigen Datensatz vom Pub/Sub-Abonnenten ab:

    gcloud pubsub subscriptions pull ${SUBSCRIPTION_ID} \
        --auto-ack --limit 1000 --project ${PROJECT_ID} >> re-id-data.txt
    

    Die Ausgabe zeigt, dass die Daten erfolgreich im ursprünglichen Format neu identifiziert wurden:

    cat re-id-data.txt
    

    Diese Ausgabe sieht in etwa so aus:

    {"id":"17880","Card Number":"6558977436350773","Card Holder's Name":"Elden E Courtright"}
    {"id":"57055","Card Number":"3529749048585358","Card Holder's Name":"Francisco Duffy"}
    {"id":"31487","Card Number":"6227182611813833","Card Holder's Name":"Leslie C Wade"}
    {"id":"38521","Card Number":"36533383873740","Card Holder's Name":"Laura Z Thomas"}
    {"id":"81585","Card Number":"3569920557158538","Card Holder's Name":"Kelly Reed"}
    {"id":"96408","Card Number":"340687318048371","Card Holder's Name":"Ignacio V Pisano"}
    

Bereinigen

Am einfachsten können Sie die Abrechnung deaktivieren, wenn Sie das Cloud-Projekt löschen, das Sie für die Anleitung erstellt haben. Alternativ haben Sie die Möglichkeit, die einzelnen Ressourcen zu löschen.

Projekt löschen

  1. Wechseln Sie in der Cloud Console zur Seite Ressourcen verwalten.

    Zur Seite "Ressourcen verwalten"

  2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen .
  3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Beenden, um das Projekt zu löschen.

Weitere Informationen