View a markdown version of this page

SEC09-BP04 Autenticar as comunicações de rede - AWS Well-Architected Framework
Orientação de implementaçãoRecursos

SEC09-BP04 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 for feita uma comunicação entre serviços, aplicações ou usuários. 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 do acesso não autorizado.

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

Antipadrões comuns:

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

  • Reutilizar credenciais de autenticação entre 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 do estabelecimento desta 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 exposição a riscos se esta prática recomendada não for estabelecida: baixo

Orientações para a 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 puderem 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ços da AWS usam o protocolo de assinatura do Signature Version 4 (SigV4) da AWS 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 usar o mesmo protocolo de assinatura SigV4 para adicionar autenticação e autorização ao tráfego leste-oeste em suas próprias workloads. Se os recursos fora do ambiente da AWS precisarem se comunicar com os serviços que exigem autenticação e autorização baseadas em SigV4, você poderá usar o AWS Identity and Access Management (IAM) Roles Anywhere no recurso que não é da 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 por Autoridade de Certificação Privada da AWS (CA Privada da AWS). É possível 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 da 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 aos serviços pelos usuários, 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), que permite que as workloads restrinjam o acesso às rotas de API usando JWTs emitidos por provedores de identidades 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 por si sós não atendem a necessidades de autorização mais complexas.

Etapas da implementação

  • Definir e documentar os fluxos de rede da workload: a primeira etapa na implementação de uma estratégia de defesa profunda é definir os fluxos de tráfego da 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 um exercício de modelagem de ameaças, conforme descrito em SEC01-BP07 Identificar ameaças e priorizar mitigações com o uso de um modelo de ameaça.

  • Estabeleça controles de rede: considere os recursos da AWS para estabelecer controles de rede alinhados aos 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 os serviços da AWS e de terceiros que são 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.

  • Implementar autenticação e autorização entre os serviços na workload: escolha o conjunto de serviços da AWS mais apropriado para fornecer fluxos de tráfego autenticados e criptografados na workload.

  • Monitorar o acesso não autorizado: monitore continuamente os canais de comunicação não intencionais, entidades principais não autorizadas que tentam acessar recursos protegidos e outros padrões de acesso inadequados.

    • Se estiver usando o VPC Lattice para gerenciar o acesso aos serviços, considere ativar 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 a ativação dos Logs de fluxo da VPC para capturar metadados nos fluxos de rede e analisar se há anomalias periodicamente.

    • Consulte o AWS Security Incident Response Guide e a seção Resposta a incidentes do Pilar Segurança: 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: