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. Scenari descritti di seguito presuppongono 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 rete per 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 networking, 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 di creare una rete VPC conforme a RFC 1918 Spazi IP che possono essere utilizzati dai progetti associati (progetti di servizio). Sviluppatori utilizzando i progetti associati può creare istanze VM nella rete VPC condivisa spazi di archiviazione. Gli amministratori di rete e della sicurezza dell'organizzazione possono creare subnet, VPN e le 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 sicurezza |
|
| Principale: | Sicurezza e team di amministratori di rete |
| Risorsa: | Progetto host | Questo ruolo concede l'autorizzazione per utilizzare le subnet condivise Il VPC è stato condiviso. |
|---|---|---|
| Ruolo: | Utente della rete | |
| Entità: | Sviluppatori |
| Risorsa: | Progetto di servizio | Tieni presente che questo ruolo consente all'autorizzazione di utilizzare l'IP esterno indirizzi IP esterni. Leggi la nota riportata di seguito per avere indicazioni su come evitare questa azione. |
|---|---|---|
| Ruolo: | compute.instanceAdmin | |
| Entità: | Sviluppatori |
In questo scenario, hai bisogno di tre criteri di autorizzazione separati: uno per dell'organizzazione, uno per il progetto host e uno per i progetti di servizio.
Il primo criterio di autorizzazione, che deve essere collegato a livello di organizzazione, concede al team addetto alla rete e alla sicurezza i ruoli di cui hanno bisogno per amministrare di progetti host VPC. 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 questa a quel livello gerarchico. In questo modo tutti i progetti creati quella cartella per ereditare le autorizzazioni impostate per la cartella all'interno della quale viene creato un 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 è in grado di eseguire la funzione, è sufficiente
per regolare l'appartenenza al gruppo, senza la necessità di aggiornare il criterio di autorizzazione.
Separa rete e team della sicurezza
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 Rete, Sicurezza e Sviluppatori.
Le tabelle seguenti spiegano i ruoli IAM che devono essere concessi il team di amministrazione e sicurezza e il team di sviluppo, nonché a cui vengono concessi i ruoli.
| Risorsa: | Organizzazione | |
|---|---|---|
| Ruoli: | Amministratore VPC condiviso Amministratore di rete |
|
| Entità: | Il team di amministratori di rete |
| Risorsa: | Organizzazione | |
|---|---|---|
| Ruoli: | Amministratore della sicurezza Amministratore dell'organizzazione |
|
| Entità: | Team della sicurezza |
| Risorsa: | Progetto host | Questo ruolo concede l'autorizzazione per utilizzare le subnet condivise Il VPC è stato condiviso. |
|---|---|---|
| Ruolo: | Utente della rete | |
| Entità: | Sviluppatori |
| Risorsa: | Progetto di servizio | Tieni presente che questo ruolo consente all'autorizzazione di utilizzare l'IP esterno indirizzi IP esterni. Leggi la nota riportata di seguito per avere indicazioni su come evitare questa azione. |
|---|---|---|
| Ruolo: | compute.instanceAdmin | |
| Entità: | 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. La il ruolo di amministratore di rete consente inoltre al team relativo di visualizzare ma non o modificare le regole firewall. Offre inoltre al team di sicurezza la possibilità di impostare e gestire le regole firewall e i certificati SSL in tutti i progetti in 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 ciascun progetto di servizio. Questo consente agli sviluppatori che utilizzano il progetto di gestire le istanze nel servizio e alla possibilità di usare le subnet condivise nel progetto host.
Puoi inserire tutti i progetti di servizio in una cartella e impostare questa a quel livello gerarchico. 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 indipendente. Non hanno team di amministratori IT centrali e si affidano ai propri team gestire tutti gli aspetti dei loro 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.
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 risorse di rete e quelle effettive nei progetti, creando per i compiti logici è una best practice.
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. Consente inoltre di cambiare chi ha accesso a cosa senza dover modificare il criterio di autorizzazione ogni volta che un cambiamento.
| Risorsa: | Cartella | Un account di servizio può essere utilizzato per creare progetti ed eseguirne la proprietà. |
|---|---|---|
| Ruoli: | Autore progetto Amministratore della cartella |
|
| Principale: | Dev Teamleads Account di servizio |
| Risorsa: | Cartella | |
|---|---|---|
| Ruoli: | Amministratore di rete Amministratore sicurezza |
|
| Principale: | Rete e team di sicurezza |
| Risorsa: | Cartella | Questi ruoli consentono agli sviluppatori di gestire tutti gli aspetti BigQuery e Compute Engine. |
|---|---|---|
| Ruoli: | Amministratore istanza Amministratore BigQuery |
|
| Principale: | Sviluppatori |
Ciò richiede l'associazione di un criterio di autorizzazione alla cartella allocata a ciascun 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"
]
}
]
}