Le risorse di Google Cloud sono organizzate in modo gerarchico, dove il nodo organizzazione è il nodo radice della gerarchia, i progetti sono i figli dell'organizzazione e le altre risorse sono discendenti dei progetti. Puoi impostare i criteri di autorizzazione a diversi livelli della gerarchia delle risorse. Le risorse ereditano i criteri di autorizzazione della risorsa padre. Il criterio di autorizzazione effettivo per una risorsa è l'unione del criterio di autorizzazione impostato a livello di risorsa e il criterio di autorizzazione ereditato dalla risorsa padre.
In questa pagina vengono descritti alcuni esempi di come funziona l'ereditarietà dei criteri e vengono descritte le best practice da tenere presenti quando si creano risorse durante il deployment di Identity and Access Management (IAM).
Prerequisiti
- Impara i concetti di base di IAM, in particolare la gerarchia delle risorse di Google Cloud.
Premesse
Il seguente diagramma mostra un esempio di gerarchia delle risorse Google Cloud.
IAM consente di impostare i criteri di autorizzazione ai seguenti livelli della gerarchia delle risorse:
Livello di organizzazione: La risorsa organizzazione rappresenta la tua azienda. I ruoli IAM concessi a questo livello vengono ereditati da tutte le risorse all'interno dell'organizzazione. Per maggiori informazioni, consulta Controllo dell'accesso per le organizzazioni che utilizzano IAM.
Livello di cartella: Le cartelle possono contenere progetti, altre cartelle o una combinazione di entrambi. I ruoli concessi al livello di cartella più alto verranno ereditati dai progetti o dalle altre cartelle contenute in quella cartella padre. Per maggiori informazioni, consulta Controllo dell'accesso alle cartelle utilizzando IAM.
A livello di progetto. I progetti rappresentano un confine di attendibilità all'interno della tua azienda. I servizi all'interno dello stesso progetto hanno un livello di attendibilità predefinito. Ad esempio, le istanze App Engine possono accedere ai bucket Cloud Storage all'interno dello stesso progetto. I ruoli IAM concessi a livello di progetto vengono ereditati dalle risorse all'interno del progetto. Per maggiori informazioni, consulta Controllo dell'accesso per i progetti che utilizzano IAM.
Livello risorsa: Oltre ai sistemi Cloud Storage e BigQuery ACL esistenti, risorse aggiuntive come i set di dati Genomics, gli argomenti Pub/Sub e le istanze di Compute Engine supportano i ruoli di livello inferiore in modo che tu possa concedere a determinati utenti l'autorizzazione per una singola risorsa all'interno di un progetto.
I criteri di autorizzazione sono gerarchici e propagano la struttura. Il criterio di autorizzazione effettivo per una risorsa è l'unione del criterio di autorizzazione impostato per quella risorsa e del criterio di autorizzazione ereditato dalla risorsa padre.
I seguenti esempi spiegano come funziona nella pratica l'ereditarietà dei criteri.
Esempio: Pub/Sub
In Pub/Sub, gli argomenti e le sottoscrizioni sono risorse che risiedono in un progetto. Supponiamo che nel progetto_1 sia presente un argomento topic_a. Se imposti un criterio di autorizzazione nel progetto_1 che concede il ruolo Editor a mario@example.com e imposti un criterio di autorizzazione su topic_a che conceda il ruolo Publisher ad alice@example.com, concedi di fatto il ruolo Editor a bob@example.com e il ruolo Publisher ad alice@example.com per topic_a.
Il seguente diagramma illustra l'esempio precedente.
I ruoli Proprietario, Editor e Visualizzatore sono concentrici, ovvero il ruolo Proprietario include le autorizzazioni del ruolo Editor, mentre il ruolo Editor include le autorizzazioni del ruolo Visualizzatore. Se concedi alla stessa persona il ruolo più ampio e quello limitato (ad esempio Editor e Visualizzatore), gli verrà concesso solo il ruolo più ampio. Ad esempio, se concedi il ruolo Editor a bob@example.com a livello di progetto e il ruolo Visualizzatore a bob@example.com per topic_a, a Bob viene concesso il ruolo Editor per topic_a. Questo perché hai già concesso a Bob il ruolo Editor per topic_a, che viene ereditato dal criterio di autorizzazione impostato su project_a.
Il seguente diagramma illustra l'esempio precedente.
Esempio: Cloud Storage
In Cloud Storage, i bucket e gli oggetti sono risorse, mentre gli oggetti si trovano nei bucket. Un esempio di utilizzo di IAM con Cloud Storage è consentire l'accesso in lettura ai file caricati.
Considera uno scenario in cui molti utenti caricano file in un bucket senza però riuscire a leggere o eliminare nessuno dei file caricati da altri utenti. Il tuo esperto di elaborazione dati dovrebbe essere in grado di leggere ed eliminare i file caricati, ma non dovrebbe essere in grado di eliminare i bucket perché altri utilizzano la posizione del bucket per caricare i propri file. In questo scenario, devi impostare i criteri di autorizzazione sul progetto nel seguente modo:
- Concedi il ruolo Amministratore oggetti Storage alla tua esperta di elaborazione dati, Alice, all'indirizzo alice@example.com.
- Alice dispone dei diritti di amministratore degli oggetti a livello di progetto e può leggere, aggiungere ed eliminare qualsiasi oggetto in qualsiasi bucket del progetto.
- Concedi Creatore oggetti Storage a un gruppo di utenti, data_uploaders@example.com.
- Questo criterio di autorizzazione indica che chiunque sia membro del gruppo data_uploaders@example.com può caricare file nel bucket.
- Un membro del gruppo è proprietario dei file che carica, ma non può leggere o eliminare i file caricati da altri utenti.
Il seguente diagramma illustra l'esempio precedente.
Esempio: Compute Engine
Nelle aziende più grandi, la gestione delle risorse di rete e di sicurezza, come i firewall, è in genere gestita da un team dedicato, diverso dal team di sviluppo. I team di sviluppo potrebbero volere la flessibilità per avviare istanze ed eseguire altre azioni correlate alle istanze nei loro progetti. La concessione del ruolo Amministratore istanze Compute a bob@example.com a livello di organizzazione e a Amministratore istanze Compute per il progetto progetto_2 consente ad Alice di eseguire qualsiasi azione sulle istanze impedendole di apportare modifiche alle risorse di rete associate al progetto. Solo Roberto può apportare modifiche alle risorse di rete dell'organizzazione e a tutti i progetti al suo interno.
Autorizzazioni per la visualizzazione dei criteri ereditati
Per visualizzare i criteri IAM ereditati da una risorsa padre, devi disporre dell'autorizzazione per visualizzare il criterio IAM della risorsa padre. Ad esempio, per visualizzare tutti i criteri IAM ereditati per un progetto, devi disporre dell'autorizzazione per visualizzare il criterio IAM dell'organizzazione padre del progetto e per visualizzare i criteri IAM di qualsiasi cartella padre.
Per ottenere le autorizzazioni necessarie per visualizzare i criteri IAM ereditati dalle risorse padre, chiedi all'amministratore di concederti i seguenti ruoli IAM:
-
Visualizza un criterio IAM ereditato da un'organizzazione:
Amministratore organizzazione (
roles/resourcemanager.organizationAdmin) nell'organizzazione -
Visualizza un criterio IAM ereditato da una cartella:
Amministratore cartelle (
roles/resourcemanager.folderAdmin) sulla cartella -
Visualizza un criterio IAM ereditato da un progetto:
Amministratore IAM progetto (
roles/resourcemanager.projectIamAdmin) sul progetto
Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso.
Questi ruoli predefiniti contengono le autorizzazioni necessarie per visualizzare i criteri IAM ereditati dalle risorse padre. Per visualizzare le autorizzazioni necessarie, espandi la sezione Autorizzazioni richieste:
Autorizzazioni obbligatorie
Per visualizzare i criteri IAM ereditati dalle risorse padre sono necessarie le seguenti autorizzazioni:
-
Visualizza un criterio IAM ereditato da un'organizzazione:
resourcemanager.organizations.getIamPolicynell'organizzazione -
Visualizza un criterio IAM ereditato da una cartella:
resourcemanager.folders.getIamPolicynella cartella -
Visualizza un criterio IAM ereditato da un progetto:
resourcemanager.projects.getIamPolicynel progetto
Potresti anche essere in grado di ottenere queste autorizzazioni con i ruoli personalizzati o altri ruoli predefiniti.
best practice
Mirroring della struttura gerarchica delle risorse di Google Cloud nella struttura organizzativa. La gerarchia delle risorse di Google Cloud dovrebbe riflettere il modo in cui è organizzata la tua azienda, che si tratti di una startup, una SME o una grande azienda. Una startup può iniziare con una gerarchia di risorse flat senza risorsa dell'organizzazione. Quando più persone iniziano a collaborare sui progetti e il numero di progetti aumenta, potrebbe essere utile ottenere una risorsa organizzazione. Una risorsa dell'organizzazione è consigliata per le aziende più grandi con più reparti e team in cui ogni team è responsabile del proprio insieme di applicazioni e servizi.
Usa i progetti per raggruppare le risorse che condividono gli stessi confini di attendibilità. Ad esempio, le risorse per lo stesso prodotto o microservizio possono appartenere allo stesso progetto.
Se possibile, concedi i ruoli a un gruppo Google anziché a singoli utenti. Gestire i membri di un gruppo Google è più facile che aggiornare un criterio di autorizzazione. Assicurati di controllare la proprietà del gruppo Google utilizzato nei criteri di autorizzazione.
Per ulteriori informazioni su come gestire i gruppi Google, consulta la guida di Google Gruppi.
Utilizza il principio di sicurezza del privilegio minimo per concedere i ruoli IAM, ovvero concedi solo il livello di accesso minimo necessario alle tue risorse.
Per trovare il ruolo predefinito appropriato, consulta la documentazione di riferimento sui ruoli predefiniti. Se non sono disponibili ruoli predefiniti appropriati, puoi anche creare i tuoi ruoli personalizzati.
Concedi ruoli nel minor ambito necessario. Ad esempio, se un utente deve accedere solo per pubblicare messaggi in un argomento Pub/Sub, concedi il ruolo Publisher all'utente per quell'argomento.
Ricorda che i criteri di autorizzazione per le risorse figlio ereditano dai criteri di autorizzazione per le risorse padre. Ad esempio, se il criterio di autorizzazione per un progetto concede a un utente la possibilità di amministrare le istanze di macchine virtuali (VM) Compute Engine, l'utente può amministrare qualsiasi VM di Compute Engine nel progetto, indipendentemente dal criterio di autorizzazione impostato su ciascuna VM.
In ogni progetto, assicurati che almeno due entità abbiano il ruolo Proprietario (
roles/owner). In alternativa, concedi il ruolo Proprietario a un gruppo Google che contiene almeno due entità.In questo modo puoi assicurarti che, se una delle entità lascia l'azienda, tu possa comunque gestire il progetto.
Se devi concedere un ruolo a un utente o a un gruppo che copre più progetti, imposta quel ruolo a livello di cartella anziché impostarlo a livello di progetto.
Utilizza le etichette per annotare, raggruppare e filtrare le risorse.
Controlla i criteri di autorizzazione per garantire la conformità. Gli audit log contengono tutte le chiamate
setIamPolicy(), quindi puoi tenere traccia di quando un criterio di autorizzazione è stato creato o modificato.Controllare la proprietà e l'appartenenza dei gruppi Google utilizzati nei criteri di autorizzazione.
Se vuoi limitare la creazione di progetti nella tua organizzazione, modifica il criterio di accesso dell'organizzazione per concedere il ruolo Autore progetto a un gruppo che gestisci.