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 acionar ataques de canal lateral mais facilmente 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.
| 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:
- Primeiro, remova todo o acesso à tabela usando os controles de acesso à tabela.
- Remova todas as políticas de acesso no nível da linha.
- Recrie as políticas de acesso no nível da linha que você quer.
- 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.
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.