Introdução aos controles de acesso de tabelas

Este documento fornece uma visão geral da ACL de tabela do BigQuery.

A ACL do BigQuery permite definir permissões no nível da tabela em recursos como tabelas e visualizações. As permissões no nível da tabela determinam os usuários, grupos e contas de serviço que podem acessar uma tabela ou visualização. É possível conceder a um usuário acesso a tabelas ou visualizações específicas, sem conceder acesso ao conjunto de dados completo. Por exemplo, conceda o papel BigQuery Data Viewer (roles/bigquery.dataViewer) a um usuário para permitir que ele consulte apenas a tabela ou visualização sem acesso completo ao conjunto de dados.

Controle de acesso com políticas de gerenciamento de identidade e acesso

É possível configurar a política de controle de acesso em uma tabela ou visualização usando uma política de gerenciamento de identidade e acesso (IAM, na sigla em inglês).

Ver a política de IAM de uma tabela ou visualização

Depois que uma tabela ou visualização é criada, é possível ver a política do IAM das seguintes maneiras:

Definir a política de IAM de uma tabela ou visualização

É possível definir ou atualizar a política de controle de acesso em um recurso das seguintes maneiras:

Uma visualização também pode se referir a outras tabelas e visualizações de origem que você compartilhou usando a ACL da tabela do BigQuery.

O acesso com a ACL da tabela do BigQuery é adicional. Para mais informações sobre o controle de acesso aditivo, consulte Como controlar o acesso a visualizações. A ACL da tabela do BigQuery não é compatível com a permissão deny.

É possível testar se um usuário tem acesso a uma tabela ou visualização específica usando o método tables.testIamPermissions. Para mais informações, consulte Como testar permissões.

Para mais informações sobre como configurar uma política, com instruções passo a passo, consulte Como controlar o acesso a tabelas e visualizações.

Exemplo de caso de uso:

Alice é a proprietária dos dados de uma empresa e quer compartilhar a tabela inventory com os proprietários de lojas franqueadas. A tabela está em um conjunto de dados que contém outras tabelas que Alice não quer compartilhar com proprietários de lojas de franquias.

Bob é um proprietário de uma loja da franquia. Alice usa a ferramenta de linha de comando bq para conceder a Bob e a outros proprietários de lojas da franquia o papel Visualizador de dados do BigQuery (roles/bigquery.dataViewer) na tabela inventory. Bob agora pode consultar a tabela inventory diretamente sem precisar de acesso a todo o conjunto de dados.

Para permitir que Bob veja uma lista das tabelas a que ela tem acesso, Alice pode conceder a ele a permissão bigquery.tables.list no conjunto de dados. O papel Leitor de metadados do BigQuery (roles/bigquery.metadataViewer) inclui a permissão bigquery.tables.list.

Políticas do IAM

Os controles de acesso no nível da tabela são criados com base no IAM. O IAM permite controlar quem (usuários) tem qual acesso (papéis) a quais recursos, definindo políticas. Essa política define e impõe quais papéis são concedidos a quais membros, e essa política está anexada a um recurso. Quando um membro autenticado tenta acessar um recurso, o IAM verifica a política do recurso para determinar se a ação é permitida.

Para a ACL da tabela do BigQuery, o recurso é uma tabela do BigQuery, e os membros são os usuários da tabela.

No exemplo a seguir, mostramos uma política com estes papéis:

  • alice@example.com recebeu o papel de proprietário de dados do BigQuery (roles/bigquery.dataOwner).

  • bob@example.com recebeu o papel de visualizador de dados do BigQuery (roles/bigquery.dataViewer).

{
  "bindings":[
    {
      "members":[
        "user:alice@example.com"
      ],
      "role":"roles/bigquery.dataOwner"
    },
    {
      "members":[
        "user:bob@example.com"
      ],
      "role":"roles/bigquery.dataViewer"
    }
  ],
  "etag":"ABAC",
  "version":1
}

Para mais informações sobre políticas de IAM, consulte Noções básicas sobre políticas.

Permissões da ACL da tabela do BigQuery

Para definir ou alterar o acesso a uma tabela ou visualização, é necessário ter a permissão bigquery.tables.setIamPolicy. Os papéis predefinidos do BigQuery a seguir têm a permissão bigquery.tables.setIamPolicy.

  • Administrador do BigQuery (roles/bigquery.admin)
  • Proprietário de dados do BigQuery (roles/bigquery.dataOwner)

Para recuperar o acesso definido em uma tabela ou visualização, é necessário ter a permissão bigquery.tables.getIamPolicy. Os papéis predefinidos do BigQuery a seguir têm a permissão bigquery.tables.getIamPolicy.

  • Administrador do BigQuery (roles/bigquery.admin)
  • Editor de dados do BigQuery (roles/bigquery.dataEditor)
  • Leitor de metadados do BigQuery (roles/bigquery.metadataViewer)
  • Proprietário de dados do BigQuery (roles/bigquery.dataOwner)
  • Leitor de dados do BigQuery (roles/bigquery.dataViewer)

Tempo até a conversão da mudança da política

Em geral, todas as alterações feitas na política entram em vigor em 60 segundos. No entanto, em determinadas circunstâncias, pode levar até sete minutos para que essas alterações se propaguem pelo sistema. Para mais informações, consulte Como conceder, alterar e revogar acesso a recursos. Além disso, neste documento, consulte Impacto no armazenamento em cache.

