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 associare una sola regola 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 norme consentite 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'associazione di ruoli 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 sul criterio di autorizzazione, ad esempio un etag e una versione per facilitare la gestione dei criteri.

Ogni associazione di ruoli può includere i seguenti campi:

  • Uno o più principali, noti anche come membri o identità. Esistono diversi tipi di entità, tra cui account utente, account di servizio, gruppi Google e domini. Per un elenco completo dei tipi di principali supportati, consulta Identificatori principali.
  • Un ruolo, ovvero una raccolta denominata di autorizzazioni che consente di eseguire azioni sulle risorse Google Cloud.

  • Una condizione, ovvero un'espressione logica facoltativa che limita ulteriormente l'associazione del ruolo in base agli attributi della richiesta, come l'origine o la risorsa di destinazione. Le condizioni vengono generalmente utilizzate per controllare se l'accesso viene concesso in base al contesto di 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 coerenti in un secondo momento. Ciò significa che le modifiche all'accesso devono essere propagate nel sistema. Per scoprire quanto tempo occorre in media per la propagazione delle modifiche di accesso, consulta Propagazione della modifica di accesso.

Limiti per tutti i principali

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 dal logging di controllo dell'accesso ai dati dal criterio di autorizzazione. Non deduplica le entità presenti in più di un'associazione di ruoli. Ad esempio, se un criterio 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 nel criterio di autorizzazione.

Inoltre, ai fini di questo limite, ogni occorrenza di un dominio o di un gruppo Google viene conteggiata come un singolo 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 meno 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 univoco 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 al numero totale di entità in un criterio di autorizzazione: per questo limite, ogni apparizione di un gruppo viene conteggiata.
  • Per i domini Cloud Identity o gli account Google Workspace, IAM conteggia tutte le occorrenze di ciascun dominio o account nelle associazioni dei ruoli del criterio di autorizzazione. Non deduplica i domini o gli account presenti in più di un'associazione di ruoli.

Ad esempio, se il criterio di autorizzazione contiene un solo gruppo, group:my-group@example.com, e il gruppo viene visualizzato nel criterio di autorizzazione 10 volte, puoi aggiungere altri 249 domini Cloud Identity, account Google Workspace o gruppi univoci prima di raggiungere il 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, puoi aggiungere altri 240 domini Cloud Identity, account Google Workspace o gruppi unici prima di raggiungere il limite.

Metadati delle norme

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

  • Un campo etag, utilizzato per controllo della contemporaneità, che garantisce l'aggiornamento coerente dei criteri di autorizzazione. Per maggiori dettagli, consulta Utilizzare gli ETag in un criterio in questa pagina.
  • Un campo version che specifica la versione dello schema per un determinato criterio di autorizzazione. Per maggiori dettagli, 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 questa parte di un criterio di autorizzazione, consulta la pagina 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, esiste il rischio che questi sistemi sovrascrivano le modifiche l'uno dell'altro. Questo rischio esiste perché i criteri di autorizzazione vengono aggiornati utilizzando il pattern di lettura, modifica e scrittura, che prevede più operazioni:

  1. Lettura del criterio di autorizzazione esistente
  2. Modifica del criterio di autorizzazione
  3. Scrittura dell'intero criterio di autorizzazione

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

Per contribuire a evitare questo problema, Identity and Access Management (IAM) supporta il controllo della concorrenza tramite l'utilizzo 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 associazioni di 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 il criterio di autorizzazione è stato modificato da quando lo hai recuperato, 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 il criterio di autorizzazione, modificalo in base alle esigenze e scrivi il criterio di autorizzazione aggiornato. Devi eseguire automaticamente i nuovi tentativi, con backoff esponenziale, in tutti gli strumenti che utilizzi per gestire i criteri di autorizzazione.

Esempio: norme semplici

Prendiamo in considerazione il seguente criterio di autorizzazione che lega un'entità a un ruolo:

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

Nell'esempio riportato sopra, a jie@example.com viene assegnato il ruolo di proprietario di base senza alcuna condizione. Questo ruolo offre a jie@example.com accesso quasi illimitato.

Esempio: criteri con più associazioni di ruoli

Prendi in considerazione il seguente criterio di autorizzazione che contiene più di un'associazione di ruolo. 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 riportato sopra, a Jie (jie@example.com) 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 (raha@example.com) è concessa la possibilità di creare progetti attraverso 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: criterio con associazione di ruoli condizionale

Prendi in considerazione la seguente policy 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, poiché la norma consenti contiene un'espressione di condizione. L'associazione del ruolo nel criterio di autorizzazione è condizionale: concede il ruolo al gruppo Googleprod-dev@example.com e all'account di servizioprod-dev-example@appspot.gserviceaccount.com, ma solo fino al 1° luglio 2022.

Per informazioni dettagliate sulle funzionalità supportate da ogni versione del criterio di autorizzazione, consulta la sezione Versioni dei criteri in questa pagina.

Esempio: criteri con associazioni di ruoli condizionali e incondizionali

Considera il seguente criterio di autorizzazione, che contiene associazioni di ruoli sia condizionali che non condizionali 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 servizioserviceAccount:prod-dev-example@appspot.gserviceaccount.com è incluso in due associazioni di ruoli per lo stesso ruolo. La prima associazione di ruoli 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à avrà 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 Google group:prod-dev@example.com è incluso solo nella associazione dei ruoli condizionali. Pertanto, ha il ruolo solo prima del 1° luglio 2022.

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

Prendi in considerazione il seguente criterio di autorizzazione. Questo criterio di autorizzazione lega 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, le associazioni dei ruoli del criterio di autorizzazione 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 i ruoli al nuovo utente, aggiungilo alle associazioni di ruoli del criterio di autorizzazione, come mostrato in Criteri con principali eliminati in questa pagina.

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

I gruppi e gli account di servizio hanno lo stesso comportamento degli utenti. Se elimini un account di servizio o un gruppo, poi visualizzi un criterio di autorizzazione che include l'entità, il nome dell'entità eliminata avrà 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. I criteri di autorizzazione predefiniti della maggior parte delle risorse sono vuoti. Tuttavia, i criteri di autorizzazione predefiniti di alcune risorse contengono automaticamente determinate 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.

Poiché queste associazioni di ruoli vengono create dal sistema, l'utente non ha bisogno di autorizzazioni getIamPolicy o setIamPolicy per la risorsa per poterle creare.

Per sapere se una risorsa è stata creata con un criterio di autorizzazione, consulta la documentazione della risorsa.

Ereditarietà dei criteri e gerarchia delle risorse

Le risorse di Google Cloud sono organizzate in modo gerarchico, dove il nodo dell'organizzazione è il nodo principale della gerarchia, poi, facoltativamente, le cartelle e infine i progetti. La maggior parte delle altre risorse viene creata e gestita in un progetto. Ogni risorsa ha un solo elemento padre, tranne l'organizzazione. L'organizzazione, come nodo radice della gerarchia, non ha un elemento principale. Per ulteriori informazioni, consulta l'argomento Gerarchia delle risorse.

La gerarchia delle risorse è importante da considerare quando si imposta un criterio di autorizzazione. Quando imposti un criterio di autorizzazione a un livello più alto nella gerarchia, ad esempio a livello di organizzazione, di cartella o di progetto, l'ambito di accesso concesso include il livello della risorsa a cui è associato questo criterio di autorizzazione e tutte le risorse al di sotto di questo livello. 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 e a tutte le risorse al suo interno.

L'ereditarietà dei criteri è il termine che descrive in che modo i criteri di autorizzazione vengono applicati alle risorse al di sotto del loro livello nella gerarchia delle risorse. Criterio applicato è 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 sulla risorsa
  • I criteri consentiti impostati su tutti i livelli di risorse della gerarchia della risorsa

