Introdução ao controle de acesso no nível da coluna

Observação: esse recurso pode não estar disponível ao usar reservas criadas com determinadas edições do BigQuery. Para mais informações sobre quais recursos estão ativados em cada edição, consulte Introdução às edições 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 o controle de acesso 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.

Para melhorar o controle de acesso no nível da coluna, é possível usar o mascaramento de dados dinâmicos. O mascaramento de dados permite mascarar dados confidenciais substituindo o conteúdo nulo, padrão ou com hash no lugar do valor real da coluna.

Fluxo de trabalho de controle de acesso no nível da coluna

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

1. Definir tags de taxonomia e política. Criar e gerenciar tags de taxonomia e política para seus dados. Para acessar 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. Aplique controle de acesso à taxonomia. A aplicação do controle de acesso faz com que as restrições de acesso definidas para todas as tags de política na taxonomia sejam aplicadas.

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

Observação: o controle de acesso no nível da coluna é aplicado além das ACLs de conjunto de dados. Um usuário precisa da permissão do conjunto de dados e da tag de política para acessar os dados protegidos pelo controle de acesso no nível da coluna.

Identifique o que precisa ser marcado

Para determinar os tipos de dados sensíveis que você tem e quais colunas precisam de tags de política, gere perfis sobre seus dados em uma organização, pasta ou projeto usando a Proteção de sensíveis. Os perfis de dados contêm métricas e metadados sobre tabelas e ajudam a determinar onde os dados confidenciais e de alto risco residem. A Proteção de dados sensíveis informa essas métricas nos níveis do projeto, da tabela e da coluna. Para saber mais, consulte Perfis de dados do BigQuery.

A imagem a seguir mostra uma lista de perfis de dados da coluna (clique para ampliar). As colunas com valores de alto risco de dados podem conter dados de alta sensibilidade e não ter controles de acesso no nível da coluna. Como alternativa, essas colunas podem conter dados moderados ou de alta sensibilidade acessíveis a um grande número de pessoas.

Exemplo de caso de uso:

Considere uma organização que precisa classificar dados confidenciais em duas categorias: Alta e Média.

Para configurar a segurança no nível da coluna, um administrador de dados, que tem as permissões apropriadas, execute as etapas a seguir para configurar uma hierarquia de classificação de dados.

1. O administrador de dados cria uma taxonomia chamada "Criticidade comercial". A taxonomia inclui os nós ou as tags de política Alta e Média.

2. O administrador de dados decide se a política para o nó High inclui acesso para um grupo chamado high-tier-access.

3. O administrador de dados cria mais níveis de nós na taxonomia, em Alta e Média. O nó de nível mais baixo é um nó de folha, como o nó de folha employee_ssn. O administrador de dados pode criar ou não uma política de acesso diferente para o nó de folha employee_ssn.

4. O administrador de dados atribui uma tag de política a colunas específicas da tabela. Neste exemplo, o administrador de dados atribui a política de acesso Alta à coluna employee_ssn em uma tabela.

5. Na página Esquema atual do console, o administrador de dados pode ver a tag de política que rege uma coluna específica. Neste exemplo, a coluna employee_ssn está na tag de política employee_ssn. Portanto, ao visualizar o esquema para employee_ssn, o console exibe o nome da taxonomia e a tag de política no campoPolicy tags: Business criticality:High.

   

   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.

   Observação: só é possível atribuir uma tag de política por coluna.

6. 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 ver detalhes sobre essas etapas, consulte Como restringir o acesso com o controle de acesso no nível da coluna.

Papéis usados com o controle de acesso no nível da coluna

Os papéis a seguir são usados para controle de acesso no nível da coluna do BigQuery.

O papel de administrador de tags de política do Data Catalog é necessário para os usuários que precisam criar e gerenciar taxonomias e tags de política.

