Infraestrutura de UO: conta de Rede

Influencie o futuro da Arquitetura de Referência de AWS Segurança (AWS SRA) respondendo a uma breve pesquisa.

O diagrama abaixo ilustra os serviços de segurança da AWS configurados na conta de Rede. 

A conta de Rede gerencia o gateway entre sua aplicação e a Internet em geral. É importante proteger essa interface bidirecional. A conta de Rede isola os serviços de rede, a configuração e a operação em relação às workloads de aplicações individuais, à segurança e a outras infraestruturas. Essa disposição não só limita a conectividade, as permissões e o fluxo de dados, mas também possibilita a separação de obrigações e o uso de privilégio mínimo para as equipes que precisem operar nessas contas. Ao dividir o fluxo da rede em nuvens privadas virtuais (VPCs) de entrada e saída distintas, é possível proteger a infraestrutura e o tráfego confidenciais contra acessos indesejados. Em geral, a rede de entrada é considerada de maior risco e merece roteamento, monitoramento e possíveis mitigações de problemas. Essas contas de infraestrutura herdarão as barreiras de proteção de permissão da conta de Gerenciamento da organização e da infraestrutura de unidade organizacional (UO). As equipes de rede (e segurança) gerenciam a maior parte da infraestrutura dessa conta.

Arquitetura de rede

Embora o design e as especificidades da rede estejam além do escopo deste documento, recomendamos essas três opções para conectividade de rede entre as várias contas: emparelhamento de VPC, PrivateLink AWS e AWS Transit Gateway. Os fatores importantes ao escolher entre elas são normas operacionais, orçamentos e necessidades específicas de largura de banda. 

• Emparelhamento de VPC: a maneira mais simples de conectar duas VPCs é usando o emparelhamento de VPC. Uma conexão viabiliza a conectividade bidirecional total entre as VPCs. Também é possível emparelhar VPCs que estejam em contas e regiões da AWS distintas. Em grande escala, quando você tem dezenas a centenas de VPCs, interconectá-las com o emparelhamento resulta em uma malha com centenas a milhares de conexões de emparelhamento, o que pode ser difícil de gerenciar e escalar. O melhor cenário para usar o emparelhamento de VPC é quando houver necessidade de que os recursos em uma VPC se comuniquem com os recursos em outra VPC, com ambas as VPCs em ambiente controlado e protegido e um número de VPCs para conexão inferior a 10 (para permitir o gerenciamento individual de cada conexão).

• A AWS PrivateLink ‒ PrivateLink fornece conectividade privada entre VPCs, serviços e aplicativos. Você pode criar seu próprio aplicativo em sua VPC e configurá-lo como um serviço baseado em PrivateLink tecnologia (conhecido como serviço de endpoint). Outras entidades principais da AWS podem criar uma conexão da VPC deles com o seu serviço de endpoint usando o endpoint da VPC de interface ou um endpoint do Gateway Load Balancer, dependendo do tipo de serviço. Quando você usa PrivateLink, o tráfego do serviço não passa por uma rede pública roteável. Use PrivateLink quando você tiver uma configuração cliente-servidor em que deseja dar a uma ou mais VPCs consumidoras acesso unidirecional a um serviço específico ou conjunto de instâncias na VPC do provedor de serviços. Essa também é uma boa opção quando clientes e servidores nas duas VPCs têm endereços IP sobrepostos, porque PrivateLink usa interfaces de rede elásticas dentro da VPC do cliente para que não haja conflitos de IP com o provedor de serviços. 

• O AWS Transit Gateway ‒ Transit Gateway fornece um hub-and-spoke design para conectar VPCs e redes locais como um serviço totalmente gerenciado, sem exigir que você provisione dispositivos virtuais. A AWS gerencia a alta disponibilidade e a escalabilidade. Um gateway de trânsito é um recurso regional e pode conectar milhares de VPCs na mesma região da AWS. Você pode anexar sua conectividade híbrida (conexões VPN e AWS Direct Connect) a um único gateway de trânsito, consolidando e controlando toda a configuração de roteamento da sua organização da AWS em um só lugar. Um gateway de trânsito soluciona a complexidade envolvida na criação e no gerenciamento de várias conexões de emparelhamento de VPC em grande escala. É o padrão para a maioria das arquiteturas de rede. No entanto, requisitos específicos de custo, largura de banda e latência podem tornar o emparelhamento de VPC mais adequado às suas necessidades.

VPC de entrada (ingresso)

A VPC de entrada é destinada a aceitar, inspecionar e rotear conexões de rede iniciadas fora da aplicação. Dependendo dos detalhes específicos da aplicação, você pode esperar ver alguma conversão de endereços de rede (NAT) nessa VPC. Os registros de fluxo dessa VPC serão capturados e armazenados na conta do arquivo de logs.

VPC de saída (egresso)

