# Proteção da infraestrutura
A proteção da infraestrutura abrange metodologias de controle, como defesa em profundidade, que são necessárias para atender às práticas recomendadas e às obrigações organizacionais ou regulatórias. O uso dessas metodologias é fundamental para o êxito de operações contínuas na nuvem.
A proteção da infraestrutura é elemento essencial de um programa de segurança da informação. Ela garante que os sistemas e os serviços de sua workload sejam protegidos contra acesso não intencional e não autorizado e possíveis vulnerabilidades. Por exemplo, você definirá limites de confiança (por exemplo, limites de rede e conta), configuração e manutenção da segurança do sistema (por exemplo, fortalecimento, minimização e aplicação de patches), autenticação e autorizações do sistema operacional (por exemplo, usuários, chaves e níveis de acesso) e outros pontos de aplicação de políticas apropriados (por exemplo, firewalls de aplicações Web e/ou API gateways).
**Regiões, zonas de disponibilidade, zonas locais da AWS e AWS Outposts**
Certifique-se de estar familiarizado com os conceitos de regiões, zonas de disponibilidade, [zonas locais da AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) e [AWS Outposts](https://aws.amazon.com/outposts/), todos eles componentes da infraestrutura global segura da AWS.
A AWS tem o conceito de região, que é um local físico em alguma parte do mundo onde agrupamos data centers. Cada grupo de data centers lógicos é chamado de zona de disponibilidade (AZ). Cada região da AWS consiste em várias AZs isoladas e fisicamente separadas em uma área geográfica. Se você tiver requisitos de residência de dados, poderá escolher a região da AWS próxima ao local desejado. Você mantém controle total e proprietário sobre a região em que seus dados estão localizados fisicamente, facilitando a conformidade com requisitos regionais de conformidade e a residência de dados. Cada AZ conta com fornecimento de energia, refrigeração e segurança física independentes. Se uma aplicação for particionada entre AZs, você terá níveis melhores de isolamento e proteção contra problemas como falta de energia elétrica, raios, tornados, terremotos e muito mais. As AZs estão separadas fisicamente por uma distância significativa, a muitos quilômetros de qualquer outra AZ, embora todas estejam a no máximo 100 km (60 milhas) de distância umas das outras. Todas as AZs em uma região AWS são interconectadas com rede de alta largura de banda e baixa latência, por fibra metropolitana dedicada totalmente redundante, fornecendo uma rede de alto throughput e baixa latência entre as zonas. Todo o tráfego entre AZs é criptografado. Os clientes da AWS focados na alta disponibilidade podem projetar suas aplicações para serem executadas em várias AZs a fim de obter uma tolerância ainda maior a falhas. AWS Com as regiões, é possível atingir os mais altos níveis de segurança, conformidade e proteção de dados.
As zonas locais da AWS coloca os recursos de computação, armazenamento, banco de dados e outros serviços da AWS selecionados mais perto dos usuários finais. Com as zonas locais da AWS, é possível executar facilmente aplicações altamente exigentes que exigem latências de um dígito em milissegundos para seus usuários finais, como criação de conteúdo de mídia e entretenimento, jogos em tempo real, simulações de reservatórios, automação de design eletrônico e machine learning. Cada localização de zona local da AWS é uma extensão de uma região da AWS na qual você pode executar suas aplicações sensíveis à latência usando serviços da AWS como Amazon EC2, Amazon VPC, Amazon EBS, Amazon File Storage e Elastic Load Balancing em um local fisicamente próximo dos usuários finais. AWS As zonas locais fornecem uma conexão segura e de alta largura de banda entre workloads locais e aquelas em execução na região da AWS, permitindo que você se conecte perfeitamente a toda a gama de serviços na região por meio das mesmas APIs e conjuntos de ferramentas.
Os AWS Outposts trazem serviços, infraestrutura e modelos operacionais nativos da AWS para praticamente qualquer data center, espaço de compartilhamento ou instalação on-premises. Você pode usar as mesmas APIs, ferramentas e infraestrutura da AWS nas instalações on-premises e na Nuvem AWS para oferecer uma experiência híbrida verdadeiramente consistente. AWS O Outposts foi projetado para ambientes conectados e pode ser usado para suportar workloads que devem permanecer no local devido à baixa latência ou às necessidades locais de processamento de dados.
A AWS tem várias abordagens para a proteção da infraestrutura. As seções a seguir descrevem como usar essas abordagens.
**Topics**
+ [Proteção de redes](protecting-networks.md)
+ [Proteção da computação](protecting-compute.md)
# Proteção de redes
Os usuários, tanto em sua força de trabalho quanto em seus clientes, podem estar localizados em qualquer lugar. Você precisa se afastar dos modelos tradicionais de confiar em qualquer pessoa e em qualquer coisa que tenha acesso à sua rede. Ao seguir o princípio de aplicar segurança em todas as camadas, você emprega uma abordagem [Zero Trust](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/). A segurança Zero Trust é um modelo em que os componentes ou microsserviços da aplicação são considerados distintos uns dos outros e nenhum componente ou microsserviço confia em nenhum outro.
O planejamento e o gerenciamento minuciosos do design da rede são a base do isolamento e dos limites para os recursos em sua workload. Como muitos recursos da workload operam em uma VPC e herdam as propriedades de segurança, é essencial que o projeto tenha o suporte de mecanismos de inspeção e proteção respaldados por automação. Da mesma forma, para workloads que operam fora de uma VPC, usando serviços puramente de borda e/ou sem servidor, as práticas recomendadas se aplicam em uma abordagem mais simplificada. Consulte a [Lente de aplicações sem servidor do AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html) para obter orientações específicas sobre segurança sem servidor.
**Topics**
+ [SEC05-BP01 Criar camadas de rede](sec_network_protection_create_layers.md)
+ [SEC05-BP02 Controlar o fluxo de tráfego dentro das camadas de rede](sec_network_protection_layered.md)
+ [SEC05-BP03 Implementar proteção baseada em inspeção](sec_network_protection_inspection.md)
+ [SEC05-BP04 Automatizar a proteção da rede](sec_network_auto_protect.md)
# SEC05-BP01 Criar camadas de rede
Segmente a topologia de rede em diferentes camadas com base nos agrupamentos lógicos dos componentes da workload e de acordo com a confidencialidade dos dados e os requisitos de acesso. Diferencie os componentes que exigem acesso de entrada pela internet, como endpoints públicos da web e aqueles que precisam apenas de acesso interno, como bancos de dados.
**Resultado desejado:** as camadas de sua rede fazem parte de uma abordagem integral de defesa aprofundada à segurança que complementa a estratégia de autenticação e autorização de identidade de suas workloads. As camadas estão posicionadas de acordo com a confidencialidade dos dados e os requisitos de acesso, com mecanismos apropriados de fluxo e controle de tráfego.
**Práticas comuns que devem ser evitadas:**
+ Você cria todos os recursos em uma única VPC ou sub-rede.
+ Você constrói as camadas de rede sem considerar os requisitos de confidencialidade dos dados, o comportamento dos componentes ou a funcionalidade.
+ Você usa VPCs e sub-redes como padrão para todas as considerações de camada de rede e não considera como os serviços gerenciados da AWS influenciam sua topologia.
**Benefícios de implementar esta prática recomendada:** estabelecer camadas de rede é a primeira etapa para restringir caminhos desnecessários na rede, especialmente aqueles que levam a sistemas e dados críticos. Desse modo, o acesso de agentes não autorizados à sua rede e a outros recursos dentro dela torna-se mais difícil. Camadas de rede discretas reduzem de forma favorável o escopo da análise para sistemas de inspeção, por exemplo, para detecção de intrusões ou prevenção de malware. Isso reduz a possibilidade de falsos positivos e a sobrecarga de processamento desnecessária.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Quando se projeta uma arquitetura de workload, é comum separar os componentes em diferentes camadas com base nas respectivas responsabilidades. Por exemplo, uma aplicação web pode ter uma camada de apresentação, uma camada de aplicação e uma camada de dados. É possível adotar uma abordagem semelhante ao projetar sua topologia de rede. Os controles de rede subjacentes podem ajudar a aplicar os requisitos de acesso aos dados da workload. [Por exemplo, em uma arquitetura de aplicação web de três camadas, você pode armazenar seus arquivos de camada de apresentação estática no [Amazon](https://aws.amazon.com/s3/) S3 e servi-los desde uma rede de entrega de conteúdo (CDN), como o Amazon CloudFront](https://aws.amazon.com/cloudfront/). A camada de aplicação pode ter endpoints públicos que um [Application Load Balancer (ALB)](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/) serve em uma sub-rede pública da [Amazon VPC](https://aws.amazon.com/vpc/) (semelhante a uma zona desmilitarizada, ou DMZ), com serviços de backend implantados em sub-redes privadas. A camada de dados, que hospeda recursos como bancos de dados e sistemas de arquivos compartilhados, pode residir em diferentes sub-redes privadas dos recursos da camada de aplicação. Em cada um desses limites de camada (CDN, sub-rede pública, sub-rede privada), é possível implantar controles que permitam somente a entrada do tráfego autorizado.
De modo semelhante à modelagem de camadas de rede com base na finalidade funcional dos componentes da workload, considere também a confidencialidade dos dados que estão sendo processados. Usando o exemplo de aplicação web, embora todos os serviços de workload possam residir na camada de aplicação, serviços diferentes podem processar dados com diferentes níveis de confidencialidade. Nesse caso, dividir a camada de aplicação usando várias sub-redes privadas, diferentes VPCs na mesma Conta da AWS ou até mesmo diferentes VPCs em diferentes Contas da AWS para cada nível de confidencialidade de dados pode ser apropriado de acordo com seus requisitos de controle.
Uma consideração adicional sobre as camadas de rede é a consistência do comportamento dos componentes da workload. Continuando com o exemplo, na camada de aplicação, você pode ter serviços que aceitem entradas de usuários finais ou integrações de sistemas externos que são inerentemente mais arriscadas do que as entradas de outros serviços. Os exemplos incluem uploads de arquivos, scripts de código para execução, verificação de e-mails e assim por diante. Colocar esses serviços em uma camada de rede própria ajuda a criar um limite de isolamento mais forte em torno deles e pode impedir que o comportamento exclusivo de cada um deles crie alertas falsos positivos nos sistemas de inspeção.
Como parte do seu design, considere como o uso de serviços gerenciados da AWS influencia sua topologia de rede. Explore como serviços como o [Amazon VPC Lattice](https://aws.amazon.com/vpc/lattice/) podem ajudar a facilitar a interoperabilidade dos componentes da workload nas camadas da rede. Ao usar o [AWS Lambda](https://aws.amazon.com/lambda/), implante nas sub-redes da VPC, a menos que haja motivos específicos para não fazê-lo. Determine onde a VPC termina e o [AWS PrivateLink](https://aws.amazon.com/privatelink/) pode simplificar a adesão às políticas de segurança que limitam o acesso aos gateways da Internet.
### Etapas de implementação
1. Revise a arquitetura da sua workload. Agrupe logicamente os componentes e serviços com base nas funções às quais eles atendem, na confidencialidade dos dados que estão sendo processados e no respectivo comportamento.
1. Com relação a componentes que respondem a solicitações da internet, considere usar balanceadores de carga ou outros proxies para fornecer endpoints públicos. Explore mudanças nos controles de segurança usando serviços gerenciados, como CloudFront, [Amazon API Gateway](https://aws.amazon.com/api-gateway/), Elastic Load Balancing e [AWS Amplify](https://aws.amazon.com/amplify/) para hospedar endpoints públicos.
1. Para componentes executados em ambientes computacionais, como instâncias do Amazon EC2, contêineres do [AWS Fargate](https://aws.amazon.com/fargate/) ou funções do Lambda, implante-os em sub-redes privadas com base em seus grupos desde a primeira etapa.
1. Para serviços da AWS totalmente gerenciados, como [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), [Amazon Kinesis](https://aws.amazon.com/kinesis/) ou [Amazon SQS](https://aws.amazon.com/sqs/), considere usar endpoints da VPC como padrão para acesso por endereços IP privados.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL02 Planejar a topologia da rede](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html)
+ [PERF04-BP01 Compreender como a rede afeta a performance](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_networking_understand_how_networking_impacts_performance.html)
**Vídeos relacionados:**
+ [AWS re:Invent 2023: Fundamentos de rede na AWS](https://www.youtube.com/watch?v=8nNurTFy-h4)
**Exemplos relacionados:**
+ [Exemplos de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-examples-intro.html)
+ [Acessar aplicações de contêiner de forma privada no Amazon ECS usando o AWS Fargate, o AWS PrivateLink e um Network Load Balancer](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html)
+ [Servir conteúdo estático em um bucket do Amazon S3 por meio de uma VPC usando o Amazon CloudFront](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.html)
# SEC05-BP02 Controlar o fluxo de tráfego dentro das camadas de rede
Dentro das camadas da sua rede, use uma segmentação adicional para restringir o tráfego somente aos fluxos necessários para cada workload. Primeiro, concentre-se em controlar o tráfego entre a Internet ou outros sistemas externos para uma workload e seu ambiente (tráfego *norte-sul*). Depois, observe os fluxos entre diferentes componentes e sistemas (tráfego *leste-oeste*).
**Resultado desejado:** você permite somente os fluxos de rede necessários para que os componentes de suas workloads se comuniquem uns com os outros e com seus clientes e com quaisquer outros serviços dos quais eles dependam. Seu design considera questões como comparação entre entradas e saídas públicas e privadas, classificação de dados, regulamentações regionais e requisitos de protocolo. Sempre que possível, você favorece fluxos ponto a ponto em vez de emparelhamento de rede como parte de um *princípio de design de privilégio mínimo*.
**Práticas comuns que devem ser evitadas:**
+ Você adota uma abordagem de segurança de rede baseada em perímetro e controla apenas o fluxo de tráfego no limite das camadas de sua rede.
+ Você presume que todo o tráfego dentro de uma camada de rede está autenticado e autorizado.
+ Você aplica controles para o tráfego de entrada ou de saída, mas não para ambos.
+ Você depende exclusivamente dos componentes da workload e dos controles de rede para autenticar e autorizar o tráfego.
**Benefícios de implementar esta prática recomendada:** essa prática ajuda a reduzir o risco de movimentação não autorizada em sua rede e adiciona uma camada extra de autorização às suas workloads. Ao realizar o controle do fluxo de tráfego, você pode restringir o escopo do impacto de um incidente de segurança e acelerar a detecção e a resposta.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Embora as camadas de rede ajudem a estabelecer os limites em torno de componentes da workload que atendem a funções, níveis de confidencialidade de dados e comportamentos semelhantes, você pode criar um nível de controle de tráfego bem mais refinado usando técnicas para segmentar ainda mais os componentes dentro dessas camadas, seguindo o princípio de privilégio mínimo. Na AWS, as camadas de rede são definidas principalmente via sub-redes de acordo com faixas de endereços IP em uma Amazon VPC. As camadas também podem ser definidas usando diferentes VPCs, como para agrupar ambientes de microsserviços por domínio de negócios. Ao usar várias VPCs, medie o roteamento usando um [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/). Embora isso forneça controle de tráfego em um nível de camada 4 (endereços IP e intervalos de portas) usando grupos de segurança e tabelas de rotas, você pode obter mais controle usando serviços adicionais como [AWS PrivateLink](https://aws.amazon.com/privatelink/), [Firewall de DNS do Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html), [AWS Network Firewall](https://aws.amazon.com/network-firewall/) e [AWS WAF](https://aws.amazon.com/waf/).
Entenda e faça um inventário do fluxo de dados e dos requisitos de comunicação de workloads em termos de partes que iniciam a conexão, portas, protocolos e camadas de rede. Avalie os protocolos disponíveis para estabelecer conexões e transmitir dados para selecionar aqueles que atendam aos seus requisitos de proteção (por exemplo, HTTPS em vez de HTTP). Capture esses requisitos nos limites de suas redes e dentro de cada camada. Depois que esses requisitos forem identificados, explore as opções para permitir que apenas o tráfego necessário flua em cada ponto de conexão. Um bom ponto de partida é usar *grupos de segurança* em sua VPC, pois eles podem ser anexados a recursos que usam uma interface de rede elástica (ENI), como instâncias do Amazon EC2, tarefas do Amazon ECS, pods do Amazon EKS ou bancos de dados do Amazon RDS. Ao contrário de um firewall de camada 4, um grupo de segurança pode ter uma regra que permite o tráfego de outro grupo de segurança por meio do respectivo identificador, minimizando as atualizações à medida que os recursos dentro do grupo mudam ao longo do tempo. Você também pode filtrar o tráfego por meio de regras de entrada e saída usando grupos de segurança.
Quando o tráfego se move entre as VPCs, é comum usar o emparelhamento de VPCs para roteamento simples ou o AWS Transit Gateway para roteamento complexo. Com essas abordagens, você facilita os fluxos de tráfego entre o intervalo de endereços IP das redes de origem e de destino. No entanto, se sua workload exigir apenas fluxos de tráfego entre componentes específicos em VPCs diferentes, considere usar uma conexão ponto a ponto usando o [AWS PrivateLink](https://aws.amazon.com/privatelink/). Para isso, identifique qual serviço deve atuar como produtor e qual deve atuar como consumidor. Implante um balanceador de carga compatível para o produtor, ative o PrivateLink adequadamente e, em seguida, aceite uma solicitação de conexão do consumidor. Em seguida, o serviço do produtor recebe um endereço IP privado da VPC do consumidor que o consumidor pode usar para fazer solicitações subsequentes. Essa abordagem reduz a necessidade de emparelhar as redes. Inclua os custos de processamento de dados e balanceamento de carga como parte da avaliação do PrivateLink.
Embora os grupos de segurança e o PrivateLink ajudem a controlar o fluxo entre os componentes de suas workloads, outra consideração importante é como controlar quais domínios DNS seus recursos podem acessar (se houver). Dependendo da configuração DHCP das suas VPCs, é possível considerar dois serviços da AWS diferentes para essa finalidade. A maioria dos clientes usa o serviço DNS padrão do Route 53 Resolver (também chamado de servidor Amazon DNS ou AmazonProvideDDNS) disponível para VPCs no endereço \$12 de seu intervalo CIDR. Com essa abordagem, é possível criar regras de firewall de DNS e associá-las à VPC para determinar quais ações devem ser realizadas para as listas de domínios que você fornece.
Se você não estiver usando o Route 53 Resolver, ou se quiser complementar o Resolver com recursos mais detalhados de inspeção e controle de fluxo, além da filtragem de domínio, considere implantar um AWS Network Firewall. Esse serviço inspeciona pacotes individuais usando regras sem estado ou com estado para determinar se deve negar ou permitir o tráfego. Você pode adotar uma abordagem semelhante para filtrar o tráfego de entrada da web para seus endpoints públicos usando o AWS WAF. Para obter mais orientações sobre esses serviços, consulte [SEC05-BP03 Implementar proteção baseada em inspeção](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_inspection.html).
### Etapas de implementação
1. Identifique os fluxos de dados necessários entre os componentes das workloads.
1. Aplique vários controles com uma abordagem de defesa profunda para tráfego de entrada e saída, incluindo o uso de grupos de segurança e tabelas de rotas.
1. Use firewalls para definir um controle refinado sobre o tráfego de rede que entra, sai e atravessa suas VPCs, como o Firewall de DNS do Route 53 Resolver, o AWS Network Firewall e o AWS WAF. Considere usar o [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/) para configurar e gerenciar centralmente suas regras de firewall em toda a organização.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL03-BP01 Escolher como segmentar a workload](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_service_architecture_monolith_soa_microservice.html)
+ [SEC09-BP02 Impor a criptografia em trânsito](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_data_transit_encrypt.html)
**Documentos relacionados:**
+ [Práticas recomendadas de segurança para a VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html)
+ [Dicas de otimização de rede da AWS](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-network-optimization-tips/)
+ [Orientação para segurança de rede na AWS](https://aws.amazon.com/solutions/guidance/network-security-on-aws/)
+ [Proteger o tráfego de rede de saída da sua VPC na Nuvem AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/secure-outbound-network-traffic/welcome.html)
**Ferramentas relacionadas:**
+ [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/)
**Vídeos relacionados:**
+ [Arquiteturas de referência do AWS Transit Gateway para muitas VPCs](https://youtu.be/9Nikqn_02Oc)
+ [Aceleração e proteção de aplicações com Amazon CloudFront, AWS WAF e AWS Shield](https://youtu.be/0xlwLEccRe0)
+ [AWS re:Inforce 2023: Firewalls e onde colocá-los](https://www.youtube.com/watch?v=lTJxWAiQrHM)
# SEC05-BP03 Implementar proteção baseada em inspeção
Configure pontos de inspeção de tráfego entre as camadas de rede para garantir que os dados em trânsito correspondam aos padrões e categorias esperados. Analise padrões, metadados e fluxos de tráfego para ajudar a identificar, detectar e responder a eventos com maior eficiência.
**Resultado desejado:** o tráfego que passa entre suas camadas de rede é inspecionado e autorizado. As decisões de permissão e negação baseiam-se em regras explícitas, inteligência contra ameaças e desvios dos comportamentos de referência. As proteções tornam-se mais rígidas à medida que o tráfego aproxima-se dos dados confidenciais.
**Práticas comuns que devem ser evitadas:**
+ Confiar somente em regras de firewall baseadas em portas e protocolos. Não aproveitar os sistemas inteligentes.
+ Criar regras de firewall com base em padrões específicos de ameaças atuais que estão sujeitos a alterações.
+ Inspecionar somente o tráfego que transita de sub-redes privadas para públicas ou de sub-redes públicas para a internet.
+ Não ter uma visão de referência do tráfego da rede para comparar com anomalias de comportamento.
**Benefícios de implementar esta prática recomendada:** os sistemas de inspeção permitem que você crie regras inteligentes, como permitir ou negar tráfego somente quando houver determinadas condições nos dados de tráfego. Beneficie-se de conjuntos de regras gerenciados pela AWS e por parceiros, com base na inteligência contra ameaças mais recente, à medida que o cenário de ameaças muda ao longo do tempo. Isso reduz as despesas indiretas de manter regras e pesquisar indicadores de comprometimento, reduzindo o potencial de falsos positivos.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Mantenha um controle refinado sobre seu tráfego de rede com e sem estado usando o AWS Network Firewall ou outros [firewalls](https://aws.amazon.com/marketplace/search/results?searchTerms=firewalls) e [sistemas de prevenção de intrusões](https://aws.amazon.com/marketplace/search/results?searchTerms=Intrusion+Prevention+Systems) (IPS) no AWS Marketplace você pode implantar por trás de um [Gateway Load Balancer (GWLB)](https://aws.amazon.com/elasticloadbalancing/gateway-load-balancer/). O AWS Network Firewall oferece suporte a especificações IPS de código aberto [compatíveis com Suricata](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-ips.html) para ajudar a proteger sua workload.
Tanto o AWS Network Firewall quanto as soluções de fornecedor que usam um GWLB comportam diferentes modelos de implantação de inspeção em linha. Por exemplo, você pode realizar a inspeção por VPC, centralizar em uma VPC de inspeção ou implantar em um modelo híbrido em que o tráfego leste-oeste flui por meio de uma VPC de inspeção e a entrada da internet é inspecionada por VPC. Outra consideração é se a solução comporta o desempacotamento do Transport Layer Security (TLS), permitindo a inspeção detalhada de pacotes para fluxos de tráfego iniciados em qualquer direção. Para obter mais informações e detalhes sobre essas configurações, consulte o [Guia de práticas recomendadas do AWS Network Firewall](https://aws.github.io/aws-security-services-best-practices/guides/network-firewall/).
Se você usa soluções que realizam inspeções fora de banda, como análise pcap de dados de pacotes de interfaces de rede operando em modo promíscuo, é possível configurar o [espelhamento de tráfego de VPC](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html). O tráfego espelhado é computado na largura de banda disponível de suas interfaces e está sujeito às mesmas cobranças de transferência de dados que o tráfego não espelhado. É possível ver se as versões virtuais desses appliances estão disponíveis no [AWS Marketplace](https://aws.amazon.com/marketplace/solutions/infrastructure-software/cloud-networking), o que pode oferecer suporte à implantação em linha por trás de um GWLB.
Para componentes que operam por meio de protocolos baseados em HTTP, proteja sua aplicação contra ameaças comuns com um firewall de aplicações Web (WAF). O [AWS WAF](https://aws.amazon.com/waf) é um firewall de aplicações Web que permite monitorar e bloquear solicitações HTTP(S) que correspondem a suas regras configuráveis antes de enviar para o Amazon API Gateway, o Amazon CloudFront, o AWS AppSync ou um Application Load Balancer. Considere a inspeção detalhada de pacotes ao avaliar a implantação do firewall de aplicações Web, pois alguns exigem que você encerre o TLS antes da inspeção de tráfego. Para começar a usar o AWS WAF, é possível usar [AWS Managed Rules](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html#getting-started-wizard-add-rule-group) em combinação com as suas próprias regras ou usar as [integrações de parceiros](https://aws.amazon.com/waf/partners/) existentes.
Você pode gerenciar centralmente o AWS WAF, o AWS Shield Advanced, o AWS Network Firewall e os grupos de segurança da Amazon VPC em toda a sua organização da AWS com o [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/).
## Etapas de implementação
1. Determine se você pode definir um escopo amplo das regras de inspeção, como por meio de uma VPC de inspeção, ou se precisa de uma abordagem mais detalhada por VPC.
1. Para soluções de inspeção em linha:
1. Se estiver usando o AWS Network Firewall, crie regras, políticas de firewall e o próprio firewall. Após a configuração, você poderá [rotear o tráfego para o endpoint do firewall](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/) para permitir a inspeção.
1. Se estiver usando um appliance de terceiros com um Gateway Load Balancer (GWLB), implante e configure seu appliance em uma ou mais zonas de disponibilidade. Em seguida, crie o GWLB, o serviço de endpoint e o endpoint e configure o roteamento para o tráfego.
1. Para soluções de inspeção fora de banda:
1. Ative o espelhamento de tráfego da VPC em interfaces nas quais o tráfego de entrada e saída deve ser espelhado. É possível usar regras do Amazon EventBridge para invocar uma função do AWS Lambda que ative o espelhamento de tráfego em interfaces quando são criados recursos. Aponte as sessões de espelhamento de tráfego para o Network Load Balancer na frente do appliance que processa o tráfego.
1. Para soluções de tráfego da Web de entrada:
1. Para configurar o AWS WAF, primeiro configure uma lista de controle de acesso à web (ACL da web). A ACL da web é um conjunto de regras com uma ação padrão processada em série (permitir ou negar) que define como o WAF lida com o tráfego. Você pode criar seus próprios grupos e regras ou usar grupos de regras gerenciadas da AWS em sua ACL da Web.
1. Assim que a ACL da Web for configurada, ela poderá ser associada a um recurso da AWS (como um Application Load Balancer, uma API REST do API Gateway ou uma distribuição do CloudFront) para começar a proteger o tráfego da Web.
## Recursos
**Documentos relacionados:**
+ [O que é espelhamento de tráfego?](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html)
+ [Implementar a inspeção de tráfego em linha usando appliances de segurança de terceiros](https://docs.aws.amazon.com/prescriptive-guidance/latest/inline-traffic-inspection-third-party-appliances/welcome.html)
+ [Exemplos de arquiteturas do AWS Network Firewall com roteamento](https://docs.aws.amazon.com/network-firewall/latest/developerguide/architectures.html)
+ [Arquitetura de inspeção centralizada com o AWS Gateway Balancer e o AWS Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/)
**Exemplos relacionados:**
+ [Práticas recomendadas para implantar o balanceador de carga do gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/)
+ [Configuração de inspeção TLS para tráfego de saída criptografado e AWS Network Firewall](https://aws.amazon.com/blogs/security/tls-inspection-configuration-for-encrypted-egress-traffic-and-aws-network-firewall/)
**Ferramentas relacionadas:**
+ [AWS Marketplace IDS/IPS](https://aws.amazon.com/marketplace/search/results?prevFilters=%257B%2522id%2522%3A%25220ed48363-5064-4d47-b41b-a53f7c937314%2522%257D&searchTerms=ids%2Fips)
# SEC05-BP04 Automatizar a proteção da rede
Automatize a implantação de suas proteções de rede usando práticas de DevOps, como *infraestrutura como código* (IaC) e pipelines de CI/CD. Essas práticas podem ajudar você a monitorar alterações nas proteções da rede por meio de um sistema de controle de versão, reduzir o tempo necessário para implantar alterações e detectar se as proteções de rede se desviam da configuração desejada.
**Resultado desejado:** você define as proteções de rede com modelos e as compromete em um sistema de controle de versão. Quando novas alterações são feitas, os pipelines automatizados são iniciados para orquestrar os respectivos testes e a implantação. Verificações de políticas e outros testes estáticos estão em vigor para validar as alterações antes da implantação. Você implanta as alterações em um ambiente de preparação para validar se os controles estão operando conforme o esperado. A implantação nos ambientes de produção também é executada automaticamente quando os controles são aprovados.
**Práticas comuns que devem ser evitadas:**
+ Contar com equipes de workload individuais para que definam sua pilha de rede completa, proteções e automações. Não publicar os aspectos padrão da pilha de rede e das proteções de maneira centralizada para as equipes de workload consumirem.
+ Contar com uma equipe de rede central para definir todos os aspectos da rede, proteções e automações. Não delegar aspectos específicos da workload da pilha de rede e das proteções à equipe da workload em questão.
+ Conseguir o equilíbrio certo de centralização e delegação entre a equipe de rede e as equipes de workload, mas não aplicar padrões consistentes de teste e implantação aos modelos de IaC e pipelines de CI/CD. Não capturar as configurações necessárias em ferramentas que verificam a aderência aos modelos.
**Benefícios de implementar esta prática recomendada:** o uso de modelos para definir suas proteções de rede permite rastrear e comparar as alterações ao longo do tempo com um sistema de controle de versão. Usar automação para testar e implantar alterações gera padronização e previsibilidade, aumentando as chances de uma implantação bem-sucedida e reduzindo configurações manuais repetitivas.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Vários controles de proteção de rede descritos em [SEC05-BP02 Controlar fluxos de tráfego em suas camadas de rede](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_layered.html) e [SEC05-BP03 Implementar a proteção baseada em inspeção](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_inspection.html) são fornecidos com sistemas de regras gerenciados que podem ser atualizados automaticamente com base nas informações mais recentes sobre ameaças. Exemplos de proteção de seus endpoints da Web incluem [regras gerenciadas pelo AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups.html) e [mitigação de DDoS na camada de aplicações automática do AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-automatic-app-layer-response.html). Use [grupos de regras gerenciados pelo AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/nwfw-managed-rule-groups.html) para se manter atualizado com listas de domínios de baixa reputação e assinaturas de ameaças.
Além das regras gerenciadas, recomendamos usar práticas de DevOps para automatizar a implantação dos recursos de rede, das proteções e das regras que você especificar. Você pode capturar essas definições no [AWS CloudFormation](https://aws.amazon.com/cloudformation/) ou em outra ferramenta de *infraestrutura como código* (IaC) de sua escolha, confirmá-las em um sistema de controle de versão e implantá-las usando pipelines de CI/CD. Use essa abordagem para obter os benefícios tradicionais de DevOps para gerenciar seus controles de rede, como lançamentos mais previsíveis, testes automatizados usando ferramentas como o [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)e detecção de desvios entre o ambiente implantado e a configuração desejada.
Com base nas decisões tomadas como parte de [SEC05-BP01 Criar camadas de rede](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_create_layers.html), você pode adotar uma abordagem de gerenciamento central para criar VPCs dedicadas aos fluxos de entrada, saída e inspeção. Conforme descrito na [Arquitetura de referência de segurança da AWS (AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture), é possível definir essas VPCs em uma [conta de infraestrutura de rede](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html) dedicada. Você pode usar técnicas semelhantes para definir centralmente as VPCs usadas pelas workloads em outras contas, os respectivos grupos de segurança, as implantações do AWS Network Firewall, as regras do Route 53 Resolver, as configurações do firewall de DNS e outros recursos de rede. Você pode compartilhar esses recursos com suas outras contas com o [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html). Com essa abordagem, é possível simplificar os testes automatizados e a implantação dos controles de rede na conta de rede, o que resulta em apenas um destino para gerenciar. É possível fazer isso em um modelo híbrido no qual você implanta e compartilha determinados controles centralmente e delega outros controles às equipes individuais de workload e respectivas contas.
## Etapas de implementação
1. Estabeleça a propriedade para definir quais aspectos da rede e das proteções são definidos centralmente e quais as equipes de workload podem manter.
1. Crie ambientes para testar e implantar alterações na rede e nas respectivas proteções. Por exemplo, use uma conta de teste de rede e uma conta de produção de rede.
1. Determine como você armazenará e manterá os modelos em um sistema de controle de versão. Os modelos centrais podem ser armazenados em um repositório diferente dos repositórios de workload, enquanto os modelos de workload podem ser armazenados em repositórios específicos para essa workload.
1. Crie pipelines de CI/CD para testar e implantar modelos. Defina testes para verificar se há configurações incorretas e se os modelos estão de acordo com os padrões da sua empresa.
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC01-BP06 Automatizar a implantação de controles de segurança padrão](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls)
**Documentos relacionados:**
+ [Arquitetura de referência de segurança da AWS: Conta de rede](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html)
**Exemplos relacionados:**
+ [Arquitetura de referência do pipeline de implantação da AWS](https://pipelines.devops.aws.dev/)
+ [NetDevSecOps para modernizar as implantações de rede da AWS](https://aws.amazon.com/blogs/networking-and-content-delivery/netdevsecops-to-modernize-aws-networking-deployments/)
+ [Integrar testes de segurança do AWS CloudFormation com relatórios do AWS Security Hub CSPM e do AWS CodeBuild](https://aws.amazon.com/blogs/security/integrating-aws-cloudformation-security-tests-with-aws-security-hub-and-aws-codebuild-reports/)
**Ferramentas relacionadas:**
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
+ [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)
+ [cfn\$1nag](https://github.com/stelligent/cfn_nag)
# Proteção da computação
Os recursos de computação incluem instâncias do EC2, contêineres, funções do AWS Lambda, serviços de banco de dados, dispositivos de IoT e muito mais. Cada um desses tipos de recursos computacionais exige abordagens diferentes para protegê-los. No entanto, eles compartilham estratégias comuns que devem ser levadas em conta: defesa em profundidade, gerenciamento de vulnerabilidades, redução na superfície de ataque, automação da configuração e operação e execução de ações à distância. Nesta seção, você encontrará orientações gerais para proteger seus recursos computacionais para os principais serviços. Para cada serviço da AWS usado, é importante verificar as recomendações de segurança específicas na documentação do serviço.
**Topics**
+ [SEC06-BP01 Realizar o gerenciamento de vulnerabilidades](sec_protect_compute_vulnerability_management.md)
+ [SEC06-BP02 Provisionar computação com base em imagens reforçadas](sec_protect_compute_hardened_images.md)
+ [SEC06-BP03 Reduzir o gerenciamento manual e o acesso interativo](sec_protect_compute_reduce_manual_management.md)
+ [SEC06-BP04 Validar a integridade do software](sec_protect_compute_validate_software_integrity.md)
+ [SEC06-BP05 Automatizar a proteção da computação](sec_protect_compute_auto_protection.md)
# SEC06-BP01 Realizar o gerenciamento de vulnerabilidades
Verifique e corrija com frequência vulnerabilidades no código, nas dependências e na infraestrutura para se proteger contra novas ameaças.
**Resultado desejado:** você tem uma solução que verifica continuamente sua workload em busca de vulnerabilidades de software, possíveis defeitos e exposição não intencional da rede. Você estabeleceu processos e procedimentos para identificar, priorizar e corrigir essas vulnerabilidades com base nos critérios de avaliação de risco. Além disso, você implementou o gerenciamento automatizado de patches para suas instâncias computacionais. Seu programa de gerenciamento de vulnerabilidades é integrado ao seu ciclo de vida de desenvolvimento de software, com soluções para escanear seu código-fonte durante o pipeline de CI/CD.
**Práticas comuns que devem ser evitadas:**
+ Não ter um programa de gerenciamento de vulnerabilidades.
+ Realizar a aplicação de patches do sistema sem considerar a gravidade ou formas de evitar riscos.
+ Utilizar software que ultrapassou a data de fim de vida útil (EOL) indicada pelo fornecedor.
+ Implantar código em produção antes de analisar a existência de problemas de segurança.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
O gerenciamento de vulnerabilidades é um aspecto fundamental para manter um ambiente de nuvem seguro e robusto. Ele envolve um processo abrangente que inclui verificações de segurança, identificação e priorização de problemas e operações de correção para resolver as vulnerabilidades identificadas. A automação desempenha um papel fundamental nesse processo porque facilita a verificação contínua das workloads em busca de possíveis problemas e exposição não intencional da rede, bem como esforços de remediação.
O [Modelo de Responsabilidade Compartilhada da AWS](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/shared-responsibility.html) é um conceito fundamental que sustenta o gerenciamento de vulnerabilidades. De acordo com esse modelo, a AWS é responsável por proteger a infraestrutura subjacente, incluindo hardware, software, redes e instalações que executam os serviços da AWS. Por outro lado, você é responsável por proteger seus dados, configurações de segurança e tarefas de gerenciamento associadas a serviços como instâncias do Amazon EC2 e objetos do Amazon S3.
AWSA oferece diversos serviços para apoiar os programas de gerenciamento de vulnerabilidades. O [Amazon Inspector](https://aws.amazon.com/inspector/) verifica continuamente as workloads da AWS em busca de vulnerabilidades de software e acesso não intencional à rede, enquanto o [Gerenciador de Patches do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html) ajuda a gerenciar a aplicação de patches nas instâncias do Amazon EC2. Esses serviços podem ser integrados ao [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/), um serviço de gerenciamento da postura de segurança na nuvem que automatiza as verificações de segurança da AWS, centraliza os alertas de segurança e fornece uma visão abrangente da postura de segurança de uma organização. Além disso, o [Amazon CodeGuru Security](https://aws.amazon.com/codeguru/) usa análise estática de código para identificar possíveis problemas em aplicações Java e Python durante a fase de desenvolvimento.
Ao incorporar práticas de gerenciamento de vulnerabilidades ao ciclo de vida de desenvolvimento de software, você pode abordar as vulnerabilidades de forma proativa antes que elas sejam introduzidas nos ambientes de produção, o que reduz o risco de eventos de segurança e minimiza o impacto potencial das vulnerabilidades.
### Etapas de implementação
1. **Entenda o modelo de responsabilidade compartilhada:** revise o modelo de responsabilidade compartilhada da AWS para entender suas responsabilidades de proteger as workloads e os dados na nuvem. A AWS é responsável por proteger a infraestrutura de nuvem subjacente, enquanto você é responsável por proteger as aplicações, os dados e os serviços utilizados.
1. **Implemente a verificação de vulnerabilidades**: configure um serviço de verificação de vulnerabilidades, como o Amazon Inspector, para verificar automaticamente as instâncias de computação (por exemplo, máquinas virtuais, contêineres ou funções de tecnologia sem servidor) em busca de vulnerabilidades de software, possíveis defeitos e exposição não intencional da rede.
1. **Estabeleça processos de gerenciamento de vulnerabilidades:** defina processos e procedimentos para identificar, priorizar e corrigir vulnerabilidades. Isso pode incluir a configuração de cronogramas regulares de verificação de vulnerabilidades, o estabelecimento de critérios de avaliação de risco e a definição de cronogramas de remediação com base na gravidade da vulnerabilidade.
1. **Configure o gerenciamento de patches:** use um serviço de gerenciamento de patches para automatizar o processo de correção de suas instâncias de computação, tanto para sistemas operacionais quanto para aplicações. Você pode configurar o serviço para verificar as instâncias em busca de patches ausentes e instalá-las automaticamente de acordo com um cronograma. Considere o Gerenciador de Patches do AWS Systems Manager para fornecer essa funcionalidade.
1. **Configure a proteção contra malware:** implemente mecanismos para detectar software malicioso em seu ambiente. Por exemplo, você pode usar ferramentas como o [Amazon GuardDuty](https://aws.amazon.com/guardduty/) para analisar, detectar e alertar sobre malware em volumes EC2 e EBS. O GuardDuty também pode escanear objetos recém-enviados ao Amazon S3 em busca de possíveis malwares ou vírus e tomar medidas para isolá-los antes que sejam ingeridos em processos posteriores.
1. **Integre a verificação de vulnerabilidades em pipelines de CI/CD:** se você estiver usando um pipeline de CI/CD para a implantação da aplicação, integre ferramentas de verificação de vulnerabilidades em seu pipeline. Ferramentas como o Amazon CodeGuru Security e opções de código aberto podem escanear seu código-fonte, dependências e artefatos em busca de possíveis problemas de segurança.
1. **Configure um serviço de monitoramento de segurança:** configure um serviço de monitoramento de segurança, como o AWS Security Hub CSPM, para ter uma visão abrangente da postura de segurança em vários serviços de nuvem. O serviço deve coletar descobertas de segurança de várias fontes e apresentá-las em um formato padronizado para facilitar a priorização e a remediação.
1. **Implemente teste de penetração de aplicativos web**: se sua aplicação for um aplicativo web e sua organização tiver as habilidades necessárias ou puder contratar assistência externa, considere a implementação de teste de penetração do aplicativo web para identificar possíveis vulnerabilidades nele.
1. **Automatize com infraestrutura como código**: use ferramentas de infraestrutura como código (IaC), como [AWS CloudFormation](https://aws.amazon.com/cloudformation/), para automatizar a implantação e a configuração de seus recursos, incluindo os serviços de segurança mencionados anteriormente. Essa prática ajuda você a criar uma arquitetura de recursos mais consistente e padronizada em várias contas e ambientes.
1. **Monitore e melhore** continuamente: monitore continuamente a eficácia do seu programa de gerenciamento de vulnerabilidades e faça melhorias conforme necessário. Analise as descobertas de segurança, avalie a eficácia de seus esforços de remediação e ajuste seus processos e ferramentas adequadamente.
## Recursos
**Documentos relacionados:**
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [Visão geral da segurança do AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf)
+ [ Amazon CodeGuru ](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [ Gerenciamento de vulnerabilidades aprimorado e automatizado para workloads na nuvem com um novo Amazon Inspector ](https://aws.amazon.com/blogs/aws/improved-automated-vulnerability-management-for-cloud-workloads-with-a-new-amazon-inspector/)
+ [ Automatize o gerenciamento e a correção de vulnerabilidades na AWS usando o Amazon Inspector e o AWS Systems Manager: parte 1](https://aws.amazon.com/blogs/mt/automate-vulnerability-management-and-remediation-in-aws-using-amazon-inspector-and-aws-systems-manager-part-1/)
**Vídeos relacionados:**
+ [Proteger serviços com tecnologia sem servidor e em contêineres](https://youtu.be/kmSdyN9qiXY)
+ [Práticas recomendadas de segurança para o serviço de metadados da instância do Amazon EC2](https://youtu.be/2B5bhZzayjI)
# SEC06-BP02 Provisionar computação com base em imagens reforçadas
Ofereça menos oportunidades de acesso indesejado aos ambientes de runtime implantando-os com base em imagens reforçadas. Adquira somente dependências de runtime, como imagens de contêiner e bibliotecas de aplicações, de registros confiáveis e verifique as respectivas assinaturas. Crie seus próprios registros privados para armazenar imagens e bibliotecas confiáveis para uso nos processos de criação e implantação.
**Resultado desejado:** seus recursos computacionais são provisionados a partir de imagens de referência reforçadas. Você recupera dependências externas, como imagens de contêiner e bibliotecas de aplicações, somente de registros confiáveis e verifica as respectivas assinaturas. Elas são armazenadas em registros privados para que seus processos de compilação e implantação as consultem. Você verifica e atualiza imagens e dependências regularmente para ajudar a oferecer proteção contra qualquer vulnerabilidade recém-descoberta.
**Práticas comuns que devem ser evitadas:**
+ Adquirir imagens e bibliotecas de registros confiáveis, mas não verificar a respectiva assinatura nem realizar verificações de vulnerabilidades antes de colocá-las em uso.
+ Reforçar as imagens, mas não testá-las regularmente em busca de novas vulnerabilidades ou atualizá-las para a versão mais recente.
+ Instalar ou não remover pacotes de software que não são necessários durante o ciclo de vida previsto da imagem.
+ Confiar apenas na aplicação de patches para manter os recursos de computação de produção atualizados. Ao utilizar apenas a aplicação de patches, os recursos de computação podem se desviar do padrão reforçado com o passar do tempo. A aplicação de patches também pode não conseguir remover malware instalado por um agente de ameaças durante um evento de segurança.
**Benefícios de implementar esta prática recomendada:** o reforço de imagens ajuda a reduzir o número de caminhos disponíveis em seu ambiente de runtime que podem permitir acesso não intencional a usuários ou serviços não autorizados. Ele também pode reduzir o escopo do impacto caso ocorra algum acesso indesejado.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Para reforçar seus sistemas, comece com as versões mais recentes de sistemas operacionais, imagens de contêiner e bibliotecas de aplicações. Aplique patches aos problemas conhecidos. Minimize o sistema removendo quaisquer aplicações, serviços, drivers de dispositivo, usuários padrão e outras credenciais desnecessários. Execute qualquer outra ação necessária, como desabilitar portas para criar um ambiente que tenha somente os recursos e capacidades essenciais para as workloads. Com base nesse parâmetro, você pode instalar software, agentes ou outros processos necessários para finalidades como monitoramento da workload ou gerenciamento de vulnerabilidades.
É possível reduzir a carga de reforçar os sistemas usando orientações fornecidas por fontes confiáveis, como o [Center for Internet Security](https://www.cisecurity.org/) (CIS) e os [Guias de implementação técnica de segurança (STIGs)](https://public.cyber.mil/stigs/) da Defense Information Systems Agency (DISA). Recomendamos começar com uma [imagem de máquina da Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) (AMI) publicada pela AWS ou um parceiro da APN e use o AWS [EC2 Image Builder](https://aws.amazon.com/image-builder/) para automatizar a configuração de acordo com uma combinação apropriada de controles CIS e STIG.
Embora existam imagens reforçadas e fórmulas do EC2 Image Builder disponíveis que aplicam as recomendações do CIS ou do STIG da DISA, talvez você veja que sua configuração impede que seu software seja executado com êxito. Nessa situação, você pode começar com uma imagem base não reforçada, instalar o software e, em seguida, aplicar incrementalmente os controles do CIS para testar o respectivo impacto. Com relação a qualquer controle do CIS que impeça a execução do software, teste se é possível implementar as recomendações de fortalecimento mais refinadas em um STIG da DISA. Acompanhe os diferentes controles do CIS e as configurações do STIG da DISA que você pode aplicar com sucesso. Use-os para definir adequadamente suas fórmulas de reforço de imagem no EC2 Image Builder.
Para workloads em contêineres, imagens reforçadas do Docker estão disponíveis no [repositório público](https://gallery.ecr.aws/docker) do [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/). Você pode usar o EC2 Image Builder para reforçar imagens de contêiner, bem como AMIs.
Semelhante aos sistemas operacionais e às imagens de contêiner, você pode obter pacotes de código (ou *bibliotecas*) de repositórios públicos por meio de ferramentas como pip, npm, Maven e NuGet. Recomendamos gerenciar pacotes de código integrando repositórios privados, como os do [AWS CodeArtifact](https://aws.amazon.com/codeartifact/), a repositórios públicos confiáveis. Com essa integração, você não precisa se preocupar em lidar com a recuperação, o armazenamento e a manutenção de pacotes atualizados. Seus processos de criação de aplicações podem então obter e testar a versão mais recente desses pacotes, bem como a aplicação, usando técnicas como análise de composição de software (SCA), testes estáticos de segurança de aplicações (SAST) e testes dinâmicos de segurança de aplicações (DAST).
Para workloads sem servidor que usam o AWS Lambda, simplifique o gerenciamento de dependências de pacotes usando [camadas do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html). Use camadas do Lambda para configurar um conjunto de dependências padrão que são compartilhadas em diferentes funções em um arquivo independente. Você pode criar e manter camadas por meio de seu próprio processo de criação, fornecendo um meio centralizado para manter as funções atualizadas.
## Etapas de implementação
+ Reforce os sistemas operacionais. Use imagens básicas de fontes confiáveis como base para criar AMIs reforçadas. Use o [EC2 Image Builder](https://aws.amazon.com/image-builder/) para ajudar a personalizar o software instalado em suas imagens.
+ Reforce os recursos em contêineres. Configure recursos em contêineres para atender a práticas recomendadas de segurança. Ao usar contêineres, implemente a [varredura de imagens do ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html) no pipeline de compilação e regularmente no repositório de imagens para procurar CVEs nos contêineres.
+ Ao usar a implementação sem servidor com o AWS Lambda, use [camadas do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html) para separar o código da função da aplicação e as bibliotecas dependentes compartilhadas. Configure a [assinatura de código](https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html) para Lambda para garantir que apenas código confiável seja executado em suas funções do Lambda.
## Recursos
**Práticas recomendadas relacionadas:**
+ [OPS05-BP05 Realizar o gerenciamento de patches](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_dev_integ_patch_mgmt.html)
**Vídeos relacionados:**
+ [Mergulho profundo na segurança do AWS Lambda](https://www.youtube.com/watch?v=FTwsMYXWGB0)
**Exemplos relacionados:**
+ [Criar rapidamente uma AMI compatível com STIG usando o EC2 Image Builder](https://aws.amazon.com/blogs/security/quickly-build-stig-compliant-amazon-machine-images-using-amazon-ec2-image-builder/)
+ [Criar imagens de contêiner melhores](https://aws.amazon.com/blogs/containers/building-better-container-images/)
+ [Usar camadas do Lambda para simplificar seu processo de desenvolvimento](https://aws.amazon.com/blogs/compute/using-lambda-layers-to-simplify-your-development-process/)
+ [Desenvolver e implantar camadas do AWS Lambda usando um framework sem servidor](https://github.com/aws-samples/aws-serverless-lambda-layers)
+ [Criar um pipeline de CI/CD completo do AWS DevSecOps com ferramentas de código aberto SCA, SAST e DAST](https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/)
# SEC06-BP03 Reduzir o gerenciamento manual e o acesso interativo
Use a automação para realizar tarefas de implantação, configuração, manutenção e investigação sempre que possível. Considere usar o acesso manual aos recursos de computação em casos de procedimentos de emergência ou em ambientes seguros (sandbox) quando a automação não estiver disponível.
**Resultado desejado:** scripts programáticos e documentos de automação (runbooks) capturam ações autorizadas em seus recursos computacionais. Os runbooks são iniciados automaticamente por meio de sistemas de detecção de alterações ou manualmente quando a avaliação humana é necessária. O acesso direto aos recursos de computação só é disponibilizado em situações de emergência quando a automação não está disponível. Todas as atividades manuais são registradas em log e incorporadas a um processo de análise para aprimorar continuamente os recursos de automação.
**Práticas comuns que devem ser evitadas:**
+ Usar o acesso interativo a instâncias do Amazon EC2 com protocolos como SSH ou RDP.
+ Manter logins de usuários individuais, como `/etc/passwd` ou usuários locais do Windows.
+ Compartilhar uma senha ou chave privada para acessar uma instância entre vários usuários.
+ Instalar software e criar ou atualizar manualmente arquivos de configuração.
+ Atualizar ou aplicar patches manualmente no software.
+ Fazer login em uma instância para solucionar problemas.
**Benefícios de implementar esta prática recomendada:** a execução de ações com automação ajuda a reduzir o risco operacional de alterações não intencionais e configurações incorretas. Eliminar o uso do Secure Shell (SSH) e do Remote Desktop Protocol (RDP) para acesso interativo reduz o escopo do acesso aos seus recursos de computação. Fazer isso elimina um caminho comum para ações não autorizadas. Capturar suas tarefas de gerenciamento de recursos de computação em documentos de automação e scripts programáticos oferece um mecanismo para definir e auditar todo o escopo das atividades autorizadas em um nível de detalhes refinado.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Fazer login em uma instância é uma abordagem clássica à administração de sistemas. Após a instalação do sistema operacional do servidor, os usuários normalmente fazem login manualmente para configurar o sistema e instalar o software desejado. Durante o ciclo de vida do servidor, os usuários podem fazer login para realizar atualizações de software, aplicar patches, alterar configurações e solucionar problemas.
No entanto, o acesso manual apresenta vários riscos. Ele exige um servidor que escuta solicitações, como um serviço SSH ou RDP, o que pode fornecer um possível caminho para acessos não autorizados. Ele também aumenta o risco de erro humano associado à execução de etapas manuais. Isso pode resultar em incidentes de workload, corrompimento ou destruição de dados ou outros problemas de segurança. O acesso humano também exige proteções contra o compartilhamento de credenciais, o que cria uma sobrecarga adicional de gerenciamento.
Para mitigar esses riscos, você pode implementar uma solução de acesso remoto baseada em agente, como o [AWS Systems Manager](https://aws.amazon.com/systems-manager/). AWS Systems Manager O agente (SSM Agent) inicia um canal criptografado e, portanto, não depende da escuta de solicitações iniciadas externamente. Considere configurar o SSM Agent para [estabelecer esse canal em um endpoint da VPC](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html).
O Systems Manager oferece controle refinado sobre como você pode interagir com suas instâncias gerenciadas. Você define as automações a serem executadas, quem pode executá-las e quando elas podem ser executadas. O Systems Manager pode aplicar patches, instalar software e fazer alterações na configuração sem ter acesso interativo à instância. O Systems Manager também pode fornecer acesso a um shell remoto e registrar cada comando invocado e sua saída durante a sessão nos logs e no [Amazon S3](https://aws.amazon.com/s3/). O [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) registra as invocações das APIs do Systems Manager para inspeção.
### Etapas de implementação
1. [Instale o AWS Systems Manager Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) (SSM Agent) nas suas instâncias do Amazon EC2. Verifique se o SSM Agent está incluído e foi iniciado automaticamente como parte da configuração básica da AMI.
1. Verifique se as funções do IAM associadas aos seus perfis de instância do EC2 incluem a [política `AmazonSSMManagedInstanceCore` gerenciada pelo IAM](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html).
1. Desabilite o SSH, o RDP e outros serviços de acesso remoto em execução nas instâncias. Você pode fazer isso executando scripts configurados na seção de dados do usuário dos seus modelos de lançamento ou criando AMIs personalizadas com ferramentas como o EC2 Image Builder.
1. Verifique se as regras de entrada do grupo de segurança aplicáveis às instâncias do EC2 não permitem acesso na porta 22/tcp (SSH) ou na porta 3389/tcp (RDP). Implemente a detecção e o alerta de grupos de segurança configurados incorretamente usando serviços como o AWS Config.
1. Defina automações, runbooks e comandos de execução apropriados no Systems Manager. Use políticas do IAM para definir quem pode realizar essas ações e as condições sob as quais elas são permitidas. Teste essas automações minuciosamente em um ambiente de não produção. Invoque essas automações quando necessário, em vez de acessar a instância de forma interativa.
1. Use o [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) para fornecer acesso interativo às instâncias quando necessário. Ative o log de atividades da sessão para manter uma trilha de auditoria no [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) ou no [Amazon S3](https://aws.amazon.com/s3/).
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL08-BP04 Implantar usando infraestrutura imutável](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_tracking_change_management_immutable_infrastructure.html)
**Exemplos relacionados:**
+ [Substituir o acesso SSH para reduzir a sobrecarga de gerenciamento e segurança com o AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/)
**Ferramentas relacionadas:**
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
**Vídeos relacionados:**
+ [Controlar o acesso da sessão do usuário à instâncias no Gerenciador de Sessões do AWS Systems Manager](https://www.youtube.com/watch?v=nzjTIjFLiow)
# SEC06-BP04 Validar a integridade do software
Use a verificação criptográfica para validar a integridade dos artefatos de software (incluindo imagens) que a workload usa. Assine criptograficamente seu software como uma proteção contra alterações não autorizadas executadas em seus ambientes de computação.
**Resultado desejado:** todos os artefatos são obtidos de fontes confiáveis. Os certificados do site do fornecedor são validados. Os artefatos baixados são verificados criptograficamente com base na respectiva assinatura. Seu próprio software é assinado e verificado criptograficamente por seus ambientes de computação.
**Práticas comuns que devem ser evitadas:**
+ Confiar em sites de fornecedores de boa reputação para obter artefatos de software, mas ignorar os avisos de expiração de certificado. Prosseguir com os downloads sem confirmar se os certificados são válidos.
+ Validar certificados de sites de fornecedores, mas não verificar criptograficamente os artefatos baixados desses sites.
+ Confiar apenas em resumos ou hashes para validar a integridade do software. Os hashes estabelecem que os artefatos não foram modificados da versão original, mas não validam a respectiva fonte.
+ Não assinar seu próprio software, código ou biblioteca, mesmo quando usados apenas em suas próprias implantações.
**Benefícios de implementar esta prática recomendada:** validar a integridade dos artefatos dos quais sua workload depende ajuda a impedir a entrada de malware em seus ambientes computacionais. Assinar seu software ajuda a impedir a execução não autorizada em seus ambientes de computação. Proteja sua cadeia de suprimentos de software assinando e verificando o código.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
As imagens do sistema operacional, as imagens de contêiner e os artefatos de código geralmente são distribuídos com verificações de integridade disponíveis, como por meio de um resumo ou hash. Isso permite que os clientes verifiquem a integridade calculando o hash da carga útil e validando se ele é o mesmo que o publicado. Embora essas verificações ajudem a verificar se a carga não foi adulterada, elas não validam que a carga veio da fonte original (sua *procedência*). A verificação de procedência exige um certificado emitido por uma autoridade confiável para assinar o artefato digitalmente.
Se você estiver usando um software ou artefatos baixados na workload, verifique se o provedor fornece uma chave pública para verificação de assinatura digital. Veja alguns exemplos de como a AWS fornece uma chave pública e instruções de verificação para o software que publicamos:
+ [EC2 Image Builder: verificar a assinatura do download da instalação do AWS TOE](https://docs.aws.amazon.com/imagebuilder/latest/userguide/awstoe-verify-sig.html)
+ [AWS Systems Manager: verificar a assinatura do SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/verify-agent-signature.html)
+ [Amazon CloudWatch: verificar a assinatura do pacote do agente do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/verify-CloudWatch-Agent-Package-Signature.html)
Incorpore a verificação de assinatura digital aos processos que você usa para obter e reforçar imagens, conforme discutido em [SEC06-BP02 Provisionar a computação com base em imagens reforçadas](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_hardened_images.html).
Você pode usar o [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) para ajudar a gerenciar a verificação de assinaturas, bem como seu próprio ciclo de vida de assinatura de código para seu próprio software e artefatos. Tanto o [AWS Lambda](https://aws.amazon.com/lambda/) quanto o [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) fornecem integrações com o Signer para verificar as assinaturas do seu código e imagens. Usando os exemplos na seção “Recursos”, você pode incorporar o Signer aos pipelines de integração e entrega contínuas (CI/CD) para automatizar a verificação de assinaturas e a assinatura de código e imagens.
## Recursos
**Documentos relacionados:**
+ [Assinatura criptográfica para contêineres](https://aws.amazon.com/blogs/containers/cryptographic-signing-for-containers/)
+ [Práticas recomendadas para ajudar a proteger sua imagem de contêiner: crie um pipeline usando AWS Signer](https://aws.amazon.com/blogs/security/best-practices-to-help-secure-your-container-image-build-pipeline-by-using-aws-signer/)
+ [Assinatura de imagens de contêineres com o AWS Signer e o Amazon EKS](https://aws.amazon.com/blogs/containers/announcing-container-image-signing-with-aws-signer-and-amazon-eks/)
+ [Configurar a assinatura de código para o AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html)
+ [Práticas recomendadas e padrões avançados para assinatura de código do Lambda](https://aws.amazon.com/blogs/security/best-practices-and-advanced-patterns-for-lambda-code-signing/)
+ [Assinatura de código usando CA privada do AWS Certificate Manager e chaves assimétricas do AWS Key Management Service](https://aws.amazon.com/blogs/security/code-signing-aws-certificate-manager-private-ca-aws-key-management-service-asymmetric-keys/)
**Exemplos relacionados:**
+ [Automatizar a assinatura de código do Lambda com o Amazon CodeCatalyst e o AWS Signer](https://aws.amazon.com/blogs/devops/automate-lambda-code-signing-with-amazon-codecatalyst-and-aws-signer/)
+ [Assinar e validar artefatos OCI com o AWS Signer](https://aws.amazon.com/blogs/containers/signing-and-validating-oci-artifacts-with-aws-signer/)
**Ferramentas relacionadas:**
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html)
+ [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/)
+ [AWS Key Management Service](https://aws.amazon.com/kms/)
+ [AWS CodeArtifact](https://aws.amazon.com/codeartifact/)
# SEC06-BP05 Automatizar a proteção da computação
Automatize as operações de proteção da computação para reduzir a necessidade de intervenção humana. Use a verificação automatizada para detectar possíveis problemas em seus recursos de computação e corrigir com respostas programáticas automatizadas ou operações de gerenciamento de frota. Incorpore a automação em seus processos de CI/CD para implantar workloads confiáveis com dependências atualizadas.
**Resultado desejado:** sistemas automatizados realizam todas as verificações e correções dos recursos computacionais. Você usa a verificação automatizada para determinar se as imagens e dependências do software são provenientes de fontes confiáveis e não foram adulteradas. As workloads são verificadas automaticamente em busca de dependências atualizadas e assinadas para estabelecer a confiabilidade em ambientes computacionais da AWS. As correções automatizadas são iniciadas quando recursos fora de conformidade são detectados.
**Práticas comuns que devem ser evitadas:**
+ Seguir a prática de infraestrutura imutável, mas sem ter uma solução para correção emergencial ou substituição de sistemas de produção.
+ Usar a automação para corrigir recursos configurados incorretamente, mas sem ter um mecanismo de substituição manual instalado. Podem surgir situações em que você precise ajustar os requisitos e suspender as automações até fazer essas alterações.
**Benefícios de implementar esta prática recomendada:** a automação pode reduzir o risco de acesso e uso não autorizados de seus recursos computacionais. Isso ajuda a evitar que configurações incorretas entrem nos ambientes de produção e a detectar e corrigir configurações incorretas caso elas ocorram. A automação também ajuda a detectar acesso e uso não autorizados de recursos de computação para reduzir o tempo de resposta. Isso, por sua vez, pode reduzir o escopo geral do impacto do problema.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
É possível aplicar as automações descritas nas práticas do pilar de segurança para proteger seus recursos de computação. [SEC06-BP01 Realizar o gerenciamento de vulnerabilidades](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_vulnerability_management.html) descreve como você pode usar o [Amazon Inspector](https://aws.amazon.com/inspector/) em seus pipelines de CI/CD e para verificar continuamente seus ambientes de runtime em busca de vulnerabilidades e exposições comuns (CVEs) conhecidas. Você pode usar o [AWS Systems Manager](https://aws.amazon.com/systems-manager/) para aplicar patches ou reimplantar com base em novas imagens por meio de runbooks automatizados para manter sua frota computacional atualizada com o software e as bibliotecas mais recentes. Use essas técnicas para reduzir a necessidade de processos manuais e acesso interativo aos seus recursos de computação. Consulte [SEC06-BP03 Reduzir o gerenciamento manual e o acesso interativo](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_reduce_manual_management.html) para saber mais.
A automação também desempenha um papel na implantação de workloads confiáveis, descritas em [SEC06-BP02 Provisionar computação com base em imagens reforçadas](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_hardened_images.html) e [SEC06-BP04 Validar a integridade do software](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_validate_software_integrity.html). É possível usar serviços como [EC2 Image Builder](https://aws.amazon.com/image-builder/), [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html), [AWS CodeArtifact](https://aws.amazon.com/codeartifact/) e [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) para baixar, verificar, construir e armazenar imagens reforçadas e aprovadas e dependências de código. Com o Inspector, cada um desses serviços pode desempenhar um papel no processo de CI/CD, de forma que a workload chegue à produção somente quando for confirmado que suas dependências estão atualizadas e provêm de fontes confiáveis. Sua workload também é assinada para que ambientes computacionais da AWS, como [AWS Lambda](https://aws.amazon.com/lambda/) e [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/), possam verificar se ela não foi adulterada antes de permitir sua execução.
Além desses controles preventivos, você também pode usar a automação nos controles de detecção para seus recursos de computação. Como exemplo, o [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/)oferece o padrão [NIST 800-53 Rev. 5](https://docs.aws.amazon.com/securityhub/latest/userguide/nist-standard.html), que inclui verificações como [[EC2.8] As instâncias do EC2 devem usar o Instance Metadata Service Version 2 (IMDSv2)](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-8). O IMDSv2 usa as técnicas de autenticação de sessão, bloqueando solicitações que contêm um cabeçalho HTTP X-Forwarded-For e um TTL de rede de 1 para interromper o tráfego proveniente de fontes externas e recuperar informações sobre a instância do EC2. Essa verificação no Security Hub CSPM pode detectar quando as instâncias do EC2 usam o IMDSv1 e iniciar a autocorreção. Saiba mais sobre detecção e remediações automatizadas em [SEC04-BP04 Iniciar a correção para recursos fora de conformidade](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_detect_investigate_events_noncompliant_resources.html).
### Etapas de implementação
1. [Automatize a criação de AMIs seguras, em conformidade e reforçadas com o EC2 Image Builder.](https://docs.aws.amazon.com/imagebuilder/latest/userguide/integ-compliance-products.html) Você pode produzir imagens que incorporem controles dos padrões de referência do Center for Internet Security (CIS) ou do Security Technical Implementation Guide (STIG) com base em imagens básicas da AWS e de parceiros da APN.
1. Automatize o gerenciamento de configuração. Aplique e valide configurações seguras automaticamente em seus recursos de computação usando um serviço ou uma ferramenta de gerenciamento de configuração.
1. Gerenciamento automatizado de configurações usando o [AWS Config](https://aws.amazon.com/config/)
1. Gerenciamento automatizado da postura de segurança e conformidade usando o [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/)
1. Automatize a aplicação de patches ou a substituição de instâncias do Amazon Elastic Compute Cloud (Amazon EC2). AWS O Gerenciador de Patches do Systems Manager automatiza o processo de aplicação de patches em instâncias gerenciadas com atualizações relacionadas à segurança e com outros tipos de atualizações. Você pode usar o Patch Manager para aplicar patches de sistemas operacionais e aplicações.
1. [Gerenciador de patches do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
1. Automatize a verificação de recursos de computação em busca de vulnerabilidades e exposições comuns (CVEs) e incorpore soluções de verificação de segurança em seu pipeline de criação.
1. [Amazon Inspector](https://aws.amazon.com/inspector/)
1. [Verificação de imagens do ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html)
1. Considere o Amazon GuardDuty para detecção automática de malware e ameaças para proteger os recursos computacionais. O GuardDuty também pode identificar possíveis problemas quando uma função do [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) é invocada em seu ambiente da AWS.
1. [Amazon GuardDuty](https://aws.amazon.com/guardduty/)
1. Considere as soluções dos parceiros da AWS. AWS Os parceiros oferecem produtos líderes do setor que são equivalentes, idênticos ou se integram aos controles existentes nos seus ambientes on-premises. Esses produtos complementam os serviços existentes da AWS para que você possa implantar uma arquitetura de segurança abrangente e obter uma experiência mais uniforme em seus ambientes na nuvem e on-premises.
1. [Segurança da infraestrutura](https://aws.amazon.com/security/partner-solutions/#infrastructure_security)
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC01-BP06 Automatizar a implantação de controles de segurança padrão](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls.html)
**Documentos relacionados:**
+ [Obtenha todos os benefícios do IMDSv2 e desative o IMDSv1 em sua infraestrutura da AWS](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure/)
**Vídeos relacionados:**
+ [Práticas recomendadas de segurança para o serviço de metadados da instância do Amazon EC2](https://youtu.be/2B5bhZzayjI)