SEC09-BP03 Autentique as comunicações de rede - AWS Estrutura Well-Architected
Orientação para implementaçãoRecursos

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á.

SEC09-BP03 Autentique as comunicações de rede

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

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 do serviço ou outros recursos no. 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.

  • Fornece defense-in-depth suas cargas de trabalho combinando controles de rede com controles de autenticação e 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, o AWS serviço APIs usa 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 AWS APIs você possa 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 para determinar se a ação deve ser permitida ou não.

Serviços como Amazon VPC Lattice e 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 cargas de trabalho. Se recursos fora do seu AWS ambiente precisarem se comunicar com serviços que exigem autenticação e autorização baseadas em SIGV4, você pode usar AWS Identity and Access Management (IAM) Roles Anywhere no AWS recurso não- para adquirir credenciais temporárias. 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 TLS mútua (m). TLS Muitos business-to-business aplicativos, microsserviços e Internet das Coisas (IoT) usam m TLS para validar a identidade de ambos os lados de uma TLS comunicação por meio do uso de certificados X.509 do lado do cliente e do servidor. Esses certificados podem ser emitidos por AWS Private Certificate Authority (AWS Private CA). Você pode usar serviços como o Amazon API Gateway e fornecer minha TLS autenticação AWS App Meshpara comunicação entre cargas de trabalho ou dentro da carga de trabalho. Embora m TLS forneça informações de autenticação para os dois lados de uma TLS comunicação, ele não fornece um mecanismo para autorização.

Por fim, OAuth 2.0 e 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 service-to-service tráfego. APIO Gateway fornece um autorizador JSON Web Token (JWT), permitindo que as cargas de trabalho restrinjam o acesso às API rotas usando provedores de identidade JWTs emitidos OIDC ou OAuth 2.0. OAuth2os escopos 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 de aplicação, e os OAuth2 escopos sozinhos não podem suportar necessidades de autorização mais complexas.

Etapas de implementação

  • Defina e documente seus fluxos de rede de carga de trabalho: A primeira etapa na implementação de uma defense-in-depth estratégia é definir os fluxos de tráfego da sua carga de trabalho.

    • 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 Identifique ameaças e priorize mitigações usando um modelo de ameaça.

  • Estabeleça controles de rede: considere os AWS recursos 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 defense-in-depth estratégia para proteger sua carga de trabalho.

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

    • Considere usar AWS PrivateLinkpara se comunicar com os serviços de suporte AWS e de terceiros AWS PrivateLink. Os dados enviados por meio de um endpoint de AWS PrivateLink interface permanecem no backbone da AWS rede e não atravessam a Internet pública.

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

  • 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 registros de acesso do VPC Lattice. Esses registros de acesso incluem informações sobre a entidade solicitante, informações de rede, incluindo origem e destinoVPC, e metadados da solicitação.

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

    • Consulte o Guia de Resposta a Incidentes de AWS Segurança e a seção Resposta a Incidentes do pilar de 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: