Panoramica di IAM

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

In questa pagina viene descritto il funzionamento del sistema di gestione di identità e accessi (IAM) di Google Cloud e come puoi utilizzarlo per gestire l'accesso in Google Cloud.

IAM ti consente di concedere l'accesso granulare a determinate risorse Google Cloud e aiuta a impedire l'accesso ad altre risorse. IAM consente di adottare il principio di sicurezza del privilegio minimo, che prevede che nessuno debba avere più autorizzazioni di quante effettivamente necessarie.

Come funziona IAM

Con IAM puoi gestire il controllo dell'accesso definendo chi (identità) ha quale accesso (ruolo) per quale risorsa. Ad esempio, le istanze VM di Compute Engine, i cluster Google Kubernetes Engine (GKE) e i bucket Cloud Storage sono tutte risorse di Google Cloud. Sono organizzazioni anche le organizzazioni, le cartelle e i progetti che utilizzi per organizzare le tue risorse.

In IAM, l'autorizzazione ad accedere a una risorsa non viene concessa direttamente all'utente finale. Le autorizzazioni sono invece raggruppate in ruoli e i ruoli vengono concessi ai principi autenticati. In passato, IAM spesso si riferisce alle entità come membri. Alcune API utilizzano ancora questo termine.

Un criterio di autorizzazione, noto anche come criterio IAM, definisce e applica i ruoli concessi a quali entità. Ogni criterio di autorizzazione è associato a una risorsa. Quando un'entità autenticata tenta di accedere a una risorsa, IAM controlla il criterio di autorizzazione della risorsa per determinare se l'azione è consentita.

Il seguente diagramma illustra la gestione delle autorizzazioni in IAM.

Un criterio di autorizzazione con due associazioni di ruolo. Le associazioni di ruoli associano membri specifici a ruoli specifici.

Questo modello per la gestione degli accessi è costituito da tre parti principali:

  • Entità. Un entità può essere un Account Google (per utenti finali), un account di servizio (per applicazioni e carichi di lavoro di calcolo), un gruppo Google o un account Google Workspace o un dominio Cloud Identity che può accedere a una risorsa. Ogni entità ha il proprio identificatore, che in genere è un indirizzo email.
  • Ruolo. Un ruolo è un insieme di autorizzazioni. Le autorizzazioni determinano quali operazioni sono consentite su una risorsa. Quando concedi un ruolo a un amministratore, concedi tutte le autorizzazioni che contiene.
  • Norme. Il criterio consentito è una raccolta di associazioni di ruoli che vincolano una o più entità a singoli ruoli. Quando vuoi definire chi (entità) ha il tipo di accesso (ruolo) di una risorsa, puoi creare un criterio di autorizzazione e collegarlo alla risorsa.

Nel diagramma precedente, ad esempio, il criterio di autorizzazione associa entità, ad esempio user@example.com, a ruoli come il ruolo Amministratore di App Engine (roles/appengine.appAdmin). Se il criterio di autorizzazione è associato a un progetto, i entità ottengono i ruoli specificati all'interno del progetto.

Il resto della pagina descrive questi concetti in modo più dettagliato.

In IAM, puoi concedere l'accesso ai entità. Le entità possono essere dei seguenti tipi:

  • Account Google
  • Account di servizio
  • gruppo Google
  • Account Google Workspace
  • Dominio Cloud Identity
  • Tutti gli utenti autenticati
  • Tutti gli utenti

Account Google

Un Account Google rappresenta uno sviluppatore, un amministratore o un'altra persona che interagisce con Google Cloud. Qualsiasi indirizzo email associato a un Account Google può essere un'identità, incluso gmail.com o altri domini. I nuovi utenti possono creare un Account Google tramite la pagina di registrazione dell'Account Google.

Account di servizio

Un account di servizio è l'account di un'applicazione o di un carico di lavoro di calcolo anziché di un singolo utente finale. Quando esegui il codice ospitato su Google Cloud, il codice viene eseguito con l'account specificato. Puoi creare tutti gli account di servizio necessari per rappresentare i diversi componenti logici della tua applicazione. Per ulteriori informazioni sull'utilizzo di un account di servizio nell'applicazione, consulta la guida introduttiva all'autenticazione.

gruppo Google

Un gruppo Google è una raccolta denominata di Account Google e account di servizio. Ogni gruppo Google ha un indirizzo email univoco associato al gruppo. Puoi trovare l'indirizzo email associato a un gruppo Google facendo clic su Informazioni nella home page di qualsiasi gruppo Google. Per scoprire di più su Google Gruppi, consulta la home page di Google Gruppi.

Google Gruppi consente di applicare facilmente i controlli dell'accesso a un insieme di utenti. Puoi modificare e concedere i controlli di accesso a un intero gruppo contemporaneamente anziché modificarli singolarmente per singoli utenti o account di servizio. Puoi anche aggiungere facilmente entità e rimuovere i entità da un gruppo Google anziché aggiornare un criterio di autorizzazione per aggiungere o rimuovere utenti.

I gruppi Google non hanno credenziali di accesso e non puoi utilizzare Google Gruppi per stabilire l'identità per effettuare una richiesta di accesso a una risorsa.

Account Google Workspace

Un account Google Workspace rappresenta un gruppo virtuale di tutti gli Account Google che contiene. Gli account Google Workspace sono associati al nome di dominio Internet della tua organizzazione, ad esempio example.com. Quando crei un Account Google per un nuovo utente, ad esempio username@example.com, tale Account Google viene aggiunto al gruppo virtuale per il tuo account Google Workspace.

Come Google Gruppi, gli account Google Workspace non possono essere utilizzati per definire l'identità, ma consentono una comoda gestione delle autorizzazioni.

Dominio Cloud Identity

Un dominio Cloud Identity è come un account Google Workspace, perché rappresenta un gruppo virtuale di tutti gli Account Google di un'organizzazione. Tuttavia, gli utenti del dominio Cloud Identity non hanno accesso alle applicazioni e alle funzionalità di Google Workspace. Per ulteriori informazioni, consulta Informazioni su Cloud Identity.

Tutti gli utenti autenticati

Il valore allAuthenticatedUsers è un identificatore speciale che rappresenta tutti gli account di servizio e tutti gli utenti su Internet che si sono autenticati con un Account Google. Questo identificatore include account non collegati a un account Google Workspace o a un dominio Cloud Identity, ad esempio account Gmail personali. Gli utenti che non sono autenticati, come i visitatori anonimi, non sono inclusi.

Questo tipo di entità non include identità provenienti da provider di identità esterni (IdP). Se utilizzi la federazione delle identità con forza lavoro o la federazione delle identità con carico di lavoro, non utilizzare allAuthenticatedUsers. Utilizza invece uno dei seguenti elementi:

Alcuni tipi di risorse non supportano questo tipo di entità.

Tutti gli utenti

Il valore allUsers è un identificatore speciale che rappresenta chiunque si trovi su Internet, inclusi gli utenti autenticati e non autenticati.

Alcuni tipi di risorse non supportano questo tipo di entità.

Quando un'entità autenticata tenta di accedere a una risorsa, IAM controlla il criterio di autorizzazione della risorsa per determinare se l'azione è consentita.

Questa sezione descrive le entità e i concetti coinvolti nel processo di autorizzazione.

Risorsa

Se un utente ha bisogno di accedere a una specifica risorsa di Google Cloud, puoi assegnargli un ruolo per quella risorsa. Alcuni esempi di risorse sono: progetti, istanze di Compute Engine e bucket di Cloud Storage.

Alcuni servizi supportano la concessione delle autorizzazioni IAM a una granularità maggiore rispetto al livello di progetto. Ad esempio, puoi concedere il ruolo Amministratore Storage (roles/storage.admin) a un utente per un determinato bucket Cloud Storage oppure puoi concedere il ruolo Amministratore istanze Compute (roles/compute.instanceAdmin) a un utente per una specifica istanza Compute Engine.

In altri casi, puoi concedere le autorizzazioni IAM a livello di progetto. Le autorizzazioni vengono poi ereditate da tutte le risorse all'interno di quel progetto. Ad esempio, per concedere l'accesso a tutti i bucket Cloud Storage in un progetto, concedi l'accesso al progetto anziché a ogni singolo bucket. Oppure, per concedere l'accesso a tutte le istanze di Compute Engine in un progetto, concedi l'accesso al progetto anziché a ogni singola istanza.

Per informazioni sui ruoli che possono essere concessi sulle risorse, consulta la pagina Informazioni sui ruoli e consulta la colonna Risorsa più bassa per un determinato ruolo.

Autorizzazioni

