Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Reinterpretazione delle otto strategie essenziali per il cloud
Di seguito sono riportate le strategie di mitigazione originali di Essential Eight progettate per reti connesse Microsoft a Internet basate su:
+ Controllo delle applicazioni
+ Applicazioni di patch
+ Configura le impostazioni delle Microsoft Office macro
+ Rafforzamento delle applicazioni utente
+ Limita i privilegi amministrativi
+ Patch i sistemi operativi
+ Autenticazione a più fattori
+ Backup regolari
È importante ribadire che il framework Essential Eight non è progettato per ambienti cloud. Tuttavia, i principi di base sono applicabili e vi è una sovrapposizione tra le strategie Essential Eight e le migliori pratiche del AWS Well-Architected Framework.
Diversi approcci nativi del cloud possono migliorare la sicurezza e ridurre drasticamente il carico di conformità. Negli ambienti locali, l'utente è responsabile di tutti gli aspetti della sicurezza e non esistono controlli ereditati. Quando esegue carichi di lavoro nel cloud, AWS è responsabile della protezione dell'infrastruttura che gestisce i nostri servizi. Puoi anche ridurre il carico di conformità utilizzando l'automazione e i servizi gestiti. *I servizi gestiti*, noti anche come *servizi astratti*, consentono Servizi AWS AWS di gestire il livello di infrastruttura, il sistema operativo e le piattaforme e di accedere agli endpoint per archiviare e recuperare i dati. Amazon Simple Storage Service (Amazon S3) Simple Storage Service (Amazon S3) e Amazon DynamoDB sono esempi di servizi gestiti. Per ulteriori informazioni, consulta la [Tema 1: Utilizzare i servizi gestiti](theme-1.md) sezione di questa guida.
Pertanto, è necessaria una certa reinterpretazione per rendere le strategie Essential Eight appropriate per i carichi di lavoro. AWS*Questa guida converte le strategie Essential Eight in temi. AWS *
## Utilizzo dei temi
Questa guida è suddivisa in otto temi. Ogni strategia Essential Eight è mappata su uno o più dei seguenti temi e ogni tema è mappato su una o più best practice nel Well-Architected AWS Framework:
+ [Tema 1: Utilizzare i servizi gestiti](theme-1.md)
+ [Tema 2: Gestione dell'infrastruttura immutabile tramite pipeline sicure](theme-2.md)
+ [Tema 3: Gestisci l'infrastruttura mutabile con l'automazione](theme-3.md)
+ [Tema 4: Gestire le identità](theme-4.md)
+ [Tema 5: Stabilire un perimetro di dati](theme-5.md)
+ [Tema 6: Automatizza i backup](theme-6.md)
+ [Tema 7: Centralizzare la registrazione e il monitoraggio](theme-7.md)
+ [Tema 8: Implementazione di meccanismi per i processi manuali](theme-8.md)
Ogni tema include una panoramica dell'argomento, le best practice correlate di AWS Well-Architected Framework e istruzioni su come raggiungere la maturità di Essential Eight e monitorare la conformità. [Le istruzioni forniscono passaggi manuali o aiutano a configurare le automazioni utilizzando le regole.AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) Le procedure manuali richiedono meccanismi per garantire che i risultati vengano risolti. Per ulteriori informazioni, vedere[Tema 8: Implementazione di meccanismi per i processi manuali](theme-8.md). AWS Config le regole richiedono una supervisione o un'automazione simili per [porre rimedio alle risorse non conformi](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html). Seguendo le linee guida in linea con questi temi, puoi raggiungere la maturità di Essential Eight con un approccio che massimizza anche i vantaggi del cloud.
## Reinterpretazione delle strategie Essential Eight per il cloud
Poiché il framework Essential Eight non è progettato per ambienti cloud, è essenziale adottare un approccio nativo del cloud nell'affrontare i principi alla base di ciascuna strategia Essential Eight. L'approccio varia in base a due domande chiave.
### Quali servizi stai utilizzando?
[AWS modello di responsabilità condivisa](australian-sec-compliance.md#shared-model)Possono contribuire ad alleggerire gli oneri operativi e di conformità. I servizi gestiti trasferiscono maggiori AWS responsabilità al mantenimento della disponibilità, delle prestazioni e dell'ottimizzazione della sicurezza del servizio distribuito. I servizi gestiti eliminano inoltre l'onere operativo e amministrativo della manutenzione di un servizio, offrendo più tempo per concentrarsi sull'innovazione.
I servizi gestiti includono servizi serverless, come [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) e [DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html). [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) Un database su [Amazon Relational Database Service (Amazon RDS) richiede meno responsabilità operative rispetto a un database](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) su Amazon Elastic Compute Cloud ([Amazon EC2) Elastic Compute Cloud (Amazon](https://docs.aws.amazon.com/ec2/?icmpid=docs_homepage_compute) EC2).
Ad esempio, se stai adattando la strategia Essential Eight del *sistema operativo Patch* per il cloud, devi considerare quali servizi stai utilizzando e se sei responsabile dell'applicazione delle patch a tali risorse. AWS è responsabile dell'applicazione di patch a servizi completamente gestiti, come Lambda e DynamoDB. Per altri servizi, come Amazon RDS o [Amazon](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html) Redshift, potrebbe essere necessario gestire le patch durante le finestre di manutenzione.
### Quale modello di distribuzione stai utilizzando?
La tua organizzazione utilizza un approccio all'infrastruttura mutevole o immutabile?
Il modello di *infrastruttura mutabile* aggiorna e modifica l'infrastruttura esistente per i carichi di lavoro di produzione. ****Questo era il metodo di implementazione standard prima del cloud, quando la sostituzione dell'infrastruttura dei server era così costosa e dispendiosa in termini di tempo che l'approccio più pratico consisteva nell'applicare le modifiche ai server già in produzione. [Un esempio di approccio mutevole nel cloud è l'implementazione delle modifiche alle applicazioni direttamente sulle istanze EC2 in esecuzione, manualmente o utilizzando un servizio di distribuzione del software, come Run Command o.AWS Systems Manager[AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html)
Il modello di infrastruttura *immutabile implementa una nuova infrastruttura* per i carichi di lavoro di produzione anziché aggiornare, applicare patch o modificare l'infrastruttura esistente. Un esempio di approccio immutabile è la definizione di uno stack di applicazioni in or. [AWS CloudFormation[AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) È possibile utilizzare questi servizi per distribuire uno stack di applicazioni tramite pipeline di integrazione e distribuzione continua (CI/CD). **Questo approccio utilizza [metodi di implementazione](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html) come rolling o blue/green.** Per ulteriori informazioni su questo approccio, consulta la best practice [Deploy using immutable infrastructure](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_immutable_infrastructure.html) nel Well-Architected AWS Framework.
Ad esempio, se stai adattando la strategia Essential Eight del *sistema operativo Patch* per il cloud, devi considerare in che modo l'applicazione delle patch si applica al modello di implementazione. Per un'infrastruttura mutevole, è possibile applicare manualmente le patch alle risorse o migliorare l'efficienza operativa attraverso l'automazione. Se utilizzi un'infrastruttura immutabile, utilizzerai una CI/CD pipeline per implementare una nuova infrastruttura con l'ultima versione del sistema operativo. In effetti, il termine *patching* è un termine improprio in questo modello perché l'infrastruttura verrebbe sostituita anziché patchata.