Esse pipeline do Dataflow usa a Proteção de dados confidenciais para detectar dados confidenciais, como informações de identificação pessoal (PII, na sigla em inglês), e marca as descobertas no Data Catalog.
A solução descrita neste documento tem como base a arquitetura da solução de tokenização baseada em arquivos descrita no documento complementar: Tokenizar automaticamente dados confidenciais baseados em arquivos com a proteção de dados confidenciais e o Cloud Key Management Service e Dataflow. A principal diferença entre os dois documentos é que descrevemos uma solução que também cria uma entrada do Data Catalog com um esquema das tags de confidencialidade de origem e de dados para as descobertas do proteção de dados sensíveis. Ele também pode inspecionar bancos de dados relacionais usando conexões de conectividade de banco de dados Java (JDBC, na sigla em inglês) (em inglês).
Este documento destina-se a um público-alvo técnico com responsabilidades que incluem segurança, governança de dados, processamento ou análise de dados. Para este documento, consideramos que você esteja familiarizado com o processamento e a privacidade de dados sem ser um especialista. Também é necessário ter familiaridade com scripts de shell e um conhecimento básico do Google Cloud.
Arquitetura
Essa arquitetura define um pipeline que executa as seguintes ações:
- Extrai os dados de um banco de dados relacional usando JDBC.
- Faz uma amostra dos registros usando a cláusula
LIMIT
do banco de dados. - Processa registros por meio da API Cloud Data Loss Prevention (parte da Proteção de dados confidenciais) para identificar categorias de confidencialidade.
- Salva as descobertas em uma tabela do BigQuery e no Data Catalog.
O diagrama a seguir ilustra as ações que o pipeline realiza:
A solução usa conexões JDBC para acessar bancos de dados relacionais. Ao usar tabelas do BigQuery como fonte de dados, a solução utiliza a API BigQuery Storage para melhorar os tempos de carregamento.
O pipeline sample-and-identify envia os seguintes arquivos para o Cloud Storage:
- Esquema Avro (equivalente) do esquema da origem
- São detectados
dados de
infoTypes
para cada uma das colunas de entrada (PERSON_NAME
,PHONE_NUMBER
eSTREET_ADDRESS
).
Essa solução usa o nivelamento de registro para processar campos aninhados e repetidos nos registros.
Objetivos
- Criar tags do Data Catalog e grupo de entidades
- Implantar o pipeline de amostragem e identificação
- Criar entidade personalizada do Data Catalog
- Aplicar tags de sensibilidade à entidade personalizada do Data Catalog
- Verificar se os dados das tags de sensibilidade também estão no BigQuery
Custos
Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:
Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços.
Antes de começar
- Faça login na sua conta do Google Cloud. Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho de nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.
-
No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
-
Ative as APIs Cloud Build, DLP API, Cloud SQL, Cloud Storage, Compute Engine, Dataflow, Data Catalog, and Secret Manager.
-
No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
-
Ative as APIs Cloud Build, DLP API, Cloud SQL, Cloud Storage, Compute Engine, Dataflow, Data Catalog, and Secret Manager.
-
No Console do Google Cloud, ative o Cloud Shell.
Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.
Configure seu ambiente
No Cloud Shell, clone o repositório de origem e acesse o diretório dos arquivos clonados:
git clone https://github.com/GoogleCloudPlatform/auto-data-tokenize.git cd auto-data-tokenize/
Use um editor de texto para modificar o script
set_variables.sh
e definir as variáveis de ambiente necessárias. Ignore as outras variáveis no script. Eles não são relevantes neste documento.# 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"
Substitua:
- PROJECT_ID: o ID do projeto
- REGION_ID: a região que contém os buckets de armazenamento. Selecione um local que esteja em uma região do Data Catalog.
- CLOUD_STORAGE_BUCKET_NAME: o nome do bucket de armazenamento.
- DLP_RUNNER_SERVICE_ACCOUNT_NAME: o nome da conta de serviço
- DATA_CATALOG_ENTRY_GROUP_ID: o nome do grupo de entradas do catálogo de dados que não é do BigQuery.
- INSPECTION_TAG_TEMPLATE_ID: o nome que você deu ao modelo de tag para o Data Catalog
Execute o script para definir as variáveis de ambiente:
source set_variables.sh
Criar recursos
A arquitetura descrita neste documento usa os seguintes recursos:
- Uma conta de serviço para executar pipelines do Dataflow, permitindo controle de acesso refinado.
- Um bucket do Cloud Storage para armazenar dados temporários e dados de teste
- Um modelo de tag do Data Catalog para anexar tags de sensibilidade às entradas
- Uma instância do MySQL no Cloud SQL como a origem JDBC
Criar contas de serviço
Recomendamos que você execute pipelines com controle de acesso detalhado para melhorar o particionamento do acesso. Se o projeto não tiver uma conta de serviço criada pelo usuário, crie uma.
No Cloud Shell, crie uma conta de serviço para usar como conta de serviço do controlador gerenciada pelo usuário para o 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"
Crie um papel personalizado com as permissões necessárias para acessar a proteção de dados confidenciais, o Dataflow, o Cloud SQL e o 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.yaml
Aplique o papel personalizado e o papel de worker do Dataflow à conta de serviço para permitir que ele seja executado como um worker do 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
Criar o bucket do Cloud Storage
No Cloud Shell, crie um bucket do Cloud Storage para armazenar dados de teste e como um local de preparo do Dataflow:
gsutil mb -p ${PROJECT_ID} -l ${REGION_ID} "gs://${TEMP_GCS_BUCKET}"
Criar um grupo de entradas do Data Catalog
O Data Catalog mantém uma lista de entradas que representam os recursos do Google Cloud ou outros recursos. As entradas são organizadas em grupos. Há um grupo de entrada implícito para o BigQuery (@bigquery
). Você precisa criar grupos de entrada para outros tipos de recursos. Para saber mais sobre as entradas do Data Catalog, consulte Mostrar arquivos do Cloud Storage com entradas do conjunto de arquivos.
No Data Catalog, um grupo de entradas é como uma pasta que contém entradas. Uma entrada representa um recurso de dados.
No Cloud Shell, crie um novo grupo de entrada em que o pipeline possa adicionar uma entrada à tabela do MySQL:
gcloud data-catalog entry-groups create \ "${DATA_CATALOG_ENTRY_GROUP_ID}" \ --project="${PROJECT_ID}" \ --location="${REGION_ID}"
Criar o modelo da tag de inspeção
No Cloud Shell, crie um modelo de tag do Data Catalog para ativar a inclusão de tags nas informações de confidencialidade com a proteção de dados confidenciais:
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
Criar uma tabela de resultados de inspeção no BigQuery
No Cloud Shell, crie uma tabela do BigQuery para armazenar descobertas agregadas da proteção de dados confidenciais:
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
Configurar uma instância do MySQL no Cloud SQL
Para a fonte de dados, use uma instância do Cloud SQL.
No Cloud Shell, instancie um MySQL na instância do Cloud SQL e carregue-o com dados de amostra:
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}"
Salve a senha do banco de dados no Secret Manager.
A senha do banco de dados e outras informações secretas não devem ser armazenadas ou registradas. O Secret Manager permite armazenar e recuperar esses secrets com segurança.
Armazene a senha raiz do banco de dados MySQL como secret da nuvem:
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}"
Copiar os dados de teste para a instância do Cloud SQL
Os dados de teste são um conjunto de dados de demonstração que contém 5.000 nomes e sobrenomes gerados aleatoriamente e números de telefone no estilo dos EUA. A tabela demonstration-dataset
contém quatro colunas: row_id
, person_name
, contact_type
e contact_number
. Você também pode usar seu próprio conjunto de dados. Se você usar
um conjunto de dados próprio, lembre-se de ajustar os valores sugeridos em
Verificar no BigQuery
neste documento. Para copiar o conjunto de dados de demonstração
(contacts5k.sql.gz
) incluído na instância do Cloud SQL, faça o seguinte:
No Cloud Shell, copie o conjunto de dados de amostra para o Cloud Storage para preparo no Cloud SQL:
gsutil cp contacts5k.sql.gz gs://${TEMP_GCS_BUCKET}
Crie um novo banco de dados na instância do Cloud SQL:
export DATABASE_ID="auto_dlp_test" gcloud sql databases create "${DATABASE_ID}" \ --project="${PROJECT_ID}" \ --instance="${SQL_INSTANCE}"
Conceda o papel Administrador de objetos do Storage à conta de serviço do Cloud SQL para que ela possa acessar o armazenamento:
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}
carregue os dados em uma nova tabela
gcloud sql import sql "${SQL_INSTANCE}" \ "gs://${TEMP_GCS_BUCKET}/contacts5k.sql.gz" \ --project="${PROJECT_ID}" \ --database="${DATABASE_ID}"
Para saber mais sobre como importar dados para o Cloud SQL, consulte Práticas recomendadas para importação e exportação de dados.
Compilar módulos
No Cloud Shell, compile os módulos para criar os executáveis a fim de implantar o pipeline de amostragem e identificação e o pipeline de tokenização:
./gradlew clean buildNeeded shadowJar -x test
Opcionalmente, para executar o teste de unidade e integração, remova a sinalização
-x test
. Se você ainda não instalou olibncurses5
, instale-o no Cloud Shell comsudo apt-get install libncurses5
.
Executar o pipeline de amostragem e identificação
O pipeline de identificação de amostragem e proteção de dados confidenciais executa as seguintes tarefas na seguinte ordem:
- Extrai registros da origem fornecida. Por exemplo, o método de identificação da proteção de dados confidenciais aceita apenas tabelas fixas. Portanto, o pipeline nivela os registros Avro, Parquet ou BigQuery, que podem conter campos aninhados e repetidos.
- Amostras de colunas individuais para amostras obrigatórias, excluindo
null
ou valores vazios. - Identifica dados
infoTypes
confidenciais usando a proteção de dados confidenciais, agrupando as amostras em tamanhos de lotes aceitáveis para proteção de dados confidenciais (valores < 500 Kb e < 50.000). - Grava relatórios no Cloud Storage e no BigQuery para referência futura.
- Cria entidades do Data Catalog quando você fornece informações sobre o modelo de tag e o grupo de entrada. Quando você fornece essas informações, o pipeline cria tags de sensibilidade para entradas no Data Catalog nas colunas apropriadas.
Criar um modelo flexível do Dataflow
Os modelos flexíveis do Dataflow permitem usar o Console do Google Cloud, a Google Cloud CLI ou as chamadas da API REST para configurar e executar seus pipelines no Google Cloud. Este documento fornece instruções para o console do Google Cloud. Os modelos clássicos são preparados como gráficos de execução no Cloud Storage, enquanto os modelos flexíveis empacotam o pipeline como uma imagem de contêiner no Container Registry do projeto. Com os modelos flexíveis, é possível separar a criação e a execução de pipelines e a integração com os sistemas de orquestração para execuções programadas de pipelines. Para mais informações sobre os modelos flexíveis do Dataflow, consulte Como avaliar o tipo de modelo a ser usado.
Os modelos flexíveis do Dataflow separam as etapas de criação e preparo
das etapas em execução. Isso possibilita o lançamento de um pipeline do Dataflow a partir de uma chamada de API e, do Cloud Composer, usando o módulo DataflowStartFlexTemplateOperator
.
No Cloud Shell, defina o local para armazenar o arquivo de especificação do modelo que contém as informações necessárias para executar o job do 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"
Crie o modelo flexível do 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\""
Executar o canal
O pipeline de amostragem e identificação extrai o número de registros especificados pelo valor sampleSize
. Ele nivela cada registro e identifica os campos infoTypes
usando a proteção de dados confidenciais (para identificar tipos de informações confidenciais). Os valores infoTypes
são contados e, em seguida, agregados por nome de coluna e pelo campo infoType
para criar um relatório de sensibilidade.
No Cloud Shell, inicie o pipeline de amostragem e identificação para identificar colunas confidenciais na fonte de dados:
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}"
O parâmetro jdbcConnectionUrl
especifica um URL de conexão do banco de dados JDBC com detalhes do nome de usuário e da senha. Os detalhes da criação do URL de conexão exato dependem do fornecedor do banco de dados e do parceiro de hospedagem. Para entender os detalhes da
conexão com bancos de dados relacionais baseados no Cloud SQL, consulte
Como se conectar usando conectores do Cloud SQL.
O pipeline cria uma consulta como SELECT * FROM [TableName]
para ler os
registros da tabela para inspeção.
Essa consulta pode resultar no carregamento no banco de dados e também no pipeline, especialmente para uma tabela grande. Se preferir, otimize sua amostra dos registros que você quer inspecionar no banco de dados.
Para isso, insira jdbcFilterClause
como a cláusula WHERE
da consulta que
aparece no exemplo de código oferecida na seção
Verificar no BigQuery posteriormente em neste tutorial.
Para gerar um relatório, você pode escolher um ou mais dos seguintes coletores de relatório:
reportLocation
para armazenar o relatório em um bucket do Cloud Storagereport
BIGQUERY_TABLE
para armazenar o relatório em umBigQueryTable
dataCatalogEntryGroupId
para criar e marcar a entrada no Data Catalog. Omita esse parâmetro sesourceType
forBIGQUERY_TABLE
.
O pipeline é compatível com os seguintes tipos de origem. Para determinar a combinação correta
de argumentos sourceType
e inputPattern
, use as opções listadas
na tabela a seguir.
Nesse caso, use apenas a tabela JDBC_TABLE
.
sourceType |
Fonte de dados | inputPattern |
---|---|---|
|
Bancos de dados relacionais (usando JDBC) |
|
|
Arquivo Avro no Cloud Storage. Para selecionar vários arquivos correspondentes a um padrão, use um único caractere curinga. O padrão a seguir seleciona todos os arquivos que começam com prefixo ( data- ):
|
|
|
Arquivo Parquet no Cloud Storage. Para selecionar vários arquivos correspondentes a um padrão, use um único caractere curinga. O padrão a seguir seleciona todos os arquivos que começam com prefixo ( data- ):
|
|
|
Tabela do BigQuery Lê todas as linhas e faz amostras aleatórias usando o pipeline. |
|
O pipeline detecta todos os
infoTypes
padrão
compatíveis com a proteção de dados confidenciais. Para fornecer mais infoTypes
personalizado, use o parâmetro --observableinfoTypes
.
Gráfico acíclico dirigido (DAG, na sigla em inglês) por amostragem e identificação de pipeline
O diagrama a seguir mostra o DAG de execução do Dataflow. O DAG tem duas ramificações. Ambas as ramificações começam em ReadJdbcTable
e terminam em ExtractReport
. A partir daí, os relatórios são gerados ou os dados são armazenados.
Recuperar o relatório
O pipeline de amostragem e identificação gera os seguintes arquivos:
- Arquivo de esquema Avro (ou um esquema convertido em Avro) da origem
- Um arquivo para cada uma das colunas confidenciais com informações e contagens de
infoType
Para recuperar o relatório, faça o seguinte:
No Cloud Shell, recupere o relatório:
mkdir -p auto_dlp_report/ gsutil -m cp "gs://${TEMP_GCS_BUCKET}/auto_dlp_report/*.json" auto_dlp_report/
Liste todos os nomes de colunas identificados:
cat auto_dlp_report/col-*.json | jq .columnName
A resposta é a seguinte:
"$.topLevelRecord.contact_number" "$.topLevelRecord.person_name"
Visualize os detalhes de uma coluna identificada com o comando
cat
para o arquivo:cat auto_dlp_report/col-topLevelRecord-contact_number-00000-of-00001.json
Veja a seguir um snippet da coluna
cc
:{ "columnName": "$.topLevelRecord.contact_number", "infoTypes": [{ "infoType": "PHONE_NUMBER", "count": "990" }] }
- O valor
columnName
é incomum devido à conversão implícita de uma linha do banco de dados em um registro Avro. - O valor de
count
varia de acordo com as amostras selecionadas aleatoriamente durante a execução.
- O valor
Verificar tags de sensibilidade no Data Catalog
O pipeline de amostragem e identificação cria uma nova entrada e aplica as tags de sensibilidade às colunas apropriadas.
No Cloud Shell, recupere a entrada criada na tabela "Contatos":
gcloud data-catalog entries describe Contacts \ --entry-group=${DATA_CATALOG_ENTRY_GROUP_ID} \ --project="${PROJECT_ID}" \ --location="${REGION_ID}"
Esse comando mostra os detalhes da tabela, incluindo o esquema.
Mostre todas as tags de sensibilidade anexadas a esta entrada:
gcloud data-catalog tags list --entry=Contacts --entry-group=${DATA_CATALOG_ENTRY_GROUP_ID} \ --project="${PROJECT_ID}" \ --location="${REGION_ID}"
Verifique se as tags de sensibilidade estão presentes nas seguintes colunas:
contact_number
,person_name
.Os dados de
infoTypes
identificados pela proteção de dados confidenciais podem conter alguns tipos falsos. Por exemplo, ele pode identificar o tipoperson_name
como um tipoDATE
, porque algumas stringsperson_names
aleatórias podem ser abril, maio, junho ou outras.Os detalhes da tag de sensibilidade que são gerados são os seguintes:
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
Verificar no BigQuery
O pipeline do Dataflow anexa as descobertas agregadas à tabela do BigQuery fornecida. A consulta imprime os resultados da inspeção recuperados da tabela do BigQuery.
No Cloud Shell, verifique os resultados:
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"'
A resposta é a seguinte:
+------------+---------------------------------+----------------------------------------------+ | table_name | column_name | info_types | +------------+---------------------------------+----------------------------------------------+ | Contacts | $.topLevelRecord.contact_number | [{"info_type":"PHONE_NUMBER","count":"990"}] | +------------+---------------------------------+----------------------------------------------+
Limpar
Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.
Exclua o projeto
- No Console do Google Cloud, acesse a página Gerenciar recursos.
- Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
- Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.
A seguir
- Leia o documento complementar sobre uma solução semelhante que usa arquivos como entrada: tokenizar automaticamente dados confidenciais baseados em arquivos com a proteção de dados, o Cloud Key Management Service e o Dataflow.
- Saiba mais sobre como inspecionar armazenamento e bancos de dados confidenciais.
- Saiba mais sobre como lidar com a desidentificação e reidentificação de PII em conjuntos de dados de grande escala usando a proteção de dados confidenciais.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.