Introdução à ocultação de dados

O BigQuery suporta ocultação de dados ao nível da coluna. Pode usar a ocultação de dados para obscurecer seletivamente os dados das colunas para grupos de utilizadores, ao mesmo tempo que lhes permite o acesso à coluna. A funcionalidade de ocultação de dados baseia-se no controlo de acesso ao nível da coluna, pelo que deve familiarizar-se com essa funcionalidade antes de continuar.

Quando usa a ocultação de dados em combinação com o controlo de acesso ao nível da coluna, pode configurar um intervalo de acesso aos dados das colunas, desde o acesso total ao acesso nulo, com base nas necessidades de diferentes grupos de utilizadores. Por exemplo, para os dados do número de identificação fiscal, pode querer conceder ao seu grupo de contabilidade acesso total, ao seu grupo de analistas acesso oculto e ao seu grupo de vendas nenhum acesso.

Vantagens

A ocultação de dados oferece as seguintes vantagens:

• Simplifica o processo de partilha de dados. Pode ocultar colunas confidenciais para poder partilhar tabelas com grupos maiores.
• Ao contrário do controlo de acesso ao nível da coluna, não precisa de modificar as consultas existentes excluindo as colunas às quais o utilizador não pode aceder. Quando configura a ocultação de dados, as consultas existentes ocultam automaticamente os dados das colunas com base nas funções concedidas ao utilizador.
• Pode aplicar políticas de acesso aos dados em grande escala. Pode escrever uma política de dados, associá-la a uma etiqueta de política e aplicar a etiqueta de política a qualquer número de colunas.
• Permite o controlo de acesso baseado em atributos. Uma etiqueta de política anexada a uma coluna fornece acesso a dados contextuais, que é determinado pela política de dados e pelos principais associados a essa etiqueta de política.

Fluxo de trabalho de ocultação de dados

Existem duas formas de ocultar dados. Pode criar uma taxonomia e etiquetas de políticas e, em seguida, configurar políticas de dados nas etiquetas de políticas. Em alternativa, pode definir uma política de dados diretamente numa coluna Pré-visualizar. Isto permite-lhe mapear uma regra de ocultação de dados nos seus dados sem processar etiquetas de políticas nem criar taxonomias adicionais.

Defina uma política de dados diretamente numa coluna

Pode configurar a ocultação de dados dinâmicos diretamente numa coluna (Pré-visualização). Para o fazer, siga os seguintes passos:

1. Crie uma política de dados.

2. Atribua uma política de dados a uma coluna.

Mascare dados com etiquetas de políticas

A Figura 1 mostra o fluxo de trabalho para configurar a ocultação de dados:

Figura 1. Componentes de ocultação de dados.

Siga estes passos para configurar a ocultação de dados:

1. Configure uma taxonomia e uma ou mais etiquetas de políticas.

2. Configure as políticas de dados para as etiquetas de políticas. Uma política de dados mapeia uma regra de ocultação de dados e um ou mais responsáveis, que representam utilizadores ou grupos, para a etiqueta de política.

   Quando cria uma política de dados através da Trusted Cloud consola, cria a regra de ocultação de dados e especifica os responsáveis num único passo. Quando cria uma política de dados através da API BigQuery Data Policy, cria a política de dados e a regra de ocultação de dados num único passo e especifica os responsáveis pela política de dados num segundo passo.

3. Atribua as etiquetas de políticas a colunas em tabelas do BigQuery para aplicar as políticas de dados.

4. Atribua aos utilizadores que devem ter acesso aos dados ocultados a função de leitor ocultado do BigQuery. Como prática recomendada, atribua a função de leitor com máscara do BigQuery ao nível da política de dados. A atribuição da função ao nível do projeto ou superior concede aos utilizadores autorizações para todas as políticas de dados no âmbito do projeto, o que pode originar problemas causados por autorizações excessivas.

   A etiqueta de política associada a uma política de dados também pode ser usada para o controlo de acesso ao nível da coluna. Nesse caso, a etiqueta de política também está associada a um ou mais responsáveis que têm a função de leitor detalhado do catálogo de dados atribuída. Isto permite que estes principais acedam aos dados originais das colunas sem ocultação.

A Figura 2 mostra como o controlo de acesso ao nível da coluna e a ocultação de dados funcionam em conjunto:

Figura 2. Componentes de ocultação de dados.

Para mais informações sobre a interação de funções, consulte o artigo Como as funções de leitor detalhado e leitor com máscara interagem. Para mais informações sobre a herança de etiquetas de políticas, consulte o artigo Funções e hierarquia de etiquetas de políticas.

Regras de ocultação de dados

Quando usa a ocultação de dados, é aplicada uma regra de ocultação de dados a uma coluna no momento da execução da consulta, com base na função do utilizador que executa a consulta. A ocultação tem precedência sobre quaisquer outras operações envolvidas na consulta. A regra de ocultação de dados determina o tipo de ocultação de dados aplicado aos dados da coluna.

Pode usar as seguintes regras de ocultação de dados:

• Rotina de ocultação personalizada. Devolve o valor da coluna após aplicar uma função definida pelo utilizador (UDF) à coluna. São necessárias autorizações de rotina para gerir a regra de ocultação. Esta regra, por definição, suporta todos os tipos de dados do BigQuery exceto o tipo de dados STRUCT. No entanto, o suporte para tipos de dados diferentes de STRING e BYTES é limitado. O resultado depende da função definida.

  Para mais informações sobre a criação de FDU para rotinas de ocultação personalizadas, consulte o artigo Crie rotinas de ocultação personalizadas.

• Máscara do ano da data. Devolve o valor da coluna após truncar o valor para o respetivo ano, definindo todas as partes do valor que não sejam o ano para o início do ano. Só pode usar esta regra com colunas que usem os tipos de dados DATE, DATETIME e TIMESTAMP. Por exemplo:

  Tipo	Original	Oculto
  DATE	2030-07-17	2030-01-01
  DATETIME	2030-07-17T01:45:06	2030-01-01T00:00:00
  TIMESTAMP	2030-07-17 01:45:06	2030-01-01 00:00:00

• Valor de ocultação predefinido. Devolve um valor de ocultação predefinido para a coluna com base no tipo de dados da coluna. Use esta opção quando quiser ocultar o valor da coluna, mas revelar o tipo de dados. Quando esta regra de ocultação de dados é aplicada a uma coluna, torna-a menos útil nas operações de consulta JOIN para utilizadores com acesso de leitor oculto. Isto acontece porque um valor predefinido não é suficientemente único para ser útil quando junta tabelas.

  A tabela seguinte mostra o valor de ocultação predefinido para cada tipo de dados:

  Tipo de dados	Valor de ocultação predefinido
  STRING	""
  BYTES	b''
  INTEGER	0
  FLOAT	0.0
  NUMERIC	0
  BOOLEAN	FALSE
  TIMESTAMP	1970-01-01 00:00:00 UTC
  DATE	1970-01-01
  TIME	00:00:00
  DATETIME	1970-01-01T00:00:00
  GEOGRAPHY	POINT(0 0)
  BIGNUMERIC	0
  ARRAY	[]
  STRUCT	NOT_APPLICABLE Não é possível aplicar etiquetas de políticas a colunas que usam o tipo de dados STRUCT, mas podem ser associadas aos campos finais dessas colunas.
  JSON	nulo

• Máscara de email. Devolve o valor da coluna após substituir o nome de utilizador de um email válido por XXXXX. Se o valor da coluna não for um endereço de email válido, devolve o valor da coluna depois de ter sido executado através da função de hash SHA-256. Só pode usar esta regra com colunas que usem o tipo de dados STRING. Por exemplo:

  Original	Oculto
  abc123@gmail.com	XXXXX@gmail.com
  randomtext	jQHDyQuj7vJcveEe59ygb3Zcvj0B5FJINBzgM6Bypgw=
  test@gmail@gmail.com	Qdje6MO+GLwI0u+KyRyAICDjHbLF1ImxRqaW08tY52k=

• Quatro primeiros carateres. Devolve os primeiros 4 carateres do valor da coluna, substituindo o resto da string por XXXXX. Se o valor da coluna for igual ou inferior a 4 carateres, devolve o valor da coluna após a execução da função de hash SHA-256. Só pode usar esta regra com colunas que usem o tipo de dados STRING.

