Questa pagina consiglia le best practice per la sicurezza da tenere presenti quando si utilizza IAM.
Questa pagina è rivolta agli utenti che conoscono bene IAM. Se hai appena iniziato a utilizzare IAM, queste istruzioni non ti insegneranno come utilizzarlo; i nuovi utenti dovrebbero invece iniziare con la guida rapida di IAM.
Privilegio minimo
|
□
I ruoli di base includono migliaia di autorizzazioni per tutti i servizi Google Cloud. Negli ambienti di produzione, non concedere ruoli di base a meno che non ci siano alternative. Concedi invece i ruoli predefiniti o i ruoli personalizzati più limitati secondo le tue esigenze.
Se devi sostituire un ruolo di base, puoi utilizzare i suggerimenti sui ruoli per determinare invece quali concedere. Puoi anche utilizzare il Simulatore dei criteri per assicurarti che la modifica del ruolo non influisca sull'accesso dell'entità. Potrebbe essere appropriato concedere ruoli di base nei seguenti casi:
|
|
□
Tratta ogni componente dell'applicazione come un confine di attendibilità separato. Se
hai più servizi che richiedono autorizzazioni diverse, crea un account di servizio separato
per ciascuno dei servizi, quindi concedi solo le autorizzazioni necessarie a ciascun
account di servizio.
|
|
□
Ricorda che i criteri di autorizzazione per le risorse figlio ereditano 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 di macchine virtuali (VM) Compute Engine, l'utente può amministrare qualsiasi VM di Compute Engine nel progetto, indipendentemente dal criterio di autorizzazione impostato su ciascuna VM.
|
|
□
Assegna i ruoli nell'ambito più ristretto necessario. Ad esempio, se un utente deve accedere solo per pubblicare argomenti Pub/Sub, concedi all'utente il ruolo Publisher per quell'argomento.
|
|
□
Specifica quali entità possono agire come account di servizio.
Gli utenti a cui è stato concesso il ruolo Utente account di servizio per un account di servizio possono accedere a tutte le risorse a cui ha accesso l'account di servizio. Presta quindi attenzione quando concedi il ruolo Utente account di servizio a un utente.
|
|
□
Specifica chi ha accesso per creare e gestire gli account di servizio nel tuo progetto.
|
|
□
La concessione dei ruoli predefiniti Amministratore IAM progetto e Amministratore IAM cartella consentirà l'accesso per modificare i criteri di autorizzazione senza anche consentire l'accesso diretto in lettura, scrittura e amministrativo a tutte le risorse.
La concessione del ruolo Proprietario ( roles/owner) a un'entità gli consentirà di accedere e
modificare quasi tutte le risorse, inclusa la modifica dei criteri di autorizzazione. Questo livello di privilegio è potenzialmente rischioso. Concedi il ruolo di proprietario solo quando è richiesto l'accesso universale (quasi quasi).
|
|
□
Utilizza le associazioni di ruoli condizionali per lasciare che l'accesso scada automaticamente e valuta la possibilità di
concedere l'accesso con privilegi solo su base just-in-time.
|
Account di servizio
|
□
Adotta le best practice per l'utilizzo degli account di servizio. Assicurati che gli account di servizio abbiano privilegi limitati e proteggiti da potenziali minacce alla sicurezza.
|
|
□
Non eliminare gli account di servizio utilizzati dalle istanze in esecuzione. Questa operazione potrebbe causare errori nell'intera applicazione o in parti di esse se non hai prima eseguito la transizione a un account di servizio alternativo.
|
|
□
Utilizza il nome visualizzato di un account di servizio per tenere traccia degli scopi per cui viene utilizzato l'account di servizio e delle autorizzazioni necessarie.
|
Chiavi account di servizio
|
□
Evita di utilizzare chiavi degli account di servizio se è disponibile un'altra opzione.
Le chiavi degli account di servizio rappresentano un rischio per la sicurezza se non vengono gestite correttamente. Devi
scegliere un'alternativa più sicura alle chiavi degli account di servizio ove possibile. Se devi eseguire l'autenticazione con una chiave dell'account di servizio, sei responsabile della sicurezza della chiave privata e di altre operazioni di gestione, ad esempio la rotazione della chiave. Per ulteriori informazioni, consulta le best practice per la gestione delle chiavi degli account di servizio.
|
|
□
Ruota le chiavi degli account di servizio utilizzando l'API IAM.
Puoi ruotare una chiave creando una nuova chiave, cambiando le applicazioni in modo che utilizzino quella nuova, disattivando quella precedente ed eliminando quella precedente quando hai la certezza che non sia più necessaria.
|
|
□
Implementa i processi per gestire le chiavi degli account di servizio gestite dall'utente.
|
|
□
Fai attenzione a non confondere le chiavi di crittografia con quelle degli account di servizio. In genere, le chiavi di crittografia vengono utilizzate per criptare i dati, mentre le chiavi degli account di servizio vengono utilizzate per un accesso sicuro alle API Google Cloud.
|
|
□
Non controllare le chiavi dell'account di servizio nel codice sorgente e non lasciarle nella directory Download.
|
Controllo
|
□
Utilizza i log di Audit log di Cloud per controllare regolarmente le modifiche al criterio di autorizzazione.
|
|
□
Esporta gli audit log in Cloud Storage per archiviare i log per lunghi periodi di tempo.
|
|
□
Verifica chi ha la possibilità di modificare i criteri di autorizzazione sui tuoi progetti.
|
|
□
Gestisci l'accesso ai log utilizzando i
ruoli di Logging.
|
|
□
Applica gli stessi criteri di accesso alla risorsa Google Cloud che utilizzi per il routing dei log applicati a Esplora log.
|
|
□
Utilizza i log di Cloud Audit Logs per controllare regolarmente l'accesso alle chiavi degli account di servizio.
|
Gestione dei criteri
|
□
Se un'entità ha bisogno di accedere a tutti i progetti dell'organizzazione, concedi i ruoli all'entità a livello di organizzazione.
|
|
□
Se possibile, concedi i ruoli a un gruppo Google anziché a singoli utenti. È più facile aggiornare i membri di un gruppo Google che aggiornare le entità nei criteri di autorizzazione.
|