Questa pagina è stata tradotta dall'API Cloud Translation.

Comprendi i criteri di autorizzazione

Puoi concedere l'accesso alle risorse di Google Cloud utilizzando i criteri di autorizzazione, noti anche come criteri IAM (Identity and Access Management), che sono allegati alle risorse. Puoi collegare un solo criterio di autorizzazione a ogni risorsa. Il criterio di autorizzazione controlla l'accesso alla risorsa stessa, nonché discendenti della risorsa che ereditano il criterio di autorizzazione.

Questa pagina mostra i criteri di autorizzazione in formato JSON. Puoi utilizzare anche Google Cloud CLI per recuperare i criteri di autorizzazione in formato YAML.

Struttura dei criteri

Un criterio di autorizzazione è una raccolta di associazioni di ruoli e metadati. Associazione di ruoli specifica quale accesso concedere a una risorsa. Associa, o vincola, una o più entità a un singolo ruolo IAM e a qualsiasi condizione specifica del contesto che modifichi le modalità e i tempi di autorizzazione del ruolo. I metadati includono informazioni aggiuntive sul criterio di autorizzazione, ad esempio etag e version per facilitare la gestione dei criteri.

Ogni associazione di ruoli può includere i seguenti campi:

Una o più entità, anch'esse noti come membri o identità. Esistono diversi tipi di entità, inclusi account utente, account di servizio, gruppi Google e domini. Per un per l'elenco completo dei tipi di entità supportati, consulta Entità identificatori.
Un role, ovvero una raccolta denominata autorizzazioni che forniscono la possibilità di eseguire azioni su Google Cloud Google Cloud.
Una condizione, che è una logica facoltativa che limita ulteriormente l'associazione del ruolo in base agli attributi ad esempio la sua origine o la risorsa di destinazione. Condizioni vengono generalmente utilizzati per controllare se l'accesso viene concesso in base al contesto per una richiesta.

Se un'associazione di ruoli contiene una condizione, si parla di associazione di ruoli condizionale.

Alcuni servizi Google Cloud non accettano condizioni nei criteri consentiti. Per un elenco di servizi e tipi di risorse che accettano condizioni, consulta Tipi di risorse che accettano associazioni di ruoli condizionali.

Le modifiche all'accesso di un'entità sono alla fine coerenti. Ciò significa che occorre del tempo per modificare l'accesso si propagano nel sistema. Per scoprire quanto tempo ci vuole, in media, per cambiare l'accesso a propagare le modifiche, consulta Propagazione delle modifiche di accesso.

Limiti per tutte le entità

Ogni criterio di autorizzazione può contenere fino a 1500 entità. Ai fini di questo limite, IAM conteggia tutte le occorrenze di ogni entità nelle associazioni dei ruoli del criterio di autorizzazione, nonché le entità esenti dall'audit logging di accesso ai dati dal criterio di autorizzazione. Non deduplica le entità che appaiono in più di un ruolo associazione. Ad esempio, se un criterio di autorizzazione contiene solo associazioni di ruoli per l'entità user:sample-user@example.com, e questa entità appare in 50 associazioni di ruoli, dopodiché puoi aggiungerne un'altra 1450 entità alle associazioni di ruolo nel criterio di autorizzazione.

Inoltre, ai fini di questo limite, ogni apparizione di un dominio o di un gruppo Google è conteggiata come una a entità singola, indipendentemente dal numero di singoli membri nel dominio o nel gruppo.

Se utilizzi le condizioni IAM o se concedi ruoli a molte entità con insolitamente identificatori lunghi, IAM potrebbe consentire meno entità nel criterio di autorizzazione.

Limiti per gruppi e domini

È possibile aggiungere fino a 250 entità in un criterio di autorizzazione gruppi Google, domini Cloud Identity o account Google Workspace.

Ai fini di questo limite, i domini Cloud Identity, gli account Google Workspace e i servizi vengono conteggiati come segue:

Per Google Gruppi, ogni gruppo univoco viene conteggiato una sola volta, indipendentemente dal numero di volte viene visualizzato nel criterio di autorizzazione. Questa modalità è diversa dalla modalità di conteggio dei gruppi per il limite. sul numero totale di entità in un criterio di autorizzazione; per quel limite, ogni aspetto per il calcolo del limite.
Per i domini Cloud Identity o gli account Google Workspace, IAM viene conteggiato tutti gli aspetti di ciascun dominio o account nelle associazioni di ruoli del criterio di autorizzazione. Non non deduplicare i domini o gli account visualizzati in più di un'associazione dei ruoli.

Ad esempio, se il criterio di autorizzazione contiene un solo gruppo, group:my-group@example.com, e il gruppo compare nel criterio di autorizzazione 10 volte, puoi aggiungerne altre 249 domini Cloud Identity, account Google Workspace o gruppi univoci prima di raggiungere limite.

In alternativa, se il criterio di autorizzazione contiene un solo dominio, domain:example.com e il dominio compare nel criterio di autorizzazione 10 volte, poi puoi aggiungerne un'altra 240 domini Cloud Identity, account Google Workspace o account prima di raggiungere il limite.

Metadati dei criteri

I metadati per un criterio di autorizzazione includono i seguenti campi:

Un campo etag, utilizzato per il controllo della concorrenza, che garantisce l'aggiornamento coerente dei criteri di autorizzazione. Per maggiori dettagli, vedi Utilizzo di etag in un criterio in questa pagina.
Un campo version che specifica la versione dello schema per un determinato criterio di autorizzazione. Per informazioni dettagliate, consulta la sezione Versioni delle norme in questa pagina.

Per organizzazioni, cartelle, progetti e account di fatturazione, il criterio di autorizzazione può contenere anche un campo auditConfig, che specifica i tipi di attività che generano audit log per ogni servizio. Per scoprire come configurare di questa parte di un criterio di autorizzazione, Configurazione degli audit log di accesso ai dati.

Utilizzo degli etag in un criterio

Quando più sistemi tentano di scrivere contemporaneamente nello stesso criterio di autorizzazione, c'è il rischio che questi sistemi sovrascrivano le modifiche apportate dall'altro. Questo rischio esiste perché i criteri di autorizzazione vengono aggiornati utilizzando il pattern di lettura, modifica e scrittura , che prevede più operazioni:

Lettura del criterio di autorizzazione esistente in corso...
Modifica del criterio di autorizzazione.
Scrivere l'intero criterio di autorizzazione

Se il sistema A legge un criterio di autorizzazione e il sistema B scrive immediatamente un di quel criterio di autorizzazione, il sistema A non sarà a conoscenza delle modifiche dal sistema B. Quando il sistema A scrive le proprie modifiche al criterio di autorizzazione, le modifiche del sistema B potrebbero andare perse.

Per evitare questo problema, Identity and Access Management (IAM) supporta la contemporaneità tramite l'uso di un campo etag nel criterio di autorizzazione. Ogni criterio di autorizzazione contiene un campo etag e il valore di questo campo cambia ogni volta che viene aggiornato un criterio di autorizzazione. Se un criterio di autorizzazione contiene un campo etag, ma non è presente di ruoli, il criterio di autorizzazione non concederà ruoli.

Il campo etag contiene un valore come BwUjMhCsNvY=. Quando aggiorni assicurati di includere il campo etag nel criterio di autorizzazione aggiornato. Se il criterio di autorizzazione è stato modificato dopo il recupero, il valore etag non corrisponderà e l'aggiornamento non andrà a buon fine. Per l'API REST, ricevi il messaggio HTTP codice di stato 409 Conflict e il corpo della risposta è simile al seguente:

{
  "error": {
    "code": 409,
    "message": "There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff.",
    "status": "ABORTED"
  }
}

Se viene visualizzato questo errore, riprova a eseguire l'intera serie di operazioni: leggi il messaggio di nuovo, modificarlo se necessario e scrivere il criterio di autorizzazione aggiornato. Tu dovrebbe eseguire nuovi tentativi automaticamente, con valori esponenziali il backoff, in tutti gli strumenti che usi per gestire i criteri di autorizzazione.

Esempio: criterio semplice

Considera il seguente criterio di autorizzazione che associa un'entità a un ruolo:

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Nell'esempio precedente, a jie@example.com viene concesso il Ruolo di base Proprietario senza alcuna condizione. Questo ruolo offre a jie@example.com accesso quasi illimitato.

Esempio: criterio con più associazioni di ruoli

