Questa pagina è stata tradotta dall'API Cloud Translation.

Comprendi i criteri di autorizzazione

Puoi concedere l'accesso alle risorse utilizzando le policy di autorizzazione, note anche come policy IAM (Identity and Access Management), che sono allegate alle risorse. Google Cloud Puoi collegare una sola policy di autorizzazione a ogni risorsa. Il criterio di autorizzazione controlla l'accesso alla risorsa stessa e a tutti i suoi discendenti che ereditano il criterio di autorizzazione.

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

Struttura delle norme

Un criterio di autorizzazione è una raccolta di associazioni di ruoli e metadati. Un binding del ruolo specifica l'accesso da 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 sulla policy di autorizzazione, ad esempio un etag e una versione per facilitare la gestione delle policy.

Ogni associazione di ruolo può includere i seguenti campi:

Una o più entità, note anche come membri o identità. Esistono più tipi di entità, tra cui singoli utenti, gruppi di utenti e service account. Per un elenco completo dei tipi di entità supportati, consulta Tipi di entità.
Un ruolo, ovvero una raccolta denominata di autorizzazioni che forniscono la possibilità di eseguire azioni sulle risorse Google Cloud.
Una condizione, ovvero un'espressione logica facoltativa che vincola ulteriormente l'associazione di ruolo in base agli attributi della richiesta, ad esempio l'origine o la risorsa di destinazione. Le condizioni vengono in genere utilizzate per controllare se l'accesso viene concesso in base al contesto di una richiesta.

Se un'associazione di ruolo contiene una condizione, viene definita associazione di ruolo condizionale.

Alcuni Google Cloud servizi non accettano condizioni nelle policy di autorizzazione. 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 le modifiche all'accesso richiedono tempo per propagarsi nel sistema. Per scoprire in media quanto tempo impiega la propagazione delle modifiche di accesso, consulta Propagazione della modifica di accesso.

Limiti per tutti i principal

Ogni policy di autorizzazione può contenere fino a 1500 entità. Ai fini di questo limite, IAM conteggia tutte le occorrenze di ciascuna entità nelle associazioni di ruolo del criterio di autorizzazione, nonché le entità che il criterio di autorizzazione esenta dalla registrazione degli audit log di accesso ai dati. Non deduplica le entità presenti in più di un'associazione di ruoli. Ad esempio, se una policy di autorizzazione contiene solo associazioni di ruoli per l'entità user:my-user@example.com e questa entità compare in 50 associazioni di ruoli, puoi aggiungere altre 1450 entità alle associazioni di ruoli nella policy di autorizzazione.

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

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

Limiti per gruppi e domini

Fino a 250 delle entità in un criterio di autorizzazione possono essere gruppi Google, domini Cloud Identity o account Google Workspace.

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

Per i gruppi Google, ogni gruppo unico viene conteggiato una sola volta, indipendentemente dal numero di volte in cui il gruppo viene visualizzato nel criterio di autorizzazione. Questo è diverso dal modo in cui i gruppi vengono conteggiati per il limite sul numero totale di entità in una policy di autorizzazione. Per questo limite, ogni occorrenza di un gruppo viene conteggiata ai fini del limite.
Per i domini Cloud Identity o gli account Google Workspace, IAM conteggia tutte le volte che ciascun dominio o account compare nelle associazioni di ruoli del criterio di autorizzazione. Non deduplica i domini o gli account presenti in più di un'associazione di ruoli.

Ad esempio, se la tua norma di autorizzazione contiene un solo gruppo, group:my-group@example.com, e il gruppo viene visualizzato nella norma di autorizzazione 10 volte, puoi aggiungere altri 249 domini Cloud Identity, account Google Workspace o gruppi unici prima di raggiungere il limite.

In alternativa, se i criteri di autorizzazione contengono un solo dominio, domain:example.com, e il dominio viene visualizzato nei criteri di autorizzazione 10 volte, puoi aggiungere altri 240 domini Cloud Identity, account Google Workspace o gruppi unici prima di raggiungere il limite.

Metadati delle norme

I metadati per una policy di autorizzazione includono i seguenti campi:

Un campo etag, utilizzato per controllo della contemporaneità e che garantisce che i criteri di autorizzazione vengano aggiornati in modo coerente. Per maggiori dettagli, vedi Utilizzo degli ETag in una policy in questa pagina.
Un campo version, che specifica la versione dello schema per una determinata policy consenti. Per maggiori dettagli, consulta la sezione Versioni delle norme di 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 questa parte di una policy di autorizzazione, consulta Configurazione degli audit log di accesso ai dati.

Utilizzo degli ETag in un criterio

Quando più sistemi tentano di scrivere contemporaneamente nella stessa policy di autorizzazione, esiste il rischio che i sistemi sovrascrivano le modifiche degli altri. Questo rischio esiste perché i criteri di autorizzazione vengono aggiornati utilizzando il pattern di lettura, modifica e scrittura, che prevede più operazioni:

Lettura della policy di autorizzazione esistente
Modifica della policy di autorizzazione
Scrittura dell'intera policy di autorizzazione

Se il sistema A legge una policy di autorizzazione e il sistema B scrive immediatamente una versione aggiornata di questa policy di autorizzazione, il sistema A non sarà a conoscenza delle modifiche apportate dal sistema B. Quando il sistema A scrive le proprie modifiche alla norma di autorizzazione, le modifiche del sistema B potrebbero andare perse.

Per contribuire a prevenire questo problema, Identity and Access Management (IAM) supporta il controllo della concorrenza tramite l'utilizzo di un campo etag nel criterio di autorizzazione. Ogni policy di autorizzazione contiene un campo etag e il valore di questo campo cambia ogni volta che una policy di autorizzazione viene aggiornata. Se un criterio di autorizzazione contiene un campo etag, ma nessun binding dei ruoli, il criterio di autorizzazione non concede alcun ruolo IAM.

Il campo etag contiene un valore come BwUjMhCsNvY=. Quando aggiorni il criterio di autorizzazione, assicurati di includere il campo etag nel criterio di autorizzazione aggiornato. Se la policy di autorizzazione è stata modificata dopo il recupero, il valore etag non corrisponderà e l'aggiornamento non andrà a buon fine. Per l'API REST, ricevi il codice di stato HTTP 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 ricevi questo errore, riprova l'intera serie di operazioni: leggi di nuovo le norme di autorizzazione, modificale in base alle tue esigenze e scrivi le norme di autorizzazione aggiornate. Devi eseguire automaticamente i nuovi tentativi, con backoff esponenziale, in tutti gli strumenti che utilizzi per gestire le norme di autorizzazione.

Esempio: policy semplice

Considera la seguente policy 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 viene concesso il ruolo di base Proprietario senza condizioni. Questo ruolo concede a Jie un accesso quasi illimitato.

Esempio: policy con più associazioni di ruoli

Considera la seguente policy di autorizzazione che contiene più di un'associazione di 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 viene assegnato il ruolo predefinito Amministratore dell'organizzazione (roles/resourcemanager.organizationAdmin) nella prima associazione del ruolo. Questo ruolo contiene le autorizzazioni per le organizzazioni, le cartelle e le operazioni limitate ai progetti. Nella seconda associazione del ruolo, sia a Jie che a Raha è concessa la possibilità di creare progetti tramite il ruolo Autore progetto (roles/resourcemanager.projectCreator). Insieme, queste associazioni del ruolo garantiscono un accesso granulare sia a Jie che a Raha e a Jie è garantito un accesso più ampio rispetto a Raha.

Esempio: policy con associazione di ruoli condizionale

Considera la seguente policy di autorizzazione, che associa le entità a un ruolo predefinito e utilizza un'espressione di condizione per vincolare 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é la policy di autorizzazione contiene un'espressione di condizione. L'associazione di ruolo nella policy di autorizzazione è condizionale: concede il ruolo al gruppo prod-dev e al account di servizio prod-dev-example@appspot.gserviceaccount.com, ma solo fino al 1° luglio 2022.

