Risolvi i problemi di controllo dell'accesso

Utilizza questo documento per risolvere i problemi di sicurezza e autorizzazione di BigQuery, tra cui le autorizzazioni di Identity and Access Management (IAM), controllo dell'accesso a livello di colonna, le chiavi di crittografia gestite dal cliente (CMEK) e le violazioni delle policy. Gli errori di controllo dell'accesso in genere generano errori Access Denied o 403 Forbidden quando le entità eseguono job o accedono alle risorse.

Errori comuni di accesso negato

Di seguito sono riportati alcuni esempi di errori comuni di accesso negato:

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

Prima di iniziare

Raccogli informazioni sul problema

Il primo passaggio per risolvere un problema di accesso alle risorse consiste nel determinare l'autorizzazione mancante, l'entità IAM a cui è stato negato l'accesso e la risorsa a cui l'entità stava tentando di accedere.

Ottieni informazioni dalla cronologia degli errori o dei job

Per ottenere informazioni sull'entità, sulla risorsa e sulle autorizzazioni, esamina l'output dello strumento a riga di comando bq, la risposta dell'API o BigQuery nella console Google Cloud .

Ad esempio, se tenti di eseguire una query con autorizzazioni insufficienti, viene visualizzato un errore simile al seguente nella scheda Informazioni job nella sezione Risultati delle query della console Google Cloud .

Un errore di accesso negato nella scheda Informazioni job della sezione Risultati delle query.

Esamina l'errore per determinare l'entità, la risorsa e le autorizzazioni.

In alcuni casi, potresti essere in grado di richiedere le autorizzazioni mancanti direttamente dal messaggio di errore. Per saperne di più, consulta Messaggi di errore di autorizzazione nella documentazione di IAM.

Ottieni informazioni da Cloud Audit Logs

Se il messaggio di errore è generico, mancano informazioni o l'azione non è riuscita in un processo in background, utilizza Esplora log di Cloud Audit Logs per ottenere informazioni sull'errore.

  1. Nella console Google Cloud , vai alla pagina Esplora log.

    Vai a Esplora log

    In alternativa, dal menu di navigazione, scegli Monitoring > Esplora log.

  2. In Esplora log, per l'ambito dei log, scegli Log di progetto.

  3. Nella finestra della query, inserisci la seguente query per ottenere gli errori relativi alle autorizzazioni dai log di accesso ai dati di 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)

    Sostituisci PROJECT_ID con l'ID progetto.

  4. Nei risultati della query, espandi la voce di log corrispondente all'operazione non riuscita.

  5. Nella sezione protoPayload, espandi l'array authorizationInfo, quindi espandi ogni nodo nell'array authorizationInfo.

    L'array authorizationInfo mostra ogni controllo delle autorizzazioni eseguito durante la chiamata API.

  6. Per visualizzare la causa dell'errore, cerca la voce granted: false. La voce granted: false mostra le seguenti informazioni:

    • permission: la stringa di autorizzazione IAM che è stata controllata. Ad esempio, bigquery.tables.getData.
    • resource: il nome completo della risorsa a cui l'entità ha tentato di accedere. Ad esempio, projects/myproject/datasets/mydataset/tables/mytable.
    • principalEmail (se disponibile): l'entità che ha tentato l'azione, a cui viene fatto riferimento in protoPayload.authenticationInfo.

    La sezione authorizationInfo del protoPayload che mostra l'autorizzazione, la risorsa e l'indirizzo email dell'entità.

Utilizza Policy Analyzer per le policy di autorizzazione

Policy Analyzer per le policy di autorizzazione ti consente di scoprire quali entità IAM hanno un determinato accesso a determinate risorse BigQuery in base alle tue policy di autorizzazione IAM.

Dopo aver raccolto informazioni sull'errore di autorizzazione, puoi utilizzare Policy Analyzer per capire perché l'entità non dispone dell'accesso richiesto. Questo strumento analizza tutte le policy pertinenti, le iscrizioni a Google Gruppi e l'ereditarietà dalle risorse principali, come un progetto, una cartella e la tua organizzazione.

Per utilizzare Policy Analyzer per le policy di autorizzazione, devi creare una query di analisi, specificare un ambito per l'analisi ed eseguire la query.

  1. Nella console Google Cloud , vai alla pagina Policy Analyzer.

    Vai a Policy Analyzer

    In alternativa, dal menu di navigazione, scegli IAM e amministrazione > Policy Analyzer.

  2. Fai clic su Crea query personalizzata.

  3. Nella pagina Configura la query, inserisci le informazioni raccolte in precedenza:

    1. Nella sezione Seleziona l'ambito, nel campo Seleziona l'ambito della query, verifica che venga visualizzato il progetto corrente o fai clic su Sfoglia per scegliere un'altra risorsa.

    2. Nella sezione Imposta i parametri di query, per Parametro 1, scegli Entità e nel campo Entità inserisci l'indirizzo email dell'utente, del gruppo o del account di servizio.

    3. Fai clic su Aggiungi parametro.

    4. Per Parametro 2, scegli Autorizzazione e nel campo Autorizzazione, fai clic su Seleziona, scegli l'autorizzazione BigQuery e poi fai clic su Aggiungi. Ad esempio, seleziona bigquery.tables.getData.

    5. Fai clic su Aggiungi parametro.

    6. Per Parametro 3, scegli Risorsa e, nel campo Risorsa, inserisci il nome completo della risorsa. Il nome della risorsa deve includere il prefisso del servizio, come nei seguenti esempi:

      • Progetto BigQuery: //cloudresourcemanager.googleapis.com/projects/PROJECT_ID
      • Set di dati BigQuery: //bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET
      • Tabella BigQuery: //bigquery.googleapis.com/projects/PROJECT/datasets/DATASET/tables/TABLE

  4. Nel riquadro Query personalizzata, fai clic su Analizza > Esegui query.

  5. Esamina i risultati della query. Il risultato può essere uno dei seguenti:

    • Un elenco vuoto. Nessun risultato conferma che l'entità non dispone dell'autorizzazione richiesta. Dovrai concedere all'entità un ruolo che fornisca le autorizzazioni corrette.
    • Uno o più risultati. Se l'analizzatore trova una policy di autorizzazione, esiste una qualche forma di accesso. Fai clic su Visualizza associazione su ogni risultato per visualizzare i ruoli che forniscono l'accesso alla risorsa di cui l'entità è membro. L'associazione della policy mostra se l'accesso è concesso tramite l'appartenenza a un gruppo o l'ereditarietà oppure se l'accesso è negato da una condizione IAM o da una policy di negazione IAM.

Trova il ruolo IAM corretto che concede le autorizzazioni richieste

Dopo aver confermato che l'entità non dispone di accesso sufficiente, il passaggio successivo consiste nel trovare il ruolo IAM predefinito o personalizzato appropriato che concede le autorizzazioni richieste. Il ruolo scelto deve rispettare il principio del privilegio minimo.

Se la tua organizzazione utilizza ruoli personalizzati, puoi trovare il ruolo corretto elencando tutti i ruoli personalizzati creati nel progetto o nell'organizzazione. Ad esempio, nella console Google Cloud , nella pagina Ruoli, puoi filtrare l'elenco per Tipo:personalizzato per visualizzare solo i ruoli personalizzati.

Per trovare il ruolo IAM predefinito corretto, segui questi passaggi.

  1. Apri la sezione delle autorizzazioni di BigQuery della pagina Ruoli e autorizzazioni IAM di BigQuery.

  2. Nella barra di ricerca Inserisci un'autorizzazione, inserisci l'autorizzazione recuperata dal messaggio di errore, dalla cronologia dei job o dagli audit log. Ad esempio, bigquery.tables.getData.

    I risultati di ricerca mostrano tutti i ruoli BigQuery predefiniti che concedono l'autorizzazione.

  3. Applica il principio del privilegio minimo: nell'elenco dei ruoli, scegli il ruolo meno permissivo che concede le autorizzazioni richieste. Ad esempio, se hai cercato bigquery.tables.getData per concedere la possibilità di eseguire query sui dati della tabella, Visualizzatore dati BigQuery è il ruolo con meno privilegi che concede questa autorizzazione.

  4. Concedi all'entità il ruolo appropriato. Per informazioni su come concedere un ruolo IAM a una risorsa BigQuery, consulta Controlla l'accesso alle risorse con IAM.

Risolvi i problemi più comuni relativi all'accesso negato

