As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Reinterpretação das estratégias Essential Eight para a nuvem
Confira abaixo as estratégias originais de mitigação do Essential Eight que foram projetadas para redes conectadas à internet baseadas na Microsoft:
+ Controle de aplicações
+ Aplicações de patches
+ Definir as configurações de macros do Microsoft Office
+ Hardening da aplicações de usuários
+ Restringir privilégios administrativos
+ Sistemas operacionais de patches
+ Autenticação multifator
+ Backups regulares
É importante reiterar que o framework Essential Eight não foi projetado para ambientes em nuvem. No entanto, os princípios subjacentes são aplicáveis e há uma sobreposição entre as estratégias Essential Eight e as melhores práticas do AWS Well-Architected Framework.
Várias abordagens nativas da nuvem podem melhorar a segurança e reduzir de forma significativa sua carga de conformidade. Em ambientes on-premises, você é responsável por todos os aspectos da segurança e não há controles herdados. Ao executar cargas de trabalho na nuvem, AWS é responsável por proteger a infraestrutura que executa nossos serviços. Você também pode reduzir sua carga de conformidade usando automação e serviços gerenciados. *Os serviços gerenciados*, também conhecidos como *serviços abstratos*, AWS operam a camada de infraestrutura, o sistema operacional e as plataformas, e você acessa os endpoints para armazenar e recuperar dados. Serviços da AWS O Amazon Simple Storage Service (Amazon S3) e o Amazon DynamoDB são exemplos de serviços gerenciados. Para obter mais informações, consulte a seção [Tema 1: usar serviços gerenciados](theme-1.md) deste guia.
Portanto, alguma reinterpretação é necessária para tornar as estratégias Essential Eight apropriadas para as workloads na AWS. Este guia converte as estratégias Essential Eight em AWS *temas*.
## Uso dos temas
Este guia está dividido em oito temas. Cada estratégia do Essential Eight é mapeada para um ou mais dos seguintes temas, e cada tema é mapeado para uma ou mais melhores práticas no Well-Architected AWS Framework:
+ [Tema 1: usar serviços gerenciados](theme-1.md)
+ [Tema 2: gerenciar infraestrutura imutável por meio de pipelines seguros](theme-2.md)
+ [Tema 3: gerenciar infraestrutura mutável com automação](theme-3.md)
+ [Tema 4: gerenciar identidades](theme-4.md)
+ [Tema 5: estabelecer um perímetro de dados](theme-5.md)
+ [Tema 6: automatizar backups](theme-6.md)
+ [Tema 7: centralizar o registro em log e o monitoramento](theme-7.md)
+ [Tema 8: implementar mecanismos para processos manuais](theme-8.md)
Cada tema inclui uma visão geral do tópico, as melhores práticas relacionadas ao AWS Well-Architected Framework e instruções sobre como alcançar a maturidade do Essential Eight e monitorar a conformidade. As instruções fornecem etapas manuais ou ajudam você a configurar automações usando as [regras do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html). As etapas manuais exigem mecanismos para garantir que as descobertas sejam abordadas. Para obter mais informações, consulte[Tema 8: implementar mecanismos para processos manuais](theme-8.md). AWS Config as regras exigem supervisão ou automação semelhantes para [remediar recursos não compatíveis](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html). Seguindo as orientações alinhadas a esses temas, você pode alcançar a maturidade do Essential Eight com uma abordagem que também maximiza os benefícios da nuvem.
## Reinterpretação das estratégias Essential Eight para a nuvem
Como o framework Essential Eight não foi projetado para ambientes de nuvem, é essencial adotar uma abordagem nativa da nuvem ao analisar os princípios subjacentes de cada estratégia do Essential Eight. A abordagem varia de acordo com duas questões principais.
### Quais serviços você está usando?
O [AWS modelo de responsabilidade compartilhada](australian-sec-compliance.md#shared-model) pode ajudar a aliviar seus encargos operacionais e de conformidade. Os serviços gerenciados transferem mais responsabilidade AWS para manter a disponibilidade, o desempenho e a otimização da segurança do serviço implantado. Os serviços gerenciados também eliminam as despesas operacionais e administrativas da manutenção de um serviço, possibilitando mais tempo para se concentrar na inovação.
Os serviços gerenciados incluem serviços sem servidor, como o [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html), o [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) e o [DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html). Um banco de dados no [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) exige menos responsabilidade operacional do que um banco de dados no [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/ec2/?icmpid=docs_homepage_compute).
Por exemplo, se você estiver adaptando a estratégia Essential Eight dos *sistemas operacionais Patch* para a nuvem, precisará considerar quais serviços está usando e se é responsável por corrigir esses recursos. AWS é responsável por corrigir serviços totalmente gerenciados, como Lambda e DynamoDB. Para outros serviços, como o Amazon RDS ou o [Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html), talvez seja necessário gerenciar os patches durante as janelas de manutenção.
### Qual modelo de implantação você está usando?
Sua organização está usando uma abordagem de infraestrutura mutável ou imutável?
O modelo de *infraestrutura mutável* atualiza e modifica a infraestrutura existente para workloads de produção.** **Este era o método padrão de implantação antes da nuvem, quando a substituição da infraestrutura do servidor era tão cara e demorada que a abordagem mais prática era aplicar alterações nos servidores que já estavam em produção. Um exemplo de abordagem mutável na nuvem é implantar alterações de aplicações diretamente nas instâncias do EC2 em execução, manualmente ou usando um serviço de implantação de software, como o [Run Command do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) ou o [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html).
O modelo de *infraestrutura imutável* implanta uma nova infraestrutura para workloads de produção em vez de atualizar, aplicar patches ou modificar a infraestrutura existente. Um exemplo de abordagem imutável é definir uma pilha de aplicações no [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) ou no [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html). Você pode usar esses serviços para implantar uma pilha de aplicações por meio de pipelines de integração e entrega contínuas (CI/CD). Essa abordagem usa [métodos de implantação](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html), como *rolagem* ou *azul/verde*. Para obter mais informações sobre essa abordagem, consulte as práticas recomendadas de [implantação usando infraestrutura imutável](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_immutable_infrastructure.html) no AWS Well-Architected Framework.
Por exemplo, se você estiver adaptando a estratégia Essential Eight *dos sistemas operacionais Patch* para a nuvem, precisará considerar como os patches se aplicam ao modelo de implantação. Para uma infraestrutura mutável, você pode corrigir recursos manualmente ou melhorar a eficiência operacional por meio da automação. Se você estiver usando uma infraestrutura imutável, usaria um CI/CD pipeline para implantar uma nova infraestrutura com a versão mais recente do sistema operacional. Na verdade, o termo *aplicação de patches* é um termo inadequado nesse modelo porque a infraestrutura seria substituída em vez de corrigida.