Panoramica di IAM

Questa pagina descrive come funziona il 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 di autorizzazioni a un utente 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 un ruolo nella risorsa. Concedi questi ruoli utilizzando un criterio di autorizzazione.

I criteri di autorizzazione sono collegati direttamente ad alcune risorse, che sono organizzate in modo gerarchico. Ad esempio, i progetti contengono risorse specifiche del servizio. Google Cloud Ciò significa che puoi concedere l'accesso a una singola risorsa o a un contenitore di risorse.

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 dei tuoi carichi di lavoro alle risorse Google Cloud .

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

Per saperne di più sulle entità, consulta Entità IAM.

Autorizzazioni e ruoli

Le autorizzazioni determinano le operazioni 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à, concedi a questa entità 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, richiedono 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 saperne di più 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 su una risorsa. Concedere a un'entità un ruolo su 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 risorse container, tra cui progetti, cartelle e organizzazioni. Queste risorse contenitore sono organizzate in modo gerarchico, il che consente alle risorse figlio di ereditare le policy delle risorse padre. Ciò significa che se concedi a un'entità un ruolo in una risorsa container, l'entità avrà accesso sia alla risorsa container che alle risorse nel container. Questa funzionalità ti consente di utilizzare una singola concessione di ruolo per gestire l'accesso a più risorse, incluse quelle su cui non puoi concedere ruoli direttamente. Per saperne di più, consulta Ereditarietà delle norme in questa pagina.

Policy di autorizzazione

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

Una policy di autorizzazione è un oggetto YAML o JSON collegato a una risorsa Google Cloud.

Il seguente diagramma mostra la struttura di una policy di autorizzazione:

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

Ogni criterio 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 policy

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 viene applicato anche a tutte le risorse nel contenitore. Questo concetto è chiamato ereditarietà delle policy, perché le risorse discendenti ereditano effettivamente le policy di autorizzazione delle risorse antenate.

L'ereditarietà delle policy 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 proprie policy di autorizzazione. 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 un proprio criterio di autorizzazione, 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 concedergli il ruolo Logs Bucket Writer (roles/logging.bucketWriter) nel progetto che contiene il bucket di log.

  • Per capire chi può accedere a una risorsa, devi anche visualizzare 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 saperne di più sull'ereditarietà delle policy per le policy di autorizzazione, consulta Utilizzo della 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 sono idonee, anche se è stato concesso loro un ruolo sulla risorsa.

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

  • Condizioni IAM: le condizioni IAM ti consentono di definire e applicare 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'associazione di 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 saperne di più sulle condizioni IAM, consulta la panoramica delle condizioni IAM.

  • Privileged Access Manager (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 in modo permanente un ruolo IAM.

    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. Potrebbe essere necessario del tempo prima che le modifiche apportate influiscano 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 il account di servizio non è stato trovato. 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