Introdução ao mascaramento de dados

Observação: esse recurso pode não estar disponível ao usar reservas criadas com determinadas edições do BigQuery. Para mais informações sobre quais recursos estão ativados em cada edição, consulte Introdução às edições do BigQuery.

O BigQuery suporta o mascaramento de dados no nível da coluna. Você pode usar o mascaramento de dados para ocultar seletivamente os dados da coluna para grupos de usuários, enquanto ainda permite o acesso deles à coluna. A funcionalidade de mascaramento de dados é criada com base no controle de acesso no nível da coluna. Portanto, você precisa se familiarizar com esse recurso antes de continuar.

Ao usar o mascaramento de dados com o controle de acesso no nível da coluna, é possível configurar um intervalo de acesso aos dados da coluna, de acesso total a sem acesso, com base nas necessidades de diferentes grupos de usuários. Por exemplo, para dados de CPF/CNPJ, convém conceder acesso total ao grupo de contas, acesso mascarado ao grupo de analistas e nenhum acesso ao grupo de vendas.

Benefícios

O uso do mascaramento de dados oferece os seguintes benefícios:

• Ele simplifica o processo de compartilhamento de dados. É possível mascarar colunas sensíveis para possibilitar o compartilhamento de tabelas com grupos maiores.
• Diferentemente do controle de acesso no nível da coluna, não é preciso modificar as consultas existentes excluindo as colunas que o usuário não pode acessar. Quando você configura o mascaramento de dados, as consultas atuais mascaram automaticamente os dados da coluna com base nos papéis concedidos ao usuário.
• É possível aplicar políticas de acesso a dados em escala. É possível gravar uma política de dados, associá-la a uma tag de política e aplicar a tag de política a qualquer número de colunas.
• Ela ativa o controle de acesso baseado em atributos. Uma tag de política anexada a uma coluna oferece acesso a dados contextuais, que são determinados pela política de dados e os participantes associados a essa tag de política.

Fluxo de trabalho de mascaramento de dados

A Figura 1 mostra o fluxo de trabalho para configurar o mascaramento de dados:

Figura 1. Componentes de mascaramento de dados.

Para configurar o mascaramento de dados, siga estas etapas:

1. Configure uma taxonomia e uma ou mais tags de política.

2. Configurar políticas de dados para as tags de política. Uma política de dados mapeia uma regra de mascaramento de dados e um ou mais principais, que representam usuários ou grupos, para a tag de política.

   Ao criar uma política de dados usando o console do Google Cloud, você cria a regra de mascaramento de dados e especifica os principais elementos em uma etapa. Ao criar uma política de dados usando a API BigQuery Data Policy, você cria a política de dados e a regra de mascaramento de dados em uma única etapa e especifica os principais elementos da política de dados em uma segunda etapa.

3. Atribua as tags de política às colunas das tabelas do BigQuery para aplicar as políticas de dados.

4. Atribua usuários que precisam ter acesso a dados mascarados ao papel Leitor mascarado do BigQuery. Como prática recomendada, atribua o papel de leitor mascarado do BigQuery no nível da política de dados. Atribuir o papel no nível do projeto ou em níveis superiores concede aos usuários permissões para todas as políticas de dados no projeto, o que pode levar a problemas causados por permissões em excesso.

   A tag de política associada a uma política de dados também pode ser usada para controle de acesso no nível da coluna. Nesse caso, a tag de política também está associada a um ou mais elementos principais que recebem o papel Leitor refinado do Data Catalog. Isso permite que esses principais acessem os dados originais não mascarados de colunas.

A Figura 2 mostra como o controle de acesso no nível da coluna e o mascaramento de dados funcionam juntos:

Figura 2. Componentes de mascaramento de dados.

Para mais informações sobre interação de papéis, consulte Como os papéis de leitor mascarado e leitor de controle refinado interagem. Para mais informações sobre a herança de tags de política, consulte Papéis e hierarquia de tags de política.

Regras de mascaramento de dados