• Hash (SHA-256). Devolve o valor da coluna depois de ter sido executado através da função de hash SHA-256. Use esta opção quando quiser que o utilizador final possa usar esta coluna numa operação JOIN para uma consulta. Só pode usar esta regra com colunas que usem os tipos de dados STRING ou BYTES.

  A função SHA-256 usada na ocultação de dados preserva o tipo, pelo que o valor de hash devolvido tem o mesmo tipo de dados que o valor da coluna. Por exemplo, o valor hash de um valor de coluna STRING também tem um tipo de dados STRING.

• Últimos quatro carateres. Devolve os últimos 4 carateres do valor da coluna, substituindo o resto da string por XXXXX. Se o valor da coluna for igual ou inferior a 4 carateres, devolve o valor da coluna depois de ter sido executado através da função de hash SHA-256. Só pode usar esta regra com colunas que usem o tipo de dados STRING.

• Anular. Devolve NULL em vez do valor da coluna. Use esta opção quando quiser ocultar o valor e o tipo de dados da coluna. Quando esta regra de ocultação de dados é aplicada a uma coluna, torna-a menos útil nas operações de consulta JOIN para utilizadores com acesso de leitor oculto. Isto acontece porque um valor não é suficientemente único para ser útil quando junta tabelas.NULL

Hierarquia das regras de ocultação de dados

Pode configurar até nove políticas de dados para uma etiqueta de política, cada uma com uma regra de ocultação de dados diferente associada. Uma destas políticas está reservada para definições de controlo de acesso ao nível da coluna. Isto permite que várias políticas de dados sejam aplicadas a uma coluna na consulta de um utilizador, com base nos grupos dos quais o utilizador é membro. Quando isto acontece, o BigQuery escolhe a regra de ocultação de dados a aplicar com base na seguinte hierarquia:

1. Rotina de ocultação personalizada
2. Hash (SHA-256)
3. Máscara de email
4. Últimos quatro carateres
5. Primeiros quatro carateres
6. Máscara de ano da data
7. Valor de ocultação predefinido
8. Anular

Por exemplo, o utilizador A é membro dos grupos de funcionários e de contabilidade. O utilizador A executa uma consulta que inclui o campo sales_total, ao qual foi aplicada a etiqueta de política confidential. A etiqueta de política confidential tem duas políticas de dados associadas: uma que tem a função de funcionários como principal e aplica a regra de ocultação de dados de anulação, e outra que tem a função de contabilidade como principal e aplica a regra de ocultação de dados de hash (SHA-256). Neste caso, a regra de ocultação de dados de hash (SHA-256) tem prioridade sobre a regra de ocultação de dados de anulação, pelo que a regra de hash (SHA-256) é aplicada ao valor do campo sales_total na consulta do utilizador A.

A Figura 3 mostra este cenário:

Figura 3. Priorização de regras de ocultação de dados.

Funções e permissões

Funções para gerir taxonomias e etiquetas de políticas

Precisa da função de administrador de etiquetas de políticas do catálogo de dados para criar e gerir taxonomias e etiquetas de políticas.

Funções para criar e gerir políticas de dados

Precisa de uma das seguintes funções do BigQuery para criar e gerir políticas de dados:

Funções para anexar etiquetas de políticas a colunas

Precisa das autorizações datacatalog.taxonomies.get e bigquery.tables.setCategory para anexar etiquetas de políticas a colunas. datacatalog.taxonomies.get está incluída nas funções de administrador e leitor de etiquetas de políticas do Data Catalog. bigquery.tables.setCategory está incluída nas funções de administrador do BigQuery (roles/bigquery.admin) e proprietário de dados do BigQuery (roles/bigquery.dataOwner).

Funções para consultar dados ocultados

Precisa da função de leitor com máscara do BigQuery para consultar os dados de uma coluna à qual foi aplicada a ocultação de dados.

Como as funções de leitor anónimo e leitor detalhado interagem

A ocultação de dados baseia-se no controlo de acesso ao nível da coluna. Para uma determinada coluna, é possível ter alguns utilizadores com a função de leitor com máscara do BigQuery que lhes permite ler dados com máscara, alguns utilizadores com a função de leitor detalhado do Data Catalog que lhes permite ler dados sem máscara, alguns utilizadores com ambas e alguns utilizadores sem nenhuma. Estas funções interagem da seguinte forma:

• Utilizador com as funções de leitor detalhado e leitor oculto: o que o utilizador vê depende do local na hierarquia de etiquetas de políticas onde cada função é concedida. Para mais informações, consulte o artigo Herança de autorização numa hierarquia de etiquetas de políticas.
• Utilizador com a função Leitor detalhado: pode ver dados de colunas não ocultados (sem ocultação).
• Utilizador com a função Leitor com dados ocultados: pode ver dados de colunas ocultados (obscurecidos).
• Utilizador sem nenhuma das funções: autorização recusada.

No caso em que uma tabela tem colunas protegidas ou protegidas e ocultadas, para executar uma declaração SELECT * FROM nessa tabela, um utilizador tem de ser membro dos grupos adequados de modo a receber funções de leitor ocultado ou leitor detalhado em todas estas colunas.

Em alternativa, um utilizador ao qual não sejam concedidas estas funções tem de especificar apenas as colunas às quais tem acesso na declaração SELECT ou usar SELECT * EXCEPT (restricted_columns) FROM para excluir as colunas protegidas ou ocultadas.

Herança de autorizações numa hierarquia de etiquetas de políticas

As funções são avaliadas a partir da etiqueta de política associada a uma coluna e, em seguida, verificadas em cada nível ascendente da taxonomia, até se determinar que o utilizador tem as autorizações adequadas ou se atingir a parte superior da hierarquia de etiquetas de política.

Por exemplo, considere a etiqueta de política e a configuração da política de dados apresentadas na Figura 4:

Figura 4. Configuração da política de dados e da etiqueta de política.

Tem uma coluna de tabela anotada com a etiqueta de política Financial e um utilizador que é membro dos grupos ftes@example.com e analysts@example.com. Quando este utilizador executa uma consulta que inclui a coluna anotada, o respetivo acesso é determinado pela hierarquia definida na taxonomia de etiquetas de políticas. Uma vez que o utilizador tem a função de leitor detalhado do catálogo de dados atribuída pela etiqueta de política Financial, a consulta devolve dados de colunas não ocultados.

Se outro utilizador que seja apenas membro da função ftes@example.com executar uma consulta que inclua a coluna anotada, a consulta devolve dados de colunas aos quais foi aplicado hash com o algoritmo SHA-256, porque o utilizador tem a função de leitor com máscara do BigQuery concedida pela etiqueta de política Confidential, que é a principal da etiqueta de política Financial.

Um utilizador que não seja membro de nenhuma dessas funções recebe um erro de acesso negado se tentar consultar a coluna anotada.

Em contraste com o cenário anterior, considere a etiqueta de política e a configuração da política de dados apresentadas na Figura 5:

Figura 5. Configuração da política de dados e da etiqueta de política.

Tem a mesma situação que é apresentada na Figura 4, mas ao utilizador é concedida a função de leitor detalhado num nível superior da hierarquia de etiquetas de políticas e a função de leitor com dados ocultados num nível inferior da hierarquia de etiquetas de políticas. Por este motivo, a consulta devolve dados de colunas ocultos para este utilizador. Isto acontece mesmo que o utilizador tenha a função de leitor detalhado mais acima na hierarquia de etiquetas, porque o serviço usa a primeira função atribuída que encontra à medida que sobe na hierarquia de etiquetas de políticas para verificar o acesso do utilizador.

Se quiser criar uma única política de dados e aplicá-la a vários níveis de uma hierarquia de etiquetas de políticas, pode definir a política de dados na etiqueta de política que representa o nível da hierarquia mais elevado ao qual deve ser aplicada. Por exemplo, considere uma taxonomia com a seguinte estrutura:

• Etiqueta de política 1
  • Etiqueta de política 1a
    • Etiqueta de política 1ai
  • Etiqueta de política 1b
    • Etiqueta de política 1bi
    • Etiqueta de política 1bii

Se quiser que uma política de dados se aplique a todas estas etiquetas de políticas, defina a política de dados na etiqueta de política 1. Se quiser que uma política de dados se aplique à etiqueta de política 1b e aos respetivos filhos, defina a política de dados na etiqueta de política 1b.

Anulação da identificação de dados com funcionalidades incompatíveis

Quando usa funcionalidades do BigQuery que não são compatíveis com a ocultação de dados, o serviço trata a coluna ocultada como uma coluna segura e só concede acesso a utilizadores que tenham a função de leitor detalhado do Data Catalog.

Por exemplo, considere a etiqueta de política e a configuração da política de dados apresentadas na Figura 6:

Figura 6. Configuração da política de dados e da etiqueta de política.

Tem uma coluna de tabela anotada com a etiqueta de política Financial e um utilizador que é membro do grupo analysts@example.com. Quando este utilizador tenta aceder à coluna anotada através de uma das funcionalidades incompatíveis, recebe um erro de acesso negado. Isto deve-se ao facto de lhes ser concedida a etiqueta de política FinancialBigQuery Masked Reader, mas, neste caso, têm de ter a função de leitor detalhado do Data Catalog. Uma vez que o serviço já determinou uma função aplicável para o utilizador, não continua a verificar mais acima na hierarquia de etiquetas de políticas para obter autorizações adicionais.

Exemplo de ocultação de dados com saída

Para ver como as etiquetas, os principais e as funções funcionam em conjunto, considere este exemplo.

Em example.com, o acesso básico é concedido através do grupo data-users@example.com. Todos os funcionários que precisam de acesso regular aos dados do BigQuery são membros deste grupo, ao qual são atribuídas todas as autorizações necessárias para ler a partir de tabelas, bem como a função de leitor com máscara do BigQuery.

Os funcionários são atribuídos a grupos adicionais que dão acesso a colunas protegidas ou ocultadas quando tal é necessário para o seu trabalho. Todos os membros destes grupos adicionais também são membros de data-users@example.com. Pode ver como estes grupos estão associados a funções adequadas na Figura 7:

Figura 7. Etiquetas de políticas e políticas de dados para example.com.

As etiquetas de políticas são, em seguida, associadas às colunas da tabela, conforme mostrado na Figura 8:

Figura 8. Etiquetas de políticas de example.com associadas a colunas de tabelas.

Tendo em conta as etiquetas associadas às colunas, a execução de SELECT * FROM Accounts; gera os seguintes resultados para os diferentes grupos:

• data-users@example.com: este grupo recebeu a função de leitor com máscara do BigQuery nas etiquetas de políticas PII e Confidential. São devolvidos os seguintes resultados:

  SSN	Prioridade	Valor do cliente	Data de criação	Email
  NULL	""	0	8 de março de 1983	NULL
  NULL	""	0	29 de dezembro de 2009	NULL
  NULL	""	0	14 de julho de 2021	NULL
  NULL	""	0	5 de maio de 1997	NULL

• accounting@example.com: este grupo recebeu a função de leitor detalhado do catálogo de dados na etiqueta de política SSN. São devolvidos os seguintes resultados:

  SSN	Prioridade	Valor do cliente	Data de criação	NULL
  123-45-6789	""	0	8 de março de 1983	NULL
  234-56-7891	""	0	29 de dezembro de 2009	NULL
  345-67-8912	""	0	14 de julho de 2021	NULL
  456-78-9123	""	0	5 de maio de 1997	NULL

• sales-exec@example.com: este grupo recebeu a função de leitor detalhado do catálogo de dados na Confidentialetiqueta de política. São devolvidos os seguintes resultados:

  SSN	Prioridade	Valor do cliente	Data de criação	Email
  NULL	Alto	90 000	8 de março de 1983	NULL
  NULL	Alto	84 875	29 de dezembro de 2009	NULL
  NULL	Médio	38 000	14 de julho de 2021	NULL
  NULL	Baixo	245	5 de maio de 1997	NULL

• fin-dev@example.com: este grupo recebeu a função de leitor com máscara do BigQuery na etiqueta de política Financial. São devolvidos os seguintes resultados:

  SSN	Prioridade	Valor do cliente	Data de criação	Email
  NULL	""	Zmy9vydG5q=	8 de março de 1983	NULL
  NULL	""	GhwTwq6Ynm=	29 de dezembro de 2009	NULL
  NULL	""	B6y7dsgaT9=	14 de julho de 2021	NULL
  NULL	""	Uh02hnR1sg=	5 de maio de 1997	NULL

