Utilizzo della gerarchia delle risorse per il controllo degli accessi

Le risorseGoogle Cloud sono organizzate in modo gerarchico, dove il nodo organizzazione è il nodo radice della gerarchia, i progetti sono figli dell'organizzazione e le altre risorse sono discendenti dei progetti. Puoi impostare criteri di autorizzazione a diversi livelli della gerarchia delle risorse. Le risorse ereditano le policy di autorizzazione della risorsa padre. Il criterio di autorizzazione effettivo per una risorsa è dato dall'unione del criterio di autorizzazione impostato per quella risorsa più il criterio di autorizzazione ereditato dalla risorsa padre.

Questa pagina descrive alcuni esempi di funzionamento dell'ereditarietà delle policy di autorizzazione e spiega le best practice da prendere in considerazione quando crei risorse durante l'implementazione di Identity and Access Management (IAM).

Prerequisiti

Sfondo

Il seguente diagramma mostra un esempio di gerarchia delle risorse Google Cloud .

Dall'alto verso il basso, la gerarchia include organizzazioni, cartelle, progetti e risorse specifiche del servizio.

IAM ti consente di impostare criteri di autorizzazione ai seguenti livelli della gerarchia delle risorse:

  • Livello dell'organizzazione. La risorsa organizzazione rappresenta la tua azienda. I ruoli IAM concessi a questo livello vengono ereditati da tutte le risorse dell'organizzazione. Per ulteriori informazioni, consulta Controllo dell'accesso per le organizzazioni utilizzando 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 da altre cartelle contenuti nella cartella principale. Per ulteriori informazioni, consulta Controllo dell'accesso per le cartelle con IAM.

  • 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 di quel progetto. Per ulteriori informazioni, consulta Controllo dell'accesso per i progetti che utilizzano IAM.

  • Livello risorsa. Oltre ai sistemi ACL di Cloud Storage e BigQuery esistenti, 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 più il criterio di autorizzazione ereditato dalla risorsa padre.

I seguenti esempi spiegano come funziona in pratica l'ereditarietà dei criteri di autorizzazione.

Esempio: Pub/Sub

In Pub/Sub, gli argomenti e le sottoscrizioni sono risorse che si trovano in un progetto. Supponiamo che project_1 abbia un argomento topic_a. Se imposti una norma di autorizzazione su project_1 che concede il ruolo Editor a Kalani e imposti una norma di autorizzazione su topic_a che concede il ruolo Editore a Nur, concedi di fatto il ruolo Editor a Kalani e il ruolo Editore a Nur per topic_a.

Il seguente diagramma illustra l'esempio precedente.

Esempio di Pub/Sub.

Se un ruolo ereditato concede già a un'entità tutte le autorizzazioni di cui ha bisogno, non è necessario concedere ruoli aggiuntivi alla risorsa stessa. La concessione di un altro ruolo che contiene le stesse autorizzazioni o un numero inferiore è ridondante e non ha alcun effetto.

Ad esempio, considera i ruoli di base Proprietario, Editor e Visualizzatore. Questi ruoli sono concentrici, ovvero il ruolo Proprietario include le autorizzazioni del ruolo Editor e quest'ultimo include le autorizzazioni del ruolo Visualizzatore. Di conseguenza, se concedi a Kalani il ruolo Editor a livello di progetto, la concessione del ruolo Visualizzatore su topic_a è ridondante. Questo perché Kalani dispone già di tutte le autorizzazioni del ruolo Visualizzatore tramite il ruolo Editor, ereditato dai criteri di autorizzazione del progetto.

Il seguente diagramma illustra l'esempio precedente.

Esempio di Pub/Sub.

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 trattamento dei dati deve essere in grado di leggere ed eliminare i file caricati, ma non deve poter eliminare i bucket perché altri utenti utilizzano la posizione del bucket per caricare i propri file. In questo scenario, imposteresti le policy di autorizzazione sul progetto nel seguente modo:

  • Concedi il ruolo Amministratore oggetti Storage (roles/storage.objectAdmin) al tuo esperto di trattamento dei dati, Nur. Questo ruolo consente a Nur di leggere, aggiungere ed eliminare qualsiasi oggetto in qualsiasi bucket del progetto.
  • Concedi il ruolo Storage Object Creator (roles/storage.objectCreator) al gruppo data-uploaders. Questo ruolo consente ai membri del gruppo di caricare file nel bucket, ma non di leggere o eliminare i file caricati da altri utenti.

Il seguente diagramma illustra l'esempio precedente.

Esempio di Cloud Storage.

Esempio: Compute Engine

Nelle aziende più grandi, la gestione delle risorse di rete e di sicurezza, come i firewall, viene in genere gestita da un team dedicato, diverso dal team di sviluppo. I team di sviluppo potrebbero voler avere la flessibilità di avviare istanze ed eseguire altre azioni correlate alle istanze nei loro progetti.

