

# SEC 2. Come si gestisce l'autenticazione per persone e macchine?
<a name="sec-02"></a>

 Ci sono due tipi di identità da gestire quando inizi a utilizzare carichi di lavoro AWS sicuri. Comprendere il tipo di identità necessaria per gestire e concedere l'accesso ti aiuta a verificare che le identità corrette abbiano accesso alle risorse giuste nelle condizioni adeguate. 

Identità umane: amministratori, sviluppatori, operatori e utenti finali necessitano di un'identità per accedere agli ambienti e alle applicazioni AWS. Si tratta di membri dell'organizzazione o di utenti esterni con cui collabori e che interagiscono con le risorse AWS tramite Web browser, applicazioni client o strumenti a riga di comando interattivi. 

Identità di macchine: le applicazioni di servizio, gli strumenti operativi e i carichi di lavoro necessitano di un'identità per effettuare richieste ai servizi AWS, ad esempio per leggere i dati. Queste identità includono macchine in esecuzione nell'ambiente AWS, ad esempio istanze Amazon EC2 o funzioni AWS Lambda. Puoi gestire le identità di macchine anche per soggetti esterni che necessitano dell'accesso. Inoltre, potresti disporre di macchine al di fuori di AWS che devono accedere al tuo ambiente AWS. 

**Topics**
+ [SEC02-BP01 Utilizzo meccanismi di accesso efficaci](sec_identities_enforce_mechanisms.md)
+ [SEC02-BP02 Utilizzo di credenziali temporanee](sec_identities_unique.md)
+ [SEC02-BP03 Archiviazione e utilizzo dei segreti in modo sicuro](sec_identities_secrets.md)
+ [SEC02-BP04 Fai affidamento su un provider di identità centralizzato](sec_identities_identity_provider.md)
+ [SEC02-BP05 Verifica e rotazione periodica delle credenziali](sec_identities_audit.md)
+ [SEC02-BP06 Utilizzo dei gruppi di utenti e degli attributi](sec_identities_groups_attributes.md)

# SEC02-BP01 Utilizzo meccanismi di accesso efficaci
<a name="sec_identities_enforce_mechanisms"></a>

I sign-in (autenticazione tramite credenziali di accesso) possono presentare dei rischi se non si utilizzano meccanismi come l'autenticazione a più fattori (MFA), soprattutto in situazioni in cui le credenziali di accesso sono state inavvertitamente divulgate o sono facilmente identificabili. Utilizza meccanismi di accesso efficaci per ridurre questi rischi, richiedendo l'MFA e policy sulle password sicure. 

 **Risultato desiderato:** ridurre i rischi di accesso involontario alle credenziali in AWS utilizzando meccanismi di accesso efficaci per gli utenti [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/), l'[utente root Account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html), [AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) (successore di AWS Single Sign-On) e i provider di identità di terze parti. Ciò significa richiedere l'MFA, applicare policy sulle password efficaci e rilevare comportamenti di accesso anomali. 

 **Anti-pattern comuni:** 
+  Nessuna applicazione di policy sulle password efficaci per le proprie identità, comprese password complesse e MFA. 
+  Condivisione delle stesse credenziali tra utenti diversi. 
+  Nessun utilizzo di controlli investigativi per gli accessi sospetti. 

 **Livello di rischio associato se questa best practice non fosse adottata:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Ci sono molti modi in cui le identità umane possono accedere ad AWS. È una best practice di AWS affidarsi a un provider di identità centralizzato che si avvale della federazione (federazione diretta o utilizzo di AWS IAM Identity Center) per l’autenticazione ad AWS. In questo caso, è necessario stabilire un processo di accesso sicuro con il provider di identità o con Microsoft Active Directory. 

 Quando apri un Account AWS, inizi con un utente root Account AWS. L'account utente root deve essere utilizzato solo per impostare l'accesso per gli utenti e per le [attività che richiedono l'utente root](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)). È importante abilitare l'MFA per l'utente root dell'account subito dopo l'apertura di Account AWS e proteggere l'utente root usando la guida AWS alle [best practice](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_aws_account.html). 

 Se crei utenti in AWS IAM Identity Center, proteggi il processo di accesso in quel servizio. Per le identità dei consumatori, puoi usare [Amazon Cognito user pools](https://docs.aws.amazon.com/cognito/index.html) e proteggere il processo di accesso in tale servizio oppure puoi utilizzare uno dei fornitori di identità supportato da Amazon Cognito user pools. 

 Se si utilizzano gli utenti [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/), è opportuno proteggere il processo di accesso mediante IAM. 

 Indipendentemente dal metodo di accesso, è fondamentale applicare una policy di accesso efficace. 

 **Passaggi dell'implementazione** 

 Le seguenti sono raccomandazioni generali per l'accesso sicuro. Le impostazioni effettive da configurare devono essere stabilite dalla policy aziendale o utilizzare uno standard come [NIST 800-63](https://pages.nist.gov/800-63-3/sp800-63b.html). 
+  Richiedere l'MFA. [Richiedere l'MFA è una best practice IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users) per le identità e i carichi di lavoro umani. L'abilitazione dell'MFA fornisce un ulteriore livello di sicurezza che richiede agli utenti di fornire le credenziali di accesso e un codice OTP (One-Time Password) o una stringa verificata e generata crittograficamente da un dispositivo hardware. 
+  Applicare una lunghezza minima della password, che è un fattore primario nella forza della password. 
+  Applicare la complessità delle password in modo che sia più difficile individuarle. 
+  Consentire agli utenti di modificare le proprie password. 
+  Creare identità individuali invece di credenziali condivise. Creando identità individuali, è possibile assegnare a ciascun utente un set unico di credenziali di sicurezza. I singoli utenti consentono di sottoporre a audit l'attività di ciascuno. 

 Suggerimenti IAM Identity Center: 
+  IAM Identity Center fornisce una [policy sulla password](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html) prestabilita quando si utilizza la directory predefinita che stabilisce i requisiti di lunghezza, complessità e riutilizzo delle password. 
+  [Abilitare l'MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-enable-how-to.html) e configurare l'impostazione "Compatibile con il contesto" o "Sempre attivo" per l'MFA quando l'origine dell'identità è la directory predefinita, AWS Managed Microsoft AD o AD Connector. 
+  Consenti agli utenti di [registrare i propri dispositivi MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/how-to-allow-user-registration.html). 

 Suggerimenti sulla directory Amazon Cognito user pools: 
+  Configura le impostazioni di [forza della password](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html). 
+  [Richiedi l'MFA](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-mfa.html) per gli utenti. 
+  Utilizza le Amazon Cognito user pools [impostazioni di sicurezza avanzate](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-advanced-security.html) per le funzionalità quali l'[autenticazione adattiva](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-adaptive-authentication.html) che può bloccare sign-in sospetti. 

 Suggerimenti per l'utente IAM: 
+  Idealmente stai utilizzando IAM Identity Center o la federazione diretta. Tuttavia, potrebbero essere necessari utenti IAM. In tal caso, [imposta una policy sulla password](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) per gli utenti IAM. Puoi utilizzare la policy sulla password per definire requisiti quali la lunghezza minima o la necessità che la password richieda caratteri non alfabetici. 
+  Crea una policy IAM per [applicare l'accesso MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html#tutorial_mfa_step1) in modo che gli utenti possano gestire le proprie password e i dispositivi MFA. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [SEC02-BP03 Archiviazione e utilizzo dei segreti in modo sicuro](sec_identities_secrets.md) 
+  [SEC02-BP04 Fai affidamento su un provider di identità centralizzato](sec_identities_identity_provider.md) 
+  [SEC03-BP08 Condivisione delle risorse in modo sicuro all'interno dell'organizzazione](sec_permissions_share_securely.md) 

 **Documenti correlati:** 
+ [AWS IAM Identity Center (successor to AWS Single Sign-On) Password Policy ](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html) Policy sulle password AWS IAM Identity Center (successore di AWS Single Sign-On)
+ [ IAM user password policy ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)(Policy sulle password degli utenti IAM)
+ [ Setting the Account AWS root user password ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)(Impostazione della password dell'utente root dell'account AWS)
+ [ Amazon Cognito password policy ](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html) (Policy sulla password di Amazon Cognito)
+ [AWS credentials ](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html)(Credenziali AWS)
+ [ IAM security best practices ](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)(Best Practice di sicurezza IAM)

 **Video correlati:** 
+  [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E) (Gestire le autorizzazioni degli utenti su larga scala con AWS SSO) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

# SEC02-BP02 Utilizzo di credenziali temporanee
<a name="sec_identities_unique"></a>

 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 credenziali. 

**Risultato desiderato:** per ridurre il rischio legato alle credenziali a lungo termine, utilizza credenziali temporanee ogni qualvolta sia possibile sia per le identità umane che per le identità macchina. Le credenziali a lungo termine creano molti rischi, ad esempio possono essere caricate in codice su repository GitHub pubblici. Utilizzando credenziali temporanee, riduci notevolmente le possibilità di compromissione delle credenziali. 

**Anti-pattern comuni:**
+  Sviluppatori che utilizzano chiavi di accesso a lungo termine dagli IAM users 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 applicazioni 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
<a name="implementation-guidance"></a>

 Utilizza credenziali di sicurezza temporanee invece di credenziali a lungo termine per tutte le richieste API e CLI AWS. Le richieste API e CLI ai servizi AWS devono, in quasi tutti i casi, essere firmate utilizzando le [chiavi di accesso AWS](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_access-keys.html). Queste richieste possono essere firmate con credenziali temporanee o a lungo termine. L'unico caso in cui si devono utilizzare credenziali a lungo termine, note anche come chiavi di accesso a lungo termine, è qualora si stia utilizzando un [utente IAM](https://docs.aws.amazon.com//latest/UserGuide/id_users.html) o un [utente root Account AWS](https://docs.aws.amazon.com//latest/UserGuide/id_root-user.html). Al momento della federazione ad AWS o dell'assunzione di un [ruolo IAM](https://docs.aws.amazon.com//latest/UserGuide/id_roles.html) attraverso altri metodi, vengono generate delle credenziali temporanee. Anche quando accedi a Console di gestione AWS utilizzando le credenziali di accesso, vengono generate credenziali temporanee per effettuare chiamate ai servizi AWS. Sono poche le situazioni in cui è necessario disporre di 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 in passato gli utenti IAM siano stati utilizzati 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
<a name="implementation-steps"></a>

 Per le identità umane come dipendenti, amministratori, sviluppatori, operatori e clienti: 
+  Devi [affidarti a un fornitore di identità centralizzato](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html) e [richiedere agli utenti umani di utilizzare la federazione con un fornitore di identità per accedere ad AWS utilizzando credenziali temporanee](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html#bp-users-federation-idp). La federazione degli utenti può essere effettuata con [la federazione diretta a ciascun Account AWS](https://aws.amazon.com/identity/federation/) o utilizzando [AWS IAM Identity Center (successore di AWS IAM Identity Center)](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) e un provider di identità a scelta. La federazione offre una serie di vantaggi rispetto all'utilizzo degli utenti IAM, oltre all'eliminazione delle credenziali a lungo termine. Gli utenti possono anche richiedere credenziali temporanee dalla riga di comando per la [federazione diretta](https://aws.amazon.com/blogs/security/how-to-implement-federated-api-and-cli-access-using-saml-2-0-and-ad-fs/) o utilizzare [IAM Identity Center](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html). Ciò significa che i casi d'uso che richiedono utenti IAM o credenziali a lungo termine per gli utenti sono pochi.  
+  Quando concedi a terzi, come ad esempio ai fornitori di software come servizio (SaaS), l'accesso alle risorse del tuo Account AWS, puoi utilizzare [ruoli multi-account](https://docs.aws.amazon.com//latest/UserGuide/tutorial_cross-account-with-roles.html) e [policy basate sulle risorse](https://docs.aws.amazon.com//latest/UserGuide/access_policies_identity-vs-resource.html). 
+  Se devi concedere l'accesso alle tue risorse alle applicazioni per i consumatori o per i clientiAWS, puoi utilizzare i [pool di identità Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html) o [Amazon Cognito user pools](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html) per fornire le credenziali temporanee. Le autorizzazioni per le credenziali sono configurate tramite i ruoli IAM. Puoi anche definire un ruolo IAM separato con autorizzazioni limitate per gli utenti guest non autenticati. 

 Per le identità macchina, potrebbero essere necessarie credenziali a lungo termine. In questi casi, devi [richiedere ai carichi di lavoro di utilizzare credenziali temporanee con ruoli IAM per accedere ad AWS](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html#bp-workloads-use-roles). 
+  Per [Amazon Elastic Compute Cloud](https://aws.amazon.com/pm/ec2/) (Amazon EC2), puoi utilizzare [ruoli per Amazon EC2](https://docs.aws.amazon.com//latest/UserGuide/id_roles_use_switch-role-ec2.html). 
+  [AWS Lambda](https://aws.amazon.com/lambda/) ti consente di configurare un [ruolo di esecuzione Lambda per concedere le autorizzazioni al servizio](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) per eseguire azioni AWS utilizzando credenziali temporanee. Per i servizi AWS esistono molti altri modelli simili per concedere credenziali temporanee utilizzando i ruoli IAM. 
+  Per i dispositivi IoT, puoi utilizzare il [provider di credenziali AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html) per richiedere credenziali temporanee. 
+  Per i sistemi on-premise o per i sistemi che vengono eseguiti al di fuori di AWS che richiedono accesso alle risorse AWS, puoi utilizzare [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html). 

 Esistono scenari in cui le credenziali temporanee non sono un'opzione e potrebbe essere necessario utilizzare credenziali a lungo termine. In queste situazioni, [sottoponi a audit e ruota periodicamente le credenziali](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html) e [ruota regolarmente le chiavi di accesso per i casi d'uso che richiedono credenziali a lungo termine.](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html#rotate-credentials). Alcuni esempi che potrebbero richiedere credenziali a lungo termine sono i plugin di WordPress e i client AWS di terze parti. Quando è necessario utilizzare credenziali a lungo termine o per credenziali diverse dalle chiavi di accesso AWS, come ad esempio i login ai database, puoi utilizzare un servizio progettato per gestire i segreti, ad esempio [Gestione dei segreti AWS](https://aws.amazon.com/secrets-manager/). Secrets Manager consente di gestire, ruotare e archiviare in modo semplice e sicuro i segreti crittografati usando [servizi supportati](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html). Per ulteriori informazioni sulla rotazione delle credenziali a lungo termine, consulta [Rotating Access Keys](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) (Rotazione delle chiavi di accesso). 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+ [SEC02-BP03 Archiviazione e utilizzo dei segreti in modo sicuro](sec_identities_secrets.md) 
+ [SEC02-BP04 Fai affidamento su un provider di identità centralizzato](sec_identities_identity_provider.md) 
+ [SEC03-BP08 Condivisione delle risorse in modo sicuro all'interno dell'organizzazione](sec_permissions_share_securely.md) 

 **Documenti correlati:** 
+  [Credenziali di sicurezza temporanee](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_temp.html) 
+  [AWS Credentials](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html) (Credenziali AWS) 
+  [IAM Security Best Practices](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html) (Best practice per la sicurezza IAM) 
+  [Ruoli IAM](https://docs.aws.amazon.com//latest/UserGuide/id_roles.html) 
+  [IAM Identity Center](https://aws.amazon.com/iam/identity-center/) 
+  [Provider di identità e federazione](https://docs.aws.amazon.com//latest/UserGuide/id_roles_providers.html) 
+  [Rotating Access Keys](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) 
+  [Soluzioni dei partner per la sicurezza: accesso e controllo degli accessi](https://aws.amazon.com/security/partner-solutions/#access-control) 
+  [L'utente root dell'account AWS](https://docs.aws.amazon.com//latest/UserGuide/id_root-user.html) 

 **Video correlati:** 
+  [Managing user permissions at scale with AWS IAM Identity Center (Gestire le autorizzazioni degli utenti su larga scala con AWS SSO), successore di AWS IAM Identity Center)](https://youtu.be/aEIqeFCcK7E) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

# SEC02-BP03 Archiviazione e utilizzo dei segreti in modo sicuro
<a name="sec_identities_secrets"></a>

 Un carico di lavoro richiede una capacità automatizzata di dimostrare la propria identità a database, risorse e servizi di terze parti. A tal fine si utilizzano credenziali di accesso segrete, come chiavi di accesso API, password e token OAuth. L'utilizzo di un servizio appositamente creato per archiviare, gestire e ruotare queste credenziali aiuta a ridurre la probabilità che queste vengano compromesse. 

**Risultato desiderato:** implementare un meccanismo per la gestione sicura delle credenziali delle applicazioni che raggiunga i seguenti obiettivi: 
+  Identificare i segreti necessari per il carico di lavoro. 
+  Ridurre il numero di credenziali a lungo termine sostituendole con credenziali a breve termine, quando possibile. 
+  Stabilire l'archiviazione sicura e la rotazione automatica delle rimanenti credenziali a lungo termine. 
+  Sottoporre a audit l'accesso ai segreti esistenti nel carico di lavoro. 
+  Eseguire il monitoraggio continuo per verificare che nessun segreto sia incorporato nel codice sorgente durante il processo di sviluppo. 
+  Ridurre la probabilità che le credenziali vengano divulgate inavvertitamente. 

**Anti-pattern comuni:**
+  Nessuna rotazione delle credenziali. 
+  Memorizzazione di credenziali a lungo termine nel codice sorgente o nei file di configurazione. 
+  Memorizzazione delle credenziali a riposo non criptate. 

 **Vantaggi dell'adozione di questa best practice:**
+  I segreti sono conservati in modo criptato a riposo e in transito. 
+  L'accesso alle credenziali è regolato da un'API (si pensi a un *distributore automatico di credenziali*). 
+  L'accesso a una credenziale (sia in lettura che in scrittura) viene sottoposto a audit e registrato. 
+  Separazione delle preoccupazioni: la rotazione delle credenziali viene eseguita da un componente distinto, che può essere separato dal resto dell'architettura. 
+  I segreti vengono distribuiti automaticamente su richiesta ai componenti software e la rotazione avviene in una posizione centrale. 
+  L'accesso alle credenziali può essere controllato in modo granulare. 

 **Livello di rischio associato se questa best practice non fosse adottata:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 In passato, le credenziali utilizzate per l'autenticazione ai database, alle API di terze parti, ai token e ad altri segreti potevano essere incorporate nel codice sorgente o nei file di ambiente. AWS fornisce diversi meccanismi per memorizzare queste credenziali in modo sicuro, ruotarle automaticamente e sottoporre a audit il loro utilizzo. 

 Il modo migliore per affrontare la gestione dei segreti è seguire le indicazioni di rimuovere, sostituire e ruotare. La credenziale più sicura è quella che non si deve memorizzare, gestire o trattare. Possono esserci credenziali che non sono più necessarie per il funzionamento del carico di lavoro e che possono essere rimosse in modo sicuro. 

 Per le credenziali che sono ancora necessarie per il corretto funzionamento del carico di lavoro, potrebbe esserci l'opportunità di sostituire una credenziale a lungo termine con una credenziale temporanea o a breve termine. Ad esempio, invece di una codifica fissa di una chiave di accesso segreta AWS, si può pensare di sostituire la credenziale a lungo termine con una credenziale temporanea utilizzando i ruoli IAM. 

 Alcuni segreti di lunga durata potrebbero non poter essere rimossi o sostituiti. Questi segreti possono essere memorizzati in un servizio come [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html), dove possono essere archiviati, gestiti e ruotati regolarmente a livello centrale. 

 Un audit del codice sorgente e dei file di configurazione del carico di lavoro può rivelare molti tipi di credenziali. La tabella seguente riassume le strategie per gestire i tipi più comuni di credenziali: 


|  Credential type  |  Description  |  Suggested strategy  | 
| --- | --- | --- | 
|  IAM access keys  |  AWS IAM access and secret keys used to assume IAM roles inside of a workload  |  Replace: Use [Ruoli IAM](https://docs.aws.amazon.com//latest/UserGuide/id_roles_common-scenarios.html) assigned to the compute instances (such as [Amazon EC2](https://docs.aws.amazon.com//latest/UserGuide/id_roles_use_switch-role-ec2.html) or [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)) instead. For interoperability with third parties that require access to resources in your Account AWS, ask if they support [AWS cross-account access](https://docs.aws.amazon.com//latest/UserGuide/id_roles_common-scenarios_third-party.html) (Accesso multi-account AWS). For mobile apps, consider using temporary credentials through [Pool di identità di Amazon Cognito (identità federate)](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html). For workloads running outside of AWS, consider [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) or [Attivazioni ibride AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html).  | 
|  SSH keys  |  Secure Shell private keys used to log into Linux EC2 instances, manually or as part of an automated process  |  Replace: Use [AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/) or [EC2 Instance Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html) to provide programmatic and human access to EC2 instances using IAM roles.  | 
|  Application and database credentials  |  Passwords – plain text string  |  Rotate: Store credentials in [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) and establish automated rotation if possible.  | 
|  Amazon RDS and Aurora Admin Database credentials  |  Passwords – plain text string  |  Replace: Use the [Secrets Manager integration with Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html) (Integrazione di Secrets Manager con Amazon RDS) or [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html). In addition, some RDS database types can use IAM roles instead of passwords for some use cases (for more detail, see [IAM database authentication](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.DBAuth.html) (Autenticazione del database IAM)).  | 
|  OAuth tokens  |  Secret tokens – plain text string  |  Rotate: Store tokens in [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) and configure automated rotation.  | 
|  API tokens and keys  |  Secret tokens – plain text string  |  Rotate: Store in [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) and establish automated rotation if possible.  | 

 Un anti-pattern comune è quello di incorporare le chiavi di accesso IAM all'interno del codice sorgente, dei file di configurazione o delle applicazioni mobili. Quando è richiesta una chiave di accesso IAM per comunicare con un servizio AWS, utilizza le [credenziali di sicurezza temporanee (a breve termine)](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_temp.html). Queste credenziali a breve termine possono essere fornite attraverso [ruoli IAM per istanze EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html), [ruoli di esecuzione](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) per funzioni Lambda, [ruoli Cognito IAM](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html) per l'accesso degli utenti di dispositivi mobili e [policy IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policies.html) per i dispositivi IoT. Quando ci si interfaccia con terze parti, è preferibile [delegare l'accesso a un ruolo IAM](https://docs.aws.amazon.com//latest/UserGuide/id_roles_common-scenarios_third-party.html) con l'accesso necessario alle risorse del proprio account, piuttosto che configurare un utente IAM e inviare alla terza parte la chiave di accesso segreta per quell'utente. 

 In molti casi il carico di lavoro richiede la memorizzazione di segreti necessari per l'interoperabilità con altri servizi e risorse. [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) è costruito appositamente per gestire in modo sicuro queste credenziali, nonché l'archiviazione, l'uso e la rotazione di token API, password e altre credenziali. 

 Gestione dei segreti AWS fornisce cinque funzionalità chiave per garantire l'archiviazione e la gestione sicura delle credenziali sensibili: [crittografia a riposo](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html), [crittografia in transito](https://docs.aws.amazon.com/secretsmanager/latest/userguide/data-protection.html), [audit completo](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html), [controllo degli accessi granulare](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html) e [rotazione estensibile delle credenziali](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html). Sono accettabili anche altri servizi di gestione dei segreti dei partner AWS o soluzioni sviluppate localmente che forniscano funzionalità e garanzie simili. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Individuare i percorsi di codice contenenti credenziali hard-coded utilizzando strumenti automatizzati come [Amazon CodeGuru](https://aws.amazon.com/codeguru/features/). 
   +  Utilizzare Amazon CodeGuru per eseguire la scansione dei repository di codice. Una volta completata la revisione, filtrare `Type=Secrets` in CodeGuru per trovare le linee di codice problematiche. 

1.  Identificare le credenziali che possono essere rimosse o sostituite. 

   1.  Identificare le credenziali non più necessarie e contrassegnarle per la rimozione. 

   1.  Le chiavi segrete AWS incorporate nel codice sorgente devono essere sostituite con ruoli IAM associati alle risorse necessarie. Se una parte del carico di lavoro è al di fuori di AWS ma richiede le credenziali IAM per accedere alle risorse AWS, considerare [IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/) o [Attivazioni ibride AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html). 

1.  Per altri segreti di terze parti a lunga durata che richiedono l'uso della strategia di rotazione, integrare Secrets Manager nel codice per recuperare i segreti di terze parti in fase di esecuzione. 

   1.  La console CodeGuru può [creare un segreto in Secrets Manager](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/) automaticamente utilizzando le credenziali individuate. 

   1.  Integrare il recupero dei segreti da Secrets Manager nel codice dell'applicazione. 
      +  Le funzioni Lambda serverless possono utilizzare un'[estensione Lambda](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html) indipendente dal linguaggio. 
      +  Per le istanze o i container EC2, AWS fornisce esempi di [codice lato client per il recupero dei segreti da Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) in diversi linguaggi di programmazione popolari. 

1.  Esaminare periodicamente la base di codice e ripetere la scansione per verificare che non siano stati aggiunti nuovi segreti al codice. 
   +  Valutare l'utilizzo di uno strumento come [git-secrets](https://github.com/awslabs/git-secrets) per impedire il commit di nuovi segreti nel repository del codice sorgente. 

1.  [Monitorare l'attività di Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html) per rilevare indicazioni di utilizzo inatteso, accesso inappropriato ai segreti o tentativi di cancellazione dei segreti. 

1.  Ridurre l'esposizione umana alle credenziali. Limitare l'accesso alle credenziali di lettura, scrittura e modifica a un ruolo IAM dedicato a questo scopo e fornire l'accesso per assumere il ruolo solo a un piccolo sottoinsieme di utenti operativi. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+ [SEC02-BP02 Utilizzo di credenziali temporanee](sec_identities_unique.md)
+ [SEC02-BP05 Verifica e rotazione periodica delle credenziali](sec_identities_audit.md)

 **Documenti correlati:** 
+  [Nozioni di base su Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [Provider di identità e federazione](https://docs.aws.amazon.com//latest/UserGuide/id_roles_providers.html) 
+  [Amazon CodeGuru Introduces Secrets Detector](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/) (Amazon CodeGuru introduce il rivelatore di segreti) 
+  [How Gestione dei segreti AWS uses AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/services-secrets-manager.html)(In che modo AWS Secrets Manager utilizza AWS Key Management Service) 
+  [Crittografia e decrittografia del segreto in Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html) 
+  [Articoli del blog su Secrets Manager](https://aws.amazon.com/blogs/security/tag/aws-secrets-manager/) 
+  [Amazon RDS announces integration with Gestione dei segreti AWS](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-rds-integration-aws-secrets-manager/) (Amazon RDS announces integration with AWS Secrets Manager) 

 **Video correlati:** 
+  [Best practice per la gestione, il recupero e la rotazione di segreti su scala](https://youtu.be/qoxxRlwJKZ4) 
+  [Find Hard-Coded Secrets Using Amazon CodeGuru Secrets Detector](https://www.youtube.com/watch?v=ryK3PN--oJs) (Trovare i segreti codificati usando il rilevatore di segreti di Amazon CodeGuru) 
+  [Securing Secrets for Hybrid Workloads Using Gestione dei segreti AWS](https://www.youtube.com/watch?v=k1YWhogGVF8) (Trovare i segreti codificati usando il rilevatore di segreti di Amazon CodeGuru) 

 **Workshop correlati:** 
+  [Store, retrieve, and manage sensitive credentials in Gestione dei segreti AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/497b4908-169f-4e6f-b80d-ef10be3038d3/en-US) (Memorizzare, recuperare e gestire le credenziali sensibili in AWS Secrets Manager) 
+  [Attivazioni ibride AWS Systems Manager](https://mng.workshop.aws/ssm/capability_hands-on_labs/hybridactivations.html) 

# SEC02-BP04 Fai affidamento su un provider di identità centralizzato
<a name="sec_identities_identity_provider"></a>

 Per le identità della forza lavoro (dipendenti e collaboratori) affidati a un provider di identità digitale che ti consenta di gestire le identità in un luogo centralizzato. In questo modo è più semplice gestire l'accesso tra più applicazioni e sistemi, perché crei, assegni, gestisci, revochi e verifichi gli accessi da una singola posizione. 

 **Risultato desiderato:** Hai un provider di identità centralizzato dal quale gestisci centralmente gli utenti della forza lavoro, le policy di autenticazione (come le richieste di autenticazione a più fattori o MFA) e le autorizzazioni per sistemi e applicazioni, come l'assegnazione dell'accesso in base all'appartenenza o agli attributi di un utente. Gli utenti che fanno parte della tua forza lavoro accedono al provider di identità centrale ed effettuano l'accesso federato (autenticazione unica) alle applicazioni interne ed esterne, il che elimina la necessità per gli utenti di ricordare più credenziali. Il provider di identità è integrato con i tuoi sistemi di risorse umane (HR), in modo che le modifiche relative al personale vengano sincronizzate automaticamente con il provider di identità. Ad esempio, se qualcuno lascia l'organizzazione, puoi revocare automaticamente l'accesso alle applicazioni e ai sistemi federati (incluso AWS). Hai abilitato la verifica dettagliata dei log nel tuo provider di identità e stai monitorando questi log per rilevare comportamenti degli utenti insoliti. 

 **Anti-pattern comuni:** 
+  Non utilizzi la federazione e l'autenticazione unica. Gli utenti che appartengono alla tua forza lavoro creano account utente e credenziali separati in più applicazioni e sistemi. 
+  Non hai automatizzato il ciclo di vita delle identità degli utenti che fanno parte della tua forza lavoro, ad esempio integrando il provider di identità con i tuoi sistemi HR. Quando un utente lascia l'organizzazione o cambia ruolo, segui una procedura manuale per eliminare o aggiornare i suoi record in più applicazioni e sistemi. 

 **Vantaggi dell'adozione di questa best practice:** Utilizzare un provider di identità centralizzato ti fornisce un unico posto per gestire le identità e le policy degli utenti che fanno parte della tua forza lavoro, la possibilità di assegnare l'accesso alle applicazioni a utenti e gruppi e la possibilità di monitorare l'attività di accesso degli utenti. Grazie all'integrazione con i sistemi di risorse umane (HR), quando un utente cambia ruolo, queste modifiche vengono sincronizzate con il provider di identità e le applicazioni e le autorizzazioni assegnate vengono aggiornate automaticamente. Quando un utente lascia l'organizzazione, la sua identità viene automaticamente disabilitata nel provider di identità e l'accesso alle applicazioni e ai sistemi federati viene revocato. 

 **Livello di rischio associato se questa best practice non fosse adottata**: elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 **Linee guida per l'accesso ad AWS degli utenti che fanno parte della forza lavoro** 

 Gli utenti che fanno parte della forza lavoro, come dipendenti e collaboratori dell'organizzazione, potrebbero richiedere l'accesso ad AWS per utilizzare la Console di gestione AWS o la AWS Command Line Interface (AWS CLI) per svolgere le proprie mansioni lavorative. Puoi concedere l'accesso ad AWS a tali utenti federando il tuo provider di identità centralizzato AWS a due livelli: federazione diretta a ciascun Account AWS o federazione a più account della tua [organizzazione AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html). 
+  Per federare gli utenti della tua forza lavoro direttamente con ciascuno Account AWS, utilizza un provider di identità centralizzato per federare l'accesso a [AWS Identity and Access Management](https://aws.amazon.com/iam/) in quell'account. Grazie alla sua flessibilità, IAM ti permette di abilitare un [SAML 2.0](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html) o un [Open ID Connect (OIDC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) Identity Provider per ciascun Account AWS e di utilizzare attributi utente federati per il controllo degli accessi. Gli utenti della tua forza lavoro utilizzano il proprio browser Web per accedere al provider di identità e forniscono le proprie credenziali (come password e codici token MFA). Il provider di identità rilascia un'asserzione SAML nel browser che viene inviata all'URL di accesso della Console di gestione AWS, così da consentire all'utente di accedere mediante l'autenticazione unica alla [Console di gestione AWS tramite l'assunzione di un ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html). Gli utenti possono anche ottenere credenziali API AWS temporanee da utilizzare nella [AWS CLI](https://aws.amazon.com/cli/) o [AWS SDK](https://aws.amazon.com/developer/tools/) da [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) tramite [l'assunzione del ruolo IAM utilizzando un'asserzione SAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) ottenuta dal provider di identità. 
+  Per federare gli utenti della tua forza lavoro con più account all'interno dell'organizzazione AWS, puoi usare [https://aws.amazon.com/single-sign-on/](https://aws.amazon.com/single-sign-on/) per gestire centralmente l'accesso degli utenti agli Account AWS e alle applicazioni. Attiva Centro di identità per la tua organizzazione e configura la tua origine di identità. IAM Identity Center fornisce una directory di origine delle identità predefinita, che puoi utilizzare per gestire utenti e gruppi. In alternativa, puoi scegliere un'origine di identità esterna [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html) tramite SAML 2.0 ed [effettuando il provisioning automatico](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html) di utenti e gruppi che utilizzano SCIM, oppure [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html) utilizzando [Directory Service](https://aws.amazon.com/directoryservice/). Una volta configurata un'origine di identità, puoi assegnare l'accesso agli Account AWS a utenti e gruppi, definendo policy di privilegio minimo nel tuo [set di autorizzazioni](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html). Gli utenti della tua forza lavoro possono autenticarsi tramite il provider di identità centrale per accedere al [portale di accesso AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/using-the-portal.html) ed effettuare l'autenticazione unica per ottenere l'accesso agli Account AWS e alle applicazioni cloud a loro assegnate. Gli utenti possono configurare [AWS CLI v2](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) per autenticarsi con Centro di identità e ottenere le credenziali per eseguire comandi della AWS CLI. Centro di identità consente inoltre l'accesso tramite autenticazione unica ad applicazioni AWS come [Amazon SageMaker AI Studio](https://docs.aws.amazon.com/sagemaker/latest/dg/onboard-sso-users.html) e [ai portali AWS IoT Sitewise Monitor](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/monitor-getting-started.html). 

 Dopo aver seguito le indicazioni precedenti, gli utenti della forza lavoro non avranno più bisogno di utilizzare IAM users e gruppi per le normali operazioni quando gestiscono i carichi di lavoro su AWS. Al contrario, gli utenti e i gruppi sono gestiti all'esterno di AWS e gli utenti possono accedere alle risorse AWS come *identità federata*. Le identità federate utilizzano i gruppi definiti dal provider di identità centralizzato. Devi identificare e rimuovere i gruppi IAM, gli IAM users e le credenziali utente di lunga durata (password e chiavi di accesso) che non sono più necessarie nei tuoi Account AWS. Puoi [trovare credenziali inutilizzate](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html) utilizzando [il report sulle credenziali IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html), [eliminare gli IAM users interessati](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html) e [rimuovere i gruppi IAM.](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_delete.html) Puoi applicare una [policy di controllo dei servizi (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) alla tua organizzazione per prevenire la creazione di nuovi IAM users e gruppi, applicando l'accesso ad AWS tramite identità federate. 

 **Linee guida per gli utenti delle tue applicazioni** 

 Puoi gestire le identità degli utenti delle applicazioni, ad esempio un'app per dispositivi mobili, utilizzando [https://aws.amazon.com/cognito/](https://aws.amazon.com/cognito/) come provider di identità centralizzato. Amazon Cognito consente l'autenticazione, l'autorizzazione e la gestione degli utenti per le app Web e mobili. Amazon Cognito fornisce un archivio di identità dimensionabile fino a milioni di utenti, supporta la federazione delle identità sociali e aziendali e offre funzionalità di sicurezza avanzate per proteggere gli utenti e l'azienda. Puoi integrare la tua applicazione Web o mobile personalizzata con Amazon Cognito per aggiungere l'autenticazione degli utenti e il controllo degli accessi alle applicazioni in pochi minuti. Amazon Cognito si fonda su standard di identità aperti come SAML e Open ID Connect (OIDC), supporta varie normative di conformità e si integra con le risorse di sviluppo frontend e backend. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

 **Procedure per l'accesso ad AWS degli utenti che fanno parte della forza lavoro** 
+  Federa l'accesso ad AWS degli utenti della tua forza lavoro tramite un provider di identità centralizzato seguendo uno dei seguenti approcci: 
  +  Utilizza IAM Identity Center per abilitare l'autenticazione unica negli Account AWS per più utenti della tua organizzazione AWS tramite la federazione con il provider di identità. 
  +  Utilizza IAM per connettere il provider di identità direttamente a ciascun Account AWS, abilitando un accesso federato e granulare. 
+  Identifica e rimuovi gli IAM users e i gruppi che vengono sostituiti da identità federate. 

 **Passaggi per gli utenti delle tue applicazioni** 
+  Utilizza Amazon Cognito come provider di identità centralizzato per le tue applicazioni. 
+  Integra le applicazioni personalizzate con Amazon Cognito utilizzando OpenID Connect e OAuth. Puoi sviluppare applicazioni personalizzate utilizzando le librerie Amplify, che forniscono interfacce semplici da integrare con una varietà di servizi AWS per l'autenticazione, come Amazon Cognito. 

## Risorse
<a name="resources"></a>

 **Best practice Well-Architected correlate:** 
+  [SEC02-BP06 Utilizzo dei gruppi di utenti e degli attributi](sec_identities_groups_attributes.md) 
+  [SEC03-BP02 Concessione dell'accesso con privilegio minimo](sec_permissions_least_privileges.md) 
+  [SEC03-BP06 Gestione degli accessi in base al ciclo di vita](sec_permissions_lifecycle.md) 

 **Documenti correlati:** 
+  [Identity federation in AWS](https://aws.amazon.com/identity/federation/) 
+  [Best practice per la sicurezza in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [AWS Identity and Access Management Best practices](https://aws.amazon.com/iam/resources/best-practices/) 
+  [Getting started with IAM Identity Center delegated administration](https://aws.amazon.com/blogs/security/getting-started-with-aws-sso-delegated-administration/) 
+  [How to use customer managed policies in IAM Identity Center for advanced use cases](https://aws.amazon.com/blogs/security/how-to-use-customer-managed-policies-in-aws-single-sign-on-for-advanced-use-cases/) 
+  [AWS CLI v2: IAM Identity Center credential provider](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sso-credentials.html) 

 **Video correlati:** 
+  [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive](https://youtu.be/YMj33ToS8cI) 
+  [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://youtu.be/TvQN4OdR_0Y) 
+  [AWS re:Invent 2018: Mastering Identity at Every Layer of the Cake](https://youtu.be/vbjFjMNVEpc) 

 **Esempi correlati:** 
+  [Workshop: Using AWS IAM Identity Center to achieve strong identity management](https://catalog.us-east-1.prod.workshops.aws/workshops/590f8439-42c7-46a1-8e70-28ee41498b3a/en-US) 
+  [Workshop: Serverless identity](https://identity-round-robin.awssecworkshops.com/serverless/) 

 **Strumenti correlati:** 
+  [Partner AWS con competenze nella sicurezza: gestione di identità e accessi](https://aws.amazon.com/security/partner-solutions/) 
+  [saml2aws](https://github.com/Versent/saml2aws) 

# SEC02-BP05 Verifica e rotazione periodica delle credenziali
<a name="sec_identities_audit"></a>

Sottoponi a audit e ruota periodicamente le credenziali per limitarne il tempo di utilizzo per accedere alle risorse. Le credenziali a lungo termine espongono a molti rischi che possono essere ridotti ruotandole regolarmente.

 **Risultato desiderato:** implementare la rotazione delle credenziali per ridurre i rischi associati all'utilizzo a lungo termine. Esegui regolarmente l'audit e rimedia alla non conformità con le policy di rotazione delle credenziali. 

 **Anti-pattern comuni:** 
+  Nessun audit dell'uso delle credenziali. 
+  Utilizzo non necessario di credenziali a lungo termine. 
+  Utilizzo di credenziali a lungo termine e mancata rotazione regolare. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Quando non si può fare affidamento sulle credenziali temporanee e sono necessarie credenziali a lungo termine, sottoponile a audit per assicurarti che siano applicati i controlli prestabiliti, ad esempio l'autenticazione a più fattori (MFA), che siano soggette a regolare rotazione e dispongano di un livello di accesso appropriato. 

 La convalida periodica, preferibilmente tramite uno strumento automatizzato, è necessaria per verificare che vengano applicati i controlli corretti. Per le identità umane, è necessario richiedere agli utenti di modificare periodicamente le password e ritirare le chiavi di accesso a favore delle credenziali temporanee. Quando passi da utenti AWS Identity and Access Management (IAM) a identità centralizzate, puoi [generare un report delle credenziali](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html) per effettuare l'audit degli utenti. 

 Ti consigliamo inoltre di monitorare l'MFA nel tuo provider di identità. Puoi configurare [Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) o utilizzare gli [standard di sicurezza AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html#fsbp-iam-3) per verificare se gli utenti hanno l'MFA abilitata. Considera la possibilità di utilizzare IAM Roles Anywhere per fornire credenziali temporanee per le identità macchina. Nelle situazioni in cui l'utilizzo di credenziali temporanee e ruoli IAM non è possibile, è necessario un audit frequente e la rotazione delle chiavi di accesso. 

 **Passaggi dell'implementazione** 
+  **Eseguire regolarmente l'audit delle credenziali:** l'audit delle identità configurate nel provider di identità e in IAM aiuta a verificare che solo le identità autorizzate abbiano accesso al carico di lavoro. Tali identità possono includere, a titolo esemplificativo ma non esaustivo, utenti IAM, utenti AWS IAM Identity Center, utenti Active Directory o utenti in un diverso provider di identità a monte. Ad esempio, eliminare le persone che lasciano l'organizzazione e i ruoli multi-account che non sono più necessari. Disporre di un processo per sottoporre periodicamente a audit le autorizzazioni ai servizi a cui accede un'entità IAM. Questo aiuta a identificare le policy da modificare per rimuovere le autorizzazioni non utilizzate. Utilizza i report delle credenziali e [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) per eseguire l'audit di autorizzazioni e credenziali IAM. Puoi utilizzare [Amazon CloudWatch per configurare allarmi per chiamate API specifiche](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) effettuate nell'ambiente AWS. [Amazon GuardDuty può anche avvisare di attività impreviste](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html), che potrebbero indicare un accesso estremamente permissivo o un accesso non intenzionale alle credenziali IAM. 
+  **Ruota regolarmente le credenziali:** quando non è possibile utilizzare le credenziali temporanee, ruotare regolarmente le chiavi di accesso IAM a lungo termine, al massimo ogni 90 giorni. Se una chiave di accesso viene involontariamente divulgata a propria insaputa, questo limita la durata di utilizzo delle credenziali per accedere alle risorse. Per informazioni sulla rotazione delle chiavi di accesso per gli utenti IAM, consulta [Rotating access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey). 
+  **Rivedi le autorizzazioni IAM:** per migliorare la sicurezza dell'Account AWS, rivedere e monitorare regolarmente ogni policy IAM. Verifica che le policy rispettino il principio del privilegio minimo. 
+  **Considera la possibilità di automatizzare la creazione e gli aggiornamenti delle risorse IAM:** IAM Identity Center automatizza molte attività IAM, come la gestione dei ruoli e delle policy. In alternativa, AWS CloudFormation può essere utilizzato per automatizzare l'implementazione delle risorse IAM, compresi ruoli e policy, per ridurre la possibilità di errore umano, poiché i modelli possono essere verificati e controllati in versione. 
+  **Utilizza IAM Roles Anywhere per sostituire gli utenti IAM per le identità macchina:** IAM Roles Anywhere consente di utilizzare i ruoli in aree tradizionalmente non accessibili, come i server on-premise. IAM Roles Anywhere utilizza un certificato X.509 affidabile per autenticarsi ad AWS e ricevere credenziali temporanee. L'utilizzo di IAM Roles Anywhere evita la necessità di ruotare queste credenziali, poiché le credenziali a lungo termine non vengono più memorizzate nell'ambiente on-premise. È necessario monitorare e ruotare il certificato X.509 quando si avvicina alla scadenza. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [SEC02-BP02 Utilizzo di credenziali temporanee](sec_identities_unique.md) 
+  [SEC02-BP03 Archiviazione e utilizzo dei segreti in modo sicuro](sec_identities_secrets.md) 

 **Documenti correlati:** 
+  [Nozioni di base su Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [IAM Best Practices](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html)(Best Practice IAM) 
+  [Provider di identità e federazione](https://docs.aws.amazon.com//latest/UserGuide/id_roles_providers.html) 
+  [Soluzioni dei partner per la sicurezza: accesso e controllo degli accessi](https://aws.amazon.com/security/partner-solutions/#access-control) 
+  [Credenziali di sicurezza temporanee](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_temp.html) 
+ [ Recupero dei report delle credenziali per l'Account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)

 **Video correlati:** 
+  [Best practice per la gestione, il recupero e la rotazione di segreti su scala](https://youtu.be/qoxxRlwJKZ4) 
+  [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E) (Gestire le autorizzazioni degli utenti su larga scala con AWS SSO) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

 **Esempi correlati:** 
+ [ Well-Architected Lab - Automated IAM User Cleanup ](https://wellarchitectedlabs.com/security/200_labs/200_automated_iam_user_cleanup/)(Well-Architected Lab - Pulizia automatica degli utenti IAM)
+ [ Well-Architected Lab - Automated Deployment of IAM Groups and Roles ](https://wellarchitectedlabs.com/security/200_labs/200_automated_deployment_of_iam_groups_and_roles/)(Well-Architected Lab - Distribuzione automatica di gruppi e ruoli IAM)

# SEC02-BP06 Utilizzo dei gruppi di utenti e degli attributi
<a name="sec_identities_groups_attributes"></a>

 Man mano che il numero di utenti gestiti cresce, sarà necessario determinare i modi per organizzarli in modo da poterli gestire su vasta scala. Inserisci gli utenti con requisiti di sicurezza comuni in gruppi definiti dal provider di identità e metti in atto meccanismi per garantire che gli attributi utente che potrebbero essere utilizzati per il controllo degli accessi (ad esempio, reparto o posizione) siano corretti e aggiornati. Utilizza questi gruppi e attributi, anziché i singoli utenti, per controllare l'accesso. In questo modo puoi gestire l'accesso centralmente, modificando una volta sola l'appartenenza o gli attributi di un gruppo utente con un [set di autorizzazioni](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsets.html), anziché aggiornare numerose policy individuali quando le esigenze di accesso di un utente cambiano. Puoi utilizzare AWS IAM Identity Center (IAM Identity Center) per gestire gruppi di utenti e attributi. IAM Identity Center supporta la maggior parte degli attributi utilizzati, indipendentemente dal fatto che vengano inseriti manualmente durante la creazione dell'utente o assegnati automaticamente utilizzando un motore di sincronizzazione, come definito nella specifica System for Cross-Domain Identity Management (SCIM). 

Inserisci gli utenti con requisiti di sicurezza comuni in gruppi definiti dal provider di identità e metti in atto meccanismi per garantire che gli attributi utente che potrebbero essere utilizzati per il controllo degli accessi (ad esempio, reparto o posizione) siano corretti e aggiornati. Utilizza questi gruppi e attributi, anziché i singoli utenti, per controllare l'accesso. In questo modo è possibile gestire l'accesso centralmente, modificando una volta sola l'appartenenza o gli attributi di un gruppo utente, anziché aggiornare numerose policy individuali quando le esigenze di accesso di un utente cambiano.

 **Livello di rischio associato se questa best practice non fosse adottata:** Basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Se stai utilizzando AWS IAM Identity Center (IAM Identity Center), configura i gruppi: IAM Identity Center offre la possibilità di configurare gruppi di utenti e di assegnare ai gruppi il livello di autorizzazione desiderato. 
  +  [AWS Single Sign-On - Gestione delle identità](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html) 
+  Scopri il controllo degli accessi basato su attributi (ABAC): ABAC è una strategia di autorizzazione che definisce i permessi in base agli attributi. 
  +  [Che cos'è ABAC per AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
  +  [Laboratorio: controllo degli accessi basato su tag IAM per EC2](https://www.wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Nozioni di base su AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [Best practice IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [Provider di identità e federazione](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) 
+  [L'utente root dell'account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) 

 **Video correlati:** 
+  [Best practice per la gestione, il recupero e la rotazione di segreti su scala](https://youtu.be/qoxxRlwJKZ4) 
+  [Gestione delle autorizzazioni utente su scala con AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

 **Esempi correlati:** 
+  [Laboratorio: controllo degli accessi basato su tag IAM per EC2](https://www.wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html) 