Ao mascarar os dados, uma regra de mascaramento de dados é aplicada a uma coluna no tempo de execução da consulta, com base no papel do usuário que está executando a consulta. O mascaramento tem precedência para qualquer outra operação envolvida na consulta. A regra de mascaramento de dados determina o tipo de mascaramento de dados aplicado aos dados da coluna.

É possível usar as seguintes regras de mascaramento de dados:

• Rotina personalizada de mascaramento. Retorna o valor da coluna depois de aplicar uma função definida pelo usuário (UDF, na sigla em inglês) à coluna. As permissões de rotina são necessárias para gerenciar a regra de mascaramento. Por padrão, essa regra é compatível com 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. A saída depende da função definida.

  Para mais informações sobre a criação de UDFs para rotinas de mascaramento personalizadas, consulte Criar rotinas de mascaramento personalizadas.

• Máscara de ano. Retorna o valor da coluna após truncar o valor com o ano, definindo todas as partes não anuais do valor para o início do ano. Só é possível usar essa regra com colunas que usam os tipos de dados DATE, DATETIME e TIMESTAMP. Exemplo:

  Tipo	Dados	Mascarado
  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

  Observação :o truncamento ocorre de acordo com o fuso horário UTC. Para mudar isso, ajuste o fuso horário padrão usando a variável de sistema @@time_zone.

• Valor de mascaramento padrão. Retorna um valor de mascaramento padrão para a coluna com base no tipo de dados da coluna. Use esse método quando quiser ocultar o valor da coluna, mas revelar o tipo de dados. Quando essa regra de aplicação de dados é aplicada a uma coluna, ela se torna menos útil em operações de consulta JOIN para usuários com acesso ao Leitor mascarado. Isso ocorre porque um valor não é exclusivo o suficiente para ser útil ao mesclar tabelas.

  A tabela a seguir mostra o valor padrão de mascaramento de cada tipo de dados:

  Tipo de dado	Valor de mascaramento padrão
  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	NÃO_RELEVANTE As tags de política não podem ser aplicadas a colunas que usam o tipo de dados STRUCT, mas podem ser associadas aos campos de folha dessas colunas.
  JSON	nulo

• Máscara de e-mail. Retorna o valor da coluna após a substituição do nome de usuário de um e-mail válido por XXXXX. Se o valor da coluna não for um endereço de e-mail válido, ele retornará o valor da coluna depois de ter sido executado pela função de hash SHA-256. Só é possível usar essa regra com colunas que utilizam o tipo de dados STRING. Exemplo:

  Dados	Mascarado
  [e-mail]	[e-mail]
  randomtext	jQHDyQuj7vJcveEe59ygb3Zcvj0B5FJINBzgM6Bypgw=
  test@[e-mail]	Qdje6MO+GLwI0u+KyRyAICDjHbLF1ImxRqaW08tY52k=

• Os primeiros quatro caracteres. Retorna os primeiros quatro caracteres do valor da coluna, substituindo o restante da string por XXXXX. Se o valor da coluna for igual ou menor que quatro caracteres, ele retornará o valor da coluna depois que ela tiver sido executada pela função de hash SHA-256. Só é possível usar essa regra com colunas que usam o tipo de dados STRING.

• Hash (SHA-256). Retorna o valor da coluna depois de ter sido executado pela função de hash SHA-256. Use essa opção quando quiser que o usuário final possa usar essa coluna em uma operação JOIN para uma consulta. Só é possível usar essa regra com colunas que usam os tipos de dados STRING ou BYTES.

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

  Importante: SHA-256 é uma função de hash determinística. Um valor inicial sempre é resolvido como o mesmo valor de hash. No entanto, ele não exige chaves de criptografia. Isso permite que um agente malicioso use um ataque de força bruta para determinar o valor original, executando todos os valores possíveis com o algoritmo SHA-256 e vendo qual deles produz um hash correspondente àquele retornado por mascaramento de dados.

