Panoramica di IAM

Questa pagina descrive come funziona il sistema di 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.

Accedere in Google Cloud

Ogni azione in Google Cloud richiede determinate autorizzazioni. Quando un utente cerca di eseguire un'azione in Google Cloud, ad esempio creare un'istanza VM o visualizzare un set di dati, IAM controlla innanzitutto se l'utente possiede le autorizzazioni richieste. In caso contrario, IAM impedisce all'utente di eseguire l'azione.

L'assegnazione delle autorizzazioni a un utente in IAM prevede i seguenti tre componenti:

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

Per concedere all'entità l'autorizzazione ad accedere alla risorsa, devi concederle il ruolo per la risorsa. Puoi concedere questi ruoli utilizzando un criterio di autorizzazione.

Le sezioni seguenti descrivono questi concetti in maggiore dettaglio.

Entità

In Google Cloud puoi controllare l'accesso per le entità. Le entità rappresentano una o più identità che si sono autenticate in Google Cloud.

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

In IAM esistono diversi tipi di entità, ma possono essere suddivise in due ampie categorie:

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

    I tipi principali che rappresentano gli 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 le risorseGoogle Cloud di accesso dei tuoi carichi di lavoro.

    I tipi di entità che rappresentano i carichi di lavoro includono account di servizio e identità federate in un pool di identità per i carichi di lavoro.

Per ulteriori informazioni sulle entità, consulta Enti IAM.

Autorizzazioni e ruoli

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

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

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

Esistono tre tipi di ruoli:

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

  • Ruoli personalizzati: i ruoli che crei contengono solo le autorizzazioni che specifichi. Hai il controllo completo sulle autorizzazioni di questi ruoli. Tuttavia, hanno un carico di manutenzione più elevato rispetto ai ruoli predefiniti e il numero di ruoli personalizzati che puoi avere nel progetto e nell'organizzazione è limitato.

  • Ruoli di base: ruoli molto permissivi che forniscono accesso ampio ai Google Cloud servizi. Questi ruoli possono essere utili per scopi di 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 Google Cloud servizi ha le proprie risorse. Ad esempio, Compute Engine ha risorse come istanze, dischi e sottoreti.

In IAM, concedi i ruoli a una risorsa. Se concedi a un'entità un ruolo in una risorsa, l'entità può utilizzare le autorizzazioni del ruolo per accedere alla risorsa.

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

Google Cloud ha anche diverse risorse contenitore, tra cui progetti, cartelle e organizzazioni. La concessione di un ruolo a un'entità in una risorsa contenitore consente all'entità di accedere alla risorsa contenitore e alle risorse al suo interno. Questa funzionalità ti consente di utilizzare una singola concessione di ruolo per concedere a un entità accessi a più risorse, incluse quelle per le quali non puoi concedere direttamente i ruoli. Per ulteriori informazioni, consulta la sezione Eredità dei criteri in questa pagina.

Criteri di autorizzazione

Puoi concedere i ruoli alle entità utilizzando i criteri di autorizzazione. In passato, questi criteri erano chiamati criteri IAM.

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

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

Un criterio di autorizzazione con due associazioni di ruolo. 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.

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

Per vedere esempi di norme consentite e conoscere la loro struttura, consulta Informazioni sulle norme consentite.

Ereditarietà delle norme

Google Cloud ha 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 ha la seguente struttura: Google Cloud

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

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

Gerarchia per le risorse IAM.

Se imposti un criterio di autorizzazione su una risorsa contenitore, questo criterio viene applicato anche a tutte le risorse del contenitore. Questo concetto è chiamato eredita dei criteri, perché le risorse discendenti ereditano effettivamente i criteri di autorizzazione delle risorse ancestrali.

L'ereditarietà delle norme ha le seguenti implicazioni:

  • Puoi utilizzare una singola associazione di ruoli per concedere l'accesso a più risorse. Se vuoi concedere a un'entità l'accesso a tutte le risorse di un contenitore, concedile un ruolo per il contenitore anziché per le risorse al suo interno.

    Ad esempio, se vuoi consentire all'amministratore della sicurezza di gestire i criteri 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 dispongono di propri criteri di autorizzazione. Non tutte le risorse accettano i criteri di autorizzazione, ma tutte le risorse ereditano i criteri di autorizzazione dai rispettivi elementi precedenti. Per concedere a un'entità l'accesso a una risorsa che non può avere un proprio criterio di autorizzazione, concedi un ruolo a uno dei suoi antenati.

    Ad esempio, immagina di voler concedere a qualcuno l'autorizzazione per scrivere i log in un bucket di log. I bucket di log non hanno propri criteri di autorizzazione, quindi per assegnare a qualcuno questa autorizzazione, puoi concedere il ruolo Scrittore del bucket di log (roles/logging.bucketWriter) al progetto che contiene il bucket di log.

  • Per capire chi può accedere a una risorsa, devi visualizzare anche tutti i criteri di autorizzazione che interessano la risorsa. Per ottenere un elenco completo dei principali che hanno accesso alla risorsa, devi visualizzare il criterio di autorizzazione della risorsa e i criteri di autorizzazione dei suoi predecessori. L'unione di tutti questi criteri è chiamata criterio di autorizzazione effettivo.

Per ulteriori informazioni sull'eredità dei criteri per i criteri 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 perfezionare chi ha accesso a quali risorse:

  • Tipi di criteri aggiuntivi: oltre ai criteri di autorizzazione, IAM offre i seguenti tipi di criteri:

    • Criteri di negazione: i criteri di negazione impediscono alle entità di utilizzare determinate autorizzazioni, anche se a queste è stato assegnato un ruolo con l'autorizzazione.

    • Criteri di confine dell'accesso dell'entità (PAB): i criteri di confine dell'accesso dell'entità 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 loro concesso un ruolo per la risorsa.

    Per scoprire di più su queste norme, consulta la sezione 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'associazione di ruoli in un criterio di autorizzazione per assicurarti che il ruolo venga concesso solo se viene soddisfatta la condizione.

    Puoi scrivere condizioni in base ad attributi come la risorsa nella richiesta e l'ora della richiesta.

    Per scoprire 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 ricevere l'accesso temporaneo e verificabile alle risorse. Ad esempio, puoi 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 principali sono tenuti a fornire giustificazioni o a 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 è a coerenza finale. 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 fai subito riferimento a questo 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 infine coerenti. Potrebbe essere necessario del tempo prima che il nuovo service account 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