Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
SEC02-BP02 Utilizzo di credenziali temporanee
Quando si esegue qualsiasi tipo di autenticazione, è preferibile utilizzare credenziali temporanee invece di credenziali a lungo termine per ridurre o eliminare i rischi, come la divulgazione, la condivisione o il furto involontario delle stesse.
Risultato desiderato: al fine di ridurre il rischio di credenziali a lungo termine, utilizza credenziali temporanee laddove possibile per le identità di persone e macchine. Le credenziali a lungo termine creano molti rischi, come l'esposizione attraverso i caricamenti su repository pubblici. Grazie alle credenziali temporanee, riduci notevolmente le possibilità di compromissione delle credenziali.
Anti-pattern comuni:
-
Sviluppatori che utilizzano chiavi di accesso a lungo termine dagli utenti IAM anziché ottenere credenziali temporanee dalla CLI utilizzando la federazione.
-
Sviluppatori che inseriscono chiavi di accesso a lungo termine nel loro codice e caricano tale codice su repository Git pubblici.
-
Sviluppatori che inseriscono chiavi di accesso a lungo termine nelle app mobili che vengono poi rese disponibili negli app store.
-
Utenti che condividono le chiavi di accesso a lungo termine con altri utenti o dipendenti che lasciano l'azienda con chiavi di accesso a lungo termine ancora in loro possesso.
-
Utilizzo di chiavi di accesso a lungo termine per le identità macchina quando è possibile utilizzare credenziali temporanee.
Livello di rischio associato se questa best practice non fosse adottata: elevato
Guida all'implementazione
Utilizza credenziali di sicurezza temporanee anziché credenziali a lungo termine per tutte le richieste API e CLI AWS. In quasi tutti i casi, le richieste API e CLI rivolte ai servizi AWS devono essere firmate mediante chiavi di accesso AWS. Queste richieste possono essere firmate con credenziali temporanee o a lungo termine. L'unico caso in cui occorre utilizzare credenziali a lungo termine, note anche come chiavi di accesso a lungo termine, è l'utilizzo di utenti IAM o dell'utente root Account AWS. L'utilizzo della federazione per AWS o l'assunzione di un ruolo IAM tramite altri metodi prevede la creazione di credenziali temporanee. Anche quando accedi a AWS Management Console utilizzando le credenziali di accesso, vengono generate credenziali temporanee per effettuare chiamate ai servizi AWS. Sono poche le situazioni in cui occorrono credenziali a lungo termine ed è possibile svolgere quasi tutte le attività utilizzando credenziali temporanee.
Evitare l'uso di credenziali a lungo termine a favore di credenziali temporanee dovrebbe andare di pari passo con una strategia di riduzione dell'uso degli utenti IAM a favore della federazione e dei ruoli IAM. Sebbene l'utilizzo in passato degli utenti IAM sia per le identità umane che per quelle macchina, ora si consiglia di non utilizzarli per evitare i rischi legati all'uso di chiavi di accesso a lungo termine.
Passaggi dell'implementazione
Identità umane
Per le identità della forza lavoro come dipendenti, amministratori, sviluppatori e operatori:
-
Dovresti affidarti a gestori dell'identità digitale centralizzati e richiedere agli utenti umani di utilizzare la federazione con un gestore dell'identità digitale per accedere ad AWS utilizzando credenziali temporanee. La federazione per gli utenti può essere effettuata sia con la federazione diretta a ciascun Account AWS
sia utilizzando Centro identità AWS IAM e il gestore dell'identità digitale preferito. La federazione offre una serie di vantaggi rispetto all'utilizzo degli utenti IAM, oltre all'eliminazione delle credenziali a lungo termine. I tuoi utenti possono inoltre richiedere credenziali temporanee dalla riga di comando per la federazione diretta o utilizzando il Centro identità IAM. Ciò significa che i casi d'uso che richiedono utenti IAM o credenziali a lungo termine per gli utenti sono pochi.
Per le identità di terze parti:
-
Quando concedi l'accesso alle risorse del tuo Account AWS a terze parti, come i fornitori di software as a service (SaaS), puoi utilizzare ruoli multi-account e policy basate su risorse. Inoltre, puoi utilizzare il flusso delle credenziali client di concessione di Amazon Cognito OAuth 2.0 per clienti o partner SaaS B2B.
Identità utente che accedono alle risorse AWS tramite browser web, applicazioni client, app per dispositivi mobili o strumenti interattivi da riga di comando:
-
Se devi concedere alle applicazioni per consumatori o clienti l'accesso alle tue risorse AWS, puoi utilizzare i pool di identità di Amazon Cognito o i pool di utenti Amazon Cognito per fornire credenziali temporanee. Le autorizzazioni per le credenziali sono configurate attraverso i ruoli IAM. Puoi inoltre definire un ruolo IAM separato con autorizzazioni limitate per gli utenti guest non autenticati.
Identità macchina
Per le identità macchina, potrebbero essere necessarie credenziali a lungo termine. In questi casi, dovresti richiedere ai carichi di lavoro di utilizzare credenziali temporanee con ruoli IAM per l'accesso ad AWS.
-
Per Amazon Elastic Compute Cloud
(Amazon EC2), puoi utilizzare i ruoli per Amazon EC2. -
AWS Lambda
ti consente di configurare un ruolo di esecuzione Lambda per la concessione delle autorizzazioni di servizio al fine di eseguire azioni AWS mediante credenziali temporanee. Per i servizi AWS esistono molti altri modelli simili per concedere credenziali temporanee utilizzando i ruoli IAM. -
Per i dispositivi IoT, puoi richiedere credenziali temporanee al provider di credenziali AWS IoT Core.
-
Per sistemi on-premises o quelli eseguiti all'esterno di AWS che richiedono l'accesso alle risorse AWS, puoi utilizzare IAM Roles Anywhere.
Esistono scenari in cui le credenziali temporanee non sono supportate e che richiedono l'uso di credenziali a lungo termine. In queste situazioni, verifica e ruota periodicamente queste credenziali e ruota regolarmente le chiavi di accesso. Per chiavi di accesso dell'utente IAM altamente limitate, considera le seguenti misure di sicurezza aggiuntive:
-
Concedi autorizzazioni altamente limitate:
-
Rispetta il principio del privilegio minimo (con impostazioni specifiche per azioni, risorse e condizioni).
-
Valuta la possibilità di concedere all'utente IAM solo l'operazione AssumeRole per un ruolo specifico. A seconda dell'architettura on-premises, questo approccio consente di isolare e proteggere le credenziali IAM a lungo termine.
-
-
Limita le origini della rete e gli indirizzi IP consentiti nella policy di attendibilità dei ruoli IAM.
-
Monitora l'utilizzo e imposta avvisi per le autorizzazioni non utilizzate o l'uso improprio (utilizzando i filtri metriche e gli allarmi di AWS CloudWatch Logs).
-
Applica i limiti delle autorizzazioni (le policy di controllo dei servizi (SCP) e i limiti delle autorizzazioni si completano a vicenda: le SCP sono poco granulari, mentre i limiti delle autorizzazioni sono più granulari).
-
Implementa un processo per il provisioning e l'archiviazione sicura (in vault on-premises) delle credenziali.
Altre opzioni per gli scenari che richiedono credenziali a lungo termine sono le seguenti:
-
Crea la tua API di distribuzione di token (utilizzando Gateway Amazon API).
-
Per gli scenari in cui è necessario utilizzare credenziali a lungo termine o credenziali diverse dalle chiavi di accesso AWS (come i login ai database), puoi utilizzare un servizio progettato per gestire i segreti, come AWS Secrets Manager
. Secrets Manager semplifica la gestione, la rotazione e l'archiviazione sicura dei segreti crittografati. Molti servizi AWS supportano l'integrazione diretta con Secrets Manager. -
Per le integrazioni multi-cloud, puoi utilizzare la federazione delle identità basata sulle credenziali del provider di servizi di credenziali (CSP) di origine (consulta AWS STS AssumeRoleWithWebIdentity).
Per ulteriori informazioni sulla rotazione delle credenziali a lungo termine, consulta rotazione delle chiavi di accesso.
Risorse
Best practice correlate:
Documenti correlati:
Video correlati: