Resolver problemas de controle de acesso

Neste documento, mostramos como resolver problemas de segurança com permissões do Identity and Access Management (IAM), controle de acesso no nível da coluna e chaves de criptografia gerenciadas pelo cliente (CMEK) no BigQuery. Problemas de permissão do IAM normalmente resultam em erros Access Denied, como os seguintes:

  • Access Denied: Project PROJECT_ID: User does not have bigquery.jobs.create permission in project PROJECT_ID.
  • Access Denied: Project PROJECT_ID: User does not have bigquery.datasets.get permission on dataset DATASET.
  • User does not have permission to query table PROJECT_ID:DATASET.TABLE.
  • Access Denied: Table PROJECT_ID:DATASET.TABLE: User does not have permission to query table PROJECT_ID:DATASET.TABLE, or perhaps it does not exist.
  • Access Denied: User PRINCIPAL does not have permission to perform bigquery.tables.getData on resource 'projects/PROJECT_ID/datasets/DATASET/tables/TABLE'.

Antes de começar

Coletar informações sobre o problema

A primeira etapa para solucionar um problema de acesso a recursos é determinar a permissão que está faltando, o principal do IAM que teve o acesso negado e o recurso que o principal estava tentando acessar.

Receber informações do histórico de erros ou jobs

Para receber informações sobre o principal, o recurso e as permissões, analise a saída da ferramenta de linha de comando bq, a resposta da API ou o BigQuery no console do Google Cloud .

Por exemplo, se você tentar executar uma consulta com permissões insuficientes, vai receber um erro como o seguinte na guia Informações do job na seção Resultados da consulta do console do Google Cloud .

Um erro de acesso negado na guia "Informações do job" na seção "Resultados da consulta".

Analise o erro para determinar o principal, o recurso e as permissões.

Em alguns casos, é possível solicitar permissões ausentes diretamente na mensagem de erro. Para mais informações, consulte Mensagens de erro de permissão na documentação do IAM.

Receber informações dos Registros de Auditoria do Cloud

Se a mensagem de erro for genérica, não tiver informações ou se a ação falhar em um processo em segundo plano, use a Análise de registros dos Registros de auditoria do Cloud para receber informações sobre o erro.

  1. No console do Google Cloud , acesse a página Análise de registros.

    Acessar a Análise de registros

    Como alternativa, no menu de navegação, escolha Monitoramento > Análise de registros.

  2. Na Análise de Registros, para o escopo do registro, escolha Registros do projeto.

  3. Na janela de consulta, insira a consulta a seguir para receber erros relacionados a permissões dos registros de acesso a dados do BigQuery:

    resource.type=("bigquery_resource" OR "bigquery_project" OR "bigquery_dataset") AND
logName=("projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access" OR
  "projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity") AND
(protoPayload.status.message:"Access Denied" OR
  protoPayload.status.message:"Permission denied" OR
  protoPayload.status.code=7)

    Substitua PROJECT_ID pelo ID do projeto.

  4. Nos resultados da consulta, expanda a entrada de registro que corresponde à operação com falha.

  5. Na seção protoPayload, expanda a matriz authorizationInfo e, em seguida, expanda cada nó na matriz authorizationInfo.

    A matriz authorizationInfo mostra todas as verificações de permissão realizadas durante a chamada de API.

  6. Para ver a causa do erro, procure a entrada granted: false. A entrada granted: false mostra as seguintes informações:

    • permission: a string de permissão do IAM que foi verificada. Por exemplo, bigquery.tables.getData.
    • resource: o nome totalmente qualificado do recurso que o principal tentou acessar. Por exemplo, projects/myproject/datasets/mydataset/tables/mytable.
    • principalEmail (se disponível): referenciado em protoPayload.authenticationInfo, esse é o principal que tentou a ação.

    A seção authorizationInfo do protoPayload que mostra a permissão, o recurso e o principalEmail.

Usar a ferramenta Análise de Políticas para políticas de permissão

A ferramenta Análise de políticas para políticas de permissão permite descobrir quais principais do IAM têm acesso a quais recursos do BigQuery com base nas políticas de permissão do IAM.

Depois de coletar informações sobre o erro de permissões, use a Análise de políticas para entender por que o principal não tem o acesso necessário. Essa ferramenta analisa todas as políticas relevantes, as participações em Grupos do Google e a herança de recursos pai, como um projeto, uma pasta e sua organização.

