# Gestione dell’identità e degli accessi
**Topics**
+ [
# SEC 2. Come si gestisce l'autenticazione per persone e macchine?
](sec-02.md)
+ [
# SEC 3. Come si gestiscono le autorizzazioni per persone e macchine?
](sec-03.md)
# SEC 2. Come si gestisce l'autenticazione per persone e macchine?
Ci sono due tipi di identità da gestire quando inizi a utilizzare carichi di lavoro AWS sicuri.
+ **Identità umane:** le identità umane che richiedono l'accesso agli ambienti e alle applicazioni AWS possono essere classificate in tre gruppi, ossia forza lavoro, terze parti e utenti.
Il gruppo della *forza lavoro* include amministratori, sviluppatori e operatori che sono membri dell'organizzazione. Hanno bisogno dell'accesso per gestire, creare e utilizzare le risorse AWS.
Il gruppo delle *terze parti* include collaboratori esterni, come appaltatori, fornitori o partner. Interagiscono con le risorse AWS nell'ambito del loro rapporto di lavoro con l'organizzazione.
Il gruppo degli *utenti* include i consumatori delle applicazioni. Accedono alle risorse AWS tramite browser web, applicazioni client, app per dispositivi mobili o strumenti da riga di comando interattivi.
+ **Identità di macchine:** le applicazioni per il carico di lavoro, gli strumenti operativi e i componenti necessitano di un'identità per effettuare richieste ai servizi AWS, ad esempio la lettura dei dati. Queste identità includono anche macchine in esecuzione all'interno dell'ambiente AWS, come le istanze Amazon EC2 o le funzioni AWS Lambda. Puoi anche gestire le identità di macchine per soggetti esterni, o per macchine al di fuori di AWS, che richiedono l'accesso all'ambiente AWS.
**Topics**
+ [
# SEC02-BP01 Utilizzo di 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 gestore dell'identità digitale centralizzato
](sec_identities_identity_provider.md)
+ [
# SEC02-BP05 Verifica e rotazione periodica delle credenziali
](sec_identities_audit.md)
+ [
# SEC02-BP06 Impiego dei gruppi di utenti e degli attributi
](sec_identities_groups_attributes.md)
# SEC02-BP01 Utilizzo di meccanismi di accesso efficaci
Gli accessi (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 tali rischi, richiedendo l’MFA e policy sulle password sicure.
**Risultato desiderato:** ridurre i rischi di accessi accidentali alle credenziali AWS utilizzando meccanismi di accesso avanzati 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) e i gestori dell’identità digitale 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
Ci sono diversi modi in cui le identità umane possono accedere a AWS. È una best practice di AWS affidarsi a un gestore dell’identità digitale centralizzato utilizzando la federazione (federazione diretta SAML 2.0 tra AWS IAM e l’IdP centralizzato o utilizzando Centro identità AWS IAM) per l’autenticazione ad AWS. In questo caso, stabilisci un processo di accesso sicuro con il gestore dell’identità digitale o con Microsoft Active Directory.
Quando apri un Account AWS, inizi con un utente root Account AWS. L’utente root dell’account va utilizzato solo per configurare l’accesso degli utenti (e per le [attività che richiedono l’utente root](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)). È importante attivare l’autenticazione a più fattori (MFA) per l’utente root dell’account subito dopo l’apertura dell’Account AWS e proteggere l’utente root utilizzando la [guida alle best practice di AWS](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_aws_account.html).
Centro identità AWS IAM è progettato per gli utenti della forza lavoro; puoi creare e gestire le identità degli utenti all’interno del servizio e proteggere il processo di accesso con l’MFA. AWS Cognito, invece, è progettato per la gestione di identità e accessi del cliente (CIAM), che fornisce pool di utenti e gestore dell’identità digitale per le identità degli utenti esterni nelle applicazioni.
Se crei utenti in Centro identità AWS IAM, proteggi il processo di accesso in tale servizio e [attiva MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html). Per le identità degli utenti esterni nelle applicazioni, puoi utilizzare i [pool di utenti di Amazon Cognito](https://docs.aws.amazon.com/cognito/index.html) e proteggere il processo di accesso in tale servizio o attraverso uno dei gestori dell’identità digitale supportati nei pool di utenti di Amazon Cognito.
Inoltre, per gli utenti in Centro identità AWS IAM, puoi utilizzare [Accesso verificato da AWS](https://docs.aws.amazon.com/verified-access/latest/ug/what-is-verified-access.html) per fornire un ulteriore livello di sicurezza, verificando l’identità e la postura del dispositivo dell’utente prima che venga concesso l’accesso alle risorse AWS.
Se utilizzi utenti [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/), proteggi il processo di accesso utilizzando IAM.
Puoi utilizzare contemporaneamente Centro identità AWS IAM e federazione diretta IAM per gestire l’accesso ad AWS. Puoi utilizzare la federazione IAM per gestire l’accesso a Console di gestione AWS e ai servizi e Centro identità IAM per gestire l’accesso ad applicazioni aziendali come QuickSight o Amazon Q Business.
Indipendentemente dal metodo di accesso, è fondamentale applicare una policy di accesso efficace.
### Passaggi dell’implementazione
Di seguito sono indicate raccomandazioni generali per l’accesso sicuro. Configura le impostazioni effettive in base alla policy aziendale. In alternativa, utilizza uno standard, come [NIST 800-63](https://pages.nist.gov/800-63-3/sp800-63b.html).
+ Richiedi MFA. È una [best practice IAM richiedere l’MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users) per identità umane e carichi di lavoro. L’attivazione 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 a livello crittografico da un dispositivo hardware.
+ Applica una lunghezza minima della password, fattore primario nell’efficacia della password.
+ Applica la complessità delle password in modo che sia più difficile individuarle.
+ Consenti agli utenti di cambiare le loro password.
+ Crea identità individuali invece di credenziali condivise. Creando identità individuali, puoi assegnare a ciascun utente un set unico di credenziali di sicurezza. I singoli utenti consentono di sottoporre ad audit l’attività di ciascuno.
Consigli del Centro identità IAM:
+ Il Centro identità IAM offre una [policy sulle password](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html) prestabilita in caso di utilizzo della directory predefinita che stabilisce lunghezza, complessità e requisiti di riutilizzo della password.
+ [Attiva l’MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-enable-how-to.html) e configura l’impostazione relativa alla sensibilità al contesto o all’attivazione costante per l’MFA quando l’origine di 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).
Consigli sulle directory dei pool di utenti Amazon Cognito:
+ Configura le impostazioni relative alla [complessità 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.
+ Le [impostazioni di sicurezza avanzate](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-advanced-security.html) dei pool di utenti di Amazon Cognito offrono funzionalità come l’[autenticazione adattiva](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-adaptive-authentication.html), che può bloccare gli accessi sospetti.
Suggerimenti per l’utente IAM:
+ Idealmente stai utilizzando il Centro identità IAM o la federazione diretta. Tuttavia, potrebbero essere necessari utenti IAM. In tal caso, [imposta una policy sulle password](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) per gli utenti IAM. Puoi utilizzare la policy sulle 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 questo modo, gli utenti potranno gestire le proprie password e i propri dispositivi MFA.
## Risorse
**Best practice correlate:**
+ [SEC02-BP03 Archiviazione e utilizzo dei segreti in modo sicuro](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
+ [SEC02-BP04 Fai affidamento su un gestore dell’identità digitale centralizzato](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP08 Condivisione delle risorse in modo sicuro all’interno dell’organizzazione](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html)
**Documenti correlati:**
+ [AWS IAM Identity Center Password Policy](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html)
+ [IAM user password policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)
+ [Setting the Account AWS root user password](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
+ [Amazon Cognito password policy](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html)
+ [AWS credentials](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html)
+ [IAM security best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
**Video correlati:**
+ [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E)
+ [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html). 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) o dell'[utente root Account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html). L'utilizzo della federazione per AWS o l'assunzione di un [ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) tramite altri metodi prevede la creazione di 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 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](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 gestore dell'identità digitale per accedere ad AWS utilizzando credenziali temporanee](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp). La federazione per gli utenti può essere effettuata sia con la [federazione diretta a ciascun Account AWS](https://aws.amazon.com/identity/federation/) sia utilizzando [Centro identità AWS IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) 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](https://aws.amazon.com/blogs/security/how-to-implement-federated-api-and-cli-access-using-saml-2-0-and-ad-fs/) o utilizzando il [Centro identità IAM](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.
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](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) e [policy basate su risorse](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html). Inoltre, puoi utilizzare il flusso delle credenziali client di [concessione di Amazon Cognito OAuth 2.0](https://docs.aws.amazon.com/cognito/latest/developerguide/federation-endpoints-oauth-grants.html) 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](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html) o i [pool di utenti Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-workloads-use-roles).
+ Per [Amazon Elastic Compute Cloud](https://aws.amazon.com/pm/ec2/) (Amazon EC2), puoi utilizzare i [ruoli per Amazon EC2](https://docs.aws.amazon.com/IAM/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 la concessione delle autorizzazioni di servizio](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) 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](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html).
+ Per sistemi on-premises o quelli eseguiti all'esterno di AWS che richiedono l'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 supportate e che richiedono l'uso di credenziali a lungo termine. In queste situazioni, [verifica e ruota periodicamente queste credenziali](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html) e [ruota regolarmente le chiavi di accesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials). 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) (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 [Gestione dei segreti AWS](https://aws.amazon.com/secrets-manager/). Secrets Manager semplifica la gestione, la rotazione e l'archiviazione sicura dei segreti crittografati. Molti servizi AWS supportano l'[integrazione diretta](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html) 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](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)).
Per ulteriori informazioni sulla rotazione delle credenziali a lungo termine, consulta [rotazione delle chiavi di accesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey).
## Risorse
**Best practice correlate:**
+ [SEC02-BP03 Archiviazione e utilizzo dei segreti in modo sicuro](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
+ [SEC02-BP04 Fai affidamento su un gestore dell'identità digitale centralizzato](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP08 Condivisione delle risorse in modo sicuro all'interno dell'organizzazione](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html)
**Documenti correlati:**
+ [Temporary Security Credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [AWS Credenziali](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html)
+ [IAM Security Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)
+ [Centro identità IAM](https://aws.amazon.com/iam/identity-center/)
+ [Identity Providers and Federation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [Rotating Access Keys](https://docs.aws.amazon.com/IAM/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/IAM/latest/UserGuide/id_root-user.html)
+ [Access AWS using a Google Cloud Platform native workload identity](https://aws.amazon.com/blogs/security/access-aws-using-a-google-cloud-platform-native-workload-identity/)
+ [How to access AWS resources from Microsoft Entra ID tenants using AWS Security Token Service](https://aws.amazon.com/blogs/security/how-to-access-aws-resources-from-microsoft-entra-id-tenants-using-aws-security-token-service/)
**Video correlati:**
+ [Managing user permissions at scale with 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
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:** implementazione di un meccanismo per la gestione sicura delle credenziali delle applicazioni che consenta di raggiungere 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, laddove 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 è controllato tramite un'API (immaginala come un *distributore automatico di credenziali*).
+ L'accesso alle credenziali (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 segregato dal resto dell'architettura.
+ La distribuzione dei segreti avviene in automatico on demand ai componenti software e la rotazione avviene in una posizione centrale.
+ È possibile controllare l'accesso alle credenziali in modo granulare.
**Livello di rischio associato se questa best practice non fosse adottata**: elevato
## Guida all'implementazione
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 in automatico e sottoporre a audit il loro utilizzo.
Il modo migliore per affrontare la gestione dei segreti è seguire le indicazioni relative a rimozione, sostituzione e rotazione. Le credenziali più sicure sono quelle che non si devono memorizzare, gestire o trattare. Possono esserci credenziali non più necessarie per il funzionamento del carico di lavoro e che possono essere rimosse in modo sicuro.
Per le credenziali ancora necessarie per il corretto funzionamento del carico di lavoro, potrebbe esserci l'opportunità di sostituire le credenziali a lungo termine con credenziali temporanee o a breve termine. Ad esempio, invece di una codifica fissa di una chiave di accesso segreta AWS, si può pensare di sostituire le credenziali a lungo termine con credenziali temporanee utilizzando i ruoli IAM.
Alcuni segreti di lunga durata potrebbero non poter essere rimossi o sostituiti. È possibile archiviare tali segreti in un servizio come [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html), dove saranno archiviati, gestiti e rotati a livello centrale su base regolare.
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:
| Tipo di credenziali | Descrizione | Strategia suggerita |
| --- | --- | --- |
| Chiavi di accesso IAM | Chiavi segrete e accesso IAM AWS utilizzate per assumere ruoli IAM all'interno di un carico di lavoro | Sostituzione: utilizza invece [i ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios.html) assegnati alle istanze di calcolo (come [Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) o [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)). Per l'interoperabilità con terze parti che richiedono l'accesso alle risorse del tuo Account AWS, chiedi se supportano l'[accesso multi-account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html). Per le app mobili, prendi in considerazione l'utilizzo di credenziali temporanee tramite [pool di identità di Amazon Cognito (identità federate)](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html). Per i carichi di lavoro eseguiti all'esterno di AWS, valuta [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) o le [attivazioni ibride di AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html). Per i container, consulta il [ruolo IAM dell'attività di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) o il [ruolo IAM del nodo di Amazon ECS](https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html). |
| Chiavi SSH | Chiavi private Secure Shell utilizzate per accedere alle istanze Linux EC2, manualmente o nell'ambito di un processo automatizzato | Sostituzione: utilizza [AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/) o [EC2 Instance Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html) per fornire un accesso programmatico e umano alle istanze EC2 mediante i ruoli IAM. |
| Credenziali di applicazione e database | Password: stringa di testo semplice | Rotazione: memorizza le credenziali in [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) e, laddove possibile, stabilisci una rotazione automatica. |
| Credenziali del database di amministrazione Aurora e Amazon RDS | Password: stringa di testo semplice | Sostituzione: utilizza l'[integrazione di Secrets Manager con Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html) o [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-secrets-manager.html). Inoltre, alcuni tipi di database RDS possono utilizzare i ruoli IAM anziché le password per alcuni casi d'uso (per maggiori dettagli, consulta [Autenticazione del database IAM](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html)). |
| Token OAuth | Token segreti: stringa di testo semplice | Rotazione: archivia i token in [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) e configura la rotazione automatica. |
| Token e chiavi API | Token segreti: stringa di testo semplice | Rotazione: archivia in [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) e stabilisci una rotazione automatica, laddove possibile. |
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. Se occorre una chiave di accesso IAM per la comunicazione con un servizio AWS, utilizza [credenziali di sicurezza temporanee (a breve termine)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html). È possibile fornire queste credenziali a breve termine tramite [ruoli IAM per le 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 le funzioni Lambda, [ruoli IAM di Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html) per l'accesso degli utenti mobili e [policy IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policies.html) per i dispositivi IoT. Nell'interfacciarsi con terze parti, è preferibile [delegare l'accesso a un ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) con l'accesso necessario alle risorse dell'account anziché configurare un utente IAM e inviare alla terza parte la chiave di accesso segreta per l'utente interessato.
Esistono molti casi in cui il carico di lavoro richiede l'archiviazione dei segreti necessari per l'interoperabilità con altri servizi e risorse. [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) è stato creato proprio 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 offre cinque funzionalità chiave per garantire la sicurezza di archiviazione e gestione 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 completi](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html), [controllo granulare degli accessi](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html) e [rotazione delle credenziali estensibile](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.
Quando si recupera un segreto, è possibile utilizzare il componente di caching lato client di Secrets Manager per memorizzarlo nella cache per un uso futuro. Il recupero di un segreto memorizzato nella cache è più veloce rispetto al recupero da Secrets Manager. Inoltre, poiché la chiamata alle API di Secrets Manager ha un costo, l'uso della cache può ridurre i costi. Per una descrizione di tutti i modi in cui è possibile recuperare i segreti, consulta [Ottieni segreti](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html).
**Nota**
Alcune lingue possono richiedere l'implementazione di una propria crittografia in memoria per la cache lato client.
### Passaggi dell'implementazione
1. Identifica i percorsi di codice con credenziali con codifica fissa mediante strumenti automatizzati come [Amazon CodeGuru](https://aws.amazon.com/codeguru/features/).
1. Utilizza Amazon CodeGuru per eseguire la scansione dei repository di codice. Una volta completata l'analisi, filtra su Type=Secrets in CodeGuru per trovare righe di codice problematiche.
1. Identifica le credenziali che possono essere rimosse o sostituite.
1. Identifica 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 parte del tuo carico di lavoro è al di fuori di AWS ma richiede credenziali IAM per accedere a risorse AWS, prendi in considerazione [IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/) o le [attivazioni ibride di 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, integra Secrets Manager nel codice per recuperare i segreti di terze parti in fase di esecuzione.
1. La console di CodeGuru può [creare in automatico un segreto in Secrets Manager](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/) utilizzando le credenziali scoperte.
1. Integra il recupero dei segreti da Secrets Manager nel codice dell'applicazione.
1. Le funzioni Lambda serverless possono utilizzare un'[estensione Lambda](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html) indipendente dal linguaggio.
1. Per container o istanze EC2, AWS fornisce un esempio di [codice lato client per il recupero di segreti da Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) in diversi linguaggi di programmazione diffusi.
1. Esamina periodicamente la base di codice e ripetere la scansione per verificare che non siano stati aggiunti nuovi segreti al codice.
1. Prendi in considerazione l'utilizzo di uno strumento come [git-secrets](https://github.com/awslabs/git-secrets) per evitare di inserire nuovi segreti nel tuo repository di codice sorgente.
1. [Monitora l'attività di Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html) per individuare eventuali indicazioni di utilizzo imprevisto, accesso inopportuno ai segreti o tentativi di eliminazione degli stessi.
1. Riduci l'esposizione umana alle credenziali. Limita l'accesso alle credenziali di lettura, scrittura e modifica a un ruolo IAM dedicato a questo scopo e fornisci l'accesso in modo che il ruolo sia assunto solo da un piccolo sottoinsieme di utenti operativi.
## Risorse
**Best practice correlate:**
+ [SEC02-BP02 Utilizzo di credenziali temporanee](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC02-BP05 Verifica e rotazione periodica delle credenziali](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html)
**Documenti correlati:**
+ [Nozioni di base su Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html)
+ [Identity Providers and Federation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [Amazon CodeGuru Introduces Secrets Detector](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/)
+ [How Gestione dei segreti AWS uses AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/services-secrets-manager.html)
+ [Secret encryption and decryption 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/)
**Video correlati:**
+ [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale](https://youtu.be/qoxxRlwJKZ4)
+ [Find Hard-Coded Secrets Using Amazon CodeGuru Secrets Detector](https://www.youtube.com/watch?v=ryK3PN--oJs)
+ [Securing Secrets for Hybrid Workloads Using Gestione dei segreti AWS](https://www.youtube.com/watch?v=k1YWhogGVF8)
**Workshop correlati:**
+ [Store, retrieve, and manage sensitive credentials in Gestione dei segreti AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/92e466fd-bd95-4805-9f16-2df07450db42/en-US)
+ [AWS Systems Manager Hybrid Activations](https://mng.workshop.aws/ssm/capability_hands-on_labs/hybridactivations.html)
# SEC02-BP04 Fai affidamento su un gestore dell'identità digitale centralizzato
Per le identità della forza lavoro (dipendenti e collaboratori) affidati a un gestore dell'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, poiché crei, assegni, gestisci, revochi e verifichi gli accessi da una singola posizione.
**Risultato desiderato:** hai un gestore dell'identità digitale dal quale gestisci centralmente gli utenti della forza lavoro, le policy di autenticazione (come le richieste di autenticazione a più fattori (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 gestore dell'identità digitale 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 gestore dell'identità digitale è integrato con i tuoi sistemi di risorse umane (HR), in modo che le modifiche relative al personale vengano sincronizzate in automatico con il gestore dell'identità digitale. 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 gestore dell'identità digitale e stai monitorando questi log per rilevare comportamenti degli utenti insoliti.
**Anti-pattern comuni:**
+ Non utilizzi federazione e 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 gestore dell'identità digitale 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 gestore dell'identità digitale centralizzato ti fornisce un'unica piattaforma 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 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 gestore dell'identità digitale e le applicazioni e le autorizzazioni assegnate si aggiornano in automatico. Quando un utente lascia l'organizzazione, la sua identità viene automaticamente disabilitata nel gestore dell'identità digitale 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
**Guida per gli utenti della forza lavoro che accedono a AWS** Gli utenti della forza lavoro, come i dipendenti e i collaboratori dell'organizzazione, possono richiedere l'accesso a AWS utilizzando la Console di gestione AWS o AWS Command Line Interface (AWS CLI) per svolgere le mansioni lavorative. Puoi concedere l'accesso ad AWS a tali utenti federando il tuo gestore dell'identità digitale 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 ciascun Account AWS, utilizza un gestore dell'identità digitale centralizzato per federare l'accesso ad [AWS Identity and Access Management](https://aws.amazon.com/iam/) in tale account. Grazie alla sua flessibilità, IAM ti consente di abilitare un gestore dell'identità digitale [SAML 2.0](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html) o [Open ID Connect (OIDC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) separato per ciascun Account AWS e di utilizzare attributi per gli utenti federati al fine di controllare gli accessi. Gli utenti della tua forza lavoro utilizzano il proprio browser Web per accedere al gestore dell'identità digitale e forniscono le proprie credenziali (come password e codici token MFA). Il gestore dell'identità digitale 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 assumendo un ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html). I tuoi utenti possono anche ottenere credenziali API AWS temporanee da [AWS CLI](https://aws.amazon.com/cli/) o [AWS SDK](https://aws.amazon.com/developer/tools/) di [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) [assumendo il ruolo IAM mediante un'asserzione SAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) proveniente dal gestore dell'identità digitale.
Per federare gli utenti della 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 a livello centrale l'accesso degli utenti della forza lavoro agli Account AWS e alle applicazioni. Puoi abilitare il Centro identità per la tua organizzazione e configurare la tua origine di identità. Centro identità IAM fornisce una directory di origine di identità predefinita, utilizzabile 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 e [allocando in automatico](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html) utenti e gruppi tramite 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) mediante [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 nei tuoi [set di autorizzazioni](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html). Gli utenti della tua forza lavoro possono autenticarsi tramite il tuo gestore dell'identità digitale centrale per accedere al [portale di accesso AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/using-the-portal.html) ed eseguire l'accesso tramite autenticazione unica per gli Account AWS e le 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 l'autenticazione con il Centro identità e ottenere le credenziali per eseguire i comandi AWS CLI. Il Centro identità consente inoltre l'accesso tramite SSO ad applicazioni AWS, come [Amazon SageMaker Studio IA](https://docs.aws.amazon.com/sagemaker/latest/dg/onboard-sso-users.html) e i [portali Sitewise AWS IoT](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 utenti IAM e gruppi per le normali operazioni quando gestiscono i carichi di lavoro su AWS. Gli utenti e i gruppi sono infatti gestiti all'esterno di AWS e sono in grado di accedere alle risorse AWS come *identità federata*. Le identità federate utilizzano i gruppi definiti dal gestore dell'identità digitale centralizzato. Devi identificare e rimuovere gruppi IAM, utenti IAM e credenziali utente di lunga durata (password e chiavi di accesso) non più necessarie nei tuoi Account AWS. Puoi [trovare le credenziali inutilizzate](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html) mediante i [report sulle credenziali IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html), [eliminare gli utenti IAM corrispondenti](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html) ed [eliminare i gruppi IAM.](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_delete.html) Puoi applicare una [policy di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) alla tua organizzazione, così da prevenire la creazione di nuovi gruppi e utenti IAM, imponendo che l'accesso ad AWS avvenga tramite identità federate.
**Nota**
L'utente è responsabile della gestione della rotazione dei token di accesso SCIM, come descritto nella documentazione sul [provisioning automatico](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html). Inoltre, l'utente è responsabile della rotazione dei certificati a supporto della federazione delle identità.
**Guida per gli utenti delle applicazioni** Puoi gestire le identità degli utenti delle applicazioni, ad esempio di un'applicazione per dispositivi mobili, utilizzando [https://aws.amazon.com/cognito/](https://aws.amazon.com/cognito/) come gestore dell'identità digitale centralizzato. Amazon Cognito consente l'autenticazione, autorizzazione e gestione degli utenti per le app Web e per dispositivi mobili. Amazon Cognito offre un archivio di identità scalabile fino a milioni di utenti, supporta la federazione delle identità sociali e aziendali e offre funzionalità di sicurezza avanzate per proteggere i tuoi utenti e la tua 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
**Passaggi per l'accesso ad AWS degli utenti della forza lavoro**
+ Federa l'accesso ad AWS degli utenti della tua forza lavoro tramite un gestore dell'identità digitale centralizzato seguendo uno dei seguenti approcci:
+ Utilizza il Centro identità IAM per abilitare l'accesso tramite autenticazione unica in più Account AWS nella tua organizzazione AWS con la federazione del tuo gestore dell'identità digitale.
+ Utilizza IAM per connettere il gestore dell'identità digitale direttamente a ciascun Account AWS, così da consentire un accesso federato e granulare.
+ Identifica e rimuovi gruppi e utenti IAM sostituiti da identità federate.
**Passaggi per gli utenti delle tue applicazioni**
+ Utilizza Amazon Cognito come gestore dell'identità digitale centralizzato per le tue applicazioni.
+ Integra le tue applicazioni personalizzate con Amazon Cognito mediante 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
**Best practice correlate:**
+ [SEC02-BP06 Impiego dei gruppi di utenti e degli attributi](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_groups_attributes.html)
+ [SEC03-BP02 Concessione dell'accesso con privilegio minimo](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html)
+ [SEC03-BP06 Gestione degli accessi in base al ciclo di vita](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html)
**Documenti correlati:**
+ [Federazione delle identità 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)
+ [Best practice AWS Identity and Access Management](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: provider di credenziali del Centro identità IAM](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)
**Strumenti correlati:**
+ [AWS Security Competency Partner 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
Sottoponi a audit e ruota periodicamente le credenziali per limitarne il tempo di utilizzo per l'accesso alle risorse. Le credenziali a lungo termine espongono a molti rischi, riducibili mediante la rotazione periodica.
**Risultato desiderato:** implementa la rotazione delle credenziali per ridurre i rischi associati all'utilizzo delle credenziali 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:** elevato
## Guida all'implementazione
Quando non è possibile fare affidamento sulle credenziali temporanee e occorrono credenziali a lungo termine, esegui l'audit delle credenziali per garantire l'applicazione dei controlli prestabiliti, ad esempio l'[autenticazione a più fattori](https://aws.amazon.com/iam/features/mfa/) (MFA), la regolare rotazione e un livello di accesso appropriato.
La convalida periodica, preferibilmente tramite uno strumento automatizzato, è necessaria per verificare l'applicazione dei 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. Nel passaggio dagli utenti AWS Identity and Access Management (IAM) alle identità centralizzate, puoi [creare report sulle credenziali](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html) per controllare gli utenti.
Ti consigliamo inoltre di monitorare l'MFA nel tuo gestore dell'identità digitale. È possibile 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 monitorare se gli utenti hanno configurato l'MFA. Valuta la possibilità di utilizzare [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) per fornire credenziali temporanee per le identità macchina. Nelle situazioni in cui l'utilizzo di credenziali temporanee e ruoli IAM non è possibile, sono necessari audit e rotazione frequenti delle chiavi di accesso.
### Passaggi dell'implementazione
+ **Esegui con regolarità audit delle credenziali:** l'audit delle identità configurate nel tuo gestore dell'identità digitale e in IAM consente di verificare che l'accesso al tuo carico di lavoro sia concesso solo alle identità autorizzate. Tali identità possono includere, a titolo esemplificativo ma non esaustivo, utenti IAM, utenti del Centro identità AWS IAM, utenti di Active Directory o utenti di altri gestori dell'identità digitale upstream. Ad esempio, eliminare le persone che lasciano l'organizzazione e i ruoli multi-account non più necessari. Predisponi un processo per sottoporre periodicamente ad audit le autorizzazioni ai servizi a cui accede un'entità IAM. In questo modo potrai 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 credenziali e autorizzazioni IAM. Usa [Amazon CloudWatch per configurare allarmi per chiamate API specifiche](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) chiamate all'interno del tuo ambiente AWS. [Amazon GuardDuty può inoltre avvisarti in caso attività impreviste](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html), possibili segnali di un accesso eccessivamente permissivo o un accesso non intenzionale alle credenziali IAM.
+ **Ruota le credenziali regolarmente:** se non puoi utilizzare credenziali temporanee, ruota con regolarità le chiavi di accesso IAM a lungo termine (massimo ogni 90 giorni). In caso di divulgazione involontaria e a propria insaputa di una chiave di accesso, 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 [Rotazione delle chiavi di accesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey).
+ **Rivedi le autorizzazioni IAM:** per migliorare la sicurezza del tuo Account AWS, rivedi con regolarità e monitora ciascuna policy IAM. Verifica che le policy rispettino il principio del privilegio minimo.
+ **Valuta la possibilità di automatizzare la creazione e gli aggiornamenti delle risorse IAM:** il [Centro identità IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) automatizza molte attività IAM, come la gestione di ruoli e 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.
+ **Usa IAM Roles Anywhere per sostituire gli utenti IAM per le identità macchina:** [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) consente di utilizzare i ruoli in aree in cui prima non era possibile, come i server on-premises. IAM Roles Anywhere utilizza un [certificato X.509](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/trust-model.html#signature-verification) attendibile per l'autenticazione a AWS e la ricezione di 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-premises. È necessario monitorare e ruotare il certificato X.509 quando si avvicina alla scadenza.
## Risorse
**Best practice correlate:**
+ [SEC02-BP02 Utilizzo di credenziali temporanee](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC02-BP03 Archiviazione e utilizzo dei segreti in modo sicuro](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
**Documenti correlati:**
+ [Nozioni di base su Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html)
+ [Best practice di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Identity Providers and Federation](https://docs.aws.amazon.com/IAM/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)
+ [Temporary Security Credentials](https://docs.aws.amazon.com/IAM/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 Practices for Managing, Retrieving, and Rotating Secrets at Scale](https://youtu.be/qoxxRlwJKZ4)
+ [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E)
+ [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP06 Impiego dei gruppi di utenti e degli attributi
Definire le autorizzazioni in base a gruppi di utenti e attributi aiuta a ridurre numero e complessità delle policy, semplificando il raggiungimento del principio del privilegio minimo. Puoi usare i gruppi di utenti per gestire le autorizzazioni di molte persone in un'unica posizione, in base alla funzione svolte nell'organizzazione. Gli attributi, come il reparto, il progetto o la posizione, possono fornire un ulteriore livello di portata dei permessi quando le persone svolgono una funzione simile ma per sottoinsiemi diversi di risorse.
**Risultato desiderato:** puoi applicare modifiche alle autorizzazioni in base alla funzione per tutti gli utenti che la eseguono. L'appartenenza al gruppo e gli attributi regolano le autorizzazioni degli utenti, riducendo la necessità di gestire le autorizzazioni a livello di singolo utente. I gruppi e gli attributi definiti nel gestore dell'identità digitale vengono propagati automaticamente agli ambienti AWS.
**Anti-pattern comuni:**
+ Gestione delle autorizzazioni per singoli utenti e duplicazione tra più utenti.
+ Definizione dei gruppi a un livello troppo alto, concessione di autorizzazioni troppo estese.
+ Definizione di gruppi a un livello troppo granulare, che crea duplicazioni e confusione sull'appartenenza.
+ Utilizzo di gruppi con autorizzazioni duplicate su sottoinsiemi di risorse quando è possibile utilizzare invece gli attributi.
+ Nessuna gestione di gruppi, attributi e appartenenze attraverso un gestore dell'identità digitale standardizzato e integrato con gli ambienti AWS.
+ Utilizzo della concatenazione dei ruoli quando si utilizzano le sessioni di Centro identità AWS IAM
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Le autorizzazioni AWS sono definite nei documenti denominati *policy*, associati a un principale, ad esempio un utente, gruppo, ruolo o risorsa. Puoi scalare la gestione delle autorizzazioni organizzando le assegnazioni delle autorizzazioni (gruppo, autorizzazioni, account) in base alla funzione lavorativa, al carico di lavoro e all'ambiente SDLC. Per la forza lavoro, ciò consente di definire i gruppi in base alla funzione svolta dagli utenti per l'organizzazione, anziché in base alle risorse a cui si accede. Ad esempio, un gruppo WebAppDeveloper può avere una policy collegata per la configurazione di servizi come Amazon CloudFront all'interno di un account di sviluppo. Un gruppo `AutomationDeveloper` può avere alcune autorizzazioni che si sovrappongono a quelle del gruppo `WebAppDeveloper`. Queste autorizzazioni comuni possono essere acquisite in una policy separata e associate a entrambi i gruppi, anziché avere utenti di entrambe le funzioni che appartengono a un gruppo `CloudFrontAccess`.
Oltre ai gruppi, è possibile utilizzare gli *attributi* per un ulteriore ambito dell'accesso. Ad esempio, è possibile avere un attributo Project per gli utenti del gruppo `WebAppDeveloper`, per limitare l'accesso alle risorse specifiche del loro progetto. L'uso di questa tecnica elimina la necessità di avere gruppi diversi per gli sviluppatori di applicazioni che lavorano su progetti diversi, se le loro autorizzazioni sono comunque le stesse. Il modo in cui si fa riferimento agli attributi nelle policy di autorizzazione si basa sulla loro origine, indipendentemente dal fatto che siano definiti come parte del protocollo di federazione (come SAML, OIDC o SCIM), come asserzioni SAML personalizzate o impostati all'interno del Centro identità IAM.
### Passaggi dell'implementazione
1. Stabilisci dove definire gruppi e attributi:
1. Seguendo le indicazioni riportate in[SEC02-BP04 Fai affidamento su un gestore dell'identità digitale centralizzato](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html), puoi determinare se occorre definire gruppi e attributi all'interno del gestore dell'identità digitale, all'interno del Centro identità IAM o utilizzare i gruppi di utenti IAM in un account specifico.
1. Definisci i gruppi:
1. Determina i tuoi gruppi in base alla funzione e all'ambito di accesso richiesti. Valuta se utilizzare una struttura gerarchica o di convenzioni di denominazione per organizzare i gruppi in modo efficace.
1. Se procedi alla definizione all'interno del Centro identità IAM, crea i gruppi e associa il livello di accesso desiderato utilizzando i set di autorizzazioni.
1. Se definisci all'interno di un gestore dell'identità digitale esterno, determina se il gestore supporta il protocollo SCIM e valuta la possibilità di abilitare il provisioning automatico all'interno del Centro identità IAM. Questa funzionalità sincronizza la creazione, l'appartenenza e l'eliminazione di gruppi tra il tuo gestore e il Centro identità IAM.
1. Definisci gli attributi:
1. Se utilizzi un gestore dell'identità digitale esterno, entrambi i protocolli SCIM e SAML 2.0 forniscono determinati attributi per impostazione predefinita. È possibile definire attributi aggiuntivi e trasferirli mediante le asserzioni SAML con il nome dell'attributo `https://aws.amazon.com/SAML/Attributes/PrincipalTag`. Consulta la documentazione del gestore dell'identità digitale per le istruzioni sulla definizione e la configurazione di attributi personalizzati.
1. Se definisci i ruoli all'interno di Centro identità IAM, abilita la funzionalità di controllo degli accessi basato su attributi (ABAC) e definisci gli attributi come desiderato. Considera gli attributi che si allineano alla struttura dell'organizzazione o alla strategia di tagging delle risorse.
Se richiedi il concatenamento dei ruoli IAM da ruoli IAM assunti tramite Centro identità IAM, i valori come `source-identity` e `principal-tags` non si propagano. Per ulteriori dettagli, consulta [Enable and configure attributes for access control](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html).
1. Autorizzazioni di ambito basate su gruppi e attributi:
1. Prendi in considerazione la possibilità di includere nelle tue policy di autorizzazione condizioni che confrontino gli attributi del tuo principale con gli attributi delle risorse a cui si accede. Ad esempio, puoi definire una condizione che consenta l'accesso a una risorsa solo se il valore di una chiave di condizione `PrincipalTag` corrisponde a quello di una chiave `ResourceTag` con lo stesso nome.
1. Per la definizione delle policy ABAC, segui le indicazioni contenute nelle best practice e negli esempi relativi alle [autorizzazioni ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html).
1. Rivedi e aggiorna regolarmente la struttura dei gruppi e degli attributi in base all'evoluzione delle esigenze dell'organizzazione per garantire una gestione ottimale delle autorizzazioni.
## Risorse
**Best practice correlate:**
+ [SEC02-BP04 Fai affidamento su un gestore dell'identità digitale centralizzato](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP02 Concessione dell'accesso con privilegio minimo](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html)
+ [COST02-BP04 Implementazione di gruppi e ruoli](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_groups_roles.html)
**Documenti correlati:**
+ [Best practice di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Manage Identities in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)
+ [What Is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [ABAC In IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)
+ [ABAC Policy Examples](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_abac.html)
**Video correlati:**
+ [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E)
+ [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC 3. Come si gestiscono le autorizzazioni per persone e macchine?
Gestisci le autorizzazioni per controllare l'accesso alle identità di persone e macchine che richiedono l'accesso ad AWS e ai tuoi carichi di lavoro. Le autorizzazioni consentono di controllare chi può accedere a cosa e a quali condizioni. Impostando le autorizzazioni per specifiche identità umane e di macchine, si concede loro l'accesso a determinate azioni di servizio su risorse specifiche. Inoltre, è possibile specificare le condizioni che devono essere vere per concedere l'accesso.
**Topics**
+ [
# SEC03-BP01 Definizione dei requisiti di accesso
](sec_permissions_define.md)
+ [
# SEC03-BP02 Concessione dell'accesso con privilegio minimo
](sec_permissions_least_privileges.md)
+ [
# SEC03-BP03 Determinazione di un processo per l'accesso di emergenza
](sec_permissions_emergency_process.md)
+ [
# SEC03-BP04 Riduzione delle autorizzazioni in modo continuo
](sec_permissions_continuous_reduction.md)
+ [
# SEC03-BP05 Definizione dei guardrail per le autorizzazioni dell'organizzazione
](sec_permissions_define_guardrails.md)
+ [
# SEC03-BP06 Gestione degli accessi in base al ciclo di vita
](sec_permissions_lifecycle.md)
+ [
# SEC03-BP07 Analisi dell’accesso multi-account e pubblico
](sec_permissions_analyze_cross_account.md)
+ [
# SEC03-BP08 Condivisione delle risorse in modo sicuro all'interno dell'organizzazione
](sec_permissions_share_securely.md)
+ [
# SEC03-BP09 Condivisione sicura delle risorse con terze parti
](sec_permissions_share_securely_third_party.md)
# SEC03-BP01 Definizione dei requisiti di accesso
Ogni componente o risorsa del carico di lavoro deve essere accessibile da amministratori, utenti finali o altri componenti. Definisci chiaramente chi o cosa deve avere accesso a ciascun componente e scegli il tipo di identità e il metodo di autenticazione e autorizzazione appropriati.
**Anti-pattern comuni:**
+ Codifica fissa o archiviazione dei segreti nell’applicazione.
+ Concessione di autorizzazioni personalizzate per ogni utente.
+ Utilizzo di credenziali di lunga durata.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all’implementazione
Ogni componente o risorsa del carico di lavoro deve essere accessibile da amministratori, utenti finali o altri componenti. Definisci chiaramente chi o cosa deve avere accesso a ciascun componente e scegli il tipo di identità e il metodo di autenticazione e autorizzazione appropriati.
L’accesso regolare agli Account AWS all’interno di un’organizzazione dovrebbe essere fornito utilizzando l’[accesso federato](https://aws.amazon.com/identity/federation/) o un gestore dell’identità digitale centralizzato. Occorre anche centralizzare la gestione delle identità e garantire la presenza di una procedura consolidata per integrare l’accesso ad AWS nel ciclo di vita dell’accesso dei dipendenti. Ad esempio, se un dipendente passa a un ruolo lavorativo con un livello di accesso diverso, anche la sua appartenenza al gruppo deve cambiare per riflettere i nuovi requisiti di accesso.
Nel definire i requisiti di accesso per le identità non umane, determina quali applicazioni e componenti devono accedere, nonché le modalità di concessione delle autorizzazioni. L’utilizzo di ruoli IAM creati con il modello di accesso con privilegio minimo è un approccio consigliato. [AWS Le policy gestite](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) forniscono le policy IAM predefinite che coprono la maggior parte dei casi d’uso comuni.
I servizi AWS, come [Gestione dei segreti AWS](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) e l’[archivio dei parametri AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) consentono di separare i segreti dall’applicazione o dal carico di lavoro in modo sicuro. In Secrets Manager, puoi adottare la rotazione automatica delle credenziali. Puoi usare Systems Manager per fare riferimento a parametri negli script, comandi, documenti SSM, configurazione e flussi di lavoro di automazione utilizzando il nome univoco specificato al momento della creazione del parametro.
Puoi utilizzare [AWS IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) per ottenere [credenziali di sicurezza temporanee in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) per carichi di lavoro eseguiti all’esterno di AWS. I tuoi carichi di lavoro possono utilizzare le stesse [policy IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) e gli stessi [ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) che utilizzi con le applicazioni AWS per accedere alle risorse AWS.
Ove possibile, prediligi le credenziali temporanee a breve termine rispetto a quelle statiche a lungo termine. Per gli scenari in cui occorrono utenti con accesso programmatico e credenziali a lungo termine, usa le [ultime informazioni usate per la chiave di accesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) per la rotazione e la rimozione delle chiavi di accesso.
Gli utenti hanno bisogno di un accesso programmatico se desiderano interagire con AWS esternamente a Console di gestione AWS. La modalità con cui concedere l’accesso programmatico dipende dal tipo di utente che accede ad AWS.
Per fornire agli utenti l’accesso programmatico, scegli una delle seguenti opzioni.
****
| Quale utente necessita dell’accesso programmatico? | Per | Come |
| --- | --- | --- |
| IAM | (Consigliato) Utilizza credenziali della console come credenziali temporanee per firmare richieste programmatiche alla AWS CLI, agli SDK AWS o alle API AWS. | Segui le istruzioni per l’interfaccia che desideri utilizzare. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/framework/sec_permissions_define.html) |
| Identità della forza lavoro (Utenti gestiti nel centro identità IAM) | Utilizza credenziali temporanee per firmare richieste programmatiche alla AWS CLI, agli SDK AWS o alle API AWS. | Segui le istruzioni per l’interfaccia che desideri utilizzare. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/framework/sec_permissions_define.html) |
| IAM | Utilizza credenziali temporanee per firmare richieste programmatiche alla AWS CLI, agli SDK AWS o alle API AWS. | Segui le istruzioni in [Utilizzo di credenziali temporanee con le risorse AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html) nella Guida per l’utente IAM. |
| IAM | (Non consigliato)Utilizza credenziali a lungo termine per firmare richieste programmatiche alla AWS CLI, agli SDK AWS o alle API AWS. | Segui le istruzioni per l’interfaccia che desideri utilizzare. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/framework/sec_permissions_define.html) |
## Risorse
**Documenti correlati:**
+ [Controllo degli accessi basato su attributi (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/)
+ [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)
+ [AWS Managed policies for IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html)
+ [AWS Condizioni delle policy IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)
+ [Casi d’uso IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UseCases.html)
+ [Rimuovere credenziali non necessarie](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [Lavorare con le policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [How to control access to AWS resources based on Account AWS, OU, or organization](https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/)
+ [Identify, arrange, and manage secrets easily using enhanced search in Gestione dei segreti AWS](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/)
**Video correlati:**
+ [Become an IAM Policy Master in 60 Minutes or Less](https://youtu.be/YQsK4MtsELU)
+ [Separation of Duties, Least Privilege, Delegation, and CI/CD](https://youtu.be/3H0i7VyTu70)
+ [Streamlining identity and access management for innovation](https://www.youtube.com/watch?v=3qK0b1UkaE8)
# SEC03-BP02 Concessione dell'accesso con privilegio minimo
Concedi solo l'accesso richiesto dagli utenti per eseguire azioni specifiche su determinate risorse in condizioni particolari. Affidati a gruppi e attributi di identità per impostare in modo dinamico le autorizzazioni su vasta scala, anziché definire le autorizzazioni per i singoli utenti. Ad esempio, puoi concedere a un gruppo di sviluppatori le autorizzazioni per gestire solo le risorse del loro progetto. In questo modo, se uno sviluppatore lascia il progetto, l'accesso viene revocato in automatico senza modificare le policy di accesso sottostanti.
**Risultato desiderato:** gli utenti dispongono solo delle autorizzazioni minime richieste per le funzioni lavorative specifiche. Utilizzi Account AWS separati per isolare gli sviluppatori dagli ambienti di produzione. Quando gli sviluppatori devono accedere agli ambienti di produzione per attività specifiche, viene concesso un accesso limitato e controllato solo per la durata di tali attività. L'accesso alla produzione viene immediatamente revocato al termine del lavoro necessario. Esegui revisioni regolari delle autorizzazioni e revocale prontamente quando non sono più necessarie, ad esempio quando un utente cambia ruolo o lascia l'organizzazione. Limita i privilegi di amministratore a un gruppo ristretto e attendibile per ridurre l'esposizione al rischio. Assegna agli account di computer o di sistema solo le autorizzazioni minime necessarie per eseguire le attività previste.
**Anti-pattern comuni:**
+ Per impostazione predefinita, concedi agli utenti le autorizzazioni di amministratore.
+ Utilizzi l'account utente root per le attività quotidiane.
+ Crei policy eccessivamente permissive senza un ambito adeguato.
+ Le revisioni delle autorizzazioni sono rare, il che porta all'insinuarsi di autorizzazioni.
+ Per l'isolamento dell'ambiente o la gestione delle autorizzazioni, fai affidamento esclusivamente al controllo degli accessi basato su attributi.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
Secondo il principio del [privilegio minimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege), le identità dovrebbero essere autorizzate a eseguire solo il più piccolo insieme di azioni necessarie per lo svolgimento di un'attività specifica. In questo modo usabilità, efficienza e sicurezza sono bilanciate. Seguendo questo principio si limitano gli accessi indesiderati e si può monitorare chi accede a quali risorse. Per impostazione predefinita, ruoli e utenti IAM non dispongono di autorizzazioni. Per impostazione predefinita, l'utente root dispone dell'accesso completo e deve essere strettamente controllato, monitorato e utilizzato solo per [le attività che richiedono l'accesso root](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html).
Le policy IAM consentono di concedere in modo esplicito le autorizzazioni ai ruoli IAM o a risorse specifiche. Ad esempio, le policy basate su identità possono essere collegate ai gruppi IAM, mentre i bucket S3 possono essere controllati da policy basate su risorse.
Quando crei una policy IAM, puoi specificare le azioni di servizio, le risorse e le condizioni che devono essere vere affinché AWS consenta o rifiuti l'accesso. AWS supporta una serie di condizioni per aiutare a ridurre l'ambito dell'accesso. Ad esempio, con la [chiave di condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) PrincipalOrgID, puoi negare azioni se il richiedente non fa parte della tua organizzazione AWS.
Puoi anche controllare le richieste effettuate dai servizi AWS per tuo conto, ad esempio AWS CloudFormation per la creazione di una funzione AWS Lambda, utilizzando la chiave di condizione CalledVia. Puoi stratificare diversi tipi di policy per stabilire una difesa in profondità e limitare le autorizzazioni complessive degli utenti. Puoi anche limitare le autorizzazioni che possono essere concesse e le relative condizioni. Ad esempio, puoi consentire ai team del carico di lavoro di creare le proprie policy IAM per i sistemi che realizzano, ma solo se applicano un [limite delle autorizzazioni](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) per circoscrivere le autorizzazioni massime che possono essere concesse.
### Passaggi dell'implementazione
+ **Implementa policy con privilegio minimo**: assegna policy di accesso con privilegio minimo a ruoli e gruppi IAM in modo da rispecchiare il ruolo o la funzione dell'utente che hai definito.
+ **Isola gli ambienti di sviluppo e produzione tramite Account AWS separati**: utilizza Account AWS separati per gli ambienti di sviluppo e di produzione e controlla l'accesso tra di essi utilizzando [policy di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html), policy delle risorse e policy identità.
+ **Policy di base sull'utilizzo delle API**: un modo per determinare le autorizzazioni necessarie consiste nel rivedere i log AWS CloudTrail. Puoi utilizzare questa revisione per creare autorizzazioni personalizzate in base alle azioni che l'utente esegue effettivamente all'interno di AWS. [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) può [generare automaticamente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) una policy IAM basata su attività di accesso. Puoi usare IAM Access Advisor a livello di organizzazione o account per [tenere traccia delle ultime informazioni a cui si ha avuto accesso per una particolare policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html).
+ **Prendi in considerazione l'utilizzo di [policy gestite da AWS per funzioni lavorative](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)**: quando inizi a creare policy di autorizzazioni granulari, può essere utile utilizzare policy gestite da AWS per ruoli lavorativi comuni, ad esempio contabili, amministratori di database e data scientist. Questi policy possono aiutare a restringere l'accesso degli utenti mentre si determina come implementare i criteri di privilegio minimo.
+ **Rimuovi le autorizzazioni non necessarie:** rileva e rimuovi le entità, le credenziali e le autorizzazioni IAM non utilizzate per ottenere il principio del privilegio minimo. Puoi utilizzare [Sistema di analisi degli accessi AWS IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html) per identificare gli accessi esterni e quelli non utilizzati e la [generazione di policy del Sistema di analisi degli accessi AWS IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) può aiutare a eseguire il fine-tuning delle policy di autorizzazione.
+ **Assicurati che gli utenti abbiano un accesso limitato agli ambienti di produzione:** gli utenti devono avere accesso agli ambienti di produzione solo in presenza di un caso d'uso valido. Una volta eseguite le attività specifiche che richiedono l'accesso alla produzione, l'accesso dell'utente deve essere revocato. Limitare l'accesso agli ambienti di produzione contribuisce a evitare eventi indesiderati con impatto sulla produzione e contiene gli effetti di accessi involontari.
+ **Considera i confini delle autorizzazioni:** un [limite delle autorizzazioni](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) è una funzionalità per l'utilizzo di una policy gestita che stabilisce le autorizzazioni massime che una policy basata sull'identità può concedere a un'entità IAM. Il limite delle autorizzazioni di un'entità consente di eseguire solo le operazioni consentite dalle sue policy basate su identità e dai suoi limiti delle autorizzazioni.
+ **Perfeziona l'accesso usando il controllo dell'accesso basato sugli attributi e i tag delle risorse** Il [controllo degli accessi basato su attributi (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) usando i tag delle risorse può essere usato per perfezionare le autorizzazioni quando è supportato. Puoi utilizzare un modello ABAC che confronta i tag dei principali con i tag delle risorse per perfezionare l'accesso in base a dimensioni personalizzate definite dall'utente. Questo approccio può semplificare e ridurre il numero di policy di autorizzazione nell'organizzazione.
+ Si consiglia di utilizzare ABAC per il controllo degli accessi solo quando sia i principali che le risorse sono di proprietà dell'organizzazione AWS. Le parti esterne possono utilizzare gli stessi nomi e valori di tag dell'organizzazione per i propri principali e risorse. Se fai affidamento esclusivamente su queste coppie nome-valore per concedere l'accesso a risorse o principali esterni, potresti fornire autorizzazioni indesiderate.
+ **Utilizza le policy di controllo dei servizi per AWS Organizations:** le [policy di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) controllano centralmente le autorizzazioni massime disponibili per gli account dei membri dell'organizzazione. È importante notare che puoi utilizzare le policy di controllo dei servizi per limitare le autorizzazioni dell'utente root negli account membri. Prendi anche in considerazione la possibilità di usare AWS Control Tower, che offre controlli gestiti prescrittivi che arricchiscono AWS Organizations. Puoi anche definire i tuoi controlli in Control Tower.
+ **Stabilisci una policy del ciclo di vita degli utenti per la tua organizzazione:** le policy del ciclo di vita degli utenti definiscono le attività da eseguire in caso di onboarding degli utenti in AWS, cambiamento di ruolo o ambito lavorativo o cessata necessità di accedere a AWS. Esegui revisioni delle autorizzazioni durante ogni fase del ciclo di vita di un utente per verificare che le autorizzazioni siano adeguatamente restrittive e per evitare l'insorgere di autorizzazioni.
+ **Stabilisci una pianificazione regolare per rivedere le autorizzazioni e rimuovere quelle non necessarie:** è necessario rivedere regolarmente l'accesso utente per verificare che non sia eccessivamente permissivo. [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) e Sistema di analisi degli accessi AWS IAM possono essere d'aiuto durante gli audit delle autorizzazioni degli utenti.
+ **Stabilisci una matrice dei ruoli professionali:** una matrice dei ruoli professionali visualizza i vari ruoli e i livelli di accesso richiesti all'interno della tua impronta AWS. Con una matrice dei ruoli professionali puoi definire e separare le autorizzazioni in base alle responsabilità degli utenti all'interno dell'organizzazione. Utilizza i gruppi anziché applicare le autorizzazioni direttamente a singoli utenti o ruoli.
## Risorse
**Documenti correlati:**
+ [Grant least privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)
+ [Techniques for writing least privilege IAM policies](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/)
+ [IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM policies based on access activity](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/)
+ [Delegate permission management to developers by using IAM permissions boundaries](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)
+ [Perfezionare le autorizzazioni utilizzando le informazioni dell'ultimo accesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [IAM policy and when to use them](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)
+ [Test delle policy IAM con il simulatore di policy IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html)
+ [Guardrail in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [Zero Trust architectures: An AWS perspective](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/)
+ [How to implement the principle of least privilege with CloudFormation StackSets](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/)
+ [Controllo degli accessi basato su attributi (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [Reducing policy scope by viewing user activity](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [View role access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html)
+ [Uso dei tag per organizzare il proprio ambiente e aumentare la responsabilità](https://docs.aws.amazon.com/aws-technical-content/latest/cost-optimization-laying-the-foundation/tagging.html)
+ [Strategie di applicazione di tag AWS](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)
+ [Applicazione di tag alle risorse AWS](https://aws.amazon.com/premiumsupport/knowledge-center/tagging-resources/)
**Video correlati:**
+ [Next-generation permissions management](https://www.youtube.com/watch?v=8vsD_aTtuTo)
+ [Zero Trust: An AWS perspective](https://www.youtube.com/watch?v=1p5G1-4s1r0)
# SEC03-BP03 Determinazione di un processo per l'accesso di emergenza
Crea un processo che consenta l'accesso di emergenza ai tuoi carichi di lavoro nell'improbabile eventualità che si verifichi un problema con il tuo gestore dell'identità digitale centralizzato.
Devi progettare processi per diverse modalità di guasto che potrebbero causare un evento di emergenza. Ad esempio, in circostanze normali, gli utenti della tua forza lavoro si federano nel cloud utilizzando un gestore dell'identità digitale centralizzato ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)) per gestire i loro carichi di lavoro. Tuttavia, se il tuo gestore dell'identità digitale centralizzato riscontra un errore o la configurazione per la federazione nel cloud subisce modifiche, gli utenti della tua forza lavoro potrebbero non essere in grado di federarsi nel cloud. Un processo di accesso di emergenza consente agli amministratori autorizzati di accedere alle risorse cloud tramite mezzi alternativi (come una forma alternativa di federazione o l'accesso diretto degli utenti) per risolvere problemi relativi alla configurazione della federazione o ai carichi di lavoro. Si ricorre al processo di accesso di emergenza fino al ripristino del normale meccanismo di federazione.
**Risultato desiderato:**
+ Hai definito e documentato le modalità di guasto che costituiscono un'emergenza: considera le circostanze normali e i sistemi da cui dipendono gli utenti per gestire i loro carichi di lavoro. Prendi in considerazione quali guasti possono interessare ciascuna di queste dipendenze e causare una situazione di emergenza. Potresti trovare utili le domande e le best practice del [pilastro dell'affidabilità](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-reliability.html) per individuare le modalità di errore e progettare sistemi più resilienti al fine di ridurre al minimo la probabilità di guasti.
+ Hai documentato i passaggi da seguire per confermare che un guasto costituisce un'emergenza. Ad esempio, puoi richiedere agli amministratori di identità di controllare lo stato dei gestori delle identità digitali primari e di standby e, se entrambi non sono disponibili, dichiarare un evento di emergenza per guasto del gestore dell'identità digitale.
+ È stato definito un processo di accesso di emergenza specifico per ogni tipo di modalità di emergenza o di guasto. Essere specifici può ridurre la tentazione da parte degli utenti di abusare di un processo generale per tutti i tipi di emergenze. I processi di accesso di emergenza illustrano le circostanze in cui ciascun processo va o non va utilizzato e indicano processi alternativi applicabili.
+ I tuoi processi sono ben documentati con istruzioni e playbook dettagliati, facili da mettere in pratica in modo rapido ed efficiente. Ricorda che un evento di emergenza può essere un momento stressante per i tuoi utenti, che potrebbero essere sotto pressione per motivi di tempo, quindi progetta il tuo processo in modo che sia il più semplice possibile.
**Anti-pattern comuni:**
+ Non si dispone di procedure di accesso di emergenza ben documentate e collaudate. Gli utenti non sono preparati per un'emergenza e seguono processi improvvisati quando si verifica un evento di emergenza.
+ I processi di accesso di emergenza dipendono dagli stessi sistemi (come un gestore dell'identità digitale centralizzato) dei normali meccanismi di accesso. Ciò significa che il guasto di un sistema di questo tipo può influire sui normali meccanismi di accesso e di emergenza e compromettere la capacità di ripristino dall'errore.
+ I processi di accesso di emergenza vengono utilizzati in situazioni non di emergenza. Ad esempio, gli utenti utilizzano spesso in modo improprio i processi di accesso di emergenza poiché trovano più facile apportare modifiche direttamente piuttosto che inviarle tramite una pipeline.
+ I processi di accesso di emergenza non generano log sufficienti per effettuare l'audit dei processi oppure i log non vengono monitorati per segnalare un potenziale uso improprio dei processi.
**Vantaggi dell'adozione di questa best practice:**
+ Grazie a processi di accesso di emergenza ben documentati e collaudati, puoi ridurre il tempo impiegato dagli utenti per rispondere a un evento di emergenza e risolverlo. Ciò può comportare una riduzione dei tempi di inattività e una maggiore disponibilità dei servizi forniti ai clienti.
+ È possibile tenere traccia di ogni richiesta di accesso di emergenza e rilevare e segnalare i casi di tentativi non autorizzati di uso improprio del processo per eventi non di emergenza.
**Livello di rischio associato se questa best practice non fosse adottata**: medio
## Guida all’implementazione
La presente sezione fornisce indicazioni per la creazione di processi di accesso di emergenza per diverse modalità di errore relative ai carichi di lavoro implementati su AWS, a partire da linee guida comuni applicabili a tutte le modalità di errore fino a linee guida specifiche in base al tipo di errore.
**Linee guida comuni per tutte le modalità di errore**
Nella progettazione di un processo di accesso di emergenza per una modalità di errore, tieni presente quanto segue:
+ Documenta prerequisiti e presupposti del processo: quando il processo deve e non deve essere utilizzato. Aiuta a descrivere in dettaglio la modalità di errore e a documentare le ipotesi, come lo stato di altri sistemi correlati. Ad esempio, il processo per la modalità di errore 2 presuppone che il gestore dell'identità digitale sia disponibile, ma la configurazione in AWS è stata modificata o è scaduta.
+ Crea preliminarmente le risorse necessarie per il processo di accesso di emergenza ([SEC10-BP05](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_pre_provision_access.html)). Ad esempio, crea preliminarmente l'accesso di emergenza a un Account AWS con ruoli e utenti IAM e in tutti gli account del carico di lavoro creando ruoli IAM multi-account. Ciò assicura che queste risorse siano pronte e disponibili quando si verifica un evento di emergenza. Creando in modo preliminare le risorse, non si dipende dalle API del [piano di controllo (control-plane)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html) AWS (utilizzate per creare e modificare risorse AWS) che potrebbero non essere disponibili in caso di emergenza. Inoltre, creando in modo preliminare le risorse IAM, non è necessario tenere conto dei [potenziali ritardi dovuti all'eventuale consistenza.](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency)
+ Includi i processi di accesso di emergenza nei tuoi piani di gestione degli incidenti ([SEC10-BP02](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_develop_management_plans.html)). Documenta le modalità in cui si tiene traccia degli eventi di emergenza e come questi vengono comunicati ad altri membri dell'organizzazione, come i team di pari livello, la leadership e, se applicabile, esternamente ai clienti e ai partner aziendali.
+ Definisci il processo di richiesta di accesso di emergenza nel tuo sistema di flusso di lavoro esistente, se ne hai uno, per le richieste di assistenza. In genere, tali sistemi di flusso di lavoro consentono di creare moduli di acquisizione per raccogliere informazioni sulla richiesta, tenere traccia della richiesta in ogni fase del flusso di lavoro e aggiungere passaggi di approvazione automatici e manuali. Collega ciascuna richiesta a un evento di emergenza corrispondente tracciato nel tuo sistema di gestione degli incidenti. Disporre di un sistema uniforme per gli accessi di emergenza consente di tenere traccia di tali richieste in un unico sistema, analizzare le tendenze di utilizzo e migliorare i processi.
+ Verifica che i processi di accesso di emergenza possano essere avviati solo da utenti autorizzati e richiedano l'approvazione di colleghi o manager dell'utente, a seconda dei casi. Il processo di approvazione deve funzionare in modo efficacie sia all'interno sia al di fuori dell'orario lavorativo. Definisci in che modo le richieste di approvazione possono essere eseguite da approvatori secondari, qualora gli approvatori principali non fossero disponibili, e come vengono inoltrate lungo la catena di gestione fino all'approvazione.
+ Implementa affidabili meccanismi di registrazione dei log, monitoraggio e avviso per il processo e i meccanismi di accesso di emergenza. Genera log di audit dettagliati per tutti i tentativi riusciti e non riusciti di ottenere l'accesso di emergenza. Metti in correlazione l'attività con gli eventi di emergenza in corso dal sistema di gestione degli incidenti e attiva gli avvisi quando le azioni si verificano al di fuori dei periodi previsti o quando l'account di accesso di emergenza viene utilizzato durante le normali operazioni. L'account di accesso di emergenza deve essere utilizzato solo in caso di emergenza, poiché le procedure break-glass possono essere considerate una backdoor. Effettua l'integrazione con lo strumento di gestione delle informazioni e degli eventi di sicurezza (SIEM) o con [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) per segnalare e verificare tutte le attività durante il periodo di accesso di emergenza. Quando torni alla normale operatività, effettua la rotazione automatica delle credenziali di accesso di emergenza e informa i team interessati.
+ Testa periodicamente i processi di accesso di emergenza per verificare che i passaggi siano chiari e garantire il livello di accesso corretto in modo rapido ed efficiente. I processi di accesso di emergenza devono essere testati nell'ambito delle simulazioni di risposta agli incidenti ([SEC10-BP07](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)) e dei test di disaster recovery ([REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)).
**Modalità di errore 1: il gestore dell'identità digitale utilizzato per la federazione dell'accesso ad AWS non è disponibile**
Come illustrato in [SEC02-BP04 Fai affidamento su un gestore dell'identità digitale centralizzato](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html), ti consigliamo di affidarti a un gestore dell'identità digitale centralizzato per federare gli utenti della tua forza lavoro e garantire loro l'accesso agli Account AWS. È possibile federare l'accesso a più Account AWS all'interno dell'organizzazione AWSutilizzando il Centro identità IAM oppure federare l'accesso individuale agli Account AWS utilizzando IAM. In entrambi i casi, gli utenti della forza lavoro si autenticano con il gestore dell'identità digitale centralizzato prima di essere reindirizzati a un endpoint di accesso AWS per l'autenticazione unica.
Nell'improbabile eventualità che il gestore dell'identità digitale centralizzato non sia disponibile, gli utenti della tua forza lavoro non possono federarsi per accedere agli Account AWS o gestire i propri carichi di lavoro. In questo evento di emergenza, puoi fornire un processo di accesso di emergenza secondo cui un piccolo gruppo di amministratori può accedere agli Account AWS per eseguire attività urgenti per le quali non è possibile attendere che i tuoi gestori delle identità digitali centralizzati tornino online. Ad esempio, il tuo gestore dell'identità digitale non è disponibile per 4 ore e durante quel periodo devi modificare i limiti massimi di un gruppo Amazon EC2 Auto Scaling in un account di produzione per gestire un picco imprevisto nel traffico dei clienti. Gli amministratori di emergenza devono seguire la procedura di accesso di emergenza per accedere a un Account AWS di produzione specifico e apportare le modifiche necessarie.
Il processo di accesso di emergenza si basa su un accesso di emergenza a un Account AWS creato preliminarmente, utilizzato esclusivamente per questo tipo di accessi e dispone di risorse AWS (come ruoli e utenti IAM) per supportare il processo di accesso di emergenza. Durante le normali operazioni, nessuno deve accedere all'account di accesso di emergenza ed è necessario monitorare e fornire avvisi riguardo a usi impropri di questo account (per maggiori dettagli, vedi la sezione precedente Linee guida comuni).
L'account di accesso di emergenza dispone di ruoli IAM di accesso di emergenza con autorizzazioni per assumere ruoli multi-account negli Account AWS che richiedono l'accesso di emergenza. Questi ruoli IAM sono creati preliminarmente e configurati con policy di attendibilità che valutano i ruoli IAM dell'account di emergenza come attendibili.
Per il processo di accesso di emergenza è possibile utilizzare uno dei seguenti approcci:
+ Puoi creare in modo preliminare un set di [utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) per gli amministratori di emergenza nell'account di accesso di emergenza con password complesse e token MFA associati. Tali utenti IAM dispongono delle autorizzazioni per assumere i ruoli IAM che consentono l'accesso multi-account all'Account AWS per cui è richiesto l'accesso di emergenza. Ti consigliamo di creare il minor numero possibile di utenti di questo tipo e di assegnare ogni utente a un unico amministratore di emergenza. Durante un'emergenza, un utente amministratore di emergenza accede all'account di accesso di emergenza utilizzando la propria password e il codice token MFA, passa al ruolo IAM di accesso di emergenza nell'account di emergenza e infine passa al ruolo IAM di accesso di emergenza nell'account del carico di lavoro per eseguire l'azione di modifica di emergenza. Il vantaggio di questo approccio è che ogni utente IAM è assegnato a un amministratore di emergenza e puoi sapere quale utente ha effettuato l'accesso esaminando gli eventi CloudTrail. Lo svantaggio è che è necessario mantenere più utenti IAM con le relative password di lunga durata e i token MFA associati.
+ Puoi usare l'accesso di emergenza dell'[utente root Account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) per accedere all'account di emergenza, assumere il ruolo IAM per l'accesso di emergenza e poi il ruolo multi-account nell'account del carico di lavoro. È consigliabile impostare una password sicura e più token MFA per l'utente root. Consigliamo inoltre di archiviare la password e i token MFA in un archivio di credenziali aziendali sicuro, che applichi policy di autenticazione e autorizzazione avanzate. Proteggi i fattori di reimpostazione della password e del token MFA: imposta l'indirizzo e-mail dell'account su una lista di distribuzione e-mail monitorata dagli amministratori della sicurezza del cloud e il numero di telefono dell'account su un numero di telefono condiviso anch'esso monitorato dagli amministratori della sicurezza. Il vantaggio di questo approccio è l'esistenza di un solo set di credenziali utente root da gestire. Lo svantaggio è che, trattandosi di un utente condiviso, più amministratori hanno la possibilità di accedere come utente root. Controlla gli eventi del log del tuo vault aziendale per identificare quale amministratore ha utilizzato la password dell'utente root.
**Modalità di errore 2: la configurazione del gestore dell'identità digitale in AWS è stata modificata o è scaduta**
Per consentire agli utenti della tua forza lavoro di effettuare l'accesso federato agli Account AWS, puoi configurare il Centro identità IAM con un gestore dell'identità digitale esterno o un gestore dell'identità digitale IAM ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)). In genere, la configurazione si effettua importando un documento XML di metadati SAML fornito dal gestore dell'identità digitale. Il documento XML di metadati include un certificato X.509 corrispondente a una chiave privata utilizzata dal gestore dell'identità digitale per firmare le sue asserzioni SAML.
Queste configurazioni lato AWS possono essere modificate o eliminate per errore da un amministratore. In un altro scenario, può accadere che il certificato X.509 importato in AWS sia scaduto e che un nuovo XML di metadati con un nuovo certificato non sia ancora stato importato in AWS. In entrambi gli scenari, la federazione degli utenti della forza lavoro per accedere ad AWS può essere interrotta, creando così una situazione di emergenza.
In un caso di emergenza di questo tipo, puoi fornire agli amministratori delle identità l'accesso ad AWS per risolvere i problemi di federazione. Ad esempio, l'amministratore delle identità utilizza la procedura di accesso di emergenza per accedere a un Account AWS, passa a un ruolo nell'account amministratore del Centro identità e riattiva la federazione aggiornando la configurazione del gestore dell'identità digitale esterno e importando l'ultimo documento XML di metadati SAML rilasciato dal gestore dell'identità digitale. Una volta ristabilita la federazione, gli utenti della forza lavoro continuano a utilizzare il normale processo operativo per federare l'accesso ai propri account di carico di lavoro.
È possibile seguire gli approcci illustrati nella sezione precedente Modalità di errore 1 per creare un processo di accesso di emergenza. Puoi concedere le autorizzazioni con il privilegio minimo agli amministratori delle identità per accedere solo all'account amministratore di Centro identità ed eseguire azioni in Centro identità in quell'account.
**Modalità di errore 3: blocco del Centro identità**
Nell'improbabile eventualità di un blocco del Centro identità IAM o una Regione AWS, ti consigliamo di eseguire una configurazione per fornire l'accesso temporaneo alla Console di gestione AWS.
Il processo di accesso di emergenza utilizza la federazione diretta rilasciata dal gestore dell'identità digitale a un IAM per accedere a un account di emergenza. Per informazioni dettagliate sul processo e sulle considerazioni di progettazione, consulta [Set up emergency access to the Console di gestione AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html).
### Passaggi dell'implementazione
**Passaggi comuni per tutte le modalità di errore**
+ Crea un Account AWS dedicato per gli accessi di emergenza. Crea preliminarmente le risorse IAM necessarie nell'account, come i ruoli IAM o gli utenti IAM, e, in modo facoltativo, i gestori delle identità digitali IAM. Inoltre, crea preliminarmente ruoli IAM multi-account negli Account AWS del carico di lavoro dotati di relazioni di fiducia con i ruoli IAM corrispondenti nell'account di accesso di emergenza. Puoi usare [CloudFormation StackSets con AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html) per creare tali risorse negli account dei membri della tua organizzazione.
+ Crea una [policy di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) AWS Organizations per negare l'eliminazione e la modifica dei ruoli IAM multi-account negli Account AWS dei membri.
+ Abilita CloudTrail per l'accesso di emergenza a un Account AWS e invia gli eventi di trail a un bucket S3 centrale nella raccolta di log relativa all'Account AWS. Se utilizzi AWS Control Tower per configurare e gestire il tuo ambiente AWS multi-account, ogni account che crei utilizzando AWS Control Tower o a cui ti iscrivi in AWS Control Tower presenta CloudTrail abilitato per impostazione predefinita e viene inviato a un bucket S3 in un Account AWS con archivio di log dedicato.
+ Monitora l'attività dell'account di accesso di emergenza creando regole EventBridge coerenti con l'accesso alla console e all'attività dell'API da parte dei ruoli IAM di emergenza. Invia notifiche al tuo centro operativo di sicurezza quando si verificano attività al di fuori di un evento di emergenza in corso e di cui hai traccia nel tuo sistema di gestione degli incidenti.
**Passaggi aggiuntivi per la Modalità di errore 1: il gestore dell'identità digitale utilizzato per la federazione dell'accesso ad AWS non è disponibile; per la Modalità di errore 2: la configurazione del gestore dell'identità digitale su AWS è stata modificata o è scaduta**
+ Crea preliminarmente le risorse in base al meccanismo scelto per l'accesso di emergenza:
+ **Usando gli utenti IAM:** crea preliminarmente gli utenti IAM con password complesse e dispositivi MFA associati.
+ **Utilizzando l'utente utente root dell'account di emergenza:** configura l'utente root con una password sicura e archivia la password nel tuo vault di credenziali aziendali. Associa più dispositivi MFA fisici all'utente root e archivia i dispositivi in posizioni a cui i membri del team di amministrazione delle emergenze possono accedere rapidamente.
**Passaggi aggiuntivi per la Modalità di errore 3: blocco del Centro identità**
+ Come illustrato in [Set up emergency access to the Console di gestione AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html), per l'accesso di emergenza a un Account AWS, crea un gestore dell'identità digitale IAM per abilitare la federazione SAML diretta dal tuo gestore dell'identità digitale.
+ Crea gruppi operativi di emergenza nel tuo IdP senza membri.
+ Crea ruoli IAM corrispondenti ai gruppi operativi di emergenza nell'account di accesso di emergenza.
## Risorse
**Best practice Well-Architected correlate:**
+ [SEC02-BP04 Fai affidamento su un gestore dell'identità digitale centralizzato](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
+ [SEC03-BP02 Concessione dell'accesso con privilegio minimo](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html)
+ [SEC10-BP02 Sviluppo di piani di gestione degli incidenti](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html)
+ [SEC10-BP07 Esecuzione di giornate di gioco](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html)
**Documenti correlati:**
+ [Set up emergency access to the Console di gestione AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)
+ [Enabling SAML 2,0 federated users to access the Console di gestione AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html)
+ [Break glass access](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)
**Video correlati:**
+ [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://youtu.be/TvQN4OdR_0Y)
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive](https://youtu.be/YMj33ToS8cI)
**Esempi correlati:**
+ [AWS Break Glass Role](https://github.com/awslabs/aws-break-glass-role)
+ [AWS Framework per playbook per i clienti](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS incident response playbook samples](https://github.com/aws-samples/aws-incident-response-playbooks)
# SEC03-BP04 Riduzione delle autorizzazioni in modo continuo
Man mano che i team determinano gli accessi necessari, rimuovi le autorizzazioni non necessarie e stabilisci processi di revisione per ottenere le autorizzazioni con il privilegio minimo. Monitora costantemente e rimuovi le identità e le autorizzazioni inutilizzate per l'accesso sia umano che delle macchine.
**Risultato desiderato:** le policy di autorizzazione rispettano il principio del privilegio minimo. Man mano che le mansioni e i ruoli vengono definiti meglio, è necessario rivedere le policy di autorizzazione per eliminare le autorizzazioni non necessarie. Questo approccio riduce la portata dell'impatto nel caso di esposizione accidentale delle credenziali o di accesso in altro modo senza autorizzazione.
**Anti-pattern comuni:**
+ L'impostazione predefinita è la concessione delle autorizzazioni di amministratore agli utenti.
+ Creazione di policy eccessivamente permissive, ma senza privilegi completi di amministratore.
+ Mantenimento delle policy di autorizzazione anche quando non sono più necessarie.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all’implementazione
Quando i team e i progetti sono in fase iniziale, è possibile usare policy di autorizzazione permissiva per stimolare l'innovazione e l'agilità. Ad esempio, in un ambiente di sviluppo o di test, gli sviluppatori possono avere accesso a un'ampia gamma di servizi AWS. Si consiglia di valutare in modo costante gli accessi e di limitare l'accesso solo ai servizi e alle azioni di servizio necessari per completare il lavoro in corso. Raccomandiamo questa valutazione sia per l'identità umana che per quella macchina. Le identità macchina, talvolta chiamate account di sistema o di servizio, sono identità che consentono ad AWS di accedere ad applicazioni o server. Questo accesso è particolarmente importante in un ambiente di produzione, dove autorizzazioni troppo permissive possono avere un ampio impatto e potenzialmente esporre i dati dei clienti.
AWS offre diversi metodi per identificare utenti, ruoli, autorizzazioni e credenziali non utilizzati. AWS può anche aiutare ad analizzare l'attività di accesso di ruoli e utenti IAM, comprese le chiavi di accesso associate, e l'accesso alle risorse AWS, come gli oggetti nei bucket Amazon S3. La generazione di policy di AWS Identity and Access Management Access Analyzer può aiutare a creare policy di autorizzazione restrittive in base ai servizi e alle azioni effettive con cui interagisce un principale. Il [controllo degli accessi basato su attributi (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) consente di semplificare la gestione delle autorizzazioni, offrendo la possibilità di fornire le autorizzazioni agli utenti sulla base dei loro attributi anziché allegare le policy di autorizzazione direttamente a ciascun utente.
### Passaggi dell’implementazione
+ **Usa [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html):** IAM Access Analyzer aiuta a identificare le risorse dell'organizzazione e gli account, ad esempio i bucket Amazon Simple Storage Service (Amazon S3) o i ruoli IAM, [condivisi con un'entità esterna](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html).
+ **Utilizza la [generazione di policy di IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html):** la generazione di policy di IAM Access Analyzer consente di [creare policy di autorizzazione granulari basate sull'attività di accesso di ruoli o utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html#access-analyzer-policy-generation-howitworks).
+ **Esegui il test delle autorizzazioni in ambienti di livello inferiore prima della produzione:** inizia utilizzando gli [ambienti sandbox e di sviluppo meno critici](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/understanding-the-devops-environments.html) per testare le autorizzazioni richieste per le varie funzioni lavorative utilizzando Sistema di analisi degli accessi AWS IAM. Quindi, limita e convalida progressivamente queste autorizzazioni negli ambienti di test, controllo qualità e gestione temporanea prima di applicarle in produzione. Gli ambienti di livello inferiore possono avere inizialmente autorizzazioni più permissive, poiché le policy di controllo dei servizi (SCP) applicano dei guardrail limitando il numero massimo di autorizzazioni concesse.
+ **Determina un periodo di tempo e una policy di utilizzo accettabili per ruoli e utenti IAM:** utilizza il [timestamp dell'ultimo accesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html) per [identificare utenti e ruoli non utilizzati](https://aws.amazon.com/blogs/security/identify-unused-iam-roles-remove-confidently-last-used-timestamp/) e rimuoverli. Rivedi le informazioni sull'ultimo accesso al servizio e sull'ultima azione per identificare e [definire le autorizzazioni per specifici utenti e ruoli.](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) Ad esempio, puoi utilizzare le informazioni sull'ultimo accesso per identificare le azioni specifiche di Amazon S3 richieste dal ruolo dell'applicazione e delimitare l'accesso del ruolo solo a tali azioni. Le funzionalità relative alle informazioni sull'ultimo accesso sono disponibili nella Console di gestione AWS e consentono di incorporarle in modo programmatico nei flussi di lavoro dell'infrastruttura e negli strumenti automatizzati.
+ **Prendi in considerazione [la possibilità di creare log degli eventi relativi ai dati in AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html):** per impostazione predefinita, CloudTrail non crea log degli eventi relativi ai dati come le attività a livello di oggetto di Amazon S3 (ad esempio, `GetObject` e `DeleteObject`) o le attività delle tabelle Amazon DynamoDB (ad esempio `PutItem` e `DeleteItem`). Considera l'uso della creazione di log di questi eventi per stabilire quali utenti e ruoli devono accedere a specifici oggetti Amazon S3 o elementi di tabelle DynamoDB.
## Risorse
**Documenti correlati:**
+ [Grant least privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [Rimuovere credenziali non necessarie](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [ What is AWS CloudTrail? ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [Lavorare con le policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [ Logging and monitoring DynamoDB ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/MonitoringDynamoDB.html)
+ [ Abilitare la creazione di log di eventi CloudTrail per bucket e oggetti Amazon S ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.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:**
+ [Become an IAM Policy Master in 60 Minutes or Less](https://youtu.be/YQsK4MtsELU)
+ [Separation of Duties, Least Privilege, Delegation, and CI/CD](https://youtu.be/3H0i7VyTu70)
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive ](https://www.youtube.com/watch?v=YMj33ToS8cI)
# SEC03-BP05 Definizione dei guardrail per le autorizzazioni dell'organizzazione
Utilizza i guardrail delle autorizzazioni per ridurre l'ambito delle autorizzazioni disponibili concedibili ai principali. La catena di valutazione delle policy di autorizzazione comprende i guardrail così da determinare le *autorizzazioni effettive* di un principale quando adotta decisioni relative alle autorizzazioni. È possibile definire i guardrail utilizzando un approccio basato sui livelli. Applica alcuni guardrail in modo esteso all'intera organizzazione e applicane altri in modo granulare alle sessioni di accesso temporaneo.
**Risultato desiderato:** hai un chiaro isolamento degli ambienti utilizzando Account AWS separati. Le policy di controllo dei servizi (SCP) consentono di definire i guardrail delle autorizzazioni a livello di organizzazione. I guardrail più estesi sono impostati ai livelli gerarchici più vicini alla radice dell'organizzazione, mentre i guardrail più rigidi sono impostati più vicino al livello dei singoli account.
Se supportate, le policy sulle risorse definiscono le condizioni che un principale deve soddisfare per ottenere l'accesso a una risorsa. Le policy per le risorse, inoltre, definiscono l'insieme delle azioni consentite, laddove appropriato. I limiti delle autorizzazioni sono posti sui principali che gestiscono le autorizzazioni del carico di lavoro, delegando la gestione delle autorizzazioni ai singoli proprietari del carico di lavoro.
**Anti-pattern comuni:**
+ Creare membri di Account AWS all'interno di un'[organizzazione AWS](https://aws.amazon.com/organizations/), senza utilizzare SCP per limitare l'uso e le autorizzazioni disponibili alle relative credenziali root.
+ Assegnare le autorizzazioni in base al privilegio minimo, senza però porre guardrail sull'insieme massimo di autorizzazioni concedibili.
+ Affidarsi alla base di *rifiuto implicito* di AWS IAM per limitare le autorizzazioni, confidando nel fatto che le policy non concedano un'*autorizzazione esplicita* indesiderata.
+ Eseguire più ambienti di carico di lavoro nello stesso Account AWS e affidarsi quindi a meccanismi come VPC, tag o policy sulle risorse per applicare i limiti delle autorizzazioni.
**Vantaggi derivanti dall'adozione di questa best practice:** i guardrail di autorizzazione contribuiscono a creare la certezza che le autorizzazioni indesiderate non possano essere concesse, anche quando una policy di autorizzazione tenta di farlo. Ciò può semplificare la definizione e la gestione delle autorizzazioni riducendo l'ambito massimo delle autorizzazioni da prendere in considerazione.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all’implementazione
Ti consigliamo di utilizzare un approccio basato sui livelli per definire i guardrail di autorizzazione per la tua organizzazione. Questo approccio riduce in modo sistematico il set massimo di autorizzazioni possibili con l'applicazione di livelli aggiuntivi. Ciò consente di concedere l'accesso in base al principio del privilegio minimo, riducendo il rischio di accessi non intenzionali dovuti a un'errata configurazione delle policy.
Il primo passo per definire i guardrail delle autorizzazioni è isolare i carichi di lavoro e gli ambienti in Account AWS separati. I principali di un account non possono accedere alle risorse di un altro account senza l'autorizzazione esplicita in tal senso, anche se entrambi gli account fanno parte della stessa organizzazione AWS o della stessa [unità organizzativa](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html). Puoi utilizzare le unità organizzative per raggruppare gli account che desideri amministrare come una singola unità.
Il passaggio successivo consiste nel ridurre il set massimo di autorizzazioni che è possibile concedere ai principali all'interno degli account dei membri dell'organizzazione. A tale scopo, puoi utilizzare le [policy di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html), applicabili a un'unità organizzativa o a un account. Le policy di controllo dei servizi possono applicare controlli di accesso comuni, ad esempio limitare l'accesso a Regioni AWS specifiche, aiutare a prevenire l'eliminazione di risorse o disabilitare azioni di servizio potenzialmente rischiose. Le policy di controllo dei servizi applicate alla radice dell'organizzazione influiscono solo sugli account dei membri, non sull'account di gestione. Le policy di controllo dei servizi regolano solo i principali all'interno della tua organizzazione. Le tue policy di controllo dei servizi non regolano i principali esterni alla tua organizzazione che accedono alle tue risorse.
Se utilizzi [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html), puoi sfruttare i [controlli](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-controls-work) e le [zone di destinazione](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) come base per i guardrail delle autorizzazioni e l'ambiente multi-account. Le zone di destinazione forniscono un ambiente di base preconfigurato e sicuro, con account separati per diversi carichi di lavoro e applicazioni. I guardrail impongono controlli obbligatori su sicurezza, operazioni e conformità attraverso una combinazione di policy di controllo dei servizi, regole AWS Config e altre configurazioni. Tuttavia, quando si utilizzano guardrail e zone di destinazione di Control Tower insieme a SCP personalizzati dell'organizzazione, è fondamentale seguire le best practice descritte nella documentazione AWS per evitare conflitti e garantire una governance adeguata. Per suggerimenti dettagliati sulla gestione di SCP, account e unità organizzative (UO) in un ambiente Control Tower, fai riferimento alla [guida di AWS Control Tower per AWS Organizations](https://docs.aws.amazon.com/controltower/latest/userguide/orgs-guidance.html).
Se ti attieni a queste linee guida, puoi sfruttare efficacemente i guardrail, le zone di destinazione e gli SCP personalizzati di Control Tower, riducendo al contempo i potenziali conflitti e garantendo una governance e un controllo adeguati sull'ambiente AWS multi-account.
Un ulteriore passo consiste nell'utilizzare le [policy delle risorse IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based) per definire le azioni disponibili che puoi intraprendere sulle risorse da esse governate, oltre a tutte le condizioni che il principale che agisce deve soddisfare. Questo può essere un ambito ampio, come consentire tutte le azioni fintanto che il principale fa parte dell'organizzazione (utilizzando la [chiave di condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) PrincipalOrgId), o granulare, come consentire solo azioni specifiche da parte di un ruolo IAM specifico. Puoi adottare un approccio simile con le condizioni nelle policy di attendibilità del ruolo IAM. Se una policy di attendibilità di una risorsa o di un ruolo nomina esplicitamente un principale nello stesso account del ruolo o della risorsa che governa, tale principale non ha bisogno di una policy IAM associata che conceda le stesse autorizzazioni. Se il principale si trova in un account diverso dalla risorsa, deve disporre di una policy IAM associata che conceda tali autorizzazioni.
Spesso, un team addetto al carico di lavoro vorrà gestire le autorizzazioni richieste dal proprio carico di lavoro. Ciò potrebbe richiedere al team di creare nuovi ruoli IAM e policy di autorizzazione. Puoi definire l'ambito massimo di autorizzazioni che il team può concedere in un [limite delle autorizzazioni IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) e associare questo documento a un ruolo IAM, utilizzabile dal team per gestire autorizzazioni e ruoli IAM. Questo approccio può fornire la flessibilità necessaria per completare il lavoro, mitigando al contempo i rischi legati all'accesso amministrativo IAM.
Un passaggio più granulare consiste nell'implementazione delle tecniche di *gestione degli accessi privilegiati* (PAM) e di *gestione temporanea degli accessi elevati* (TEAM). Un esempio di gestione degli accessi privilegiati consiste nel richiedere ai principali di eseguire l'autenticazione a più fattori prima di intraprendere azioni privilegiate. Per ulteriori informazioni, consulta [Configuring MFA-protected API access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html). La gestione temporanea degli accessi elevati richiede una soluzione che gestisca l'approvazione e i tempi in cui un principale può avere un accesso elevato. Un approccio consiste nell'aggiungere temporaneamente il principale alla policy di attendibilità dei ruoli per un ruolo IAM con accesso elevato. Un altro approccio consiste nel ridurre, in condizioni di funzionamento normale, le autorizzazioni concesse a un principale da un ruolo IAM mediante una [policy di sessione](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session), quindi revocare in modo temporaneo questa restrizione durante la finestra temporale approvata. Per ulteriori informazioni sulle soluzioni convalidate da AWS e da alcuni partner selezionati, consulta [Temporary elevated access](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html).
### Passaggi dell'implementazione
1. Isola i carichi di lavoro e gli ambienti in Account AWS separati.
1. Usa le policy di controllo del servizio per ridurre il set massimo di autorizzazioni che possono essere concesse ai principali all'interno degli account membri della tua organizzazione.
1. Quando si definiscono SCP per ridurre l'insieme massimo di autorizzazioni che possono essere concesse ai principali all'interno degli account membri dell'organizzazione, è possibile scegliere tra un approccio di tipo *elenco di consentiti* o *elenco di rifiuto*. La strategia dell'elenco di consentiti specifica esplicitamente gli accessi consentiti e blocca implicitamente tutti gli altri accessi. La strategia dell'elenco di rifiuto specifica esplicitamente gli accessi non consentiti e consente tutti gli altri accessi per impostazione predefinita. Entrambe le strategie presentano vantaggi e compromessi e la scelta appropriata dipende dai requisiti specifici e dal modello di rischio dell'organizzazione. Per maggiori dettagli, consulta [Strategy for using SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html).
1. Inoltre, esamina gli [esempi di policy di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) per capire come creare le SCP in modo efficace.
1. Utilizza le policy relative alle risorse IAM per definire l'ambito e specificare le condizioni per le azioni consentite sulle risorse. Utilizza le condizioni nelle policy di fiducia dei ruoli IAM per creare restrizioni all'assunzione dei ruoli.
1. Assegna limiti delle autorizzazioni IAM ai ruoli IAM che i team del carico di lavoro possono quindi utilizzare per autorizzazioni e ruoli IAM del proprio carico di lavoro.
1. Valuta le soluzioni PAM e TEAM in base alle tue esigenze.
## Risorse
**Documenti correlati:**
+ [Data perimeters on AWS](https://aws.amazon.com/identity/data-perimeters-on-aws/)
+ [Establish permissions guardrails using data perimeters](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_data-perimeters.html)
+ [Logica di valutazione delle policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)
**Esempi correlati:**
+ [Service control policy examples](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
**Strumenti correlati:**
+ [AWS Solution: Temporary Elevated Access Management](https://aws-samples.github.io/iam-identity-center-team/)
+ [Validated security partner solutions for TEAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html#validatedpartners)
# SEC03-BP06 Gestione degli accessi in base al ciclo di vita
Monitora e regola le autorizzazioni concesse ai tuoi principali (utenti, ruoli e gruppi) durante il loro ciclo di vita all'interno dell'organizzazione. Adatta le appartenenze ai gruppi quando gli utenti cambiano ruolo e rimuovi l'accesso quando un utente lascia l'organizzazione.
**Risultato desiderato:** monitori e modifichi le autorizzazioni durante l'intero ciclo di vita dei principali all'interno dell'organizzazione, riducendo così il rischio di privilegi superflui. Concedi l'accesso appropriato quando crei un utente. L'accesso viene modificato man mano che cambiano le responsabilità dell'utente e lo si rimuove quando l'utente non è più attivo o ha lasciato l'organizzazione. Gestisci a livello centrale le modifiche ai tuoi utenti, ruoli e gruppi. Utilizza l'automazione per propagare le modifiche agli ambienti AWS.
**Anti-pattern comuni:**
+ Concedere in anticipo alle identità privilegi di accesso eccessivi o ampi, al di là di quanto richiesto inizialmente.
+ Non rivedere né modificare i privilegi di accesso in base al cambiamento dei ruoli e delle responsabilità delle identità nel tempo.
+ Lasciare le identità inattive o terminate con privilegi di accesso attivi. Ciò aumenta il rischio di accessi non autorizzati.
+ Non sfruttare l'automazione per gestire il ciclo di vita delle identità.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Gestisci e adatta attentamente i privilegi di accesso che concedi alle identità (come utenti, ruoli, gruppi) durante il loro ciclo di vita. Questo ciclo di vita include la fase iniziale di onboarding, i continui cambiamenti di ruoli e responsabilità e l'eventuale offboarding o cessazione. Gestisci in modo proattivo l'accesso in base alla fase del ciclo di vita per mantenere il livello di accesso appropriato. Rispetta il principio del privilegio minimo per ridurre il rischio di privilegi di accesso eccessivi o non necessari.
Puoi gestire il ciclo di vita degli utenti IAM direttamente all'interno dell'Account AWS o tramite federazione dal gestore dell'identità digitale della forza lavoro al [Centro identità AWS IAM](https://aws.amazon.com/iam/identity-center/). Per gli utenti IAM, puoi creare, modificare ed eliminare gli utenti e le relative autorizzazioni associate nell'Account AWS. Per gli utenti federati, puoi utilizzare il Centro identità IAM per gestire il ciclo di vita sincronizzando le informazioni sugli utenti e sui gruppi dal gestore dell'identità digitale dell'organizzazione mediante il protocollo [System for Cross-domain Identity Management](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) (SCIM).
SCIM è un protocollo standard aperto per il provisioning e il deprovisioning automatici delle identità degli utenti su diversi sistemi. Integrando il tuo gestore dell'identità digitale con il Centro identità IAM tramite SCIM, puoi sincronizzare in automatico le informazioni sugli utenti e sui gruppi, verificando che i privilegi di accesso siano concessi, modificati o revocati in base ai cambiamenti nella fonte di identità autorevole dell'organizzazione.
Man mano che i ruoli e le responsabilità dei dipendenti cambiano all'interno dell'organizzazione, modifica di conseguenza i loro privilegi di accesso. Puoi utilizzare i set di autorizzazioni del Centro identità IAM per definire diversi ruoli o responsabilità lavorative e associarli alle policy IAM e alle autorizzazioni appropriate. Quando il ruolo di un dipendente cambia, puoi aggiornare il set di autorizzazioni assegnato per riflettere le nuove responsabilità. Verifica che il dipendente disponga dell'accesso necessario rispettando il principio del privilegio minimo.
### Passaggi dell'implementazione
1. Definisci e documenta un processo del ciclo di vita della gestione degli accessi, comprese le procedure per la concessione dell'accesso iniziale, le revisioni periodiche e l'offboarding.
1. Implementa [ruoli IAM, gruppi e limiti delle autorizzazioni](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) per gestire l'accesso collettivamente e applicare i livelli di accesso massimi consentiti.
1. Effettua l'integrazione con un [gestore dell'identità digitale federato](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) (come Microsoft Active Directory, Okta, Ping Identity) come fonte autorevole per le informazioni sugli utenti e sui gruppi utilizzando il Centro identità IAM.
1. Utilizza il protocollo [SCIM](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) per sincronizzare le informazioni su utenti e gruppi dal gestore dell'identità digitale nell'Identity Store del Centro identità IAM.
1. Crea [set di autorizzazioni](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) nel Centro identità IAM che rappresentino diversi ruoli o responsabilità all'interno dell'organizzazione. Definisci autorizzazioni e policy IAM appropriate per ogni set di autorizzazioni.
1. Implementa revisioni regolari degli accessi, la relativa revoca tempestiva e il miglioramento continuo del processo del ciclo di vita della gestione degli accessi.
1. Offri formazione e sensibilizza i dipendenti in materia di best practice sulla gestione degli accessi.
## Risorse
**Best practice correlate:**
+ [SEC02-BP04 Fai affidamento su un gestore dell'identità digitale centralizzato](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
**Documenti correlati:**
+ [Manage your identity source ](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html)
+ [Manage identities in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)
+ [Uso di AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+ [IAM Access Analyzer policy generation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)
**Video correlati:**
+ [AWS re:Inforce 2023 - Manage temporary elevated access with AWS IAM Identity Center](https://www.youtube.com/watch?v=a1Na2G7TTQ0)
+ [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://www.youtube.com/watch?v=TvQN4OdR_0Y&t=444s)
+ [AWS re:Invent 2022 - Harness power of IAM policies & rein in permissions w/Access Analyzer](https://www.youtube.com/watch?v=x-Kh8hKVX74&list=PL2yQDdvlhXf8bvQJuSP1DQ8vu75jdttlM&index=11)
# SEC03-BP07 Analisi dell’accesso multi-account e pubblico
Monitora continuamente i risultati che evidenziano l’accesso multi-account e pubblico. Limita l’accesso multi-account e pubblico alle risorse che lo richiedono.
**Risultato desiderato:** conosci le risorse AWS condivise e con chi avviene la condivisione. Monitora e sottoponi costantemente ad audit le risorse condivise per verificare che siano condivise solo con i principali autorizzati.
**Anti-pattern comuni:**
+ Assenza di un inventario delle risorse condivise.
+ Mancanza di un processo di approvazione dell’accesso multi-account e dell’accesso pubblico alle risorse.
**Livello di rischio associato se questa best practice non fosse adottata:** basso
## Guida all’implementazione
Se l’account è in AWS Organizations, puoi concedere l’accesso alle risorse all’intera organizzazione, a specifiche unità organizzative o a singoli account. Se l’account non è membro di un’organizzazione, puoi condividere le risorse con account individuali. Puoi concedere l’accesso multi-account diretto utilizzando policy basate sulle risorse, ad esempio le policy di bucket di [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) o consentendo a un principale di un altro account di assumere un ruolo IAM nel tuo account. Quando utilizzi le policy sulle risorse, verifica che l’accesso sia concesso solo ai principali autorizzati. Definisci un processo per approvare tutte le risorse che devono essere pubblicamente disponibili.
[AWS Identity and Access Management Access Analyzer](https://aws.amazon.com/iam/features/analyze-access/) utilizza una [sicurezza comprovabile](https://aws.amazon.com/security/provable-security/) per identificare tutti i percorsi di accesso a una risorsa dall’esterno del proprio account. Esamina continuamente le policy delle risorse e segnala i risultati dell’accesso multi-account e pubblico per semplificare l’analisi di accessi potenzialmente estesi. Prendi in considerazione la configurazione di IAM Access Analyzer con AWS Organizations per verificare di avere visibilità su tutti i tuoi account. IAM Access Analyzer consente inoltre di [visualizzare in anteprima i risultati](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html) prima di implementare le autorizzazioni per le risorse. In questo modo è possibile verificare che le modifiche alle policy garantiscano alle risorse solo l’accesso multi-account e pubblico previsto. In caso di progettazione per l’accesso multi-account, puoi utilizzare [policy di affidabilità](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/) per controllare i casi in cui è possibile assumere un ruolo. Ad esempio, puoi utilizzare la [chiave di condizione `PrincipalOrgId` per negare un tentativo di assumere un ruolo al di fuori di AWS Organizations](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/).
[AWS Config è grado di segnalare le risorse](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-Publicly-Accessible-Resources.html) non configurate correttamente. Inoltre, tramite i controlli delle policy AWS Config, rileva le risorse con l’accesso pubblico configurato. Servizi come [AWS Control Tower](https://aws.amazon.com/controltower/) e [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) semplificano l’implementazione di controlli di rilevamento e guardrail in AWS Organizations per identificare e correggere le risorse pubblicamente esposte. Ad esempio, AWS Control Tower dispone di un guardrail gestito in grado di rilevare se eventuali [snapshot Amazon EBS sono ripristinabili tramite Account AWS](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html).
### Passaggi dell’implementazione
+ **Prendi in considerazione l’utilizzo di [AWS Config per AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html):** AWS Config consente di aggregare gli esiti di più account all’interno di AWS Organizations in un account amministratore delegato. In questo modo, avrai una visione completa e potrai eseguire l’[implementazione di Regole di AWS Config su più account per rilevare risorse accessibili al pubblico](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html).
+ **Configurare AWS Identity and Access Management Access Analyzer:** consente di identificare le risorse nell’organizzazione e negli account, ad esempio bucket Amazon S3 o ruoli IAM, [condivise con un’entità esterna](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html).
+ **Usa la riparazione automatica in AWS Config per rispondere alle modifiche nella configurazione dell’accesso pubblico dei bucket Amazon S3:** [ puoi attivare in automatico le impostazioni di blocco dell’accesso pubblico per i bucket Amazon S3](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/).
+ **Implementa monitoraggio e avvisi per stabilire se i bucket Amazon S3 sono diventati pubblici**: devi disporre di [monitoraggio e avvisi](https://aws.amazon.com/blogs/aws/amazon-s3-update-cloudtrail-integration/) per stabilire se il blocco dell’accesso pubblico Amazon S3 è disattivato e se i bucket Amazon S3 diventano pubblici. Inoltre, se utilizzi AWS Organizations, puoi creare una [policy di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) che impedisca modifiche alle policy di accesso pubblico di Amazon S3. [AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html) verifica la presenza di bucket Amazon S3 dotati di autorizzazioni di accesso aperte. Le autorizzazioni bucket che concedono, caricano o eliminano l’accesso per chiunque danno origine a potenziali problemi di sicurezza, consentendo a chiunque di aggiungere, modificare o rimuovere elementi in un bucket. Il controllo di Trusted Advisor esamina le autorizzazioni bucket esplicite e le policy associate che possono prevalere sulle autorizzazioni bucket. Puoi anche utilizzare AWS Config per monitorare l’accesso pubblico ai bucket Amazon S3. Per ulteriori informazioni, consulta [How to Use AWS Config to Monitor for and Respond to Amazon S3 Buckets Allowing Public Access](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/).
Quando si esaminano i controlli di accesso per i bucket Amazon S3, è importante considerare la natura dei dati memorizzati al loro interno. [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/findings-types.html) è un servizio progettato per aiutarti a scoprire e proteggere dati sensibili, come informazioni di identificazione personale (PII), dati sanitari protetti (PHI) e credenziali come chiavi private o chiavi di accesso AWS.
## Risorse
**Documenti correlati:**
+ [Using AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html?ref=wellarchitected)
+ [AWS Control Tower controls library ](https://docs.aws.amazon.com/controltower/latest/userguide/controls-reference.html)
+ [AWS Foundational Security Best Practices standard](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html)
+ [AWS Config Regole gestite da](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html)
+ [AWS Trusted Advisor check reference](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html)
+ [ Monitoring AWS Trusted Advisor check results with Amazon EventBridge ](https://docs.aws.amazon.com/awssupport/latest/user/cloudwatch-events-ta.html)
+ [ Managing AWS Config Rules Across All Accounts in Your Organization ](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html)
+ [AWS Config e AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html)
+ [ Make your AMI publicly available for use in Amazon EC2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-intro.html#block-public-access-to-amis)
**Video correlati:**
+ [Best Practices for securing your multi-account environment](https://www.youtube.com/watch?v=ip5sn3z5FNg)
+ [Dive Deep into IAM Access Analyzer](https://www.youtube.com/watch?v=i5apYXya2m0)
# SEC03-BP08 Condivisione delle risorse in modo sicuro all'interno dell'organizzazione
Con l'aumento del numero di carichi di lavoro, è possibile che sia necessario condividere l'accesso alle risorse in tali carichi di lavoro o eseguire il provisioning delle risorse più volte su più account. Possono esistere costrutti per segmentare il proprio l'ambiente, come ambienti di sviluppo, di test e di produzione. Tuttavia, la presenza di costrutti di separazione non limita la possibilità di condivisione sicura. La condivisione di componenti sovrapposti consente di ridurre i costi operativi e di garantire un'esperienza coerente, senza dover intuire cosa potrebbe sfuggire durante la creazione della stessa risorsa più volte.
**Risultato desiderato:** ridurre al minimo gli accessi involontari tramite l'uso di metodi sicuri di condivisione delle risorse all'interno dell'organizzazione e contribuire alle iniziative di prevenzione della perdita dei dati. Ridurre i costi operativi rispetto alla gestione dei singoli componenti, ridurre gli errori dovuti alla creazione manuale dello stesso componente più volte e aumentare la scalabilità dei carichi di lavoro. Si riducono i tempi di risoluzione in caso di guasti multipli e si aumenta la sicurezza nel determinare quando un componente non è più necessario. Per linee guida prescrittive sull'analisi delle risorse condivise all'esterno, consulta [SEC03-BP07 Analisi dell’accesso multi-account e pubblico](sec_permissions_analyze_cross_account.md).
**Anti-pattern comuni:**
+ Mancanza di un processo per il monitoraggio continuo e segnalazione automatica di condivisioni esterne inaspettate.
+ Mancanza di una linea di base su ciò che deve e ciò che non deve essere condiviso.
+ Scelta di una policy di ampia apertura piuttosto che di una condivisione esplicita quando richiesto.
+ Creazione manuale di risorse fondamentali che si sovrappongono quando necessario.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Progetta controlli e modelli di accesso per gestire il consumo di risorse condivise in modo sicuro e solo con entità fidate. Monitora le risorse condivise e controllane in modo costante l'accesso, ricevendo un avviso in caso di condivisione inappropriata o inaspettata. Consulta [Analisi dell'accesso multi-account e pubblico](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html) per stabilire una governance che riduca l'accesso esterno alle sole risorse che lo richiedono e per stabilire un processo di monitoraggio continuo e avvisi automatici.
La condivisione tra più account all'interno di AWS Organizations è [supportata da diversi servizi AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html), come [AWS Security Hub CSPM](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-securityhub.html), [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html) e [AWS Backup](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-backup.html). Questi servizi permettono di condividere i dati con un account centrale, di accedere a un account centrale o di gestire risorse e dati da un account centrale. Ad esempio, AWS Security Hub CSPM può trasferire gli esiti dai singoli account a un account centrale in cui è possibile visualizzare tutti gli esiti. AWS Backup può eseguire un backup di una risorsa e condividerlo tra gli account. Puoi usare [AWS Resource Access Manager](https://aws.amazon.com/ram/) (AWS RAM) per la condivisione di altre risorse comuni, come [sottoreti VPC e collegamenti del gateway di transito alla VPN](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc), [AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall) o [pipeline IA di Amazon SageMaker](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker).
Per limitare l'account in modo che condivida sole risorse all'interno dell'organizzazione, utilizza le [policy di controllo dei servizi (SCP)](https://docs.aws.amazon.com/ram/latest/userguide/scp.html) per impedire l'accesso a principali esterni. In caso di condivisione di risorse, combina controlli basati sull'identità e di rete per [creare un perimetro di dati per l'organizzazione](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) e proteggere la stessa da accessi involontari. Un perimetro di dati è un insieme di guardrail preventivi che aiutano a verificare che solo le identità fidate accedano a risorse fidate dalle reti previste. Questi controlli pongono limiti adeguati alle risorse condivisibili e impediscono la condivisione o l'esposizione di risorse che non sono consentite. Ad esempio, nell'ambito del tuo perimetro di dati, puoi utilizzare le policy degli endpoint VPC e la condizione `AWS:PrincipalOrgId` per garantire che le identità che accedono ai bucket Amazon S3 appartengano alla tua organizzazione. È importante sottolineare che le [SCP non si applicano a ruoli collegati a servizi o a principali dei servizi AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions).
Se usi Amazon S3, [disattiva gli ACL per il bucket Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) e definisci il controllo degli accessi con le policy IAM. Per [limitare l'accesso a un'origine Amazon S3](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) da [Amazon CloudFront](https://aws.amazon.com/cloudfront/), effettua la migrazione dall'identità di accesso origine (OAI) al controllo di accesso origine (OAC) che supporta funzionalità aggiuntive, tra cui la crittografia lato server con [AWS Key Management Service](https://aws.amazon.com/kms/).
In alcuni casi, può essere necessario condividere le risorse al di fuori dell'organizzazione o concedere a terze parti l'accesso alle risorse stesse. Per linee guida prescrittive sulla gestione delle autorizzazioni per la condivisione esterna delle risorse, consulta [Gestione delle autorizzazioni](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html).
### Passaggi dell'implementazione
1. **Utilizzo di AWS Organizations -** AWS Organizations è un servizio di gestione degli account che consente di consolidare più Account AWS in un'organizzazione, che è possibile creare e gestire in modo centralizzato. È possibile raggruppare gli account in unità organizzative (OU) e associare policy diverse a ciascuna di esse per soddisfare le esigenze di bilancio, sicurezza e conformità. È inoltre possibile controllare il modo in cui i servizi di Intelligenza Artificiale (IA) e di machine learning (ML) di AWS possono raccogliere e archiviare i dati e utilizzare la gestione multi-account dei servizi AWS integrati nelle organizzazioni.
1. **Integrazione di AWS Organizations con i servizi AWS -** Se usi un servizio AWS per eseguire attività per tuo conto negli account membri dell'organizzazione, AWS Organizations crea un ruolo collegato ai servizi IAM (SLR) per tale servizio in ogni account membro. L'accesso attendibile deve essere gestito tramite la Console di gestione AWS, le API AWS o la AWS CLI. Per linee guida prescrittive sull'attivazione dell'accesso attendibile, consulta [Using AWS Organizations with other AWS services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html) e [AWS services that you can use with Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html).
1. **Definizione di un perimetro dati -** Un perimetro dati fornisce un limite ben chiaro per attendibilità e proprietà. Su AWS, solitamente è rappresentato come la tua organizzazione AWS gestita tramite AWS Organizations, insieme a eventuali sistemi o reti on-premises che accedono alle tue risorse AWS. L'obiettivo del perimetro dati è verificare che l'accesso sia consentito se l'identità è attendibile, la risorsa è attendibile e la rete è conforme. Tuttavia, la definizione di un perimetro di dati non è una soluzione adatta a tutti gli scenari. Valuta e adotta gli obiettivi di controllo delineati nel [white paper Building a Perimeter on AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/welcome.html) in base ai tuoi specifici modelli e requisiti di rischio per la sicurezza. Devi valutare attentamente la tua specifica posizione di rischio e implementare i controlli perimetrali in linea con le tue esigenze di sicurezza.
1. **Utilizzo della condivisione delle risorse nei servizi AWS e restrizioni correlate -** Molti servizi AWS consentono di condividere risorse con altri account o di destinare risorse ad altri account, come ad esempio [Amazon Machine Image (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) e [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html). Limita l'API `ModifyImageAttribute` in modo da specificare gli account affidabili con cui condividere l'AMI. Specifica la condizione `ram:RequestedAllowsExternalPrincipals` in caso di utilizzo di AWS RAM per limitare la condivisione solo alla tua organizzazione e impedire l'accesso di identità non attendibili. Per considerazioni e linee guida prescrittive, consulta [Resource sharing and external targets](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html).
1. **Utilizzo di AWS RAM per condividere risorse in modo sicuro all'interno di un account o con altri Account AWS -** [AWS RAM](https://aws.amazon.com/ram/) ti consente di condividere in modo sicuro le risorse create con i ruoli e gli utenti del tuo account e di altri Account AWS. In un ambiente multi-account, AWS RAM consente di creare una risorsa una sola volta e di condividerla con altri account. Questo approccio contribuisce a ridurre i costi operativi, fornendo al contempo coerenza, visibilità e la facilità di audit grazie alle integrazioni con Amazon CloudWatch e AWS CloudTrail, che non si ottengono quando si utilizza l'accesso multi-account.
Se disponi di risorse condivise in precedenza mediante una policy basata sulle risorse, puoi utilizzare l'[API `PromoteResourceShareCreatedFromPolicy`](https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html) o un metodo equivalente per promuovere il passaggio da una condivisione di risorse a una condivisione completa di risorse completa AWS RAM.
In alcuni casi, potrebbe essere necessario adottare ulteriori misure per condividere le risorse. Ad esempio, per condividere uno snapshot crittografato, occorre [condividere una chiave AWS KMS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html#share-kms-key).
## Risorse
**Best practice correlate:**
+ [SEC03-BP07 Analisi dell’accesso multi-account e pubblico](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP09 Condivisione sicura delle risorse con terze parti](sec_permissions_share_securely_third_party.md)
+ [SEC05-BP01 Creazione di livelli di rete](sec_network_protection_create_layers.md)
**Documenti correlati:**
+ [Bucket owner granting cross-account permission to objects it does not own](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [How to use Trust Policies with IAM](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Building Data Perimeter on AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)
+ [Come utilizzare un ID esterno quando si concede a una terza parte l'accesso alle risorse AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [AWS services you can use with AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)
+ [ Establishing a data perimeter on AWS: Allow only trusted identities to access company data ](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-identities-to-access-company-data/)
**Video correlati:**
+ [Granular Access with AWS Resource Access Manager](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [Securing your data perimeter with VPC endpoints](https://www.youtube.com/watch?v=iu0-o6hiPpI)
+ [ Establishing a data perimeter on AWS](https://www.youtube.com/watch?v=SMi5OBjp1fI)
**Strumenti correlati:**
+ [ Esempi di policy del perimetro di dati ](https://github.com/aws-samples/data-perimeter-policy-examples)
# SEC03-BP09 Condivisione sicura delle risorse con terze parti
La sicurezza dell'ambiente cloud non si ferma alla tua organizzazione. L'organizzazione potrebbe affidare a terze parti la gestione di una parte dei dati. La gestione dei permessi per il sistema gestito da terze parti deve seguire la pratica dell'accesso just-in-time utilizzando il principio del privilegio minimo con credenziali temporanee. Lavorando a stretto contatto con una terza parte, puoi ridurre allo stesso momento la portata dell'impatto e il rischio di accesso non intenzionale.
**Risultato desiderato:** non vengono utilizzate credenziali AWS Identity and Access Management (IAM) a lungo termine come chiavi di accesso e chiavi segrete, poiché rappresentano un rischio per la sicurezza se utilizzate in modo improprio. Al contrario, vengono utilizzati i ruoli IAM e le credenziali temporanee per migliorare il livello di sicurezza e ridurre al minimo il sovraccarico operativo legato alla gestione delle credenziali a lungo termine. Quando concedi l'accesso a terze parti, utilizzi un identificativo univoco universale (UUID) come ID esterno nella policy di attendibilità IAM e mantieni sotto il tuo controllo le policy IAM collegate al ruolo per garantire l'accesso con il privilegio minimo. Per linee guida prescrittive sull'analisi delle risorse condivise a livello esterno, consulta [SEC03-BP07 Analisi dell'accesso multi-account e pubblico](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html).
**Anti-pattern comuni:**
+ Utilizzo della policy di attendibilità IAM predefinita senza alcuna condizione.
+ Utilizzo di credenziali IAM e chiavi di accesso a lungo termine.
+ Riutilizzo di ID esterni.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
In alcuni casi, può essere necessario condividere le risorse al di fuori di AWS Organizations o concedere a terze parti l'accesso alle risorse stesse. Ad esempio, una terza parte potrebbe fornire una soluzione di monitoraggio che necessita di accedere alle risorse del tuo account. In questi casi, devi creare un ruolo IAM multi-account con i soli privilegi necessari alla terza parte. Inoltre, definisci una policy di attendibilità utilizzando la [condizione ID esterno](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html). L'utilizzo di un ID esterno da parte tua o della terza parte può comportare la generazione di un ID univoco per ogni cliente, terza parte o tenancy. Una volta creato, l'ID univoco non deve essere controllato da nessuno, se non da te. La terza parte deve implementare un processo per collegare l'ID esterno al cliente in modo sicuro, verificabile e riproducibile.
Puoi anche utilizzare [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) per la gestione dei ruoli IAM per le applicazioni all'esterno di AWS che non utilizzano API AWS.
Se la terza parte non ha più bisogno di accedere al tuo ambiente, rimuovi il ruolo. Evita di fornire a terze parti credenziali a lungo termine. Mantieni la visibilità degli altri servizi AWS che supportano la condivisione, come AWS Well-Architected Tool che consente di [condividere un carico di lavoro](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-sharing.html) con altri Account AWS e [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) che permette di condividere in modo sicuro una risorsa AWS di tua proprietà con altri account.
### Passaggi dell'implementazione
1. **Utilizza ruoli multi-account per fornire l'accesso agli account esterni.** I [ruoli multi-account](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) riducono la quantità di informazioni sensibili archiviate da account esterni e terze parti per l'assistenza ai propri clienti. I ruoli multi-account consentono di concedere l'accesso alle risorse AWS dell'account in modo sicuro a terze parti, come i Partner AWS o altri account dell'organizzazione, mantenendo la possibilità di gestire e sottoporre a audit tale accesso. La terza parte può fornire il servizio da un'infrastruttura ibrida o, in alternativa, estrarre i dati in una sede esterna. [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) consente ai carichi di lavoro di terze parti di interagire in modo sicuro con i tuoi carichi di lavoro AWS e di ridurre ulteriormente la necessità di credenziali a lungo termine.
Non devi utilizzare credenziali a lungo termine o chiavi di accesso associate agli utenti per fornire accesso ad account esterni. Per fornire l'accesso multi-account invece, occorre utilizzare i ruoli multi-account.
1. **Effettua verifiche di due diligence e garantisci un accesso sicuro per i provider SaaS di terze parti.** Quando condividi alcune risorse con provider SaaS di terze parti, esegui un'attenta due diligence per assicurarti che abbiano un approccio sicuro e responsabile all'accesso alle tue risorse AWS. Valuta il loro modello di responsabilità condivisa per capire quali misure di sicurezza forniscono e cosa rientra nella tua responsabilità. Assicurati che il provider SaaS disponga di un processo sicuro e verificabile per l'accesso alle tue risorse, incluso l'uso di [ID esterni](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) e principi di accesso con privilegio minimo. L'uso di ID esterni aiuta a risolvere i [problemi di "confused deputy"](https://aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/).
Implementa controlli di sicurezza per garantire un accesso sicuro e il rispetto del principio del privilegio minimo quando concedi l'accesso a provider SaaS di terze parti. Ciò può includere l'uso di ID esterni, di identificatori univoci universali (UUID) e di policy di attendibilità IAM che limitano l'accesso solo a ciò che è strettamente necessario. Collabora a stretto contatto con il provider SaaS per stabilire meccanismi di accesso sicuri, controllarne regolarmente l'accesso alle risorse AWS e condurre audit per garantire il rispetto dei requisiti di sicurezza.
1. **Rendi obsolete le credenziali a lungo termine fornite dal cliente.** Rendi obsoleto l'uso di credenziali a lungo termine e utilizza ruoli multi-account oppure IAM Roles Anywhere. Se devi utilizzare credenziali a lungo termine, stabilisci un piano per migrare verso l'accesso basato sui ruoli. Per i dettagli sulla gestione delle chiavi, consulta [Gestione delle identità](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-management.html). Collabora inoltre con il team dell'Account AWS e con la terza parte per predisporre un runbook di mitigazione dei rischi. Per un prontuario su come rispondere e mitigare il potenziale impatto di un incidente di sicurezza, consulta [Risposta agli imprevisti](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html).
1. **Verifica che la configurazione presenti indicazioni prescrittive o sia automatizzata.** L'ID esterno non viene trattato come un segreto, ma non deve essere un valore facilmente individuabile, come un numero di telefono, un nome o un ID account. Rendi l'ID esterno un campo di sola lettura, in modo che non possa essere modificato per rappresentare la configurazione.
L'ID esterno può essere generato da te o dalla terza parte. Definisci un processo per stabilire chi è responsabile della generazione dell'ID. Indipendentemente dall'entità che crea l'ID esterno, la terza parte fa rispettare l'univocità e i formati in modo coerente tra i clienti.
La policy creata per l'accesso multi-account ai tuoi account deve attenersi al [principio del privilegio minimo.](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) La terza parte deve fornire un documento sulla policy del ruolo o un meccanismo di configurazione automatica che utilizzi un modello AWS CloudFormation o un equivalente per l'utente. In questo modo si riduce la possibilità di errori associati alla creazione manuale della policy e si offre un audit trail. Per ulteriori informazioni sull'utilizzo di un modello AWS CloudFormation per creare ruoli multi-account, consulta [Cross-Account Roles](https://aws.amazon.com/blogs/apn/tag/cross-account-roles/).
La terza parte deve fornire un meccanismo di configurazione automatizzato e verificabile. Tuttavia, utilizzando il documento della policy sui ruoli che delinea gli accessi necessari, è possibile automatizzare l'impostazione del ruolo. Con un modello AWS CloudFormation o equivalente, è necessario monitorare le modifiche con il rilevamento delle deviazioni come parte della pratica di audit.
1. **Tieni conto delle modifiche.** La struttura del tuo account, la tua necessità di una terza parte o l'offerta di servizi che ti viene fornita possono cambiare. Occorre anticipare cambiamenti e guasti, quindi pianificare di conseguenza con le persone, i processi e le tecnologie adeguati. Sottoponi periodicamente a audit il livello di accesso fornito e implementa metodi di rilevamento per avvisare l'utente di cambiamenti inattesi. Monitora e sottoponi ad audit l'uso del ruolo e del datastore degli ID esterni. Occorre essere pronti a revocare l'accesso a terze parti, in modo temporaneo o permanente, in seguito a modifiche o modelli di accesso imprevisti. Inoltre, valuta l'impatto dell'operazione di revoca, compreso il tempo necessario per eseguirla, le persone coinvolte, il costo e l'impatto su altre risorse.
Per linee guida prescrittive sui metodi di rilevamento, consulta le [best practice di rilevamento](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html).
## Risorse
**Best practice correlate:**
+ [SEC02-BP02 Utilizzo di credenziali temporanee](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC03-BP05 Definizione dei guardrail per le autorizzazioni dell'organizzazione](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_define_guardrails.html)
+ [SEC03-BP06 Gestione degli accessi in base al ciclo di vita](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html)
+ [SEC03-BP07 Analisi dell'accesso multi-account e pubblico](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [SEC04 Rilevamento](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
**Documenti correlati:**
+ [Bucket owner granting cross-account permission to objects it does not own](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [How to use trust policies with IAM roles](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Delegate access across Account AWS using IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ [How do I access resources in another Account AWS using IAM?](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-iam/)
+ [Best practice per la sicurezza in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Cross-account policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)
+ [How to use an external ID when granting access to your AWS resources to a third party](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [Collecting Information from AWS CloudFormation Resources Created in External Accounts with Custom Resources](https://aws.amazon.com/blogs/apn/collecting-information-from-aws-cloudformation-resources-created-in-external-accounts-with-custom-resources/)
+ [Securely Using External ID for Accessing AWS Accounts Owned by Others](https://aws.amazon.com/blogs/apn/securely-using-external-id-for-accessing-aws-accounts-owned-by-others/)
+ [Extend IAM roles to workloads outside of IAM with IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/)
**Video correlati:**
+ [How do I allow users or roles in a separate Account AWS access to my Account AWS?](https://www.youtube.com/watch?v=20tr9gUY4i0)
+ [AWS re:Invent 2018: Become an IAM Policy Master in 60 Minutes or Less](https://www.youtube.com/watch?v=YQsK4MtsELU)
+ [AWS Knowledge Center Live: IAM Best Practices and Design Decisions](https://www.youtube.com/watch?v=xzDFPIQy4Ks)
**Esempi correlati:**
+ [Configurazione dell'accesso multi-account in Amazon DynamoDB](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html)
+ [Strumento di query di rete AWS STS](https://github.com/aws-samples/aws-sts-network-query-tool)