Quando un'operazione non va a buon fine con 403 accessDenied (Access Denied: RESOURCE_TYPE RESOURCE_ID: DETAILS), controlla i seguenti scenari comuni oltre ai passaggi IAM generali precedenti:

  • Risorsa inesistente o mancata corrispondenza della località (or perhaps it does not exist). Quando un messaggio di errore termina con or perhaps it does not exist, BigQuery maschera l'esistenza della tabella, della vista o della routine perché l'entità non dispone delle autorizzazioni per i metadati del set di dati o del progetto (bigquery.tables.get o bigquery.datasets.get). Verifica che l'ID progetto, l'ID set di dati e il nome della tabella siano scritti correttamente e verifica che la query venga eseguita nella stessa località del set di dati.

  • Viste e routine autorizzate. Quando un utente esegue una query su una vista autorizzata o una routine autorizzata, deve disporre dell'autorizzazione per eseguire query sulla vista o sulla routine e la vista o la routine stessa deve essere autorizzata nell'elenco di controllo dell'accesso (ACL) del set di dati di origine. Se la query non va a buon fine con Access Denied sulla tabella di base sottostante, aggiungi la vista o la routine (o l'intero set di dati come set di dati autorizzato) all'elenco per gli accessi del set di dati di origine. Se una vista esegue una query su un'altra vista, ogni vista della catena deve essere autorizzata sul set di dati da cui legge.

    Se una vista o un set di dati autorizzati sono stati eliminati ed è stata creata un'altra vista o un altro set di dati con lo stesso nome, le query possono non riuscire con Access Denied. Questo errore può verificarsi anche se il nome appare ancora nell'elenco per gli accessi autorizzati del set di dati di origine, dove le voci eliminate possono rimanere fino a 24 ore. Controlla gli audit log di Cloud per verificare se una vista autorizzata o un set di dati autorizzato nella catena è stato eliminato e sostituito dall'ultima esecuzione della query. Per ripristinare l'accesso, rimuovi prima la voce esistente dall'elenco per gli accessi autorizzati del set di dati di origine, quindi aggiungi di nuovo la nuova vista o il nuovo set di dati. L'aggiunta della nuova visualizzazione prima della rimozione della voce precedente può non riuscire e generare un errore Duplicate authorized views.

    Per modificare una vista senza interrompere l'autorizzazione, aggiorna la query SQL della vista anziché eliminarla e ricrearla. Tuttavia, se modifichi una routine autorizzata con un'istruzione CREATE OR REPLACE o il metodo routines.update, devi autorizzarla nuovamente.

  • Controlli di servizio VPC. Se la tua organizzazione utilizza i Controlli di servizio VPC, le richieste che superano il confine di un perimetro di servizio non vanno a buon fine con 403 accessDenied o policyViolation. Cerca in Cloud Audit Logs intorno al momento dell'errore il valore vpcServiceControlsUniqueIdentifier del messaggio di errore e utilizza lo strumento di analisi delle violazioni per ispezionare le regole in entrata e in uscita. Per la query di Esplora log da utilizzare, consulta La richiesta è vietata dalla policy dell'organizzazione.

  • Ruoli di base (roles/owner, roles/editor, roles/viewer). I ruoli di base del progetto non includono le autorizzazioni a livello di organizzazione richieste per le visualizzazioni come INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE_BY_ORGANIZATION o autorizzazioni specializzate come bigquery.rowAccessPolicies.overrideTimeTravelRestrictions, necessarie per accedere ai dati storici di una tabella che ha o aveva policy di accesso a livello di riga (consulta Spostamento cronologico e accesso a livello di riga). Concedi ruoli IAM BigQuery predefiniti anziché fare affidamento sui ruoli di base.

  • Sovrascritture temporanee delle policy IAM (SetIamPolicy). Se le autorizzazioni funzionano in modo intermittente e poi non funzionano, cerca protoPayload.methodName=~"SetIamPolicy" negli audit log delle attività di amministrazione per verificare se uno script automatico o una pipeline di infrastructure as code sta sovrascrivendo le associazioni delle policy esistenti anziché unirle.

  • Fonti di dati esterne (Google Drive, Cloud Storage, BigLake):

    • Google Drive (Permission denied while getting Drive credentials). Concedi all'utente o al account di servizio l'accesso in visualizzazione al file di Google Drive o al foglio Google, assicurati che il chiamante fornisca l'ambito OAuth https://www.googleapis.com/auth/drive o aggiorna le credenziali delle query pianificate.
    • Cloud Storage e tabelle BigLake. Concedi roles/storage.objectViewer sul bucket Cloud Storage all'utente (per le tabelle esterne standard) o al service account di connessione BigLake (per le tabelle BigLake).

  • Chiavi di crittografia gestite dal cliente (CMEK). Se la query fa riferimento a una tabella protetta da CMEK, assicurati che la chiave Cloud KMS corrispondente esista e sia abilitata. Se un job di query o di caricamento non riesce con Cloud KMS Error: Permission 'cloudkms.cryptoKeyVersions.useToEncrypt' denied (o useToDecrypt), concedi all'agente di servizio di crittografia BigQuery (bq-PROJECT_NUMBER@bigquery-encryption.) il ruolo roles/cloudkms.cryptoKeyEncrypterDecrypter sulla chiave Cloud Key Management Service. Vedi Concedi l'autorizzazione di crittografia e decriptazione. Per altri errori CMEK, consulta Risolvi i problemi relativi alle chiavi di crittografia gestite dal cliente.

  • Simulazione dell'identità dei service account. Se una richiesta che utilizza la simulazione dell'identità dei account di servizio non va a buon fine con Permission 'iam.serviceAccounts.getAccessToken' denied, concedi all'entità chiamante roles/iam.serviceAccountTokenCreator sul account di servizio di destinazione.

  • Sicurezza a livello di colonna (tag di policy) e sicurezza a livello di riga. Se una query o un'istruzione DML non va a buon fine con Requires fineGrainedGet permission on the read columns o User does not have permission to access data protected by policy tag, concedi all'entità il ruolo Lettore granulare (roles/datacatalog.categoryFineGrainedReader) di Data Catalog sul tag di criteri o escludi le colonne protette dall'elenco SELECT. Consulta Autorizzazioni di controllo dell'accesso a livello di colonna insufficienti. Se la tabella utilizza la sicurezza a livello di riga, esamina le policy di accesso a livello di riga attive nella console Google Cloud o eseguendo bq ls --row_access_policies. Consulta Elenca le policy di accesso a livello di riga della tabella.

  • Ritardi di propagazione di IAM e dei metadati. I ruoli IAM appena concessi e gli aggiornamenti degli ACL dei set di dati sono a coerenza finale e in genere richiedono alcuni minuti per essere propagati nelle cache. Se un'autorizzazione è stata appena concessa, attendi qualche minuto e riprova a inviare la richiesta.