Ogni nuova associazione di ruolo (ereditata dalle risorse principali) che influisce sul criterio di autorizzazione effettivo della risorsa viene valutata in modo indipendente. Una richiesta di accesso specifica alla risorsa viene concessa se una delle associazioni di ruoli di livello superiore concede l'accesso alla richiesta.

Se viene introdotta una nuova associazione di ruoli a qualsiasi livello del criterio di autorizzazione ereditato di una risorsa, l'ambito della concessione dell'accesso aumenta.

Esempio: ereditarietà delle norme

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

Per concedere a Raha un ruolo a livello di organizzazione, imposti il seguente criterio 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 per la 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, imposti il seguente criterio di autorizzazione sul 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 di oggetti archiviazione (roles/storage.objectCreator), che gli 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 i seguenti criteri di autorizzazione:

  • Un criterio di autorizzazione a livello di organizzazione concede la possibilità di elencare e recuperare tutti gli oggetti Cloud Storage di 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 per Raha:

Autorizzazioni concesse tramite il ruolo "storage.objectViewer" a livello di organizzazione Autorizzazioni concesse tramite il ruolo "storage.objectCreator" 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 modificano o aggiungono in modo significativo i campi nello schema del criterio di autorizzazione. Per evitare di interrompere le integrazioni esistenti che si basano sulla coerenza nella struttura dei criteri consentiti, queste modifiche vengono introdotte nelle nuove versioni dello schema dei criteri consentiti.

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 al momento. Di seguito, illustreremo le diverse versioni disponibili e come utilizzarle. Inoltre, descriveremo come specificare la versione che preferisci e illustreremo alcuni scenari di risoluzione dei problemi.

Ogni criterio di autorizzazione esistente specifica un campo version come parte dei 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. Ogni versione del criterio di autorizzazione contiene uno schema di sintassi specifico che può essere utilizzato dall'associazione dei 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 è pensato per 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:

Versione Descrizione
1 La prima versione dello schema di sintassi IAM per le norme. Supporta l'associazione di un ruolo a uno 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 limita l'associazione di ruolo tramite regole basate su contesto e attributi. Per ulteriori informazioni, consulta la panoramica delle condizioni IAM.

Specificare una versione del criterio quando ne viene richiesto uno

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 una versione del criterio di autorizzazione, IAM presuppone che il chiamante sia a conoscenza delle funzionalità della versione del criterio di autorizzazione e che possa gestirle correttamente.

Se la richiesta non specifica una versione del criterio di autorizzazione, IAM assume che chi chiama voglia un criterio di autorizzazione della versione 1.

Quando ricevi un criterio di autorizzazione, IAM controlla la versione del criterio di autorizzazione nella richiesta o la versione predefinita se la richiesta non ne ha specificata una. IAM controlla anche il criterio di autorizzazione per i campi non supportati 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 condizioni, IAM restituisce sempre un criterio di autorizzazione della versione 1, indipendentemente dal numero di versione nella richiesta.
  • Se il criterio di autorizzazione contiene condizioni e l'utente che ha chiamato la funzione ha richiesto un criterio di autorizzazione versione 3, IAM restituisce un criterio di autorizzazione versione 3 che include le condizioni. Per un esempio, consulta lo scenario 1 in questa pagina.

  • Se il criterio di autorizzazione contiene condizioni e l'utente che ha effettuato la chiamata ha richiesto un criterio di autorizzazione 1 o non ha specificato una versione, IAM restituisce un criterio 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, consulta lo scenario 2 in questa pagina.

Scenario 1: versione del criterio 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 il criterio di autorizzazione del progetto. Se il criterio di autorizzazione contiene almeno un'associazione di ruoli condizionale, 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 e non specifica un numero di versione. Di conseguenza, IAM utilizza la versione predefinita del criterio di autorizzazione,1.

Il criterio di autorizzazione contiene un'associazione di ruoli condizionale. Poiché la versione del criterio di autorizzazione è 1, la condizione non viene visualizzata nella 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
}

Specifica di una versione del criterio durante l'impostazione di un criterio

Quando imposti un criterio di autorizzazione, ti consigliamo di specificare una versione del criterio di autorizzazione nella richiesta. Quando una richiesta specifica una versione del criterio di autorizzazione, IAM presuppone che il chiamante sia a conoscenza delle funzionalità della versione del criterio di autorizzazione e che possa gestirle 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 della versione 1. Come best practice, non modificare le associazioni di ruoli condizionali in un criterio di autorizzazione 1 della versione; poiché il criterio di autorizzazione non mostra la condizione per ogni associazione di ruoli, non sai quando o dove viene effettivamente concessa l'associazione di ruoli. Recupera invece la rappresentazione della versione 3 del criterio allow, che mostra la condizione per ogni associazione di ruolo, e utilizza questa rappresentazione per aggiornare le associazioni di ruolo.

Scenario: versioni delle norme nelle richieste e nelle risposte

Supponiamo che tu utilizzi l'API REST per ottenere un criterio di autorizzazione e specifichi la versione3 nella richiesta. La risposta contiene il seguente regola del permesso, 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 se la richiesta ha specificato la versione 3, perché il criterio di autorizzazione utilizza solo i campi supportati in un criterio di autorizzazione della versione 1.

Norme con entità eliminate

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

Ad esempio, considera questo criterio di autorizzazione che include un'associazione di ruolo a un utente eliminato, donald@example.com, e a un account di servizio eliminato, my-service-account@project-id.iam.gserviceaccount.com. Di conseguenza, l' identificatore di 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
}

Supponiamo che tu crei un nuovo utente denominato anche donald@example.com e che tu voglia assegnare al nuovo utente il ruolo Autore progetto (roles/resourcemanager.projectCreator), che consente ai principali di creare progetti Google Cloud. Per concedere il ruolo al nuovo utente, aggiorna il criterio di autorizzazione come mostrato in questo 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 per le 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 Gruppi Google. 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 attentamente a quali agenti vengono assegnati i ruoli a livello di organizzazione. Per la maggior parte delle organizzazioni, solo alcuni team specifici, come i team di sicurezza e di rete, devono avere 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 in linea con le esigenze aziendali e operative. Ad esempio, una cartella principale potrebbe riflettere un reparto, una delle sue cartelle secondarie potrebbe riflettere l'accesso alle risorse e il funzionamento di un gruppo e un'altra cartella secondaria potrebbe riflettere un piccolo team. Entrambe le 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 i criteri di autorizzazione ereditati dalle cartelle principali e dall'organizzazione. Questa pratica richiede una minore manutenzione dei criteri di autorizzazione durante la creazione e la gestione delle risorse Google Cloud.

  • Ruoli concessi a livello di progetto: concedi le associazioni di ruoli a livello di progetto quando necessario per seguire il principio del privilegio minimo. Ad esempio, se un'entità deve accedere a 3 dei 10 progetti in una cartella, devi concedere l'accesso a ciascuno dei 3 progetti singolarmente. Al contrario, se concedi un ruolo alla cartella, l'entità acquisirà l'accesso a 7 progetti di cui non ha bisogno.

    In alternativa, puoi utilizzare le condizioni IAM per concedere i ruoli a livello di organizzazione o cartella, ma solo per un sottoinsieme di cartelle o progetti.

  • Concede l'accesso solo alle entità all'interno del tuo dominio: per migliorare la sicurezza della tua organizzazione, non concedere ruoli alle entità esterne al tuo dominio. Puoi applicare questa best practice applicando il iam.allowedPolicyMemberDomains vincolo dei criteri dell'organizzazione.

Passaggi successivi