Introdução à segurança no nível da coluna do BigQuery

O BigQuery fornece acesso detalhado a colunas com dados confidenciais usando tags de política ou uma classificação de dados baseada em tipos. Usando a segurança no nível da coluna do BigQuery, é possível criar políticas que verifiquem no momento da consulta se o usuário tem o acesso adequado. Por exemplo, uma política pode impor verificações de acesso como:

  • É necessário estar em group:high-access para ver as colunas que contêm TYPE_SSN.

Fluxo de trabalho de segurança no nível da coluna

Fluxo de trabalho

Para restringir o acesso a dados no nível da coluna:

  1. Definir tags de taxonomia e política de dados. Use o Data Catalog para criar e gerenciar tags de taxonomia e política para seus dados. Para ver as diretrizes, consulte Práticas recomendadas para tags de política.

  2. Atribuir tags de política às colunas do BigQuery. No BigQuery, use anotações de esquema para atribuir uma tag de política a cada coluna em que você quer restringir o acesso.

  3. Gerenciar o acesso nas tags de política. Use as políticas de gerenciamento de identidade e acesso (IAM, na sigla em inglês) para restringir o acesso a cada tag de política. A política está em vigor para cada coluna que pertence à tag de política.

Quando um usuário tenta acessar os dados da coluna no momento da consulta, o BigQuery verifica a tag da política de coluna e a própria política, para ver se o usuário está autorizado a acessar os dados.

Exemplo de caso de uso:

Considere uma organização que precisa classificar dados confidenciais em três categorias: Alta, Média e Baixa.

Tags de política

Para configurar a segurança no nível da coluna:

  1. Um administrador de governança de dados define as tags de política Média e Alta no Data Catalog.

  2. Para a tag de política de acesso Alta, o administrador concede acesso ao grupo high-tier-access.

  3. O administrador atribui colunas às tags de política Alta. Por exemplo, se a coluna ssn estiver na tag de política Alta, o esquema para ssn conterá um campo policyTags. Veja a seguir como uma tag de política aparece na página Esquema atual.

    IU da tag de política

    Para saber como usar o console para definir uma tag de política, consulte Definir uma tag de política em uma coluna.

    Como alternativa, é possível definir a tag de política usando o comando bq update. O campo names de policyTags inclui o ID da tag de política Alta, projects/project- id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id:

    [
     ...
     {
       "name": "ssn",
       "type": "STRING",
       "mode": "REQUIRED",
       "policyTags": {
         "names": ["projects/project-id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id",]
       }
     },
     ...
    ]
    

    Para saber como usar o comando bq update para definir uma tag de política, consulte Definir uma tag de política em uma coluna.

  4. O administrador realiza etapas semelhantes para a tag de política Média.

Ao usar o acesso detalhado, é possível gerenciar o acesso a muitas colunas controlando apenas um pequeno número de tags da política de classificação de dados.

Para saber mais sobre essas etapas, consulte Como restringir o acesso com a segurança no nível da coluna do BigQuery.

Papéis usados com a segurança no nível da coluna

Os papéis do Data Catalog a seguir são usados para segurança no nível da coluna do BigQuery.

Role Nome Aplicável a Descrição
roles/
datacatalog.categoryAdmin
Administrador de tag de política Projeto Tem permissão para:
  • criar, ler, atualizar e excluir taxonomias;
  • definir políticas do IAM em tags de política.
Este papel não tem acesso para ler o conteúdo da coluna.

Normalmente, um usuário com essa função é responsável por definir políticas de governança de dados para a organização.
roles/
datacatalog.categoryFineGrainedReader
Leitor de controle refinado Tag de política Tem permissão para acessar colunas do BigQuery marcadas com a tag de política correspondente.

Normalmente, um usuário com esse papel está consultando os dados.

Impacto das gravações

Para ler dados de uma coluna protegida pela segurança no nível da coluna, o usuário sempre precisa ter permissão de leitura recebida por meio do acesso de leitura detalhado nas tags de política da coluna.

Isso se aplica a:

  • Tabelas, incluindo tabelas de caracteres curinga
  • Visualizações
  • Copiar tabelas

Para gravar dados em uma linha de uma coluna protegida pela segurança no nível da coluna, o requisito do usuário depende do tipo de gravação.

Se a operação de gravação for inserida, o acesso de leitura detalhado não será necessário. No entanto, o usuário não terá acesso para ler os dados que foram inseridos, a menos que ele tenha acesso de leitura detalhado.

Se a operação de gravação for atualizada, excluída ou mesclada, o usuário não poderá realizar a operação, a menos que tenha acesso de leitura detalhado.