A VPC de saída é destinada a processar conexões de rede iniciadas diretamente na aplicação. Dependendo dos detalhes específicos da aplicação, você pode esperar ver NAT de tráfego, endpoints da VPC específicos de serviços da AWS e hospedagem de endpoints de API externos nessa VPC. Os registros de fluxo dessa VPC serão capturados e armazenados na conta do arquivo de logs.

VPC de inspeção

Uma VPC exclusiva de inspeção oferece uma abordagem simplificada e central para gerenciar as inspeções entre VPCs (na mesma ou em diferentes regiões da AWS), a Internet e redes on-premises. Para a AWS SRA, garanta que todo o tráfego entre VPCs passe pela VPC de inspeção e evite usar a VPC de inspeção para qualquer outra workload.

AWS Network Firewall

O AWS Network Firewall é um serviço de firewall de rede gerenciado e altamente disponível para sua VPC. Ele permite que você implante e gerencie facilmente inspeção com estado, prevenção e detecção de intrusões e filtragem da Web visando ajudar a proteger suas redes virtuais na AWS. Você pode usar o Network Firewall para descriptografar sessões TLS e inspecionar o tráfego de entrada e saída. Para obter mais informações sobre a configuração do Network Firewall, consulte a publicação de blog AWS Network Firewall: novo serviço de firewall gerenciado na VPC.

Você usa um firewall por zona de disponibilidade em sua VPC. Para cada zona de disponibilidade, você escolhe uma sub-rede para hospedar o endpoint do firewall que filtra seu tráfego. O endpoint do firewall em uma zona de disponibilidade pode proteger todas as sub-redes nessa zona, exceto a sub-rede na qual esteja localizado. A sub-rede do firewall pode ser pública ou privada, dependendo do caso de uso e do modelo de implantação. O firewall é completamente transparente para o fluxo de tráfego e não realiza a conversão de endereços de rede (NAT). Ele preserva os endereços de origem e de destino. Nessa arquitetura de referência, os endpoints do firewall são hospedados em uma VPC de inspeção. Todo o tráfego da VPC de entrada e para a VPC de saída é roteado por essa sub-rede do firewall para inspeção. 

O Network Firewall torna a atividade do firewall visível em tempo real por meio das CloudWatch métricas da Amazon e oferece maior visibilidade do tráfego da rede enviando registros para o Amazon Simple Storage Service (Amazon S3) e o Amazon CloudWatch Data Firehose. O Network Firewall tem interoperabilidade com sua abordagem de segurança atual, incluindo tecnologias de parceiros da AWS. Você também pode importar conjuntos de regras Suricata existentes, que podem ter sido criados internamente ou fornecidos externamente por prestadores terceirizados ou plataformas de código aberto. 

Na AWS SRA, o Network Firewall é usado na conta de Rede porque a funcionalidade do serviço focada no controle de rede está alinhada com a intenção da conta. 

Considerações sobre design

• O AWS Firewall Manager é compatível com o Network Firewall, permitindo que você configure e implante centralmente as regras do Network Firewall em toda a sua organização. (Para obter mais detalhes, consulte as políticas do AWS Network Firewall na documentação da AWS.) Quando você configura o Firewall Manager, ele cria automaticamente um firewall com conjuntos de regras nas contas e VPCs que você especifica. Ele também implanta um endpoint em uma sub-rede dedicada para cada zona de disponibilidade que contenha sub-redes públicas. Ao mesmo tempo, todas as alterações no conjunto de regras configurado centralmente são atualizadas automaticamente nos firewalls downstream dos firewalls implantados do Network Firewall. 

• O Network Firewall disponibiliza vários modelos de implantação. A abordagem escolhida dependerá do seu caso de uso. Os exemplos incluem:

  • Um modelo distribuído de implantação no qual o Network Firewall é implantado em VPCs individuais.

  • Um modelo centralizado de implantação no qual o Network Firewall é implantado em uma VPC centralizada para tráfego no sentido leste/oeste (VPC para VPC) ou no sentido norte/sul (entrada e saída da Internet, on-premises).

  • Um modelo combinado de implantação no qual o Network Firewall é implantado em uma VPC centralizada para tráfego no sentido leste/oeste e em um subconjunto no sentido norte/sul.

• Como prática recomendada, não use a sub-rede do Network Firewall para implantar outros serviços. Isso ocorre porque o Network Firewall não é capaz de inspecionar o tráfego de origens ou destinos na sub-rede do firewall.

Analisador de Acesso à Rede

O Analisador de Acesso à Rede é um recurso da Amazon VPC que identifica acesso de rede inesperado aos seus recursos. Você pode usar o Analisador de Acesso à Rede para validar a segmentação da rede, identificar recursos acessíveis por meio da Internet ou acessíveis exclusivamente a partir de intervalos de endereços IP confiáveis e validar se você tem controles de rede adequados em todos os caminhos de rede.

