# SEC 3. Come si gestisce l'autenticazione per persone e macchine? Gestisci le autorizzazioni per controllare l'accesso alle identità di persone e macchine che richiedono l'accesso ad AWS e al tuo carico di lavoro. Le autorizzazioni controllano chi può accedere a cosa e a quali condizioni. **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 pubblico e multi-account](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. Individua una definizione chiara di chi o cosa deve avere accesso a ciascun componente, quindi 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:** alto ## Guida all'implementazione Ogni componente o risorsa del carico di lavoro deve essere accessibile da amministratori, utenti finali o altri componenti. Individua una definizione chiara di chi o cosa deve avere accesso a ciascun componente, quindi scegli il tipo di identità e il metodo di autenticazione e autorizzazione appropriati. L'accesso regolare agli Account AWS dell'organizzazione viene fornito utilizzando [l'accesso federato](https://aws.amazon.com/identity/federation/) o un gestore dell'identità 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, quando 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. Quando si definiscono i requisiti di accesso per le identità non umane, determina quali applicazioni e componenti devono accedere e come vengono concesse le autorizzazioni. L'utilizzo di ruoli IAM creati con il modello di accesso con privilegi minimi è un approccio consigliato. [Le policy gestite da AWS](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 [Archivio dei parametri AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)ti consentono di scollegare i segreti dall'applicazione o dal carico di lavoro in modo sicuro nei casi in cui non è possibile utilizzare i ruoli IAM. 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 usare AWS Identity and Access Management Roles Anywhere per ottenere [credenziali di sicurezza temporanee in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) per i 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 [ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) che usi 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 gli utenti IAM devono avere l'accesso programmatico e credenziali a lungo termine, utilizza [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 ruotare e rimuovere le chiavi di accesso. ## Risorse **Documenti correlati:** + [Il controllo dell'accesso basato su attributi (Attribute-Based Access Control, 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 (Policy gestite da AWS per IAM Identity Center)](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) + [AWS IAM policy conditions (Condizioni delle policy AWS 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) + [Rimozione di 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 (Come controllare l'accesso alle risorse AWS in base all'account, all'unità organizzativa o all'organizzazione AWS)](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 (Identificazione, organizzazione e gestione semplificate dei segreti con la ricerca avanzata di 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 (Diventa un IAM Policy Master in 60 minuti)](https://youtu.be/YQsK4MtsELU) + [Separation of Duties, Least Privilege, Delegation, and CI/CD (Separazione dei compiti, privilegio minimo, delega e integrazione e distribuzione continua (CI/CD)](https://youtu.be/3H0i7VyTu70) + [Streamlining identity and access management for innovation (Semplificazione della gestione delle identità e degli accessi per l'innovazione)](https://www.youtube.com/watch?v=3qK0b1UkaE8) # SEC03-BP02 Concessione dell'accesso con privilegio minimo È una best practice concedere alle identità soltanto il livello di accesso di cui hanno bisogno, specificando le operazioni che possono effettuare, le risorse su cui possono operare e a quali condizioni. Affidati ai gruppi e agli attributi di identità per impostare dinamicamente 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, il suo accesso viene automaticamente revocato senza modificare le policy di accesso sottostanti. **Risultato desiderato:** gli utenti devono avere solo le autorizzazioni necessarie per portare a termine la loro attività. Gli utenti dovrebbero avere accesso solo agli ambienti di produzione per eseguire un'attività specifica in un intervallo temporale limitato e l'accesso dovrebbe essere revocato una volta completata l'attività. Le autorizzazioni devono essere revocate quando non sono più necessarie, incluso quando un utente passa a un progetto o a un ruolo professionale diversi. I privilegi di amministratore devono essere riservati a un piccolo gruppo di amministratori fidati. Le autorizzazioni devono essere riviste con regolarità per evitare che si accumulino. Account di sistemi o di macchine devono avere il numero minimo di autorizzazioni necessarie per portare a termine un'attività. **Anti-pattern comuni:** + L'impostazione predefinita è la concessione delle autorizzazioni di amministratore agli utenti. + L'utilizzo dell'utente root per le attività quotidiane. + Creazione di policy eccessivamente permissive, ma senza privilegi completi di amministratore. + La mancata revisione delle autorizzazioni per capire se consentono l'accesso privilegio minimo. **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//latest/UserGuide/best-practices.html#grant-least-privilege) le identità dovrebbero essere consentite solo per eseguire il numero minimo di azioni necessarie per completare 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. Gli utenti e i ruoli IAM non hanno autorizzazioni per impostazione predefinita. L'utente root ha accesso completo per impostazione predefinita e dovrebbe essere controllato e monitorato con zelo, nonché usato solo per le [attività che richiedono l'accesso root](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Le policy IAM sono utilizzate in modo esplicito per concedere 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 e colleghi una policy IAM, puoi specificare le azioni del servizio, le risorse e le condizioni che devono essere vere affinché AWS consenta o neghi l'accesso. AWS supporta una varietà di condizioni che contribuiscono a ridurre l'accesso. Ad esempio, se usi la [chiave di condizione](https://docs.aws.amazon.com//latest/UserGuide/reference_policies_condition-keys.html) `PrincipalOrgID`, puoi non autorizzare le operazioni se il richiedente non è parte della tua AWS Organization. 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`. Dovresti avere tipi diversi di policy su più livelli per definire un livello di difesa ben radicato e limitare le autorizzazioni complessive dei tuoi utenti. Puoi anche limitare le autorizzazioni che possono essere concesse e a quali condizioni. Ad esempio, puoi consentire ai team delle applicazioni di creare le proprie policy IAM per i sistemi che creano, ma devi anche applicare un [limite delle autorizzazioni](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) per impostare un limite massimo di autorizzazioni che il sistema può ricevere. **Passaggi dell'implementazione** + **Implementazione di policy con privilegi minimi**: assegna policy di accesso con privilegi minimi a gruppi e ruoli IAM in modo da rispecchiare il ruolo o la funzione dell'utente che hai definito. + **Policy di base sull'uso delle API**: un modo per stabilire le autorizzazioni necessarie consiste nell'analisi dei log AWS CloudTrail. Questa revisione consente di creare autorizzazioni personalizzate in base alle azioni che l'utente deve realmente eseguire in AWS. [IAM Access Analyzer può generare automaticamente una policy IAM basata](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) [su attività](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/). Puoi usare IAM Access Advisor a livello di account o di organizzazione per [monitorare](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html) [le ultime informazioni consultate per una policy specifica](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html). + **Prendi in considerazione l'uso di [policy gestite da AWS per le funzioni dell'attività](https://docs.aws.amazon.com//latest/UserGuide/access_policies_job-functions.html).** Quando inizi a creare policy di autorizzazioni dettagliate, può essere difficile sapere da dove iniziare. AWS ha policy gestite per ruoli professionali comuni, ad esempio contabili, amministratori di database e data scientist. Queste policy possono contribuire a limitare l'accesso degli utenti e, al contempo, definiscono come implementare le policy di privilegio minimo. + **Rimuovi le autorizzazioni superflue:** rimuovi le autorizzazioni non necessarie e rivedi quelle eccessivamente permissive. La [generazione di policy di IAM Access Analyzer](https://docs.aws.amazon.com//latest/UserGuide/access-analyzer-policy-generation.html) può essere utile per perfezionare le policy relative alle autorizzazioni. + **Verifica che gli utenti abbiano un accesso limitato agli ambienti di produzione:** gli utenti possono accedere agli ambienti di produzione solo se hanno 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. + **Considerazioni sui limiti delle autorizzazioni:** un limite delle autorizzazioni è una caratteristica avanzata per utilizzare una policy gestita che imposta il numero massimo di autorizzazioni che una policy basata su identità può concedere a un'entità IAM. Il limite delle autorizzazioni di un'entità le permette di eseguire solo le operazioni consentite dalle policy basate su identità e dai limiti delle autorizzazioni.   + **Prendi in considerazione i [tag delle risorse](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) per le autorizzazioni:** un modello di controllo degli accessi basato su attributi che usa tag delle risorse ti consente di concedere l'accesso in base a scopo delle risorse, proprietario, ambiente e altri criteri. Ad esempio, puoi usare tag di risorse per diversificare gli ambienti di produzione e sviluppo. Tramite questi tag puoi limitare gli sviluppatori all'ambiente di sviluppo. Abbinando policy su tag e autorizzazioni, puoi ottenere l'accesso a risorse dettagliate senza dover definire policy personalizzate e complesse per ogni funzione professionale. + **Usa [policy di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) per AWS Organizations.** Le policy di controllo dei servizi monitorano centralmente il numero massimo di autorizzazioni disponibili per gli account membri della tua organizzazione. È importante notare che le policy di controllo dei servizi consentono di limitare le autorizzazioni dell'utente root negli account membri. Considera anche 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 dell'utente per la tua organizzazione:** le policy del ciclo di vita dell'utente definiscono attività da eseguire quando gli utenti eseguono l'onboarding su AWS, cambiano ruolo o ambito professionale o non hanno più bisogno di accedere a AWS. Le revisioni delle autorizzazioni devono essere eseguite in ogni fase del ciclo di vita di un utente per verificare che siano sufficientemente restrittive e per evitare che si accumulino. + **Stabilisci un piano per analizzare le autorizzazioni con regolarità ed eventualmente rimuovere quelle non necessarie:** dovresti periodicamente analizzare l'accesso degli utenti per verificare che non abbiano autorizzazioni troppo permissive. [AWS Config](https://aws.amazon.com/config/) e IAM Access Analyzer può essere utile in fase di audit delle autorizzazioni utente. + **Definisci una matrice dei ruoli professionali:** una matrice dei ruoli professionali mostra i diversi ruoli e livelli di accesso richiesti all'interno della tua presenza in AWS. Tramite una matrice dei ruoli professionali puoi definire e separare le autorizzazioni in base alle responsabilità degli utenti all'interno dell'organizzazione. Usa i gruppi invece di applicare le autorizzazioni direttamente ai singoli utenti o ruoli.**  ** ## Risorse **Documenti correlati:** + [Assegnare il privilegio minimo](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html?ref=wellarchitected#grant-least-privilege) + [Limiti delle autorizzazioni per le entità IAM](https://docs.aws.amazon.com//latest/UserGuide/access_policies_boundaries.html) + [Tecniche per la scrittura di policy IAM con privilegio minimo](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/) + [IAM Access Analyzer semplifica l'implementazione delle autorizzazioni con privilegio minimo generando IAM](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/) [policy basate sull'attività di accesso](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/) + [Delegare la gestione delle autorizzazioni agli sviluppatori tramite i limiti delle autorizzazioni IAM](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) + [Perfezionamento delle autorizzazioni in AWS utilizzando le informazioni sull'ultimo accesso](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html) + [Tipi di policy IAM e quando utilizzarle](https://docs.aws.amazon.com//latest/UserGuide/access_policies.html) + [Test delle policy IAM con il simulatore di policy IAM](https://docs.aws.amazon.com//latest/UserGuide/access_policies_testing-policies.html) + [Guardrail in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) + [Architetture Zero Trust: una prospettiva AWS](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/) + [Come implementare il principio del privilegio minimo con CloudFormation StackSets](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/) + [Il controllo dell'accesso basato su attributi (Attribute-Based Access Control, ABAC)](https://docs.aws.amazon.com//latest/UserGuide/introduction_attribute-based-access-control.html?ref=wellarchitected) + [Riduzione dell'ambito di applicazione della policy mediante visualizzazione dell'attività dell'utente](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html?ref=wellarchitected) + [Visualizzazione dell'accesso al ruolo](https://docs.aws.amazon.com//latest/UserGuide/id_roles_manage_delete.html?ref=wellarchitected#roles-delete_prerequisites) + [Utilizza l'applicazione di tag per organizzare il tuo ambiente e per promuovere la responsabilità](https://docs.aws.amazon.com/aws-technical-content/latest/cost-optimization-laying-the-foundation/tagging.html?ref=wellarchitected) + [Strategie di applicazione di tag AWS](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/?ref=wellarchitected) + [Applicazione di tag alle risorse AWS](https://aws.amazon.com/premiumsupport/knowledge-center/quicksight-iam-identity-center/) **Video correlati:** + [Next-generation permissions management (Gestione delle autorizzazioni di ultima generazione)](https://www.youtube.com/watch?v=8vsD_aTtuTo) + [Zero Trust: una prospettiva AWS](https://www.youtube.com/watch?v=1p5G1-4s1r0) + [Come posso utilizzare i limiti delle autorizzazioni per limitare utenti e ruoli e impedire l'escalation dei privilegi?](https://www.youtube.com/watch?v=omwq3r7poek) **Esempi correlati:** + [Laboratorio: limiti delle autorizzazioni IAM per delegare la creazione di ruoli](https://wellarchitectedlabs.com/Security/300__Permission_Boundaries_Delegating_Role_Creation/README.html) + [Laboratorio: controllo degli accessi basato su tag IAM per EC2](https://wellarchitectedlabs.com/Security/300__Tag_Based_Access_Control_for_EC2/README.html?ref=wellarchitected) # 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 provider di identità centralizzato. È necessario progettare processi per diverse modalità di guasto che possono causare un evento di emergenza. Ad esempio, in circostanze normali, gli utenti della tua forza lavoro si federano nel cloud utilizzando un provider di identità centralizzato ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)) per gestire i propri carichi di lavoro. Tuttavia, se il tuo provider di identità centralizzato genera un errore o la configurazione per la federazione nel cloud viene modificata, 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. Il processo di accesso di emergenza viene utilizzato 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. Considera quali guasti possono interessare ognuna di queste dipendenze e causare una situazione di emergenza. Puoi trovare le domande e le best practice nel [Principio di base dell'affidabilità](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-reliability.html) , utile per identificare le modalità di errore e progettare sistemi più resilienti per 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 provider di identità primari e di standby e, se entrambi non sono disponibili, dichiarare un evento di emergenza per guasto del provider di identità. + È 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 descrivono le circostanze in cui ogni processo deve essere o non deve essere utilizzato e indicano processi alternativi che possono essere applicati. + I tuoi processi sono ben documentati con istruzioni e playbook dettagliati che possono essere seguiti 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 provider di identità 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 controllare i 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 avvisare in caso 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 Questa sezione fornisce indicazioni per la creazione di processi di accesso di emergenza per diverse modalità di errore relative ai carichi di lavoro distribuiti su AWS, a partire da linee guida comuni che si applicano 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 i prerequisiti e i 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 provider di identità 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 IAM users 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 preliminarmente le risorse, non si ha alcuna dipendenza dalle API del piano di controllo di AWS [(](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html) utilizzate per creare e modificare risorse AWS), che potrebbero non essere disponibili in caso di emergenza. Inoltre, creando preliminarmente le risorse IAM, non è necessario tenere conto di [potenziali ritardi dovuti alla coerenza finale.](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 in che modo viene tenuta traccia degli eventi di emergenza e come essi 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 ogni 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 dei colleghi o dei manager dell'utente, a seconda dei casi. Il processo di approvazione deve funzionare efficacemente sia all'interno che 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. + Verifica che il processo generi log di controllo ed eventi dettagliati per i tentativi riusciti e falliti di ottenere l'accesso di emergenza. Monitora sia il processo di richiesta sia il meccanismo di accesso di emergenza per rilevare usi impropri o accessi non autorizzati. Metti in correlazione l'attività con gli eventi di emergenza in corso dal tuo sistema di gestione degli incidenti e avvisa quando le azioni si verificano al di fuori dei periodi di tempo previsti. Ad esempio, devi monitorare e inviare avvisi in merito ad attività nell'Account AWS di accesso di emergenza, poiché non dovrebbe mai essere utilizzato per le normali operazioni. + 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 test di ripristino di emergenza ([REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)). **Modalità di errore 1: il provider di identità utilizzato per la federazione dell'accesso ad AWS non è disponibile** Come descritto in [SEC02-BP04 Fai affidamento su un provider di identità centralizzato](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html), ti consigliamo di affidarti a un provider di identità centralizzato per federare gli utenti della tua forza lavoro e garantire loro l'accesso agli Account AWS. È possibile federare l'accesso agli Account AWS a più utenti AWS all'interno dell'organizzazione utilizzando IAM Identity Center, oppure federare l'accesso individuale agli Account AWS utilizzando IAM. In entrambi i casi, gli utenti della forza lavoro si autenticano con il provider di identità centralizzato prima di essere reindirizzati a un endpoint di accesso AWS per l'autenticazione unica. Nell'improbabile eventualità che il provider di identità 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 caso critico, puoi fornire un processo di accesso di emergenza a cui un piccolo gruppo di amministratori può accedere agli Account AWS per eseguire attività urgenti per le quali non è possibile attendere che i tuoi provider di identità centralizzati tornino online. Ad esempio, il tuo provider di identità 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, che viene utilizzato esclusivamente per questo tipo di accessi e dispone di risorse AWS (come ruoli IAM e IAM users) 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 di accesso di emergenza IAM 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: + Creare preliminarmente un set di [IAM users](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. Questi IAM users 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 IAM user è 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ù IAM users con le relative password di lunga durata e i token MFA associati. + È possibile utilizzare l'accesso di emergenza come [utente root dell'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 è che esiste 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 il log eventi della tua vault aziendale per identificare quale amministratore ha utilizzato la password dell'utente root. **Modalità di errore 2: la configurazione del provider di identità su AWS è stata modificata o è scaduta** Per consentire agli utenti della tua forza lavoro di effettuare l'accesso federato agli Account AWS, puoi configurare il IAM Identity Center con un provider di identità esterno o creare un provider di identità IAM ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)). In genere, la configurazione viene effettuata importando un documento XML di metadati SAML fornito dal provider di identità. Il documento XML di metadati include un certificato X.509 corrispondente a una chiave privata utilizzata dal provider di identità 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, costituendo una situazione di emergenza. In un caso di emergenza di questo tipo, puoi fornire agli amministratori di 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 di identità e riattiva la federazione aggiornando la configurazione del provider di identità esterno e importando l'ultimo documento XML di metadati SAML rilasciato dal provider di identità. 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 descritti 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 di identità per accedere solo all'account amministratore di Centro di identità ed eseguire azioni sul Centro di identità in quell'account. **Modalità di errore 3: blocco del Centro di identità** Nell'improbabile eventualità di un blocco di IAM Identity Center o di 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 provider di identità a un ruolo IAM per accedere a un account di emergenza. Per informazioni dettagliate sulle considerazioni relative al processo e alla progettazione, consulta [Configurare l'accesso di emergenza alla 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 users, e, in modo facoltativo, i provider di identità IAM. Inoltre, crea preliminarmente ruoli IAM mutli-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 utilizzare [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 Policy di controllo dei servizi AWS Organizations [(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 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 ha 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 provider di identità utilizzato per la federazione dell'accesso ad AWS non è disponibile; per la Modalità di errore 2: la configurazione del provider di identità su AWS è stata modificata o è scaduta** + Crea preliminarmente le risorse in base al meccanismo scelto per l'accesso di emergenza: + **Utilizza IAM users:** crea preliminarmente IAM users con password complesse e dispositivi MFA associati. + **Usa l'utente root dell'account di emergenza:** configura l'utente root con una password sicura e archivia la password nel tuo archivio 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 di identità** + Come spiegato nei dettagli in [Configurare l'accesso di emergenza alla 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 provider di identità IAM per abilitare la federazione SAML diretta dal tuo provider di identità. + 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 provider di identità 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) + [Abilitazione degli utenti federati SAML 2.0 per accedere a 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 customer playbook framework](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 i permessi non necessari e stabilisci processi di revisione per ottenere i permessi del privilegio minimo. Monitora costantemente e rimuovi le identità e le autorizzazioni inutilizzate per l'accesso sia umano che automatico. **Risultato desiderato:** le policy di autorizzazione devono attenersi al 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 in cui le credenziali vengano inavvertitamente esposte o si acceda 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, le policy di autorizzazione permissiva possono essere utilizzate 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 costantemente 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 degli utenti e dei ruoli 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. [Controllo dell'accesso basato sugli attributi (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) può aiutare a semplificare la gestione delle autorizzazioni, in quanto è possibile fornire autorizzazioni agli utenti utilizzando i loro attributi invece di allegare le policy di autorizzazione direttamente a ciascun utente. **Passaggi dell'implementazione** + **Utilizza [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 nell'organizzazione e negli account, come ad esempio bucket Amazon Simple Storage Service (Amazon S3) o ruoli IAM che sono [condivisi con un'entità esterna](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html). + **Utilizza la [generazione della policy IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html): la** generazione della policy IAM Access Analyzer aiuta a [creare policy di autorizzazione granulari basate su un utente IAM o su un'attività di accesso del ruolo](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html#access-analyzer-policy-generation-howitworks). + **Stabilisci una tempistica accettabile e una policy di utilizzo per gli utenti e i ruoli IAM:** utilizza il [timestamp dell'ultimo accesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html) per [identificare gli utenti e i ruoli inutilizzati](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 [delimitare 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. + **Considera la [registrazione degli eventi di dati in AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html):** per impostazione predefinita, CloudTrail non registra eventi di dati come le attività a livello di oggetto Amazon S3 (ad esempio, `GetObject` e `DeleteObject`) o le attività della tabella Amazon DynamoDB (ad esempio, `PutItem` e `DeleteItem`). Considera la possibilità di abilitare la registrazione di questi eventi per stabilire quali utenti e ruoli devono accedere a specifici oggetti Amazon S3 o elementi di tabelle DynamoDB. ## Risorse **Documenti correlati:** + [Assegnare il privilegio minimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) + [Rimozione di credenziali non necessarie](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) + [ Cosa è AWS CloudTrail? ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) + [Working with Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) (Gestire le policy) + [ Registrazione e monitoraggio in DynamoDB ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/MonitoringDynamoDB.html) + [ Abilitazione della registrazione di eventi CloudTrail per bucket e oggetti Amazon S3 ](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) (Diventa un IAM Policy Master in 60 minuti) + [Separation of Duties, Least Privilege, Delegation, and CI/CD (Separazione dei compiti, privilegio minimo, delega e integrazione e distribuzione continua (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) [AWS re:Inforce 2022 - Approfondimento su AWS Identity and Access Management (IAM)] # SEC03-BP05 Definizione dei guardrail per le autorizzazioni dell'organizzazione Stabilisci controlli comuni che limitano l'accesso a tutte le identità nella tua organizzazione. Ad esempio, puoi limitare l'accesso a Regioni AWS specifiche o impedire agli operatori di eliminare risorse comuni, come ad esempio un ruolo IAM utilizzato per il team di sicurezza centrale. **Anti-pattern comuni:** + Esecuzione di carichi di lavoro nell'account di amministratore dell'organizzazione. + Esecuzione di carichi di lavoro di produzione e non di produzione nello stesso account. **Livello di rischio associato se questa best practice non fosse adottata:** medio ## Guida all'implementazione Man mano che aumenti e gestisci carichi di lavoro aggiuntivi in AWS, devi separarli utilizzando gli account e gestire questi ultimi utilizzando AWS Organizations. Ti consigliamo di stabilire limiti di autorizzazione comuni che limitano l'accesso a tutte le identità nella tua organizzazione. Ad esempio, puoi limitare l'accesso a Regioni AWS specifiche o impedire al tuo team di eliminare risorse comuni, come ad esempio un ruolo IAM utilizzato dal team di sicurezza centrale. Puoi iniziare implementando delle policy di controllo dei servizi di esempio, come una policy che impedisce agli utenti di disabilitare i servizi chiave. Le policy di controllo dei servizi utilizzano il linguaggio di policy IAM e consentono di stabilire i controlli a cui aderiscono tutti i principali IAM (utenti e ruoli). Puoi limitare l'accesso a specifiche azioni del servizio, risorse e in base a condizioni specifiche per soddisfare le esigenze di controllo degli accessi della tua organizzazione. Se necessario, puoi definire eccezioni ai limiti definiti. Ad esempio, puoi limitare le azioni del servizio per tutte le entità IAM nell'account tranne per un ruolo amministratore specifico. Ti consigliamo di evitare di eseguire carichi di lavoro nell'account di gestione. L'account di gestione deve essere utilizzato per governare e distribuire i guardrail di sicurezza che influiscono sugli account membri. Alcuni servizi AWS supportano l'uso di un account amministratore delegato. Se è disponibile, devi utilizzare questo account delegato anziché l'account di gestione. È necessario limitare scrupolosamente l'accesso all'account dell'amministratore dell'organizzazione. L'utilizzo di una strategia multi-account ti consente di avere una maggiore flessibilità nell'applicazione di guardrail ai tuoi carichi di lavoro. L'architettura di riferimento per la sicurezza AWS fornisce le indicazioni prescrittive su come progettare la struttura del tuo account. I servizi AWS come AWS Control Tower forniscono le funzionalità per gestire centralmente i controlli preventivi e investigativi all'interno dell'organizzazione. Definisci uno scopo chiaro per ogni account o unità organizzativa all'interno della tua organizzazione e limita i controlli in linea con tale scopo. ## Risorse **Documenti correlati:** + [AWS Organizations](https://aws.amazon.com/organizations/) + [Policy di controllo dei servizi (Service Control Policies, SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) + [Get more out of service control policies in a multi-account environment (Ottieni di più dalle policy di controllo dei servizi in un ambiente multi-account)](https://aws.amazon.com/blogs/security/get-more-out-of-service-control-policies-in-a-multi-account-environment/) + [AWS Security Reference Architecture (AWS SRA) (Architettura di riferimento per la sicurezza AWS (AWS SRA))](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html) **Video correlati:** + [Enforce Preventive Guardrails using Service Control Policies (Applicazione di guardrail preventivi utilizzando le policy di controllo dei servizi)](https://www.youtube.com/watch?v=mEO05mmbSms) + [Building governance at scale with AWS Control Tower (Creazione di una governance su vasta scala con AWS Control Tower)](https://www.youtube.com/watch?v=Zxrs6YXMidk) + [AWS Identity and Access Management deep dive (Approfondimenti su AWS Identity and Access Management)](https://www.youtube.com/watch?v=YMj33ToS8cI) # SEC03-BP06 Gestione degli accessi in base al ciclo di vita Integra i controlli degli accessi con il ciclo di vita degli operatori e delle applicazioni e con il tuo provider di federazione centralizzata. Ad esempio, rimuovi l'accesso di un utente quando lascia l'organizzazione o cambia ruolo. Quando gestisci i carichi di lavoro utilizzando account separati, in alcuni casi sarà necessario condividere le risorse tra tali account. Ti consigliamo di condividere le risorse utilizzando [AWS Resource Access Manager (AWS RAM)](http://aws.amazon.com/ram/). Questo servizio ti consente di condividere in modo semplice e sicuro le risorse AWS all'interno della tua organizzazione AWS Organizations e delle unità organizzative. Con AWS RAM, l'accesso alle risorse condivise viene automaticamente concesso o revocato quando gli account vengono spostati da e verso l'organizzazione o l'unità organizzativa con cui sono condivisi. In questo modo puoi garantire che le risorse vengano condivise solo con gli account desiderati. **Livello di rischio associato se questa best practice non fosse adottata:** Basso ## Guida all'implementazione Ciclo di vita degli accessi utente: implementa una policy per il ciclo di vita degli accessi utente per i nuovi entranti, le modifiche alle funzioni lavorative e gli uscenti per garantire l'accesso solo agli utenti attuali. ## Risorse **Documenti correlati:** + [Controllo dell'accesso basato su attributi (Attribute-Based Access Control, ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) + [Assegnare il privilegio minimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) + [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) + [Rimozione di 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) **Video correlati:** + [Become an IAM Policy Master in 60 Minutes or Less (Diventa un IAM Policy Master in 60 minuti)](https://youtu.be/YQsK4MtsELU) + [Separation of Duties, Least Privilege, Delegation, and CI/CD (Separazione dei compiti, privilegio minimo, delega e integrazione e distribuzione continua (CI/CD)](https://youtu.be/3H0i7VyTu70) # SEC03-BP07 Analisi dell'accesso pubblico e multi-account Monitora continuamente i risultati che evidenziano l'accesso pubblico e multi-account. Limita l'accesso pubblico e multi-account alle risorse che lo richiedono. **Risultato desiderato:** sapere quali risorse AWS sono condivise e con chi. Monitora e sottoponi costantemente a 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 collegate a risorse, ad esempio [policy di bucket Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) o consentendo a un principale in 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 la [sicurezza comprovabile](https://aws.amazon.com/security/provable-security/) per identificare tutti i percorsi di accesso a una risorsa dall'esterno del suo account. Esamina continuamente le policy delle risorse e segnala i risultati dell'accesso pubblico e multi-account per semplificare l'analisi di accessi potenzialmente estesi. Considera di configurare IAM Access Analyzer con AWS Organizations per assicurarti di avere visibilità su tutti gli account. IAM Access Analyzer consente inoltre di [vedere in anteprima i risultati](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html) prima di implementare le autorizzazioni della risorsa. Questo consente di convalidare che le modifiche alla policy concedono solo l'accesso multi-account e pubblico autorizzati alle risorse. Quando progetti l'accesso multi-account, puoi utilizzare le [policy di attendibilità](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/) per controllare in quali casi un ruolo può essere assunto. Ad esempio, puoi utilizzare la chiave di condizione [`PrincipalOrgId` per respingere il 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 può segnalare le risorse](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-Publicly-Accessible-Resources.html) che non sono configurate correttamente e, attraverso i controlli delle policy AWS Config, può rilevare le risorse con accesso pubblico configurato. Servizi quali [AWS Control Tower](https://aws.amazon.com/controltower/) e [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html) semplificano l'implementazione dei controlli e guardrail investigativi su AWS Organizations per identificare e correggere le risorse esposte pubblicamente. Ad esempio, AWS Control Tower ha un guardrail gestito in grado di rilevare l'eventuale presenza di [snapshot Amazon EBS ripristinabili da Account AWS](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html). **Passaggi dell'implementazione** + **Considera di abilitare [AWS Config per AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html):** AWS Config consente di aggregare i risultati di più account all'interno di un AWS Organizations a un account amministratore delegato. In questo modo si ottiene una visione completa che consente di [implementare Regole di AWS Config su più account per rilevare le risorse accessibili pubblicamente](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html). + **Configura AWS Identity and Access Management Access Analyzer.** IAM Access Analyzer ti aiuta a identificare le risorse nell'organizzazione e negli account, come ad esempio bucket Amazon S3 o ruoli IAMche sono [condivisi con un'entità esterna](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html). + **Utilizza la riparazione automatica in AWS Config per rispondere alle modifiche della configurazione di accesso pubblico dei bucket Amazon S3:** [puoi riattivare automaticamente 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 il monitoraggio e gli 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 quando Amazon S3 Block Public Access è disabilitato e se i bucket Amazon S3 diventano pubblici. Inoltre, se stai utilizzando AWS Organizations, puoi creare una [policy di controllo del servizio](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) che impedisce di modificare le policy Amazon S3 di accesso pubblico. AWS Trusted Advisor controlla i bucket Amazon S3 che hanno 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/) (Come utilizzare AWS Config per monitorare e gestire i bucket Amazon S3 che consentono l'accesso pubblico). Durante la revisione degli accessi, è importante considerare quali tipi di dati sono contenuti nei bucket Amazon S3. [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/findings-types.html) aiuta a scoprire e a proteggere i dati sensibili, come PII, PHI, e le credenziali, come le chiavi private o quelle AWS. ## Risorse **Documenti correlati:** + [Utilizzo di 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) (Libreria di controlli di AWS Control Tower) + [AWS Foundational Security Best Practices standard](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html) (Standard AWS Foundational Security Best Practices) + [AWS Config Managed Rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html) (Regole gestite di AWS Config) + [Riferimento dei controlli AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html) + [ Monitoraggio dei risultati dei controlli AWS Trusted Advisor con 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) (Gestire le regole di configurazione AWS tra tutti gli account dell'organizzazione) + [AWS Config e AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html) **Video correlati:** + [Best Practices for securing your multi-account environment (Best practice per la protezione dell'ambiente multi-account)](https://www.youtube.com/watch?v=ip5sn3z5FNg) + [Dive Deep into IAM Access Analyzer](https://www.youtube.com/watch?v=i5apYXya2m0) (Approfondire l'analisi degli accessi IAM) # 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 ad esempio ambienti di sviluppo, di test e di produzione. Tuttavia, la presenza di costrutti di separazione non limita la possibilità di condividere in modo sicuro. La condivisione di componenti che si sovrappongono 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 indesiderati utilizzando metodi sicuri per condividere le risorse all'interno dell'organizzazione e contribuire all'iniziativa di prevenzione della perdita di 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. I tempi di risoluzione in caso di guasti multipli sono ridotti e la sicurezza nel determinare quando un componente non è più necessario è aumentata. Per una guida prescrittiva sull'analisi delle risorse condivise dall'esterno, consulta [SEC03-BP07 Analisi dell'accesso pubblico e multi-account](sec_permissions_analyze_cross_account.md). **Anti-pattern comuni:** + Mancanza di un processo per il monitoraggio continuo e segnalazione automatica di azioni 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 i controlli e i modelli di accesso per gestire il consumo di risorse condivise in modo sicuro e solo con entità fidate. Monitora le risorse condivise e controllane costantemente l'accesso ricevendo un avviso in caso di condivisione inappropriata o inaspettata. Consulta [Analisi dell'accesso pubblico e multi-account](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html) come supporto per stabilire una governance che riduca l'accesso esterno alle sole risorse che lo richiedono e per definire un processo di monitoraggio continuo e di avviso automatico. La condivisione multi-account in AWS Organizations è supportata da [una serie di 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 i risultati dai singoli account a un account centrale in cui è possibile visualizzare tutti i risultati. AWS Backup può eseguire un backup di una risorsa e condividerlo tra gli account. Puoi utilizzare [AWS Resource Access Manager](https://aws.amazon.com/ram/) (AWS RAM) per condividere altre risorse comuni, quali [sottoreti VPC e allegati Transit Gateway](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 Amazon SageMaker AI](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker). Per limitare l'account alla condivisione di risorse solo all'interno dell'organizzazione, utilizza le [policy di controllo dei servizi](https://docs.aws.amazon.com/ram/latest/userguide/scp.html) (Service Control Policies, SCP) per impedire l'accesso ai principali esterni. Quando condividi le risorse, combina controlli basati sull'identità e controlli 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) in modo da proteggere dall'accesso non intenzionale. 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 che possono essere condivise e impediscono la condivisione o l'esposizione di risorse che non sono consentite. Ad esempio, nell'ambito del perimetro dei dati, è possibile utilizzare le policy degli endpoint VPC e la condizione `AWS:PrincipalOrgId` per assicurarsi che le identità che accedono ai bucket Amazon S3 appartengano alla propria organizzazione. È importante notare che le [policy di controllo dei servizi non si applicano ai ruoli correlati ai servizi (Service-Linked Roles, LSR) o ai principali del servizio AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions). Quando utilizzi Amazon S3, [disabilita le ACL per il bucket Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) e utilizza le policy IAM per definire il controllo degli accessi. Per [delimitare un 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/), migra dall'identità di accesso origine (OAI) al controllo di accesso origine (OAC) che supporta funzionalità aggiuntive, inclusa 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 terzi l'accesso alle risorse stesse. Per una guida prescrittiva sulla gestione delle autorizzazioni per la condivisione di risorse all'esterno, 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 creata e gestita centralmente. È 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 Organizations. 1. **Integrazione delle AWS Organizations con i servizi AWS.** Quando si abilita un servizio AWS a svolgere attività per conto dell'utente negli account membri dell'organizzazione, AWS Organizations crea un ruolo IAM collegato al 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 una guida prescrittiva sull'abilitazione dell'accesso attendibile, consulta [Uso di AWS Organizations con altri servizi AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html) e [Servizi AWS che puoi utilizzare con Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html). 1. **Definizione di un perimetro di dati.** Il perimetro AWS è tipicamente rappresentato come un'organizzazione gestita da AWS Organizations. Insieme alle reti e ai sistemi on-premise, l'accesso alle risorse AWS è ciò che molti considerano il perimetro di My AWS. L'obiettivo del perimetro è verificare che l'accesso sia consentito se l'identità è attendibile, la risorsa è attendibile e la rete è conforme. 1. Definizione e implementazione dei perimetri. Segui i passaggi descritti in [Perimeter implementation](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html) (Implementazione del perimetro) nel whitepaper Building a Perimeter on AWS (Costruire un perimetro su AWS) per qualsiasi condizione di autorizzazione. Per una guida prescrittiva sulla protezione del livello di rete, consulta [Protezione delle reti](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/protecting-networks.html). 1. Monitoraggio e segnalazione continui. [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) aiuta a identificare le risorse dell'organizzazione e gli account condivisi con entità esterne. Puoi integrare [IAM Access Analyzer con AWS Security Hub CSPM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-securityhub-integration.html) per inviare e aggregare i risultati di una risorsa da IAM Access Analyzer a Security Hub CSPM per analizzare la sicurezza dell'ambiente. Per abilitare l'integrazione, abilita sia IAM Access Analyzer che Security Hub CSPM in ogni Regione per ogni account. Puoi anche utilizzare Regole di AWS Config per eseguire l'audit della configurazione e avvisare la parte interessata mediante [Amazon Q Developer in chat applications con AWS Security Hub CSPM](https://aws.amazon.com/blogs/security/enabling-aws-security-hub-integration-with-aws-chatbot/). Puoi quindi utilizzare i [Documenti di AWS Systems Manager](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) per adottare i provvedimenti correttivi alle risorse non conformi. 1. Per una guida prescrittiva sul monitoraggio e sull'avviso continuo delle risorse condivise esternamente, consulta [Analisi dell'accesso pubblico e multi-account](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html). 1. **Utilizza la condivisione delle risorse nei servizi AWS e delimitale di conseguenza.** Molti servizi AWS consentono di condividere le risorse con un altro account o di puntare a una risorsa di un altro account, come [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). Delimita l'API `ModifyImageAttribute` per specificare gli account affidabili con cui condividere l'AMI. Specifica la condizione `ram:RequestedAllowsExternalPrincipals` quando si utilizza AWS RAM per limitare la condivisione solo alla propria organizzazione, per evitare l'accesso da parte di identità non affidabili. Per indicazioni e considerazioni prescrittive [Resource sharing and external targets](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html) (Condivisione delle risorse e target esterni). 1. **Utilizzare AWS RAM per condivisioni sicure con un account o con altri Account AWS.** [AWS RAM](https://aws.amazon.com/ram/) consente di condividere in modo sicuro le risorse create con i ruoli e gli utenti del proprio account e con altri utenti 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 verificabilità grazie alle integrazioni con Amazon CloudWatch e AWS CloudTrail, che non si ottengono quando si utilizza l'accesso multi-account. Se si dispone di risorse condivise in precedenza utilizzando una policy basata sulle risorse, è possibile utilizzare l'API [https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html](https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html) o un'API equivalente per promuovere il passaggio da una condivisione di risorse a una condivisione completa di risorse AWS RAM. In alcuni casi, potrebbe essere necessario adottare ulteriori misure per condividere le risorse. Ad esempio, per condividere un'istantanea crittografata è necessario [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 pubblico e multi-account](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:** + [Il proprietario del bucket concede autorizzazioni multi-account per gli oggetti che non sono di sua proprietà](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/) (Come utilizzare le policy di attendibilità con IAM) + [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) (Creazione del perimetro dei dati in AWS) + [How to use an external ID when granting a third party access to your AWS resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) (Come utilizzare un ID esterno quando si concede a una terza parte l'accesso alle risorse AWS) + [Servizi AWS che puoi utilizzare con 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/)(Applicazione di un perimetro dei dati in AWS: consentire l'accesso ai dati aziendali solo alle identità attendibili) **Video correlati:** + [Granular Access with AWS Resource Access Manager](https://www.youtube.com/watch?v=X3HskbPqR2s) (Accesso granulare con Gestione degli accessi alle risorse AWS) + [Securing your data perimeter with VPC endpoints (Protezione del perimetro dei dati con gli endpoint VPC)](https://www.youtube.com/watch?v=iu0-o6hiPpI) + [ Establishing a data perimeter on AWS](https://www.youtube.com/watch?v=SMi5OBjp1fI)(Applicazione di un perimetro dei dati in AWS) **Strumenti correlati:** + [ Esempi di policy sul perimetro dei 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 terzi la gestione di una parte dei dati. La gestione dei permessi per il sistema gestito da terzi 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 congiuntamente la portata dell'impatto e il rischio di accesso non intenzionale. **Risultato desiderato:** le credenziali AWS Identity and Access Management (IAM) a lungo termine, le chiavi di accesso IAM e le chiavi segrete associate a un utente possono essere utilizzate da chiunque, purché le credenziali siano valide e attive. L'utilizzo di credenziali temporanee e di un ruolo IAM consente di migliorare la sicurezza generale riducendo l'impegno per la manutenzione delle credenziali a lungo termine, compresi i costi di gestione e di funzionamento di questi dati sensibili. Utilizzando un identificatore univoco universale (UUID) per l'ID esterno nella policy di attendibilità IAM e mantenendo sotto il proprio controllo le policy IAM collegate al ruolo IAM, puoi sottoporre a audit e verificare che l'accesso concesso a terzi non sia troppo permissivo. Per una guida prescrittiva sull'analisi delle risorse condivise dall'esterno, consulta [SEC03-BP07 Analisi dell'accesso pubblico e multi-account](sec_permissions_analyze_cross_account.md). **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 terzi 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, devi definire una policy di attendibilità utilizzando la [condizione di 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 gestire ruoli IAM per le applicazioni esterne ad AWS che utilizzano le 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. Ad esempio, AWS Well-Architected Tool consente la [condivisione di 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) ti aiuta a condividere in modo sicuro una risorsa AWS di tua proprietà con altri account. **Passaggi dell'implementazione** 1. **Utilizzare i 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 da terze parti per l'assistenza ai propri clienti. I ruoli multi-account consentono di concedere l'accesso alle risorse AWS del proprio account in modo sicuro a terzi, come i AWS Partner 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 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. **Utilizzare un ID esterno con terze parti.** L'utilizzo di un [ID esterno](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) consente di designare chi può assumere un ruolo in una policy di attendibilità IAM. La policy di attendibilità può richiedere che l'utente che assume il ruolo dichiari la condizione e l'obiettivo in cui sta operando. Inoltre, il proprietario dell'account può consentire l'assunzione del ruolo solo in determinate circostanze. La funzione principale dell'ID esterno è quella di affrontare e prevenire il problema del [confused deputy](https://docs.aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/). Utilizza un ID esterno se sei il proprietario di un Account AWS e hai configurato un ruolo per una terza parte che accede ad altri Account AWS oltre al tuo, oppure quando ti trovi nella posizione di assumere ruoli per conto di diversi clienti. Collabora con la terza parte o con il AWS Partner per stabilire una condizione di ID esterno da includere nelle policy di attendibilità IAM. 1. **Utilizzare ID esterni universalmente univoci.** Implementa un processo che generi un valore univoco casuale per un ID esterno, ad esempio un identificatore univoco universale (UUID). Una terza parte che riutilizza gli ID esterni tra diversi clienti non risolve il problema del confused deputy, perché il cliente A potrebbe essere in grado di visualizzare i dati del cliente B utilizzando l'ARN del ruolo del cliente B insieme all'ID esterno duplicato. In un ambiente multi-tenant, in cui una terza parte supporta più clienti con diversi Account AWS, la terza parte deve utilizzare un ID univoco diverso come ID esterno per ogni Account AWS. La terza parte è responsabile del rilevamento di ID esterni duplicati e della mappatura sicura di ciascun cliente al rispettivo ID esterno. La terza parte deve verificare di poter assumere il ruolo solo quando specifica l'ID esterno. La terza parte deve astenersi dal memorizzare l'ARN del ruolo del cliente e l'ID esterno fino a quando non è richiesto l'ID esterno. 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 di 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'unicità e i formati in modo coerente tra i clienti. 1. **Rendere 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 dettagli sulla gestione delle chiavi, consulta [Identity Management](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html) (Gestione dell'identità). Collaborare inoltre con il team dell'Account AWS e con la terza parte per stabilire un runbook di mitigazione dei rischi. Per una guida prescrittiva sulla risposta e la mitigazione dell'impatto potenziale di un incidente di sicurezza, consulta [Incident response](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html) (Risposta agli incidenti). 1. **Verifica che l'impostazione abbia una guida prescrittiva o sia automatizzata.** La policy creata per l'accesso multi-account deve seguire il [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 una traccia verificabile. Per ulteriori informazioni sull'utilizzo di un modello CloudFormation per creare ruoli trasversali agli account, consulta [Cross-Account Roles](https://aws.amazon.com/blogs/apn/tag/cross-account-roles/) (Ruoli multi-account). 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 CloudFormation o equivalente, è necessario monitorare le modifiche con il rilevamento delle derive come parte della pratica di audit. 1. **Account per le 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 i cambiamenti e i fallimenti e 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 a audit l'uso del ruolo e del datastore degli ID esterni. Devi essere pronto a revocare l'accesso a terzi, 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 una guida prescrittiva sui metodi di rilevamento, consulta [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](sec_identities_unique.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 pubblico e multi-account](sec_permissions_analyze_cross_account.md) + [ SEC04 Rilevamento ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html) **Documenti correlati:** + [Il proprietario del bucket concede autorizzazioni multi-account per gli oggetti che non sono di sua proprietà](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/) (Come utilizzare le policy di attendibilità con i ruoli IAM) + [ Delega dell'accesso tra Account AWS tramite i ruoli IAM](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/) (Come faccio ad accedere alle risorse di un altro account AWS utilizzando IAM?) + [ Best practice per la sicurezza in IAM ](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) + [ Logica di valutazione della policy multiaccount ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html) + [ Come utilizzare un ID esterno quando si concede a una terza parte l'accesso alle proprie risorse AWS](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/)(Raccolta di informazioni dalle risorse AWS CloudFormation create in account esterni con risorse personalizzate) + [ 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/)(Utilizzo sicuro dell'ID esterno per l'accesso agli account AWS di proprietà di altri) + [ 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/)(Estendere i ruoli IAM a carichi di lavoro esterni a IAM con 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)(Come posso consentire agli utenti o ai ruoli di un account AWS separato di accedere al mio account AWS?) + [AWS re:Invent 2018: Become an IAM Policy Master in 60 Minutes or Less ](https://www.youtube.com/watch?v=YQsK4MtsELU)(Diventa un IAM Policy Master in 60 minuti) + [AWS Knowledge Center Live: IAM Best Practices and Design Decisions ](https://www.youtube.com/watch?v=xzDFPIQy4Ks) (Knowledge Center AWS in diretta: best practice e decisioni di progettazione IAM) **Esempi correlati:** + [ Well-Architected Lab - Lambda cross account IAM role assumption (Level 300) ](https://www.wellarchitectedlabs.com/security/300_labs/300_lambda_cross_account_iam_role_assumption/)[Well-Architected Lab: Assunzione di ruoli IAM per account incrociati Lambda (livello 300)] + [ Configure cross-account access to Amazon DynamoDB ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html)(Configurare l'accesso multi-account ad Amazon DynamoDB) + [AWS STS Network Query Tool ](https://github.com/aws-samples/aws-sts-network-query-tool) (Strumento di consultazione della rete AWS STS)