Panoramica di IAM

Questa pagina descrive il funzionamento del sistema Identity and Access Management (IAM) di Cloud de Confiance by S3NS e 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

Ogni azione in Cloud de Confiance richiede determinate autorizzazioni. Quando qualcuno tenta di eseguire un'azione in Cloud de Confiancead 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 qualcuno 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 Cloud de Confiance risorsa a cui vuoi consentire l'accesso all' entità.

Per concedere all'entità l'autorizzazione ad accedere alla risorsa, devi assegnarle un ruolo sulla risorsa. Questi ruoli vengono concessi utilizzando una policy di autorizzazione.

Le policy di autorizzazione sono associate direttamente ad alcuri Cloud de Confiance risorse, che sono organizzate gerarchicamente. Ad esempio, i progetti contengono risorse specifiche del servizio. Ciò significa che puoi concedere l'accesso a una singola risorsa o a un container 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à che hanno eseguito l'autenticazione in Cloud de Confiance.

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

In IAM esistono vari tipi di entità, ma possono essere suddivisi in due categorie principali:

  • Utenti umani: alcuni tipi di entità IAM rappresentano utenti umani. Utilizza questi tipi di entità per gestire l'accesso dei dipendenti alle Cloud de Confiance risorse.

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

  • Carichi di lavoro: alcuni tipi di entità IAM rappresentano carichi di lavoro. Utilizza questi tipi di entità quando gestisci l'accesso dei carichi di lavoro alle Cloud de Confiance risorse.

    I tipi di entità che rappresentano i carichi di lavoro 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 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'entità. Puoi invece concedere le autorizzazioni alle entità assegnando loro dei ruoli.

I ruoli sono raccolte di autorizzazioni. Quando concedi un ruolo a un'entità, le concedi tutte le autorizzazioni incluse nel ruolo.

Esistono tre tipi di ruoli:

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

  • Ruoli personalizzati: ruoli creati che contengono solo le autorizzazioni che specifichi. Hai il controllo completo sulle autorizzazioni in questi ruoli. Tuttavia, hanno un carico di manutenzione maggiore rispetto ai ruoli predefiniti ed esiste un limite al numero di ruoli personalizzati che puoi avere nel tuo progetto e nella tua organizzazione.

  • Ruoli di base: ruoli altamente permissivi che forniscono un ampio accesso ai Cloud de Confiance servizi. Questi ruoli possono essere utili per i test, ma non devono essere utilizzati in ambienti di produzione.

Per saperne di più su ruoli e autorizzazioni, consulta Ruoli e autorizzazioni.

Risorse

La maggior parte dei Cloud de Confiance servizi ha le proprie risorse. Ad esempio, Compute Engine ha risorse come istanze, dischi e subnet.

In IAM, concedi i ruoli su una risorsa. Concedere a un'entità un ruolo su una risorsa significa che l'entità può utilizzare le autorizzazioni in quel 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 i ruoli, consulta Tipi di risorse che accettano le policy di autorizzazione.

Cloud de Confiance ha anche risorse container, tra cui progetti, cartelle e organizzazioni. Queste risorse container sono organizzate gerarchicamente, il che consente alle risorse secondarie di ereditare le policy delle risorse principali. Ciò significa che la concessione di un ruolo a un'entità su una risorsa container consente all'entità di accedere sia alla risorsa container sia alle risorse nel container. Questa funzionalità ti consente di utilizzare una singola concessione di ruolo per gestire l'accesso a più risorse, incluse le risorse su cui non puoi concedere direttamente i ruoli. Per saperne di più, consulta Ereditarietà delle policy in questa pagina.

Policy di autorizzazione

Concedi i ruoli alle entità utilizzando le policy di autorizzazione. In passato, queste policy venivano chiamate policy IAM.

Una policy di autorizzazione è un oggetto YAML o JSON associato a una Cloud de Confiance risorsa.

Ogni policy 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 vedere esempi di policy di autorizzazione e scoprire di più sulla loro struttura, consulta Informazioni sulle policy di autorizzazione.

Ereditarietà delle policy

Cloud de Confiance ha risorse container, come progetti, cartelle e organizzazioni, che ti consentono di organizzare le risorse in una gerarchia padre-figlio. Questa gerarchia è chiamata gerarchia delle risorse.

La Cloud de Confiance gerarchia delle risorse 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 Cloud de Confiance gerarchia delle risorse:

Gerarchia per le risorse IAM.

Se imposti una policy di autorizzazione su una risorsa container, la policy di autorizzazione si applica anche a tutte le risorse nel container. Questo concetto è chiamato ereditarietà delle policy, perché le risorse discendenti ereditano effettivamente le policy di autorizzazione delle risorse predecessori.

L'ereditarietà delle policy 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 in un container, concedile un ruolo sul container anziché sulle risorse nel container.

    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 a 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 loro predecessori. Per concedere a un'entità l'accesso a una risorsa che non può avere una propria policy di autorizzazione, concedile un ruolo su uno dei predecessori della risorsa.

    Ad esempio, supponiamo che tu voglia concedere a qualcuno l'autorizzazione a scrivere log in un bucket di log. I bucket di log non hanno policy di autorizzazione proprie, quindi per concedere questa autorizzazione puoi invece concedere il ruolo Writer 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 delle entità che hanno accesso alla risorsa, devi visualizzare la policy di autorizzazione della risorsa e le policy di autorizzazione dei predecessori della risorsa. L'unione di tutte queste policy è chiamata policy di autorizzazione effettiva.

Per saperne di più sull'ereditarietà delle policy per le policy di autorizzazione, consulta Utilizzare la gerarchia delle risorse per il controllo dell'accesso.

Controllo dell'accesso avanzato

Oltre alle policy 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 viene concesso loro un ruolo con l'autorizzazione. Per saperne di più sulle policy di negazione, consulta Policy di negazione.

  • Condizioni IAM: le condizioni IAM consentono di definire e applicare il controllo dell'accesso condizionale basato su attributi. Puoi utilizzare le condizioni in vari tipi di policy. Ad esempio, puoi aggiungere una condizione a un'associazione di ruoli in una policy 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 Panoramica delle condizioni IAM.

Modello di coerenza per l'API IAM

L'API IAM è coerente a livello di evento. In altre parole, se scrivi dati con l'API IAM e poi li leggi immediatamente, l'operazione di lettura potrebbe restituire una versione precedente dei dati. Inoltre, le modifiche apportate 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 poi fai immediatamente riferimento a questo service account in un'altra richiesta, l'API IAM potrebbe indicare che non è stato possibile trovare il account di servizio. Questo comportamento si verifica perché le operazioni sono coerenti a livello di evento; potrebbe essere necessario del tempo prima che il nuovo account di servizio diventi visibile alle richieste di lettura.

Passaggi successivi