O Analisador de Acesso à Rede usa algoritmos de raciocínio automatizado para analisar os caminhos de rede que um pacote pode percorrer entre os recursos em uma rede da AWS e produz descobertas para caminhos correspondentes ao escopo de acesso à rede que você definiu. O Analisador de Acesso à Rede executa uma análise estática de uma configuração de rede, o que significa que nenhum pacote é transmitido na rede como parte dessa análise.

As regras de acessibilidade de rede do Amazon Inspector fornecem um recurso relacionado. As descobertas geradas por essas regras são usadas na conta de Aplicação. Tanto o Analisador de Acesso à Rede quanto o Network Reachability usam a tecnologia mais recente da iniciativa AWS Provable Security e aplicam essa tecnologia em diferentes áreas de foco. O pacote Network Reachability se concentra especificamente nas instâncias do EC2 e em sua acessibilidade à Internet. 

A conta de Rede define a infraestrutura crítica de rede que controla o tráfego que entra e sai do seu ambiente da AWS. É necessário monitorar esse tráfego rigorosamente. Na AWS SRA, o Analisador de Acesso à Rede é usado na conta de Rede para ajudar a identificar o acesso inesperado à rede, identificar recursos acessíveis pela Internet por meio de gateways da Internet e verificar se os controles de rede adequados, como firewalls de rede e gateways NAT, estão presentes em todos os caminhos de rede entre recursos e gateways da Internet. 

Considerações sobre design

• O Analisador de Acesso à Rede é um recurso da Amazon VPC que pode ser usado em qualquer conta da AWS que tenha uma VPC. Os administradores de rede podem criar perfis do IAM entre contas com escopo rigoroso para validar se os caminhos de rede aprovados são aplicados em cada conta da AWS.

AWS RAM

O AWS Resource Access Manager (AWS RAM) ajuda você a compartilhar de modo seguro com outras contas da AWS os recursos da AWS criados em uma conta da AWS. O AWS RAM fornece um local central para gerenciar o compartilhamento de recursos e padronizar essa experiência em todas as contas. Isso simplifica o gerenciamento de recursos e tira proveito do isolamento administrativo e de cobrança, além de reduzir o escopo dos benefícios de contenção de impacto fornecidos por uma estratégia de várias contas. Se o AWS Organizations gerenciar sua conta, o AWS RAM permitirá compartilhar recursos com todas as outras contas da organização ou somente com as contas contidas em uma ou mais unidades organizacionais (UOs). Você também pode compartilhar com contas específicas da AWS por ID de conta, independentemente de a conta integrar ou não uma organização. Você também pode compartilhar alguns tipos de recursos compatíveis com perfis e usuários do IAM especificados.

O AWS RAM permite compartilhar recursos incompatíveis com políticas baseadas em recursos do IAM, como sub-redes VPC e regras do Route 53. Além disso, com o AWS RAM os proprietários de um recurso podem ver quais entidades principais têm acesso a cada recurso individual que eles compartilharam. As entidades principais do IAM podem recuperar a lista de recursos compartilhados diretamente com elas, algo que elas não podem fazer com os recursos compartilhados pelas políticas de recursos do IAM. Um processo de convite será iniciado se o AWS RAM for usado para compartilhar recursos fora da sua organização da AWS. O destinatário deverá aceitar o convite antes que possa acessar os recursos. Isso fornece freios e contrapesos adicionais.

O AWS RAM é invocado e gerenciado pelo proprietário do recurso, na conta em que o recurso compartilhado é implantado. Um caso de uso comum do AWS RAM ilustrado na AWS SRA é para administradores de rede compartilharem sub-redes de VPC e gateways de trânsito com toda a organização da AWS. Isso permite dissociar os perfis de gerenciamento de redes e de contas da AWS e ajuda a concretizar a separação de responsabilidade. Para obter mais informações sobre o compartilhamento de VPCs, consulte a publicação Compartilhamento de VPC: uma nova abordagem para o gerenciamento de várias contas e VPCs no Blog da AWS e o whitepaper sobre infraestrutura de rede da AWS. 

Considerações sobre design

• Embora o AWS RAM como serviço seja implantado somente na conta de Rede na AWS SRA, normalmente ele seria implantado em mais de uma conta. Por exemplo, você pode centralizar o gerenciamento do data lake em uma única conta do data lake e depois compartilhar os recursos do catálogo de dados do AWS Lake Formation (bancos de dados e tabelas) com outras contas na sua organização da AWS. Para obter mais informações, consulte a documentação do AWS Lake Formation e a publicação Compartilhe seus dados com segurança entre contas da AWS usando o AWS Lake Formation no Blog da AWS. Além disso, os administradores de segurança podem usar o AWS RAM para seguir as melhores práticas ao criar uma CA privada da AWS hierarquia. As CAs podem ser compartilhadas com partes externas, que podem emitir certificados sem ter acesso à hierarquia da CA. Isso permite que as organizações de originação limitem e revoguem o acesso de terceiros.

Acesso Verificado pela AWS

