Aplique automaticamente tags de confidencialidade no Data Catalog a arquivos, bancos de dados e tabelas do BigQuery usando a proteção de dados confidenciais e o Dataflow

Last reviewed 2022-01-11 UTC

Neste documento, mostramos como usar o Data Catalog com um pipeline automatizado do Dataflow para identificar e aplicar A sensibilidade de dados inclui tags nos seus dados em arquivos do Cloud Storage, bancos de dados relacionais, como MySQL, PostgreSQL e BigQuery.

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:

Os dados são extraídos, amostrados, processados e salvos.

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 e STREET_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. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Antes de começar

  1. 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.
  2. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acessar o seletor de projetos

  3. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

  4. Ative as APIs Cloud Build, DLP API, Cloud SQL, Cloud Storage, Compute Engine, Dataflow, Data Catalog, and Secret Manager.

    Ative as APIs

  5. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acessar o seletor de projetos

  6. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

  7. Ative as APIs Cloud Build, DLP API, Cloud SQL, Cloud Storage, Compute Engine, Dataflow, Data Catalog, and Secret Manager.

    Ative as APIs

  8. No Console do Google Cloud, ative o Cloud Shell.

    Ativar 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

  1. 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/
    
  2. 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
  3. 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.

  1. 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"
    
  2. 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
    
  3. 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.

  1. 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}"
    
  2. 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:

  1. 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}
    
  2. 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}"
    
  3. 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}
    
  4. 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 o libncurses5, instale-o no Cloud Shell com sudo 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:

  1. 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.
  2. Amostras de colunas individuais para amostras obrigatórias, excluindo null ou valores vazios.
  3. 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).
  4. Grava relatórios no Cloud Storage e no BigQuery para referência futura.
  5. 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.

  1. 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"
    
  2. 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 Storage
  • report BIGQUERY_TABLE para armazenar o relatório em um BigQueryTable
  • dataCatalogEntryGroupId para criar e marcar a entrada no Data Catalog. Omita esse parâmetro se sourceType for BIGQUERY_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

JDBC_TABLE

Bancos de dados relacionais (usando JDBC)

TABLE_NAME

AVRO

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-):

gs://my-bucket/path/to/folder/data-*

gs://LOCATION_OF_FILES

PARQUET

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-):

gs://my-bucket/path/to/folder/data-*

gs://LOCATION_OF_FILES

BIGQUERY_TABLE

Tabela do BigQuery
Lê todas as linhas e faz amostras aleatórias usando o pipeline.

PROJECT_ID:=DATASET.=TABLE

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.

Fluxo de dados de amostragem e identificação de pipelines.

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:

  1. 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/
    
  2. 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"

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

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.

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

  2. 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}"
    
  3. 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 tipo person_name como um tipo DATE, porque algumas strings person_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

  1. No Console do Google Cloud, acesse a página Gerenciar recursos.

    Acessar "Gerenciar recursos"

  2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
  3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

A seguir