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 resolver problemas 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, examine a saída da ferramenta de linha de comando bq, a resposta da API ou o BigQuery no console do Cloud de Confiance .

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 Cloud de Confiance .

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

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

Em alguns casos, é possível solicitar as 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 Cloud de Confiance , 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" AND
logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access" 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 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 Cloud de Confiance , 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. Você precisará 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 Cloud de Confiance , na página Papéis, é possível filtrar a lista por Tipo:personalizado para ver apenas 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 permissões e papéis 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 saber como conceder um papel do IAM a um recurso do BigQuery, consulte Controlar o acesso a recursos com o IAM.

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 Cloud de Confiance , 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 de erro 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 Cloud de Confiance by S3NSe 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 Cloud de Confiance , 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 doCloud de Confiance 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 Cloud de Confiance by S3NS solicitou explicitamente que o Cloud de Confiance by S3NS aplique uma configuração de bloqueio estrita para que o projeto substitua 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 Cloud de Confiance by S3NS solicitaram que uma configuração organizacional específica e rigorosa fosse aplicada ao seu 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 restringir 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 Cloud de Confiance by S3NS 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 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 seu 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 doCloud de Confiance . 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 Cloud de Confiance by S3NS específica e não são reassociadas automaticamente 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 Cloud de Confiance 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 Cloud de Confiance 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 do Cloud KMS especificada. Para conceder a permissão do IAM necessária, siga as instruções na mensagem de erro ou em Conceder permissões 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