Identity and Access Management (IAM) offre diversi tipi di policy per aiutarti a controllare a quali risorse possono accedere le entità. Questa pagina ti aiuta a capire le differenze tra il modo in cui utilizzi e gestisci questi tipi di policy.
Tipi di criteri IAM in Google Cloud
IAM offre i seguenti tipi di criteri:
- Policy di autorizzazione
- Policy di negazione
- Policy di Principal Access Boundary (PAB)
- Criteri di accesso
La seguente tabella riassume le differenze tra questi tipi di norme:
| Norme | Funzione del criterio | API utilizzata per gestire la policy | Relazione tra policy e destinazioni | Metodo di collegamento delle policy alla destinazione | Risorsa padre del criterio |
|---|---|---|---|---|---|
| Policy di autorizzazione | Concedere alle entità l'accesso alle risorse | L'API per la risorsa per cui vuoi gestire le policy di autorizzazione |
Relazione one-to-one Ogni criterio di autorizzazione è associato a una risorsa; ogni risorsa può avere un solo criterio di autorizzazione |
Specifica la risorsa durante la creazione della policy | Uguale alla risorsa a cui è collegata la policy di autorizzazione |
| Policy di negazione | Assicurati che le entità non possano utilizzare autorizzazioni specifiche | L'API IAM v2 |
Relazione one-to-many Ogni policy di negazione è associata a una risorsa; ogni risorsa può avere fino a 500 policy di negazione |
Specifica la risorsa durante la creazione della policy di negazione | Uguale alla risorsa a cui è associata la policy di negazione |
| Policy PAB | Limitare le risorse a cui un'entità può accedere | API IAM v3 |
Relazione many-to-many Ogni criterio PAB può essere associato a un numero illimitato di set di entità; ogni set di entità può avere fino a 10 criteri PAB associati |
Crea un'associazione di policy che colleghi la policy PAB a un set di entità | L'organizzazione |
| Criteri di accesso | Concedere o negare alle entità l'accesso alle risorse per i servizi supportati | API IAM v3 |
Relazione many-to-many Ogni criterio di accesso può essere collegato a un massimo di 5 risorse; ogni risorsa può avere fino a 5 criteri di accesso associati. |
Crea un'associazione di policy di accesso che colleghi la policy di accesso alla risorsa | Il progetto, la cartella o l'organizzazione in cui viene creata la policy di accesso |
Le sezioni seguenti forniscono dettagli su ciascun tipo di norma.
Policy per concedere l'accesso alle entità
Per concedere alle entità l'accesso alle risorse, utilizza una delle seguenti policy:
- Utilizza le policy di autorizzazione per concedere l'accesso a qualsiasi tipo di risorsa.
- Utilizza le policy di accesso per concedere l'accesso alle risorse Eventarc.
Le policy di autorizzazione ti consentono di concedere l'accesso alle risorse in Google Cloud. Le policy di autorizzazione sono costituite da associazioni di ruoli e metadati. Le associazioni di ruoli specificano quali entità devono avere un determinato ruolo nella risorsa.
Le policy di autorizzazione sono sempre associate a una singola risorsa. Dopo aver collegato una policy di autorizzazione a una risorsa, la policy viene ereditata dai discendenti della risorsa.
Per creare e applicare una policy di autorizzazione, identifica una risorsa che accetta le policy di autorizzazione, quindi utilizza il metodo setIamPolicy di questa risorsa per creare la policy di autorizzazione. A tutte le entità nel criterio allow
vengono concessi i ruoli specificati per la risorsa e tutti i relativi
discendenti. A ogni risorsa può essere associata una sola policy di autorizzazione.
Per saperne di più sulle policy di autorizzazione, consulta Informazioni sulle policy di autorizzazione.
I criteri di accesso ti consentono di controllare l'accesso alle risorse Eventarc. Le policy di accesso possono consentire e negare l'accesso alle risorse. Per creare e applicare una policy di accesso, crea una policy di accesso e poi crea un'associazione di policy per connettere la policy a un progetto con risorse Eventarc.Ogni binding dei criteri associa un criterio di accesso a una risorsa. Un criterio di accesso può essere associato a un massimo di 5 risorse. A ogni risorsa possono essere associate fino a 5 policy di accesso. Quando viene eliminata una policy di accesso, vengono eliminate anche tutte le associazioni di policy correlate.
Per scoprire di più sull'utilizzo delle policy di accesso per controllare l'accesso alle risorse Eventarc, consulta la documentazione di Eventarc.
Policy per negare l'accesso alle entità
Per negare l'accesso alle risorse alle entità, utilizza uno dei seguenti metodi:
- Utilizza le policy di negazione per negare l'accesso a qualsiasi tipo di risorsa.
- Utilizza le policy di accesso per negare l'accesso alle risorse Eventarc.
I criteri di negazione, come i criteri di autorizzazione, sono sempre associati a una singola risorsa. Puoi collegare un criterio di negazione a un progetto, una cartella o un'organizzazione. Questo progetto, cartella o organizzazione funge anche da elemento padre del criterio nella gerarchia delle risorse. Dopo aver collegato una policy di negazione a una risorsa, la policy viene ereditata dai discendenti della risorsa.
Per creare e applicare policy di negazione, utilizza l'API IAM v2. Quando crei una policy di negazione, specifichi la risorsa a cui è associata. Tutte le entità nel criterio di negazione non possono utilizzare le autorizzazioni specificate per accedere a quella risorsa e a tutti i relativi discendenti. A ogni risorsa possono essere associati fino a 500 criteri di negazione.
Per saperne di più sulle policy di negazione, consulta Policy di negazione.
I criteri di accesso ti consentono di controllare l'accesso alle risorse Eventarc. Le policy di accesso possono consentire e negare l'accesso alle risorse. Per creare e applicare una policy di accesso, crea una policy di accesso e poi crea un'associazione di policy per connettere la policy a un progetto con risorse Eventarc.Ogni binding dei criteri associa un criterio di accesso a una risorsa. Un criterio di accesso può essere associato a un massimo di 5 risorse. A ogni risorsa possono essere associate fino a 5 policy di accesso. Quando viene eliminata una policy di accesso, vengono eliminate anche tutte le associazioni di policy correlate.
Per scoprire di più sull'utilizzo delle policy di accesso per controllare l'accesso alle risorse Eventarc, consulta la documentazione di Eventarc.
Policy per limitare le risorse a cui un'entità può accedere
Per limitare le risorse a cui un'entità può accedere, utilizza un criterio di Principal Access Boundary. Le policy di Principal Access Boundary sono disponibili nell'API IAM v3.
Per creare e applicare una policy di Principal Access Boundary, crea una policy di Principal Access Boundary e poi crea un'associazione di policy per connettere la policy a un insieme di entità.
Le policy di Principal Access Boundary sono sempre unità secondarie della tua organizzazione. Le associazioni di criteri per le policy di Principal Access Boundary sono elementi secondari del progetto, della cartella o dell'organizzazione più vicini all'insieme di entità a cui viene fatto riferimento nell'associazione di criteri.
Ogni associazione di policy associa una policy di Principal Access Boundary a un set di entità. Un criterio di Principal Access Boundary può essere associato a un numero qualsiasi di insiemi di entità. A ogni insieme di entità possono essere associate fino a 10 policy di Principal Access Boundary. Quando viene eliminata una policy di Principal Access Boundary, vengono eliminate anche tutte le associazioni di policy correlate.
Per saperne di più sulle policy di Principal Access Boundary, consulta Policy di Principal Access Boundary.
Valutazione delle norme
Quando un'entità tenta di accedere a una risorsa, IAM valuta tutte le policy di autorizzazione, di negazione e di Principal Access Boundary pertinenti per verificare se l'entità è autorizzata ad accedere alla risorsa. Se una qualsiasi di queste policy indica che l'entità non deve essere in grado di accedere alla risorsa, IAM impedisce l'accesso.
In realtà, IAM valuta tutti i tipi di policy contemporaneamente, poi compila i risultati per determinare se l'entità può accedere alla risorsa. Tuttavia, può essere utile pensare a questa valutazione delle norme che si svolge nelle seguenti fasi:
-
IAM controlla tutte le policy di Principal Access Boundary pertinenti per verificare se l'entità è idonea ad accedere alla risorsa. Una policy di Principal Access Boundary è pertinente se sono vere le seguenti condizioni:
- Il criterio è associato a un set di entità che include l'entità
- Il criterio di Principal Access Boundary blocca l'autorizzazione che l'entità sta tentando di utilizzare. Le autorizzazioni bloccate da un criterio di Principal Access Boundary dipendono dalla versione del criterio di Principal Access Boundary. Specifichi la versione della policy quando crei la policy di Principal Access Boundary. Per saperne di più, consulta Versioni delle policy di Principal Access Boundary.
Dopo aver controllato le policy di Principal Access Boundary pertinenti, IAM esegue una delle seguenti operazioni:
- Se le policy di Principal Access Boundary pertinenti non includono la risorsa a cui l'entità sta tentando di accedere o se IAM non può valutare le policy di Principal Access Boundary pertinenti, allora IAM impedisce l'accesso alla risorsa.
- Se le policy di Principal Access Boundary pertinenti includono la risorsa a cui l'entità sta tentando di accedere, IAM continua con il passaggio successivo.
- Se non sono presenti policy di Principal Access Boundary pertinenti, IAM continua con il passaggio successivo.
-
IAM controlla tutti i criteri di rifiuto pertinenti per verificare se all'entità è stata negata l'autorizzazione. Le policy di negazione pertinenti sono le policy di negazione associate alla risorsa, nonché tutte le policy di negazione ereditate.
- Se uno qualsiasi di questi criteri di negazione impedisce all'entità di utilizzare un'autorizzazione richiesta, IAM le impedisce di accedere alla risorsa.
- Se nessuna policy di negazione impedisce all'entità di utilizzare un'autorizzazione richiesta, IAM continua con il passaggio successivo.
-
IAM controlla tutte le policy di autorizzazione pertinenti per verificare se l'entità dispone delle autorizzazioni richieste. I criteri di autorizzazione pertinenti sono quelli associati alla risorsa, nonché quelli ereditati.
- Se l'entità non dispone delle autorizzazioni richieste, IAM le impedisce di accedere alla risorsa.
- Se l'entità dispone delle autorizzazioni richieste, IAM le consente di accedere alla risorsa.
Il seguente diagramma mostra questo flusso di valutazione dei criteri:
Passaggi successivi
- Scopri di più sulle norme di autorizzazione.
- Scopri di più sui criteri di negazione.
- Scopri di più sulle policy di Principal Access Boundary.