Termini di servizio di BigQuery non accettati

Stringa di errore: BigQuery Terms of Service have not been accepted

Questo errore HTTP 403 Forbidden (reason: termsOfServiceNotAccepted) si verifica quando i Termini di servizio di BigQuery non sono stati accettati. L'errore non è causato da autorizzazioni IAM mancanti. Può essere restituito per richieste come la creazione di un set di dati o il caricamento di dati.

Per risolvere il problema, segui questi passaggi:

  1. Nella console Google Cloud , vai alla pagina BigQuery.

    Vai a BigQuery

  2. Se viene visualizzata la pagina di benvenuto, seleziona il tuo paese, seleziona la casella di controllo Termini di servizio e poi fai clic su Accetta e continua. Per saperne di più, consulta Attiva la sandbox di BigQuery.

Dopo aver accettato i Termini di servizio, riprova a inviare la richiesta.

Risolvi gli errori di violazione delle norme

Quando ricevi un errore HTTP 403 PERMISSION_DENIED in BigQuery con il motivo dell'errore policyViolation, significa che si è verificato un errore causato da policy dell'organizzazione, perimetri di dati o Controlli di servizio VPC.

Le sezioni seguenti descrivono i messaggi di errore più comuni associati a questo motivo di errore, le relative cause e come risolverli.

La richiesta è vietata dalla policy dell'organizzazione

Stringa di errore: VPC Service Controls: Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: VPC_SERVICE_CONTROLS_UNIQUE_IDENTIFIER

Diagnosi

