Introdução ao controlo de acesso ao nível da coluna

Nota: 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.

O BigQuery fornece acesso detalhado a colunas confidenciais com recurso a etiquetas de políticas ou à classificação de dados baseada em tipos. A utilização do controlo de acesso ao nível da coluna do BigQuery permite-lhe criar políticas que verificam, no momento da consulta, se um utilizador tem o acesso adequado. Por exemplo, uma política pode aplicar verificações de acesso, como:

• Tem de estar em group:high-access para ver as colunas que contêm TYPE_SSN.

Para melhorar o controlo de acesso ao nível da coluna, pode usar opcionalmente a ocultação dinâmica de dados. A ocultação de dados permite-lhe ocultar dados confidenciais substituindo o conteúdo nulo, predefinido ou com hash no lugar do valor real da coluna.

Fluxo de trabalho de controlo de acesso ao nível da coluna

Para restringir o acesso aos dados ao nível da coluna:

1. Defina uma taxonomia e etiquetas de políticas. Crie e faça a gestão de uma taxonomia e de etiquetas de políticas para os seus dados. Para ver diretrizes, consulte o artigo Práticas recomendadas para etiquetas de políticas.

2. Atribua etiquetas de políticas às colunas do BigQuery. No BigQuery, use anotações de esquema para atribuir uma etiqueta de política a cada coluna onde quer restringir o acesso.

3. Aplique o controlo de acesso na taxonomia. A aplicação do controlo de acesso faz com que as restrições de acesso definidas para todas as etiquetas de políticas na taxonomia sejam aplicadas.

4. Faça a gestão do acesso nas etiquetas de políticas. Use políticas de gestão de identidade e de acesso (IAM) para restringir o acesso a cada etiqueta de política. A política está em vigor para cada coluna que pertence à etiqueta de política.

Quando um utilizador tenta aceder aos dados de colunas no momento da consulta, o BigQuery verifica a etiqueta de política da coluna e a respetiva política para ver se o utilizador está autorizado a aceder aos dados.

Nota: o controlo de acesso ao nível da coluna é aplicado além das ACLs do conjunto de dados existentes. Um utilizador precisa da autorização do conjunto de dados e da autorização da etiqueta de política para aceder aos dados protegidos pelo controlo de acesso ao nível da coluna.

Identifique o que tem de ser etiquetado

Para determinar os tipos de dados confidenciais que tem e que colunas precisam de etiquetas de políticas, considere gerar perfis sobre os seus dados numa organização, pasta ou projeto através da Proteção de dados confidenciais. Os perfis de dados contêm métricas e metadados sobre as suas tabelas e ajudam a determinar onde residem os dados confidenciais e de alto risco. A Proteção de dados confidenciais comunica estas métricas ao nível do projeto, da tabela e da coluna. Para mais informações, consulte o artigo Perfis de dados para dados do BigQuery.

A imagem seguinte mostra uma lista de perfis de dados de colunas (clique para aumentar). As colunas com valores de risco de dados elevados podem conter dados de alta sensibilidade e não ter controlos de acesso ao nível da coluna. Em alternativa, essas colunas podem conter dados de sensibilidade moderada ou elevada que são acessíveis a um grande número de pessoas.

Exemplo de utilização

Considere uma organização que precisa de classificar dados confidenciais em duas categorias: Alta e Média.

Para configurar a segurança ao nível da coluna, um administrador de dados com as autorizações adequadas executa os seguintes passos para configurar uma hierarquia de classificação de dados.

1. O administrador de dados cria uma taxonomia denominada "Criticidade da empresa". A taxonomia inclui os nós ou as etiquetas de políticas Elevado e Médio.

2. O administrador de dados decide que a política para o nó High inclui acesso para um grupo denominado high-tier-access.

3. O responsável pelos dados cria mais níveis de nós na taxonomia, em Alto e Médio. O nó de nível mais baixo é um nó folha, como o nó folha employee_ssn. O administrador de dados pode criar ou não uma política de acesso diferente para o nó folha employee_ssn.

4. O administrador de dados atribui uma etiqueta de política a colunas de tabelas específicas. Neste exemplo, o responsável pelos dados atribui a política de acesso High à coluna employee_ssn numa tabela.

