Le risorse di Google Cloud sono organizzate in modo gerarchico, dove il nodo organizzazione è il nodo principale della gerarchia, i progetti sono 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. La il criterio di autorizzazione effettivo per una risorsa è l'unione del criterio di autorizzazione impostato quella risorsa e il criterio di autorizzazione ereditato dalla risorsa padre.
Questa pagina descrive alcuni esempi di come funziona l'eredità dei criteri di autorizzazione e illustra le best practice da tenere in considerazione quando crei risorse durante il deployment di Identity and Access Management (IAM).
Prerequisiti
- L'architettura concetti di base di IAM, in particolare Gerarchia delle risorse di Google Cloud.
Sfondo
Il seguente diagramma mostra un esempio di gerarchia delle risorse di Google Cloud.
IAM ti consente di impostare i criteri di autorizzazione ai seguenti livelli della gerarchia delle risorse:
A 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 ulteriori informazioni, vedi Controllo dell'accesso per le organizzazioni che utilizzano IAM.
A livello di cartella. Le cartelle possono contenere progetti, altre cartelle o un combinazione di entrambi. I ruoli concessi al livello di cartella più alto verranno ereditati dai progetti o dalle altre cartelle contenute nella cartella principale. Per ulteriori informazioni, consulta Controllo dell'accesso per le cartelle con 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 ulteriori informazioni, consulta Controllo dell'accesso per i progetti che utilizzano IAM.
A livello di risorsa. Oltre alle risorse Cloud Storage e i sistemi ACL di BigQuery, risorse aggiuntive come i set di dati Genomics, Gli argomenti Pub/Sub e le istanze Compute Engine supportano in modo da poter concedere a determinati utenti l'autorizzazione per una singola risorsa all'interno di un progetto.
I criteri di autorizzazione sono gerarchici e si propagano verso il basso nella struttura. Il criterio di autorizzazione effettivo per una risorsa è dato dall'unione del criterio di autorizzazione impostato per quella risorsa e del criterio di autorizzazione ereditato dalla risorsa di livello superiore.
I seguenti esempi spiegano come funziona nella pratica l'ereditarietà dei criteri di autorizzazione.
Esempio: Pub/Sub
In Pub/Sub, gli argomenti e le iscrizioni sono risorse che si trovano all'interno di un progetto. Supponiamo che project_1 abbia un argomento topic_a al suo interno. Se imposti il criterio di autorizzazione sul progetto_1 che concede il ruolo Editor a bob@example.com e imposta un criterio di autorizzazione su topic_a che assegna il ruolo Publisher a alice@example.com, concedi in modo efficace 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 e quest'ultimo include le autorizzazioni del ruolo Visualizzatore. Se concedi sia il ruolo più ampio sia quello limitato (ad esempio Editor e Visualizzatore) alla stessa persona, viene concesso solo il ruolo più ampio. Ad esempio, se concedi il ruolo Editor a bob@example.com all'indirizzo a livello di progetto e concedi il ruolo Visualizzatore a bob@example.com per topic_a, Roberto dispone del ruolo Editor per topic_a. Ciò è dovuto al fatto che hai già concesso Bob con il ruolo Editor per l'argomento topic_a, che viene ereditato dal criterio di autorizzazione impostato su progetto_a.
Il seguente diagramma illustra l'esempio precedente.
Esempio: Cloud Storage
In Cloud Storage, i bucket e gli oggetti sono risorse e gli oggetti si trovano nei bucket. Esempio di utilizzo di IAM con Cloud Storage consente l'accesso in lettura ai file caricati.
Considera uno scenario in cui molti utenti caricano file in un bucket, ma non deve essere in grado di leggere o eliminare nessuno dei file caricati da altri utenti. L'esperto di elaborazione dei dati dovrebbe essere in grado di leggere ed eliminare i file caricati, ma non dovrebbe essere in grado di eliminare i bucket perché altri utenti utilizzano la posizione del bucket per caricare i propri file. In questo scenario, devi impostare i criteri di autorizzazione sul progetto come segue:
- Concedi il ruolo Amministratore oggetti di archiviazione al tuo esperto di elaborazione dei dati Alice all'indirizzo alice@example.com.
- Alice ha diritti di amministratore degli oggetti a livello di progetto e può leggere, aggiungere ed eliminare qualsiasi oggetto in qualsiasi bucket del progetto.
- Concedi il ruolo Storage Object Creator
a un gruppo di utenti,
data_uploaders@example.com.
- Questo criterio di autorizzazione implica 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 sono generalmente gestiti da un team dedicato, che è diverso team di sviluppo. I team di sviluppo potrebbero volere la flessibilità per lanciare ed eseguire altre azioni correlate alle istanze in modo programmatico a gestire i progetti. Concedendo a bob@example.com il Amministratore rete Compute ruolo a livello di organizzazione e alice@example.com Amministratore istanze Compute nel progetto project_2 consente ad Alice di eseguire qualsiasi azione sulle istanze e al tempo stesso le impedisce di apportare modifiche alle risorse di rete associate con il suo progetto. Solo Bob può apportare modifiche alle risorse di rete nell'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 principale, è necessaria l'autorizzazione per visualizzare il criterio IAM della risorsa principale. Ad esempio, per visualizzare tutti i criteri IAM ereditati per un progetto, devi disporre dell'autorizzazione per visualizzare il criterio IAM dell'organizzazione principale del progetto e i criteri IAM di eventuali cartelle principali.
Per ottenere le autorizzazioni necessarie per visualizzare i criteri IAM ereditati dalle risorse principali, chiedi all'amministratore di concederti i seguenti ruoli IAM:
-
Visualizza un criterio IAM ereditato da un'organizzazione:
Amministratore organizzazione (
roles/resourcemanager.organizationAdmin) dell'organizzazione -
Visualizza un criterio IAM ereditato da una cartella:
Amministratore cartelle (
roles/resourcemanager.folderAdmin) sulla cartella -
Visualizza un criterio IAM ereditato da un progetto:
Project IAM Admin (
roles/resourcemanager.projectIamAdmin) nel progetto
Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.
Questi ruoli predefiniti contengono le autorizzazioni necessarie per visualizzare i criteri IAM ereditati dalle risorse principali. Per vedere le autorizzazioni esatte obbligatorie, espandi la sezione Autorizzazioni obbligatorie:
Autorizzazioni obbligatorie
Per visualizzare i criteri IAM ereditati dalle risorse principali, 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 riuscire a ottenere queste autorizzazioni con ruoli personalizzati altri ruoli predefiniti.
Best practice
Esegui il mirroring della struttura gerarchica delle risorse Google Cloud nella struttura della tua organizzazione. La gerarchia delle risorse Google Cloud riflettono il modo in cui è organizzata la tua azienda, che si tratti di una startup, una PMI o un società di grandi dimensioni. Una startup potrebbe iniziare con una gerarchia delle risorse piatta senza risorse dell'organizzazione. Quando più persone iniziano a collaborare ai progetti e il numero di progetti aumenta, potrebbe essere utile creare una risorsa dell'organizzazione. È consigliata una risorsa dell'organizzazione per le aziende più grandi con reparti e team, ciascuno dei quali è responsabile della propria un insieme di applicazioni e servizi.
Usa i progetti per raggruppare le risorse che condividono gli stessi confini di attendibilità. Per 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. it è più facile gestire i membri in un gruppo Google piuttosto 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, vedi Guida di Google Gruppi.
Utilizza il principio di sicurezza privilegio minimo per concedere ruoli IAM; cioè assegna solo la quantità minima l'accesso necessario alle tue risorse.
Per trovare il ruolo predefinito appropriato, consulta la documentazione di riferimento ai ruoli predefiniti. Se non sono presenti ruoli predefiniti appropriati, puoi anche creare i tuoi ruoli personalizzati.
Assegna i ruoli limitando le autorizzazioni all'indispensabile. Ad esempio, se un utente ha bisogno solo di accedere per pubblicare messaggi in un argomento Pub/Sub, concedi all'utente il ruolo Publisher per quell'argomento.
Ricorda che i criteri di autorizzazione per le risorse figlio ereditano per le rispettive risorse padre. Ad esempio, se il criterio di autorizzazione per un progetto concede a un utente la possibilità di amministrare le istanze VM (virtual machine) di Compute Engine, l'utente può amministrare qualsiasi VM di Compute Engine nel progetto, indipendentemente dal criterio di autorizzazione impostato su ogni VM.
In ogni progetto, assicurati che almeno due entità abbiano il ruolo Proprietario (
roles/owner). In alternativa, concedi il ruolo di Proprietario a un gruppo Google che contiene almeno due entità.Questa prassi ti consente di assicurarti che, se uno dei principali lascia la tua azienda, tu abbia ancora un modo per gestire il progetto.
Se devi assegnare un ruolo a un utente o a un gruppo che si estende a più progetti, impostalo a livello di cartella anziché a livello di progetto.
Utilizza le etichette per annotare, raggruppare e filtrare le risorse.
Controlla i criteri di autorizzazione per garantire la conformità. I log di controllo contengono tutte le chiamate
setIamPolicy(), pertanto puoi risalire al momento in cui è stato creato o modificato un criterio di autorizzazione.Verificare la proprietà e l'appartenenza ai gruppi Google utilizzati in di autorizzazione.
Se vuoi limitare la creazione di progetti nella tua organizzazione, modifica criteri di accesso dell'organizzazione per concedere Ruolo Autore progetto a un gruppo gestito da te.