• Últimos quatro caracteres. Retorna os últimos quatro caracteres do valor da coluna, substituindo o restante da string por XXXXX. Se o valor da coluna for igual ou menor que quatro caracteres, ele retornará o valor da coluna depois que ela tiver sido executada pela função hash SHA-256. Só é possível usar essa regra com colunas que usam o tipo de dados STRING.

• Anular. Retorna NULL no lugar do valor da coluna. Use-o quando quiser ocultar o valor e o tipo de dados da coluna. Quando essa regra de aplicação de dados é aplicada a uma coluna, ela se torna menos útil em operações de consulta JOIN para usuários com acesso ao Leitor mascarado. Isso ocorre porque um valor NULL não é exclusivo o suficiente para ser útil ao mesclar tabelas.

Hierarquia da regra de mascaramento de dados

É possível configurar até nove políticas de dados para uma tag de política, cada uma com uma regra de mascaramento de dados diferente associada a ela. Uma dessas políticas é reservada para configurações de controle de acesso no nível da coluna. Isso possibilita que várias políticas de dados sejam aplicadas a uma coluna na consulta de um usuário, com base nos grupos de que o usuário é membro. Quando isso acontece, o BigQuery escolhe qual regra de mascaramento de dados será aplicada com base na seguinte hierarquia:

1. Rotina personalizada de mascaramento
2. Hash (SHA-256)
3. Máscara de e-mail
4. Últimos quatro caracteres
5. Primeiros quatro caracteres
6. Máscara do ano
7. Valor de mascaramento padrão
8. Anular

Por exemplo, o usuário A é membro de dois grupos: funcionários e da contabilidade. O usuário A executa uma consulta que inclui o campo sales_total, que tem a tag de política confidential aplicada. A tag de política confidential tem duas políticas de dados associadas: uma que tem o papel de funcionários como elemento principal e aplica a regra de mascaramento de dados de nulidade e outra que tem o papel de contabilidade como elementoprincipal e aplica a regra de mascaramento de dados de hash (SHA-256). Nesse caso, a regra de mascaramento de dados de hash (SHA-256) é priorizada em relação à regra de mascaramento de dados de nulo. Portanto, a regra de hash (SHA-256) é aplicada ao valor do campo sales_total no usuário. Consulta A.

A Figura 3 mostra esse cenário:

Figura 3. Priorização das regras de mascaramento de dados.

Papéis e permissões

Papéis para gerenciar taxonomias e tags de política

Você deve ser o administrador de tags de política do Data Catalog para criar e gerenciar taxonomias e tags de política.

ID/papel	Permissões	Descrição
Administrador de tags de política do Data Catalog/datacatalog.categoryAdmin	datacatalog.categories.getIamPolicy datacatalog.categories.setIamPolicy datacatalog.taxonomies.create datacatalog.taxonomies.delete datacatalog.taxonomies.get datacatalog.taxonomies.getIamPolicy datacatalog.taxonomies.list datacatalog.taxonomies.setIamPolicy datacatalog.taxonomies.update resourcemanager.projects.get resourcemanager.projects.list	Aplica-se no nível do projeto. Com essa função, é possível fazer o seguinte: Criar, ler, atualizar e excluir taxonomias e tags de política. Acessar e definir políticas do IAM nas tags de política.

Papéis para criar e gerenciar políticas de dados

Você precisa de um dos seguintes papéis do BigQuery para criar e gerenciar as políticas de dados:

ID/papel	Permissões	Descrição
Administrador do BigQuery/bigquery.admin Proprietário de dados do BigQuery/bigquery.dataOwner	bigquery.dataPolicies.create bigquery.dataPolicies.delete bigquery.dataPolicies.get bigquery.dataPolicies.getIamPolicy bigquery.dataPolicies.list bigquery.dataPolicies.setIamPolicy bigquery.dataPolicies.update	As permissões bigquery.dataPolicies.create e bigquery.dataPolicies.list se aplicam no nível do projeto. As outras permissões são aplicáveis no nível da política de dados. Com essa função, é possível fazer o seguinte: Criar, ler, atualizar e excluir políticas de dados. Acessar e definir políticas do IAM nas políticas de dados.

