Como gerenciar tags de política entre locais

Neste documento, descrevemos como gerenciar tags de política em locais regionais para segurança no nível da coluna e mascaramento de dados dinâmicos no BigQuery.

O BigQuery oferece controle de acesso minucioso e máscara de dados dinâmicos para colunas de tabela confidenciais com tags de política, oferecendo suporte à classificação de dados com base no tipo.

Depois de criar uma taxonomia de classificação de dados e aplicar tags de política aos seus dados, é possível gerenciar melhor as tags de política nos locais.

Considerações sobre o local

As taxonomias são recursos regionais, como conjuntos de dados e tabelas do BigQuery. Ao criar uma taxonomia, você especifica a região ou o local dela.

É possível criar uma taxonomia e aplicar tags de política a tabelas em todas as regiões em que o BigQuery está disponível. No entanto, para aplicar tags de política de uma taxonomia a uma coluna da tabela, a taxonomia e a tabela precisam existir no mesmo local regional.

Embora não seja possível aplicar uma tag de política a uma coluna da tabela que existe em outro local, você pode copiar a taxonomia para outro local replicando-o explicitamente.

Como usar taxonomias entre locais

É possível copiar ou replicar explicitamente uma taxonomia e as definições de tag de política dela para outros locais, sem precisar criar manualmente uma nova taxonomia em cada local. Ao replicar taxonomias, é possível usar as mesmas tags de política para segurança no nível da coluna em vários locais, simplificando o gerenciamento.

Ao replicá-las, as tags de taxonomia e política mantêm os mesmos códigos em cada local.

As tags de taxonomia e política podem ser sincronizadas novamente para mantê-las unificadas em vários locais. A replicação explícita de uma taxonomia é seguida por uma chamada para a API Data Catalog. As sincronizações futuras da taxonomia replicada usam o mesmo comando da API, que substitui a taxonomia anterior.

Para facilitar a sincronização da taxonomia, é possível usar o Cloud Scheduler para executar periodicamente uma sincronização da taxonomia entre regiões, seja em uma programação definida ou com um envio manual de botões. Para usar o Cloud Scheduler, é preciso configurar uma conta de serviço.

Como replicar uma taxonomia em um novo local

Permissões necessárias

As credenciais do usuário ou a conta de serviço que replica a taxonomia precisa ter o papel Administrador das tags de política do Data Catalog.

Leia mais sobre como conceder o papel Administrador de tags de política em Como restringir o acesso com a segurança no nível da coluna do BigQuery.

Para mais informações sobre papéis e permissões do IAM no BigQuery, consulte Papéis e permissões predefinidos.

Para replicar uma taxonomia entre locais:

API

Chame o método projects.locations.taxonomies.import da API Data Catalog, fornecendo uma solicitação POST e o nome do projeto de destino e do local na string HTTP.

POST https://datacatalog.googleapis.com/{parent}/taxonomies:import

O parâmetro de caminho parent é o projeto de destino e o local para onde você quer copiar a taxonomia. Exemplo: projects/MyProject/locations/eu

Como sincronizar uma taxonomia replicada

Para sincronizar uma taxonomia que já foi replicada em vários locais, repita a chamada da API Data Catalog conforme descrito em Como replicar uma taxonomia em um novo local.

Como alternativa, é possível usar uma conta de serviço e o Cloud Scheduler para sincronizar a taxonomia em uma programação especificada. A configuração de uma conta de serviço no Cloud Scheduler também permite acionar uma sincronização sob demanda (não programada) pela página do Cloud Scheduler no console do Google Cloud ou com a Google Cloud CLI.

Como sincronizar uma taxonomia replicada com o Cloud Scheduler

Para sincronizar uma taxonomia replicada entre locais com o Cloud Scheduler, você precisa de uma conta de serviço.

Contas de serviço

É possível conceder permissões para a sincronização de replicação com uma conta de serviço atual ou criar uma nova conta de serviço.

Para criar uma nova conta de serviço, consulte Criar contas de serviço.

Permissões necessárias

  1. A conta de serviço que sincroniza a taxonomia precisa ter o papel Administrador das tags de política do Data Catalog. Para mais informações, consulte Conceder o papel de administrador de tags de política.

  2. Ative a API do Cloud Scheduler

Como configurar uma sincronização de taxonomia com o Cloud Scheduler

Para sincronizar uma taxonomia replicada entre locais com o Cloud Scheduler:

Console

Primeiro, crie o trabalho de sincronização e a programação dele.

  1. Siga as instruções para Criar um job no Cloud Scheduler.

  2. Em Frequência, preencha o intervalo que você quer entre as sincronizações automáticas.

  3. Em Destino, consulte as instruções em Como criar um job do programador com autenticação.

    Criar um job do programador, parte 2

Em seguida, adicione a autenticação necessária para a sincronização programada.

  1. Clique em MOSTRAR MAIS para exibir os campos de autenticação.

  2. Em Cabeçalho Auth, selecione "Adicionar token OAuth".

  3. Adicione as informações da sua conta de serviço.

  4. Em Escopo, digite "https://www.googleapis.com/auth/cloud-platform".

  5. Clique em Criar para salvar a sincronização programada.

    Criar um job do programador, parte 2

Agora teste se o job está configurado corretamente.

  1. Depois que o job for criado, clique em Executar agora para testar se o job está configurado corretamente. Em seguida, o Cloud Scheduler aciona a solicitação HTTP com base na programação que você especificou.

    Testar um job do programador

gcloud

Sintaxe:

  gcloud scheduler jobs create http "JOB_ID" --schedule="FREQUENCY" --uri="URI" --oath-service-account-email="CLIENT_SERVICE_ACCOUNT_EMAIL" --time-zone="TIME_ZONE" --message-body-from-file="MESSAGE_BODY"

Substitua:

  1. ${JOB_ID} é um nome para o job. Ele precisa ser exclusivo no projeto. Não é possível reutilizar o nome de um job em um projeto mesmo depois de excluir o job com esse nome.
  2. ${FREQUENCY} é a programação, também chamada de intervalo de job, da frequência de execução do job. Por exemplo, "a cada 3 horas". É possível usar aqui qualquer string compatível com o formato crontab. Os desenvolvedores também podem usar a sintaxe de cron do App Engine se estiverem familiarizados com o antigo cron do App Engine legado.
  3. ${URI} é o URL completo do endpoint.
  4. --oauth-service-account-email define o tipo de token. As APIs do Google hospedadas em *.googleapis.com esperam um token OAuth.
  5. ${CLIENT_SERVICE_ACCOUNT_EMAIL} é o e-mail da conta de serviço de cliente.
  6. ${MESSAGE_BODY} é o caminho para o arquivo que contém o corpo da solicitação POST.

Há outros parâmetros de opção disponíveis, descritos na referência da Google Cloud CLI.

Exemplo:

  gcloud scheduler jobs create http cross_regional_copy_to_eu_scheduler --schedule="0 0 1 * *" --uri="https://datacatalog.googleapis.com/v1/projects/my-project/locations/eu/taxonomies:import" --oauth-service-account-email="policytag-manager-service-acou@my-project.iam.gserviceaccount.com" --time-zone="America/Los_Angeles" --message-body-from-file=request_body.json

A seguir