Per informazioni dettagliate sulle funzionalità supportate da ogni versione delle norme di autorizzazione, consulta la sezione Versioni delle norme in questa pagina.

Esempio: policy con associazioni di ruoli condizionali e incondizionali

Considera la seguente policy di autorizzazione, che contiene associazioni di ruoli condizionali e 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, il account di servizio serviceAccount:prod-dev-example@appspot.gserviceaccount.com è incluso in due assegnazioni di ruolo per lo stesso ruolo. La prima associazione di ruolo non ha una condizione. La seconda associazione di ruoli ha una condizione che concede il ruolo solo fino al 1° luglio 2022.

In pratica, questo criterio di autorizzazione concede sempre il ruolo al account di servizio. 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 di ruoli non ha una condizione, l'entità ha sempre quel ruolo. L'aggiunta dell'entità a un'associazione di ruolo condizionale per lo stesso ruolo non ha alcun effetto.

Al contrario, il gruppo prod-dev è incluso solo nel binding del ruolo condizionale. Pertanto, ha il ruolo solo prima del 1° luglio 2022.

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

Considera la seguente policy di autorizzazione. Questa policy di autorizzazione associa un ruolo a un service account, serviceAccount:my-service-account@my-project.iam.gserviceaccount.com, che è stato eliminato. Di conseguenza, l'identificatore del service account ora ha il prefisso deleted::

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

Se crei un nuovo account di servizio con lo stesso nome, le associazioni di ruoli della policy di autorizzazione per ilaccount di serviziot eliminato non si applicano al nuovoaccount di serviziot. Questo comportamento si applica a tutti i tipi di entità eliminate.

Questo comportamento impedisce alle nuove entità di ereditare i ruoli concessi alle entità eliminate. Se vuoi concedere ruoli alla nuova entità, aggiungila alle associazioni di ruolo della policy di autorizzazione, come mostrato in Policy con entità eliminate in questa pagina.

Tutte le entità eliminate hanno il prefisso deleted:. Alcuni tipi di entità eliminate, come i service account, hanno anche il suffisso ?uid=numeric-id, dove numeric-id è l'ID numerico univoco dell'entità eliminata. In questo esempio, anziché serviceAccount:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com, il criterio di autorizzazione mostra l'identificatore deleted:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com?uid=123456789012345678901.

Norme predefinite

Tutte le risorse che accettano le policy di autorizzazione vengono create con le policy di autorizzazione predefinite. I criteri di autorizzazione predefiniti della maggior parte delle risorse sono vuoti. Tuttavia, i criteri di autorizzazione predefiniti di alcune risorse contengono automaticamente determinati binding dei ruoli. Ad esempio, quando crei un nuovo progetto, la policy di autorizzazione per il progetto ha automaticamente un binding del ruolo che ti concede il ruolo Proprietario (roles/owner) per il progetto.

Queste associazioni di ruoli vengono create dal sistema, quindi l'utente non ha bisogno delle autorizzazioni getIamPolicy o setIamPolicy sulla risorsa per la creazione delle associazioni di ruoli.

Per sapere se una risorsa viene creata con una policy di autorizzazione, consulta la documentazione della risorsa.

Ereditarietà delle policy e gerarchia delle risorse

Le risorseGoogle Cloud sono organizzate in modo gerarchico, dove il nodo organizzazione è il nodo radice della gerarchia, seguito facoltativamente da cartelle e poi da progetti. La maggior parte delle altre risorse vengono create e gestite in un progetto. Ogni risorsa ha un solo elemento padre, tranne l'organizzazione. L'organizzazione, in quanto nodo radice della gerarchia, non ha un elemento padre. Per saperne di più, consulta l'argomento Gerarchia delle risorse.

La gerarchia delle risorse è importante da considerare quando si imposta una policy di autorizzazione. Quando imposti una policy di autorizzazione a un livello superiore della gerarchia, ad esempio a livello di organizzazione, cartella o progetto, l'ambito di accesso concesso include il livello di risorsa a cui è collegata questa policy di autorizzazione e tutte le risorse al di sotto di questo livello. Ad esempio, una policy di autorizzazione impostata a livello di organizzazione si applica all'organizzazione e a tutte le risorse sottostanti. Analogamente, una policy di autorizzazione impostata a livello di progetto si applica al progetto e a tutte le risorse del progetto.