In una situazione come questa, potresti configurare i criteri di autorizzazione nel seguente modo:

  • Concedi il ruolo Amministratore di rete Compute(roles/compute.networkAdmin) all'amministratore di rete e sicurezza, Kalani, a livello di organizzazione. Questo ruolo consente a Kalani di apportare modifiche alle risorse di rete nell'organizzazione e in tutti i progetti al suo interno.
  • Concedi il ruolo Compute Instance Admin(roles/compute.instanceAdmin) a un responsabile del team di sviluppo, Nur, nel suo progetto project_2. Questo ruolo consente a Nur di eseguire qualsiasi azione sulle sue istanze, impedendole di apportare modifiche alle risorse di rete associate al suo progetto. Tuttavia, non consente di apportare modifiche alle risorse di rete in altri progetti.

Esempio di Compute Engine.

Autorizzazioni per la visualizzazione delle policy ereditate

Per visualizzare i criteri IAM ereditati da una risorsa padre, devi disporre dell'autorizzazione per visualizzare i criteri IAM della risorsa padre. Ad esempio, per visualizzare tutte le policy IAM ereditate per un progetto, devi disporre dell'autorizzazione per visualizzare la policy IAM dell'organizzazione padre del progetto e le policy IAM di tutte le cartelle padre.

Per ottenere le autorizzazioni necessarie per visualizzare le policy IAM ereditate dalle risorse parent, chiedi all'amministratore di concederti i seguenti ruoli IAM:

  • Visualizza una policy IAM ereditata da un'organizzazione: Amministratore dell'organizzazione (roles/resourcemanager.organizationAdmin) sull'organizzazione
  • Visualizza una policy IAM ereditata da una cartella: Amministratore cartella (roles/resourcemanager.folderAdmin) sulla cartella
  • Visualizza una policy IAM ereditata da un progetto: Project IAM Admin (roles/resourcemanager.projectIamAdmin) sul progetto

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Questi ruoli predefiniti contengono le autorizzazioni necessarie per visualizzare le policy IAM ereditate dalle risorse padre. Per vedere quali sono esattamente le autorizzazioni richieste, espandi la sezione Autorizzazioni obbligatorie:

Autorizzazioni obbligatorie

Per visualizzare i criteri IAM ereditati dalle risorse padre sono necessarie le seguenti autorizzazioni:

  • Visualizza una policy IAM ereditata da un'organizzazione: resourcemanager.organizations.getIamPolicy sull'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 sul progetto

Potresti anche ottenere queste autorizzazioni con ruoli personalizzati o altri ruoli predefiniti.

Best practice

  • Rispecchia la struttura della gerarchia delle risorse nella struttura organizzativa. Google Cloud La gerarchia delle risorse Google Cloud deve riflettere l'organizzazione della tua azienda, che si tratti di una startup, una PMI o una grande società. Una startup potrebbe iniziare con una gerarchia delle risorse piatta senza una risorsa organizzazione. Quando più persone iniziano a collaborare ai progetti e il numero di progetti aumenta, potrebbe essere utile ottenere una risorsa dell'organizzazione. Una risorsa 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, assegna i ruoli a un gruppo anziché a singoli utenti. È più facile gestire i membri di un gruppo che aggiornare un criterio di autorizzazione. Assicurati di controllare la proprietà del gruppo utilizzato nei criteri di autorizzazione.

    Per saperne di più su come gestire i gruppi Google, consulta la Guida di Google Gruppi.

  • Utilizza il principio di sicurezza del privilegio minimo per assegnare ruoli IAM, ovvero 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 ruoli personalizzati.

  • Assegna i ruoli limitando le autorizzazioni all'indispensabile. Ad esempio, se un utente ha bisogno solo dell'accesso per pubblicare messaggi in un argomento Pub/Sub, concedi il ruolo Publisher all'utente per quell'argomento.

  • Tieni presente che le policy di autorizzazione per le risorse figlio vengono ereditate dalle policy di autorizzazione per le risorse padre. Ad esempio, se la policy di autorizzazione per un progetto concede a un utente la possibilità di amministrare le istanze di macchine virtuali (VM) di Compute Engine, l'utente può amministrare qualsiasi VM di Compute Engine in quel progetto, indipendentemente dalla policy di autorizzazione impostata su ciascuna VM.

  • In ogni progetto, assicurati che almeno due entità abbiano il ruolo Proprietario (roles/owner). In alternativa, assegna il ruolo Proprietario a un gruppo che contiene almeno due entità.

    Questa pratica contribuisce a garantire che, se uno dei principali lascia la tua azienda, tu abbia comunque un modo per gestire il tuo progetto.

  • Se devi concedere un ruolo a un utente o a un gruppo che si estende su più progetti, imposta il ruolo a livello di cartella anziché a livello di progetto.

  • Utilizza le etichette per annotare, raggruppare e filtrare le risorse.

  • Controlla le tue policy di autorizzazione per garantire la conformità. I log di controllo contengono tutte le chiamate setIamPolicy(), quindi puoi tracciare quando è stata creata o modificata una policy di autorizzazione.

  • Controlla la proprietà e l'iscrizione ai gruppi utilizzati nei criteri di autorizzazione.

  • Se vuoi limitare la creazione di progetti nella tua organizzazione, modifica i criteri di accesso dell'organizzazione per concedere il ruolo Project Creator a un gruppo che gestisci.