Panoramica di IAM

Questa pagina descrive il funzionamento del sistema Identity and Access Management (IAM) di Google Cloude come puoi utilizzarlo per gestire l'accesso in Google Cloud.

IAM è uno strumento per gestire l'autorizzazione granulare per Google Cloud. In altre parole, ti consente di controllare chi può fare cosa su quali risorse.

Accesso in Google Cloud

Tutte le azioni in Google Cloud richiedono determinate autorizzazioni. Quando qualcuno tenta di eseguire un'azione in Google Cloud, ad esempio creare un'istanza VM o visualizzare un set di dati, IAM verifica innanzitutto se dispone delle autorizzazioni richieste. In caso contrario, IAM impedisce l'esecuzione dell'azione.

La concessione delle autorizzazioni in IAM comporta i seguenti tre componenti:

  • Entità: l'identità della persona o del sistema a cui vuoi concedere le autorizzazioni
  • Ruolo: la raccolta di autorizzazioni che vuoi concedere all'entità
  • Risorsa: la risorsa Google Cloud a cui vuoi consentire l'accesso all'entità

Per concedere all'entità l'autorizzazione ad accedere alla risorsa, le assegni il ruolo sulla risorsa. Concedi questi ruoli utilizzando un criterio di autorizzazione.

Le sezioni seguenti descrivono questi concetti in modo più dettagliato.

Entità

In Google Cloud controlli l'accesso per le entità. Le entità rappresentano una o più identità autenticate in Google Cloud.

In passato, le entità venivano chiamate membri. Alcune API utilizzano ancora questo termine.

In IAM esistono vari tipi di principal, ma possono essere suddivisi in due categorie generali:

  • Utenti umani: alcuni tipi di principal IAM rappresentano utenti umani. Utilizzi questi tipi di entità per gestire l'accesso dei tuoi dipendenti alle risorseGoogle Cloud .

    I tipi di entità che rappresentano utenti umani includono Account Google, gruppi Google e identità federate nei pool di identità della forza lavoro.

  • Workload: alcuni tipi di entità IAM rappresentano i workload. Utilizzi questi tipi di entità quando gestisci l'accesso delle risorse Google Cloud dei tuoi carichi di lavoro.

    I tipi di entità che rappresentano i workload includono service account e identità federate in un pool di identità per i workload.

Per ulteriori informazioni sulle entità, consulta Entità IAM.

Autorizzazioni e ruoli

Le autorizzazioni determinano quali operazioni sono consentite su una risorsa. In IAM, le autorizzazioni sono in genere rappresentate nel formato service.resource.verb. Spesso, le autorizzazioni corrispondono uno a uno ai metodi dell'API REST. Ad esempio, l'autorizzazione resourcemanager.projects.list consente di elencare i progetti Resource Manager.

Non puoi concedere direttamente le autorizzazioni a un principal. Assegni invece le autorizzazioni alle entità concedendo loro ruoli.

I ruoli sono raccolte di autorizzazioni. Se concedi un ruolo a un'entità, le concedi tutte le autorizzazioni incluse nel ruolo.

Esistono tre tipi di ruoli:

  • Ruoli predefiniti: ruoli gestiti dai servizi Google Cloud . Questi ruoli contengono le autorizzazioni necessarie per eseguire le attività comuni per ogni servizio specificato. Ad esempio, il ruolo Publisher Pub/Sub (roles/pubsub.publisher) fornisce l'accesso per pubblicare messaggi in un argomento Pub/Sub.

  • Ruoli personalizzati: ruoli che crei e che contengono solo le autorizzazioni che specifichi. Hai il controllo completo delle autorizzazioni in questi ruoli. Tuttavia, comportano un carico di manutenzione maggiore rispetto ai ruoli predefiniti e il numero di ruoli personalizzati che puoi avere nel tuo progetto e nella tua organizzazione è limitato.

  • Ruoli di base: ruoli altamente permissivi che forniscono un ampio accesso ai serviziGoogle Cloud . Questi ruoli possono essere utili per i test, ma non devono essere utilizzati negli ambienti di produzione.