Ereditarietà dei criteri è il termine che descrive in che modo i criteri di autorizzazione si applicano alle risorse al di sotto del loro livello nella gerarchia delle risorse. Policy effettiva è il termine che descrive in che modo tutte le policy di autorizzazione principali nella gerarchia delle risorse vengono ereditate per una risorsa. È l'unione di quanto segue:

La policy di autorizzazione impostata sulla risorsa
Le policy di autorizzazione impostate su tutti i livelli di risorse di origine della risorsa nella gerarchia

Ogni nuovo binding del ruolo (ereditato dalle risorse padre) che influisce sul criterio di autorizzazione effettivo della risorsa viene valutato in modo indipendente. Una richiesta di accesso specifica alla risorsa viene concessa se uno qualsiasi dei binding dei ruoli di livello superiore concede l'accesso alla richiesta.

Se viene introdotto un nuovo binding del ruolo in qualsiasi livello della policy di autorizzazione ereditata di una risorsa, l'ambito della concessione di accesso aumenta.

Esempio: ereditarietà delle policy

Per comprendere l'ereditarietà dei criteri di autorizzazione, considera uno scenario in cui concedi a un utente, Raha, due ruoli IAM diversi a due livelli diversi della gerarchia delle risorse.

Per concedere a Raha un ruolo a livello di organizzazione, imposta la seguente policy di autorizzazione nella 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 nella tua organizzazione, Raha può utilizzare queste autorizzazioni per tutti i progetti e tutti gli oggetti Cloud Storage della tua organizzazione.

Per concedere a Raha un ruolo a livello di progetto, imposta i seguenti criteri di autorizzazione sul progetto myproject-123:

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

Questa policy di autorizzazione concede a Raha il ruolo Storage Object Creator (roles/storage.objectCreator), che le consente di creare oggetti Cloud Storage. Poiché hai impostato il criterio di autorizzazione su myproject-123, Raha può creare oggetti Cloud Storage solo in myproject-123.

Ora che esistono due associazioni di ruoli che concedono a Raha l'accesso agli oggetti Cloud Storage di destinazione in myproject-123, si applicano le seguenti policy di autorizzazione:

Una policy di autorizzazione a livello di organizzazione concede la possibilità di elencare e recuperare 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 di questo progetto.

La tabella seguente riassume la policy effettiva di Raha:

Autorizzazioni del ruolo Visualizzatore oggetti Storage nell'organizzazione	Autorizzazioni del ruolo Storage Object Creator su `myproject-123`	Autorizzazioni valide per Raha su `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 delle policy

Nel tempo, IAM potrebbe aggiungere nuove funzionalità che aggiungono o modificano in modo significativo i campi nello schema dei criteri di autorizzazione. Per evitare di interrompere le integrazioni esistenti che si basano sulla coerenza della struttura della policy di autorizzazione, queste modifiche vengono introdotte nelle nuove versioni dello schema della policy di autorizzazione.

Se esegui l'integrazione con IAM per la prima volta, ti consigliamo di utilizzare la versione più recente dello schema dei criteri di autorizzazione disponibile in quel momento. La sezione seguente illustra le diverse versioni disponibili e come utilizzarle. Descrive inoltre come specificare una versione della policy e illustra alcuni scenari di risoluzione dei problemi.

Ogni criterio di autorizzazione esistente specifica un campo version come parte dei metadati del criterio di autorizzazione. Considera la parte evidenziata del seguente esempio:

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

Questo campo specifica la versione dello schema della sintassi del criterio di autorizzazione. Ogni versione della policy di autorizzazione contiene uno schema di sintassi specifico che può essere utilizzato dalle 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 della sintassi per la policy di autorizzazione.

Versioni valide delle norme

I criteri di autorizzazione possono utilizzare le seguenti versioni:

Versione	Descrizione
`1`	La prima versione dello schema della sintassi IAM per le policy. 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 di ruolo, che vincola l'associazione di ruolo utilizzando regole basate sul contesto e sugli attributi. Per saperne di più, consulta la panoramica delle condizioni IAM.

Specifica di una versione della policy durante il recupero di una policy

Per l'API REST e le librerie client, quando recuperi una policy di autorizzazione, ti consigliamo di specificare una versione della policy di autorizzazione nella richiesta. Quando una richiesta specifica una versione dei criteri di autorizzazione, IAM presuppone che il chiamante sia a conoscenza delle funzionalità di quella versione dei criteri di autorizzazione e possa gestirle correttamente.

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

Quando ricevi una policy di autorizzazione, IAM controlla la versione della policy di autorizzazione nella richiesta o la versione predefinita se la richiesta non ha specificato una versione. IAM controlla anche la policy di autorizzazione per i campi non supportati in una policy di autorizzazione della versione 1. Utilizza queste informazioni per decidere il tipo di risposta da inviare:

Se il criterio di autorizzazione non contiene condizioni, IAM restituisce sempre una versione 1 del criterio di autorizzazione, indipendentemente dal numero di versione nella richiesta.
Se il criterio di autorizzazione contiene condizioni e il chiamante ha richiesto un criterio di autorizzazione 3, IAM restituisce un criterio di autorizzazione 3 che include le condizioni. Per un esempio, consulta lo scenario 1 in questa pagina.
Se la policy di autorizzazione contiene condizioni e il chiamante ha richiesto una policy di autorizzazione 1 o non ha specificato una versione, IAM restituisce una policy di autorizzazione 1.

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

Scenario 1: versione dei criteri che supporta completamente 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 contiene il seguente testo:

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

La risposta contiene la policy di autorizzazione del progetto. Se il criterio di autorizzazione contiene almeno un binding di ruolo condizionale, il relativo campo version è impostato su 3:

{
  "bindings": [
    {
      "members": [
        "user:tal@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 la policy di autorizzazione non contiene associazioni di ruoli condizionali, il campo version è impostato su 1, anche se la richiesta ha specificato la versione 3:

{
  "bindings": [
    {
      "members": [
        "user:tal@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 e non specifica un numero di versione. Di conseguenza, IAM utilizza la versione predefinita della policy di autorizzazione, 1.

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

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

Specifica di una versione della policy durante l'impostazione di una policy

Quando imposti una policy di autorizzazione, ti consigliamo di specificare una versione della policy di autorizzazione nella richiesta. Quando una richiesta specifica una versione dei criteri di autorizzazione, IAM presuppone che il chiamante sia a conoscenza delle funzionalità di quella versione dei criteri di autorizzazione e possa gestirle correttamente.

Se la richiesta non specifica una versione del criterio di autorizzazione, IAM accetta solo i campi che possono essere visualizzati in un criterio di autorizzazione 1. Come best practice, non modificare i binding dei ruoli condizionali in un criterio di autorizzazione della versione 1, perché il criterio di autorizzazione non mostra la condizione per ogni binding del ruolo, quindi non sai quando o dove viene effettivamente concesso il binding del ruolo. Ottieni invece la rappresentazione della versione 3 della policy di autorizzazione, che mostra la condizione per ogni associazione di ruoli, e utilizza questa rappresentazione per aggiornare le associazioni di ruoli.

Scenario: versioni delle norme nelle richieste e nelle risposte

Supponiamo che tu utilizzi l'API REST per ottenere una policy di autorizzazione e che tu specifichi la versione 3 nella richiesta. La risposta contiene la seguente policy di autorizzazione, 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 deve disporre del ruolo Amministratore Storage (roles/storage.admin) durante tutta la settimana, non solo nei giorni feriali. Rimuovi la condizione dal binding del ruolo e invia una richiesta API REST per impostare la policy 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 la policy di autorizzazione aggiornata:

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

La policy di autorizzazione nella risposta utilizza la versione 1, anche se la richiesta ha specificato la versione 3, perché la policy di autorizzazione utilizza solo i campi supportati in una versione 1 della policy di autorizzazione.

Policy con entità eliminate

Se un'associazione di ruolo in una policy di autorizzazione include un'entità eliminata e aggiungi un'associazione di ruolo per una nuova entità con lo stesso nome, l'associazione di ruolo viene sempre applicata alla nuova entità.

Ad esempio, considera questa policy di autorizzazione che include un'associazione di ruolo per un account di servizio eliminato, my-service-account@project-id.iam.gserviceaccount.com. Di conseguenza, l'identificatore di ogni account di servizio ha il prefisso deleted::

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

Supponiamo di creare un nuovo account di servizio denominato my-service-account@project-id.iam.gserviceaccount.com e di voler concedergli il ruolo Autore progetto (roles/resourcemanager.projectCreator). Per concedere il ruolo al nuovo service account, aggiorna la policy di autorizzazione come mostrato in questo esempio:

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

Per semplificare l'audit delle policy IAM consentite, puoi anche rimuovere l'utente eliminato dall'associazione di 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 per le norme

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

Quando gestisci più entità con le stesse configurazioni di accesso, utilizza i gruppi. Inserisci ogni singola entità nel gruppo e concedi i ruoli previsti al gruppo anziché alle entità degli account utente individuali.
Ruoli concessi a livello di organizzazione: valuta attentamente a quali entità vengono concessi ruoli a livello di organizzazione. Per la maggior parte delle organizzazioni, solo a pochi team specifici, come i team di sicurezza e di rete, deve essere concesso l'accesso a questo livello della gerarchia delle risorse.
Ruoli concessi a livello di cartella: valuta la possibilità di riflettere la struttura operativa della tua organizzazione utilizzando livelli di cartelle, in cui ogni cartella può essere configurata con diversi set di concessioni di accesso allineati alle esigenze aziendali e operative. Ad esempio, una cartella principale potrebbe riflettere un reparto, una delle sue cartelle secondarie potrebbe riflettere l'accesso e l'operazione alle risorse da parte di un gruppo e un'altra cartella secondaria potrebbe riflettere un piccolo team. Entrambe queste cartelle potrebbero contenere progetti per le esigenze operative del team. L'utilizzo delle cartelle in questo modo può garantire una corretta separazione dell'accesso, rispettando al contempo le norme di autorizzazione ereditate dalle cartelle principali e dall'organizzazione. Questa pratica richiede meno manutenzione delle norme di autorizzazione durante la creazione e la gestione delle risorse Google Cloud .
Ruoli concessi a livello di progetto: concedi i binding dei ruoli a livello di progetto quando necessario per seguire il principio del privilegio minimo. Ad esempio, se un principal ha bisogno dell'accesso a 3 dei 10 progetti in una cartella, devi concedere l'accesso a ciascuno dei 3 progetti singolarmente. Al contrario, se concedi un ruolo nella cartella, il principal otterrà l'accesso a 7 progetti aggiuntivi di cui non ha bisogno.

In alternativa, puoi utilizzare le condizioni IAM per concedere ruoli a livello di organizzazione o cartella, ma solo per un sottoinsieme di cartelle o progetti.
Concedi l'accesso solo alle entità all'interno del tuo dominio: per migliorare la sicurezza della tua organizzazione, non concedere ruoli a entità esterne al tuo dominio. Puoi applicare questa best practice applicando il vincolo dei criteri dell'organizzazione iam.allowedPolicyMemberDomains.

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

Passaggi successivi

Scopri come risolvere i problemi relativi alle policy di autorizzazione che contengono la stringa withcond nei nomi dei ruoli.
Scopri come gestire i binding dei ruoli in una policy di autorizzazione.
Consulta una panoramica delle condizioni IAM, che utilizzano le policy di autorizzazione della versione 3.
Esplora gli strumenti di Policy Intelligence, che ti aiutano a comprendere e gestire le tue policy di autorizzazione per migliorare in modo proattivo la configurazione della sicurezza.
Utilizza l'API Cloud Asset per cercare i criteri di autorizzazione.
Utilizza l'API Cloud Asset per visualizzare le policy di autorizzazione effettive.