SEC09-BP03 Autenticar as comunicações de rede - Pilar de segurança
Orientação para implementaçãoRecursos

SEC09-BP03 Autenticar as comunicações de rede

Verifique a identidade das comunicações usando protocolos que oferecem suporte à autenticação, como Transport Layer Security (TLS) ou IPsec.

Projete a workload para usar protocolos de rede seguros e autenticados sempre que uma comunicação entre serviços, aplicações ou usuários for feita. O uso de protocolos de rede compatíveis com a autenticação e a autorização fornece maior controle sobre os fluxos de rede e reduz o impacto causado por acessos não autorizados.

Resultado desejado: uma workload com fluxos de tráfego de plano de dados e ambiente de gerenciamento bem definidos entre os serviços. Os fluxos de tráfego usam protocolos de rede autenticados e criptografados quando tecnicamente viável.

Práticas comuns que devem ser evitadas:

  • Fluxos de tráfego não criptografados ou não autenticados na workload.

  • Reutilizar credenciais de autenticação em vários usuários ou entidades.

  • Confiar apenas nos controles de rede como um mecanismo de controle de acesso.

  • Criar um mecanismo de autenticação personalizado em vez de depender de mecanismos de autenticação padrão do setor.

  • Fluxos de tráfego excessivamente permissivos entre componentes de serviço ou outros recursos na VPC.

Benefícios de implementar esta prática recomendada:

  • Limita o escopo do impacto do acesso não autorizado a uma parte da workload.

  • Fornece um nível mais alto de garantia de que as ações são executadas somente por entidades autenticadas.

  • Melhora o desacoplamento de serviços definindo e aplicando claramente as interfaces de transferência de dados pretendidas.

  • Melhora o monitoramento, o log e a resposta a incidentes por meio da atribuição de solicitações e interfaces de comunicação bem definidas.

  • Oferece defesa profunda para as workloads combinando controles de rede com controles de autenticação e de autorização.

Nível de risco exposto se esta prática recomendada não for estabelecida: Baixo

Orientação para implementação

Os padrões de tráfego de rede da workload podem ser caracterizados em duas categorias:

  • O tráfego leste-oeste representa fluxos de tráfego entre serviços que compõem uma workload.

  • O tráfego norte-sul representa fluxos de tráfego entre a workload e os consumidores.

Embora seja uma prática comum criptografar o tráfego norte-sul, é menos comum proteger o tráfego leste-oeste usando protocolos autenticados. As práticas modernas de segurança recomendam que o design da rede por si só não conceda um relacionamento confiável entre duas entidades. Quando dois serviços podem residir dentro de um limite de rede comum, criptografar, autenticar e autorizar as comunicações ainda são práticas recomendadas entre esses serviços.

Como exemplo, as APIs de serviço da AWS usam o protocolo de assinatura AWS Signature Version 4 (SigV4) para autenticar o chamador, independentemente da rede de origem da solicitação. Essa autenticação garante que as APIs da AWS possam verificar a identidade que solicitou a ação e que essa identidade possa ser combinada com políticas para tomar uma decisão de autorização a fim de determinar se a ação deve ser permitida ou não.

Serviços como o Amazon VPC Lattice e o Amazon API Gateway permitem que você use o mesmo protocolo de assinatura SigV4 para adicionar autenticação e autorização ao tráfego leste-oeste em suas próprias workloads. Se recursos fora do seu ambiente da AWS precisarem se comunicar com serviços que exigem autenticação e autorização baseadas em SIGV4, é possível usar o AWS Identity and Access Management (IAM) Roles Anywhere no recurso externo à AWS para adquirir credenciais temporárias da AWS. Essas credenciais podem ser usadas para assinar solicitações para serviços que usam o SigV4 para autorizar o acesso.