Você também precisa da permissão datacatalog.taxonomies.get, que pode ser recebida de vários dos papéis predefinidos do Data Catalog.

Papéis para anexar tags de política a colunas

Você precisa das permissões datacatalog.taxonomies.get e bigquery.tables.setCategory para anexar tags de política às colunas. datacatalog.taxonomies.get está incluído nos papéis de administrador de tags de política do Data Catalog e de visualizador. bigquery.tables.setCategory está incluído nos papéis Administrador do BigQuery (roles/bigquery.admin) e de Proprietário de dados do BigQuery (roles/bigquery.dataOwner).

Papéis para a consulta de dados mascarados

Você precisa do papel de Leitor mascarado do BigQuery para consultar os dados de uma coluna com o mascaramento de dados aplicado.

ID/papel	Permissões	Descrição
Leitor mascarado/bigquerydatapolicy.maskedReader	bigquery.dataPolicies.maskedGet	Ele é aplicado no nível da política de dados. Esse papel concede a capacidade de visualizar os dados mascarados de uma coluna associada uma política de dados. Além disso, um usuário precisa ter as permissões apropriadas para consultar a tabela. Para mais informações, consulte Permissões necessárias.

Como os papéis de leitor mascarado e leitor de controle refinado interagem

O mascaramento de dados se baseia no controle de acesso no nível da coluna. Para uma determinada coluna, é possível que alguns usuários com o papel Leitor mascarado do BigQuery permitam a leitura de dados mascarados, alguns usuários com o papel Leitor refinado do Data Catalog que permite a eles ler dados não mascarados, alguns usuários com ambos e outros sem nenhum. Esses papéis interagem da seguinte maneira:

• Usuário com os papéis de Leitor de controle refinado e Leitor mascarado: o que o usuário vê depende do local na hierarquia de tags de política que cada papel é concedido. Para mais informações, consulte Herança de autorização em uma hierarquia de tags de política.
• Usuário com o papel de Leitor de controle refinado: pode acessar dados não mascarados de colunas (sem obscuridade).
• Usuário com o papel de Leitor mascarado: pode acessar dados mascarados de colunas.
• Usuário sem papel: permissão negada.

No caso de uma tabela ter colunas seguras e/ou seguras e mascaradas, para executar uma instrução SELECT * FROM nessa tabela, um usuário precisa ser membro de grupos apropriados para que receba os papéis de leitor mascarado ou leitor de controle refinado de todas essas colunas.

Um usuário que não tem esses papéis precisa especificar apenas as colunas a que ele tem acesso na instrução SELECT ou usar SELECT * EXCEPT (restricted_columns) FROM para excluir as colunas protegidas ou mascaradas.

Herança de autorização em uma hierarquia de tags de política

Os papéis são avaliados a partir da tag de política associada a uma coluna e verificados em cada nível crescente da taxonomia, até que o usuário determine que tem as permissões apropriadas ou a parte superior da tag de política seja alcançada.

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

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

Há uma coluna de tabela com a tag de política Financial e um usuário que é membro dos grupos [e-mail] e [e-mail]. Quando esse usuário executa uma consulta que inclui a coluna com anotação, o acesso dele é determinado pela hierarquia definida na taxonomia de tag de política. Como o usuário recebe o papel Leitor refinado do Data Catalog pela tag de política Financial, a consulta retorna os dados de colunas não mascaradas.

Se outro usuário que é apenas um membro do papel [e-mail] executa uma consulta que inclui a coluna com anotação, a consulta retorna dados da coluna que foram criptografados com hash usando o algoritmo SHA-256, porque o usuário recebe o papel Leitor mascarado do BigQuery da tag de política Confidential, que é o pai da tag de política Financial.

Um usuário que não é membro de nenhum desses papéis receberá um erro de acesso negado se tentar consultar a coluna com anotação.

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

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

