Como usar a segurança no nível da linha com outros recursos do BigQuery

Neste documento, você verá como usar a segurança de acesso no nível da linha com outros recursos do BigQuery.

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.

O filtro TRUE.

As políticas de acesso no nível da linha podem filtrar os dados do resultado vistos ao executar consultas. Para executar operações não relacionadas a consultas, como a DML, é necessário ter acesso total a todas as linhas da tabela. O acesso total é concedido usando uma política de acesso de linha com a expressão de filtro definida como TRUE. Essa política de acesso no nível da linha é chamada de filtro TRUE.

Qualquer usuário pode receber acesso ao filtro TRUE, incluindo uma conta de serviço.

Exemplos de operações não consulta são:

Exemplo

Criar o filtro TRUE

CREATE ROW ACCESS POLICY all_access ON project.dataset.table1
GRANT TO ("group:all-rows-access@example.com")
FILTER USING (TRUE);

Recursos que funcionam com o filtro TRUE

Jobs de cópia

Para copiar uma tabela que tenha uma ou mais políticas de acesso da linha, é necessário ter acesso de filtro TRUE na tabela de origem. Todas as políticas de acesso no nível da linha na tabela de origem também são copiadas para a nova tabela de destino. Se você copiar uma tabela de origem sem políticas de acesso no nível da linha para uma tabela de destino que tenha políticas de acesso no nível da linha, as políticas de acesso no nível da linha vão ser removidas da tabela de destino, a menos que--append_table seja usada ou"writeDisposition": "WRITE_APPEND" esteja definido.

As políticas de acesso no nível da linha em uma tabela precisam ter nomes exclusivos. Um conflito em nomes de políticas de acesso no nível da linha durante a cópia resulta em um erro de entrada inválido.

Permissões necessárias para copiar uma tabela com uma política de acesso no nível da linha

Para copiar uma tabela com uma ou mais políticas de acesso no nível da linha, é necessário ter as seguintes permissões, além das permissões necessárias para copiar uma tabela sem uma política de acesso no nível da linha.

Permissão Recurso
bigquery.rowAccessPolicies.list A tabela de origem.
bigquery.rowAccessPolicies.getIamPolicy A tabela de origem.
O filtro TRUE. A tabela de origem.
bigquery.rowAccessPolicies.create A tabela de destino.
bigquery.rowAccessPolicies.setIamPolicy A tabela de destino.

Tabledata.list na API BigQuery

Você precisa de acesso ao filtro TRUE para usar o método tabledata.list na API BigQuery em uma tabela com políticas de acesso no nível da linha.

DML

Para executar uma instrução DML que atualiza uma tabela que tem políticas de acesso no nível da linha, é necessário ter o acesso de filtro TRUE à tabela.

As instruções MERGE interagem com as políticas de acesso no nível da linha da seguinte maneira:

  • Se uma tabela de destino contiver políticas de acesso no nível da linha, será necessário ter acesso de filtro TRUE à tabela de destino.
  • Se uma tabela de origem contiver políticas de acesso no nível da linha, a instrução MERGE agirá apenas nas linhas visíveis para o usuário.

Snapshots da tabela

Os snapshots da tabela são compatíveis com a segurança no nível da linha. As permissões necessárias para a tabela base (tabela de origem) e para o snapshot da tabela (tabela de destino) são descritas em Permissões necessárias para copiar uma tabela com uma política de acesso no nível da linha.

A viagem no tempo não é compatível com tabelas base que têm uma ou mais políticas de segurança no nível da linha.

Tabela do BigQuery com colunas JSON

Não é possível aplicar políticas de acesso no nível da linha em colunas JSON. Para saber mais sobre as limitações da segurança no nível da linha, consulte Limitações.

BigQuery BI Engine e Looker Studio

O BigQuery BI Engine não acelera consultas executadas em tabelas com uma ou mais políticas de acesso no nível da linha. Essas consultas são executadas como consultas padrão no BigQuery.

Os dados em um painel do Looker Studio são filtrados de acordo com as políticas de acesso no nível de linha da tabela de origem subjacente.

Segurança no nível da coluna

As soluções no nível da linha e da coluna, que incluem controle de acesso no nível da coluna e mascaramento de dados dinâmicos, são totalmente compatíveis.

Os pontos principais são:

  • É possível aplicar uma política de acesso no nível da linha para filtrar dados em qualquer coluna, mesmo se você não tiver acesso aos dados nessa coluna.
  • Se a coluna estiver restrita devido à segurança no nível da coluna e ela estiver nomeada na instrução SELECT da consulta, você verá um erro de acesso negado.
  • A segurança no nível da coluna também se aplica a uma instrução de consulta SELECT *. O SELECT * é tratado da mesma forma que uma consulta que nomeia explicitamente uma coluna restrita.

Exemplo de segurança no nível da linha e interação de segurança no nível da coluna

Neste exemplo, você conhecerá as etapas para proteger uma tabela e, em seguida, consultá-la.

Os dados

Suponha que você tenha o papel DataOwner em um conjunto de dados chamado my_dataset que inclui uma tabela com três colunas, chamada my_table. A tabela contém os dados exibidos na tabela a seguir.

Neste exemplo, um usuário é Alice, cujo endereço de e-mail é alice@example.com. A segunda pessoa é Bob, colega de Alice.

rank fruta cor
1 maçã vermelho
2 laranja laranja
3 limão amarelo
4 verde-limão green

A segurança

Você quer que Alice veja todas as linhas com números ímpares na coluna rank, mas sem linhas numeradas. Você não quer que Bob veja nenhuma linha, par ou ímpar. Você não quer que ninguém veja dados na coluna fruit.

  • Para impedir que Alice veja as linhas com números pares, crie uma política de acesso no nível da linha que tenha uma expressão de filtro com base nos dados exibidos na coluna rank. Para impedir que Bob veja linhas pares ou ímpares, não o inclua na lista de beneficiários.

    CREATE ROW ACCESS POLICY only_odd ON my_dataset.my_table GRANT
TO ('user:alice@example.com') FILTER USING (MOD(rank, 2) = 1);

  • Para impedir que todos os usuários vejam dados na coluna chamada fruit, crie uma tag de política de segurança no nível da coluna que proíba todos os usuários de acessar qualquer um dos dados deles.

Por fim, você também restringe o acesso à coluna chamada color de duas maneiras: a coluna é governada pelas duas tags de política de segurança no nível da coluna que impede todo o acesso por qualquer pessoa, e é afetada por uma política de acesso no nível da linha, que filtra alguns dos dados da linha na coluna color.

  • Essa segunda política de acesso no nível da linha exibe apenas linhas com o valor green na coluna color.

    CREATE ROW ACCESS POLICY only_green ON my_dataset.my_table
GRANT TO ('user:alice@example.com') FILTER USING (color="green");

Consulta de Bob

Se o colega de trabalho de Alice tentar consultar dados de my_dataset.my_table, ele não verá nenhuma linha, porque não está na lista de beneficiários de qualquer política de acesso no nível de linha na tabela.

Consulta my_dataset.my_table Comentários
rank

(Alguns dados são afetados pela política de acesso da linha only_odd)		 fruit

(Todos os dados são protegidos por uma tag de política de CLS)		 color

(Todos os dados são protegidos por uma tag de política de CLS e alguns dados são afetados pela política de acesso da linha only_green)
SELECT rank FROM my_dataset.my_table
(0) linhas retornadas.		 Bob não está na lista de beneficiários da política de acesso no nível da linha. Portanto, a consulta é realizada, mas nenhum dado de linha é retornado.

Uma mensagem é exibida para Bob dizendo que os resultados dele podem ser filtrados pela política de acesso da linha.

Consultas de Alice

Quando Alice executa consultas para acessar dados de my_dataset.my_table, os resultados dependem da consulta executada e da segurança, conforme mostrado na tabela a seguir.

Consulta my_dataset.my_table Comentários
rank

(Alguns dados são afetados pela política de acesso da linha only_odd)		 fruit

(Todos os dados são protegidos por uma tag de política de CLS)		 color

(Todos os dados são protegidos por uma tag de política de CLS e alguns dados são afetados pela política de acesso da linha only_green)

SELECT rank FROM my_dataset.my_table


(2) linhas com um número ímpar são retornadas.		 Alice está na lista de beneficiários da política de acesso no nível da linha only_odd de dados na coluna de classificação. Portanto, Alice vê apenas os dados de linha de número ímpar. As linhas com numeração par são ocultas pela política de acesso no nível da linha chamada only_odd.

Uma mensagem é exibida para Alice dizendo que os resultados dela podem ser filtrados pela política de acesso de linha.

SELECT fruit FROM my_dataset.my_table


access denied

A coluna fruit foi nomeada explicitamente na consulta.

A segurança no nível da coluna é aplicada.

Acesso negado.

SELECT color FROM my_dataset.my_table


access denied

A coluna color foi nomeada explicitamente na consulta.

A segurança no nível da coluna se aplica, antes de a política de acesso no nível da linha nos dados da coluna color ser acionada.

Acesso negado.

SELECT rank, fruit FROM my_dataset.my_table


access denied

A coluna "fruit" foi nomeada explicitamente na consulta.

A segurança no nível da coluna se aplica, antes de a política de acesso no nível da linha nos dados da coluna rank ser acionada.

Acesso negado.

SELECT rank, color FROM my_dataset.my_table


access denied

A coluna color foi nomeada explicitamente na consulta.

A segurança no nível da coluna color é aplicada antes de políticas de acesso no nível da linha nos dados do rank e as colunas color serem envolvidas.

Acesso negado.

SELECT fruit, color FROM my_dataset.my_table


access denied


access denied

As colunas fruit e color foram nomeadas explicitamente na consulta.

A segurança no nível das coluna fruit e color é aplicada antes da política de acesso no nível da linha nos dados na coluna color ser envolvida.

Acesso negado.

SELECT * FROM my_dataset.my_table


access denied


access denied

As colunas fruit e color foram nomeadas implicitamente usando "SELECT *" na consulta.

A segurança no nível das colunas fruit e color é aplicada antes das políticas de acesso no nível da linha nos dados nas colunas rank ou color serem engajadas.

Acesso negado.

Acesso de filtro TRUE

Por fim, conforme explicado na seção sobre o acesso de filtro TRUE, se Alice ou Bob tiver acesso de filtro TRUE, eles poderão ver todas as linhas na tabela e usá-la em jobs que não são de consulta. No entanto, se a tabela tiver segurança no nível da coluna, ela ainda será aplicada e poderá afetar os resultados.

Jobs de extração

Se uma tabela tiver políticas de acesso no nível da linha, somente os dados que você poderá visualizar serão exportados para o Cloud Storage quando você executar um job de extração.

SQL legado

As políticas de acesso no nível da linha não são compatíveis com o SQL legado. As consultas em tabelas com políticas de acesso no nível da linha precisam usar o GoogleSQL. As consultas SQL legadas serão rejeitadas.

Tabelas particionadas e em cluster

A segurança no nível da linha não participa da remoção de consultas, que é um recurso das tabelas particionadas.

Embora a segurança no nível da linha seja compatível com tabelas particionadas e em cluster, as políticas de acesso no nível da linha que filtram os dados da linha não são aplicadas durante a remoção da partição. Ainda é possível usar a remoção de partições em uma tabela que utiliza a segurança no nível da linha especificando uma cláusula WHERE que opere na coluna da partição. Da mesma forma, as políticas de acesso no nível da linha por si só não criam nenhum benefício de desempenho para consultas nas tabelas em cluster, mas não interferem em outros filtros aplicados por você.

Renomear uma tabela

Não é necessário ter acesso de filtro TRUE para renomear uma tabela com uma ou mais políticas de acesso de linha nela. É possível renomear uma tabela com uma instrução DDL.

Como alternativa, é possível copiar uma tabela e atribuir um nome diferente à tabela de destino. Se a tabela de origem tiver uma política de acesso no nível da linha, consulte os jobs de cópia de tabela nesta página para mais informações.

atualizações de streaming

Para executar operações de tabela de streaming UPDATE ou DELETE com captura de dados de alteração, é necessário ter acesso ao filtro TRUE.

Viagem no tempo

Somente o administrador de uma tabela pode acessar dados históricos de uma tabela que já tenha políticas de acesso no nível da linha. Outros usuários receberão um erro accesss denied se usarem um decorador de viagem no tempo em uma tabela que teve acesso no nível da linha. Para mais informações, consulte Viagem no tempo e acesso no nível da linha.

Visualizações e visualizações materializadas

Os dados exibidos em uma visualização ou visualização materializada são filtrados de acordo com as políticas de acesso no nível da linha da tabela de origem subjacente.

Além disso, quando uma visualização materializada é derivada de uma tabela subjacente que tem políticas de acesso no nível da linha, o desempenho da consulta é o mesmo de quando a tabela de origem é consultada diretamente. Em outras palavras, se a tabela de origem tiver segurança no nível da linha, você não verá os benefícios de desempenho típicos de consultar uma visualização materializada em comparação à tabela de origem.

Consultas com caracteres curinga

As consultas com caracteres curinga em tabelas com políticas de acesso no nível da linha falham com um erro INVALID_INPUT.

A seguir