La tua richiesta proviene da un indirizzo di rete o da un client che si trova al di fuori del perimetro dei Controlli di servizio VPC designato oppure la richiesta ha violato le regole in entrata e in uscita definite per il tuo workspace. Questo accade spesso quando la query si estende su più progetti. Ad esempio, il progetto di fatturazione delle query si trova al di fuori del perimetro sicuro del progetto di dati.

Risoluzione

  1. Trova l'ID univoco. Recupera il vpcServiceControlsUniqueIdentifier incluso nel messaggio di errore. Utilizza questo ID per filtrare Google CloudEsplora log in modo da trovare il log dei Controlli di servizio VPC corrispondente con i dettagli del motivo:

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

    Cerca il valore violationReason in protoPayload.metadata.violationReason. Una volta identificati, studia i dettagli aggiuntivi nella voce di log e segui la guida alla risoluzione dei problemi relativi ai Controlli di servizio VPC esistente. Inoltre, valuta la possibilità di utilizzare lo strumento di analisi delle violazioni.

  2. Correggi la fatturazione tra progetti. Per le query tra progetti, assicurati che il progetto di fatturazione che esegue la query si trovi nello stesso perimetro dei dati sottoposti a query all'interno del perimetro. Se necessario, specifica manualmente un progetto di fatturazione conforme utilizzando il selettore di progetti della console Google Cloud , il flag --project_id nello strumento a riga di comando bq o la tua richiesta API o della libreria client.

  3. Verifica i livelli di accesso. Assicurati che la rete client, l'IP o l'account utente siano autorizzati utilizzando Gestore contesto accesso. La consoleGoogle Cloud richiede regole in entrata configurate specificamente per consentire l'accesso degli utenti agli ambienti protetti.

L'esportazione su Google Drive è bloccata per i progetti con Controlli di servizio VPC abilitati

Stringa di errore: Export to Google Drive is blocked for projects with VPC-SC enabled

Diagnosi

Google Drive non supporta i Controlli di servizio VPC. Poiché Google Drive non può applicare il perimetro di sicurezza, BigQuery disabilita automaticamente l'esportazione degli estratti dell'API su Google Drive per qualsiasi richiesta proveniente da un confine dei Controlli di servizio VPC per impedire l'esfiltrazione di dati.

Risoluzione

Anziché esportare direttamente su Google Drive, estrai i risultati delle query in un bucket Cloud Storage situato all'interno dello stesso perimetro dei Controlli di servizio VPC o salva i risultati come file locale.

Le tabelle esterne di Google Drive sono bloccate per i progetti con i Controlli di servizio VPC abilitati

Stringa di errore: Google Drive external tables are blocked for projects with VPC-SC enabled

Diagnosi

Per impostazione predefinita, i Controlli di servizio VPC non bloccano le query sulle tabelle esterne di Google Drive (come i fogli connessi). Tuttavia, questo errore viene visualizzato perché la tua organizzazione Google Cloud ha richiesto esplicitamente che Google Cloudapplichi una configurazione di blocco rigorosa per il tuo progetto per eseguire l'override del comportamento permissivo predefinito, impedendo qualsiasi query in entrata ai dati di Google Drive dall'interno di un perimetro dei Controlli di servizio VPC.

Risoluzione

Importa i dati dal file di Fogli Google o Google Drive direttamente in una tabella BigQuery standard all'interno del perimetro dei Controlli di servizio VPC, anziché eseguire query in modo dinamico come tabella federata esterna. In alternativa, contatta l'amministratore Cloud interno per discutere dei limiti di esportazione dei dati della tua organizzazione.

L'esportazione su Google Drive è bloccata per il tuo progetto

Stringa di errore: Export to Google Drive is blocked for your project.

Diagnosi

Anche senza un perimetro dei Controlli di servizio VPC, gli amministratori di Google Cloud hanno richiesto l'applicazione di una configurazione organizzativa specifica e rigorosa al tuo progetto, negando tutte le funzionalità di estrazione dei dati a Google Drive.

Risoluzione

Scegli una destinazione di estrazione alternativa, ad esempio un bucket Cloud Storage o un file locale, oppure contatta l'amministratore Cloud interno per discutere dei limiti di esportazione dei dati della tua organizzazione.

La località viola il vincolo delle policy dell'organizzazione

