Práticas recomendadas para segurança no nível da linha no BigQuery

Este documento explica as práticas recomendadas ao usar a segurança no nível da linha.

Antes de ler este documento, familiarize-se com a segurança no nível da linha lendo a Introdução à segurança no nível da linha do BigQuery e Como trabalhar com a segurança no nível da linha.

Restringir as permissões do usuário para limitar ataques secundários no canal

Um ataque no canal é um ataque de segurança com base nas informações recebidas pelo próprio sistema. Um invasor com mais permissões do que o necessário pode aprender dados confidenciais por observação ou pesquisa, faturamento, geração de registros ou mensagens do sistema.

Para atenuar essas oportunidades, o BigQuery oculta estatísticas confidenciais em todas as consultas em tabelas com segurança no nível da linha. Essas estatísticas confidenciais incluem o número de bytes e partições processados, o número de bytes faturados e os estágios do plano de consulta.

Recomendamos que os administradores evitem conceder as seguintes permissões a usuários que devem ver apenas dados filtrados, para evitar conceder acesso a dados confidenciais.

Permissões Dados confidenciais
Papel de Proprietário ou de Criador de projeto Os proprietários do projeto podem ver os bytes processados e os dados relacionados nos registros de auditoria. Os criadores podem criar novos projetos de que são proprietários e visualizar registros de faturamento e auditoria.
Papéis de editor, proprietário ou leitor de dados do BigQuery Veja as mensagens de erro nas consultas.
Papéis de leitor do monitoramento de métricas Stackdriver do BigQuery Visualize métricas em consultas, incluindo bytes processados e dados relacionados.
Permissões do leitor do Cloud Billing Ver o faturamento do BigQuery.

Exemplos

  • Ao observar repetidamente a duração da consulta ao consultar tabelas com políticas de acesso no nível da linha, um usuário pode inferir os valores das linhas que, de outra forma, poderiam ser protegidos por políticas de acesso no nível da linha. Esse tipo de ataque requer muitas tentativas repetidas em um intervalo de valores de chave nas colunas particionadas ou em cluster. Embora haja um barulho inerente ao observar ou medir a duração da consulta, tentando repetidamente, um invasor pode conseguir uma estimativa confiável. Se você estiver sujeito a esse nível de proteção, recomendamos usar tabelas separadas para isolar linhas com diferentes requisitos de controle de acesso.
  • Com consultas repetidas e cuidadosamente elaboradas, é possível que um usuário mal-intencionado aprenda informações confidenciais observando as mensagens de erro resultantes. Especificamente, um usuário mal-intencionado com acesso à tabela subjacente pode derivar valores de linha protegidos quando a consulta retornar uma exceção de divisão por zero, mesmo que haja uma predicado de segurança para evitar que esse usuário consulte diretamente os mesmos dados. Esse tipo de ataque geralmente requer muitas tentativas repetidas em uma tabela com segurança no nível da linha.
  • Um invasor pode pesquisar os bytes processados por uma consulta ao monitorar os erros que ocorrem quando os limites do job de consulta, como máximo de bytes faturados ou controles de custo personalizados, são excedidos. No entanto, esse ataque demanda muitas consultas.
  • Ao consultar e observar repetidamente a quantidade de faturamento do BigQuery no Cloud Billing, um usuário pode inferir os valores das linhas que, de outra forma, poderiam ser protegidas por políticas de acesso no nível da linha. Esse tipo de ataque requer muitas tentativas repetidas em um intervalo de valores de chave na partição ou no particionamento de colunas. Se você for sensível a esse nível de proteção, recomendamos que limite o acesso aos dados de faturamento para consultas.

Também recomendamos que os administradores monitorem registros de auditoria do Cloud(/bigquery/docs/reference/auditlogs) para identificar atividades suspeitas em tabelas com segurança no nível da linha, como adições inesperadas, modificações e exclusões de políticas de acesso no nível da linha.

Evitar abrir o acesso acidentalmente ao recriar políticas de acesso no nível da linha

Ao adicionar uma política de acesso de linha a uma tabela pela primeira vez, você começa imediatamente a filtrar dados nos resultados da consulta. Ao remover a última política de acesso no nível da linha em uma tabela, mesmo que você pretenda apenas recriar a política de acesso no nível da linha, talvez você conceda acesso não filtrado acidentalmente a um público maior do que o pretendido.

Recomendamos que os administradores prestem atenção especial ao recriar a última política de acesso no nível da linha em uma tabela seguindo estas diretrizes:

  1. Primeiro, remova todo o acesso à tabela usando os controles de acesso à tabela.
  2. Remova todas as políticas de acesso no nível da linha.
  3. Recrie as políticas de acesso no nível da linha que você quer.
  4. Reative o acesso à tabela com controles de acesso de tabela.

Como alternativa, primeiro crie novas políticas de acesso no nível da linha na tabela e depois exclua as mais antigas que não são mais necessárias.

Usar a segurança no nível da linha apenas dentro das organizações, não entre organizações.

Não use o recurso de segurança no nível da linha entre organizações, para ajudar a evitar o vazamento de dados em ataques de canal e manter um maior controle sobre o acesso a dados confidenciais.

Recomendamos o uso do recurso de segurança no nível da linha apenas para restrições de segurança dentro da organização (como para compartilhar dados em uma organização/empresa), e não para segurança entre empresas ou pública.

Exemplo

Fora da organização, você tem menos controle sobre quem tem acesso aos dados. Dentro da organização, é possível controlar quem recebeu acesso às informações de faturamento de consultas nas tabelas com políticas de acesso no nível da linha. As informações de faturamento são um vetor para ataques de canal.

Use o papel Filtered Data Viewer com cautela

Ao criar uma política de acesso no nível da linha, os principais na política recebem automaticamente o papel bigquery.filteredDataViewer. Só é possível adicionar ou remover principalis da política com uma instrução DDL.

No entanto, é possível conceder o papel bigquery.filteredDataViewer pelo IAM a um recurso de nível superior, como tabela, conjunto de dados ou projeto. A concessão do papel bigquery.filteredDataViewer a um usuário permite que ele visualize as linhas definidas por todas as políticas de acesso no nível da linha nessa tabela, conjunto de dados ou projeto.

No entanto, conceder o papel bigquery.filteredDataViewer em uma tabela não significa necessariamente que o usuário pode ver todas as linhas na tabela. A união de todas as expressões de filtro das políticas de acesso no nível da linha pode ou não fechar toda a tabela.

Recomendamos que você tenha cuidado antes de conceder o papel bigquery.filteredDataViewer em qualquer recurso.

Filtrar colunas particionadas afeta o desempenho

Os filtros da política de acesso no nível da linha não participam da remoção de tabelas particionadas e em cluster.

Se a política de acesso no nível da linha nomear uma coluna particionada, a consulta não receberá os benefícios de desempenho da remoção da consulta.