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 verdadeiro"

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 "TRUE" como filtro. Esse acesso é chamado de "filtro verdadeiro".

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

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

Exemplo

Como criar o "filtro verdadeiro"

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 verdadeiro"

Jobs de cópia

Para copiar uma tabela com uma ou mais políticas de acesso no nível da linha, primeiro você precisa receber o "filtro verdadeiro" 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 serão removidas da tabela de destino.

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 verdadeiro" A tabela de origem.
bigquery.rowAccessPolicies.create A tabela de destino.
bigquery.rowAccessPolicies.setIamPolicy A tabela de destino.

API Storage Read, tabledata.list na API BigQuery

Você precisa de acesso de "filtro verdadeiro" para usar a API Storage Read ou o método tabledata.list na API BigQuery em uma tabela com políticas de acesso no nível da linha.

Para executar cargas de trabalho no Dataproc, que usa a API Storage Read, é preciso ter acesso de "filtro verdadeiro".

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 verdadeiro" à 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, você precisará de acesso de "filtro verdadeiro" à 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. Para mais informações, consulte Viagem no tempo.

BigQuery BI Engine e Google Data 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 Data 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

A segurança no nível da linha e a segurança no nível da coluna 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.

O "filtro verdadeiro"

Por fim, conforme explicado na seção sobre o "filtro verdadeiro", se Alice ou Bob tiver acesso de "filtro verdadeiro", 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 SQL padrão. 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.

Como renomear uma tabela

O "filtro verdadeiro" não é necessário para renomear uma tabela com uma ou mais políticas de acesso de linha. É 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.

Viagem no tempo

O recurso viagem no tempo não é compatível com a segurança no nível da linha. Você receberá um erro accesss denied se usar um decorador de viagem no tempo com uma tabela que tenha ou que já teve uma ou mais políticas de acesso no nível da linha. Se você precisar recuperar dados de tabela usando a viagem no tempo, entre em contato com o Cloud Customer Care.

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