Utilizzo della gerarchia delle risorse per il controllo degli accessi

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. Il criterio di autorizzazione effettivo per una risorsa è dato dall'unione del criterio di autorizzazione impostato per la risorsa e del criterio di autorizzazione ereditato dalla risorsa di livello superiore.

Questa pagina descrive alcuni esempi di come funziona l'eredità delle autorizzazioni delle norme e illustra le best practice da tenere in considerazione quando crei risorse durante il deployment di Identity and Access Management (IAM).

Prerequisiti

• Comprendi i concetti di base di IAM, in particolare la 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 al di sotto dell'organizzazione. Per ulteriori informazioni, consulta Controllo dell'accesso per le organizzazioni che utilizzano IAM.

• A 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 da 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. 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.

• Livello risorsa. Oltre ai sistemi ACL esistenti di Cloud Storage e BigQuery, risorse aggiuntive come gli argomenti Pub/Sub e le istanze Compute Engine supportano ruoli di livello inferiore, 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 la modalità Consenti l'eredità dei criteri nella pratica.

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 una regola di autorizzazione su project_1 che concede il ruolo Editor a bob@example.com e una regola di autorizzazione su topic_a che concede il ruolo Publisher ad alice@example.com, concedi effettivamente 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 a livello di progetto e il ruolo Visualizzatore a bob@example.com per l'argomento argomento_a, a Bob viene concesso il ruolo Editor per l'argomento argomento_a. Questo perché hai già concesso a Bob il ruolo Editor per l'argomento 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 e 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, ma non devono essere in grado di leggere o eliminare i 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, imposterai 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 indica che chiunque sia membro del gruppo data_uploaders@example.com può caricare file nel bucket.
  • Un membro di un 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 voler avere la flessibilità di lanciare istanze ed eseguire altre azioni correlate alle istanze nei loro progetti. Se assegni a bob@example.com il ruolo Amministratore rete Compute a livello di organizzazione e ad alice@example.com il ruolo Amministratore istanze Compute nel suo progetto project_2, Alice potrà eseguire qualsiasi azione sulle istanze impedendo al contempo di apportare modifiche alle risorse di rete associate al 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 delle norme ereditate

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 dell'organizzazione (roles/resourcemanager.organizationAdmin) nell'organizzazione
• Visualizza un criterio IAM ereditato da una cartella: Amministratore cartella (roles/resourcemanager.folderAdmin) nella 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 le norme IAM ereditate dalle risorse principali. Per visualizzare le autorizzazioni esatte richieste, espandi la sezione Autorizzazioni richieste:

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.getIamPolicy nell'organizzazione
• Visualizza un criterio IAM ereditato da una cartella: resourcemanager.folders.getIamPolicy nella cartella
• Visualizza un criterio IAM ereditato da un progetto: resourcemanager.projects.getIamPolicy nel progetto

Potresti anche ottenere queste autorizzazioni con ruoli personalizzati o 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 deve riflettere l'organizzazione della tua azienda, che si tratti di una startup, di una PMI o di una grande azienda. Una startup potrebbe iniziare con una gerarchia delle risorse piatta senza alcuna risorsa dell'organizzazione. Quando più persone iniziano a collaborare ai progetti e il numero di progetti aumenta, potrebbe essere utile creare una risorsa dell'organizzazione. Una risorsa dell'organizzazione è consigliata per le aziende più grandi con diversi 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 anziché a singoli utenti. È più facile gestire i membri di un gruppo rispetto ad aggiornare un criterio di autorizzazione. Assicurati di controllare la proprietà del gruppo 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 assegnare i ruoli IAM. In altre parole, concedi solo il livello di accesso necessario per le tue risorse.

  Per trovare il ruolo predefinito appropriato, consulta il 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 vengono ereditati 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 VM (virtual machine) di Compute Engine, l'utente può amministrare qualsiasi VM di Compute Engine in quel 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 Proprietario a un gruppo che contenga 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 concedere 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.

• Controlla la proprietà e l'appartenenza ai gruppi 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 Creatore di progetti a un gruppo che gestisci.