Risolvi i problemi di controllo dell'accesso

Questo documento mostra come risolvere i problemi di sicurezza relativi alle autorizzazioni di Identity and Access Management (IAM), controllo dell'accesso a livello di colonna e alle chiavi di crittografia gestite dal cliente (CMEK) in BigQuery. I problemi relativi alle autorizzazioni IAM in genere generano errori Access Denied come i seguenti:

  • 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 la risoluzione dei problemi 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 Cloud de Confiance .

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

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 Cloud de Confiance , 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" 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

    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 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, crea una query di analisi, specifica un ambito per l'analisi, quindi esegui la query.

  1. Nella console Cloud de Confiance , 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 un 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 Cloud de Confiance , 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 autorizzazioni 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.

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 Cloud de Confiance , 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ù, vedi 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 Cloud de Confiance by S3NS Esplora log per 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 identificata, 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 Cloud de Confiance , 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 consoleCloud de Confiance 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 i 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 disattiva 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 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 Cloud de Confiance by S3NS ha richiesto esplicitamente che Cloud de Confiance by S3NSapplichi 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 Cloud de Confiance by S3NS 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 viene visualizzato 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'organizzazione Cloud de Confiance by S3NS per rivedere la policy dell'organizzazione a livello di cartella o organizzazione. Per maggiori dettagli, consulta la sezione sulla strutturazione e definizione delle località delle risorse.

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 consoleCloud de Confiance , 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 in posizione 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 Cloud de Confiance by S3NS 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 Cloud de Confiance 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 Cloud de Confiance 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 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 decriptazione.
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