• Todos os outros utilizadores: qualquer utilizador que não pertença a um dos grupos indicados recebe um erro de acesso negado, porque não lhe foram concedidas as funções de leitor detalhado do Data Catalog ou leitor com máscara do BigQuery. Para consultar a tabela Accounts, têm de especificar apenas as colunas às quais têm acesso no SELECT * EXCEPT (restricted_columns) FROM Accounts para excluir as colunas protegidas ou ocultadas.

Considerações sobre o custo

A ocultação de dados pode afetar indiretamente o número de bytes processados e, por isso, afetar o custo da consulta. Se um utilizador consultar uma coluna que lhe está oculta com as regras de anulação ou valor de ocultação predefinido, essa coluna não é analisada, o que resulta num menor número de bytes processados.

Restrições e limitações

As secções seguintes descrevem as categorias de restrições e limitações a que a ocultação de dados está sujeita.

Gestão da Política de Dados

• 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.
• Pode criar até nove políticas de dados para cada etiqueta de política. Uma destas políticas está reservada para definições de controlo de acesso ao nível da coluna.
• As políticas de dados, as respetivas etiquetas de políticas associadas e todas as rotinas que as usam têm de estar no mesmo projeto.

Etiquetas de políticas

• O projeto que contém a taxonomia de etiquetas de políticas tem de pertencer a uma organização.

• Uma hierarquia de etiquetas de políticas não pode ter mais de cinco níveis de profundidade a partir do nó raiz até à subetiqueta de nível mais baixo, conforme mostrado na captura de ecrã seguinte:

  

Defina o controlo de acesso

Depois de uma taxonomia ter uma política de dados associada, pelo menos, a uma das respetivas etiquetas de políticas, o controlo de acesso é aplicado automaticamente. Se quiser desativar o controlo de acesso, tem de eliminar primeiro todas as políticas de dados associadas à taxonomia.

Consultas de mascaramento de registos repetidos e vistas materializadas

Se tiver vistas materializadas existentes, as consultas de ocultação de registos repetidas na tabela base associada falham. Para resolver este problema, elimine a vista materializada. Se a vista materializada for necessária por outros motivos, pode criá-la noutro conjunto de dados.

Consulte colunas ocultadas em tabelas particionadas

As consultas que incluem ocultação de dados nas colunas particionadas ou agrupadas não são suportadas.

Dialetos SQL

O SQL antigo não é suportado.

Rotinas de ocultação personalizadas

As rotinas de ocultação personalizadas estão sujeitas às seguintes limitações:

• A ocultação de dados personalizada suporta todos os tipos de dados do BigQuery exceto STRUCT, porque a ocultação de dados só pode ser aplicada a campos finais do tipo de dados STRUCT.
• A eliminação de uma rotina de ocultação personalizada não elimina todas as políticas de dados que a usam. No entanto, as políticas de dados que usam a rotina de ocultação eliminada ficam com uma regra de ocultação vazia. Os utilizadores com a função Leitor com máscara noutras políticas de dados com a mesma etiqueta podem ver dados com máscara. Os outros utilizadores veem a mensagem: Permission denied. As referências pendentes a regras de ocultação vazias podem ser limpas por processos automáticos após sete dias.

Compatibilidade com outras funcionalidades do BigQuery

API BigQuery

Não é compatível com o método tabledata.list. Para chamar tabledata.list, precisa de acesso total a todas as colunas devolvidas por este método. A função de leitor detalhado do Data Catalog concede o acesso adequado.

Tabelas do BigLake

Compatível. As políticas de ocultação de dados são aplicadas a tabelas do BigLake.

API BigQuery Storage Read

Compatível. As políticas de ocultação de dados são aplicadas na API BigQuery Storage Read.

BigQuery BI Engine

Compatível. As políticas de ocultação de dados são aplicadas no BI Engine. As consultas que têm a ocultação de dados em vigor não são aceleradas pelo BI Engine. A utilização destas consultas no Looker Studio pode fazer com que os relatórios ou os painéis de controlo relacionados fiquem mais lentos e caros.

BigQuery Omni

Compatível. As políticas de ocultação de dados são aplicadas às tabelas do BigQuery Omni.

Colação