Impacto no armazenamento em cache

Se o armazenamento em cache estiver ativado, é possível que uma conta veja os resultados de consulta autorizados anteriormente depois que ela não tiver mais acesso à tabela. Especificamente, se o usuário executou a consulta anteriormente e você removeu o acesso do usuário, ele pode acessar resultados do cache de resultados da consulta. O BigQuery armazena em cache apenas os acessos autorizados e eles são armazenados em cache por apenas alguns minutos.

Impacto na viagem no tempo

A cláusula FOR SYSTEM_TIME AS OF é o recurso de "viagem de tempo" do BigQuery que permite recuperar dados de até sete dias atrás. Se você usar esse recurso, o BigQuery aplicará a ACL da tabela atual à solicitação. Se você acessou o tabela anteriormente, mas seu acesso foi removido, não será possível acessar as versões anteriores da tabela.

Impacto ao copiar tabelas

Quando você copia dados para uma nova tabela, as ACLs de tabela na tabela de origem não são copiadas automaticamente. Se você quiser uma ACL de tabela em uma nova tabela criada por meio de uma cópia, será necessário definir explicitamente uma ACL de tabela na nova tabela.

Comparação com visualizações autorizadas

O BigQuery também fornece acesso usando visualizações autorizadas. Uma visualização autorizada permite que você compartilhe resultados de consultas com usuários e grupos específicos sem conceder a eles acesso às tabelas subjacentes. O acesso de visualização autorizado é sempre somente leitura.

Por exemplo, a visualização autorizada dept_view permite que o usuário joe@example.com veja o salário médio por departamento, mas não o salário de cada pessoa no conjunto de dados salary subjacente. Se dept_view tiver acesso à origem de dados, joe@example.com só precisará de permissões em dept_view.

A principal diferença entre uma visualização normal e uma visualização autorizada é a autorização para controlar o acesso aos dados da tabela de origem. O acesso de visualização regular aos dados da tabela de origem é verificado em nome da autoridade do usuário final. O acesso de uma visualização autorizada aos dados da tabela de origem é verificado usando a própria autoridade da visualização autorizada.

Com a adição da ACL de tabela do BigQuery, você tem as seguintes opções para acesso à tabela:

  • Compartilhar um conjunto de dados, incluindo todas as tabelas de origem, com os usuários. Essa opção é o controle de acesso do IAM definido no nível do conjunto de dados.
  • Crie uma visualização autorizada para acessar dados de origem a que o usuário não tem acesso de IAM. Os dados de origem são acessados com base na própria autoridade de visualização autorizada, não na autoridade do usuário. Esta opção é o recurso de visualizações autorizadas.
  • Compartilhar uma tabela ou visualização com usuários específicos sem compartilhar todos os dados no conjunto de dados pai. Essa opção é o recurso ACL da tabela do BigQuery.

Compatibilidade com outros recursos do BigQuery

No modelo de acesso do IAM, as permissões são adicionais. As permissões são herdadas de um recurso pai, conforme descrito na Hierarquia de recursos. Todas as permissões adicionadas ao recurso resultam em acesso adicional. Uma ACL de tabela só pode permitir mais acesso. Ela não pode remover nenhum conjunto de dados ou acessos ao projeto do Google Cloud. Se um recurso do BigQuery não consegue verificar o acesso no nível da tabela, ele volta para o controle de acesso no nível do conjunto de dados. Como resultado, a ACL da tabela do BigQuery é compatível com outros recursos do BigQuery.

Compatibilidade com o VPC Service Controls

O VPC Service Controls usa o IAM para controlar o acesso a serviços como o BigQuery e o Cloud Storage. A ACL da tabela do BigQuery usa o IAM para fornecer uma granularidade mais profunda do controle de acesso em tabelas individuais do BigQuery. Como o IAM é usado de forma complementar, o VPC Service Controls e a ACL da tabela do BigQuery são compatíveis.

Audit logging

Definir uma política em uma tabela ou visualização é uma atividade do administrador. Uma atividade do administrador é sempre registrada. Para ver a atividade registrada, use os registros de auditoria do Cloud para encontrar ocorrências de methodName definidas como "google.iam.v1.IAMPolicy.SetIamPolicy".

Geração de registros da ACL da tabela

Limitações

  • Visualizações autorizadas no nível da tabela não são aceitas. As visualizações autorizadas só podem receber acesso a conjuntos de dados inteiros. No entanto, é possível usar a ACL de tabela do BigQuery para conceder aos usuários acesso a uma tabela ou visualização individual.

  • Atualmente, se uma tabela for compartilhada diretamente sem o conjunto de dados subjacente, ela não aparecerá nos resultados da pesquisa do Data Catalog.

  • Quando você consulta tabelas curinga, os controles de acesso no nível da tabela não são verificados. Se você pretende compartilhar tabelas que os usuários acessam usando um caractere curinga de tabela em uma consulta, você precisa conceder acesso ao conjunto de dados que contém as tabelas.

  • Assim como as tabelas de caracteres curinga, as tabelas no conjunto de dados INFORMATION_SCHEMA não estão sujeitas ao controle de acesso no nível da tabela. Elas também exigem permissões no nível do conjunto de dados.

A seguir