ID/papel	Permissões	Descrição
Administrador de tags de política do Data Catalog/datacatalog.categoryAdmin	datacatalog.categories.getIamPolicy datacatalog.categories.setIamPolicy datacatalog.taxonomies.create datacatalog.taxonomies.delete datacatalog.taxonomies.get datacatalog.taxonomies.getIamPolicy datacatalog.taxonomies.list datacatalog.taxonomies.setIamPolicy datacatalog.taxonomies.update resourcemanager.projects.get resourcemanager.projects.list	Aplica-se no nível do projeto. Com essa função, é possível fazer o seguinte: Criar, ler, atualizar e excluir taxonomias e tags de política. Acessar e definir políticas do IAM nas tags de política.

O papel de administrador do BigQuery ou o papel de proprietário de dados do BigQuery é necessário para criar e gerenciar políticas de dados. Quando você usa o Console do Google Cloud para aplicar o controle de acesso a uma taxonomia, o serviço cria silenciosamente uma política de dados.

ID/papel	Permissões	Descrição
Administrador do BigQuery/bigquery.admin Proprietário de dados do BigQuery/bigquery.dataOwner	bigquery.dataPolicies.create bigquery.dataPolicies.delete bigquery.dataPolicies.get bigquery.dataPolicies.getIamPolicy bigquery.dataPolicies.list bigquery.dataPolicies.setIamPolicy bigquery.dataPolicies.update	As permissões bigquery.dataPolicies.create e bigquery.dataPolicies.list se aplicam no nível do projeto. As outras permissões são aplicáveis no nível da política de dados. Com essa função, é possível fazer o seguinte: Criar, ler, atualizar e excluir políticas de dados. Acessar e definir políticas do IAM nas políticas de dados.

Você também precisa da permissão datacatalog.taxonomies.get, que pode ser recebida de vários dos papéis predefinidos do Data Catalog.

O papel Leitor refinado do Data Catalog é necessário para usuários que precisam de acesso a dados em colunas seguras.

ID/papel	Permissões	Descrição
Leitor de controle refinado/datacatalog.categoryFineGrainedReader	datacatalog.categories.fineGrainedGet	Aplica-se no nível da tag de política. Este papel concede a capacidade de acessar o conteúdo de colunas restritas por uma tag de política.

Para saber mais sobre os papéis do Data Catalog, consulte Gerenciamento de identidade e acesso do Data Catalog (IAM). Para saber mais sobre os papéis do BigQuery, consulte Controle de acesso com o IAM.

Impacto das gravações

Para ler dados de uma coluna protegida pelo controle de acesso 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 pelo controle de acesso 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 nas colunas de leitura.

Um usuário pode carregar dados de arquivos locais ou do Cloud Storage. Ao carregar dados em uma tabela, o BigQuery não verifica a permissão do leitor refinada nas colunas da tabela de destino. Isso ocorre porque o carregamento de dados não requer a leitura de conteúdo da tabela de destino. Da mesma forma, 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 tem 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 controle de acesso no nível da coluna.

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 esse 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 anterior, 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.

Visualizações de consultas

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

Uma visualização autorizada é uma das seguintes:

• Uma visualização que está explicitamente autorizada para acessar as tabelas em um conjunto de dados.
• Uma visualização que está implicitamente autorizada a acessar as tabelas em um conjunto de dados porque está contida em um conjunto de dados autorizado.

Para mais informações, consulte Visualizações autorizadas e Conjuntos de dados autorizados.

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

Se o usuário tiver acesso do IAM às tabelas e ao conjunto de dados subjacentes da visualização, bem como acesso no nível da coluna às tabelas subjacentes da visualização, o usuário 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:

Somente a segurança no nível da coluna nas colunas das tabelas subjacentes da visualização controla o acesso. 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.

Impacto da viagem no tempo e de visualizações materializadas com max_staleness

O BigQuery permite consultar uma tabela em um estado anterior. Esse recurso permite consultar as linhas em um momento anterior. Além disso, é possível restaurar uma tabela em um momento.

No SQL legado, é preciso consultar os dados históricos usando decoradores de tempo no nome da tabela. No GoogleSQL, para consultar dados históricos, use a cláusula FOR SYSTEM_TIME AS OF na tabela.

