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