Ce pipeline Dataflow utilise la protection des données sensibles pour détecter les données sensibles, telles que les informations permettant d'identifier personnellement l'utilisateur, puis marque les résultats dans Data Catalog.
La solution décrite dans le présent document s'appuie sur l'architecture de la solution de tokenisation basée sur des fichiers décrite dans le document associé : Tokeniser automatiquement les données sensibles basées sur des fichiers à l'aide de la protection des données sensibles, Cloud Key Management Service et Dataflow. La principale différence entre les deux documents est que le présent document décrit une solution qui crée également une entrée Data Catalog avec un schéma des tags de source et de sensibilité des données pour les résultats de la protection des données sensibles. Il permet également d'inspecter des bases de données relationnelles à l'aide de connexions de JDBC (connectivité de base de données Java).
Ce document est destiné à un public technique dont les responsabilités couvrent la sécurité des données, leur gouvernance, leur traitement et leur analyse. Dans le présent document, nous partons du principe que vous connaissez bien les principes de base du traitement et de la confidentialité des données, sans être un expert. Nous supposons également que vous maîtrisez les scripts de shell et que vous avez une connaissance de base de Google Cloud.
Architecture
Cette architecture définit un pipeline qui effectue les actions suivantes :
- Extrait les données d'une base de données relationnelle en utilisant JDBC.
- Échantillonne les enregistrements en utilisant la clause
LIMITde la base de données. - Traite les enregistrements via l'API Cloud Data Loss Prevention (partie intégrante de la protection des données sensibles) pour identifier les catégories de sensibilité.
- Enregistre les résultats dans une table BigQuery et Data Catalog.
Le schéma suivant illustre les actions effectuées par le pipeline :
La solution utilise des connexions JDBC pour accéder aux bases de données relationnelles. Si vous utilisez des tables BigQuery en tant que source de données, la solution utilise l'API BigQuery Storage pour améliorer les temps de chargement.
Le pipeline sample-and-identify génère les fichiers suivants dans Cloud Storage :
- Schéma Avro (équivalent) du schéma de la source
- Des données
infoTypesdétectées pour chacune des colonnes d'entrée (PERSON_NAME,PHONE_NUMBERetSTREET_ADDRESS)
Cette solution utilise l'aplatissement d'enregistrements pour gérer les champs imbriqués et répétés dans les enregistrements.
Objectifs
- Créer des tags et un groupe d'entités Data Catalog
- Déployer le pipeline d'échantillonnage et d'identification
- Créer une entité Data Catalog personnalisée
- Appliquer des tags de sensibilité à une entité Data Catalog personnalisée
- Vérifier que les données sur les tags de sensibilité se trouvent également dans BigQuery
Coûts
Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :
Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.
Avant de commencer
- Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.
-
Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.
-
Vérifiez que la facturation est activée pour votre projet Google Cloud.
-
Activer les API Cloud Build, DLP API, Cloud SQL, Cloud Storage, Compute Engine, Dataflow, Data Catalog, and Secret Manager.
-
Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.
-
Vérifiez que la facturation est activée pour votre projet Google Cloud.
-
Activer les API Cloud Build, DLP API, Cloud SQL, Cloud Storage, Compute Engine, Dataflow, Data Catalog, and Secret Manager.
-
Dans la console Google Cloud, activez Cloud Shell.
En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.
Configurer votre environnement
Dans Cloud Shell, clonez le dépôt source et accédez au répertoire des fichiers clonés :
git clone https://github.com/GoogleCloudPlatform/auto-data-tokenize.git cd auto-data-tokenize/Utilisez un éditeur de texte pour modifier le script
set_variables.shafin de définir les variables d'environnement requises. Ignorez les autres variables du script. Elles ne sont pas pertinentes dans ce document.# The Google Cloud project to use: export PROJECT_ID="PROJECT_ID" # The Compute Engine region to use for running dataflow jobs and create a # temporary storage bucket: export REGION_ID= "REGION_ID" # The Cloud Storage bucket to use as a temporary bucket for Dataflow: export TEMP_GCS_BUCKET="CLOUD_STORAGE_BUCKET_NAME" # Name of the service account to use (not the email address) # (For example, tokenizing-runner): export DLP_RUNNER_SERVICE_ACCOUNT_NAME="DLP_RUNNER_SERVICE_ACCOUNT_NAME" # Entry Group ID to use for creating/searching for Entries # in Data Catalog for non-BigQuery entries. # The ID must begin with a letter or underscore, contain only English # letters, numbers and underscores, and have 64 characters or fewer. export DATA_CATALOG_ENTRY_GROUP_ID="DATA_CATALOG_ENTRY_GROUP_ID" # The Data Catalog Tag Template ID to use # for creating sensitivity tags in Data Catalog. # The ID must contain only lowercase letters (a-z), numbers (0-9), or # underscores (_), and must start with a letter or underscore. # The maximum size is 64 bytes when encoded in UTF-8 export INSPECTION_TAG_TEMPLATE_ID="INSPECTION_TAG_TEMPLATE_ID"
Remplacez les éléments suivants :
- PROJECT_ID : ID de votre projet
- REGION_ID : région contenant votre ou vos buckets de stockage. Sélectionnez un emplacement situé dans une région Data Catalog.
- CLOUD_STORAGE_BUCKET_NAME : nom de votre bucket de stockage.
- DLP_RUNNER_SERVICE_ACCOUNT_NAME : nom de votre compte de service.
- DATA_CATALOG_ENTRY_GROUP_ID : nom de votre groupe d'entrées du catalogue de données autre que BigQuery.
- INSPECTION_TAG_TEMPLATE_ID : nom que vous avez donné à votre modèle de tag pour Data Catalog.
Exécutez le script permettant de définir les variables d'environnement :
source set_variables.sh
Créer des ressources
L'architecture décrite dans ce document utilise les ressources suivantes :
- Un compte de service permettant d'exécuter des pipelines Dataflow, pour bénéficier d'un contrôle d'accès précis
- Un bucket Cloud Storage pour stocker les données temporaires et tester les données
- Un modèle de tag Data Catalog pour associer des tags de sensibilité aux entrées
- Une instance MySQL sur Cloud SQL en tant que source JDBC
Créer des comptes de service
Nous vous recommandons d'exécuter des pipelines avec un contrôle d'accès précis afin d'améliorer le partitionnement des accès. Si votre projet ne possède pas de compte de service créé par l'utilisateur, créez-en un.
Dans Cloud Shell, créez un compte de service à utiliser comme compte de service de contrôleur géré par l'utilisateur pour Dataflow :
gcloud iam service-accounts create ${DLP_RUNNER_SERVICE_ACCOUNT_NAME} \ --project="${PROJECT_ID}" \ --description="Service Account for Sampling and Cataloging pipelines." \ --display-name="Sampling and Cataloging pipelines"Créez un rôle personnalisé avec les autorisations requises pour accéder à la protection des données sensibles, Dataflow, Cloud SQL et Data Catalog :
export SAMPLING_CATALOGING_ROLE_NAME="sampling_cataloging_runner" gcloud iam roles create ${SAMPLING_CATALOGING_ROLE_NAME} \ --project="${PROJECT_ID}" \ --file=tokenizing_runner_permissions.yamlAppliquez le rôle personnalisé et le rôle de nœud de calcul Dataflow au compte de service pour lui permettre de s'exécuter en tant que nœud de calcul Dataflow :
gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${DLP_RUNNER_SERVICE_ACCOUNT_EMAIL}" \ --role=projects/${PROJECT_ID}/roles/${SAMPLING_CATALOGING_ROLE_NAME} gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${DLP_RUNNER_SERVICE_ACCOUNT_EMAIL}" \ --role=roles/dataflow.worker
Créer le bucket Cloud Storage
Dans Cloud Shell, créez un bucket Cloud Storage pour stocker les données de test et en tant qu'emplacement de préproduction Dataflow :
gsutil mb -p ${PROJECT_ID} -l ${REGION_ID} "gs://${TEMP_GCS_BUCKET}"
Créer un groupe d'entrées Data Catalog
Data Catalog gère une liste d'entrées qui représentent des ressources Google Cloud ou d'autres ressources. Les entrées sont organisées en groupes d'entrées. Un groupe d'entrées implicite existe pour BigQuery (@bigquery). Vous devez créer des groupes d'entrées pour d'autres types de ressources. Pour en savoir plus sur les entrées de Data Catalog, consultez la section Afficher des fichiers stockés dans Cloud Storage avec des entrées d'ensembles de fichiers.
Dans Data Catalog, un groupe d'entrées ressemble à un dossier contenant des entrées. Une entrée représente un élément de données.
Dans Cloud Shell, créez un groupe d'entrées dans lequel le pipeline peut ajouter une entrée pour votre table MySQL :
gcloud data-catalog entry-groups create \ "${DATA_CATALOG_ENTRY_GROUP_ID}" \ --project="${PROJECT_ID}" \ --location="${REGION_ID}"
Créer le modèle de tag d'inspection
Dans Cloud Shell, créez un modèle de tag Data Catalog pour activer les entrées de tag avec des informations de sensibilité à l'aide de la protection des données sensibles :
gcloud data-catalog tag-templates create ${INSPECTION_TAG_TEMPLATE_ID} \ --project="${PROJECT_ID}" \ --location="${REGION_ID}" \ --display-name="Auto DLP sensitive categories" \ --field=id=infoTypes,type=string,display-name="DLP infoTypes",required=TRUE \ --field=id=inspectTimestamp,type=timestamp,display-name="Inspection run timestamp",required=TRUE
Créer une table de résultats d'inspection dans BigQuery
Dans Cloud Shell, créez une table BigQuery permettant de stocker les résultats agrégés provenant de la protection des données sensibles :
bq mk --dataset \ --location="${REGION_ID}" \ --project_id="${PROJECT_ID}" \ inspection_results bq mk --table \ --project_id="${PROJECT_ID}" \ inspection_results.SensitivityInspectionResults \ inspection_results_bigquery_schema.json
Configurer une instance MySQL sur Cloud SQL
Pour la source de données, vous utilisez une instance Cloud SQL.
Dans Cloud Shell, instanciez une instance MySQL sur Cloud SQL et chargez-la avec des exemples de données :
export SQL_INSTANCE="mysql-autodlp-instance" export SQL_ROOT_PASSWORD="root1234" gcloud sql instances create "${SQL_INSTANCE}" \ --project="${PROJECT_ID}" \ --region="${REGION_ID}" \ --database-version=MYSQL_5_7 \ --root-password="${SQL_ROOT_PASSWORD}"Enregistrez le mot de passe de la base de données dans Secret Manager.
Le mot de passe de la base de données et les autres informations secrètes ne doivent pas être stockés ni enregistrés. Secret Manager vous permet de stocker et de récupérer ces secrets de manière sécurisée.
Stockez le mot de passe racine de la base de données MySQL en tant que secret cloud :
export SQL_PASSWORD_SECRET_NAME="mysql-password" printf $SQL_ROOT_PASSWORD | gcloud secrets create "${SQL_PASSWORD_SECRET_NAME}" \ --data-file=- \ --locations="${REGION_ID}" \ --replication-policy="user-managed" \ --project="${PROJECT_ID}"
Copier les données de test sur l'instance Cloud SQL
Les données de test sont un ensemble de données de démonstration contenant 5 000 prénoms et noms générés de manière aléatoire ainsi que des numéros de téléphone de style américain. La table demonstration-dataset contient quatre colonnes : row_id, person_name, contact_type et contact_number. Vous pouvez également utiliser votre propre ensemble de données. Si vous utilisez votre propre ensemble de données, n'oubliez pas de modifier les valeurs suggérées dans la section Vérifier dans BigQuery de ce document. Pour copier l'ensemble de données de démonstration fourni (contacts5k.sql.gz) dans votre instance Cloud SQL, procédez comme suit :
Dans Cloud Shell, copiez l'exemple d'ensemble de données dans Cloud Storage pour la préproduction dans Cloud SQL :
gsutil cp contacts5k.sql.gz gs://${TEMP_GCS_BUCKET}Créez une base de données dans l'instance Cloud SQL :
export DATABASE_ID="auto_dlp_test" gcloud sql databases create "${DATABASE_ID}" \ --project="${PROJECT_ID}" \ --instance="${SQL_INSTANCE}"Attribuez le rôle "Administrateur des objets de l'espace de stockage" à votre compte de service Cloud SQL afin qu'il puisse accéder à l'espace de stockage :
export SQL_SERVICE_ACCOUNT=$(gcloud sql instances describe "${SQL_INSTANCE}" --project="${PROJECT_ID}" | grep serviceAccountEmailAddress: | sed "s/serviceAccountEmailAddress: //g") gsutil iam ch "serviceAccount:${SQL_SERVICE_ACCOUNT}:objectAdmin" \ gs://${TEMP_GCS_BUCKET}Charger les données dans une nouvelle table :
gcloud sql import sql "${SQL_INSTANCE}" \ "gs://${TEMP_GCS_BUCKET}/contacts5k.sql.gz" \ --project="${PROJECT_ID}" \ --database="${DATABASE_ID}"Pour en savoir plus sur l'importation de données dans Cloud SQL, consultez la page Bonnes pratiques pour l'importation et l'exportation de données.
Compiler les modules
Dans Cloud Shell, compilez les modules pour créer les exécutables permettant de déployer le pipeline d'échantillonnage et d'identification ainsi que le pipeline de tokenisation :
./gradlew clean buildNeeded shadowJar -x testVous pouvez également supprimer l'option
-x testpour exécuter le test unitaire et le test d'intégration. Silibncurses5n'est pas déjà installé, installez-le dans Cloud Shell avec :sudo apt-get install libncurses5.
Exécuter le pipeline d'échantillonnage et d'identification
Le pipeline d'échantillonnage et d'identification de la protection des données sensibles effectue les tâches ci-dessous dans l'ordre suivant :
- Extrait les enregistrements de la source fournie. Par exemple, la méthode d'identification de la protection des données sensibles n'accepte que les tables plates. Le pipeline regroupe donc les enregistrements Avro, Parquet ou BigQuery, car ces enregistrements peuvent contenir des champs imbriqués et répétés.
- Échantillonne les colonnes individuelles pour les échantillons requis, à l'exclusion des valeurs
nullou vides. - Identifie les données
infoTypessensibles à l'aide de la protection des données sensibles, en regroupant les échantillons dans des tailles de lot acceptables pour la protection des données sensibles (< 500 ko et < 50 000 valeurs). - Écrit des rapports dans Cloud Storage et BigQuery pour référence ultérieure
- Crée des entités Data Catalog lorsque vous fournissez des informations sur le modèle de tag et les groupes d'entrées. Lorsque vous fournissez ces informations, le pipeline crée des tags de sensibilité pour les entrées Data Catalog dans les colonnes correspondantes.
Créer un modèle Flex Dataflow
Les modèles Flex Dataflow vous permettent d'utiliser la console Google Cloud, Google Cloud CLI ou les appels d'API REST pour configurer et exécuter vos pipelines sur Google Cloud. Ce document fournit des instructions pour la console Google Cloud. Les modèles classiques sont organisés sous forme de graphiques d'exécution sur Cloud Storage, tandis que les modèles Flex regroupent le pipeline en tant qu'image de conteneur dans le Container Registry de votre projet. Les modèles Flex vous permettent de dissocier les compilations et les pipelines, et de les intégrer à des systèmes d'orchestration pour les exécutions programmées de pipelines. Pour en savoir plus sur les modèles Flex Dataflow, consultez la page Évaluer le type de modèle à utiliser.
Les modèles Flex Dataflow séparent les étapes de compilation et de préproduction des étapes en cours d'exécution. Pour ce faire, ils peuvent lancer un pipeline Dataflow à partir d'un appel d'API et de Cloud Composer à l'aide du module DataflowStartFlexTemplateOperator.
Dans Cloud Shell, définissez le site où stocker le fichier de spécification du modèle contenant les informations nécessaires à l'exécution de la tâche Dataflow :
export FLEX_TEMPLATE_PATH="gs://${TEMP_GCS_BUCKET}/dataflow/templates/sample-inspect-tag-pipeline.json" export FLEX_TEMPLATE_IMAGE="us.gcr.io/${PROJECT_ID}/dataflow/sample-inspect-tag-pipeline:latest"Créez le modèle Flex Dataflow :
gcloud dataflow flex-template build "${FLEX_TEMPLATE_PATH}" \ --image-gcr-path="${FLEX_TEMPLATE_IMAGE}" \ --service-account-email="${DLP_RUNNER_SERVICE_ACCOUNT_EMAIL}" \ --sdk-language="JAVA" \ --flex-template-base-image=JAVA11 \ --metadata-file="sample_identify_tag_pipeline_metadata.json" \ --jar="build/libs/auto-data-tokenize-all.jar" \ --env="FLEX_TEMPLATE_JAVA_MAIN_CLASS=\"com.google.cloud.solutions.autotokenize.pipeline.DlpInspectionPipeline\""
Exécuter le pipeline
Le pipeline d'échantillonnage et d'identification extrait le nombre d'enregistrements spécifié par la valeur sampleSize. Il aplatit ensuite chaque enregistrement et identifie les champs infoTypes en utilisant la protection des données sensibles (pour identifier les types d'informations sensibles). Les valeurs infoTypes sont comptabilisées, puis agrégées par nom de colonne et par champ infoType pour créer un rapport de sensibilité.
Dans Cloud Shell, lancez le pipeline d'échantillonnage et d'identification pour identifier les colonnes sensibles dans la source de données :
export CLOUD_SQL_JDBC_CONNECTION_URL="jdbc:mysql:///${DATABASE_ID}?cloudSqlInstance=${PROJECT_ID}%3A${REGION_ID}%3A${SQL_INSTANCE}&socketFactory=com.google.cloud.sql.mysql.SocketFactory" gcloud dataflow flex-template run "sample-inspect-tag-`date +%Y%m%d-%H%M%S`" \ --template-file-gcs-location "${FLEX_TEMPLATE_PATH}" \ --region "${REGION_ID}" \ --service-account-email "${DLP_RUNNER_SERVICE_ACCOUNT_EMAIL}" \ --staging-location "gs://${TEMP_GCS_BUCKET}/staging" \ --worker-machine-type "n1-standard-1" \ --parameters sampleSize=2000 \ --parameters sourceType="JDBC_TABLE" \ --parameters inputPattern="Contacts" \ --parameters reportLocation="gs://${TEMP_GCS_BUCKET}/auto_dlp_report/" \ --parameters reportBigQueryTable="${PROJECT_ID}:inspection_results.SensitivityInspectionResults" \ --parameters jdbcConnectionUrl="${CLOUD_SQL_JDBC_CONNECTION_URL}" \ --parameters jdbcDriverClass="com.mysql.cj.jdbc.Driver" \ --parameters jdbcUserName="root" \ --parameters jdbcPasswordSecretsKey="projects/${PROJECT_ID}/secrets/${SQL_PASSWORD_SECRET_NAME}/versions/1" \ --parameters ^:^jdbcFilterClause="ROUND(RAND() * 10) IN (1,3)" \ --parameters dataCatalogEntryGroupId="projects/${PROJECT_ID}/locations/${REGION_ID}/entryGroups/${DATA_CATALOG_ENTRY_GROUP_ID}" \ --parameters dataCatalogInspectionTagTemplateId="projects/${PROJECT_ID}/locations/${REGION_ID}/tagTemplates/${INSPECTION_TAG_TEMPLATE_ID}"
Le paramètre jdbcConnectionUrl spécifie une URL de connexion à la base de données JDBC avec les détails de nom d'utilisateur et de mot de passe. Les détails de création de l'URL de connexion exacte dépendent de votre fournisseur de base de données et de votre partenaire d'hébergement. Pour comprendre comment vous connecter aux bases de données relationnelles Cloud SQL, consultez la page Se connecter à l'aide de connecteurs Cloud SQL.
Le pipeline crée une requête telle que SELECT * FROM [TableName] pour lire les enregistrements de table à des fins d'inspection.
Cette requête peut entraîner un chargement sur la base de données et sur le pipeline, en particulier pour une table volumineuse. Si vous le souhaitez, vous pouvez optimiser votre échantillon d'enregistrements du côté de la base de données.
Pour ce faire, insérez jdbcFilterClause en tant que clause WHERE de la requête qui apparaît dans l'exemple de code proposé dans la section Vérifier dans BigQuery plus loin dans ce document.
Pour générer un rapport, vous pouvez choisir un ou plusieurs des récepteurs de rapport suivants :
reportLocationpour stocker le rapport dans un bucket Cloud StoragereportBIGQUERY_TABLEpour stocker le rapport dans un objetBigQueryTabledataCatalogEntryGroupIdpour créer l'entrée et y ajouter un tag dans Data Catalog (omettez ce paramètre si lesourceTypeestBIGQUERY_TABLE)
Le pipeline est compatible avec les types de sources suivants. Pour déterminer la bonne combinaison d'arguments sourceType et inputPattern, utilisez les options répertoriées dans le tableau suivant.
Dans ce cas, vous n'utilisez que la table JDBC_TABLE.
sourceType |
Source de données | inputPattern |
|---|---|---|
|
Bases de données relationnelles (utilisant JDBC) |
|
|
Fichier Avro dans Cloud Storage. Pour sélectionner plusieurs fichiers correspondant à un modèle spécifique, vous pouvez utiliser un seul caractère générique. Le modèle suivant sélectionne tous les fichiers commençant par le préfixe ( data-) :
|
|
|
Fichier Parquet dans Cloud Storage. Pour sélectionner plusieurs fichiers correspondant à un modèle spécifique, vous pouvez utiliser un seul caractère générique. Le modèle suivant sélectionne tous les fichiers commençant par le préfixe ( data-) :
|
|
|
Table BigQuery. Lit toutes les lignes, puis échantillonne aléatoirement à l'aide du pipeline. |
|
Le pipeline détecte toutes les classes infoTypes standards compatibles avec la protection des données sensibles. Vous pouvez fournir un identifiant infoTypes personnalisé supplémentaire en utilisant le paramètre --observableinfoTypes.
Graphe orienté acyclique (DAG) de pipeline d'échantillonnage et d'identification
Le diagramme suivant illustre le DAG d'exécution Dataflow. Ce DAG comporte deux branches. Les deux branches commencent à ReadJdbcTable et se terminent à ExtractReport. Les rapports sont ensuite générés ou stockés.
Récupérer le rapport
Le pipeline d'échantillonnage et d'identification génère les fichiers suivants :
- Fichier de schéma Avro (ou un schéma converti au format Avro) de la source
- Un fichier pour chacune des colonnes sensibles avec des informations
infoTypeet des décomptes
Pour récupérer le rapport, procédez comme suit :
Dans Cloud Shell, récupérez le rapport :
mkdir -p auto_dlp_report/ gsutil -m cp "gs://${TEMP_GCS_BUCKET}/auto_dlp_report/*.json" auto_dlp_report/Répertoriez tous les noms de colonnes identifiés :
cat auto_dlp_report/col-*.json | jq .columnNameVoici le résultat :
"$.topLevelRecord.contact_number" "$.topLevelRecord.person_name"Affichez les détails d'une colonne identifiée avec la commande
catdu fichier :cat auto_dlp_report/col-topLevelRecord-contact_number-00000-of-00001.jsonVoici un extrait de la colonne
cc:{ "columnName": "$.topLevelRecord.contact_number", "infoTypes": [{ "infoType": "PHONE_NUMBER", "count": "990" }] }- La valeur
columnNameest inhabituelle en raison de la conversion implicite d'une ligne de base de données en enregistrement Avro. - La valeur
countvarie en fonction des échantillons sélectionnés de manière aléatoire lors de l'exécution.
- La valeur
Vérifier les tags de sensibilité dans Data Catalog
Le pipeline d'échantillonnage et d'identification crée une entrée et applique les tags de sensibilité aux colonnes pertinentes.
Dans Cloud Shell, récupérez l'entrée créée pour la table Contacts :
gcloud data-catalog entries describe Contacts \ --entry-group=${DATA_CATALOG_ENTRY_GROUP_ID} \ --project="${PROJECT_ID}" \ --location="${REGION_ID}"Cette commande affiche les détails de la table, y compris son schéma.
Affichez tous les tags de sensibilité associés à cette entrée :
gcloud data-catalog tags list --entry=Contacts --entry-group=${DATA_CATALOG_ENTRY_GROUP_ID} \ --project="${PROJECT_ID}" \ --location="${REGION_ID}"Vérifiez que les tags de sensibilité sont présents dans les colonnes suivantes :
contact_number,person_name.Les données
infoTypesidentifiées par la protection des données sensibles peuvent contenir de faux types. Par exemple, il peut identifier le typeperson_nameen tant que typeDATE, car certaines chaînesperson_namesaléatoires peuvent être d'Avril, Mai, Juin ou autres.Les détails du tag de sensibilité générés sont les suivants :
column: contact_number fields: infoTypes: displayName: DLP infoTypes stringValue: '[PHONE_NUMBER]' inspectTimestamp: displayName: Inspection run timestamp timestampValue: '2021-05-20T16:34:29.596Z' name: projects/auto-dlp/locations/asia-southeast1/entryGroups/sql_databases/entries/Contacts/tags/CbS0CtGSpZyJ template: projects/auto-dlp/locations/asia-southeast1/tagTemplates/auto_dlp_inspection templateDisplayName: Auto DLP sensitive categories --- column: person_name fields: infoTypes: displayName: DLP infoTypes stringValue: '[DATE, PERSON_NAME]' inspectTimestamp: displayName: Inspection run timestamp timestampValue: '2021-05-20T16:34:29.594Z' name: projects/auto-dlp/locations/asia-southeast1/entryGroups/sql_databases/entries/Contacts/tags/Cds1aiO8R0pT template: projects/auto-dlp/locations/asia-southeast1/tagTemplates/auto_dlp_inspection templateDisplayName: Auto DLP sensitive categories
Vérifier dans BigQuery
Le pipeline Dataflow ajoute les résultats agrégés à la table BigQuery fournie. La requête imprime les résultats d'inspection récupérés de la table BigQuery.
Dans Cloud Shell, vérifiez les résultats :
bq query \ --location="${REGION_ID}" \ --project="${PROJECT_ID}" \ --use_legacy_sql=false \ 'SELECT input_pattern AS table_name, ColumnReport.column_name AS column_name, ColumnReport.info_types AS info_types FROM `inspection_results.SensitivityInspectionResults`, UNNEST(column_report) ColumnReport; WHERE column_name="$.topLevelRecord.contact_number"'Voici le résultat :
+------------+---------------------------------+----------------------------------------------+ | table_name | column_name | info_types | +------------+---------------------------------+----------------------------------------------+ | Contacts | $.topLevelRecord.contact_number | [{"info_type":"PHONE_NUMBER","count":"990"}] | +------------+---------------------------------+----------------------------------------------+
Effectuer un nettoyage
Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.
Supprimer le projet
- Dans la console Google Cloud, accédez à la page Gérer les ressources.
- Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
- Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.
Étapes suivantes
- Consultez le document associé pour découvrir une solution similaire qui utilise des fichiers en entrée : Tokeniser automatiquement les données sensibles basées sur des fichiers à l'aide de la protection des données sensibles, Cloud Key Management Service et Dataflow.
- Découvrez comment inspecter le stockage et les bases de données pour les données sensibles.
- Découvrez comment gérer l'anonymisation et la désanonymisation des informations permettant d'identifier personnellement l'utilisateur dans les ensembles de données à grande échelle à l'aide de la protection des données sensibles.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.