Stringa di errore: LOCATION violates constraint CONSTRAINT_NAME on the resource projects/PROJECT_ID o LOCATION violates constraint CONSTRAINT_NAME on the resource projects/PROJECT_ID/datasets/DATASET_ID

Diagnosi

L'amministratore di Cloud ha configurato un vincolo della policy dell'organizzazione per limitare esattamente dove è possibile creare o analizzare le risorse. Questo errore si verifica comunemente quando:

  • Creazione di un set di dati in una regione geografica non autorizzata (ad esempio, limitata da constraints/gcp.resourceLocations).
  • Tentativo di utilizzare BigQuery Omni su cloud esterni quando non è consentito (ad esempio, bloccato da constraints/bigquery.disableBQOmniAWS o constraints/bigquery.disableBQOmniAzure).

Risoluzione

  1. Controlla l'esatto CONSTRAINT_NAME fornito nel messaggio di errore per capire quale azione è stata bloccata.
  2. Seleziona una regione diversa e non bloccata per i tuoi dati o collabora con l'amministratore dell'organizzazioneGoogle Cloud per esaminare la policy dell'organizzazione a livello di cartella o organizzazione. Per maggiori dettagli, consulta Strutturazione e definizione delle località delle risorse.

Risolvi gli errori di mancata autenticazione

Quando ricevi un errore HTTP 401 Unauthorized (gRPC UNAUTHENTICATED) in BigQuery con il motivo dell'errore unauthenticated, la richiesta non dispone di credenziali di autenticazione valide, il token di accesso OAuth 2.0 è scaduto o il chiamante non può autenticarsi come l'identità specificata.

Le sezioni seguenti descrivono gli scenari unauthenticated più comuni, le relative cause e come risolverli.

Credenziali non valide o scadute

Stringhe di errore:

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

Diagnosi

Il token di accesso, la chiave account di servizio o le Credenziali predefinite dell'applicazione (ADC) forniti con la richiesta sono scaduti, revocati o non dispongono degli ambiti OAuth 2.0 richiesti. Questo errore si verifica anche quando la richiesta viene firmata con un orologio di sistema che si è discostato dall'ora del protocollo NTP (Network Time Protocol).

Risoluzione

  • Aggiorna le tue credenziali. Se l'autenticazione viene eseguita da un ambiente di sviluppo locale, esegui gcloud auth application-default login (per ADC) o gcloud auth login per ottenere un nuovo token.
  • Verifica le chiavi dei account di servizio e gli ambiti OAuth. Se la tua applicazione utilizza GOOGLE_APPLICATION_CREDENTIALS, verifica che la variabile punti a un file di chiave JSON valido e non revocato, che l'account di servizio sia abilitato nella consoleGoogle Cloud e che la credenziale includa l'ambito https://www.googleapis.com/auth/bigquery o https://www.googleapis.com/auth/cloud-platform richiesto.
  • Utilizza le librerie client attuali e sincronizza gli orologi di sistema. Aggiorna la libreria client di BigQuery o il driver ODBC o JDBC all'ultima versione in modo che gli aggiornamenti dei token OAuth 2.0 e le credenziali federate vengano gestiti automaticamente. Assicurati inoltre che l'orologio di sistema della macchina host sia sincronizzato utilizzando NTP.

Credenziali dell'utente finale o autorizzazione di simulazione dell'identità dei account di servizio mancanti

Stringhe di errore:

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

Diagnosi

Il job o la query continua sono configurati per l'esecuzione come account di servizio personalizzato per cui il chiamante non dispone dell'autorizzazione per agire oppure la tabella o la policy di sicurezza di destinazione richiede le credenziali dell'utente finale (EUC) in modo che BigQuery possa valutare l'accesso rispetto a un'identità utente interattiva.

Risoluzione

  • Concedi le autorizzazioni di simulazione dell'identità dei account di servizio account. Quando esegui una query continua o un job configurato con un account di servizio personalizzato, concedi al chiamante il ruolo Service Account User (roles/iam.serviceAccountUser, che include l'autorizzazione iam.serviceAccounts.actAs) su quel account di servizio. Quando emuli un service account o scambi credenziali federate con un token di breve durata, concedi al chiamante il ruolo Creatore token account di servizio (roles/iam.serviceAccountTokenCreator) sul service account di destinazione.
  • Autenticati con le credenziali dell'utente finale. Quando la risorsa di destinazione richiede le credenziali dell'utente finale, autentica la richiesta utilizzando le credenziali OAuth 2.0 di un utente interattivo (ad esempio eseguendo gcloud auth application-default login o configurando OAuth utente nel tuo strumento di BI) anziché le credenziali di un account di servizio autonomo.
  • Verifica le regole in entrata e in uscita dei Controlli di servizio VPC. Se la richiesta attraversa un confine dei Controlli di servizio VPC, verifica che le regole in entrata e in uscita del perimetro consentano l'identità del chiamante e la risorsa di destinazione.

Account limitato, sospeso o eliminato

Stringhe di errore:

  • The account was restricted due to REASON
  • Account deleted

Diagnosi

L'Account Google o l'account Google Workspace che invia la richiesta è stato sospeso, disattivato, limitato o eliminato da un amministratore o da una policy di sicurezza dell'account.

Risoluzione

Contatta l'amministratore di Google Workspace o Cloud Identity per esaminare lo stato dell'account nella Console di amministrazione Google e ripristinare o annullare la sospensione dell'account utente oppure aggiornare il workload per l'autenticazione con un account di servizio attivo.

Risolvi i problemi relativi controllo dell'accesso a livello di colonna

Le sezioni seguenti spiegano come risolvere i problemi relativi al controllo degli accessi a livello di colonna e ai tag di policy di Data Catalog.

Non riesco a visualizzare i ruoli di Data Catalog

Se non riesci a visualizzare ruoli come Lettore granulare di Data Catalog, è possibile che tu non abbia abilitato l'API Data Catalog nel tuo progetto. Per scoprire come abilitare l'API Data Catalog, consulta Prima di iniziare. I ruoli Data Catalog vengono visualizzati alcuni minuti dopo l'abilitazione dell'API Data Catalog.

Non riesco a visualizzare la pagina Tassonomie

Per visualizzare la pagina Tassonomie di tag di policy nella consoleGoogle Cloud , devi disporre di autorizzazioni aggiuntive. Ad esempio, il ruolo Amministratore tag di policy di Data Catalog ha accesso alla pagina Tassonomie.

Ho applicato i tag di policy, ma non sembra funzionare

Se continui a ricevere risultati delle query per un account che non dovrebbe avere accesso, è possibile che l'account riceva risultati memorizzati nella cache. In particolare, se in precedenza hai eseguito la query con successo e poi hai applicato i tag di policy, potresti ottenere risultati dalla cache dei risultati delle query. Per impostazione predefinita, i risultati delle query vengono memorizzati nella cache per 24 ore. La query non va a buon fine immediatamente se disattivi la cache dei risultati. Per maggiori dettagli sulla memorizzazione nella cache, consulta Impatto del controllo dell'accesso a livello di colonna.

In genere, la propagazione degli aggiornamenti IAM richiede circa 30 secondi. La propagazione delle modifiche alla gerarchia dei tag di criteri può richiedere fino a 30 minuti.

Non ho l'autorizzazione per leggere da una tabella con sicurezza a livello di colonna

Devi disporre del ruolo Fine-Grained Reader o del ruolo Masked Reader a diversi livelli, ad esempio organizzazione, cartella, progetto e tag di criteri. Il ruolo Lettore granulare concede l'accesso ai dati non elaborati, mentre il ruolo Lettore mascherato concede l'accesso ai dati mascherati. Puoi utilizzare lo strumento per la risoluzione dei problemi relativi alle policy IAM per verificare questa autorizzazione a livello di progetto.

Ho impostato il controllo granulare dell'accesso nella tassonomia dei tag di criteri, ma gli utenti vedono i dati protetti

Per risolvere il problema, verifica i seguenti dettagli:

  • Nella pagina Tassonomie dei tag di policy del Centro sicurezza di BigQuery, verifica che l'opzione Applica il controllo dell'accesso sia impostata su On.

  • Assicurati che le query non utilizzino i risultati delle query memorizzati nella cache. Se utilizzi lo strumento a riga di comando bq per testare le query, utilizza il flag --nouse_cache per disabilitare la cache delle query. Ad esempio:

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

Considerazioni sulla migrazione dei progetti