Per ulteriori informazioni su ruoli e autorizzazioni, consulta Ruoli e autorizzazioni.

Risorse

La maggior parte dei servizi Google Cloud ha risorse proprie. Ad esempio, Compute Engine ha risorse come istanze, dischi e subnet.

In IAM, concedi ruoli a una risorsa. La concessione di un ruolo a un'entità per una risorsa significa che l'entità può utilizzare le autorizzazioni del ruolo per accedere alla risorsa.

Puoi concedere ruoli su un sottoinsieme di Google Cloud risorse. Per un elenco completo delle risorse su cui puoi concedere ruoli, consulta Tipi di risorse che accettano le policy di autorizzazione.

Google Cloud dispone anche di diverse risorse contenitore, tra cui progetti, cartelle e organizzazioni. Se concedi a un'entità un ruolo su una risorsa container, l'entità ha accesso alla risorsa container e alle risorse nel container. Questa funzionalità ti consente di utilizzare una singola concessione di ruolo per concedere a un'entità l'accesso a più risorse, incluse quelle a cui non puoi concedere ruoli direttamente. Per ulteriori informazioni, consulta la sezione Ereditarietà dei criteri di questa pagina.

Policy di autorizzazione

Concedi i ruoli alle entità utilizzando le policy di autorizzazione. In passato, questi criteri erano chiamati criteri IAM.

Un criterio di autorizzazione è un oggetto YAML o JSON collegato a una risorsa Google Cloud.

Il seguente diagramma mostra la struttura di un criterio di autorizzazione:

Una policy di autorizzazione con due associazioni di ruoli. Le associazioni di ruoli associano entità specifiche a ruoli specifici.

Ogni policy di autorizzazione contiene un elenco di associazioni di ruoli che associano i ruoli IAM alle entità a cui vengono concessi questi ruoli.

Quando un'entità autenticata tenta di accedere a una risorsa, IAM controlla la policy di autorizzazione della risorsa per determinare se l'entità dispone delle autorizzazioni richieste. Se l'entità si trova in un'associazione di ruoli che include un ruolo con le autorizzazioni richieste, può accedere alla risorsa.

Per visualizzare esempi di norme di autorizzazione e scoprire la loro struttura, consulta Informazioni sulle norme di autorizzazione.

Ereditarietà delle norme

Google Cloud dispone di risorse contenitore, come progetti, cartelle e organizzazioni, che ti consentono di organizzare le risorse in una gerarchia padre-figlio. Questa gerarchia è chiamata gerarchia delle risorse.

La gerarchia delle risorse Google Cloud ha la seguente struttura:

  • L'organizzazione è il nodo radice della gerarchia.
  • Le cartelle sono figli dell'organizzazione o di un'altra cartella.
  • I progetti sono figli dell'organizzazione o di una cartella.
  • Le risorse per ogni servizio sono discendenti dei progetti.

Il seguente diagramma è un esempio di gerarchia delle risorse Google Cloud :

Gerarchia delle risorse IAM.

Se imposti un criterio di autorizzazione su una risorsa contenitore, questo criterio si applica anche a tutte le risorse nel contenitore. Questo concetto è chiamato ereditarietà dei criteri, perché le risorse discendenti ereditano effettivamente i criteri di autorizzazione delle risorse antenate.