5. Na página Esquema atual da consola, o responsável pelos dados pode ver a etiqueta de política que rege uma coluna específica. Neste exemplo, a coluna employee_ssn está na etiqueta de política High. Por isso, quando visualiza o esquema de employee_ssn, a consola apresenta o nome da taxonomia e a etiqueta de política no campo Policy tags: Business criticality:High.

   

   Para ver detalhes sobre como usar a consola para definir uma etiqueta de política, consulte o artigo Defina uma etiqueta de política numa coluna.

   Em alternativa, pode definir a etiqueta de política através do comando bq update. O campo names de policyTags inclui o ID da etiqueta de política High, projects/project-id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id:

   [
    ...
    {
      "name": "ssn",
      "type": "STRING",
      "mode": "REQUIRED",
      "policyTags": {
        "names": ["projects/project-id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id"]
      }
    },
    ...
   ]

   Para ver detalhes sobre a utilização do comando bq update para definir uma etiqueta de política, consulte o artigo Defina uma etiqueta de política numa coluna.

   Nota: só pode atribuir uma etiqueta de política por coluna.

6. O administrador executa passos semelhantes para a etiqueta de política Médio.

Com este acesso detalhado, pode gerir o acesso a muitas colunas controlando apenas um pequeno número de etiquetas de políticas de classificação de dados.

Para ver detalhes acerca destes passos, consulte o artigo Restringir o acesso com o controlo de acesso ao nível da coluna.

Funções usadas com o controlo de acesso ao nível da coluna

As seguintes funções são usadas para o controlo de acesso ao nível da coluna do BigQuery.

A função de administrador de etiquetas de políticas do catálogo de dados é necessária para os utilizadores que precisam de criar e gerir taxonomias e etiquetas de políticas.

Função/ID	Autorizações	Descrição
Administrador de etiquetas de políticas do catálogo de dados/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 ao nível do projeto. Esta função concede a capacidade de fazer o seguinte: Criar, ler, atualizar e eliminar taxonomias e etiquetas de políticas. Obter e definir políticas IAM em etiquetas de políticas.

A função de administrador de políticas de dados do BigQuery, a função de administrador do BigQuery ou a função de proprietário de dados do BigQuery são necessárias para criar e gerir políticas de dados. Quando usa a consola Google Cloud para aplicar o controlo de acesso a uma taxonomia, o serviço cria automaticamente uma política de dados para si.

Função/ID	Autorizações	Descrição
Administrador da política de dados do BigQuery/bigquerydatapolicy.admin 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 autorizações bigquery.dataPolicies.create e bigquery.dataPolicies.list aplicam-se ao nível do projeto. As outras autorizações aplicam-se ao nível da política de dados. Esta função concede a capacidade de fazer o seguinte: Criar, ler, atualizar e eliminar políticas de dados. Obter e definir políticas IAM em políticas de dados.

Também precisa da autorização datacatalog.taxonomies.get, que pode obter através de várias das funções predefinidas do catálogo de dados.

A função Leitor detalhado do catálogo de dados é necessária para os utilizadores que precisam de acesso a dados em colunas protegidas.

Função/ID	Autorizações	Descrição
Leitor detalhado/datacatalog.categoryFineGrainedReader	datacatalog.categories.fineGrainedGet	Aplica-se ao nível da etiqueta de política. Esta função concede a capacidade de aceder ao conteúdo de colunas restritas por uma etiqueta de política.

Para saber mais acerca das funções do Data Catalog, consulte o artigo Gestão de identidade e de acesso (IAM) do Data Catalog. Para saber mais sobre as funções do BigQuery, consulte o artigo Controlo de acesso com a IAM.

Impacto das escritas

Para ler dados de uma coluna protegida pelo controlo de acesso ao nível da coluna, o utilizador tem sempre de ter autorização de leitura através do acesso de leitura detalhado nas etiquetas de política da coluna.

Isto aplica-se ao seguinte:

• Tabelas, incluindo tabelas com carateres universais
• Visualizações
• Copiar tabelas

Para escrever dados numa linha para uma coluna protegida pelo controlo de acesso ao nível da coluna, o requisito do utilizador depende do tipo de escrita.

Se a operação de escrita for uma inserção, não é necessário um acesso de leitura detalhado. No entanto, o utilizador não tem acesso para ler os dados que foram inseridos, a menos que tenha acesso de leitura detalhado.

Se um utilizador executar uma declaração INSERT SELECT, é necessária a função de leitor detalhada na tabela consultada.

Se a operação de escrita for uma atualização, uma eliminação ou uma união, o utilizador não pode realizar a operação, a menos que tenha acesso de leitura detalhado nas colunas de leitura.

