# Nozioni di base sulla sicurezza
**Topics**
+ [SEC 1. Come gestire un carico di lavoro in sicurezza?](sec-01.md)
# SEC 1. Come gestire un carico di lavoro in sicurezza?
Per gestire il carico di lavoro in modo sicuro, è necessario applicare le best practice globali a ogni area di sicurezza. Segui i requisiti e i processi definiti in termini di eccellenza operativa a livello organizzativo e di carico di lavoro e applicali a tutte le aree. Rimanere aggiornati con le raccomandazioni di AWS e del settore nonché con l'intelligence sulle minacce aiuta a sviluppare il modello di rischio e gli obiettivi di controllo. L'automazione dei processi di sicurezza, i test e la convalida permettono di dimensionare le operazioni di sicurezza.
**Topics**
+ [SEC01-BP01 Separazione dei carichi di lavoro tramite account](sec_securely_operate_multi_accounts.md)
+ [SEC01-BP02 Utente root e proprietà dell'account sicuro](sec_securely_operate_aws_account.md)
+ [SEC01-BP03 Identificazione e convalida degli obiettivi di controllo](sec_securely_operate_control_objectives.md)
+ [SEC01-BP04 Aggiornamento costante sulle minacce alla sicurezza](sec_securely_operate_updated_threats.md)
+ [SEC01-BP05 Aggiornamento costante sulle raccomandazioni di sicurezza](sec_securely_operate_updated_recommendations.md)
+ [SEC01-BP06 Automatizzazione dei test e della convalida dei controlli di sicurezza nelle pipeline](sec_securely_operate_test_validate_pipeline.md)
+ [SEC01-BP07 Identificare le minacce e dare priorità alle mitigazioni utilizzando un modello di minaccia.](sec_securely_operate_threat_model.md)
+ [SEC01-BP08 Valutazione e implementazione periodiche di nuovi servizi e funzionalità di sicurezza](sec_securely_operate_implement_services_features.md)
# SEC01-BP01 Separazione dei carichi di lavoro tramite account
Definisci guardrail e isolamento comuni tra ambienti (ad esempio quelli di produzione, sviluppo e test) e carichi di lavoro attraverso una strategia multi-account. La separazione a livello di account è fortemente consigliata, in quanto fornisce un solido margine di isolamento per la sicurezza, la fatturazione e l'accesso.
**Risultato desiderato:** una struttura di account che isola le operazioni cloud, i carichi di lavoro non correlati e gli ambienti in account separati, aumentando la sicurezza dell'infrastruttura cloud.
**Anti-pattern comuni:**
+ Inserimento di più carichi di lavoro non correlati con diversi livelli di sensibilità dei dati nello stesso account.
+ Struttura dell'unità organizzativa (UO) scarsamente definita.
**Vantaggi dell'adozione di questa best practice:**
+ Riduzione dell'impatto in caso di accesso involontario a un carico di lavoro.
+ Governance centralizzata dell'accesso a risorse, regioni e servizi AWS.
+ Garanzia di sicurezza dell'infrastruttura cloud con policy e amministrazione centralizzata dei servizi di sicurezza.
+ Processo automatizzato di creazione e mantenimento dell'account.
+ Audit centralizzato della tua infrastruttura per la conformità e i requisiti normativi.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
Gli Account AWS offrono un confine di isolamento della sicurezza tra carichi di lavoro o risorse che operano a livelli di sensibilità diversi. AWS fornisce strumenti per gestire i carichi di lavoro del cloud su larga scala attraverso una strategia multi-account per sfruttare questo margine di isolamento. Per avere una guida su concetti, modelli e implementazione di una strategia multi-account su AWS, consulta [Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) (Organizzazione dell'ambiente AWS con l'utilizzo di account multipli).
Se si dispone di più Account AWS, gli account devono essere organizzati in una gerarchia definita da livelli di unità organizzative (UO). I controlli di sicurezza possono quindi essere organizzati e applicati alle unità organizzative e agli account membri, stabilendo controlli preventivi coerenti sugli account membri dell'organizzazione. I controlli di sicurezza sono ereditati e consentono di filtrare le autorizzazioni disponibili per gli account membro situati ai livelli inferiori di una gerarchia di unità organizzative. Un buon progetto sfrutta questa ereditarietà per ridurre il numero e la complessità delle policy di sicurezza necessarie per ottenere i controlli desiderati per ogni account membro.
[AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) e [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) sono due servizi che possono essere utilizzati per implementare e gestire questa struttura multi-account nel proprio ambiente AWS. AWS Organizations consente di organizzare gli account in una gerarchia definita da uno o più livelli di unità organizzative, ognuna delle quali contiene una serie di account membri. Le [policy di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) consentono all'amministratore dell'organizzazione di stabilire controlli preventivi granulari sugli account dei membri, mentre [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html) può essere utilizzato per stabilire controlli proattivi e investigativi sugli account dei membri. Molti servizi AWS [si integrano con AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html) per fornire controlli amministrativi delegati e per eseguire attività specifiche del servizio su tutti gli account dei membri dell'organizzazione.
Posizionato sopra AWS Organizations, [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) fornisce un'impostazione delle best practice in un solo clic per un ambiente AWS multi-account con una [zona di destinazione](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html). La zona di destinazione è il punto di ingresso nell'ambiente multi-account stabilito da Control Tower. Control Tower offre diversi [vantaggi](https://aws.amazon.com/blogs/architecture/fast-and-secure-account-governance-with-customizations-for-aws-control-tower/) rispetto a AWS Organizations. Tre sono i vantaggi che consentono di migliorare la governance degli account:
+ Guardrail di sicurezza obbligatori integrati che vengono applicati automaticamente agli account ammessi nell'organizzazione.
+ Guardrail opzionali che possono essere attivati o disattivati per un determinato insieme di unità organizzative.
+ [AWS Control Tower Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html) fornisce l'implementazione automatica di account contenenti linee di base e opzioni di configurazione pre-approvate all'interno dell'organizzazione.
## Passaggi dell'implementazione
1. **Progettazione di una struttura organizzativa unitaria:** una struttura di unità organizzative opportunamente studiata riduce l'onere di gestione necessario per creare e mantenere le policy di controllo dei servizi e gli altri controlli di sicurezza. La struttura delle unità organizzative deve essere [allineata alle esigenze aziendali, alla sensibilità dei dati e alla struttura del carico di lavoro.](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/).
1. **Creazione di una zona di destinazione per l'ambiente multi-account:** una zona di destinazione fornisce una base di sicurezza e infrastruttura coerente da cui l'organizzazione può sviluppare, lanciare e implementare rapidamente i carichi di lavoro. Puoi utilizzare una [zona di destinazione personalizzata o AWS Control Tower](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/building-landing-zones.html) per orchestrare il tuo ambiente.
1. **Realizzazione di guardrail:** implementa guardrail di sicurezza coerenti per il tuo ambiente attraverso la zona di destinazione. AWS Control Tower offre un elenco di controlli implementabili [obbligatori](https://docs.aws.amazon.com/controltower/latest/userguide/mandatory-controls.html) e [facoltativi](https://docs.aws.amazon.com/controltower/latest/userguide/optional-controls.html). I controlli obbligatori vengono implementati automaticamente quando si utilizza Control Tower. Esamina l'elenco dei controlli altamente consigliati e facoltativi e adotta quelli più adatti alle tue esigenze.
1. **Accesso limitato a Regioni aggiunte di recente:** per le nuove Regioni AWS, le risorse IAM, ad esempio utenti e ruoli, verranno propagate solo alle Regioni specificate. Questa azione può essere eseguita tramite la [console quando si utilizza Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html) oppure regolando le [policy di autorizzazione IAM in AWS Organizations](https://aws.amazon.com/blogs/security/setting-permissions-to-enable-accounts-for-upcoming-aws-regions/).
1. **Presa in esame di AWS [CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)**: StackSets consente di implementare risorse, tra cui policy, ruoli e gruppi IAM in Account AWS e Regioni differenti a partire da un modello approvato.
## Risorse
**Best practice correlate:**
+ [SEC02-BP04 Fai affidamento su un provider di identità centralizzato](sec_identities_identity_provider.md)
**Documenti correlati:**
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [Linee guida sugli audit di sicurezza AWS](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html)
+ [IAM Best Practices](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html)(Best Practice IAM)
+ [Use CloudFormation StackSets to provision resources across multiple Account AWS and regions](https://aws.amazon.com/blogs/aws/use-cloudformation-stacksets-to-provision-resources-across-multiple-aws-accounts-and-regions/) (Utilizzo di StackSet CloudFormation per il provisioning delle risorse su più account e regioni AWS)
+ [Organizations FAQ](https://aws.amazon.com/organizations/faqs/) (Domande frequenti sulle organizzazioni)
+ [AWS Organizations Concetti e terminologia](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)
+ [Best Practices for Service Control Policies in an AWS Organizations Multi-Account Environment (Best practice per le policy di controllo dei servizi di AWS Organizations in un ambiente multi-account)](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [Guida di riferimento per la gestione degli account AWS](https://docs.aws.amazon.com/accounts/latest/reference/accounts-welcome.html)
+ [Organizzazione dell'ambiente AWS con l'utilizzo di account multipli](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
**Video correlati:**
+ [Enable AWS adoption at scale with automation and governance](https://youtu.be/GUMSgdB-l6s) (Consentire l'adozione di AWS su larga scala con l'automazione e la governance)
+ [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM)
+ [Building and Governing Multiple Accounts using AWS Control Tower](https://www.youtube.com/watch?v=agpyuvRv5oo) (Creazione e gestione di account multipli con AWS Control Tower)
+ [Enable Control Tower for Existing Organizations](https://www.youtube.com/watch?v=CwRy0t8nfgM) (Abilitare la Control Tower per le organizzazioni esistenti)
**Workshop correlati:**
+ [Control Tower Immersion Day](https://controltower.aws-management.tools/immersionday/) (Giornata di approfondimento su Control Tower)
# SEC01-BP02 Utente root e proprietà dell'account sicuro
L'utente root è la figura più privilegiata di un Account AWS, ha pieno accesso amministrativo a tutte le risorse dell'account e, in alcuni casi, non può essere limitato dalle policy di sicurezza. Disabilitare l'accesso programmatico all'utente root, stabilire controlli appropriati per l'utente root ed evitare l'uso di routine dell'utente root aiuta a ridurre il rischio di esposizione involontaria delle credenziali root e la conseguente compromissione dell'ambiente cloud.
**Risultato desiderato: **la sicurezza dell'utente root contribuisce a ridurre la possibilità che si verifichino danni accidentali o intenzionali a causa dell'uso improprio delle credenziali dell'utente root. La creazione di controlli investigativi può anche permettere di avvisare il personale appropriato quando vengono eseguite azioni utilizzando l'utente root.
**Anti-pattern comuni:**
+ Utilizzo dell'utente root per attività diverse da quelle che richiedono le proprie credenziali.
+ Nessun test dei piani di emergenza su base regolare per verificare il funzionamento delle infrastrutture critiche, dei processi e del personale durante un'emergenza.
+ Analisi limitata al tipico flusso di accesso all'account, trascurando di considerare o testare metodi alternativi di ripristino dell'account.
+ Nessuna gestione di DNS, server di posta elettronica e provider telefonici come parte del perimetro di sicurezza critico, in quanto utilizzati nel flusso di recupero degli account.
**Vantaggi derivanti dall'adozione di questa best practice:** proteggere l'accesso all'utente root crea la certezza che le azioni del proprio account siano controllate e sottoposte a audit.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
AWS offre molti strumenti per proteggere gli account. Tuttavia, poiché alcune di queste misure non sono abilitate per impostazione predefinita, è necessario intervenire direttamente per implementarle. Queste raccomandazioni sono i passi fondamentali per mettere in sicurezza il proprio Account AWS. Durante l'implementazione di questi passaggi, è importante creare un processo di valutazione e monitoraggio continuo dei controlli di sicurezza.
Quando si crea un Account AWS per la prima volta, si inizia con una singola identità che ha accesso completo a tutti i servizi e risorse AWS presenti nell'account. Questa identità è chiamata utente root dell'Account AWS. È possibile accedere come utente root mediante l'indirizzo e-mail e la password usati per creare l'account. A causa dei livelli elevati di accesso concessi all'utente root AWS, è necessario limitare l'uso dell'utente root AWS all'esecuzione di attività che [lo richiedono specificamente](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html). Le credenziali di accesso dell'utente root devono essere tenute sotto stretta sorveglianza e l'autenticazione a più fattori (MFA) deve essere sempre abilitata per l'utente root dell'Account AWS.
Oltre al normale flusso di autenticazione per accedere all'utente root utilizzando un nome utente, una password e un dispositivo di autenticazione a più fattori (MFA), esistono flussi di recupero dell'account che consentono di accedere all'utente root dell'Account AWS grazie all'accesso all'indirizzo e-mail e al numero di telefono associati all'account. Pertanto, è altrettanto importante proteggere l'account e-mail dell'utente root a cui vengono inviati l'e-mail di recupero e il numero di telefono associato all'account. Considerare anche le potenziali dipendenze circolari, quando l'indirizzo e-mail associato all'utente root è ospitato su server di posta elettronica o su risorse del servizio dei nomi di dominio (DNS) dello stesso Account AWS.
Quando si utilizza AWS Organizations, esistono più Account AWS, ognuno dei quali ha un utente root. Un account è designato come account di gestione e sotto l'account di gestione possono essere aggiunti diversi livelli di account membri. La priorità è proteggere l'utente root dell'account di gestione, quindi occuparsi degli utenti root degli account membri. La strategia per la protezione dell'utente root dell'account di gestione può essere diversa da quella degli utenti root degli account membri ed è possibile effettuare controlli di sicurezza preventivi sugli utenti root degli account membri.
### Passaggi dell'implementazione
Per stabilire i controlli per l'utente root si consigliano le seguenti fasi di implementazione. Eventuali raccomandazioni sono collegate a [CIS AWS Foundations benchmark versione 1.4.0](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-cis-controls-1.4.0.html). Oltre a questi passaggi, consulta le [AWS best practice guidelines](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) (Linee guida sulle best practice AWS) per la protezione delle risorse e degli Account AWS.
**Controlli preventivi**
1. Imposta [informazioni di contatto](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-primary.html) accurate per l'account.
1. Queste informazioni vengono utilizzate per il flusso di recupero della password persa, per il flusso di recupero dell'account del dispositivo MFA perso e per le comunicazioni critiche relative alla sicurezza con il team.
1. Utilizza un indirizzo e-mail ospitato dal dominio aziendale, preferibilmente una lista di distribuzione, come indirizzo e-mail dell'utente root. L'utilizzo di una lista di distribuzione piuttosto che dell'account di e-mail di un singolo individuo offre una maggiore ridondanza e continuità di accesso all'account root per lunghi periodi di tempo.
1. Il numero di telefono indicato nelle informazioni di contatto deve essere dedicato e sicuro per questo scopo. Il numero di telefono non deve essere indicato o condiviso con nessuno.
1. Non creare chiavi di accesso per l'utente root. Se sono presenti chiavi di accesso, rimuovile (CIS 1.4).
1. Elimina le credenziali programmatiche a lunga durata (chiavi di accesso e segrete) per l'utente root.
1. Se esistono già chiavi di accesso per l'utente root, è necessario passare i processi che utilizzano tali chiavi all'uso di chiavi di accesso temporanee di un ruolo AWS Identity and Access Management (IAM), quindi [eliminare le chiavi di accesso per l'utente root](https://docs.aws.amazon.com/accounts/latest/reference/root-user-access-key.html#root-user-delete-access-key).
1. Stabilisci se è necessario memorizzare le credenziali per l'utente root.
1. Se utilizzi AWS Organizations per creare nuovi account membro, la password iniziale dell'utente root sui nuovi account membro è impostata su un valore casuale che non è visibile a te. Considera l'utilizzo del flusso di ripristino della password dal tuo account di gestione di AWS Organization per [ottenere l'accesso all'account membro](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_access-as-root), se necessario.
1. Per gli Account AWS standalone o per l'account di gestione di AWS Organization, considera la creazione e l'archiviazione sicura delle credenziali per l'utente root. Abilita la MFA per l'utente root.
1. Abilita i controlli preventivi per gli utenti root degli account membri in ambienti multi-account AWS.
1. Considera di attivare il guardrail preventivo [Disallow Creation of Root Access Keys for the Root User](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html#disallow-root-access-keys) (Disabilitare la creazione di chiavi di accesso root per l'utente root) per gli account dei membri.
1. Considera di attivare il guardrail preventivo [Disallow Actions as a Root User](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html#disallow-root-auser-actions) (Disabilitare le azioni come utente root) per gli account dei membri.
1. Se sono necessarie le credenziali per l'utente root:
1. Utilizza una password complessa.
1. Abilita l'autenticazione a più fattori (MFA) per l'utente root, in particolare per gli account dei manager (paganti) AWS Organizations (CIS 1.5).
1. Considera i dispositivi MFA hardware per la resilienza e la sicurezza, in quanto i dispositivi monouso possono ridurre le possibilità che i dispositivi contenenti i codici MFA vengano riutilizzati per altri scopi. Verifica che i dispositivi hardware MFA alimentati da una batteria siano sostituiti regolarmente. (CIS 1.6)
+ Per configurare l'MFA per l'utente root, segui le istruzioni per abilitare un [dispositivo MFA](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_mfa_enable_virtual.html#enable-virt-mfa-for-root) o [virtuale o hardware](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_mfa_enable_physical.html#enable-hw-mfa-for-root).
1. Considera la possibilità di iscrivere più dispositivi MFA per il backup. [Sono consentiti fino a 8 dispositivi MFA per account](https://aws.amazon.com/blogs/security/you-can-now-assign-multiple-mfa-devices-in-iam/).
+ Tieni presente che l'iscrizione di più di un dispositivo MFA per l'utente root disabilita automaticamente il [flusso per il recupero dell'account in caso di perdita del dispositivo MFA.](https://aws.amazon.com/premiumsupport/knowledge-center/reset-root-user-mfa/).
1. Conserva la password in modo sicuro e considera le dipendenze circolari se la password viene conservata elettronicamente. Non memorizzare la password in modo tale da richiedere l'accesso allo stesso Account AWS per ottenerla.
1. Facoltativo: valuta la possibilità di stabilire un programma di rotazione periodica delle password per l'utente root.
+ Le best practice per la gestione delle credenziali dipendono dai requisiti normativi e di policy. Gli utenti root protetti da MFA non dipendono dalla password come unico fattore di autenticazione.
+ [La modifica della password dell'utente root](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_passwords_change-root.html) su base periodica riduce il rischio che una password esposta inavvertitamente possa essere utilizzata in modo improprio.
### Controlli di rilevamento
+ Crea allarmi per rilevare l'uso delle credenziali root (CIS 1.7). [L'abilitazione di Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html) monitorerà e segnalerà l'uso delle credenziali API dell'utente root attraverso il rilevamento [RootCredentialUsage](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#policy-iam-rootcredentialusage).
+ Valuta e implementa i controlli investigativi inclusi in [AWS Well-Architected Security Pillar conformance pack for AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-wa-Security-Pillar.html) (Pacchetto di conformità del pilastro di sicurezza well-architected di AWS per AWS Config) oppure, se si utilizza AWS Control Tower, i [controlli fortemente consigliati](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html) disponibili in Control Tower.
### Guida operativa
+ Stabilisci chi nell'organizzazione deve avere accesso alle credenziali dell'utente root.
+ Utilizza una regola a due persone, in modo che nessun individuo abbia accesso a tutte le credenziali necessarie e all'MFA per ottenere l'accesso come utente root.
+ Verifica che l'organizzazione, e non un singolo individuo, mantenga il controllo sul numero di telefono e sull'alias e-mail associati all'account (utilizzati per il ripristino della password e il flusso di ripristino MFA).
+ Utilizza l'utente root solo in via eccezionale (CIS 1.7).
+ L'utente root dell’account AWS non deve essere utilizzato per le attività giornaliere e nemmeno per quelle amministrative. Effettua il login come utente root solo per eseguire [attività AWS che lo richiedono](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html). Tutte le altre azioni devono essere eseguite da altri utenti che assumono i ruoli appropriati.
+ Verifica periodicamente che l'accesso all'utente root sia funzionante, in modo da testare le procedure prima di una situazione di emergenza che richieda l'uso delle credenziali dell'utente root.
+ Verifica periodicamente che l'indirizzo e-mail associato all'account e quelli elencati in [Alternate Contacts](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-alternate.html) (Contatti alternativi) funzionino. Monitora queste caselle di posta elettronica per le notifiche di sicurezza che potresti ricevere da abuse@amazon.com. Assicurati inoltre che i numeri di telefono associati all'account siano attivi.
+ Prepara procedure di risposta agli incidenti per rispondere all'uso improprio dell'account root. Consulta la [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html) (Guida alla risposta agli incidenti di sicurezza AWS) e alle best practice riportate nella [sezione Incident Response (Risposta agli incidenti) del whitepaper Security Pillar (Pilastro di sicurezza)](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html) per ulteriori informazioni sulla creazione di una strategia di risposta agli incidenti del tuo Account AWS.
## Risorse
**Best practice correlate:**
+ [SEC01-BP01 Separazione dei carichi di lavoro tramite account](sec_securely_operate_multi_accounts.md)
+ [SEC02-BP01 Utilizzo meccanismi di accesso efficaci](sec_identities_enforce_mechanisms.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)
+ [SEC10-BP05 Preassegnazione dell'accesso](sec_incident_response_pre_provision_access.md)
**Documenti correlati:**
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [Linee guida sugli audit di sicurezza AWS](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html)
+ [IAM Best Practices](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html)(Best Practice IAM)
+ [Amazon GuardDuty – root credential usage alert](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#policy-iam-rootcredentialusage) (Amazon GuardDuty – Avviso sull'utilizzo delle credenziali root)
+ [Step-by-step guidance on monitoring for root credential use through CloudTrail](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-cis-controls-1.4.0.html#securityhub-cis1.4-controls-1.7) (Guida passo-passo sul monitoraggio dell'uso delle credenziali root tramite CloudTrail)
+ [Token MFA approvati per l'uso con AWS](https://aws.amazon.com/iam/features/mfa/)
+ Implementazione di funzionalità di [break glass access](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html) (accesso di emergenza) su AWS
+ [Top 10 security items to improve in your Account AWS](https://aws.amazon.com/blogs/security/top-10-security-items-to-improve-in-your-aws-account/) (I 10 principali elementi di sicurezza da migliorare nel proprio account AWS)
+ [Che cosa devo fare se noto un'attività non autorizzata nel mio Account AWS?](https://aws.amazon.com/premiumsupport/knowledge-center/potential-account-compromise/)
**Video correlati:**
+ [Enable AWS adoption at scale with automation and governance](https://youtu.be/GUMSgdB-l6s) (Consentire l'adozione di AWS su larga scala con l'automazione e la governance)
+ [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM)
+ [Limiting use of AWS root credentials](https://youtu.be/SMjvtxXOXdU?t=979) (Restrizioni nell'uso delle credenziali AWS) da AWS re:inforce 2022 – Security best practices with AWS IAM (Best practice di sicurezza con AWS IAM)
**Esempi e laboratori correlati:**
+ [Laboratorio: Account AWS e utente root](https://www.wellarchitectedlabs.com/security/100_labs/100_aws_account_and_root_user/)
# SEC01-BP03 Identificazione e convalida degli obiettivi di controllo
In base ai requisiti di conformità e ai rischi identificati dal modello di rischio, deriva e convalida gli obiettivi di controllo e i controlli da applicare al carico di lavoro. La convalida continua degli obiettivi di controllo e dei controlli aiuta a misurare l'efficacia della mitigazione dei rischi.
**Livello di rischio associato se questa best practice non fosse adottata:** Alto
## Guida all'implementazione
+ Identifica i requisiti di conformità. Scopri i requisiti organizzativi, legali e di conformità perché il tuo carico di lavoro risulti conforme.
+ Identifica le risorse di conformità AWS: identifica le risorse che AWS mette a disposizione per aiutarti nei processi di conformità.
+ [https://aws.amazon.com/compliance/ ](https://aws.amazon.com/compliance/)
+ [ https://aws.amazon.com/artifact/](https://aws.amazon.com/artifact/)
## Risorse
**Documenti correlati:**
+ [AWS Security Audit Guidelines](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html)
+ [ Bollettini sulla sicurezza](https://aws.amazon.com/security/security-bulletins/)
**Video correlati:**
+ [AWS Security Hub CSPM: gestire gli avvisi di sicurezza e automatizzare la conformità](https://youtu.be/HsWtPG_rTak)
+ [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM)
# SEC01-BP04 Aggiornamento costante sulle minacce alla sicurezza
Per definire e implementare controlli appropriati, riconosci i vettori di attacco rimanendo aggiornato sulle minacce alla sicurezza più recenti. Usa AWS Managed Services per semplificare la ricezione di notifiche in seguito a comportamenti inaspettati o inusuali nei tuoi account AWS. Esegui delle indagini avvalendoti degli strumenti AWS Partner o di feed di informazioni sulle minacce di terze parti come parte del tuo flusso di informazioni di sicurezza. Al [CVE (Common Vulnerabilities and Exposures) ](https://cve.mitre.org/) contiene vulnerabilità di sicurezza informatica pubbliche che puoi utilizzare come aggiornamento.
**Livello di rischio associato se questa best practice non fosse adottata:** Alto
## Guida all'implementazione
+ Iscrizione alle fonti di informazione sulle minacce: consulta regolarmente le informazioni sulle minacce da varie fonti attinenti alle tecnologie che utilizzi per il tuo carico di lavoro.
+ [Elenco CVE (Common Vulnerabilities and Exposures) ](https://cve.mitre.org/)
+ Considera il servizio [AWS Shield Advanced](https://aws.amazon.com/shield/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc) : fornisce visibilità quasi in tempo reale sulle fonti di intelligence, se il tuo carico di lavoro è accessibile da Internet.
## Risorse
**Documenti correlati:**
+ [AWS Security Audit Guidelines](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html)
+ [AWS Shield](https://aws.amazon.com/shield/)
+ [ Bollettini sulla sicurezza](https://aws.amazon.com/security/security-bulletins/)
**Video correlati:**
+ [Security Best Practices the Well-Architected Way ](https://youtu.be/u6BCVkXkPnM)
# SEC01-BP05 Aggiornamento costante sulle raccomandazioni di sicurezza
Tieniti aggiornato sulle raccomandazioni di sicurezza di AWS e del settore, così da revisionare l'assetto di sicurezza del tuo carico di lavoro. [Bollettini sulla sicurezza AWS](https://aws.amazon.com/security/security-bulletins/?card-body.sort-by=item.additionalFields.bulletinDateSort&card-body.sort-order=desc&awsf.bulletins-year=year%232009) contengono informazioni importanti sulla sicurezza e notifiche relative alla privacy.
**Livello di rischio associato se questa best practice non fosse adottata:** Alto
## Guida all'implementazione
+ Segui gli aggiornamenti di AWS: segui o verifica regolarmente la presenza di nuovi consigli, suggerimenti e trucchi.
+ [AWS Well-Architected Labs](https://wellarchitectedlabs.com/?ref=wellarchitected)
+ [Blog sulla sicurezza AWS](https://aws.amazon.com/blogs/security/?ref=wellarchitected)
+ [Documentazione del servizio AWS](https://aws.amazon.com/documentation/?ref=wellarchitected)
+ Sottoscrivi gli aggiornamenti di settore: consulta regolarmente le notizie da varie fonti attinenti alle tecnologie impiegate nel tuo carico di lavoro.
+ [Esempio: Elenco CVE (Common Vulnerabilities and Exposures)](https://cve.mitre.org/cve/?ref=wellarchitected)
## Risorse
**Documenti correlati:**
+ [Bollettini sulla sicurezza](https://aws.amazon.com/security/security-bulletins/)
**Video correlati:**
+ [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM)
# SEC01-BP06 Automatizzazione dei test e della convalida dei controlli di sicurezza nelle pipeline
Stabilisci previsioni e modelli sicuri per i meccanismi di sicurezza testati e convalidati come parte della compilazione, delle pipeline e dei processi. Utilizza strumenti e l'automazione per testare e convalidare tutti i controlli di sicurezza in modo continuo. Ad esempio, scansiona elementi quali immagini di macchine e modelli di infrastrutture come codice per individuare vulnerabilità di sicurezza, irregolarità e deviazioni da una previsione stabilita in ogni fase. AWS CloudFormation Guard può aiutarti a verificare la sicurezza dei modelli CloudFormation, a risparmiare tempo e a ridurre il rischio che si verifichino errori di configurazione.
È fondamentale ridurre il numero di errori di sicurezza introdotti in un ambiente di produzione, quindi più operazioni di controllo di qualità e riduzione dei difetti è possibile eseguire nel processo di compilazione, più efficace sarà il risultato. Progetta pipeline di integrazione e distribuzione continue (CI/CD) per testare eventuali problemi di sicurezza quando possibile. Le pipeline CI/CD offrono l'opportunità di migliorare la sicurezza in ogni fase della compilazione e della distribuzione. Anche gli strumenti di sicurezza CI/CD devono essere mantenuti aggiornati per mitigare le minacce in continua evoluzione.
Monitora le modifiche alla configurazione del tuo carico di lavoro per facilitare gli audit di conformità, la gestione delle modifiche e le indagini che possono essere applicate al tuo caso. Puoi usare AWS Config per registrare e valutare le tue risorse AWS e di terze parti. Consente di eseguire audit costanti e di valutare la conformità generale a regole e pacchetti di conformità, ossia raccolte di regole con azioni di correzione.
Nel monitoraggio delle modifiche sono incluse modifiche pianificate, parte del processo di controllo delle modifiche della tua organizzazione (a cui a volte si fa riferimento con l'acronimo MACD: Move, Add, Change, Delete), le modifiche non pianificate e le modifiche inaspettate, come gli incidenti. Le modifiche possono avvenire a livello di infrastruttura, ma essere relative anche ad altre categorie, come le modifiche nei repository di codice, le modifiche delle immagini di macchine e degli inventari di applicazioni, le modifiche di processi e policy o le modifiche alla documentazione.
**Livello di rischio associato se questa best practice non fosse adottata:** Medio
## Guida all'implementazione
+ Automazione della gestione della configurazione: applica e convalida in automatico configurazioni sicure sfruttando un apposito servizio o strumento di gestione.
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
+ [Configurazione di una pipeline CI/CD in AWS](https://aws.amazon.com/getting-started/projects/set-up-ci-cd-pipeline/)
## Risorse
**Documenti correlati:**
+ [Come usare le policy di controllo dei servizi per impostare guardrail di permessi negli account della tua AWS Organization](https://aws.amazon.com/blogs/security/how-to-use-service-control-policies-to-set-permission-guardrails-across-accounts-in-your-aws-organization/)
**Video correlati:**
+ [Gestire ambienti AWS multi-account tramite AWS Organizations](https://youtu.be/fxo67UeeN1A)
+ [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM)
# SEC01-BP07 Identificare le minacce e dare priorità alle mitigazioni utilizzando un modello di minaccia.
Effettua la modellazione delle minacce per identificare e mantenere un registro aggiornato delle minacce potenziali e delle relative mitigazioni per il carico di lavoro. Definisci le priorità delle minacce e adatta le mitigazioni dei controlli di sicurezza per prevenire, intercettare e rispondere. Rivedi e mantieni questo aspetto nel contesto del tuo carico di lavoro e dell'evoluzione del panorama della sicurezza.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
**Che cos'è la modellazione delle minacce?**
"La modellazione delle minacce ha lo scopo di identificare, comunicare e comprendere le minacce e le mitigazioni nel contesto della protezione di qualcosa di valore." – [The Open Web Application Security Project (OWASP) Application Threat Modeling](https://owasp.org/www-community/Threat_Modeling)
**Perché realizzare un modello di minaccia?**
I sistemi sono complessi e nel tempo diventano sempre più complessi e capaci di fornire un maggiore valore aziendale e una maggiore soddisfazione e coinvolgimento dei clienti. Ciò significa che le decisioni di progettazione IT devono tenere conto di un numero sempre maggiore di casi d'uso. Questa complessità e il numero di combinazioni di casi d'uso rendono in genere gli approcci non strutturati inefficaci per individuare e mitigare le minacce. È invece necessario un approccio sistematico per enumerare le potenziali minacce al sistema e per elaborare le mitigazioni e stabilirne le priorità per assicurarsi che le risorse limitate dell'organizzazione abbiano il massimo impatto nel migliorare lo stato di sicurezza complessiva del sistema.
La modellazione delle minacce è progettata per fornire questo approccio sistematico, con l'obiettivo di trovare e affrontare i problemi nelle prime fasi del processo di progettazione, quando le mitigazioni hanno un costo e un impegno relativi bassi rispetto alle fasi successive del ciclo di vita. Questo approccio è in linea con il principio di [sicurezza *shift-left* del settore](https://owasp.org/www-project-devsecops-guideline/latest/00a-Overview). In definitiva, la modellazione delle minacce si integra con il processo di gestione del rischio di un'organizzazione e aiuta a prendere decisioni sui controlli da implementare utilizzando un approccio orientato alle minacce.
**Quando è necessario eseguire la modellazione delle minacce?**
La modellazione delle minacce deve essere avviata il più presto possibile nel ciclo di vita del carico di lavoro, in modo da avere una maggiore flessibilità di intervento sulle minacce identificate. Come per i bug del software, prima si identificano le minacce, più è conveniente affrontarle. Un modello di minacce è un documento vivo e deve continuare a evolvere in base ai cambiamenti dei carichi di lavoro. I modelli di minaccia vanno rivisti nel tempo, anche in caso di modifiche importanti, di cambiamenti nel panorama delle minacce o di adozione di nuove funzionalità o servizi.
### Passaggi dell'implementazione
**Come possiamo eseguire la modellazione delle minacce?**
Esistono diversi modi per eseguire la modellazione delle minacce. Come per i linguaggi di programmazione, anche in questo caso ci sono vantaggi e svantaggi e bisogna scegliere il metodo più adatto alle proprie esigenze. Un approccio possibile è iniziare con [Shostack’s 4 Question Frame for Threat Modeling](https://github.com/adamshostack/4QuestionFrame), che pone domande aperte per strutturare l'esercizio di modellazione delle minacce:
1. **A cosa si sta lavorando?**
Questa domanda ha lo scopo di aiutare a comprendere e concordare il sistema che si sta costruendo e i dettagli di tale sistema che sono rilevanti per la sicurezza. La creazione di un modello o di un diagramma è il modo più diffuso per rispondere a questa domanda, in quanto aiuta a visualizzare ciò che si sta costruendo, ad esempio utilizzando un [diagramma di flusso dei dati](https://en.wikipedia.org/wiki/Data-flow_diagram). Scrivere le ipotesi e i dettagli importanti del sistema aiuta anche a definire l'ambito di applicazione. In questo modo, tutti coloro che contribuiscono alla modellazione delle minacce possono concentrarsi sullo stesso aspetto, evitando deviazioni dispendiose in termini di tempo su argomenti fuori portata (comprese le versioni non aggiornate del sistema). Ad esempio, se si sta costruendo un'applicazione web, probabilmente non vale la pena procedere alla modellazione per la sequenza di avvio attendibile del sistema operativo per i browser client, poiché non si ha la possibilità di influire su questo aspetto con il proprio progetto.
1. **Cosa può andare storto?**
In questa fase si identificano le minacce al sistema. Le minacce sono azioni o eventi accidentali o intenzionali che hanno impatti indesiderati e potrebbero compromettere la sicurezza del sistema. Senza una visione chiara di ciò che potrebbe andare storto, non è possibile fare nulla per evitarlo.
Non esiste un elenco canonico di ciò che può andare storto. La creazione di questo elenco richiede un brainstorming e la collaborazione di tutti i componenti del team e dei [soggetti coinvolti](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/#tips) nell'esercizio di modellazione delle minacce. Per facilitare il brainstorming si può utilizzare un modello per l'identificazione delle minacce, ad esempio [STRIDE](https://en.wikipedia.org/wiki/STRIDE_(security)), che suggerisce diverse categorie da valutare: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of privilege (spoofing, manomissione, ripudio, divulgazione di informazioni, negazione del servizio ed elevazione dei privilegi). Inoltre, per facilitare il brainstorming, si possono consultare gli elenchi e le ricerche esistenti per trarne ispirazione, come ad esempio [OWASP Top 10](https://owasp.org/www-project-top-ten/), [HiTrust Threat Catalog](https://hitrustalliance.net/hitrust-threat-catalogue/) e il catalogo delle minacce della propria organizzazione.
1. **Che cosa faremo a questo proposito?**
Come nel caso della domanda precedente, non esiste un elenco canonico di tutte le possibili mitigazioni. Gli input di questa fase sono le minacce, gli attori e le aree di miglioramento identificate nella fase precedente.
La sicurezza e la conformità sono una [responsabilità condivisa da AWS e dal cliente](https://aws.amazon.com/compliance/shared-responsibility-model/). È importante capire che quando si chiede "Che cosa faremo?", si chiede anche "Chi è responsabile? Chi ha la responsabilità di fare qualcosa?" Comprendere l'equilibrio delle responsabilità tra utente e AWS consente di limitare l'esercizio di modellazione delle minacce alle mitigazioni sotto il proprio controllo, che di solito sono una combinazione di opzioni di configurazione del servizio AWS e di mitigazioni specifiche del proprio sistema.
Per la parte AWS relativa alla responsabilità condivisa, si scoprirà che i [servizi AWS rientrano nell'ambito di molti programmi di conformità](https://aws.amazon.com/compliance/services-in-scope/). Questi programmi aiutano a comprendere i solidi controlli in atto presso AWS per mantenere la sicurezza e la conformità del cloud. I report di audit di questi programmi sono disponibili per il download per i clienti AWS da [AWS Artifact](https://aws.amazon.com/artifact/).
Indipendentemente dai servizi AWS utilizzati, c'è sempre una responsabilità del cliente e le mitigazioni allineate a tale responsabilità devono essere incluse nel modello di minaccia. Per quanto riguarda le mitigazioni dei controlli di sicurezza per i servizi AWS stessi, è necessario considerare l'implementazione dei controlli di sicurezza in tutti i domini, compresi quelli quali la gestione delle identità e degli accessi (autenticazione e autorizzazione), la protezione dei dati (a riposo e in transito), la sicurezza dell'infrastruttura, la registrazione e il monitoraggio. La documentazione di ogni servizio AWS ha un [capitolo sulla sicurezza dedicato](https://docs.aws.amazon.com/security/) che fornisce indicazioni sui controlli di sicurezza da considerare come mitigazioni. È importante considerare il codice che si sta scrivendo e le sue dipendenze e pensare ai controlli che si possono mettere in atto per affrontare queste minacce. Questi controlli possono essere elementi come la [convalida degli input](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html), la [gestione delle sessioni](https://owasp.org/www-project-mobile-top-10/2014-risks/m9-improper-session-handling) e la [gestione dei limiti](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow). Spesso la maggior parte delle vulnerabilità viene introdotta nel codice personalizzato, quindi è bene concentrarsi su quest'area.
1. **Abbiamo fatto un buon lavoro?**
L'obiettivo è che il team e l'organizzazione migliorino sia la qualità dei modelli di minacce sia la velocità con cui vengono eseguiti nel tempo. Questi miglioramenti derivano da una combinazione di pratica, apprendimento, insegnamento e revisione. Per approfondire e mettere mano alla situazione, è consigliabile completare il corso di formazione [Threat modeling the right way for builders](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop) (Come modellare le minacce nel modo giusto per gli sviluppatori) o il [workshop](https://catalog.workshops.aws/threatmodel/en-US) insieme al team. Inoltre, se si desidera una guida su come integrare la modellazione delle minacce nel ciclo di vita dello sviluppo dell'applicazione della propria organizzazione, invitiamo a consultare il post [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) (Come affrontare la modellazione delle minacce) su AWS Security Blog (Blog sulla sicurezza AWS).
**Threat Composer**
Come ausilio nella modellazione delle minacce, puoi utilizzare lo strumento [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer), il cui scopo è ridurre il time-to-value di questa attività. Lo strumento consente di eseguire le seguenti operazioni:
+ Scrivere dichiarazioni sulle minacce in linea con la [sintassi delle minacce](https://catalog.workshops.aws/threatmodel/en-US/what-can-go-wrong/threat-grammar) che funzionino in un flusso di lavoro naturale non lineare
+ Generare un modello di minaccia leggibile dall'uomo
+ Generare un modello di minaccia leggibile dal computer per consentire la gestione dei modelli di minaccia come codice
+ Velocizzare l'individuazione delle aree di miglioramento della qualità e della copertura utilizzando l'area del pannello di controllo contenente le informazioni dettagliate
Per ulteriori riferimenti, visita la pagina relativa allo strumento Threat Composer e passa all'**area di lavoro di esempio** definita dal sistema.
## Risorse
**Best practice correlate:**
+ [SEC01-BP03 Identificazione e convalida degli obiettivi di controllo](sec_securely_operate_control_objectives.md)
+ [SEC01-BP04 Aggiornamento costante sulle minacce alla sicurezza](sec_securely_operate_updated_threats.md)
+ [SEC01-BP05 Aggiornamento costante sulle raccomandazioni di sicurezza](sec_securely_operate_updated_recommendations.md)
+ [SEC01-BP08 Valutazione e implementazione periodiche di nuovi servizi e funzionalità di sicurezza](sec_securely_operate_implement_services_features.md)
**Documenti correlati:**
+ [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) (AWS Security Blog)
+ [ NIST: Guide to Data-Centric System Threat Modelling ](https://csrc.nist.gov/publications/detail/sp/800-154/draft)
**Video correlati:**
+ [AWS Summit ANZ 2021 – How to approach threat modelling](https://www.youtube.com/watch?v=GuhIefIGeuA) (Summit ANZ 2021 – Come affrontare la modellazione delle minacce)
+ [AWS Summit ANZ 2022 - Scaling security – Optimise for fast and secure delivery ](https://www.youtube.com/watch?v=DjNPihdWHeA) (Summit ANZ 2022 - Scalare la sicurezza - Ottimizzare la consegna rapida e sicura)
**Training correlati:**
+ [ Threat modeling the right way for builders – AWS Skill Builder virtual self-paced training ](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop) (La corretta modellazione delle minacce per gli sviluppatori – Formazione virtuale autogestita Skill Builder)
+ [ Threat modeling the right way for builders – AWS Workshop ](https://catalog.workshops.aws/threatmodel) (La corretta modellazione delle minacce per gli sviluppatori – Workshop)
**Strumenti correlati:**
+ [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer)
# SEC01-BP08 Valutazione e implementazione periodiche di nuovi servizi e funzionalità di sicurezza
Valuta e implementa servizi e funzionalità di sicurezza di AWS e partner AWS che consentano di sviluppare l'assetto di sicurezza del carico di lavoro. Il blog sulla sicurezza AWS evidenzia nuovi servizi e funzionalità AWS, guide all'implementazione e linee guida generali sulla sicurezza. [Novità di AWS](https://aws.amazon.com/new) è un'ottima scelta per essere aggiornati su tutte le nuove funzionalità, i servizi e gli annunci AWS.
**Livello di rischio associato se questa best practice non fosse adottata:** Basso
## Guida all'implementazione
+ Pianificazione di revisioni regolari: crea un calendario di attività di revisione che preveda requisiti di conformità, valutazione delle nuove funzionalità e dei nuovi servizi di sicurezza AWS e l'aggiornamento costante rispetto alle novità del settore.
+ Funzionalità e servizi AWS: scopri le funzionalità di sicurezza disponibili per i servizi che utilizzi e approfondisci le nuove caratteristiche al momento del rilascio.
+ [ Blog sulla sicurezza AWS](https://aws.amazon.com/blogs/security/)
+ [ Bollettini sulla sicurezza AWS](https://aws.amazon.com/security/security-bulletins/)
+ [Documentazione del servizio AWS](https://aws.amazon.com/documentation/)
+ Definizione del processo di onboarding del servizio AWS: definisci i processi per l'onboarding di nuovi servizi AWS. Includi il modo in cui valuti la funzionalità dei nuovi servizi AWS e i requisiti di conformità per il tuo carico di lavoro.
+ Test di nuovi servizi e funzionalità: testa nuovi servizi e funzionalità al momento del rilascio in un ambiente non di produzione che replica in maniera fedele quello di produzione.
+ Implementazione di altri meccanismi di difesa: implementa meccanismi automatizzati per difendere il carico di lavoro, esplora le opzioni disponibili.
+ [Correzione di risorse AWS non conformi in base alle regole di Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
## Risorse
**Video correlati:**
+ [Security Best Practices the Well-Architected Way ](https://youtu.be/u6BCVkXkPnM)