Um usuário não pode carregar dados de arquivos locais ou do Cloud Storage, a menos que tenha acesso de leitura detalhado. No entanto, um usuário pode carregar dados de streaming, porque os carregamentos de streaming não verificam as tags de política. O usuário não terá acesso para ler os dados que foram carregados de um stream, a menos que tenha acesso de leitura detalhado.

Para mais informações, consulte Impacto nas gravações com a segurança no nível da coluna do BigQuery.

Como consultar tabelas

Se um usuário tiver acesso ao conjunto de dados e tiver o papel "Leitor refinado" do Data Catalog, os dados da coluna estarão disponíveis para o usuário. O usuário executa uma consulta normalmente.

Se um usuário tiver acesso ao conjunto de dados, mas não tiver o papel "Leitor refinado" do Data Catalog, os dados da coluna não estarão disponíveis para o usuário. Se o usuário executar SELECT *, ele receberá um erro que lista as colunas que o usuário não pode acessar. Para resolver o erro, é possível:

  • Modifique a consulta para excluir as colunas que o usuário não pode acessar. Por exemplo, se o usuário não tiver acesso à coluna ssn, mas tiver acesso às colunas restantes, ele poderá executar a seguinte consulta:

    SELECT * EXCEPT (ssn) FROM ...
    

    No exemplo acima, a cláusula EXCEPT exclui a coluna ssn.

  • Peça ao administrador do Data Catalog para adicionar o usuário no papel de "Leitor refinado" do Data Catalog para a classe de dados relevante. A mensagem de erro fornece o nome completo da tag de política à qual o usuário precisa de acesso.

Como consultar visualizações

O impacto da segurança no nível da coluna nas visualizações é independente da visualização autorizada. Em ambos os casos, a segurança no nível da coluna é aplicada de forma transparente.

Se a visualização não for autorizada:

Se o usuário tiver acesso no nível da coluna para as colunas das tabelas subjacentes da visualização, ele poderá consultar as colunas na visualização. Caso contrário, o usuário não poderá consultar as colunas na visualização.

Se a visualização for autorizada:

O acesso é controlado apenas pela segurança no nível da coluna em colunas nas tabelas subjacentes da visualização. As políticas do IAM no nível da tabela e no conjunto de dados, se houver, não são usadas para verificar o acesso. Se o usuário tiver acesso às tags de política usadas nas tabelas subjacentes da visualização autorizada, ele poderá consultar as colunas na visualização autorizada.

O diagrama a seguir mostra como o acesso a uma visualização é avaliado.

Como acessar visualizações

Impacto dos snapshots

O BigQuery permite que os usuários consultem uma tabela em um estado anterior. Esse recurso permite consultar as linhas de um snapshot anterior da tabela. Ele também permite reverter a tabela para a data em que o snapshot foi tirado.

No SQL legado, é possível consultar um snapshot usando decoradores de snapshot no nome da tabela. No SQL padrão, é possível consultar um snapshot usando a cláusula FOR SYSTEM_TIME AS OF na tabela.

O limite de tempo mais recente para consultar um snapshot foi:

  • os últimos sete dias
  • o horário de criação da tabela

Não será possível consultar uma tabela anterior se ela tiver sido excluída e recriada com o mesmo nome de tabela.

Para ver como os snapshots funcionam com a segurança no nível da coluna, suponha que você tenha:

  • um ponto de origem, que é uma tabela existente no momento;

  • um snapshot da mesma tabela;

  • o esquema do snapshot que é idêntico a (ou que seja) um subconjunto do esquema da origem. Ou seja, todas as colunas do snapshot são incluídas na origem.

Considerando essas suposições, as permissões marcadas são contrárias à segurança mais recente em nível de coluna na tabela de origem (atual). Se o usuário tiver permissão para ler as colunas atuais, ele poderá consultar um snapshot dessas colunas.

Se o esquema da origem e o snapshot forem diferentes para as colunas na consulta, uma solicitação para recuperar um snapshot falhará.

Limitações

  • Se você substituir para uma tabela de destino, qualquer tag de política atual será removida da tabela, a menos que você use a sinalização --destination_schema para especificar um esquema com tags de política. O exemplo a seguir mostra como usar --destination_schema.

    bq query --destination_table mydataset.mytable2 \
      --use_legacy_sql=false --destination_schema=schema.json \
      'SELECT * FROM mydataset.mytable1'
    
  • Uma coluna pode ter apenas uma tag de política.

  • Uma tabela pode ter no máximo 1.000 tags de políticas únicas.

  • Não será possível usar o SQL legado se você tiver ativado a segurança no nível da coluna. Todas as consultas do SQL legado serão rejeitadas se houver alguma tag de política nas tabelas de destino.

  • Não é possível usar referências entre organizações. Ou seja, uma tabela e todas as tags de política usadas na tabela precisam existir na mesma organização.

A seguir