Um utilizador pode carregar dados de ficheiros locais ou do Cloud Storage. Quando carrega dados para uma tabela, o BigQuery não verifica a autorização de leitor detalhada nas colunas da tabela de destino. Isto acontece porque o carregamento de dados não requer a leitura de conteúdo da tabela de destino. Da mesma forma, um utilizador pode carregar dados a partir da transmissão em fluxo contínuo, porque os carregamentos de transmissão em fluxo contínuo não verificam as etiquetas de políticas. O utilizador não tem acesso para ler os dados carregados a partir de uma stream, a menos que tenha acesso de leitura detalhado.

Para mais informações, consulte o artigo Impacto nas gravações com o controlo de acesso ao nível da coluna.

Consultar tabelas

Se um utilizador tiver acesso ao conjunto de dados e tiver a função de leitor detalhado do catálogo de dados, os dados da coluna estão disponíveis para o utilizador. O utilizador executa uma consulta como habitualmente.

Se um utilizador tiver acesso ao conjunto de dados, mas não tiver a função de leitor detalhado do Data Catalog, os dados da coluna não estão disponíveis para o utilizador. Se um utilizador executar SELECT *, recebe um erro que indica as colunas às quais não pode aceder. Para resolver o erro, pode:

• Modifique a consulta para excluir as colunas às quais o utilizador não pode aceder. Por exemplo, se o utilizador não tiver acesso à coluna ssn, mas tiver acesso às restantes colunas, pode executar a seguinte consulta:

  SELECT * EXCEPT (ssn) FROM ...

  No exemplo anterior, a cláusula EXCEPT exclui a coluna ssn.

• Peça a um administrador do Data Catalog para adicionar o utilizador como leitor detalhado do Data Catalog à classe de dados relevante. A mensagem de erro indica o nome completo da etiqueta de política para a qual o utilizador precisa de acesso.

Consultar vistas

O impacto da segurança ao nível da coluna nas vistas é independente do facto de a vista ser ou não uma vista autorizada. Em ambos os casos, a segurança ao nível da coluna é aplicada de forma transparente.

Uma visualização autorizada é uma das seguintes:

• Uma vista que tem autorização explícita para aceder às tabelas num conjunto de dados.
• Uma vista que está implicitamente autorizada a aceder às tabelas num conjunto de dados porque está contida num conjunto de dados autorizado.

Para mais informações, consulte Vistas autorizadas e Conjuntos de dados autorizados.

Se a visualização não for uma visualização autorizada:

Se o utilizador tiver acesso à IAM às tabelas e ao conjunto de dados subjacentes da visualização de propriedade, bem como acesso ao nível da coluna às tabelas subjacentes da visualização de propriedade, pode consultar as colunas na visualização de propriedade. Caso contrário, o utilizador não pode consultar as colunas na vista.

Se a visualização for uma visualização autorizada:

Apenas a segurança ao nível da coluna nas tabelas subjacentes da vista controla o acesso. As políticas de IAM ao nível da tabela e do conjunto de dados, se existirem, não são usadas para verificar o acesso. Se o utilizador tiver acesso às etiquetas de políticas usadas nas tabelas subjacentes da visualização autorizada, pode consultar as colunas na visualização autorizada.

O diagrama seguinte mostra como o acesso a uma vista é avaliado.

Impacto da viagem no tempo e das vistas materializadas com max_staleness

O BigQuery permite-lhe consultar uma tabela num estado anterior. Esta capacidade permite-lhe consultar as linhas de um ponto anterior no tempo. Também lhe permite restaurar uma tabela a partir de um determinado momento.

No SQL antigo, consulta dados do histórico através de decoradores de tempo no nome da tabela. No GoogleSQL, consulta dados do histórico através da cláusula FOR SYSTEM_TIME AS OF na tabela.

As vistas materializadas com a opção max_staleness definida devolvem dados do histórico do respetivo intervalo de desatualização. Este comportamento é semelhante a uma consulta que usa FOR SYSTEM_TIME AS OF no momento da última atualização da vista, uma vez que permite ao BigQuery consultar registos que foram eliminados ou atualizados. Suponhamos que consulta os dados do histórico de uma tabela no momento t. Nesse caso:

• Se o esquema no momento t for idêntico ou um subconjunto do esquema atual da tabela, o BigQuery faz a verificação em relação à segurança ao nível da coluna mais recente na tabela atual. Se o utilizador tiver autorização para ler as colunas atuais, pode consultar os dados do histórico dessas colunas. Para eliminar ou ocultar dados sensíveis de colunas protegidas pela segurança ao nível da coluna, a segurança ao nível da coluna só pode ser relaxada em segurança após a passagem do período de viagem no tempo configurado desde a limpeza dos dados sensíveis.

• Se o esquema no momento t diferir do esquema atual das colunas na consulta, a consulta falha.

Considerações sobre a localização

Quando escolher uma localização para a sua taxonomia, tenha em atenção as seguintes limitações.

Etiquetas de políticas

As taxonomias são recursos regionais, como tabelas e conjuntos de dados do BigQuery. Quando cria uma taxonomia, especifica a região ou a localização da taxonomia.

Pode criar uma taxonomia e aplicar etiquetas de políticas a tabelas em todas as regiões onde o BigQuery está disponível. No entanto, para aplicar etiquetas de políticas de uma taxonomia a uma coluna de tabela, a taxonomia e a tabela têm de existir na mesma localização regional.

Embora não possa aplicar uma etiqueta de política a uma coluna de tabela que exista numa localização diferente, pode copiar a taxonomia para outra localização replicando-a explicitamente nessa localização.

Se quiser usar a mesma taxonomia e etiquetas de políticas em várias localizações regionais, saiba mais sobre como replicar taxonomias no artigo Gerir etiquetas de políticas em várias localizações.

Organizações

Não pode usar referências entre organizações. Uma tabela e todas as etiquetas de políticas que quer aplicar às respetivas colunas têm de existir na mesma organização.

Limitações

• 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.

• O BigQuery só suporta o controlo de acesso ao nível da coluna para tabelas do BigLake, tabelas do BigQuery e tabelas do BigQuery Omni.

• Se substituir uma tabela de destino, todas as etiquetas de políticas existentes são removidas da tabela, a menos que use a flag --destination_schema para especificar um esquema com etiquetas de políticas. O exemplo seguinte mostra como usar --destination_schema.

  bq query --destination_table mydataset.mytable2 \
    --use_legacy_sql=false --destination_schema=schema.json \
    'SELECT * FROM mydataset.mytable1'
  

  As alterações ao esquema ocorrem numa operação separada da execução da consulta. Se escrever resultados de consultas numa tabela especificando a flag --destination_table e, posteriormente, a consulta gerar uma exceção, é possível que as alterações ao esquema sejam ignoradas. Se isto ocorrer, verifique o esquema da tabela de destino e, se necessário, atualize-o manualmente.

• Uma coluna só pode ter uma etiqueta de política.

• Uma tabela pode ter, no máximo, 1000 etiquetas de políticas únicas.

• Não pode usar o SQL antigo se tiver ativado o controlo de acesso ao nível da coluna. Todas as consultas SQL antigas são rejeitadas se existirem etiquetas de política nas tabelas de destino.

• 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:

  

• Os nomes das taxonomias têm de ser exclusivos entre todos os projetos de uma organização.

• Não é possível copiar uma tabela entre regiões se tiver ativado o controlo de acesso ao nível da coluna ou da linha. Todas as cópias de tabelas entre regiões são rejeitadas se existirem etiquetas de política nas tabelas de origem.

Preços

O controlo de acesso ao nível da coluna requer a utilização do BigQuery e do Data Catalog. Para ver informações de preços sobre estes produtos, consulte os seguintes tópicos:

• Preços do BigQuery
• Preços do catálogo de dados

Registo de auditoria

Quando os dados de tabelas com etiquetas de políticas são lidos, guardamos as etiquetas de políticas referenciadas no Cloud Logging. No entanto, a verificação da etiqueta de política não está associada à consulta que acionou a verificação.

Através do Cloud Logging, os auditores podem compreender quem tem que tipo de acesso a que categorias de dados confidenciais. Para mais informações, consulte o artigo Auditar etiquetas de políticas.

Para mais informações sobre o registo no BigQuery, consulte o artigo Introdução à monitorização do BigQuery.

Para mais informações sobre como iniciar sessão Google Cloud, consulte o Cloud Logging.

O que se segue?

• Para ver detalhes sobre a utilização do controlo de acesso ao nível da coluna, consulte o artigo Restringir o acesso com o controlo de acesso ao nível da coluna.

• Para informações sobre as práticas recomendadas para etiquetas de políticas, consulte o artigo Práticas recomendadas do BigQuery: usar etiquetas de políticas.