Você tem a mesma situação mostrada na Figura 4, mas o usuário recebe o papel de leitor de controle refinado em um nível mais alto da hierarquia de tags de política e o papel de leitor mascarado em um nível inferior da política da tag. Por isso, a consulta retorna dados da coluna mascarados desse usuário. Isso acontece mesmo que o usuário receba o papel de leitor de controle refinado elevado na hierarquia de tags, pois o serviço usa o primeiro papel atribuído que encontra ao atribuir a hierarquia da tag de política a ser verificada para o acesso do usuário.

Se você quiser criar uma única política de dados e aplicá-la a vários níveis de uma hierarquia de tags de política, defina a política de dados na tag de política que representa o nível superior de hierarquia que será aplicado. Por exemplo, considere uma taxonomia com a seguinte estrutura:

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

Se você quiser que uma política de dados seja aplicada a todas essas tags de política, defina a política de dados na tag de política 1. Se você quiser que uma política de dados seja aplicada à tag de política 1b e aos filhos dela, defina a política de dados na tag de política 1b.

Mascaramento de dados com recursos incompatíveis

Quando você usa recursos do BigQuery que não são compatíveis com o mascaramento de dados, o serviço trata a coluna mascarada como uma coluna protegida e concede acesso somente a usuários que tenham o Papel de leitor de controle refinado do Data Catalog.

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

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

Você tem uma coluna de tabela com a tag de política Financial e um usuário que é membro do grupo "[e-mail]". Quando esse usuário tenta acessar a coluna com anotações em um dos recursos incompatíveis, ele recebe um erro de acesso negado. Isso porque ele recebe o leitor mascarado do BigQuery pela tag de política Financial, mas, nesse caso, precisa receber o papel Leitor refinado do Data Catalog. Como o serviço já determinou um papel aplicável para o usuário, ele não continua verificando em mais detalhes a hierarquia de tags de política para permissões adicionais.

Exemplo de mascaramento de dados com saída

Para saber como as tags, os elementos principais e os papéis funcionam juntos, considere este exemplo.

Em example.com, o acesso básico é concedido pelo grupo [e-mail]. Todos os funcionários que precisam de acesso regular aos dados do BigQuery são membros desse grupo, que recebe todas as permissões necessárias para ler tabelas, assim como o papel de leitor mascarado do BigQuery.

Os funcionários são atribuídos a outros grupos que fornecem acesso a colunas seguras ou mascaradas, em que isso é necessário para o trabalho. Todos os membros desses grupos também são participantes do [e-mail]. Confira como esses grupos estão associados aos papéis apropriados na Figura 7:

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

As tags de política são associadas às colunas da tabela, como mostrado na Figura 8:

Figura 8. Tags de política de example.com associadas às colunas da tabela.

Com as tags associadas às colunas, a execução de SELECT * FROM Accounts; leva aos seguintes resultados para diferentes grupos:

• [e-mail]: esse grupo recebeu o papel de Leitor mascarado do BigQuery nas tags de política PII e Confidential. Os seguintes resultados são retornados:

  SSN	Prioridade	Valor da vida útil	Data de criação	E-mail
  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

• [e-mail]: esse grupo recebeu o papel de Leitor de controle refinado do Data Catalog na tag de política SSN. Os seguintes resultados são retornados:

  SSN	Prioridade	Valor da vida útil	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

• [e-mail]: esse grupo recebeu o papel de Leitor de controle refinado do Data Catalog na tag de política Confidential. Os seguintes resultados são retornados:

  SSN	Prioridade	Valor da vida útil	Data de criação	E-mail
  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	Baixa	245	5 de maio de 1997	NULL

• [e-mail]: esse grupo recebeu o papel de Leitor mascarado do BigQuery na tag de política Financial. Os seguintes resultados são retornados:

  SSN	Prioridade	Valor da vida útil	Data de criação	E-mail
  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 usuários: qualquer usuário que não pertença a um dos grupos listados recebe um erro de acesso negado, porque ele não recebeu o leitor refinado do Data Catalog ou Papéis de leitor mascarado do BigQuery. Para consultar a tabela Accounts, eles precisam especificar somente as colunas a que têm acesso no SELECT * EXCEPT (restricted_columns) FROM Accounts para excluir as colunas protegidas ou mascaradas.

Considerações sobre o custo

O mascaramento de dados pode afetar indiretamente o número de bytes processados e, portanto, afetar o custo da consulta. Se um usuário consultar uma coluna mascarada com as regras de valor nulo ou de mascaramento padrão, essa coluna não será verificada, o que resultará em menos bytes processados.

Restrições e limitações

As seções a seguir descrevem as categorias de restrições e limitações a que o mascaramento de dados está sujeito.

Gerenciamento de políticas de dados

• Esse recurso pode não estar disponível ao usar reservas criadas com determinadas edições do BigQuery. Para mais informações sobre quais recursos estão ativados em cada edição, consulte Introdução às edições do BigQuery.
• Você pode criar até nove políticas de dados para uma tag de política. Uma dessas políticas é reservada para configurações de controle de acesso no nível da coluna.
• As políticas de dados, as tags de política associadas e as rotinas que as usam precisam estar no mesmo projeto.

Tags de política

• O projeto que contém a taxonomia da tag de política precisa pertencer a uma organização.

• Uma hierarquia de tags de política não pode ter mais de cinco níveis de profundidade do nó raiz até a subtag de nível mais baixo, conforme a captura de tela abaixo:

  

Definir controle de acesso

Depois que uma taxonomia tem uma política de dados associada a pelo menos uma das tags de política, o controle de acesso é aplicado automaticamente. Se você quiser desativar o controle de acesso, primeiro exclua todas as políticas de dados associadas à taxonomia.

Visualizações materializadas e consultas repetidas de mascaramento de registro

Se você tiver visualizações materializadas, as consultas repetidas de mascaramento de registro na tabela base associada falharão. Para resolver esse problema, exclua a visualização materializada. Se a visualização materializada for necessária por outros motivos, você poderá criá-la em outro conjunto de dados.

Consultar colunas mascaradas em tabelas particionadas

As consultas que incluem mascaramento de dados nas colunas particionadas ou em cluster não são compatíveis.

Dialetos SQL

Não há suporte para o SQL legado.

Rotinas de mascaramento personalizadas

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

• O mascaramento de dados personalizado oferece suporte a todos os tipos de dados do BigQuery, exceto STRUCT, porque ele só pode ser aplicado a campos de folha do tipo de dados STRUCT.
• Excluir uma rotina de mascaramento personalizada não exclui todas as políticas de dados que a utilizam. No entanto, as políticas de dados que usam a rotina de mascaramento excluída ficam com uma regra de mascaramento vazia. Usuários com o papel de leitor mascarado em outras políticas de dados com a mesma tag podem acessar os dados mascarados. Outras pessoas recebem a mensagem Permission denied. Referências pendentes de regras de mascaramento vazias podem ser limpadas por processos automatizados após sete dias.

Compatibilidade com outros recursos do BigQuery

API BigQuery

Incompatível com o método tabledata.list. Para chamar tabledata.list, você precisa do acesso total a todas as colunas retornadas por esse método. O papel de Leitor de controle refinado do Data Catalog concede o acesso apropriado.

Tabelas do BigLake

Compatível. As políticas de mascaramento de dados são aplicadas nas tabelas do BigLake.

Leitura de armazenamento do BigQuery da API

Compatível. As políticas de mascaramento de dados são aplicadas na Leitura de armazenamento do BigQuery da API.

BigQuery BI Engine

Compatível. As políticas de mascaramento de dados são aplicadas no BI Engine. As consultas com mascaramento de dados em vigor não são aceleradas pelo BI Engine. O uso dessas consultas no Looker Studio pode fazer com que relatórios ou painéis relacionados se tornem mais lentos e caros.