Outro mecanismo comum para autenticar o tráfego leste-oeste é a autenticação mútua TLS (mTLS). Muitas aplicações da Internet das Coisas (IoT), aplicações business to business e microsserviços usam o mTLS para validar a identidade de ambos os lados de uma comunicação TLS por meio do uso de certificados X.509 do lado do cliente e do servidor. Esses certificados podem ser emitidos pela AWS Private Certificate Authority (AWS Private CA). Você pode usar serviços como o Amazon API Gateway e o AWS App Mesh para fornecer autenticação mTLS para comunicação entre workloads ou dentro de uma mesma workload. Embora o mTLS forneça informações de autenticação aos dois lados de uma comunicação TLS, ele não fornece um mecanismo de autorização.

Por fim, o OAuth 2.0 e o OpenID Connect (OIDC) são dois protocolos normalmente usados para controlar o acesso dos usuários aos serviços, mas agora também estão se tornando populares para o tráfego entre serviços. O API Gateway fornece um autorizador JSON Web Token (JWT), permitindo que as workloads restrinjam o acesso às rotas de API usando JWTs emitidos por provedores de identidade OIDC ou OAuth 2.0. Os escopos do OAuth2 podem ser usados como uma fonte para decisões básicas de autorização, mas as verificações de autorização ainda precisam ser implementadas na camada da aplicação, e os escopos do OAuth2 em si não atendem a necessidades de autorização mais complexas.

Etapas de implementação

  • Defina e documente seus fluxos de rede de workload: a primeira etapa na implementação de uma estratégia de defesa aprofundada é definir os fluxos de tráfego da sua workload.

    • Crie um diagrama de fluxo de dados que defina claramente como os dados são transmitidos entre os diferentes serviços que compõem a workload. Esse diagrama é a primeira etapa para aplicar esses fluxos por meio de canais de rede autenticados.

    • Instrumente a workload nas fases de desenvolvimento e testes para validar se o diagrama de fluxo de dados reflete com precisão o comportamento da workload em tempo de execução.

    • Um diagrama de fluxo de dados também pode ser útil ao realizar uma simulação de modelagem de ameaças, conforme descrito em SEC01-BP07 Identificar ameaças e priorizar mitigações usando um modelo de ameaça.

  • Estabeleça controles de rede: considere os recursos da AWS para estabelecer controles de rede alinhados aos seus fluxos de dados. Embora os limites da rede não devam ser o único controle de segurança, eles fornecem uma camada na estratégia de defesa profunda para proteger a workload.

    • Use grupos de segurança para estabelecer, definir e restringir fluxos de dados entre recursos.

    • Considere usar o AWS PrivateLink para se comunicar com a AWS e com serviços de terceiros compatíveis com o AWS PrivateLink. Os dados enviados por meio de um endpoint da interface do AWS PrivateLink permanecem na estrutura da rede da AWS e não atravessam a Internet pública.

  • Implemente autenticação e autorização em todos os serviços em sua workload: escolha o conjunto de serviços da AWS mais adequado para fornecer fluxos de tráfego autenticados e criptografados em sua workload.

  • Monitore o acesso não autorizado: monitore continuamente canais de comunicação não intencionais, entidades principais não autorizadas tentando acessar recursos protegidos e outros padrões de acesso impróprios.

    • Se estiver usando o VPC Lattice para gerenciar o acesso aos seus serviços, considere habilitar e monitorar os logs de acesso do VPC Lattice. Esses logs de acesso incluem informações sobre a entidade solicitante, informações de rede que incluem a VPC de origem e de destino e os metadados da solicitação.

    • Considere habilitar os Logs de fluxo da VPC para capturar metadados em fluxos de rede e analisar periodicamente se há anomalias.

    • Consulte o Guia de resposta a incidentes de segurança da AWS e a seção Resposta a Incidentes do pilar Segurança do AWS Well-Architected Framework para obter mais orientações sobre planejamento, simulação e resposta a incidentes de segurança.

Recursos

Práticas recomendadas relacionadas:

Documentos relacionados:

Vídeos relacionados:

Exemplos relacionados: