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 montar ataques de canal lateral e aprender dados sensíveis observando ou pesquisando faturamentos, 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.
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.
  • 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.

Restringir permissões do usuário para limitar a adulteração de dados

Os usuários com permissões de gravação em uma tabela podem inserir dados na tabela com o comando bq load ou com a API do BigQuery Storage Write. Isso pode permitir que o usuário com permissões de gravação altere os resultados da consulta de outros usuários.

Recomendamos que os administradores criem grupos separados do Google para políticas de acesso de nível de linha e gravação de tabela. Os usuários que devem ver somente resultados de tabela filtrados não têm acesso de gravação a ela.

Evitar o acesso inadvertido 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.
  4. Reative o acesso à 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.

Para políticas de acesso de subconsulta no nível da linha, crie e pesquise tabelas em organizações ou projetos. Isso melhora a segurança e a configuração da ACL, já que os beneficiários precisam ter a permissão bigquery.tables.getData nas tabelas de destino e referenciadas nas políticas, além de qualquer segurança relevante no nível da coluna.

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.

Gerenciar o papel Filtered Data Viewer com políticas de acesso no nível da linha

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 participantes da política de acesso com uma instrução DDL.

O papel bigquery.filteredDataViewer não pode ser concedido pelo IAM a um recurso de nível superior, como tabela, conjunto de dados ou projeto. A concessão da função dessa forma permite que os usuários acessem as linhas definidas por todas as políticas de acesso no nível da linha dentro desse escopo, independentemente das restrições pretendidas. Embora a união de filtros de política de acesso no nível da linha não abranja a tabela inteira, essa prática representa um risco de segurança significativo e prejudica o propósito da segurança no nível da linha.

Recomendamos gerenciar o papel bigquery.filteredDataViewer exclusivamente com políticas de acesso no nível da linha. Esse método garante que os principais sejam concedidos o papel bigquery.filteredDataViewer de forma implícita e correta, respeitando os predicados de filtro definidos para cada política.

Impacto dos filtros no desempenho de colunas particionadas

Os filtros de 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.