BigQuery Omni

compatível. As políticas de mascaramento de dados são aplicadas nas tabelas do BigQuery Omni.

Compilação

Incompatível. A ordenação não é compatível com colunas mascaradas.

Jobs de cópia

Incompatível. Para copiar uma tabela da origem para o destino, é preciso ter acesso total a todas as colunas na tabela de origem. O papel Leitor refinado do Data Catalog concede o acesso apropriado.

Exportação de dados

Compatível. Se você tiver o papel Leitor mascarado do BigQuery, os dados exportados serão mascarados. Se você tiver o papel Leitor refinado do Data Catalog, os dados exportados não serão mascarados.

Segurança no nível da linha

Compatível. O mascaramento de dados é aplicado além da segurança no nível da linha. Por exemplo, se houver uma política de acesso de linha aplicada em location = "US" e location estiver mascarada, os usuários poderão acessar as linhas em que location = "US", mas o campo de localização é mascarado.

Pesquisar no BigQuery

Parcialmente compatível. Chame a função SEARCH em colunas indexadas ou não indexadas com mascaramento de dados.

Ao chamar a função SEARCH em colunas com o mascaramento de dados aplicado, é necessário usar critérios de pesquisa compatíveis com seu nível de acesso. Por exemplo, se você tiver acesso ao leitor mascarado com uma regra de mascaramento de dados Hash (SHA-256), usará o valor de hash na cláusula SEARCH, semelhante ao seguinte:

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

Se você tiver acesso de leitor de controle refinado, use o valor real da coluna na cláusula SEARCH, semelhante ao seguinte:

SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "[e-mail]");

A pesquisa terá menos probabilidade de ser útil se você tiver acesso por leitor mascarado a uma coluna em que a regra de mascaramento de dados usada seja Nulo ou Valor de mascaramento padrão. Isso acontece porque os resultados mascarados que você usaria como critérios de pesquisa, como NULL ou "", não são exclusivos o suficiente para serem úteis.

Ao pesquisar em uma coluna indexada que tenha máscara de dados aplicada, o índice de pesquisa será usado apenas se você tiver acesso de leitura refinada à coluna.

Snapshots

Incompatível. Para criar um snapshot de uma tabela, é preciso ter acesso total a todas as colunas na tabela de origem. O papel Leitor refinado do Data Catalog concede acesso apropriado.

Renomeação da tabela

Compatível. A renomeação da tabela não é afetada pelo mascaramento de dados.

Viagem no tempo

Compatível com decoradores de horário e a opção FOR SYSTEM_TIME AS OF nas instruções SELECT. As tags de política no esquema atual do conjunto de dados são aplicadas aos dados recuperados.

Armazenamento de consultas em cache

Parcialmente compatível. O BigQuery armazena em cache os resultados da consulta por aproximadamente 24 horas, embora o cache seja invalidado se forem feitas alterações nos dados ou no esquema da tabela antes disso. Nessas circunstâncias, é possível que um usuário que não tenha atualmente o papel de Leitor refinado do Data Catalog concedido em uma coluna pode ainda acessar os dados da coluna ao realizar uma consulta:

1. Um usuário recebeu o papel Leitor refinado do Data Catalog em uma coluna.
2. O usuário executa uma consulta que inclui a coluna restrita, e os dados são armazenados em cache.
3. Em até 24 horas da etapa 2, o usuário recebe o papel de Leitor mascarado do BigQuery e tem o papel de Leitor de controle refinado do Data Catalog.
4. Em 24 horas da etapa 2, o usuário realiza essa mesma consulta, e os dados armazenados em cache são retornados.

Consultas de tabelas de caractere curinga

Incompatível. É preciso ter acesso total a todas as colunas referenciadas em todas as tabelas que correspondam à consulta com o caractere curinga. O papel Leitor refinado do Data Catalog concede acesso apropriado.

A seguir

• Receba instruções detalhadas para ativar o mascaramento de dados.