O Acesso Verificado pela AWS fornece acesso seguro a aplicações corporativas sem uma VPN. Ele melhora a postura de segurança, avaliando cada solicitação de acesso em tempo real em relação aos requisitos predefinidos. É possível definir uma política de acesso exclusiva para cada aplicação com condições baseadas nos dados de identidade e na postura do dispositivo. O Acesso Verificado também simplifica as operações de segurança, ajudando os administradores a definir e monitorar com eficiência as políticas de acesso. Isso deixa mais tempo livre para atualizar políticas, responder a incidentes de segurança e conectividade e auditar os padrões de conformidade. O Acesso Verificado também é compatível com integrações ao AWS WAF para ajudar a filtrar ameaças comuns, como injeção de SQL e cross-site scripting (XSS). O acesso verificado é perfeitamente integrado ao AWS IAM Identity Center, que permite que os usuários se autentiquem com provedores de identidade terceirizados baseados em SAML (). IdPs Se você já tiver uma solução personalizada de IdP compatível com o OpenID Connect (OIDC), o Acesso Verificado também poderá autenticar usuários mediante conexão direta com seu IdP. O Acesso Verificado registra em log todas as tentativas de acesso, permitindo que você responda rapidamente a incidentes de segurança e solicitações de auditoria. O Verified Access suporta a entrega desses registros para o Amazon Simple Storage Service (Amazon S3), Amazon Logs e CloudWatch Amazon Data Firehose.

O Acesso Verificado é compatível com dois padrões comuns de aplicações corporativas: internas e voltadas para a Internet. O Acesso Verificado se integra às aplicações usando Application Load Balancers ou interfaces de rede elástica. Se você estiver usando um Application Load Balancer, o Acesso Verificado exigirá um balanceador de carga interno. Como o Acesso Verificado é compatível com o AWS WAF no nível de instância, uma aplicação existente com integração do AWS WAF a um Application Load Balancer poderá mover políticas do balanceador de carga para a instância do Acesso Verificado. Um aplicação corporativa é representada como um endpoint do Acesso Verificado. Cada endpoint está associado a um grupo de Acesso Verificado e herda a política de acesso do grupo. Um grupo do Acesso Verificado é uma coleção de endpoints do Acesso Verificado e uma política do Acesso Verificado no nível de grupo. Os grupos simplificam o gerenciamento de políticas e permitem que os administradores de TI definam critérios básicos. Os proprietários da aplicação podem definir ainda mais políticas granulares de acordo com a sensibilidade da aplicação.

Na AWS SRA, o Acesso Verificado é hospedado na conta de Rede. A equipe central de TI define centralmente as configurações gerenciadas. Por exemplo, a equipe pode conectar provedores de confiança, como provedores de identidade (por exemplo, Okta) e provedores de confiança de dispositivos (por exemplo, Jamf), criar grupos e determinar a política por grupo. Em seguida, é possível usar o AWS Resource Access Manager (AWS RAM) para compartilhar essas configurações com dezenas, centenas ou milhares de contas de workload. Isso permite que as equipes de aplicações gerenciem os endpoints subjacentes que gerenciam as aplicações sem sobrecarregar outras equipes. O AWS RAM fornece uma forma escalável de aproveitar o Acesso Verificado para aplicações corporativas hospedadas em diferentes contas de workload.

Considerações sobre design

• É possível agrupar os endpoints para aplicações com requisitos de segurança semelhantes a fim de simplificar a administração de políticas e então compartilhar com grupo com contas de aplicação. Todas as aplicações do grupo compartilham a política do grupo. Se uma aplicação do grupo exigir uma política específica devido a um caso de borda, você poderá aplicar uma política por aplicação para essa aplicação.

Amazon VPC Lattice

O Amazon VPC Lattice é um serviço de rede de aplicativos que conecta, monitora e protege as comunicações. service-to-service Um serviço, geralmente chamado de microsserviço, é uma unidade de software implantável de modo independente e que entrega uma tarefa específica. O VPC Lattice gerencia automaticamente a conectividade de rede e o roteamento da camada de aplicações entre serviços em VPCs e contas da AWS sem exigir que você gerencie a conectividade de rede subjacente, os balanceadores de carga de front-end ou os proxies associados. O serviço fornece um proxy totalmente gerenciado de camada de aplicação que oferece roteamento por aplicação com base nas características da solicitação, como caminhos e cabeçalhos. O VPC Lattice está integrado à infraestrutura da VPC, fornecendo uma abordagem consistente em uma ampla variedade de tipos de computação, como Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Kubernetes Service (Amazon EKS) e AWS Lambda. O VPC Lattice também é compatível com roteamento ponderado para implantações do tipo azul/verde e no estilo canário. Você pode usar o VPC Lattice para criar uma rede de serviços com um limite lógico que implemente automaticamente a conectividade e a descoberta de serviços. O VPC Lattice se integra ao AWS Identity and Access Management (IAM) para service-to-service autenticação e autorização usando políticas de autenticação.

O VPC Lattice também se integra ao AWS Resource Access Manager (AWS RAM) para viabilizar o compartilhamento de serviços e redes de serviço. A AWS SRA descreve uma arquitetura distribuída na qual desenvolvedores ou proprietários de serviços criam serviços VPC Lattice em sua conta de Aplicação. Os proprietários do serviço definem os receptores, as regras de roteamento e os grupos de destino juntamente com as políticas de autenticação. Em seguida, eles compartilham os serviços com outras contas e os associam às redes de serviços VPC Lattice. Essas redes são criadas pelos administradores de rede na conta de Rede e compartilhadas com a conta de Aplicação. Os administradores de rede configuram políticas de autenticação e monitoramento para cada rede de serviços. Os administradores associam VPCs e serviços do VPC Lattice a uma ou mais redes de serviços. Para obter uma explicação detalhada dessa arquitetura distribuída, consulte a postagem Construa conectividade segura de várias contas e várias VPC para suas aplicações com o Amazon VPC Lattice no Blog da AWS.

Considerações sobre design

• Dependendo do modelo operacional de serviço ou da visibilidade da rede de serviços da sua organização, os administradores de rede poderão compartilhar suas redes de serviços e permitir que os proprietários de serviços associem seus serviços e VPCs a essas redes de serviços. Como alternativa, os proprietários de serviço podem compartilhar seus serviços e os administradores de rede podem associar os serviços às redes de serviços.

  Um cliente só poderá enviar solicitações para serviços associados a uma rede de serviços se o cliente estiver em uma VPC que esteja associada à mesma rede de serviços. O tráfego do cliente que atravessar uma conexão de emparelhamento da VPC ou um gateway de trânsito será negado.

Segurança de borda

Em geral, a segurança de borda envolve três tipos de proteções: entrega segura de conteúdo, proteção da rede e da camada de aplicações, além de mitigação de negação distribuída de serviço (DDoS). Conteúdo como dados, vídeos, aplicações e APIs precisam ser entregues com rapidez e segurança, usando a versão recomendada do TLS para criptografar as comunicações entre endpoints. O conteúdo também deve ter restrições de acesso por meio de URLs assinados, cookies assinados e autenticação por token. Deve-se projetar a segurança por aplicação para controlar o tráfego de bots, bloquear padrões de ataque comuns, como injeção de SQL ou cross-site scripting (XSS), e fornecer visibilidade do tráfego na Web. Na borda, a mitigação de DDoS fornece uma importante camada de defesa que garante a disponibilidade contínua de operações e serviços comerciais essenciais. É necessário proteger aplicações e APIs contra floods de SYN, floods de UDP ou outros ataques de reflexão, além de ter mitigação em linha vigente para impedir ataques básicos na camada de rede.

A AWS oferece vários serviços para ajudar a fornecer um ambiente seguro, da nuvem central até a borda da rede da AWS. A Amazon CloudFront, o AWS Certificate Manager (ACM), o AWS Shield, o AWS WAF e o Amazon Route 53 trabalham juntos para ajudar a criar um perímetro de segurança flexível e em camadas. Com a Amazon CloudFront, conteúdo, APIs ou aplicativos podem ser entregues por HTTPS usando o TLSv1.3 para criptografar e proteger a comunicação entre clientes visualizadores e. CloudFront Você pode usar o ACM para criar um certificado SSL personalizado e implantá-lo em uma CloudFront distribuição gratuitamente. O ACM gerencia automaticamente a renovação do certificado. O AWS Shield é um serviço gerenciado de proteção contra DDoS que ajuda a proteger aplicações executadas na AWS. Ele fornece detecção dinâmica e mitigações automáticas em linha que minimizam o tempo de inatividade e a latência da aplicação. O AWS WAF permite criar regras para filtrar o tráfego da web com base em condições específicas (endereços IP, cabeçalhos e corpo HTTP ou URIs personalizados), ataques comuns na web e bots generalizados. O Amazon Route 53 é um web service DNS altamente disponível e dimensionável. O Route 53 conecta solicitações de usuários a aplicações da Internet que são executadas na AWS ou on-premises. A AWS SRA adota uma arquitetura centralizada de entrada de rede usando o AWS Transit Gateway, hospedado na conta de Rede, de modo que a infraestrutura de segurança na borda também esteja centralizada nessa conta.

Amazon CloudFront

