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:
- Outras APIs do BigQuery, como a API BigQuery Storage Read .
- Alguns comandos da
ferramenta de linha de comando
bq
, como o comandobq head
. - Como copiar uma tabela
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 *
. OSELECT *
é 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 colunacolor
.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 ) |
||
|
(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. |
||
|
|
A coluna fruit foi nomeada explicitamente na consulta. A segurança no nível da coluna é aplicada. Acesso negado. |
||
|
|
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. |
||
|
|
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. |
||
|
|
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. |
||
|
|
|
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. |
|
|
|
|
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
- Para mais informações sobre as práticas recomendadas para políticas de acesso no nível da linha, consulte Práticas recomendadas de segurança no nível da linha no BigQuery.