# 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)