CloudFrontA Amazon é uma rede de entrega de conteúdo (CDN) segura que fornece proteção inerente contra tentativas comuns de DDoS em camadas de rede e transporte. Você pode entregar seu conteúdo, APIs ou aplicações usando certificados TLS, e os recursos avançados de TLS são ativados automaticamente. Você pode usar o ACM para criar um certificado TLS personalizado e impor comunicações HTTPS entre visualizadores e CloudFront, conforme descrito posteriormente na seção ACM. Além disso, você pode exigir que as comunicações entre sua origem personalizada CloudFront e sua origem personalizada implementem end-to-end criptografia em trânsito. Para esse cenário, você deverá instalar um certificado TLS no seu servidor de origem. Se sua origem for um balanceador de carga elástico, você poderá usar um certificado gerado pelo ACM ou um certificado validado por uma autoridade de certificação (CA) externa e importado para o ACM. Se os endpoints do site do bucket S3 servirem como origem para CloudFront, você não poderá configurar CloudFront para usar HTTPS com sua origem, porque o Amazon S3 não oferece suporte a HTTPS para endpoints de sites. (No entanto, você ainda pode exigir HTTPS entre os espectadores CloudFront e.) Para todas as outras origens compatíveis com a instalação de certificados HTTPS, será necessário usar um certificado assinado por uma CA externa.

CloudFront fornece várias opções para proteger e restringir o acesso ao seu conteúdo. Por exemplo, ele pode restringir o acesso à sua origem do Amazon S3 usando URLs assinados e cookies assinados. Para obter mais informações, consulte Configurando o acesso seguro e restringindo o acesso ao conteúdo na CloudFront documentação.

O AWS SRA ilustra as CloudFront distribuições centralizadas na conta de rede porque elas se alinham ao padrão de rede centralizado que é implementado usando o Transit Gateway. Ao implantar e gerenciar CloudFront distribuições na conta de rede, você obtém os benefícios dos controles centralizados. Você pode gerenciar todas as CloudFront distribuições em um único local, o que facilita o controle do acesso, a configuração das configurações e o monitoramento do uso em todas as contas. Além disso, você pode gerenciar os certificados do ACM, os registros DNS e o CloudFront registro em uma conta centralizada. O painel CloudFront de segurança fornece visibilidade e controles do AWS WAF diretamente em sua CloudFront distribuição. Você obtém visibilidade das principais tendências de segurança do seu aplicativo, do tráfego permitido e bloqueado e da atividade de bots. Você pode usar ferramentas investigativas, como analisadores visuais de registros e controles de bloqueio integrados, para isolar padrões de tráfego e bloquear o tráfego sem consultar registros ou escrever regras de segurança.

Considerações sobre design

• Como alternativa, você pode implantar CloudFront como parte do aplicativo na conta do aplicativo. Nesse cenário, a equipe de aplicativos toma decisões como a forma como CloudFront as distribuições são implantadas, determina as políticas de cache apropriadas e assume a responsabilidade pela governança, auditoria e monitoramento das distribuições. CloudFront Ao CloudFront distribuir as distribuições em várias contas, você pode se beneficiar de cotas de serviço adicionais. Como outro benefício, você pode usar a configuração CloudFront de identidade de acesso de origem (OAI) e controle de acesso de origem (OAC) inerente e automatizada para restringir o acesso às origens do Amazon S3.

• Quando você entrega conteúdo da web por meio de uma CDN CloudFront, como, você precisa impedir que os espectadores ignorem a CDN e acessem seu conteúdo de origem diretamente. Para alcançar essa restrição de acesso à origem, você pode usar CloudFront o AWS WAF para adicionar cabeçalhos personalizados e verificar os cabeçalhos antes de encaminhar solicitações para sua origem personalizada. Para obter uma explicação detalhada dessa solução, consulte a postagem no blog de segurança da AWS Como aprimorar a segurança de CloudFront origem da Amazon com o AWS WAF e o AWS Secrets Manager. Um método alternativo é limitar somente a lista de CloudFront prefixos no grupo de segurança associado ao Application Load Balancer. Isso ajudará a garantir que somente uma CloudFront distribuição possa acessar o balanceador de carga.

AWS WAF

O AWS WAF é um firewall de aplicações da Web que ajuda a proteger contra exploits da Web, como vulnerabilidades e bots comuns capazes de afetar a disponibilidade da aplicação, comprometer a segurança ou consumir recursos em excesso. Ele pode ser integrado com uma CloudFront distribuição da Amazon, uma API REST do Amazon API Gateway, um Application Load Balancer, uma API do AWS GraphQL AppSync , um grupo de usuários do Amazon Cognito e o serviço AWS App Runner.

O AWS WAF usa listas de controle de acesso (ACLs) à Web para proteger um conjunto de recursos da AWS. Uma ACL da Web é um conjunto de regras que define os critérios de inspeção e uma ação associada a ser adotada (bloquear, permitir, contar ou executar o controle de bots) se uma solicitação da Web atender aos critérios. O AWS WAF fornece um conjunto de regras gerenciadas que oferece proteção contra vulnerabilidades comuns de aplicações. Essas regras são organizadas e gerenciadas pela AWS e pelos parceiros da AWS. O AWS WAF também oferece uma linguagem avançada de regras para a criação de regras personalizadas. É possível usar regras personalizadas para escrever critérios de inspeção que atendam às suas necessidades específicas. Os exemplos incluem restrições de IP, restrições geográficas e versões personalizadas de regras gerenciadas que se adaptem melhor ao comportamento específico da sua aplicação.