Le autorizzazioni determinano quali operazioni sono consentite su una risorsa. Nel mondo IAM, le autorizzazioni sono rappresentate nel formato service.resource.verb, ad esempio pubsub.subscriptions.consume.

Spesso le autorizzazioni corrispondono a one-to-one con i metodi dell'API REST. In altre parole, a ogni servizio Google Cloud è associato un set di autorizzazioni per ogni metodo dell'API REST esposto. Il chiamante di quel metodo deve disporre di tali autorizzazioni per chiamare il metodo. Ad esempio, se utilizzi Pub/Sub e devi chiamare il metodo topics.publish(), devi avere l'autorizzazione pubsub.topics.publish per quell'argomento.

Non concedi le autorizzazioni direttamente agli utenti. Dovrai invece identificare i ruoli che contengono le autorizzazioni appropriate e concedere tali ruoli all'utente. Per un elenco di tutte le autorizzazioni disponibili e i ruoli che le contengono, consulta il riferimento sulle autorizzazioni.

Ruoli

Un ruolo è una raccolta di autorizzazioni. Non puoi concedere direttamente l'autorizzazione all'utente. Concedi loro un ruolo. Quando concedi un ruolo a un utente, gli concedi tutte le autorizzazioni che contiene.

Autorizzazione per la mappatura dei ruoli.

Esistono diversi tipi di ruoli in IAM:

  • Ruoli di base: ruoli storicamente disponibili in Google Cloud Console. Questi ruoli sono Proprietario, Editor e Visualizzatore.

  • Ruoli predefiniti: ruoli che offrono un controllo dell'accesso più granulare rispetto ai ruoli di base. Ad esempio, il ruolo predefinito Pub/Sub Publisher (roles/pubsub.publisher) fornisce l'accesso per pubblicare solo messaggi in un argomento Pub/Sub.

  • Ruoli personalizzati: ruoli che crei per personalizzare le autorizzazioni in base alle esigenze della tua organizzazione quando i ruoli predefiniti non soddisfano le tue esigenze.

Per ulteriori informazioni sui ruoli, consulta le seguenti risorse:

Consenti criterio

Puoi concedere ruoli agli utenti creando un criterio di autorizzazione, ovvero una raccolta di istruzioni che definiscono chi dispone di un determinato tipo di accesso. Un criterio di autorizzazione viene associato a una risorsa e viene usato per applicare il controllo dell'accesso per ogni accesso alla risorsa.

criterio IAM

Un criterio di autorizzazione è un elenco di associazioni di ruoli. Un'associazione di ruoli associa un elenco di entità a un ruolo.

  • role: il ruolo che vuoi concedere all'entità. role è specificato sotto forma di roles/service.roleName. Ad esempio, Cloud Storage fornisce i ruoli roles/storage.objectAdmin, roles/storage.objectCreator e roles/storage.objectViewer, tra gli altri.

  • members: elenco di una o più entità, come descritto nella sezione Concetti relativi all'identità in questo documento. Ogni tipo di entità è identificato con un prefisso, ad esempio un Account Google (user:), un account di servizio (serviceAccount:), un gruppo Google (group:) o un account Google Workspace o un dominio Cloud Identity (domain:). Nello snippet di codice di esempio riportato di seguito, il ruolo storage.objectAdmin viene concesso ai seguenti utenti utilizzando il prefisso appropriato: user:ali@example.com, serviceAccount:my-other-app@appspot.gserviceaccount.com, group:admins@example.com e domain:google.com. Il ruolo objectViewer viene concesso a user:maria@example.com.

Il seguente snippet di codice mostra la struttura di un criterio di autorizzazione.

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
       "members": [
         "user:ali@example.com",
         "serviceAccount:my-other-app@appspot.gserviceaccount.com",
         "group:admins@example.com",
         "domain:google.com"
       ]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:maria@example.com"
      ]
    }
  ]
}

API di criteri e IAM

IAM offre una serie di metodi che puoi utilizzare per creare e gestire criteri di autorizzazione per le risorse Google Cloud. Questi metodi vengono esposti dai servizi che supportano IAM. Ad esempio, i metodi IAM sono esposti dalle API Resource Manager, Pub/Sub e Cloud Life Sciences, solo per citarne alcuni.

I metodi IAM sono:

  • setIamPolicy(): gli insiemi di criteri consentono le risorse.
  • getIamPolicy(): riceve un criterio di autorizzazione precedentemente impostato.
  • testIamPermissions(): verifica se il chiamante dispone delle autorizzazioni specificate per una risorsa.

