Panoramica di IAM

Questa pagina descrive come funziona il sistema Identity and Access Management (IAM) di Cloud de Confiance by S3NSe come puoi utilizzarlo per gestire l'accesso in Cloud de Confiance.

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

Accesso in Cloud de Confiance

Tutte le azioni in Cloud de Confiance richiedono determinate autorizzazioni. Quando qualcuno tenta di eseguire un'azione in Cloud de Confiance, 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 Cloud de Confiance 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. Cloud de Confiance 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 Cloud de Confiance controlli l'accesso per le entità. Le entità rappresentano una o più identità autenticate in Cloud de Confiance.

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 risorseCloud de Confiance .

    Ad esempio, le identità federate nei pool di identità della forza lavoro rappresentano utenti umani.

  • 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 Cloud de Confiance .

    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 Cloud de Confiance . 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 serviziCloud de Confiance . 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 Cloud de Confiance 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 Cloud de Confiance risorse. Per un elenco completo delle risorse su cui puoi concedere ruoli, consulta Tipi di risorse che accettano le policy di autorizzazione.

Cloud de Confiance 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 Cloud de Confiance.

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

Cloud de Confiance 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 Cloud de Confiance 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 Cloud de Confiance :

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:

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

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

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