O AWS WAF fornece um conjunto de regras inteligentes gerenciadas por níveis para bots comuns e bots direcionados e Account takeover protection (ATP – Proteção contra invasão de contas). Você paga uma tarifa de assinatura e uma tarifa de inspeção de tráfego ao usar os grupos de regras para controle de bots e para ATP. Por isso, recomendamos que você monitore o tráfego antes e então decida o que usar. É possível usar os painéis de gerenciamento de bots e de controle de contas que estão disponíveis gratuitamente no console do AWS WAF para monitorar essas atividades e depois decidir se é preciso um grupo de regras do AWS WAF de nível inteligente.

No AWS SRA, o AWS WAF é integrado à conta CloudFront de rede. Nessa configuração, o processamento de regras do WAF acontece nos locais da borda em vez de acontecer na VPC. Isso permite filtrar o tráfego malicioso mais perto do usuário final que solicitou o conteúdo e ajuda a impedir que o tráfego malicioso entre na sua rede principal.

É possível encaminhar registros completos do AWS WAF para um bucket do S3 na conta de Arquivamento de logs ao configurar o acesso entre contas ao bucket do S3. Consulte o artigo do AWS re:Post sobre esse tópico para obter mais informações.

Considerações sobre design

• Como alternativa à implantação centralizada do AWS WAF na conta de Rede, alguns casos de uso funcionam melhor com a implantação do AWS WAF na conta de Aplicação. Por exemplo, você pode escolher essa opção ao implantar suas CloudFront distribuições em sua conta do aplicativo ou ter balanceadores de carga de aplicativos voltados para o público, ou se estiver usando o Amazon API Gateway na frente de seus aplicativos web. Se você decidir implantar o AWS WAF em cada conta de Aplicação, use o AWS Firewall Manager para gerenciar as regras do AWS WAF nessas contas diretamente da conta centralizada de ferramentas de segurança.

• Você também pode adicionar regras gerais do AWS WAF na CloudFront camada e regras adicionais do AWS WAF específicas do aplicativo em um recurso regional, como o Application Load Balancer ou o API gateway.

AWS Shield

O AWS Shield é um serviço gerenciado de proteção contra DDoS que protege aplicações executadas na AWS. Há dois níveis do Shield: Shield Padrão e Shield Avançado. O Shield Padrão fornece a todos os clientes da AWS proteção contra os eventos de infraestrutura mais comuns (camadas 3 e 4) sem custo adicional. O Shield Advanced fornece mitigações automáticas mais sofisticadas para eventos não autorizados que visam aplicativos em zonas hospedadas protegidas do Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing (ELB), CloudFront Amazon, AWS Global Accelerator e Route 53. Se tiver sites de alta visibilidade ou propensos a ataques frequentes de DDoS, você poderá avaliar recursos adicionais oferecidos pelo Shield Avançado.

Você pode usar o recurso de mitigação automática de DDoS da camada de aplicação Shield Advanced para configurar o Shield Advanced para responder automaticamente para mitigar os ataques da camada de aplicação (camada 7) contra suas CloudFront distribuições protegidas e Application Load Balancers. Ao habilitar esse recurso, o Shield Avançado gera automaticamente regras personalizadas do AWS WAF para mitigar ataques de DDoS. O Shield Avançado também fornece acesso ao AWS Shield Response Team (SRT). Você pode entrar em contato com o SRT a qualquer momento para criar e gerenciar mitigações personalizadas para sua aplicação ou durante um ataque ativo de DDoS. Se você quiser que o SRT monitore proativamente seus recursos protegidos e entre em contato com você durante uma tentativa de DDoS, considere habilitar o recurso de engajamento proativo.

Considerações sobre design

• Se você tiver alguma carga de trabalho baseada em recursos voltados para a Internet na conta do aplicativo, como Amazon, um Application Load Balancer ou um Network CloudFront Load Balancer, configure o Shield Advanced na conta do aplicativo e adicione esses recursos à proteção do Shield. Você poderá usar o AWS Firewall Manager para configurar essas opções em grande escala.

• Se você tiver vários recursos no fluxo de dados, como uma CloudFront distribuição na frente de um Application Load Balancer, use somente o recurso de ponto de entrada como recurso protegido. Isso garantirá que você não pague as tarifas do Shield Data Transfer Out (DTO – Saída de transferência de dados) duplamente por dois recursos.

• O Shield Advanced registra métricas que você pode monitorar na Amazon CloudWatch. (Para obter mais informações, consulte Métricas e alarmes do AWS Shield Avançado na documentação da AWS.) Configure CloudWatch alarmes para receber notificações do SNS em sua central de segurança quando um evento de DDoS for detectado. Em uma suspeita de evento de DDoS, entre em contato com a equipe do AWS Enterprise Support preenchendo um ticket de suporte e atribuindo a maior prioridade ao ticket. A equipe do Enterprise Support incluirá a Shield Response Team (SRT) ao processar o evento. Além disso, você pode pré-configurar a função do Lambda de engajamento do AWS Shield para criar um ticket de suporte e enviar um e-mail para a equipe do SRT.

