Introdução à segurança ao nível da linha do BigQuery
Este documento explica o conceito de segurança ao nível da linha, como funciona no BigQuery, quando usar a segurança ao nível da linha para proteger os seus dados e outros detalhes.
O que é a segurança ao nível da linha?
A segurança ao nível da linha permite-lhe filtrar dados e ativar o acesso a linhas específicas numa tabela com base nas condições de utilizador qualificadas.
O BigQuery suporta controlos de acesso ao nível do projeto, do conjunto de dados e da tabelaetiquetas de políticas. A segurança ao nível da linha expande o princípio do menor privilégio, permitindo o controlo de acesso detalhado a um subconjunto de dados numa tabela do BigQuery, através de políticas de acesso ao nível da linha.
Uma tabela pode ter várias políticas de acesso ao nível da linha. As políticas de acesso ao nível da linha podem coexistir numa tabela com a ao nível do conjunto de dados, ao nível da tabela> e ao nível do projeto.
Como funciona a segurança ao nível da linha
A um nível elevado, a segurança ao nível da linha envolve a criação de políticas de acesso ao nível da linha numa tabela do BigQuery de destino. Estas políticas funcionam como filtros para ocultar ou apresentar determinadas linhas de dados, consoante um utilizador ou um grupo esteja numa lista permitida. É negado o acesso a todos os utilizadores ou grupos que não estejam especificamente incluídos na lista de permitidos.
TRUE
Um utilizador autorizado, com as funções de gestão de identidades e acessos (IAM) de administrador do BigQuery ou proprietário de dados do BigQuery, pode criar políticas de acesso ao nível da linha numa tabela do BigQuery.
Quando cria uma política de acesso ao nível da linha, especifica a tabela pelo nome e
que utilizadores ou grupos (denominados grantee-list
) podem aceder a determinados
dados das linhas. A política também inclui os dados pelos quais quer filtrar, denominados filter_expression
. A função filter_expression
funciona como uma cláusula WHERE
numa consulta típica.
Para ver instruções sobre como criar e usar uma política de acesso ao nível da linha, consulte o artigo Gerir a segurança ao nível da linha.
Consulte a referência DDL para ver a sintaxe, a utilização e as opções completas quando criar políticas de acesso ao nível da linha.
Exemplos de utilização
Os exemplos seguintes demonstram potenciais exemplos de utilização da segurança ao nível da linha.
Filtre os dados das linhas com base na região
Considere o caso em que a tabela dataset1.table1
contém linhas pertencentes a
diferentes regiões (indicadas pela coluna region
).
Pode criar e preencher a tabela de exemplo com 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 ao nível da linha permite que um proprietário ou um administrador de dados implemente políticas. A seguinte declaração implementa uma política que restringe os utilizadores no grupo de correio da região APAC para verem 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 utilizadores no grupo sales-apac@example.com
só podem ver linhas em que o valor de region
é APAC
.
A declaração seguinte implementa uma política que restringe indivíduos e grupos para verem 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 utilizadores no grupo sales-us@example.com
e o utilizador jon@example.com
só podem ver linhas em que o valor de region
é US
.
A imagem seguinte mostra como as duas políticas de acesso anteriores restringem as linhas que os utilizadores e os grupos podem ver na tabela:
Os utilizadores que não pertencem aos grupos APAC
ou US
não veem nenhuma linha.
Filtre dados de linhas com base em dados confidenciais
Agora, considere um exemplo de utilização diferente, em que tem uma tabela com informações sobre salários.
Pode criar e preencher a tabela de exemplo com 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 ao nível da linha na seguinte declaração restringe as consultas aos membros do domínio da empresa. Além disso, a utilização da função SESSION_USER()
restringe o acesso apenas às linhas que pertencem ao utilizador que executa a consulta, com base no respetivo endereço de email do utilizador.
CREATE ROW ACCESS POLICY salary_personal ON dataset1.table1 GRANT TO ("domain:example.com") FILTER USING (Email=SESSION_USER());
A imagem seguinte demonstra como a política de acesso ao nível da linha restringe a tabela que contém informações sobre salários. Neste exemplo, o utilizador chama-se Jim e tem o endereço de email jim@example.com
.
Filtre dados de linhas com base na tabela de consulta
Com o suporte de subconsultas, as políticas de acesso ao nível da linha podem referenciar outras tabelas e usá-las como tabelas de consulta. Os dados usados nas regras de filtragem podem ser armazenados numa tabela e uma única política de acesso a linhas de subconsulta pode substituir várias políticas de acesso a linhas configuradas. Para atualizar as políticas de acesso ao nível da linha, só tem de atualizar a tabela de consulta, que substitui várias políticas de acesso ao nível da linha. Não tem de atualizar cada política de acesso a linhas individual.
Quando usar a segurança ao nível da linha em comparação com outros métodos
As vistas autorizadas, as políticas de acesso ao nível da linha e o armazenamento de dados em tabelas separadas oferecem diferentes níveis de segurança, desempenho e conveniência. Escolher o mecanismo certo para o seu exemplo de utilização é importante para garantir o nível adequado de segurança para os seus dados.
Comparação com vistas autorizadas: vulnerabilidades
Tanto a segurança ao nível da linha como a aplicação do acesso ao nível da linha com uma vista autorizada podem ter vulnerabilidades, se forem usadas incorretamente.
Quando usa vistas autorizadas ou políticas de acesso ao nível da linha para segurança ao nível da linha, recomendamos que monitorize qualquer atividade suspeita através do registo de auditoria.
Os canais laterais, como a duração da consulta, podem divulgar informações sobre as linhas que estão no limite de um fragmento de armazenamento. Estes ataques exigem provavelmente algum conhecimento sobre como a tabela é dividida ou um grande número de consultas.
Para mais informações sobre como impedir estes ataques de canal lateral, consulte as Práticas recomendadas para a segurança ao nível da linha.
Comparação entre vistas autorizadas, segurança ao nível da linha e tabelas separadas
A tabela seguinte compara a flexibilidade, o desempenho e a segurança das visualizações autorizadas, das políticas de acesso ao nível da linha e das tabelas separadas.
Método | Considerações de segurança | Recomendação |
---|---|---|
Vistas autorizadas |
Recomendado para flexibilidade. Podem ser vulneráveis a consultas cuidadosamente elaboradas, durações de consultas e outros tipos de ataques de canal lateral. | As visualizações autorizadas são uma boa opção quando precisa de partilhar dados com outras pessoas e a flexibilidade e o desempenho são importantes. Por exemplo, pode usar visualizações autorizadas para partilhar dados no seu grupo de trabalho. |
Políticas de acesso ao nível da linha | Recomendado para um equilíbrio entre flexibilidade e segurança. Pode ser vulnerável a ataques de side-channel de duração da consulta. | As políticas de acesso ao nível da linha são uma boa escolha quando precisa de partilhar dados com outras pessoas e quer oferecer segurança adicional em vistas ou fatias de tabelas. Por exemplo, pode usar políticas de acesso ao nível da linha para partilhar dados com pessoas que usam o mesmo painel de controlo, mesmo que algumas pessoas tenham acesso a mais dados do que outras. |
Tabelas separadas | Recomendado para segurança. Os utilizadores não podem inferir dados sem acesso à tabela. | As tabelas separadas são uma boa opção quando precisa de partilhar dados com outras pessoas e manter os dados isolados. Por exemplo, pode usar tabelas separadas para partilhar dados com parceiros e fornecedores externos quando o número total de linhas tiver de ser secreto. |
Crie e faça a gestão de políticas de acesso ao nível da linha
Para obter informações sobre como criar, atualizar (recriar), listar, ver e eliminar políticas de acesso ao nível da linha numa tabela, e como consultar tabelas com políticas de acesso ao nível da linha, consulte o artigo Trabalhar com a segurança de acesso ao nível da linha.
Quotas
Para mais informações acerca das quotas e dos limites da segurança ao nível da linha, consulte o artigo Quotas e limites do BigQuery.
Preços
A segurança ao nível da linha está incluída no BigQuery sem custos adicionais. No entanto, uma política de acesso ao nível da linha pode afetar o custo de execução de uma consulta das seguintes formas:
A faturação adicional pode ser causada por políticas de acesso ao nível da linha, especificamente, políticas que incluem subconsultas que fazem referência a outras tabelas.
Os filtros de políticas de acesso ao nível da linha não participam na eliminação de consultas em tabelas particionadas e agrupadas. Isto não significa que lê mais dados durante a execução da consulta principal. Não tira partido dos predicados da política de acesso ao nível da linha para fazer mais cortes.
Com os filtros de políticas de acesso ao nível da linha, nem todos os filtros de utilizadores são aplicados antecipadamente. Isto pode aumentar os dados lidos das tabelas e pode ler e faturar mais linhas.
Para mais informações acerca dos preços das consultas do BigQuery, consulte o artigo Preços do BigQuery.
Limitações
Para informações sobre os limites da segurança ao nível da linha, consulte o artigo Limites da segurança ao nível da linha do BigQuery. As secções seguintes documentam limitações adicionais de segurança ao nível da linha.
Limitações de desempenho
Algumas funcionalidades do BigQuery não são aceleradas quando trabalha com tabelas que contêm políticas de acesso ao nível da linha, como o BigQuery BI Engine e as vistas materializadas.
A segurança ao nível da linha não participa na redução de consultas, que é uma funcionalidade das tabelas particionadas. Para mais informações, consulte o artigo Tabelas particionadas e agrupadas. Esta limitação não abranda a execução da consulta principal.
Pode verificar uma pequena degradação do desempenho quando consulta tabelas com segurança ao nível das linhas.
Para mais informações sobre a forma como a segurança ao nível da linha interage com algumas funcionalidades e serviços do BigQuery, consulte o artigo Usar a segurança ao nível da linha com outras funcionalidades do BigQuery.
Outras limitações
Esta funcionalidade pode não estar disponível quando usa reservas criadas com determinadas edições do BigQuery. Para mais informações sobre as funcionalidades ativadas em cada edição, consulte o artigo Introdução às edições do BigQuery.
As políticas de acesso ao nível da linha não são compatíveis com o SQL antigo. As consultas de tabelas com políticas de acesso ao nível da linha têm de usar o GoogleSQL. As consultas SQL antigo são rejeitadas com um erro.
Não pode aplicar políticas de acesso ao nível da linha em colunas JSON.
As consultas de tabelas com carateres universais não são suportadas em tabelas com políticas de acesso ao nível da linha.
Não é possível aplicar políticas de acesso ao nível da linha a tabelas temporárias.
Não pode aplicar políticas de acesso ao nível da linha a tabelas que referenciam outras tabelas com segurança ao nível da linha.
Algumas funcionalidades do BigQuery não são compatíveis com a segurança ao nível da linha. Para mais informações, consulte o artigo Usar a segurança ao nível da linha.
- As políticas de acesso ao nível da linha que incorporam subconsultas não são compatíveis com a API BigQuery Storage Read. A API BigQuery Storage Read só suporta predicados de filtro simples.
As operações que não são de consulta, incluindo tarefas de contas de serviço, que precisam de acesso total aos dados das tabelas podem usar a segurança ao nível da linha com o filtro
TRUE
. Alguns exemplos incluem a cópia de tabelas, os fluxos de trabalho do Dataproc e muito mais. Para mais informações, consulte o artigo Usar a segurança ao nível da linha.Pode criar, substituir ou eliminar políticas de acesso ao nível da linha com declarações LDD ou APIs de políticas de acesso ao nível da linha. Também pode realizar todas as ações disponíveis nas APIs de políticas de acesso ao nível da linha na ferramenta de linhas de comando bq. Pode listar e ver as políticas de acesso ao nível da linha naTrusted Cloud consola.
A pré-visualização ou a navegação em tabelas é incompatível com a segurança ao nível das linhas.
A amostragem de tabelas não é compatível com a segurança ao nível das linhas.
Os resultados da política de subconsultas de nível superior estão limitados a 100 MB. Este limite aplica-se por política de acesso ao nível da linha.
As
IN
subconsultas de nível superior em que o tipo desearch_value
éFLOAT
,STRUCT
,ARRAY
,JSON
ouGEOGRAPHY
não estão disponíveis nas políticas de acesso ao nível da linha.Se não for possível avaliar o predicado da política de acesso ao nível da linha devido à eliminação de qualquer tabela referenciada, a consulta falha.
As políticas de acesso ao nível da linha de subconsultas só suportam tabelas do BigQuery, tabelas externas do BigLake e tabelas geridas do BigLake.
As declarações de mudança do nome e eliminação de colunas que modificam o esquema da tabela e podem afetar as políticas de acesso ao nível da linha não são permitidas.
Registo de auditoria e monitorização
Quando os dados numa tabela com uma ou mais políticas de acesso ao nível da linha são lidos, as políticas de acesso ao nível da linha autorizadas para o acesso de leitura e quaisquer tabelas correspondentes referenciadas em subconsultas aparecem nas informações de autorização do IAM para esse pedido de leitura.
A criação e a eliminação de políticas de acesso ao nível da linha são registadas em auditoria e podem ser acedidas através do Cloud Logging. Os registos de auditoria incluem o nome da política de acesso ao nível da linha. No entanto, as definições de filter_expression
e grantee_list
de uma política de acesso ao nível da linha são omitidas dos registos, uma vez que podem conter informações do utilizador ou outras informações confidenciais. A listagem e a visualização de políticas de acesso ao nível da linha não são registadas
em auditoria.
Para mais informações sobre o registo no BigQuery, consulte o artigo Introdução à monitorização do BigQuery.
Para mais informações sobre como iniciar sessão Trusted Cloud, consulte o Cloud Logging.
O que se segue?
Para obter informações sobre a gestão da segurança ao nível da linha, consulte o artigo Use a segurança ao nível da linha.
Para obter informações sobre como a segurança ao nível da linha funciona com outras funcionalidades e serviços do BigQuery, consulte o artigo Usar a segurança ao nível da linha com outras funcionalidades do BigQuery.
Para informações sobre as práticas recomendadas para a segurança ao nível da linha, consulte o artigo Práticas recomendadas para a segurança ao nível da linha no BigQuery.