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

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

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

Restrinja as autorizações do utilizador para limitar os ataques de canal lateral

Um ataque de side-channel é um ataque de segurança baseado em informações obtidas a partir do próprio sistema. Um atacante com autorizações mais amplas do que o necessário pode montar ataques de canal lateral e aprender dados confidenciais observando ou pesquisando mensagens de faturação, registo ou sistema.

Para mitigar essas oportunidades, o BigQuery oculta estatísticas confidenciais em todas as consultas em tabelas com segurança ao nível da linha. Estas estatísticas confidenciais incluem o número de bytes e partições processados, o número de bytes faturados e as fases do plano de consulta.

Recomendamos que os administradores se abstenham de conceder as seguintes autorizações aos utilizadores que só devem ver dados filtrados, para evitar dar acesso a dados confidenciais.

Exemplos

• Através da observação repetida da duração da consulta ao consultar tabelas com políticas de acesso ao nível da linha, um utilizador pode inferir os valores das linhas que, de outra forma, podem estar protegidas por políticas de acesso ao nível da linha. Este tipo de ataque requer muitas tentativas repetidas num intervalo de valores-chave em colunas de particionamento ou agrupamento. Apesar de haver ruído inerente ao observar ou medir a duração da consulta, com tentativas repetidas, um atacante pode obter uma estimativa fiável. Se for sensível a este nível de proteção, recomendamos que use tabelas separadas para isolar linhas com requisitos de controlo de acesso diferentes.
• Um atacante pode pesquisar os bytes processados por uma consulta monitorizando os erros que ocorrem quando os limites de tarefas de consulta (como os bytes faturados máximos ou os controlos de custos personalizados) são excedidos. No entanto, este ataque requer um volume elevado de consultas.
• Através de consultas repetidas e da observação do valor de faturação do BigQuery na faturação do Google Cloud, um utilizador pode inferir os valores das linhas que, de outra forma, podem estar protegidas por políticas de acesso ao nível da linha. Este tipo de ataque requer muitas tentativas repetidas num intervalo de valores-chave em colunas de partição ou agrupamento. Se for sensível a este nível de proteção, recomendamos que limite o acesso aos dados de faturação para consultas.

Também recomendamos que os administradores monitorizem os registos de auditoria da nuvem(/bigquery/docs/reference/auditlogs) para verificar a existência de atividade suspeita em tabelas com segurança ao nível da linha, como adições, modificações e eliminações inesperadas de políticas de acesso ao nível da linha.

Restrinja as autorizações dos utilizadores para limitar a adulteração de dados

Os utilizadores com autorizações de escrita numa tabela podem inserir dados na tabela com o comando bq load ou com a API BigQuery Storage Write. Isto pode permitir que o utilizador com autorizações de escrita altere os resultados da consulta de outros utilizadores.

Recomendamos que os administradores criem grupos Google separados para acesso de escrita a tabelas e políticas de acesso ao nível da linha. Os utilizadores que só devem ver resultados de tabelas filtradas não devem ter acesso de escrita à tabela filtrada.

Evite o acesso inadvertido quando recriar políticas de acesso ao nível da linha

Quando adiciona uma política de acesso ao nível da linha a uma tabela pela primeira vez, começa imediatamente a filtrar dados nos resultados da consulta. Quando remove a última política de acesso ao nível da linha numa tabela, mesmo que pretenda apenas recriar a política de acesso ao nível da linha, pode conceder inadvertidamente acesso não filtrado a um público-alvo mais vasto do que o pretendido.

Recomendamos que os administradores prestem especial atenção quando recriam a última política de acesso ao nível da linha numa tabela, seguindo estas diretrizes:

1. Primeiro, remova todo o acesso à tabela através dos controlos de acesso à tabela.
2. Remova todas as políticas de acesso ao nível da linha.
3. Recrie as políticas de acesso ao nível da linha.
4. Reative o acesso à tabela.

Em alternativa, pode criar primeiro novas políticas de acesso ao nível da linha na tabela e, em seguida, eliminar as políticas de acesso ao nível da linha anteriores que já não são necessárias.

Use a segurança ao nível da linha apenas em organizações, não entre organizações

Não use a funcionalidade de segurança ao nível da linha em várias organizações para ajudar a evitar a fuga de dados através de ataques de canal lateral e para manter um maior controlo sobre o acesso a dados confidenciais.

Para políticas de acesso ao nível da linha de subconsultas, crie e pesquise tabelas em organizações ou projetos. Isto leva a uma melhor segurança e a uma configuração mais simples da ACL, uma vez que os beneficiários têm de ter a autorização bigquery.tables.getData nas tabelas de destino e referenciadas nas políticas, bem como quaisquer autorizações de segurança ao nível da coluna relevantes.

Recomendamos a utilização da funcionalidade de segurança ao nível da linha apenas para restrições de segurança dentro da organização (como para partilhar dados dentro de uma organização/empresa), e não para segurança entre organizações ou pública.

Exemplo

Fora da sua organização, tem menos controlo sobre quem tem acesso aos dados. Na sua organização, pode controlar quem tem acesso às informações de faturação de consultas em tabelas com políticas de acesso ao nível da linha. As informações de faturação são um vetor para ataques de side-channel.

Faça a gestão da função Filtered Data Viewer através de políticas de acesso ao nível da linha

Quando cria uma política de acesso ao nível da linha, os principais na política recebem automaticamente a função bigquery.filteredDataViewer. Só pode adicionar ou remover responsáveis da política de acesso com uma declaração DDL.

A função bigquery.filteredDataViewer não deve ser concedida através do IAM a um recurso de nível superior, como uma tabela, um conjunto de dados ou um projeto. A atribuição da função desta forma permite que os utilizadores vejam as linhas definidas por todas as políticas de acesso ao nível da linha nesse âmbito, independentemente das restrições pretendidas. Embora a união dos filtros da política de acesso ao nível da linha possa não abranger a tabela inteira, esta prática representa um risco de segurança significativo e compromete o objetivo da segurança ao nível da linha.

Recomendamos que faça a gestão da função bigquery.filteredDataViewer exclusivamente através de políticas de acesso ao nível da linha. Este método garante que os principais recebem a função bigquery.filteredDataViewer de forma implícita e correta, respeitando os predicados de filtro definidos para cada política.

Impacto no desempenho dos filtros em colunas particionadas

Os filtros de políticas de acesso ao nível da linha não participam na redução de consultas em tabelas particionadas e agrupadas.

Se a sua política de acesso ao nível da linha nomear uma coluna particionada, a sua consulta não recebe as vantagens de desempenho da eliminação de consultas.