As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
SEC05-BP01 Crie 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 da sua rede fazem parte de uma defense-in-depth abordagem integral de segurança que complementa a estratégia de autenticação e autorização de identidade de suas cargas de trabalho. 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 rede VPC ou em uma 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 sub-redes como padrões para todas as considerações da camada de rede e não considera como os serviços AWS gerenciados 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
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 ou até mesmo diferentes VPCs em diferentes Contas da AWS para cada nível de sensibilidade de dados Conta da AWS, 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 projeto, considere como o uso de serviços AWS gerenciados influencia sua topologia de rede. Explore como serviços como o Amazon VPC Lattice
Etapas de implementação
-
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.
-
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
, Elastic Load Balancing, AWS Amplify e hospedando endpoints públicos. -
Para componentes executados em ambientes computacionais, como EC2 instâncias da Amazon, AWS Fargate
contêineres ou funções Lambda, implante-os em sub-redes privadas com base em seus grupos desde a primeira etapa. -
Para AWS serviços totalmente gerenciados, como Amazon DynamoDB
, Amazon Kinesis ou SQSAmazon , considere VPC usar endpoints como padrão para acesso por endereços IP privados.
Recursos
Práticas recomendadas relacionadas:
Vídeos relacionados:
Exemplos relacionados:
