Introdução à segurança no nível da linha do BigQuery

Neste documento, explicamos o conceito de segurança no nível da linha, como ele funciona no BigQuery, quando usar a segurança no nível da linha para proteger dados e outros detalhes.

O que é segurança no nível da linha?

A segurança no nível da linha permite filtrar dados e acessar linhas específicas em uma tabela, com base nas condições de qualificação do usuário.

O BigQuery é compatível com controles de acesso nos níveis de projeto, conjunto de dados e tabela, além da segurança no nível da coluna usando tags de política. A segurança no nível da linha amplia o princípio de privilégio mínimo ao ativar o controle de acesso detalhado a um subconjunto de dados em uma tabela do BigQuery, usando políticas de acesso no nível da linha.

Uma tabela pode ter várias políticas de acesso no nível da linha. As políticas de acesso no nível da linha podem coexistir em uma tabela com segurança no nível da coluna, assim como controles de acesso no nível da tabela, do conjunto de dados e do projeto.

Como funciona a segurança no nível da linha

Em um nível alto, a segurança no nível da linha envolve a criação de políticas de acesso no nível da linha em uma tabela de destino do BigQuery. Essas políticas funcionam como filtros para ocultar ou exibir determinadas linhas de dados, dependendo de se um usuário ou um grupo está em uma lista de permissões. O acesso de todos os usuários ou grupos que não estiverem incluídos especificamente na lista de permissões será negado.

Um usuário autorizado, com os papéis do Identity and Access Management (IAM) BigQuery Admin ou BigQuery DataOwner, pode criar políticas de acesso no nível da linha em uma tabela do BigQuery.

Ao criar uma política de acesso no nível da linha, você especifica a tabela por nome e quais usuários ou grupos (chamados de grantee-list) podem acessar determinados dados da linha. A política também inclui os dados que você quer filtrar, chamados de filter_expression. O filter_expression funciona como uma cláusula WHERE em uma consulta típica.

Para instruções sobre como criar e usar uma política de acesso no nível da linha, consulte Gerenciar a segurança no nível da linha.

Consulte a referência da DDL para ver a sintaxe completa, o uso e as opções ao criar políticas de acesso no nível da linha.

Exemplos de casos de uso

Os exemplos a seguir demonstram possíveis casos de uso para a segurança no nível da linha.

Filtrar dados da linha com base na região

Considere o caso em que uma tabela dataset1.table1 contém linhas pertencentes a regiões diferentes (denotadas pela coluna region).

É possível criar e preencher a tabela de exemplo usando a seguinte consulta:

CREATE TABLE IF NOT EXISTS
  dataset1.table1 (partner STRING,
    contact STRING,
    country STRING,
    region STRING);
INSERT INTO
  dataset1.table1 (partner,
    contact,
    country,
    region)
VALUES
  ('Example Customers Corp', 'alice@examplecustomers.com', 'Japan', 'APAC'),
  ('Example Enterprise Group', 'bob@exampleenterprisegroup.com', 'Singapore', 'APAC'),
  ('Example HighTouch Co.', 'carrie@examplehightouch.com', 'USA', 'US'),
  ('Example Buyers Inc.', 'david@examplebuyersinc.com', 'USA', 'US');

A segurança no nível da linha permite que um proprietário de dados ou administrador implemente políticas. A declaração a seguir implementa uma política que restringe os usuários no grupo de e-mails da APAC a visualizar apenas parceiros da região APAC:

CREATE ROW ACCESS POLICY
  apac_filter
ON
  dataset1.table1 GRANT TO ("group: sales-apac@example.com")
FILTER USING
  (region="APAC" );

O comportamento resultante é que os usuários no grupo sales-apac@example.com podem visualizar apenas as linhas em que o valor de region é APAC.

A declaração a seguir implementa uma política que restringe indivíduos e grupos a visualizar apenas parceiros da região dos EUA:

CREATE ROW ACCESS POLICY
  us_filter
ON
  dataset1.table1 GRANT TO ("group:sales-us@example.com",
"user: jon@example.com")
FILTER USING
  (region="US");

O comportamento resultante é que os usuários no grupo sales-us@example.com e o usuário jon@example.com só podem visualizar linhas em que o valor de region é US.

A imagem a seguir mostra como as duas políticas de acesso anteriores restringem quais usuários e grupos podem visualizar quais linhas na tabela:

Caso de uso de segurança no nível da linha para regiões.

Os usuários que não estão nos grupos APAC ou US não veem linhas.

Filtrar dados de linha com base em dados confidenciais

Agora, considere um caso de uso diferente, em que você tem uma tabela com informações salariais.

É possível criar e preencher a tabela de exemplo usando a seguinte consulta:

CREATE OR REPLACE TABLE
  dataset1.table1 (name STRING,
    department STRING,
    salary INT64,
    email STRING);
INSERT INTO
  dataset1.table1 ( name,
    department,
    salary,
    email)
VALUES
  ('Jim D', 'HR', 100000, 'jim@example.com'),
  ('Anna K', 'Finance', 100000, 'anna@example.com'),
  ('Bruce L', 'Engineering', 100000, 'bruce@example.com'),
  ('Carrie F', 'Business', 100000, 'carrie@example.com');

A política de acesso de linha na instrução a seguir restringe a consulta a membros do domínio da empresa. Além disso, o uso da função SESSION_USER() restringe ainda mais o acesso apenas às linhas que pertencem ao usuário que executa a consulta, com base no próprio endereço de e-mail dele.

CREATE ROW ACCESS POLICY
  salary_personal
ON
  dataset1.table1 GRANT TO ("domain:example.com")
  FILTER USING
  (Email=SESSION_USER());

A imagem a seguir demonstra como a política de acesso de linha restringe a tabela que contém informações de salário. Neste exemplo, o usuário se chama Jim, com o endereço de e-mail jim@example.com.

Caso de uso de segurança no nível da linha para salários

Filtrar dados da linha com base na tabela de consulta

Para enviar feedback ou receber suporte com esse recurso, envie um e-mail para bigquery-row-level-security-support@google.com.

Com suporte a subconsultas, as políticas de acesso de linha podem referenciar outras tabelas e usá-las como tabelas de consulta. Os dados usados nas regras de filtragem podem ser armazenados em uma tabela, e uma única política de acesso de linha da subconsulta pode substituir várias políticas de acesso de linha configuradas. Para atualizar as políticas de acesso de linha, basta atualizar a tabela de consulta, que substitui várias políticas de acesso de linha. Não é preciso atualizar cada política de acesso de linha.

Quando usar a segurança no nível da linha em comparação com outros métodos

As visualizações autorizadas, políticas de acesso no nível da linha e o armazenamento de dados em tabelas separadas fornecem diferentes níveis de segurança, desempenho e conveniência. Escolher o mecanismo correto para o caso de uso é importante para garantir o nível adequado de segurança para os dados.

Comparação com visualizações autorizadas: vulnerabilidades

A segurança no nível da linha e a aplicação do acesso no nível da linha com uma visualização autorizada podem ter vulnerabilidades se usadas incorretamente.

Ao usar visualizações autorizadas ou políticas de acesso no nível da linha para segurança no nível da linha, recomendamos que você monitore qualquer atividade suspeita usando a geração de registros de auditoria.

Canais secundários, como a duração da consulta, podem vazar informações sobre as linhas que estão na borda de um fragmento de armazenamento. Esses ataques provavelmente exigiriam algum conhecimento da fragmentação da tabela ou de um grande número de consultas.

Para mais informações sobre como evitar esses ataques de canal lateral, consulte Práticas recomendadas para segurança no nível da linha.

Comparação de visualizações autorizadas, segurança no nível da linha e tabelas separadas

A tabela a seguir compara o desempenho e a segurança de visualizações autorizadas, políticas de acesso no nível da linha e tabelas separadas.

Método Considerações sobre segurança Recomendação
Visualizações
autorizadas		 Recomendado para flexibilidade. Pode ser vulnerável a consultas criadas com cuidado, durações de consulta e outros tipos de ataques de canal lateral. As visualizações autorizadas são uma boa opção quando você precisa compartilhar dados com outras pessoas e a flexibilidade e o desempenho são importantes. Por exemplo, é possível usar visualizações autorizadas para compartilhar dados no seu grupo de trabalho.
Políticas de acesso no nível da linha Recomendado para equilibrar flexibilidade e segurança. pode ser vulnerável a ataques de canal lateral da duração da consulta (em inglês). As políticas de acesso no nível da linha são uma boa opção quando você precisa compartilhar dados com outras pessoas e quer fornecer segurança adicional a visualizações ou frações da tabela. Por exemplo, é possível usar políticas de acesso no nível da linha para compartilhar dados com pessoas que usam o mesmo painel, mesmo que algumas pessoas tenham acesso a mais dados do que outras.
Tabelas separadas Recomendado por questões de segurança. Os usuários não podem inferir dados sem acessar a tabela. Tabelas separadas são uma boa opção quando você precisa compartilhar dados com outras pessoas e manter os dados isolados. Por exemplo, é possível usar tabelas separadas para compartilhar dados com parceiros e fornecedores terceirizados, quando o número total de linhas precisa ser secreto.

Criar e gerenciar políticas de acesso no nível da linha

Para informações sobre como criar, atualizar (recriar), listar, visualizar e excluir políticas de acesso no nível da linha em uma tabela e como consultar tabelas com políticas de acesso no nível da linha, consulte }Como trabalhar com a segurança de acesso no nível da linha.

Cotas

Para mais informações sobre cotas e limites para segurança no nível da linha, consulte Cotas e limites do BigQuery.

Preços

A segurança no nível da linha está incluída no BigQuery sem custos. No entanto, uma política de acesso no nível da linha pode afetar o custo de executar uma consulta das seguintes maneiras:

  • O faturamento extra pode ser causado por políticas de acesso no nível da linha, especificamente políticas que incluem subconsultas que fazem referência a outras tabelas.

  • 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. Isso não significa que ele lê mais dados durante a execução da consulta principal. Ele não aproveita os predicados da política de acesso de linha para remover mais.

  • Com filtros de política de acesso no nível da linha, nem todos os filtros de usuário são aplicados antecipadamente. Isso pode aumentar os dados lidos das tabelas e pode ler e faturar mais linhas.

Para mais informações sobre os preços de consulta do BigQuery, consulte Preços do BigQuery.

Limitações

Para informações sobre limites de segurança no nível da linha, consulte Limites de segurança no nível da linha do BigQuery. As seções a seguir documentam outras limitações de segurança no nível da linha.

Limitações de desempenho

Para mais informações sobre como a segurança no nível da linha interage com alguns recursos e serviços do BigQuery, consulte Como usar a segurança no nível da linha com outros recursos do BigQuery.

Outras limitações

  • Esse recurso pode não estar disponível ao usar reservas criadas com determinadas edições do BigQuery. Para mais informações sobre quais recursos estão ativados em cada edição, consulte Introdução às edições do BigQuery.

  • As políticas de acesso de linha não são compatíveis com o SQL legado. As consultas de tabelas com políticas de acesso no nível da linha precisam usar o GoogleSQL. As consultas do SQL legado são rejeitadas com um erro.

  • Não é possível aplicar políticas de acesso no nível da linha em colunas JSON.

  • Não é possível aplicar políticas de acesso no nível da linha a tabelas que fazem referência a outras que têm segurança no nível da linha.

  • Alguns recursos do BigQuery não são compatíveis com a segurança no nível da linha. Para mais informações, consulte Como usar a segurança no nível da linha.

  • Operações que não sejam de consulta, incluindo jobs de conta de serviço e que precisam de acesso total aos dados da tabela podem usar a segurança no nível da linha com o filtro TRUE. Exemplos incluem cópia de tabela, fluxos de trabalho do Dataproc e muito mais. Para mais informações, consulte Como usar a segurança no nível da linha.

  • A criação, substituição ou exclusão de políticas de acesso no nível da linha precisa ser executada com instruções DDL. É possível listar e visualizar políticas de acesso no nível da linha no console do Google Cloud ou pela ferramenta de linha de comando bq .

  • Visualizar ou navegar por tabelas é incompatível com a segurança de linha.

  • A amostragem de tabela não é compatível com a segurança no nível da linha.

  • Os resultados da política de subconsulta de nível superior são limitados a 100 MB. Esse limite se aplica por política de acesso no nível da linha.

  • Se o predicado da política de acesso no nível da linha não puder ser avaliado devido à exclusão de qualquer tabela referenciada, a consulta falhará.

  • As políticas de acesso no nível da linha da subconsulta só são compatíveis com tabelas do BigQuery, tabelas externas do BigLake e tabelas gerenciadas do BigLake.

Monitoramento e geração de registros de auditoria

Quando dados em uma tabela com uma ou mais políticas de acesso de linha são lidos, as políticas de acesso de linha autorizadas para acesso de leitura e quaisquer tabelas correspondentes referenciadas nas subconsultas aparecem nas informações de autorização do IAM para essa solicitação de leitura.

A criação e a exclusão de políticas de acesso no nível da linha são registradas por auditoria e podem ser acessadas pelo Cloud Logging. Os registros de auditoria incluem o nome da política de acesso no nível da linha. No entanto, as definições filter_expression e grantee_list de uma política de acesso no nível da linha são omitidas dos registros, porque podem conter informações confidenciais ou do usuário. A listagem e a visualização de políticas de acesso no nível da linha não são registradas em auditoria.

Para mais informações sobre a geração de registros no BigQuery, consulte Introdução ao monitoramento do BigQuery.

Para mais informações sobre a geração de registros no Google Cloud, consulte Cloud Logging.

A seguir