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:

É 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 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:

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. As etapas manuais exigem mecanismos para garantir que as descobertas sejam abordadas. Para obter mais informações, consulteTema 8: implementar mecanismos para processos manuais. AWS Config as regras exigem supervisão ou automação semelhantes para remediar recursos não compatíveis. 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 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, o AWS Lambda e o DynamoDB. Um banco de dados no Amazon Relational Database Service (Amazon RDS) exige menos responsabilidade operacional do que um banco de dados no Amazon Elastic Compute Cloud (Amazon EC2).

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, 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 ou o AWS CodeDeploy.

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 ou no AWS Cloud Development Kit (AWS CDK). 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, 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 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.