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á.
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 a seguir ilustra os serviços de AWS segurança 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 de entrada e saída (VPCs) separadas, você pode 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 AWS PrivateLink de VPC 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.
-
Peering de VPC ‒ A maneira mais simples de conectar dois VPCs é usar o peering de VPC. Uma conexão permite a conectividade bidirecional total entre o. VPCs VPCs que estão em contas separadas e também Regiões da AWS podem ser comparadas. Em grande escala, quando você tem dezenas a centenas de VPCs, interconectá-las com o peering resulta em uma malha de centenas a milhares de conexões de peering, o que pode ser difícil de gerenciar e escalar. O emparelhamento de VPC é melhor usado quando os recursos em uma VPC precisam se comunicar com os recursos em outra VPC, o ambiente de ambas VPCs é controlado e protegido e o número de VPCs pessoas conectadas é menor que 10 (para permitir o gerenciamento individual de cada conexão).
-
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). Outros AWS diretores podem criar uma conexão da VPC com seu serviço de endpoint usando uma interface VPC endpoint ou um endpoint 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 um ou mais consumidores acesso VPCs 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 nos dois VPCs têm endereços IP sobrepostos, porque PrivateLink usa interfaces de rede elásticas na VPC do cliente para que não haja conflitos de IP com o provedor de serviços. -
AWS Transit Gateway
‒ O Transit Gateway fornece um hub-and-spoke design para redes conectadas VPCs e locais como um serviço totalmente gerenciado, sem exigir que você provisione dispositivos virtuais. AWS gerencia alta disponibilidade e escalabilidade. Um gateway de trânsito é um recurso regional e pode conectar milhares de pessoas VPCs dentro do mesmo Região da AWS. Você pode conectar sua conectividade híbrida (VPN e AWS Direct Connect conexões) a um único gateway de trânsito, consolidando e controlando toda a configuração de roteamento da sua AWS organização 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 tem como objetivo aceitar, inspecionar e rotear conexões de rede iniciadas de fora do aplicativo. 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 das especificidades do aplicativo, você pode esperar ver NAT de tráfego, endpoints de VPC AWS service (Serviço da AWS) específicos 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 de inspeção dedicada fornece uma abordagem simplificada e central para gerenciar inspeções entre VPCs (na mesma ou em diferentes Regiões da AWS) a Internet e as redes locais. Para a AWS SRA, certifique-se de que todo o tráfego entre elas VPCs passe pela VPC de inspeção e evite usar a VPC de inspeção para qualquer outra carga de trabalho.
AWS Network Firewall
AWS Network Firewall
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 é interoperável com sua abordagem de segurança existente, incluindo tecnologias de AWS
parceiros.
No AWS SRA, o Firewall de Rede é 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
-
AWS Firewall Manager oferece suporte ao Firewall de Rede, para que você possa configurar e implantar centralmente as regras do Firewall de Rede em sua organização. (Para obter detalhes, consulte Usando AWS Network Firewall políticas no Firewall Manager na AWS documentação.) 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 de implantação distribuída em que o Network Firewall é implantado individualmente VPCs.
-
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 Network Access Analyzer usa algoritmos de raciocínio automatizado para analisar os caminhos de rede que um pacote pode percorrer entre os recursos em uma AWS rede e produz descobertas para caminhos que correspondem ao escopo de acesso à rede definido. 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 Network Access Analyzer quanto o Network Reachability usam a tecnologia mais recente da AWS comprovada iniciativa de segurança
A conta de rede define a infraestrutura de rede crítica que controla o tráfego que entra e sai do seu AWS ambiente. É necessário monitorar esse tráfego rigorosamente. No AWS SRA, o Network Access Analyzer é usado na conta de rede para ajudar a identificar o acesso não intencional à rede, identificar recursos acessíveis pela Internet por meio de gateways da Internet e verificar se os controles de rede apropriados, como firewalls de rede e gateways NAT, estão presentes em todos os caminhos de rede entre os recursos e os gateways da Internet.
Considerações sobre design
O Network Access Analyzer é um recurso da Amazon VPC e pode ser usado em Conta da AWS qualquer uma que tenha uma VPC. Os administradores de rede podem obter funções de IAM com escopo rigoroso e entre contas para validar se os caminhos de rede aprovados são aplicados em cada uma. Conta da AWS
AWS RAM
AWS Resource Access Manager
AWS RAM permite que você compartilhe recursos que não oferecem suporte a políticas baseadas em recursos do IAM, como sub-redes VPC e regras do Route 53. Além disso, com AWS RAM, os proprietários de um recurso podem ver quais diretores têm acesso aos recursos individuais que eles compartilharam. Os diretores do IAM podem recuperar a lista de recursos compartilhados diretamente com eles, o que eles não podem fazer com os recursos compartilhados pelas políticas de recursos do IAM. Se AWS RAM for usado para compartilhar recursos fora da sua AWS organização, um processo de convite será iniciado. O destinatário deve aceitar o convite antes que o acesso aos recursos seja concedido. Isso fornece freios e contrapesos adicionais.
AWS RAM é invocado e gerenciado pelo proprietário do recurso, na conta em que o recurso compartilhado é implantado. Um caso de uso comum AWS RAM ilustrado na AWS SRA é que os administradores de rede compartilhem sub-redes VPC e gateways de trânsito com toda a organização. AWS
Isso fornece a capacidade de desacoplar as funções de gerenciamento de rede Conta da AWS e ajuda a alcançar a separação de tarefas. Para obter mais informações sobre o compartilhamento de VPC, consulte a AWS postagem do blog Compartilhamento de VPC: uma nova abordagem para várias contas e gerenciamento de VPC e
Considerações sobre design
Embora AWS RAM o serviço seja implantado somente na conta de rede no AWS SRA, ele normalmente 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 AWS Lake Formation dados (bancos de dados e tabelas) com outras contas na sua AWS organização. Para obter mais informações, consulte a AWS Lake Formation
documentação e a postagem do AWS blog Compartilhe seus dados com segurança entre Contas da AWS os usuários
Acesso Verificado pela AWS
Acesso Verificado pela AWS
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 Verified Access requer um balanceador de carga interno. Como o Verified Access oferece suporte AWS WAF no nível da instância, um aplicativo existente que tenha AWS WAF integração com um Application Load Balancer pode mover políticas do balanceador de carga para a instância do Verified Access. 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.
No 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. Essas configurações podem então ser compartilhadas com dezenas, centenas ou milhares de contas de carga de trabalho usando. AWS RAM Isso permite que as equipes de aplicativos gerenciem os endpoints subjacentes que gerenciam seus aplicativos sem a sobrecarga de outras equipes. AWS RAM fornece uma maneira escalável de aproveitar o Acesso Verificado para aplicativos corporativos hospedados em diferentes contas de carga de trabalho.
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
O VPC Lattice se integra AWS RAM para permitir o compartilhamento de serviços e redes de serviços. AWS O SRA descreve uma arquitetura distribuída em que desenvolvedores ou proprietários de serviços criam serviços VPC Lattice em sua conta de aplicativo. 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 os VPCs serviços do VPC Lattice a uma ou mais redes de serviços. Para uma explicação detalhada dessa arquitetura distribuída, consulte a postagem do AWS blog Crie conectividade segura de várias contas e várias VPC para seus aplicativos com o Amazon VPC Lattice
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 podem compartilhar suas redes de serviços e dar aos proprietários do serviço o controle de associar 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
A segurança de borda geralmente envolve três tipos de proteções: entrega segura de conteúdo, proteção da rede e da camada de aplicativos e mitigação distribuída de negação de serviço (S). DDo Conteúdos como dados, vídeos, aplicativos 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 cookies assinados e assinados e autenticação por token. URLs 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. No limite, a mitigação DDo S fornece uma importante camada de defesa que garante a disponibilidade contínua de operações e serviços comerciais essenciais. Os aplicativos APIs devem ser protegidos contra inundações de SYN, inundações de UDP ou outros ataques de reflexão e ter mitigação em linha para impedir ataques básicos na camada de rede.
AWS oferece vários serviços para ajudar a fornecer um ambiente seguro, desde a nuvem central até a borda da AWS rede. A Amazon CloudFront, AWS Certificate Manager (ACM), AWS Shield 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 CloudFront APIs, o conteúdo ou os aplicativos podem ser fornecidos por HTTPS usando 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
Amazon CloudFront
CloudFrontA Amazon
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 cookies assinados URLs e assinados. Para obter mais informações, consulte Configurar o acesso seguro e restringir o acesso ao conteúdo na CloudFront documentação.
O AWS SRA ilustra CloudFront as distribuições centralizadas na conta de rede porque elas se alinham ao padrão de rede centralizado que é implementado usando. AWS 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 ACM, os registros DNS e o CloudFront registro em uma conta centralizada.
O painel CloudFront de segurança fornece AWS WAF visibilidade e controles 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 e AWS WAF adicionar cabeçalhos personalizados e verificar os cabeçalhos antes de encaminhar as solicitações para sua origem personalizada. Para obter uma explicação detalhada dessa solução, consulte a postagem do blog de AWS segurança Como aprimorar a segurança de CloudFront origem da Amazon com AWS WAFAWS Secrets Manager e.
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
AWS WAF
AWS WAF usa listas de controle de acesso à web (ACLs) para proteger um conjunto de AWS recursos. Uma ACL da web é um conjunto de regras que define os critérios de inspeção e uma ação associada a ser tomada (bloquear, permitir, contar ou executar o controle do bot) se uma solicitação da web atender aos critérios. AWS WAF fornece um conjunto de regras gerenciadas
AWS WAF fornece um conjunto de regras inteligentes gerenciadas por níveis para bots comuns e direcionados e proteção contra invasão de contas (ATP). 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. Você pode usar os painéis de gerenciamento de bots e controle de contas que estão disponíveis gratuitamente no AWS WAF console para monitorar essas atividades e depois decidir se você precisa de um grupo de AWS WAF regras de nível inteligente.
No AWS SRA, AWS WAF está integrado à conta CloudFront de rede. Nessa configuração, o processamento de AWS WAF regras acontece nos pontos de presença em vez de dentro da 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.
Você pode enviar AWS WAF registros completos para um bucket do S3 na conta do Log Archive configurando o acesso entre contas ao bucket do S3. Para obter mais informações, consulte o artigo do AWS
re:POST
Considerações sobre design
-
Como alternativa à implantação AWS WAF centralizada na conta de rede, alguns casos de uso são melhor atendidos com a implantação AWS WAF na conta do aplicativo. Por exemplo, você pode escolher essa opção ao implantar suas CloudFront distribuições em sua conta de aplicativo ou ter balanceadores de carga de aplicativos voltados para o público ou se estiver usando o API Gateway na frente de seus aplicativos web. Se você decidir implantar AWS WAF em cada conta do aplicativo, use AWS Firewall Manager para gerenciar AWS WAF as regras nessas contas a partir da conta centralizada do Security Tooling.
-
Você também pode adicionar AWS WAF regras gerais na CloudFront camada e AWS WAF regras adicionais específicas do aplicativo em um recurso regional, como o Application Load Balancer ou o gateway da API.
AWS Shield
AWS Shield
Você pode usar o recurso de mitigação automática da camada DDo S do aplicativo 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, balanceadores de carga do Elastic Load Balancing (ELB) (aplicativo, rede e clássico), zonas hospedadas do Amazon Route 53, endereços IP do Amazon Elastic e aceleradores padrão. EC2 AWS Global Accelerator Quando você ativa esse recurso, o Shield Advanced gera automaticamente AWS WAF regras personalizadas para mitigar DDo os ataques S. O Shield Advanced também dá acesso à Equipe de AWS Shield Resposta (SRT). Você pode entrar em contato com a SRT a qualquer momento para criar e gerenciar mitigações personalizadas para seu aplicativo ou durante um ataque S ativo DDo. Se você quiser que o SRT monitore proativamente seus recursos protegidos e entre em contato com você durante uma tentativa DDo S, considere ativar 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 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ê pode usar 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 Monitoramento com a Amazon CloudWatch na AWS documentação.) Configure CloudWatch alarmes para receber notificações do SNS em sua central de segurança quando um evento DDo S for detectado. Em um evento suspeito de DDo S, entre em contato com a equipe do AWS Enterprise Support
preenchendo um ticket de suporte e atribuindo a ele a maior prioridade. 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 Lambda de AWS Shield engajamento para criar um ticket de suporte e enviar um e-mail para a equipe do SRT.
AWS Certificate Manager (ACM)
AWS Certificate Manager
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 documentação do CloudFront .
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
Você pode usar o Route 53 como um serviço de DNS para mapear nomes de domínio para suas EC2 instâncias, buckets S3, CloudFront distribuições e outros recursos. AWS A natureza distribuída dos servidores AWS DNS ajuda a garantir que seus usuários finais sejam roteados para seu aplicativo de forma consistente. Recursos como fluxo de tráfego e 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 sua VPC e redes locais por meio de uma VPN gerenciada. AWS Direct Connect AWS
Ao usar o serviço 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 do seu. 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. Ele também pode bloquear solicitações de nomes de EC2 instâncias públicas ou privadas.
Os resolvedores do Route 53 são criados por padrão como parte de cada VPC. No AWS SRA, o Route 53 é usado na conta de rede principalmente para o recurso de firewall DNS.
Considerações sobre design
O DNS Firewall e AWS Network Firewall ambos oferecem filtragem de nomes de domínio, mas para diferentes tipos de tráfego. Você pode usar o Firewall DNS e o Firewall de Rede juntos para configurar a filtragem baseada em domínio para o tráfego da camada de aplicativo em dois caminhos de rede diferentes:
-
O Firewall DNS fornece filtragem para consultas DNS de saída que passam pelo Resolvedor do Route 53 a partir de aplicativos dentro do seu. 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.
