Questa pagina consiglia le best practice di sicurezza da tenere presenti quando si utilizza IAM.
Questa pagina è progettata per gli utenti esperti di IAM. Se stai appena iniziando a utilizzare IAM, queste istruzioni non ti insegneranno come farlo; i nuovi utenti dovrebbero invece iniziare con la guida rapida IAM.
Principio del 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 in base alle tue esigenze.
Se devi sostituire un ruolo di base, puoi utilizzare i consigli sui ruoli per determinare quali ruoli concedere. Puoi anche utilizzare Policy Simulator per assicurarti che la modifica del ruolo non influisca sull'accesso dell'entità. Potrebbe essere opportuno concedere i 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 di questi servizi, quindi concedi solo le autorizzazioni richieste a ogni account di servizio.
|
❑
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 di macchine virtuali (VM) Compute Engine, l'utente può amministrare qualsiasi VM Compute Engine nel progetto, indipendentemente dal criterio di autorizzazione impostato su ogni VM.
|
❑
Assegna i ruoli limitando le autorizzazioni all'indispensabile. Ad esempio, se un utente ha bisogno solo di accedere per pubblicare argomenti Pub/Sub, concedi all'utente il ruolo Publisher per quell'argomento.
|
❑
Specifica quali entità possono
fungere da 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. Pertanto, fai attenzione quando assegni 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 del progetto e Amministratore IAM della cartella consente di modificare i criteri di autorizzazione senza consentire anche l'accesso amministrativo, di lettura e scrittura diretto a tutte le risorse.
La concessione del ruolo Proprietario ( roles/owner ) a un'entità consente di accedere e modificare quasi tutte le risorse, inclusa la modifica dei criteri di autorizzazione. Questo livello di privilegi è potenzialmente rischioso. Concedi il ruolo Proprietario solo quando è richiesto un accesso (quasi) universale.
|
❑
Utilizza le associazioni di ruoli condizionali per consentire la scadenza automatica dell'accesso e valuta la possibilità di concedere un accesso elevato temporaneo.
|
Account di servizio
❑
Adotta le best practice per lavorare con gli account di servizio. Assicurati che gli account di servizio abbiano privilegi limitati e proteggili da potenziali minacce alla sicurezza.
|
❑
Non eliminare gli account di servizio in uso da istanze in esecuzione. Ciò potrebbe comportare il fallimento dell'intera applicazione o di parti di essa se non hai prima eseguito la transizione all'utilizzo di un account di servizio alternativo.
|
❑
Utilizza il nome visualizzato di un account di servizio per tenere traccia delle finalità per cui viene utilizzato e delle autorizzazioni di cui ha bisogno.
|
Chiavi account di servizio
❑
Evita di utilizzare le chiavi dei account di servizio se è disponibile un'altra opzione.
Le chiavi degli account di servizio comportano un rischio per la sicurezza se non vengono gestite correttamente. Dovresti
scegliere un'alternativa più sicura alle chiavi degli account di servizio
quando è possibile. Se devi effettuare l'autenticazione con una chiave dell'account di servizio, sei responsabile della sicurezza della chiave privata e di altre operazioni descritte dalle
best practice per la gestione delle chiavi degli account di servizio.
Se non riesci a creare una chiave del account di servizio, la creazione di chiavi del account di servizio potrebbe essere disabilitata per la tua organizzazione. Per ulteriori informazioni, vedi
Gestire le risorse dell'organizzazione sicure per impostazione predefinita.
|
❑
Ruota le chiavi dell'account di servizio utilizzando l'API account di servizio IAM.
Puoi ruotare una chiave creandone una nuova, impostando le applicazioni in modo che utilizzino la nuova chiave, disattivando la vecchia chiave ed eliminandola quando hai la certezza che non sia più necessaria.
|
❑
Implementa procedimenti per gestire le chiavi degli account di servizio gestiti dall'utente.
|
❑
Fai attenzione a non confondere le chiavi di crittografia con le chiavi degli account di servizio. Le chiavi di crittografia vengono in genere utilizzate per criptare i dati, mentre le chiavi dell'account di servizio vengono utilizzate per accedere in sicurezza alle API Google Cloud.
|
❑
Non eseguire il check-in delle chiavi dell'account di servizio nel codice sorgente o non lasciarle nella directory Download.
|
Controllo
❑
Utilizza i log di Cloud Audit Logs per eseguire regolarmente la revisione delle modifiche al criterio di autorizzazione.
|
❑
Esporta gli audit log in Cloud Storage per archiviarli per lunghi periodi di tempo.
|
❑
Controlla chi ha la possibilità di modificare i criteri di autorizzazione nei tuoi progetti.
|
❑
Gestisci l'accesso ai log utilizzando i
ruoli di logging.
|
❑
Applica alla risorsa Google Cloud che utilizzi per instradare i log gli stessi criteri di accesso applicati a Logs Explorer.
|
❑
Utilizza i log di Cloud Audit Logs per controllare regolarmente l'accesso alle chiavi degli account di servizio.
|
Gestione dei criteri
❑
Se un'entità deve accedere a tutti i progetti della tua organizzazione, concedi i ruoli all'entità a livello di organizzazione.
|
❑
Se possibile, concedi i ruoli ai gruppi anziché ai singoli utenti. È più facile aggiornare i membri di un gruppo rispetto agli entità nelle norme di autorizzazione.
|