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.

Considerações sobre o design da política de acesso de linha

Ao configurar políticas de acesso de linha em uma tabela, você precisa de pelo menos duas políticas:

• Uma política que concede acesso à tabela. A primeira política de acesso de linha deve conceder acesso a usuários e grupos que exigem acesso total aos dados na tabela para manutenção ou suporte de dados. Por exemplo, seus administradores do BigQuery e contas de serviço que usam instruções DML para transformar dados da tabela.
• Uma segunda política que usa filtros com base na lógica de negócios e é concedida a grupos específicos.

Para mais informações sobre como configurar políticas de acesso de linha, consulte Criar ou atualizar uma política de acesso no nível da linha.

Testar contas de serviço com políticas de acesso de linha

Use a identidade temporária de conta de serviço para testar como as políticas de acesso de linha são aplicadas. Para testar as políticas de acesso de linha usando uma conta de serviço, faça o seguinte:

1. Crie uma conta de serviço.
2. Atualize a política de acesso de linha para conceder acesso à conta de serviço. Como alternativa, adicione a conta de serviço ao Grupo do Google que recebe acesso pela política de acesso de linha.
3. Use a identidade temporária de conta de serviço para validar se a política de acesso de linha está funcionando conforme o esperado.

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 acionar ataques de canal lateral e aprender dados sensíveis observando ou pesquisando faturamentos, gerações de registros ou mensagens de sistemas.

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.

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 acesso de gravação de tabela e políticas de acesso no nível da linha. Os usuários que só devem ver resultados de tabelas filtradas não podem ter acesso de gravação à tabela filtrada.

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, você pode primeiro criar novas políticas de acesso no nível da linha na tabela e, em seguida, excluir as políticas de acesso no nível da linha anteriores 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 lateral e manter um maior controle sobre o acesso a dados sensíveis.

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 usando 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 bigquery.filteredDataViewer papel. Só é possível adicionar ou remover principais 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. Conceder o papel dessa forma permite que os usuários visualizem linhas definidas por todas as políticas de acesso no nível da linha nesse escopo, independentemente das restrições pretendidas. Embora a união dos filtros de política de acesso no nível da linha não abranja toda a tabela, essa prática representa um risco de segurança significativo e prejudica a finalidade da segurança no nível da linha.

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

Impacto no desempenho de filtros em colunas particionadas

Os filtros de política de acesso no nível da linha não participam da remoção de consultas em 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.