L'ereditarietà delle norme ha le seguenti implicazioni:

  • Puoi utilizzare un singolo binding del ruolo per concedere l'accesso a più risorse. Se vuoi concedere a un'entità l'accesso a tutte le risorse di un contenitore, concedi un ruolo per il contenitore anziché per le risorse al suo interno.

    Ad esempio, se vuoi consentire all'amministratore della sicurezza di gestire le policy di autorizzazione per tutte le risorse della tua organizzazione, puoi concedergli il ruolo Amministratore sicurezza (roles/iam.securityAdmin) nell'organizzazione.

  • Puoi concedere l'accesso alle risorse che non hanno policy di autorizzazione proprie. Non tutte le risorse accettano le policy di autorizzazione, ma tutte le risorse ereditano le policy di autorizzazione dai relativi antenati. Per concedere a un'entità l'accesso a una risorsa che non può avere criteri di autorizzazione propri, concedi un ruolo a uno degli antenati della risorsa.

    Ad esempio, supponiamo di voler concedere a qualcuno l'autorizzazione a scrivere log in un bucket di log. I bucket di log non hanno criteri di autorizzazione propri, quindi per concedere a qualcuno questa autorizzazione, puoi invece assegnargli il ruolo di scrittore del bucket di log (roles/logging.bucketWriter) nel progetto che contiene il bucket di log.

  • Per capire chi può accedere a una risorsa, devi visualizzare anche tutte le policy di autorizzazione che interessano la risorsa. Per ottenere un elenco completo dei principal che hanno accesso alla risorsa, devi visualizzare i criteri di autorizzazione della risorsa e i criteri di autorizzazione delle risorse predecessori. L'unione di tutte queste norme è chiamata norma di autorizzazione effettiva.

Per ulteriori informazioni sull'ereditarietà dei criteri per le policy di autorizzazione, consulta Utilizzare la gerarchia delle risorse per il controllo dell'accesso.

Controllo dell'accesso avanzato

Oltre ai criteri di autorizzazione, IAM fornisce i seguenti meccanismi di controllo dell'accesso per aiutarti a definire con precisione chi ha accesso a quali risorse:

  • Tipi di criteri aggiuntivi: IAM offre i seguenti tipi di criteri oltre a quelli di autorizzazione:

    • Policy di negazione: le policy di negazione impediscono alle entità di utilizzare determinate autorizzazioni, anche se è stato concesso loro un ruolo con l'autorizzazione.

    • Policy di Principal Access Boundary (PAB): le policy di Principal Access Boundary definiscono e applicano le risorse a cui un'entità può accedere. Le entità non possono accedere alle risorse a cui non hanno diritto di accedere, anche se è stato concesso loro un ruolo sulla risorsa.

    Per saperne di più su queste norme, consulta Tipi di norme.

  • Condizioni IAM: le condizioni IAM consentono di definire e applicare forzatamente il controllo dell'accesso condizionale basato su attributi. Puoi utilizzare le condizioni in vari tipi di criteri. Ad esempio, puoi aggiungere una condizione a un binding del ruolo in un criterio di autorizzazione per assicurarti che il ruolo venga concesso solo se la condizione è soddisfatta.

    Puoi scrivere condizioni basate su attributi come la risorsa nella richiesta e l'ora della richiesta.

    Per scoprire di più sulle condizioni IAM, consulta la panoramica delle condizioni IAM.

  • Gestore degli accessi con privilegi (PAM): con Privileged Access Manager, puoi consentire alle entità di richiedere e ottenere l'accesso temporaneo e controllabile alle risorse. Ad esempio, potresti richiedere che le entità richiedano l'accesso ogni volta che vogliono visualizzare una risorsa sensibile anziché concedere loro un ruolo IAM in modo permanente.

    Puoi anche configurare se i principal devono fornire giustificazioni o ottenere approvazioni quando richiedono l'accesso.

    Per scoprire di più su Privileged Access Manager, consulta la panoramica di Privileged Access Manager.

Modello di coerenza per l'API IAM

L'API IAM è alla fine coerente. In altre parole, se scrivi dati con l'API IAM e li leggi immediatamente, l'operazione di lettura potrebbe restituire una versione precedente dei dati. Inoltre, le modifiche apportate potrebbero richiedere del tempo prima di influire sui controlli di accesso.

Questo modello di coerenza influisce sul funzionamento dell'API IAM. Ad esempio, se crei un account di servizio e poi lo fai riferimento immediatamente in un'altra richiesta, l'API IAM potrebbe indicare che non è stato possibile trovare il account di servizio. Questo comportamento si verifica perché le operazioni sono alla fine coerenti; potrebbe essere necessario del tempo prima che il nuovoaccount di serviziot diventi visibile alle richieste di lettura.

Passaggi successivi

Provalo

Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $ di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

Inizia gratuitamente