Considera il seguente criterio di autorizzazione che contiene più di un'associazione dei ruoli. Ogni associazione di ruolo concede un ruolo diverso:

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:raha@example.com",
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Nell'esempio precedente, a Jie (jie@example.com) viene concessa l'autorizzazione Organizzazione Ruolo predefinito Amministratore (roles/resourcemanager.organizationAdmin) nella prima associazione del ruolo. Questo ruolo contiene le autorizzazioni per organizzazioni, cartelle e progetti con limitazioni operazioni aziendali. Nella seconda associazione del ruolo, sia Jie che Raha (raha@example.com) possono creare progetti mediante il ruolo Autore progetto (roles/resourcemanager.projectCreator). Insieme, queste associazioni di ruoli un accesso granulare sia a Jie che a Raha e a Jie viene concesso un accesso maggiore rispetto Raha.

Esempio: criterio con associazione condizionale del ruolo

Prendi in considerazione il seguente criterio di autorizzazione, che associa gli entità a un ruolo predefinito e utilizza un'espressione di condizione per limitare l'associazione del ruolo:

{
  "bindings": [
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression":
            "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

In questo esempio, il campo version è impostato su 3, perché il criterio di autorizzazione contiene un'espressione di condizione. L'associazione dei ruoli il criterio di autorizzazione è condizionale; concede il ruolo al gruppo Google prod-dev@example.com e l'account di servizio prod-dev-example@appspot.gserviceaccount.com, ma solo fino al 1° luglio 2022.

Per maggiori dettagli sulle funzionalità supportate da ogni versione dei criteri di autorizzazione, consulta Versioni dei criteri in questa pagina.

Esempio: criterio con associazioni di ruoli condizionali e incondizionali

Considera il seguente criterio di autorizzazione, che contiene sia condizioni associazioni di ruoli incondizionali per lo stesso ruolo:

{
  "bindings": [
    {
      "members": [
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
       ],
       "role": "roles/appengine.deployer"
    },
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
        "title": "Expires_July_1_2022",
        "description": "Expires on July 1, 2022",
        "expression":
          "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

In questo esempio, l'account di servizio serviceAccount:prod-dev-example@appspot.gserviceaccount.com è incluso in due associazioni di ruoli per lo stesso ruolo. La prima associazione di ruolo non ha un . La seconda associazione di ruolo ha una condizione che concede solo il ruolo fino al 1° luglio 2022.

In pratica, questo criterio di autorizzazione concede sempre il ruolo al service account. In IAM, le associazioni di ruoli condizionali non sostituiscono le associazioni di ruoli senza condizioni. Se un'entità è associata a un ruolo e l'associazione dei ruoli non hanno una condizione, l'entità ha sempre quel ruolo. L'aggiunta del parametro a un'associazione condizionale di ruoli per lo stesso ruolo non ha alcun effetto.

Al contrario, il gruppo Google group:prod-dev@example.com è incluso solo in l'associazione condizionale del ruolo. Di conseguenza, ha il ruolo solo prima del 1° luglio 2022.

Esempio: criterio che associa un ruolo a un'entità eliminata

Considera il seguente criterio di autorizzazione. Questo criterio di autorizzazione associa un ruolo a un utente donald@example.com, il cui account è stato eliminato. Di conseguenza, l'identificatore dell'utente ora ha un prefisso deleted::

{
  "bindings": [
    {
      "members": [
        "deleted:user:donald@example.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Se crei un nuovo utente denominato donald@example.com, il ruolo del criterio di autorizzazione le associazioni per l'utente eliminato non vengono applicate al nuovo utente. Questo comportamento impedisce ai nuovi utenti di ereditare i ruoli concessi agli utenti eliminati. Se vuoi concedere ruoli al nuovo utente, aggiungilo alle associazioni di ruoli del criterio di autorizzazione, come mostrato in Criteri con principali eliminati in questa pagina.

Inoltre, ora il nome dell'utente include il prefisso deleted: e il suffisso ?uid=numeric-id, dove numeric-id è l'ID numerico univoco dell'utente eliminato. Nel in questo esempio, invece di user:donald@example.com, il criterio di autorizzazione mostra identificatore deleted:user:donald@example.com?uid=123456789012345678901.

Gli account di servizio e i gruppi si comportano come gli utenti. Se elimini un gruppo o account di servizio, quindi visualizza un criterio di autorizzazione dell'entità, il nome dell'entità eliminata ha il prefisso deleted: e il suffisso ?uid=numeric-id.

Norme predefinite

Tutte le risorse che accettano i criteri di autorizzazione vengono create con i criteri di autorizzazione predefiniti. La maggior parte delle risorse I criteri di autorizzazione predefiniti sono vuoti. Tuttavia, la posizione di alcune risorse i criteri di autorizzazione predefiniti contengono automaticamente associazioni di ruoli. Ad esempio, quando crei un nuovo progetto, il criterio di autorizzazione per il progetto ha automaticamente un'associazione di ruolo che ti concede il ruolo Proprietario (roles/owner) per il progetto.

Queste associazioni di ruoli vengono create dal sistema, quindi l'utente non deve Autorizzazioni getIamPolicy o setIamPolicy per la risorsa per il ruolo associazioni da creare.

Per sapere se una risorsa viene creata con un criterio di autorizzazione, consulta la sezione documentazione.

Ereditarietà dei criteri e gerarchia delle risorse

Le risorse Google Cloud sono organizzate in modo gerarchico, nodo organizzazione è il nodo radice della gerarchia e, facoltativamente, le cartelle, quindi su progetti. La maggior parte delle altre risorse viene creata e gestita all'interno di un progetto. Ogni risorsa ha un solo elemento padre, tranne l'organizzazione. L'organizzazione, come nodo radice della gerarchia, non ha un elemento principale. Vedi la risorsa Argomento Gerarchia per ulteriori informazioni.

È importante considerare la gerarchia delle risorse quando si imposta un criterio di autorizzazione. Quando imposti un criterio di autorizzazione a un livello superiore nella gerarchia, ad esempio a livello di organizzazione, di cartella o di progetto, l'ambito di accesso concesso include il livello di risorsa a cui è associato questo criterio di autorizzazione di risorse di livello inferiore. Ad esempio, un criterio di autorizzazione impostato a livello di organizzazione si applica all'organizzazione e a tutte le risorse al suo interno. Analogamente, un criterio di autorizzazione impostato a livello di progetto si applica al progetto a tutte le risorse del progetto.

L'ereditarietà dei criteri è il termine che descrive in che modo si applicano i criteri di autorizzazione a a un livello inferiore nella gerarchia delle risorse. La norma effettiva è il termine che descrive in che modo tutti i criteri di autorizzazione padre nella gerarchia delle risorse vengono ereditati per una risorsa. L'unione di quanto segue:

Il criterio di autorizzazione impostato nella risorsa
I criteri di autorizzazione impostati su tutti i livelli delle risorse di discendenza della risorsa nel gerarchia

Ogni nuova associazione di ruoli (ereditata dalle risorse padre) che interessa il criterio di autorizzazione effettiva della risorsa viene valutato in modo indipendente. Un accesso specifico alla risorsa viene concessa se una delle associazioni di ruoli di livello superiore concedere l'accesso alla richiesta.

Se viene introdotta una nuova associazione dei ruoli a qualsiasi livello dell'autorizzazione ereditata di una risorsa l'ambito di concessione dell'accesso aumenta.

Esempio: ereditarietà dei criteri

Per comprendere l'ereditarietà dei criteri, considera uno scenario in cui concedi una Raha, due diversi ruoli IAM a due livelli diversi la gerarchia delle risorse.

Per concedere a Raha un ruolo a livello di organizzazione, imposta quanto segue: criteri per la tua organizzazione:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.objectViewer"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Questo criterio di autorizzazione concede a Raha il ruolo Visualizzatore oggetti Storage (roles/storage.objectViewer), che contiene le autorizzazioni get e list per progetti e oggetti Cloud Storage. Poiché hai impostato il criterio di autorizzazione organizzazione, Raha può usare queste autorizzazioni per tutti i progetti oggetti Cloud Storage nella tua organizzazione.

Per concedere a Raha un ruolo a livello di progetto, imposta quanto segue: criterio per il progetto myproject-123:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.objectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Questo criterio di autorizzazione concede a Raha il ruolo Creatore oggetti Storage (roles/storage.objectCreator), che consente di creare Cloud Storage di oggetti strutturati. Poiché hai impostato il criterio di autorizzazione su myproject-123, Raha può creare Solo oggetti Cloud Storage in myproject-123.

Ora che ci sono due associazioni di ruoli che concedono a Raha l'accesso alla destinazione Oggetti Cloud Storage in myproject-123, i seguenti criteri di autorizzazione applica:

Un criterio di autorizzazione a livello di organizzazione concede la possibilità di elencare e ottenere per tutti gli oggetti Cloud Storage in questa organizzazione.
Un criterio di autorizzazione a livello di progetto, per il progetto myproject-123, concede la possibilità di creare oggetti all'interno del progetto.

La tabella seguente riassume le norme vigenti di Raha:

Autorizzazioni concesse tramite "storage.objectViewer" ruolo a livello di organizzazione	Autorizzazioni concesse tramite "storage.objectCreator" ruolo in "myproject-123"	Ambito della concessione effettivo per Raha in "myproject-123"
resourcemanager.projects.get resourcemanager.projects.list storage.objects.get storage.objects.list	resourcemanager.projects.get resourcemanager.projects.list storage.objects.create	resourcemanager.projects.get resourcemanager.projects.list storage.objects.get storage.objects.list storage.objects.create

Versioni dei criteri

Nel tempo, IAM potrebbe aggiungere nuove funzionalità che aggiungono o modifica i campi nello schema del criterio di autorizzazione. Per evitare di danneggiare integrazioni che si basano sulla coerenza nella struttura dei criteri di autorizzazione, ad esempio vengono introdotte modifiche nelle nuove versioni dello schema dei criteri di autorizzazione.

Se è la prima volta che esegue l'integrazione con IAM, consiglia di utilizzare la versione più recente dello schema di criteri di autorizzazione disponibile in quella nel tempo. Di seguito illustreremo le diverse versioni disponibili e il modo in cui utilizzarle. Ti spiegheremo inoltre come specificare la versione desiderata e ti guideremo attraverso alcuni scenari di risoluzione dei problemi.

Ogni criterio di autorizzazione esistente specifica un campo version nell'ambito dell'autorizzazione nei metadati del criterio. Considera la parte evidenziata di seguito:

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Questo campo specifica la versione dello schema di sintassi del criterio di autorizzazione. Ciascuna del criterio di autorizzazione contiene uno schema di sintassi specifico che può essere utilizzato per associazioni di ruoli. La versione più recente può contenere associazioni di ruoli con lo schema di sintassi più recente non supportato dalle versioni precedenti. Questo campo non è destinato a essere utilizzato per scopi diversi dal controllo dello schema di sintassi per il criterio di autorizzazione.

Versioni dei criteri valide

I criteri di autorizzazione possono utilizzare le seguenti versioni dei criteri di autorizzazione:

Versione	Descrizione
`1`	La prima versione dello schema di sintassi IAM per criteri. Supporta l'associazione di un ruolo a una o più entità. Non supporta le associazioni di ruoli condizionali.
`2`	Riservato per uso interno.
`3`	Introduce il campo `condition` nell'associazione del ruolo, che limita l'associazione del ruolo le regole del caso. Per ulteriori informazioni, consulta Panoramica di IAM Condizioni.

Specificare la versione di un criterio durante il recupero di un criterio

Per l'API REST e le librerie client, quando ricevi un criterio di autorizzazione, ti consigliamo di specificare una versione del criterio di autorizzazione nella richiesta. Quando una richiesta specifica la versione di un criterio di autorizzazione, IAM presuppone che il chiamante sia a conoscenza delle funzionalità presenti di autorizzazione alla versione del criterio e sia in grado di gestirle correttamente.

Se la richiesta non specifica una versione del criterio di autorizzazione, IAM presuppone che il chiamante voglia un'autorizzazione di versione 1 .

Quando ricevi un criterio di autorizzazione, IAM controlla il criterio di autorizzazione. la versione nella richiesta o la versione predefinita se la richiesta non specificava completamente gestita. IAM verifica anche che nel criterio di autorizzazione siano presenti campi non supportato in un criterio di autorizzazione della versione 1. Utilizza queste informazioni per decidere quale tipo di risposta inviare:

Se il criterio di autorizzazione non contiene alcuna condizione: IAM restituisce sempre una versione 1 di autorizzazione, indipendentemente dal numero di versione nella richiesta.
Se il criterio di autorizzazione contiene condizioni e il chiamante ha richiesto una versione 3 criterio di autorizzazione, poi IAM restituisce un criterio di autorizzazione della versione 3 che include le condizioni. Per un esempio, vedi lo scenario 1 di questo video .
Se il criterio di autorizzazione contiene condizioni e il chiamante ha richiesto una versione 1 criterio di autorizzazione o non specifica una versione, quindi IAM restituisce un'autorizzazione di versione 1 .

Per le associazioni di ruoli che includono una condizione, IAM aggiunge la stringa _withcond_ al nome del ruolo, seguita da un valore hash; della ad esempio roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8. La non è presente. Per un esempio, vedi scenario 2 in questa pagina.

Scenario 1: versione del criterio che supporta completamente le condizioni IAM

Supponi di chiamare il seguente metodo dell'API REST per ottenere il criterio di autorizzazione per un progetto:

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

Il corpo della richiesta contiene il seguente testo:

{
  "options": {
    "requestedPolicyVersion": 3
  }
}

La risposta contiene il criterio di autorizzazione del progetto. Se il criterio di autorizzazione contiene almeno un'associazione condizionale di ruoli, il relativo campo version è impostato su 3:

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression": "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Se il criterio di autorizzazione non contiene associazioni di ruoli condizionali, il relativo campo version è impostato su 1, anche se la richiesta ha specificato la versione 3:

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer",
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Scenario 2: versione del criterio con supporto limitato per le condizioni IAM

Supponiamo di chiamare il seguente metodo dell'API REST per ottenere il criterio di autorizzazione per un progetto:

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

Il corpo della richiesta è vuoto. non specifica un numero di versione. Di conseguenza, IAM usa la versione predefinita del criterio di autorizzazione, 1.

Il criterio di autorizzazione contiene un'associazione condizionale dei ruoli. Poiché il criterio di autorizzazione è 1, la condizione non viene visualizzata nel risposta. Per indicare che l'associazione del ruolo utilizza una condizione, IAM aggiunge la stringa _withcond_ al nome del ruolo, seguita da un valore hash:

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer_withcond_58e135cabb940ad9346c"
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Specificare la versione di un criterio durante l'impostazione di un criterio

Quando imposti un criterio di autorizzazione, ti consigliamo di specificare un criterio di autorizzazione nella richiesta. Quando una richiesta specifica un criterio di autorizzazione automatica, IAM presuppone che il chiamante sia a conoscenza delle funzionalità nella versione del criterio di autorizzazione e che sia in grado di gestirli correttamente.

Se la richiesta non specifica una versione del criterio di autorizzazione, IAM accetta solo i campi che possono apparire in un criterio di autorizzazione versione1. Come best practice, non modificare le associazioni di ruoli condizionali in una versione 1 consentono policy; perché il criterio di autorizzazione non mostra la condizione per ogni ruolo. l'associazione, non sai quando o dove viene effettivamente concessa l'associazione del ruolo. Puoi invece recuperare la rappresentazione 3 della versione di autorizzazione , che mostra la condizione per ciascuna associazione dei ruoli. per aggiornare le associazioni di ruolo.

Scenario: versioni dei criteri in richieste e risposte

Supponi di usare l'API REST per ottenere un criterio di autorizzazione e di specificare la versione 3 nella richiesta. La risposta contiene la seguente norma consentita, che utilizza la versione 3:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin",
      "condition": {
          "title": "Weekday_access",
          "description": "Monday thru Friday access only in America/Chicago",
          "expression": "request.time.getDayOfWeek('America/Chicago') >= 1 && request.time.getDayOfWeek('America/Chicago') <= 5"
      }
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

Decidi che raha@example.com debba disporre del ruolo Amministratore archiviazione (roles/storage.admin) per tutta la settimana, non solo nei giorni feriali. Rimuovi la condizione dall'associazione di ruolo e invia una richiesta API REST per impostare il criterio di autorizzazione. Ancora una volta, specifica la versione 3 nella richiesta:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

La risposta contiene il criterio di autorizzazione aggiornato:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwWd8I+ZUAQ=",
  "version": 1
}

Il criterio di autorizzazione nella risposta utilizza la versione 1, anche tramite la richiesta specificata la versione 3, il criterio di autorizzazione utilizza solo i campi supportati in una versione Criterio di autorizzazione di 1.

Criteri con entità eliminate

Se un'associazione dei ruoli in un criterio di autorizzazione include un'entità eliminata e aggiungi un'entità l'associazione di ruoli per una nuova entità con lo stesso nome, l'associazione dei ruoli è sempre applicati alla nuova entità.

Ad esempio, considera questo criterio di autorizzazione che include un'associazione dei ruoli a un utente eliminato, donald@example.com e un account di servizio eliminato, my-service-account@project-id.iam.gserviceaccount.com. Di conseguenza, identificatore per ogni entità ha un prefisso deleted::

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901",
        "deleted:user:donald@example.com?uid=234567890123456789012"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Supponi di creare un nuovo utente anch'esso denominato donald@example.com e di vuoi concedere il ruolo Autore progetto (roles/resourcemanager.projectCreator), che consente alle entità di creare progetti Google Cloud per il nuovo utente. Per concedere il ruolo al nuovo utente, aggiorna il criterio di autorizzazione come mostrato in esempio:

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901",
        "deleted:user:donald@example.com?uid=234567890123456789012"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:donald@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Per semplificare il controllo dei criteri di autorizzazione IAM, puoi anche rimuovere l'utente eliminato dall'associazione del ruolo al ruolo Proprietario:

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:donald@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Best practice relative alle norme

Le seguenti best practice si applicano alle organizzazioni con molti utenti Google Cloud:

Quando gestisci più account utente con le stesse configurazioni di accesso, utilizza Google Gruppi. Inserisci ogni singolo account utente nel gruppo e concedi i ruoli previsti al gruppo anziché ai singoli account utente.
Ruoli concessi a livello di organizzazione: valuta con attenzione quali alle entità vengono concessi ruoli a livello di organizzazione. Per la maggior parte solo a pochi team specifici, come i team dedicati a sicurezza e rete, a questo livello della gerarchia delle risorse.
Ruoli concessi a livello di cartella: considera la possibilità di rispecchiare il tuo struttura operativa dell'organizzazione utilizzando livelli di cartelle, in cui Ogni cartella può essere configurata con diversi insiemi di accessi di donazioni in linea con le esigenze aziendali e operative. Ad esempio, un cartella principale potrebbe riflettere un reparto, una delle rispettive cartelle secondarie riflettono l'accesso e il funzionamento alle risorse da parte di un gruppo e di un'altra cartella secondaria può essere il frutto di un piccolo team. Entrambe queste due cartelle potrebbero contenere progetti per le esigenze operative del loro team. Utilizzare le cartelle in questo modo può garantire la separazione degli accessi, rispettando i criteri di autorizzazione ereditati dall'elemento padre cartelle e l'organizzazione. Questa pratica richiede una manutenzione minore di consentire i criteri durante la creazione e la gestione delle risorse Google Cloud.
Ruoli concessi a livello di progetto: concedi le associazioni dei ruoli a livello di progetto a livello di progetto ove necessario per seguire il principio del privilegio minimo. Per Ad esempio, se un'entità deve accedere a 3 dei 10 progetti in una cartella, deve concedere l'accesso a ciascuno dei tre progetti individualmente; al contrario, se se hai concesso un ruolo per la cartella, l'entità otterrà l'accesso necessario senza bisogno di altri 7 progetti.

In alternativa, puoi utilizzare Condizioni IAM per concedere ruoli a livello di organizzazione o di cartella, ma solo per un sottoinsieme di cartelle o progetti.
Concedi l'accesso solo alle entità del tuo dominio: per migliorare le tue sicurezza dell'organizzazione, non concedere ruoli a entità esterne al tuo dominio. Puoi applicare questa best practice applicando il iam.allowedPolicyMemberDomains criterio dell'organizzazione di blocco.

Nota: se la tua organizzazione è stata creata a partire dal 3 maggio 2024, questo vincolo viene applicato per impostazione predefinita e il tuo dominio è elencato come l'unico valore consentito.

Passaggi successivi

Scopri come risolvere i problemi relativi ai criteri di autorizzazione che contengono la stringa withcond nei nomi dei ruoli.
Scopri come gestire le associazioni di ruoli in un criterio di autorizzazione.
Panoramica delle condizioni IAM, che usano i criteri di autorizzazione della versione 3.
Esplora gli strumenti di Policy Intelligence, che ti aiutano comprendere e gestire i criteri di autorizzazione per migliorare proattivamente la sicurezza configurazione.
Utilizza l'API Cloud Asset per cercare i criteri di autorizzazione.
Utilizza l'API Cloud Asset per visualizza i criteri di autorizzazione in vigore.