Questo argomento mostra come configurare le autorizzazioni di Identity and Access Management (IAM) per scenari di rete. Fornisce indicazioni su quali ruoli IAM concedere ai ruoli funzionali relativi alla rete della tua azienda per gli scenari. Questi contenuti sono principalmente rivolti agli amministratori di rete e ai dipendenti che gestiscono le attività di networking per un'organizzazione. Gli scenari descritti di seguito presuppongono tutti che sia configurata un'organizzazione Google Cloud.
Questo documento non spiega nel dettaglio i ruoli e le autorizzazioni di rete. Per una descrizione dettagliata dei ruoli e delle autorizzazioni associati alle API di calcolo e di rete, leggi la sezione Ruoli IAM di Compute Engine predefiniti.
Un unico team gestisce la sicurezza e la rete per l'organizzazione
In questo scenario, una grande organizzazione ha un team centrale che gestisce la sicurezza e i controlli di rete per l'intera organizzazione. Gli sviluppatori non hanno autorizzazioni per apportare modifiche alle impostazioni di rete o di sicurezza definite dal team di sicurezza e di rete, ma hanno l'autorizzazione per creare risorse come macchine virtuali in sottoreti condivise.
Per semplificare questa operazione, l'organizzazione utilizza una VPC condivisa (Virtual Private Cloud). Un VPC condiviso consente la creazione di una rete VPC di spazi IP RFC 1918 che i progetti associati (progetti di servizio) possono utilizzare. Gli sviluppatori che utilizzano i progetti associati possono creare istanze VM negli spazi della rete VPC condivisa. Gli amministratori di rete e della sicurezza dell'organizzazione possono creare subnet, VPN e regole firewall utilizzabili da tutti i progetti nella rete VPC.
Le tabelle riportate di seguito illustrano i ruoli IAM che devono essere concessi al team di sicurezza e di amministrazione e al team di sviluppo, nonché il livello di risorsa a cui vengono concessi i ruoli.
| Risorsa: | Organizzazione | |
|---|---|---|
| Ruoli: | Amministratore VPC condiviso Amministratore di rete Amministratore della sicurezza |
|
| Principale: | Team di amministratori della sicurezza e della rete |
| Risorsa: | Progetto host | Questo ruolo concede l'autorizzazione per utilizzare le subnet condivise dalla VPC condivisa. |
|---|---|---|
| Ruolo: | Utente di rete | |
| Principale: | Sviluppatori |
| Risorsa: | Progetto di servizio | Tieni presente che questo ruolo consente l'autorizzazione per l'utilizzo di indirizzi IP esterni. Consulta la nota riportata di seguito per indicazioni su come impedire questa azione. |
|---|---|---|
| Ruolo: | compute.instanceAdmin | |
| Principale: | Sviluppatori |
Per questo scenario, sono necessari tre criteri di autorizzazione distinti: uno per l'organizzazione, uno per il progetto host e uno per i progetti di servizio.
Il primo criterio di autorizzazione, che deve essere associato a livello di organizzazione, concede al team di rete e sicurezza i ruoli necessari per amministrare i progetti host VPC condivisi. inclusa la possibilità di associare i progetti di servizio al progetto host. Inoltre, concede al team di rete e sicurezza la possibilità di gestire tutte le risorse di rete e sicurezza in tutti i progetti dell'organizzazione.
{
"bindings": [
{
"role": "roles/compute.xpnAdmin",
"members": [
"group:sec-net@example.com"
]
},
{
"role":"roles/compute.networkAdmin",
"members": [
"group:sec-net@example.com"
]
},
{
"role": "roles/compute.securityAdmin",
"members": [
"group:sec-net@example.com"
]
}
]
}
Il secondo criterio di autorizzazione deve essere associato al progetto host e consente agli sviluppatori dell'organizzazione di utilizzare le reti condivise nel progetto host VPC condiviso.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
}
]
}
Il terzo criterio di autorizzazione deve essere associato a ogni progetto di servizio. In questo modo, gli sviluppatori che utilizzano il progetto possono gestire le istanze nel progetto di servizio e utilizzare le subnet condivise nel progetto host.
Puoi inserire tutti i progetti di servizio in una cartella e impostare questo particolare criterio di autorizzazione a quel livello della gerarchia. In questo modo, tutti i progetti creati in quella cartella erediteranno le autorizzazioni impostate nella cartella in cui viene creato il progetto di servizio.
Inoltre, devi concedere agli sviluppatori il ruolo Utente di rete nel progetto di servizio.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
},
{
"role": "roles/compute.instanceAdmin",
"members": [
"group:developers@example.com"
]
}
]
}
La best practice prevede l'utilizzo di gruppi per gestire i principali. Nell'esempio riportato sopra,
dovresti aggiungere gli ID utente degli utenti che gestiscono i controlli di sicurezza e di rete
al gruppo sec-net e gli sviluppatori al gruppo developers.
Per modificare chi deve poter eseguire la funzione, dovrai semplicemente modificare l'appartenenza al gruppo, senza dover aggiornare il criterio di autorizzazione.
Team di rete e sicurezza separati
In questo scenario, una grande organizzazione ha due team centrali: uno che gestisce i controlli di sicurezza e un altro che gestisce tutte le altre risorse di rete per l'intera organizzazione. Gli sviluppatori non hanno l'autorizzazione per apportare modifiche alle impostazioni di rete o di sicurezza definite dal team di sicurezza e di rete, ma hanno l'autorizzazione per creare risorse come macchine virtuali in sottoreti condivise.
Come nel primo scenario, verrà utilizzato un VPC condiviso e le autorizzazioni appropriate verranno configurate per i tre gruppi di rete, sicurezza e sviluppatori.
Le tabelle riportate di seguito illustrano i ruoli IAM che devono essere concessi al team di sicurezza e di amministrazione e al team di sviluppo, nonché il livello di risorsa a cui vengono concessi i ruoli.
| Risorsa: | Organizzazione | |
|---|---|---|
| Ruoli: | Amministratore VPC condiviso Amministratore di rete |
|
| Principale: | Team di amministratori di rete |
| Risorsa: | Organizzazione | |
|---|---|---|
| Ruoli: | Amministratore sicurezza Amministratore dell'organizzazione |
|
| Principale: | Team di sicurezza |
| Risorsa: | Progetto host | Questo ruolo concede l'autorizzazione per utilizzare le subnet condivise dalla VPC condivisa. |
|---|---|---|
| Ruolo: | Utente di rete | |
| Principale: | Sviluppatori |
| Risorsa: | Progetto di servizio | Tieni presente che questo ruolo consente l'autorizzazione per l'utilizzo di indirizzi IP esterni. Consulta la nota riportata di seguito per indicazioni su come impedire questa azione. |
|---|---|---|
| Ruolo: | compute.instanceAdmin | |
| Principale: | Sviluppatori |
Per questo scenario, sono necessari tre criteri di autorizzazione distinti: uno per l'organizzazione, uno per il progetto host e uno per i progetti di servizio.
Il primo criterio di autorizzazione, che deve essere allegato a livello di organizzazione, concede al team di rete i ruoli necessari per amministrare i progetti host VPC condivisi e per gestire tutte le risorse di rete. È inclusa la possibilità di associare i progetti di servizio al progetto host. Il ruolo Amministratore rete concede inoltre al team di rete la possibilità di visualizzare, ma non di modificare, le regole firewall. Inoltre, consente al team di sicurezza di impostare criteri di autorizzazione e gestire regole firewall e certificati SSL in tutti i progetti dell'organizzazione.
{
"bindings": [
{
"role": "roles/compute.xpnAdmin",
"members": [
"group:networks@example.com"
]
},
{
"role": "roles/compute.networkAdmin",
"members": [
"group:networks@example.com"
]
},
{
"role": "roles/compute.securityAdmin",
"members": [
"group:security@example.com"
]
},
{
"role": "roles/resourcemanager.organizationAdmin",
"members": [
"group:security@example.com"
]
}
]
}
Il secondo criterio di autorizzazione deve essere associato al progetto host. Questo criterio di autorizzazione consente agli sviluppatori dell'organizzazione di utilizzare le reti condivise nel progetto host VPC condiviso.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
}
]
}
Il terzo criterio di autorizzazione deve essere associato a ogni progetto di servizio. In questo modo, gli sviluppatori che utilizzano il progetto possono gestire le istanze nel progetto di servizio e utilizzare le subnet condivise nel progetto host.
Puoi inserire tutti i progetti di servizio in una cartella e impostare questo particolare criterio di autorizzazione a quel livello della gerarchia. In questo modo, tutti i progetti creati in quella cartella erediteranno le autorizzazioni impostate nella cartella in cui viene creato il progetto di servizio.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
},
{
"role": "roles/compute.instanceAdmin",
"members": [
"group:developers@example.com"
]
}
]
}
Ogni team può gestire la propria rete
Un'azienda nativa digitale vuole dare ai propri team di sviluppo la possibilità di lavorare in modo autonomo. Non hanno team di amministratori IT centrali e si affidano ai propri team per gestire tutti gli aspetti dei progetti.
Nonostante ciò, vogliono anche poter implementare alcuni controlli flessibili per adottare una configurazione più formale man mano che crescono e il loro prodotto viene lanciato sul mercato.
Per implementare questo scenario, a ogni team di sviluppatori viene assegnata una propria cartella. Questa struttura garantisce che i singoli progetti creati nella cartella ereditino le autorizzazioni appropriate, consentendo al contempo a ogni team di lavorare in modo indipendente. Ogni team deve comunque seguire il principio del privilegio minimo quando imposta i criteri di autorizzazione per le proprie risorse.
Anche se inizialmente saranno gli stessi membri del team a gestire le risorse di rete e le risorse effettive dei progetti, è buona prassi creare gruppi distinti per le responsabilità logiche.
Questo approccio facilita la limitazione dell'accesso alle risorse di cui ha bisogno il personale temporaneo o, ad esempio, il nuovo personale che deve essere formato prima di poter modificare le risorse di rete. Inoltre, consente di modificare chi ha accesso a quali risorse senza dover modificare il criterio di autorizzazione ogni volta che si verifica un cambio di personale.
| Risorsa: | Cartella | Un account di servizio può essere utilizzato per creare e possedere progetti. |
|---|---|---|
| Ruoli: | Autore progetto Amministratore cartelle |
|
| Principale: | Dev Teamleads Account di servizio |
| Risorsa: | Cartella | |
|---|---|---|
| Ruoli: | Amministratore di rete Amministratore sicurezza |
|
| Principale: | Il team di rete e sicurezza |
| Risorsa: | Cartella | Questi ruoli consentono agli sviluppatori di gestire tutti gli aspetti di BigQuery e Compute Engine. |
|---|---|---|
| Ruoli: | Amministratore istanza Amministratore BigQuery |
|
| Principale: | Sviluppatori |
È necessario un criterio di autorizzazione associato alla cartella allocata di ogni team.
{
"bindings": [
{
"role": "roles/resourcemanager.foldersAdmin",
"members": [
"group:devteamleads01@example.com",
"serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
]
},
{
"role":"roles/resourcemanager.projectCreator",
"members": [
"group:devteamleads01@example.com",
"serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
]
},
{
"role": "roles/compute.securityAdmin",
"members": [
"group:net-sec-dev01@example.com"
]
},
{
"role": "roles/compute.networkAdmin",
"members": [
"group:net-sec-dev01@example.com"
]
},
{
"role": "roles/compute.instanceAdmin",
"members": [
"group:dev01@example.com"
]
},
{
"role": "roles/bigquery.admin",
"members": [
"group:dev01@example.com"
]
}
]
}