I tag di policy e le tassonomie si trovano all'interno di un'organizzazione Google Cloud specifica e non vengono riassociati automaticamente quando viene eseguita la migrazione di un progetto a una nuova organizzazione. Se esegui la migrazione di un progetto che utilizza tag di policy per controllo dell'accesso a livello di colonna a un'altra organizzazione, si verificano i seguenti problemi:

  • I tag di policy non sono più gestibili nella console Google Cloud all'interno del progetto di cui è stata eseguita la migrazione.
  • Non puoi applicare questi tag di policy alle nuove colonne del progetto di cui è stata eseguita la migrazione.
  • I controlli di accesso a livello di colonna esistenti potrebbero sembrare ancora attivi, ma il link alla tassonomia di origine nell'organizzazione originale è interrotto per scopi di gestione.

Per risolvere questo problema, è necessario l'intervento manuale dell'assistenza Google Cloud per riassociare la tassonomia alla nuova organizzazione. Se hai eseguito la migrazione di un progetto con tag di policy e riscontri questi problemi, contatta l'assistenza clienti Google Cloud.

Risolvi i problemi relativi ai tag di governance dei dati

Le sezioni seguenti descrivono come risolvere i problemi comuni durante il controllo dell'accesso alle colonne con i tag di governance dei dati.

Nomi dei tag formattati in modo errato

Quando crei i tag, definisci un nome breve (ad esempio ssn). Tuttavia, quando colleghi i tag alle colonne dello schema o li utilizzi nelle condizioni, la chiave tag deve utilizzare il formato con spazio dei nomi (PROJECT_ID/TAG_KEY o ORGANIZATION_ID/TAG_KEY), mentre il valore tag utilizza comunque il nome breve. Se fornisci solo il nome breve della chiave tag, viene generato un errore Invalid tagKey o Invalid tagValue.

Applicazione delle policy tra progetti

Per impostazione predefinita, vengono valutate solo le policy dei dati del progetto della tabella. Le policy di altri progetti non vengono applicate, a meno che non sia configurato un progetto di policy dei dati predefinito a livello di organizzazione. Per saperne di più sulla configurazione e sulla valutazione delle policy tra progetti, consulta Configura un progetto di policy dei dati predefinito.

Risolvi i problemi relativi alle chiavi di crittografia gestite dal cliente

Il seguente elenco descrive gli errori comuni e le soluzioni consigliate quando utilizzi le chiavi di crittografia gestite dal cliente (CMEK) con Cloud Key Management Service:

Errore: Please grant Cloud KMS CryptoKey Encrypter/Decrypter role
Risoluzione: il account di servizio BigQuery associato al tuo progetto non dispone di autorizzazioni IAM sufficienti per operare sulla chiave Cloud KMS specificata. Per concedere l'autorizzazione IAM richiesta, segui le istruzioni nel messaggio di errore o in Concedi l'autorizzazione di crittografia e decrittografia.
Errore: Existing table encryption settings don't match encryption settings specified in the request
Risoluzione: questo errore può verificarsi quando la tabella di destinazione ha impostazioni di crittografia che non corrispondono a quelle della richiesta. Per risolvere questo problema, utilizza la disposizione di scrittura TRUNCATE per sostituire la tabella o specifica una tabella di destinazione diversa.
Errore: This region is not supported
Risoluzione: la regione della chiave Cloud KMS non corrisponde alla regione del set di dati BigQuery per la tabella di destinazione. Per risolvere il problema, seleziona una chiave in una regione che corrisponda al set di dati o carica i dati in un set di dati che corrisponda alla regione della chiave.
Errore: Your administrator requires that you specify an encryption key for queries in project PROJECT_ID.
Risoluzione: una policy dell'organizzazione ha impedito la creazione di una risorsa o l'esecuzione di una query. Per saperne di più su questa policy, consulta Richiedi CMEK per tutte le risorse.
Errore: Your administrator prevents using KMS keys from project KMS_PROJECT_ID to protect resources in project PROJECT_ID.
Risoluzione: una policy dell'organizzazione ha impedito la creazione di una risorsa o l'esecuzione di una query. Per saperne di più su questa policy, consulta Limita le chiavi Cloud KMS per un progetto BigQuery.

Passaggi successivi