Panoramica di IAM

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

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

Accesso in Trusted Cloud

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

    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 delle risorse Trusted 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à del 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 Trusted 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 serviziTrusted 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 Trusted Cloud ha risorse proprie. Ad esempio, Compute Engine ha risorse come istanze, dischi e subnet.

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

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

Trusted Cloud dispone anche di diverse risorse contenitore, tra cui progetti, cartelle e organizzazioni. Se concedi a un'entità un ruolo in una risorsa contenitore, l'entità ha accesso sia alla risorsa contenitore che alle risorse in quel contenitore. Questa funzionalità ti consente di utilizzare una singola concessione di ruolo per concedere a un principal l'accesso a più risorse, incluse quelle su cui non puoi concedere ruoli direttamente. Per ulteriori informazioni, consulta Ereditarietà dei criteri in 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 Trusted Cloud.

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

Trusted 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 Trusted 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 Trusted 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à delle policy, perché le risorse discendenti ereditano effettivamente le policy 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à 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 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 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.

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