Para usar a Análise de Políticas em políticas de permissão, crie uma consulta de análise, especifique um escopo para a análise e execute a consulta.

  1. No console do Google Cloud , acesse a página Análise de políticas.

    Acessar a Análise de Políticas

    Como alternativa, no menu de navegação, escolha IAM e administrador > Análise de políticas.

  2. Clique em Criar consulta personalizada.

  3. Na página Configurar sua consulta, insira as informações que você coletou anteriormente:

    1. Na seção Selecionar o escopo, no campo Selecionar escopo da consulta, verifique se o projeto atual aparece ou clique em Procurar para escolher outro recurso.

    2. Na seção Definir os parâmetros de consulta, em Parâmetro 1, escolha Principal e, no campo Principal, insira o e-mail do usuário, grupo ou conta de serviço.

    3. Clique em Adicionar parâmetro.

    4. Em Parâmetro 2, escolha Permissão e, no campo Permissão, clique em Selecionar, escolha a permissão do BigQuery e clique em Adicionar. Por exemplo, selecione bigquery.tables.getData.

    5. Clique em Adicionar parâmetro.

    6. Em Parâmetro 3, escolha Recurso e, no campo Recurso, insira o nome totalmente qualificado do recurso. O nome do recurso precisa incluir o prefixo do serviço, como nos exemplos a seguir:

      • Projeto do BigQuery: //cloudresourcemanager.googleapis.com/projects/PROJECT_ID
      • Conjunto de dados do BigQuery: //bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET
      • Tabela do BigQuery: //bigquery.googleapis.com/projects/PROJECT/datasets/DATASET/tables/TABLE

  4. No painel Consulta personalizada, clique em Analisar > Executar consulta.

  5. Analise os resultados da consulta. O resultado pode ser um dos seguintes:

    • Uma lista vazia. Nenhum resultado confirma que o principal não tem a permissão necessária. Será necessário conceder ao principal um papel que forneça as permissões corretas.
    • Um ou mais resultados. Se o analisador encontrar uma política de permissão, alguma forma de acesso existe. Clique em Ver vinculação em cada resultado para conferir os papéis que dão acesso ao recurso de que o principal é membro. A vinculação de política mostra se o acesso é concedido por meio de associação ou herança de grupo ou se o acesso é negado por uma condição do IAM ou uma política de negação do IAM.

Encontrar o papel do IAM correto que concede as permissões necessárias

Depois de confirmar que o principal não tem acesso suficiente, a próxima etapa é encontrar o papel predefinido ou personalizado do IAM que concede as permissões necessárias. O papel escolhido precisa seguir o princípio de privilégio mínimo.

Se a organização usa papéis personalizados, é possível encontrar o papel correto listando todos os papéis personalizados criados no projeto ou na organização. Por exemplo, no console do Google Cloud , na página Papéis, é possível filtrar a lista por Tipo:personalizado para ver apenas os papéis personalizados.

Para encontrar o papel predefinido correto do IAM, siga estas etapas.

  1. Abra a seção de permissões do BigQuery da página de papéis e permissões do IAM do BigQuery.

  2. Na barra de pesquisa Inserir uma permissão, digite a permissão que você recuperou da mensagem de erro, do histórico de jobs ou dos registros de auditoria. Por exemplo, bigquery.tables.getData.

    Os resultados da pesquisa mostram todos os papéis predefinidos do BigQuery que concedem a permissão.

  3. Aplique o princípio de privilégio mínimo: na lista de papéis, escolha o papel menos permissivo que concede as permissões necessárias. Por exemplo, se você pesquisou bigquery.tables.getData para conceder a capacidade de consultar dados de tabela, Leitor de dados do BigQuery é o papel menos permissivo que concede essa permissão.

  4. Conceda ao principal o papel apropriado. Para informações sobre como conceder um papel do IAM a um recurso do BigQuery, consulte Controlar o acesso a recursos com o IAM.

Resolver problemas comuns de acesso negado