AWS Certificate Manager

O AWS Certificate Manager (ACM) permite provisionar, gerenciar e implantar certificados TLS públicos e privados para usar com serviços da AWS e seus recursos internos conectados. Com o ACM, você pode solicitar rapidamente um certificado, implantá-lo em recursos da AWS integrados ao ACM, como balanceadores de carga do Elastic Load Balancing, distribuições da Amazon e APIs no CloudFront Amazon API Gateway, e deixar que o ACM cuide das renovações de certificados. Quando você solicita certificados públicos do ACM, não há necessidade de gerar um par de chaves ou uma solicitação de assinatura de certificado (CSR), enviar uma CSR a uma autoridade de certificação (CA) ou carregar e instalar o certificado quando ele for recebido. O ACM também oferece a opção de importar certificados TLS emitidos por CAs externas e implantá-los com serviços integrados do ACM. Quando você opta por gerenciar certificados com o ACM, as chaves privadas são protegidas e armazenadas de maneira segura, seguindo as melhores práticas de criptografia e gestão de chaves. Com o ACM, não há cobrança adicional pelo provisionamento de certificados públicos, e o ACM gerencia o processo de renovação.

O ACM é usado na conta de rede para gerar um certificado TLS público, que, por sua vez, é usado pelas CloudFront distribuições para estabelecer a conexão HTTPS entre visualizadores e. CloudFront Para obter mais informações, consulte a CloudFront documentação.

Considerações sobre design

• Para certificados direcionados externamente, o ACM deverá residir na mesma conta dos recursos para os quais ele fornece certificados. Não é possível compartilhar certificados entre contas.

Amazon Route 53

O Amazon Route 53 é um serviço web de DNS altamente disponível e escalável. Você pode usar o Route 53 para executar três funções principais: registro de domínios, roteamento de DNS e verificação de integridade.

Você pode usar o Route 53 como um serviço de DNS para mapear nomes de domínio para suas instâncias do EC2, buckets S3 CloudFront , distribuições e outros recursos da AWS. A natureza distribuída dos servidores de DNS da AWS ajuda a garantir que seus usuários finais sejam roteados para sua aplicação de modo consistente. Recursos como o fluxo de tráfego e o controle de roteamento do Route 53 ajudam você a melhorar a confiabilidade. Se o endpoint principal de aplicação ficar indisponível, você poderá configurar seu failover para redirecionar seus usuários para um local alternativo. O Route 53 Resolver fornece DNS recursivo para suas redes VPC e on-premises pelo AWS Direct Connect ou VPN gerenciada pela AWS.

Ao usar o serviço AWS Identity and Access Management (IAM) com o Route 53, você obtém um controle refinado sobre quem pode atualizar seus dados de DNS. É possível habilitar a assinatura Domain Name System Security Extensions (DNSSEC) para permitir que os resolvedores de DNS validem que uma resposta de DNS veio do Route 53 e não foi adulterada.

O Route 53 Resolver DNS Firewall fornece proteção para solicitações de DNS de saída oriundas de suas VPCs. Essas solicitações passam pelo Route 53 Resolver para resolução de nomes de domínio. Um uso principal das proteções do Firewall DNS é ajudar a impedir a exfiltração de DNS de seus dados. Com o Firewall DNS, você pode monitorar e controlar os domínios que as aplicações podem consultar. Você pode negar acesso aos domínios sabidamente nocivos e permitir a passagem de todas as outras consultas. Como alternativa, você pode negar acesso a todos os domínios, exceto aqueles em que você confia explicitamente. Você também pode usar o DNS Firewall para bloquear solicitações de resolução para recursos em zonas hospedadas privadas (compartilhadas ou locais), incluindo nomes de endpoint da VPC. O serviço também pode bloquear solicitações para nomes de instâncias públicas ou privadas do EC2.

Os resolvedores do Route 53 são criados por padrão como parte de cada VPC. Na AWS SRA, o Route 53 é usado na conta de Rede principalmente para a capacidade de firewall do DNS. 

Considerações sobre design

• O DNS Firewall e o AWS Network Firewall oferecem filtragem de nomes de domínio, mas para diferentes tipos de tráfego. Você pode usar o DNS Firewall e o Network Firewall juntos para configurar a filtragem baseada em domínio para o tráfego da camada de aplicação em dois caminhos de rede diferentes.

  • O Firewall DNS fornece filtragem para consultas de DNS de saída que passam pelo Route 53 Resolver a partir de aplicações dentro de suas VPCs. Você também pode configurar o Firewall DNS para enviar respostas personalizadas para consultas a nomes de domínio bloqueados.

  • O Network Firewall fornece filtragem para tráfego de camada de rede e camada de aplicação, mas não tem visibilidade sobre as consultas feitas pelo Route 53 Resolver.