As visualizações materializadas com a opção max_staleness definida retornam dados históricos do intervalo de inatividade. Esse comportamento é semelhante a uma consulta que usa FOR SYSTEM_TIME AS OF no momento da última atualização da visualização, porque permite que o BigQuery consulte registros que foram excluídos ou atualizados. Suponha que você consulte os dados históricos de uma tabela no tempo t. Nesse caso, faça o seguinte:

• Se o esquema no tempo t é idêntico a um subconjunto do esquema atual da tabela ou é um, o BigQuery verifica a segurança mais recente no nível da coluna na tabela atual. Se o usuário tiver permissão para ler as colunas atuais, ele poderá consultar os dados históricos dessas colunas. Para excluir ou mascarar dados sensíveis de colunas protegidas pela segurança no nível da coluna, só é possível relaxar a segurança no nível da coluna após a janela de viagem no tempo configurada já ter passado desde a limpeza dos dados sensíveis.

• Se o esquema no tempo t for diferente do esquema atual para as colunas na consulta, a consulta falhará.

Considerações sobre o local

Ao escolher um local para a taxonomia, considere as limitações a seguir.

Tags de política

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.

Se você quiser usar a mesma taxonomia e tags de política em vários locais regionais, saiba mais sobre como replicar taxonomias em Como gerenciar tags de política em locais.

Organizações

Não é possível usar referências entre organizações. Uma tabela e todas as tags de política que você quer aplicar às colunas precisam existir na mesma organização.

Limitações

• Esse recurso pode não estar disponível ao usar reservas criadas com determinadas edições do BigQuery. Para mais informações sobre quais recursos estão ativados em cada edição, consulte Introdução às edições do BigQuery.

• O BigQuery é compatível apenas com controle de acesso no nível da coluna para tabelas do BigLake, tabelas do BigQuery e tabelas do BigQuery Omni.

• 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'
  

  As alterações no esquema ocorrem em uma operação separada da execução da consulta. Se você gravar os resultados da consulta em uma tabela especificando a sinalização --destination_table e a consulta gerar uma exceção posteriormente, é possível que todas as alterações de esquema sejam ignoradas. Se isso ocorrer, verifique o esquema da tabela de destino e atualize-o manualmente, se necessário.

• 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 o controle de acesso 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.

• Uma hierarquia de tags de política não pode ter mais de cinco níveis de profundidade do nó raiz até a subtag de nível mais baixo, conforme a captura de tela abaixo:

  

• Os nomes de taxonomia precisam ser exclusivos entre todos os projetos de uma organização.

• Não é possível copiar uma tabela entre regiões quando você tem o controle de acesso no nível da coluna ou nível da linha ativado. Todas as cópias de tabelas entre regiões são rejeitadas quando há tags de política nas tabelas de origem.

Preços

O controle de acesso no nível da coluna requer o uso do BigQuery e do Data Catalog. Para informações sobre preços desses produtos, consulte os seguintes tópicos:

• Preços do BigQuery
• Preços do Data Catalog

Registro de auditoria

Quando os dados da tabela com tags de política são lidos, salvamos as tags de política referenciadas no Cloud Logging. No entanto, a verificação de tags de política não está associada à consulta que acionou a verificação.

Por meio do Cloud Logging, os auditores podem entender quem tem acesso a determinadas categorias de dados confidenciais. Para mais informações, consulte Como auditar tags de política.

Para mais informações sobre a geração de registros no BigQuery, consulte Introdução ao monitoramento do BigQuery.

Para mais informações sobre a geração de registros no Google Cloud, consulte Cloud Logging.

A seguir

• Para ver mais detalhes sobre como usar o controle de acesso no nível da coluna, consulte Como restringir o acesso com o controle de acesso no nível da coluna.

• Para mais informações sobre as práticas recomendadas para tags de política, consulte Práticas recomendadas do BigQuery: como usar tags de política.