Usar a segurança ao nível da linha com outras funcionalidades do BigQuery
Este documento descreve como usar a segurança de acesso ao nível da linha com outras funcionalidades do BigQuery.
Antes de ler este documento, familiarize-se com a segurança ao nível da linha lendo a Introdução à segurança ao nível da linha do BigQuery e o artigo Trabalhar com a segurança ao nível da linha.
O filtro TRUE
As políticas de acesso ao nível da linha podem filtrar os dados de resultados que vê quando executa consultas. Para executar operações que não sejam de consulta, como DML, precisa de acesso total a todas as linhas da tabela. O acesso total é concedido
através da utilização de uma política de acesso ao nível da linha com a expressão de filtro definida como TRUE
. Esta política de acesso ao nível da linha é denominada filtro TRUE
.
Qualquer utilizador pode receber TRUE
acesso a filtros, incluindo uma conta de serviço.
Seguem-se exemplos de operações que não são de consulta:
- Outras APIs BigQuery, como a API BigQuery Storage Read.
- Alguns comandos da
bq
ferramenta de linha de comandos, como o comandobq head
. - Copiar uma tabela
Exemplo de filtro TRUE
CREATE ROW ACCESS POLICY all_access ON project.dataset.table1
GRANT TO ("group:[email protected]")
FILTER USING (TRUE);
Funcionalidades que funcionam com o filtro TRUE
Quando usa uma operação DML numa tabela protegida por políticas de acesso ao nível da linha, tem de usar um filtro TRUE
, o que implica o acesso a toda a tabela. Todas as operações que não alteram o esquema da tabela mantêm todas as políticas de acesso ao nível da linha na tabela.
Por exemplo, a declaração ALTER TABLE RENAME
TO
copia as políticas de acesso ao nível da linha da tabela original para a nova tabela.
Como outro exemplo, a declaração TRUNCATE
TABLE
remove todas as linhas de uma tabela, mas mantém o esquema da tabela, bem como todas as políticas de acesso ao nível da linha.
Tarefas de cópia
Para copiar uma tabela com uma ou mais políticas de acesso ao nível da linha, primeiro tem de lhe ser concedido TRUE
acesso de filtro
na
tabela de origem. Todas as políticas de acesso ao nível da linha na tabela de origem também são copiadas para a nova tabela de destino. Se copiar uma tabela de origem sem políticas de acesso ao nível da linha para uma tabela de destino que tenha políticas de acesso ao nível da linha, as políticas de acesso ao nível da linha são removidas da tabela de destino, a menos que seja usada a flag --append_table
ou que "writeDisposition": "WRITE_APPEND"
seja definido.
As cópias entre regiões são permitidas e todas as políticas são copiadas. As consultas subsequentes podem ser interrompidas após a conclusão da cópia se contiverem referências de tabelas inválidas nas políticas de subconsultas.
As políticas de acesso ao nível da linha numa tabela têm de ter nomes exclusivos. Uma colisão nos nomes das políticas de acesso ao nível da linha durante a cópia resulta num erro de entrada inválida.
Autorizações necessárias para copiar uma tabela com uma política de acesso ao nível da linha
Para copiar uma tabela com uma ou mais políticas de acesso ao nível da linha, tem de ter as seguintes autorizações, além das funções para copiar tabelas e partições.
Autorizaçã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
Precisa de acesso de filtro para usar o método tabledata.list
na API BigQuery numa tabela com políticas de acesso ao nível da linha.TRUE
DML
Para executar uma declaração DML que atualiza uma tabela com políticas de acesso ao nível da linha, precisa de acesso de filtragem TRUE
para a tabela.
Em particular, as declarações MERGE
interagem com as políticas de acesso ao nível da linha da seguinte forma:
- Se uma tabela de destino contiver políticas de acesso ao nível da linha, tem de
TRUE
filtrar o acesso à tabela de destino. - Se uma tabela de origem contiver políticas de acesso ao nível da linha, a declaração
MERGE
só atua nas linhas visíveis para o utilizador.
Instantâneos de tabelas
Os instantâneos de tabelas suportam a segurança ao nível da linha. As autorizações de que precisa para a tabela base (tabela de origem) e a cópia instantânea da tabela (tabela de destino) são descritas no artigo Autorizações necessárias para copiar uma tabela com uma política de acesso ao nível da linha.
Tabela do BigQuery com colunas JSON
As políticas de acesso ao nível da linha não podem ser aplicadas a colunas JSON. Para saber mais sobre as limitações da segurança ao nível da linha, consulte a secção Limitações.
BigQuery BI Engine e Looker Studio
O BigQuery BI Engine não acelera as consultas executadas em tabelas com uma ou mais políticas de acesso ao nível da linha. Essas consultas são executadas como consultas padrão no BigQuery.
Os dados num painel de controlo do Looker Studio são filtrados de acordo com as políticas de acesso ao nível da linha da tabela de origem subjacente.
Segurança ao nível da coluna
A segurança ao nível da linha e a segurança ao nível da coluna, que incluem o controlo de acesso ao nível da coluna e a ocultação dinâmica de dados, são totalmente compatíveis.
Os pontos-chave são:
- Pode aplicar uma política de acesso ao nível da linha para filtrar dados em qualquer coluna, mesmo que não tenha acesso aos dados nessa coluna.
- As tentativas de aceder a estas colunas com a política de acesso ao nível da linha da subconsulta resultam num erro que indica que o acesso é negado. Estas colunas não são consideradas colunas referenciadas pelo sistema.
- As tentativas de acesso a estas colunas com a política de acesso ao nível da linha sem subconsulta contornam a segurança ao nível da coluna.
- Se a coluna estiver restrita devido à segurança ao nível da coluna e for
mencionada na declaração
SELECT
da consulta ou nas políticas de acesso ao nível da linha da subconsulta, recebe um erro. - A segurança ao nível da coluna também se aplica com uma declaração de consulta
SELECT *
. O elementoSELECT *
é tratado da mesma forma que uma consulta que nomeia explicitamente uma coluna restrita.
Exemplo de interação entre a segurança ao nível da linha e a segurança ao nível da coluna
Este exemplo explica os passos para proteger uma tabela e, em seguida, fazer uma consulta à mesma.
Os dados
Suponhamos que tem a função DataOwner para um conjunto de dados denominado my_dataset
que inclui uma tabela com três colunas, denominada my_table
.
A tabela contém os dados apresentados na tabela seguinte.
Neste exemplo, um utilizador é Alice, cujo endereço de email é
[email protected]
. Um segundo utilizador é o João, colega da Ana.
rank | fruta | cor |
---|---|---|
1 | maçã | vermelho |
2 | cor de laranja | cor de laranja |
3 | lima | verde |
4 | limão | amarelo |
A segurança
Quer que a Alice possa ver todas as linhas com números ímpares na coluna rank
, mas não as linhas com números pares. Não quer que o João veja nenhuma linha, quer sejam pares ou ímpares. Não quer que ninguém veja dados na coluna fruit
.
Para impedir que a Alice veja as linhas com números pares, cria uma política de acesso ao nível da linha com uma expressão de filtro baseada nos dados que aparecem na coluna
rank
. Para impedir que o 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:[email protected]') FILTER USING (MOD(rank, 2) = 1);
Para restringir a visualização de dados na coluna denominada
fruit
, cria uma etiqueta de política de segurança ao nível da coluna que proíbe todos os utilizadores de acederem a quaisquer dos respetivos dados.
Por último, também restringe o acesso à coluna denominada color
de duas formas:
a coluna é regida por uma etiqueta de política de segurança ao nível da coluna que proíbe
o acesso de qualquer pessoa, e é afetada por uma política de acesso ao nível da linha, que
filtra alguns dos dados das linhas na coluna color
.
Esta segunda política de acesso ao nível da linha apenas apresenta linhas com o valor
green
na colunacolor
.CREATE ROW ACCESS POLICY only_green ON my_dataset.my_table GRANT TO ('user:[email protected]') FILTER USING (color="green");
A consulta do Bruno
Se o colega de trabalho da Alice, o Bob, tentar consultar dados de my_dataset.my_table
, não vê nenhuma linha, porque o Bob não está na lista de beneficiários de nenhuma política de acesso ao nível da linha na tabela.
Consulta | my_dataset.my_table
|
Comentários | ||
---|---|---|---|---|
rank (Alguns dados são afetados pela política de acesso ao nível da linha only_odd ) |
fruit (Todos os dados estão protegidos por uma etiqueta de política de CLS) |
color (Todos os dados estão protegidos por uma etiqueta de política CLS e alguns dados são afetados pela política de acesso ao nível da linha only_green ) |
||
SELECT rank FROM my_dataset.my_table
|
(0) linhas devolvidas. |
O Bob não está na lista de beneficiários da política de acesso ao nível da linha;
por conseguinte, esta consulta é bem-sucedida, mas não são devolvidos dados de linhas. É apresentada uma mensagem ao João a indicar que os resultados podem ser filtrados pela política de acesso ao nível da linha. |
Consultas da Alice
Quando a Alice executa consultas para aceder a dados de my_dataset.my_table
, os respetivos resultados dependem da consulta que executa e da segurança, conforme mostrado na tabela seguinte.
Consulta | my_dataset.my_table
|
Comentários | ||
---|---|---|---|---|
rank (Alguns dados são afetados pela política de acesso ao nível da linha only_odd ) |
fruit (Todos os dados estão protegidos por uma etiqueta de política de CLS) |
color (Todos os dados estão protegidos por uma etiqueta de política CLS e alguns dados são afetados pela política de acesso ao nível da linha only_green ) |
||
|
É devolvida 1 linha. |
A Alice está na lista de beneficiários para as políticas de acesso ao nível da linha only_odd e only_green . Por isso, a Alice vê apenas classificações ímpares e cores verdes. Por conseguinte, Alice vê a seguinte linha:
rank: 3, color: green .A Alice não vê a coluna de fruta porque está restrita por uma política de segurança ao nível da coluna. É apresentada uma mensagem à Alice a indicar que os resultados podem ser filtrados pela política de acesso ao nível da linha. |
||
|
|
A coluna fruit foi explicitamente denominada na consulta. A segurança ao nível da coluna aplica-se. Acesso negado. |
||
|
É devolvida 1 linha. |
A Alice está na lista de beneficiários para as políticas de acesso ao nível da linha only_odd e only_green . Por isso, a Alice vê apenas classificações ímpares e cores verdes. Por conseguinte, Alice vê a seguinte linha:
rank: 3, color: green .A Alice não vê a coluna de fruta porque está restrita por uma política de segurança ao nível da coluna. É apresentada uma mensagem à Alice a indicar que os resultados podem ser filtrados pela política de acesso ao nível da linha. |
||
|
|
A coluna fruit foi explicitamente denominada na consulta. A segurança ao nível da coluna aplica-se antes da política de acesso ao nível da linha nos dados na coluna rank .Acesso negado. |
||
|
É devolvida 1 linha. |
A Alice está na lista de beneficiários para as políticas de acesso ao nível da linha only_odd e only_green . Por isso, a Alice vê apenas classificações ímpares e cores verdes. Por conseguinte, Alice vê a seguinte linha:
rank: 3, color: green .A Alice não vê a coluna de fruta porque está restrita por uma política de segurança ao nível da coluna. É apresentada uma mensagem à Alice a indicar que os resultados podem ser filtrados pela política de acesso ao nível da linha. |
||
|
|
A coluna fruit foi explicitamente
denominada na consulta. A segurança ao nível da coluna na coluna fruit aplica-se antes de a política de acesso ao nível da linha nos dados da coluna color ser ativada.Acesso negado. |
||
|
É devolvida 1 linha. |
A Alice está na lista de beneficiários para as políticas de acesso ao nível da linha only_odd e only_green . Por isso, a Alice vê apenas classificações ímpares e cores verdes. Por conseguinte, Alice vê a seguinte linha:
rank: 3, color: green .A Alice não vê a coluna de fruta porque está restrita por uma política de segurança ao nível da coluna. É apresentada uma mensagem à Alice a indicar que os resultados podem ser filtrados pela política de acesso ao nível da linha. |
Acesso ao filtro TRUE
Por último, conforme explicado na
secção acerca do TRUE
acesso ao filtro,
se a Alice ou o Bob tiverem TRUE
acesso ao filtro, podem
ver todas as linhas na tabela e usá-las em tarefas que não sejam de consulta. No entanto, se a tabela tiver segurança ao nível da coluna, esta continua a aplicar-se e pode afetar os resultados.
Gráfico de execução
Não pode usar o gráfico de execução de consultas para tarefas com políticas de acesso ao nível da linha.
Extraia tarefas
Se uma tabela tiver políticas de acesso ao nível da linha, apenas os dados que pode ver são exportados para o Cloud Storage quando executa uma tarefa de extração.
SQL antigo
As políticas de acesso ao nível da linha não são compatíveis com o SQL antigo. As consultas em tabelas com políticas de acesso ao nível da linha têm de usar o GoogleSQL. As consultas SQL antigas são rejeitadas.
Tabelas particionadas e agrupadas
A segurança ao nível da linha não participa na redução de consultas, que é uma funcionalidade das tabelas particionadas.
Embora a segurança ao nível da linha seja compatível com tabelas particionadas e agrupadas, as políticas de acesso ao nível da linha que filtram os dados das linhas não são aplicadas durante a eliminação de partições. Pode continuar a usar a eliminação de partições numa tabela que usa a segurança ao nível da linha especificando uma cláusula WHERE
que opera na coluna de partição. Da mesma forma, as políticas de acesso ao nível da linha não criam vantagens de desempenho para consultas em tabelas agrupadas, mas não interferem com outras filtragens que aplicar.
A eliminação de consultas é realizada durante a execução das políticas de acesso ao nível da linha através dos filtros com as políticas.
Mude o nome de uma tabela
Não precisa de acesso de filtragem TRUE
para mudar o nome de uma tabela com uma ou mais políticas de acesso ao nível da linha. Pode
mudar o nome de uma tabela com uma declaração DDL.
Em alternativa, também pode copiar uma tabela e atribuir um nome diferente à tabela de destino. Se a tabela de origem tiver uma política de acesso ao nível da linha, consulte os trabalhos de cópia de tabelas nesta página para mais informações.
Atualizações de streaming
Para realizar operações de tabelas de streaming UPDATE
ou DELETE
com a captura de dados de alterações, tem de ter acesso ao filtro TRUE
.
Viagem no tempo
Apenas um administrador da tabela pode aceder aos dados do histórico de uma tabela que tenha, ou
já tenha tido, políticas de acesso ao nível da linha. Os outros utilizadores recebem um erro access
denied
se usarem um decorador de viagem no tempo numa tabela que tenha tido acesso ao nível da linha. Para mais informações, consulte os artigos Viagem no tempo e acesso ao nível da linha.
Vistas lógicas, materializadas e autorizadas
Esta secção descreve diferentes tipos de visualizações de propriedade do BigQuery e como interagem com a segurança ao nível da linha.
Vistas lógicas ou materializadas
As vistas lógicas ou materializadas são criadas a partir de consultas em tabelas. Normalmente, os resultados da consulta são um subconjunto dos dados da tabela.
Os dados apresentados em qualquer tipo de vista são filtrados de acordo com as políticas de acesso ao nível da linha da tabela de origem subjacente. No entanto, não pode fazer referência a vistas ou vistas materializadas em políticas de acesso ao nível da linha.
Desempenho das vistas materializadas
Além disso, quando uma vista materializada é derivada de uma tabela subjacente que tem políticas de acesso ao nível da linha, o desempenho da consulta é o mesmo que quando consulta a tabela de origem diretamente. Por outras palavras, se a tabela de origem tiver segurança ao nível das linhas, não vê as vantagens de desempenho típicas da consulta de uma vista materializada em comparação com a consulta da tabela de origem.
Vistas autorizadas
Também pode autorizar uma vista lógica ou materializada, o que significa partilhar a vista com utilizadores ou grupos específicos (diretores). Em seguida, os principais podem consultar uma vista, mas não têm acesso à tabela subjacente. Para mais informações, consulte o artigo Vistas autorizadas.
Consultas com carateres universais
As consultas com carateres universais em tabelas com políticas de acesso ao nível da linha falham com um erro INVALID_INPUT
.
O que se segue?
- Para informações sobre as práticas recomendadas para políticas de acesso ao nível da linha, consulte o artigo Práticas recomendadas para a segurança ao nível da linha no BigQuery.