Quando uma operação falha com 403 accessDenied (Access Denied: RESOURCE_TYPE RESOURCE_ID: DETAILS), verifique os seguintes cenários comuns, além das etapas gerais do IAM anteriores:

  • Recurso inexistente ou incompatibilidade de local (or perhaps it does not exist). Quando uma mensagem de erro termina com or perhaps it does not exist, o BigQuery mascara se a tabela, visualização ou rotina existe porque o principal não tem permissões de metadados de conjunto de dados ou projeto (bigquery.tables.get ou bigquery.datasets.get). Verifique se o ID do projeto, o ID do conjunto de dados e o nome da tabela estão escritos corretamente e confirme se a consulta é executada no mesmo local que o conjunto de dados.
  • Visualizações e rotinas autorizadas. Quando um usuário consulta uma visualização autorizada ou rotina autorizada, ele precisa de permissão para consultar a visualização ou rotina, e a visualização ou rotina em si precisa ser autorizada na lista de controle de acesso (ACL) do conjunto de dados de origem. Se a consulta falhar com Access Denied na tabela base, adicione a visualização ou rotina (ou todo o conjunto de dados como um conjunto de dados autorizado) à lista de acesso autorizado do conjunto de dados de origem. Se uma visualização consultar outra, todas as visualizações na cadeia precisarão ser autorizadas no conjunto de dados de onde ela lê. Se uma visualização autorizada foi excluída e recriada com o mesmo nome, ela pode permanecer na lista de acesso autorizado do conjunto de dados de origem por até 24 horas, e a autorização da nova visualização falha com Duplicate authorized views. Remova a entrada antiga da lista e autorize a nova visualização ou atualize a consulta SQL da visualização em vez de excluir e recriar a visualização. Se você modificar uma rotina autorizada com uma instrução CREATE OR REPLACE ou o método routines.update, será necessário autorizar novamente a rotina.
  • VPC Service Controls. Se a organização usa o VPC Service Controls, as solicitações que cruzam um limite de perímetro de serviço falham com 403 accessDenied ou policyViolation. Pesquise os Registros de auditoria do Cloud no momento da falha para encontrar o valor vpcServiceControlsUniqueIdentifier da mensagem de erro e use o Analisador de violações para inspecionar as regras de entrada e saída. Para saber qual consulta da Análise de Registros usar, consulte A solicitação é proibida pela política da organização.
  • Papéis básicos (roles/owner, roles/editor, roles/viewer). Os papéis básicos do projeto não incluem permissões no nível da organização necessárias para visualizações como INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE_BY_ORGANIZATION ou permissões especializadas como bigquery.rowAccessPolicies.overrideTimeTravelRestrictions, que é necessária para acessar os dados históricos de uma tabela que tem ou tinha políticas de acesso no nível da linha (consulte Viagem no tempo e acesso no nível da linha). Conceda papéis predefinidos do IAM do BigQuery em vez de usar papéis básicos.
  • Substituições temporárias da política do IAM (SetIamPolicy): se as permissões funcionarem de forma intermitente e depois falharem, pesquise protoPayload.methodName=~"SetIamPolicy" nos registros de auditoria de atividade do administrador para verificar se um script automatizado ou um pipeline de infraestrutura como código está substituindo as vinculações de política atuais em vez de mesclá-las.
  • Fontes de dados externas (Google Drive, Cloud Storage, BigLake):
    • Google Drive (Permission denied while getting Drive credentials). Conceda ao usuário ou à conta de serviço acesso de visualizador ao arquivo do Google Drive ou à planilha do Google, verifique se o autor da chamada fornece o escopo OAuth https://www.googleapis.com/auth/drive ou atualize as credenciais de consulta programada.
    • Tabelas do Cloud Storage e do BigLake. Conceda roles/storage.objectViewer no bucket do Cloud Storage ao usuário (para tabelas externas padrão) ou à conta de serviço de conexão do BigLake (para tabelas do BigLake).
  • Chaves de criptografia gerenciadas pelo cliente (CMEK). Se a consulta fizer referência a uma tabela protegida por CMEK, verifique se a chave correspondente do Cloud KMS existe e está ativada. Se um job de consulta ou carregamento falhar com Cloud KMS Error: Permission 'cloudkms.cryptoKeyVersions.useToEncrypt' denied (ou useToDecrypt), conceda ao agente de serviço de criptografia do BigQuery (bq-PROJECT_NUMBER@bigquery-encryption.iam.gserviceaccount.com) o papel roles/cloudkms.cryptoKeyEncrypterDecrypter na chave do Cloud Key Management Service. Consulte Conceder permissões de criptografia e descriptografia. Para outros erros de CMEK, consulte Resolver problemas de chaves de criptografia gerenciadas pelo cliente.
  • Identidade temporária de conta de serviço. Se uma solicitação que usa a identidade temporária de conta de serviço falhar com Permission 'iam.serviceAccounts.getAccessToken' denied, conceda roles/iam.serviceAccountTokenCreator ao principal de chamada na conta de serviço de destino.
  • Segurança no nível da coluna (tags de política) e segurança no nível da linha. Se uma consulta ou instrução DML falhar com Requires fineGrainedGet permission on the read columns ou User does not have permission to access data protected by policy tag, conceda ao principal o papel de Leitor de controle refinado (roles/datacatalog.categoryFineGrainedReader) do Data Catalog na tag de política ou exclua as colunas protegidas da lista SELECT. Consulte Permissões de controle de acesso insuficientes no nível da coluna. Se a tabela usar segurança no nível da linha, revise as políticas de acesso no nível da linha ativas no console do Google Cloud ou executando bq ls --row_access_policies. Consulte Listar políticas de acesso no nível da linha da tabela.
  • Atrasos na propagação de metadados e do IAM. Os papéis do IAM recém-concedidos e as atualizações de ACL do conjunto de dados têm consistência posterior e normalmente levam alguns minutos para serem propagados nos caches. Se uma permissão acabou de ser concedida, aguarde alguns minutos e tente novamente.

Os Termos de Serviço do BigQuery não foram aceitos

String de erro: BigQuery Terms of Service have not been accepted

Esse erro HTTP 403 Forbidden (reason: termsOfServiceNotAccepted) ocorre quando os Termos de Serviço do BigQuery não são aceitos. O erro não é causado pela falta de permissões do IAM. Ele pode ser retornado para solicitações como criar um conjunto de dados ou carregar dados.

Para resolver esse problema, faça o seguinte:

  1. No console do Google Cloud , acesse a página BigQuery.

    Acessar o BigQuery

  2. Se a página de recepção aparecer, selecione seu país, marque a caixa de seleção Termos de Serviço e clique em Concordar e continuar. Para mais informações, consulte Ativar o sandbox do BigQuery.

Depois que os Termos de Serviço forem aceitos, tente fazer a solicitação novamente.

Resolver erros de violação de política

Quando você recebe um erro HTTP 403 PERMISSION_DENIED no BigQuery com o motivo policyViolation, isso indica uma falha causada por políticas da organização, perímetros de dados ou VPC Service Controls.

As seções a seguir descrevem as mensagens de erro mais comuns associadas a esse motivo, o que as causa e como resolvê-las.

A solicitação é proibida pela política da organização

String de erro: VPC Service Controls: Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: VPC_SERVICE_CONTROLS_UNIQUE_IDENTIFIER

Diagnóstico

Sua solicitação foi originada de um endereço de rede ou cliente que está fora do perímetro designado do VPC Service Controls, ou a solicitação violou as regras de entrada e saída definidas para seu espaço de trabalho. Isso costuma ocorrer quando a consulta abrange vários projetos. Por exemplo, o projeto de faturamento da consulta está fora do perímetro seguro do projeto de dados.

Resolução

  1. Encontre o ID exclusivo. Recupere o vpcServiceControlsUniqueIdentifier incluído na mensagem de erro. Use esse ID para filtrar a Análise de registros do Google Cloude encontrar o registro correspondente do VPC Service Controls com os detalhes do motivo:

    protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="VPC_SERVICE_CONTROLS_UNIQUE_IDENTIFIER"

    Procure o valor violationReason em protoPayload.metadata.violationReason. Depois de identificados, estude os detalhes adicionais na entrada de registro e siga o guia de solução de problemas do VPC Service Controls. Além disso, use o Analisador de Violações.

  2. Corrigir o faturamento entre projetos. Para consultas entre projetos, verifique se o projeto de faturamento que executa a consulta está no mesmo perímetro que os dados consultados. Se necessário, especifique manualmente um projeto de faturamento compatível usando o seletor de projetos do console do Google Cloud , a flag --project_id na ferramenta de linha de comando bq ou a solicitação de API ou biblioteca de cliente.

  3. Verifique os níveis de acesso. Verifique se a rede, o IP ou a conta de usuário do cliente estão permitidos usando o Access Context Manager. O console doGoogle Cloud requer regras de entrada configuradas especificamente para permitir o acesso do usuário a ambientes protegidos.

A exportação para o Google Drive está bloqueada para projetos com o VPC Service Controls ativado

String de erro: Export to Google Drive is blocked for projects with VPC-SC enabled

Diagnóstico

O Google Drive não é compatível com o VPC Service Controls. Como o Google Drive não pode aplicar o perímetro de segurança, o BigQuery desativa automaticamente a exportação de extrações de API para o Google Drive em qualquer solicitação originada dentro de um limite do VPC Service Controls para evitar a exfiltração de dados.

Resolução

Em vez de exportar diretamente para o Google Drive, extraia os resultados da consulta para um bucket do Cloud Storage localizado no mesmo perímetro do VPC Service Controls ou salve os resultados como um arquivo local.

As tabelas externas do Google Drive são bloqueadas para projetos com o VPC Service Controls ativado

String de erro: Google Drive external tables are blocked for projects with VPC-SC enabled

Diagnóstico

Por padrão, o VPC Service Controls não bloqueia a consulta de tabelas externas do Google Drive (como as páginas conectadas). No entanto, esse erro aparece porque sua organização do Google Cloud solicitou explicitamente que o Google Cloud aplique uma configuração de bloqueio estrita ao projeto para substituir o comportamento permissivo padrão, impedindo qualquer consulta de entrada para dados do Google Drive de dentro de um perímetro do VPC Service Controls.

Resolução

Importe os dados do arquivo do Google Planilhas ou do Google Drive diretamente para uma tabela padrão do BigQuery dentro do perímetro do VPC Service Controls, em vez de consultá-los dinamicamente como uma tabela federada externa. Como alternativa, entre em contato com o administrador interno do Cloud para discutir os limites de exportação de dados da sua organização.

A exportação para o Google Drive está bloqueada para seu projeto

String de erro: Export to Google Drive is blocked for your project.

Diagnóstico

Mesmo sem um perímetro do VPC Service Controls, os administradores do Google Cloud solicitaram que uma configuração organizacional específica e rigorosa seja aplicada ao projeto, negando todos os recursos de extração de dados ao Google Drive.

Resolução

Escolha um destino de extração alternativo, como um bucket do Cloud Storage ou um arquivo local, ou entre em contato com o administrador interno do Cloud para discutir os limites de exportação de dados da sua organização.

O local viola a restrição da política da organização

String de erro: LOCATION violates constraint CONSTRAINT_NAME on the resource projects/PROJECT_ID ou LOCATION violates constraint CONSTRAINT_NAME on the resource projects/PROJECT_ID/datasets/DATASET_ID

Diagnóstico

Seu administrador do Cloud configurou uma restrição da política da organização para limitar exatamente onde os recursos podem ser criados ou analisados. Esse erro costuma aparecer quando:

  • Criar um conjunto de dados em uma região geográfica não autorizada (por exemplo, restrita por constraints/gcp.resourceLocations).
  • Tentativa de usar o BigQuery Omni em nuvens externas quando isso não é permitido (por exemplo, bloqueado por constraints/bigquery.disableBQOmniAWS ou constraints/bigquery.disableBQOmniAzure).

Resolução

  1. Verifique o CONSTRAINT_NAME exato fornecido na mensagem de erro para entender qual ação está sendo bloqueada.
  2. Selecione uma região diferente e desbloqueada para seus dados ou trabalhe com o Google Cloud administrador da organização para revisar a Política da Organização no nível da pasta ou da organização. Consulte Como estruturar e definir locais de recursos para mais detalhes.

Resolver erros de não autenticação

Quando você recebe um erro HTTP 401 Unauthorized (gRPC UNAUTHENTICATED) no BigQuery com o motivo de erro unauthenticated, a solicitação não tem credenciais de autenticação válidas, o token de acesso do OAuth 2.0 expirou ou o autor da chamada não pode se autenticar como a identidade especificada.

As seções a seguir descrevem os cenários mais comuns de unauthenticated, o que os causa e como resolvê-los.

Credenciais inválidas ou expiradas

Strings de erro:

  • Invalid credential
  • User credential was invalid.
  • Credentials expired
  • Credentials missing required scope.
  • Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential.

Diagnóstico

O token de acesso, a chave da conta de serviço ou o Application Default Credentials (ADC) fornecido com a solicitação expirou, foi revogado ou não tem os escopos necessários do OAuth 2.0. Esse erro também ocorre quando a solicitação é assinada com um relógio do sistema que se desviou do horário do Network Time Protocol (NTP).

Resolução

  • Atualize suas credenciais. Se você estiver autenticando em um ambiente de desenvolvimento local, execute gcloud auth application-default login (para ADC) ou gcloud auth login para receber um novo token.
  • Verifique as chaves da conta de serviço e os escopos do OAuth. Se o aplicativo usar GOOGLE_APPLICATION_CREDENTIALS, verifique se a variável aponta para um arquivo de chave JSON válido e não revogado, se a conta de serviço está ativada no console doGoogle Cloud e se a credencial inclui o escopo https://www.googleapis.com/auth/bigquery ou https://www.googleapis.com/auth/cloud-platform necessário.
  • Use as bibliotecas de cliente atuais e sincronize os relógios do sistema. Atualize a biblioteca de cliente do BigQuery ou o driver ODBC ou JDBC para a versão mais recente, de modo que as atualizações de token do OAuth 2.0 e as credenciais federadas sejam processadas automaticamente. Verifique também se o relógio do sistema da máquina host está sincronizado usando o NTP.

Credenciais de usuário final ou permissão de identidade temporária de conta de serviço ausentes

Strings de erro:

  • Current user can not act as user for service account SERVICE_ACCOUNT_EMAIL
  • No end user credentials found when accessing PROJECT_ID:DATASET_ID.TABLE_ID. Please use end user credentials to call BigQuery APIs.

Diagnóstico

O job ou a consulta contínua está configurado para ser executado como uma conta de serviço personalizada que o autor da chamada não tem permissão para personificar, ou a tabela de destino ou os requisitos da política de segurança exigem credenciais de usuário final (EUC, na sigla em inglês) para que o BigQuery possa avaliar o acesso em relação a uma identidade de usuário interativa.

Resolução

  • Conceder permissões de identidade temporária de conta de serviço. Ao executar uma consulta contínua ou um job configurado com uma conta de serviço personalizada, conceda ao autor da chamada o papel de usuário da conta de serviço (roles/iam.serviceAccountUser, que inclui a permissão iam.serviceAccounts.actAs) nessa conta de serviço. Ao representar uma conta de serviço ou trocar credenciais federadas por um token de curta duração, conceda ao autor da chamada o papel de Criador de token da conta de serviço (roles/iam.serviceAccountTokenCreator) na conta de serviço de destino.
  • Autenticar com credenciais de usuário final. Quando o recurso de destino exigir credenciais de usuário final, autentique a solicitação usando as credenciais do OAuth 2.0 de um usuário interativo (por exemplo, executando gcloud auth application-default login ou configurando o OAuth do usuário na ferramenta de BI), em vez de credenciais de conta de serviço independentes.
  • Verifique as regras de entrada e saída do VPC Service Controls. Se a solicitação cruzar um limite do VPC Service Controls, verifique se as regras de entrada e saída do perímetro permitem a identidade do autor da chamada e o recurso de destino.

Conta restrita, suspensa ou excluída

Strings de erro:

  • The account was restricted due to REASON
  • Account deleted

Diagnóstico

A Conta do Google ou do Google Workspace que emitiu a solicitação foi suspensa, desativada, restrita ou excluída por um administrador ou uma política de segurança da conta.

Resolução

Entre em contato com o administrador do Google Workspace ou do Cloud Identity para analisar o status da conta no Google Admin Console e restaurar ou cancelar a suspensão da conta de usuário ou atualizar a carga de trabalho para autenticar com uma conta de serviço ativa.

Resolver problemas de controle de acesso no nível da coluna

As seções a seguir explicam como solucionar problemas com o controle de acesso no nível da coluna e as tags de política do Data Catalog.

Não consigo ver os papéis do Data Catalog

Se você não conseguir ver papéis como Leitor refinado do Data Catalog, é possível que não tenha ativado a API Data Catalog no projeto. Para saber como ativar a API Data Catalog, consulte Antes de começar. Os papéis do Data Catalog aparecem vários minutos depois que você ativa a API Data Catalog.

Não consigo visualizar a página Taxonomias

Você precisa de outras permissões para acessar a página Taxonomias de tag de política no console doGoogle Cloud . Por exemplo, o papel de administrador de tags de política do Data Catalog tem acesso à página Taxonomias.

Apliquei tags de política, mas elas não funcionam

Se você ainda estiver recebendo resultados de consulta para uma conta que não deveria ter acesso, é possível que ela esteja recebendo resultados armazenados em cache. Especificamente, se você executou a consulta com sucesso e, em seguida, aplicou tags de política, talvez esteja recebendo resultados do cache de resultados da consulta. Por padrão, os resultados da consulta são armazenados em cache por 24 horas. A consulta falhará imediatamente se você desativar o cache de resultados. Para mais detalhes sobre o armazenamento em cache, consulte Impacto do controle de acesso no nível da coluna.

Em geral, as atualizações do IAM levam cerca de 30 segundos para serem propagadas. As alterações na hierarquia de tags de política podem levar até 30 minutos para serem propagadas.

Não tenho permissão para ler uma tabela com segurança no nível da coluna

Você precisa do papel de Leitor de controle refinado ou de leitor mascarado em diferentes níveis, como organização, pasta, projeto e tag de política. O papel Leitor de Controle Refinado concede acesso a dados brutos, enquanto o papel Leitor Mascarado concede acesso a dados mascarados. Use o Solucionador de problemas de políticas do IAM para verificar essa permissão no nível do projeto.

Defini o controle de acesso refinado na taxonomia de tag de política, mas os usuários veem dados protegidos

Para resolver esse problema, confirme os seguintes detalhes:

  • Na página Taxonomias de tags de política da Central de segurança do BigQuery, confirme se o botão Aplicar controle de acesso está na posição Ativado.

  • Verifique se as consultas não estão usando resultados de consulta armazenados em cache. Se você usar a ferramenta de linha de comando bq para testar suas consultas, use a sinalização --nouse_cache para desativar o cache de consulta. Exemplo:

    bq query --nouse_cache --use_legacy_sql=false "SELECT * EXCEPT (customer_pii) FROM my_table;"

Considerações sobre a migração de projetos

As tags de política e as taxonomias ficam em uma organização Google Cloud específica e não são associadas novamente de forma automática quando um projeto é migrado para uma nova organização. Se você migrar um projeto que usa tags de política para controle de acesso no nível da coluna para uma organização diferente, os seguintes problemas vão ocorrer:

  • As tags de política não podem mais ser gerenciadas no console do Google Cloud no projeto migrado.
  • Não é possível aplicar essas tags de política a novas colunas no projeto migrado.
  • Os controles de acesso no nível da coluna podem parecer ainda estar em vigor, mas o link para a taxonomia de origem na organização original está corrompido para fins de gerenciamento.

Para resolver esse problema, é necessária uma intervenção manual do suporte do Google Cloud para associar novamente a taxonomia à nova organização. Se você migrou um projeto com tags de política e encontrou esses problemas, entre em contato com o Cloud Customer Care.

Resolver problemas de chaves de criptografia gerenciadas pelo cliente

A lista a seguir descreve erros comuns e resoluções recomendadas ao usar chaves de criptografia gerenciadas pelo cliente (CMEK) com o Cloud Key Management Service:

Erro: Please grant Cloud KMS CryptoKey Encrypter/Decrypter role
Resolução: a conta de serviço do BigQuery associada ao projeto não tem permissão suficiente do IAM para operar na chave especificada do Cloud KMS. Para conceder a permissão do IAM necessária, siga as instruções na mensagem de erro ou em Conceder permissão de criptografia e descriptografia.
Erro: Existing table encryption settings don't match encryption settings specified in the request
Solução: esse erro pode ocorrer quando as configurações de criptografia da tabela de destino não correspondem às da sua solicitação. Para resolver esse problema, use a disposição de gravação TRUNCATE para substituir a tabela ou especifique uma tabela de destino diferente.
Erro: This region is not supported
Resolução: a região da chave do Cloud KMS não corresponde à região do conjunto de dados do BigQuery para a tabela de destino. Para resolver esse problema, selecione uma chave em uma região que corresponda ao seu conjunto de dados ou carregue dados em um conjunto de dados que corresponda à região da chave.
Erro: Your administrator requires that you specify an encryption key for queries in project PROJECT_ID.
Resolução: uma política da organização impediu a criação de um recurso ou a execução de uma consulta. Para saber mais sobre essa política, consulte Exigir CMEKs para todos os recursos.
Erro: Your administrator prevents using KMS keys from project KMS_PROJECT_ID to protect resources in project PROJECT_ID.
Resolução: uma política da organização impediu a criação de um recurso ou a execução de uma consulta. Para saber mais sobre essa política, consulte Restringir chaves do Cloud KMS para um projeto do BigQuery.

A seguir