Parcialmente compatível. Pode aplicar a DDM a colunas agrupadas, mas a ocultação é aplicada antes do agrupamento. Esta ordem de operações pode levar a resultados inesperados, uma vez que a ordenação pode não afetar os valores ocultados conforme previsto (por exemplo, a correspondência não sensível a maiúsculas e minúsculas pode não funcionar após a ocultação). É possível encontrar soluções alternativas, como usar rotinas de ocultação personalizadas que normalizam os dados antes de aplicar a função de ocultação.

Tarefas de cópia

Incompatível. Para copiar uma tabela da origem para o destino, tem de ter acesso total a todas as colunas na tabela de origem. A função de leitor detalhado do Data Catalog concede o acesso adequado.

Exportação de dados

Compatível. Se tiver a função de leitor com máscara do BigQuery, os dados exportados são mascarados. Se tiver a função de leitor detalhado do Data Catalog, os dados exportados não são ocultados.

Segurança ao nível da linha

Compatível. A ocultação de dados é aplicada além da segurança ao nível da linha. Por exemplo, se existir uma política de acesso ao nível da linha aplicada em location = "US" e location estiver oculto, os utilizadores podem ver linhas onde location = "US", mas o campo de localização está oculto.

Pesquise no BigQuery

Parcialmente compatível. Pode chamar a função SEARCH em colunas indexadas ou não indexadas às quais foi aplicada a ocultação de dados.

Quando chama a função SEARCH em colunas às quais foi aplicada a ocultação de dados, tem de usar critérios de pesquisa compatíveis com o seu nível de acesso. Por exemplo, se tiver acesso de leitor mascarado com uma regra de ocultação de dados de hash (SHA-256), usaria o valor de hash na sua cláusula SEARCH, semelhante ao seguinte:

SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "sg172y34shw94fujaweu");

Se tiver acesso de leitor detalhado, usaria o valor real da coluna na sua cláusula SEARCH, semelhante ao seguinte:

SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "jane.doe@example.com");

A pesquisa tem menos probabilidade de ser útil se tiver acesso de leitor mascarado a uma coluna em que a regra de ocultação de dados usada seja Anular ou o valor de ocultação predefinido. Isto deve-se ao facto de os resultados ocultados que usaria como critérios de pesquisa, como NULL ou "", não serem suficientemente únicos para serem úteis.

Quando pesquisa numa coluna indexada à qual foi aplicada a ocultação de dados, o índice de pesquisa só é usado se tiver acesso de leitor detalhado à coluna.

Instantâneos

Incompatível. Para criar um instantâneo de uma tabela, precisa de acesso total a todas as colunas da tabela de origem. A função de leitor detalhado do Data Catalog concede o acesso adequado.

Mudança do nome da tabela

Compatível. A mudança do nome da tabela não é afetada pela ocultação de dados.

Viagem no tempo

Compatível com decoradores de tempo e a opção FOR SYSTEM_TIME AS OF nas declarações SELECT. As etiquetas de políticas do esquema do conjunto de dados atual são aplicadas aos dados obtidos.

Colocação em cache de consultas

Parcialmente compatível. O BigQuery coloca os resultados das consultas em cache durante aproximadamente 24 horas, embora a cache seja invalidada se forem feitas alterações aos dados ou ao esquema da tabela antes desse período. Na seguinte circunstância, é possível que um utilizador que não tenha a função de leitor detalhado do catálogo de dados concedida numa coluna possa continuar a ver os dados da coluna quando executa uma consulta:

1. Foi concedido a um utilizador o papel de leitor detalhado do catálogo de dados numa coluna.
2. O utilizador executa uma consulta que inclui a coluna restrita e os dados são colocados em cache.
3. No prazo de 24 horas após o passo 2, é concedida ao utilizador a função de leitor com máscara do BigQuery e a função de leitor detalhado do Data Catalog é revogada.
4. No prazo de 24 horas após o passo 2, o utilizador executa essa mesma consulta e os dados em cache são devolvidos.

Consultas de tabelas com carateres universais

Incompatível. Precisa de acesso total a todas as colunas referenciadas em todas as tabelas que correspondam à consulta com carateres universais. A função de leitor detalhado do Data Catalog concede o acesso adequado.

O que se segue?

• Receba instruções passo a passo para ativar a ocultação de dados.