Questa pagina è stata tradotta dall'API Cloud Translation.

Comprendi i criteri di autorizzazione

Puoi concedere l'accesso alle risorse Google Cloud utilizzando consentire i criteri, noti anche come criteri di Identity and Access Management (IAM), che sono collegati alle risorse. Puoi associare un solo criterio 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 il riga di comando Google Cloud per recuperare i criteri di autorizzazione in formato YAML.

Struttura dei criteri

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 binds, una o più entità con un singolo ruolo IAM e Qualsiasi condizione specifica del contesto che modifichi come e quando viene concesso il 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:

Una o più entità, anch'esse noti come membri o identità. Esistono diversi tipi di entità, tra cui account utente, account di servizio, gruppi Google e domini. Per un per l'elenco completo dei tipi di entità supportati, consulta Entità identificatori.
Un ruolo, ovvero una raccolta denominata di autorizzazioni che consente di eseguire azioni sulle risorse 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. 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 occorre del tempo per modificare l'accesso si propagano nel sistema. Per scoprire quanto tempo occorre in media per la propagazione delle modifiche di accesso, consulta Propagazione della modifica 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 apparizioni di ogni l'entità nelle associazioni di ruolo del criterio di autorizzazione, nonché le entità che il criterio di autorizzazione esclude dall'accesso ai dati log di controllo. 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:sample-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 insolitamente identificatori 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 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. 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 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 contemporaneità, che garantisce che consenta criteri vengono aggiornati con regolarità. Per maggiori dettagli, consulta Utilizzare gli ETag in un criterio in questa pagina.
Un campo version, che specifica la versione dello schema per una determinata 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ò contiene anche un campo auditConfig, che specifica i tipi di attività che generare 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.

Utilizzare gli 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 il rischio esiste perché i criteri di autorizzazione vengono aggiornati utilizzando il metodo read-modify-write , che comporta più operazioni:

Lettura del criterio di autorizzazione esistente
Modifica del criterio di autorizzazione
Scrittura dell'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, System A scrive le proprie modifiche al criterio di autorizzazione, Le modifiche di 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 è 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 da quando lo hai recuperato, 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 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. Tu dovrebbe eseguire nuovi tentativi automaticamente, con valori esponenziali il backoff, in tutti gli strumenti che usi 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 un numero quasi illimitato l'accesso.

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 organizzazioni, cartelle e progetti con limitazioni operazioni. 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 di ruoli condizionale

Considera il seguente criterio 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é il criterio di autorizzazione contiene un'espressione di condizione. L'associazione del ruolo nel criterio di autorizzazione è condizionale: concede il ruolo al gruppo Google prod-dev@example.com e all'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 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 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 ruoli ha una condizione che concede il ruolo solo fino al 1° luglio 2022.

Di fatto, questo criterio di autorizzazione assegna sempre il ruolo all'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. 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 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, 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, aggiungi il nuovo utente al criterio di autorizzazione di ruoli, come mostrato Criteri con entità eliminate su questo .

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

Criteri predefiniti

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, 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) sul progetto.

Poiché queste associazioni di ruoli vengono create dal sistema, l'utente non ha bisogno di autorizzazioni getIamPolicy o setIamPolicy sulla 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 eventualmente 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.

È importante considerare la gerarchia delle risorse quando si imposta un criterio di autorizzazione. Quando imposti un criterio di autorizzazione a un livello superiore della 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 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 di ruoli a qualsiasi livello del criterio di autorizzazione ereditato di una risorsa, l'ambito della concessione dell'accesso aumenta.

Esempio: ereditarietà dei criteri

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, 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 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 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 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 ottenere per tutti gli oggetti Cloud Storage in questa organizzazione.
Un criterio di autorizzazione a livello di progetto, per il progetto myproject-123, concede di creare oggetti all'interno del progetto.

La tabella seguente riassume le norme effettive di Raha:

Autorizzazioni concesse tramite "storage.objectViewer" ruolo a livello di organizzazione	Autorizzazioni concesse tramite "storage.objectCreator" ruolo in "myproject-123"	Ambito di sovvenzione effettivo per Raha nell'ambito di "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 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 il modo in cui 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. 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 schema di sintassi 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 Allow possono utilizzare le seguenti versioni:

Versione	Descrizione
`1`	La prima versione dello schema di sintassi IAM per i 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 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 un criterio di autorizzazione all'interno della 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 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 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, consulta lo scenario 1 in questa pagina.
Se il criterio di autorizzazione contiene condizioni e il chiamante ha richiesto una versione 1 criterio di autorizzazione o non specifica una versione, poi 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 condizione stessa non è presente. Per un esempio, vedi 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 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 version è impostato su 1, anche se la richiesta specificata 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

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 è vuoto; 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é il criterio di autorizzazione è 1, la condizione non viene visualizzata nel la risposta corretta. 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 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 versione1. Come best practice, non modificare le associazioni di ruoli condizionali in un criterio di autorizzazione 1 della versione 2.0; 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. 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 delle norme nelle richieste e nelle risposte

Supponi di usare l'API REST per ottenere un criterio di autorizzazione e di specificare la versione 3 nella richiesta. La risposta contiene quanto segue criterio di autorizzazione, che usa 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 a raha@example.com deve assegnare il ruolo Amministratore Storage (roles/storage.admin) nel corso della settimana, non solo nei giorni feriali. Rimuovi da te la condizione dall'associazione dei ruoli e invia una richiesta API REST per impostare criterio di autorizzazione; di nuovo, specifichi la versione 3 nel 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 1, perché il criterio di autorizzazione utilizza solo i campi supportati in un criterio di autorizzazione della versione 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 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, 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 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 relative alle norme

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

Quando gestisci più account utente con le stesse configurazioni di accesso, utilizza Google Gruppi. Inserisci ogni singolo account utente nel gruppo e assegnare i ruoli previsti al gruppo anziché ai singoli account utente.
Ruoli assegnati 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 ciascuna cartella può essere configurata con insiemi di accesso diversi di donazioni 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. 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 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 dei ruoli a livello di progetto a livello di progetto ove 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.

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 a comprendere e gestire i criteri 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 i criteri di autorizzazione effettivi.