Puoi trovare gli argomenti di riferimento delle API per questi metodi nella documentazione di ciascun servizio che supporta IAM.

Gerarchia delle risorse

Le risorse Google Cloud sono organizzate in modo gerarchico:

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

Ogni risorsa ha un solo elemento padre. Per ulteriori informazioni, consulta la gerarchia delle risorse di Resource Manager.

Il seguente diagramma è un esempio di gerarchia di risorse di Google Cloud.

Gerarchia delle risorse IAM.

Puoi impostare un criterio di autorizzazione a qualsiasi livello della gerarchia delle risorse: a livello di organizzazione, di cartella, di progetto o di risorsa. Le risorse ereditano i criteri di autorizzazione di tutte le risorse padre. Il criterio di autorizzazione effettivo per una risorsa è dato dall'unione del criterio di autorizzazione impostato per quella risorsa con i criteri di autorizzazione ereditati dal livello più alto della gerarchia.

L'ereditarietà di questo criterio è transitiva, ovvero le risorse ereditano i criteri di autorizzazione dal progetto, che ereditano i criteri di autorizzazione dalle cartelle, che ereditano i criteri di autorizzazione dall'organizzazione. Di conseguenza, i criteri di autorizzazione a livello di organizzazione si applicano anche a livello di risorsa.

Ad esempio: nel diagramma precedente, topic_a è una risorsa Pub/Sub che si trova nel progetto example-prod. Se concedi il ruolo Editor a micah@example.com per example-prod e il ruolo Publisher a song@example.com per topic_a, concedi di fatto il ruolo Editor per topic_a a micah@example.com e il ruolo Publisher a canto@example.com.

I criteri di autorizzazione per le risorse figlio ereditano dai criteri di autorizzazione per le risorse principali. Ad esempio, se concedi il ruolo Editor a un utente per un progetto e concedi il ruolo Visualizzatore allo stesso utente per una risorsa secondaria, l'utente continuerà ad avere la concessione del ruolo Editor per la risorsa secondaria. Se modifichi la gerarchia delle risorse, cambia anche l'ereditarietà dei criteri. Ad esempio, lo spostamento di un progetto in un'organizzazione fa sì che il progetto erediti dal criterio di autorizzazione dell'organizzazione.

Supporto IAM per i servizi Google Cloud

Con IAM, ogni metodo API in tutti i servizi Google Cloud viene controllato per garantire che l'account che esegue la richiesta API disponga dell'autorizzazione appropriata per utilizzare la risorsa.

I servizi Google Cloud offrono ruoli predefiniti che forniscono un controllo dell'accesso granulare. Ad esempio, Compute Engine offre ruoli come Amministratore di istanze Compute e Amministratore di rete Compute, mentre App Engine offre ruoli come Amministratore di App Engine e Amministratore di servizio App Engine.

I ruoli predefiniti sono disponibili per la maggior parte dei servizi Google Cloud. Per i dettagli, consulta l'elenco di tutti i ruoli predefiniti. Se hai bisogno di un controllo ancora maggiore sulle autorizzazioni, valuta la possibilità di creare un ruolo personalizzato.

Puoi concedere agli utenti determinati ruoli per accedere alle risorse in modo granulare a livello di progetto. Ad esempio, puoi creare un criterio di autorizzazione che conceda a un utente il ruolo Sottoscrittore per un determinato argomento Pub/Sub. L'elenco di tutti i ruoli predefiniti mostra il tipo di risorsa di livello più basso, o più granulare, che accetta ogni ruolo.

Modello di coerenza per l'API IAM

L'API IAM è definitivamente coerente. In altre parole, se scrivi i dati con l'API IAM e leggi immediatamente i dati, l'operazione di lettura potrebbe restituire una versione precedente dei dati. Inoltre, le modifiche che apporti potrebbero richiedere del tempo per influire sui controlli di accesso.

Questo modello di coerenza influisce sul funzionamento dell'API IAM. Ad esempio, se crei un account di servizio e fai immediatamente riferimento all'account di servizio in un'altra richiesta, l'API IAM potrebbe indicare che l'account di servizio non è stato trovato. Questo comportamento si verifica perché le operazioni sono a coerenza finale, in quanto il nuovo account di servizio può diventare visibile per le 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