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á.
# Redução da superfície de ataque
Outra consideração importante ao arquitetar uma AWS solução é limitar as oportunidades que um invasor tem de atacar seu aplicativo. Esse conceito é conhecido como *redução da superfície de* ataque. Recursos que não estão expostos à Internet são mais difíceis de atacar, o que limita as opções que um invasor tem para atingir a disponibilidade do seu aplicativo.
Por exemplo, se você não espera que os usuários interajam diretamente com determinados recursos, certifique-se de que esses recursos não estejam acessíveis pela Internet. Da mesma forma, não aceite tráfego de usuários ou aplicativos externos em portas ou protocolos que não sejam necessários para comunicação.
Na seção a seguir, AWS fornece as melhores práticas para orientá-lo na redução da superfície de ataque e na limitação da exposição do seu aplicativo à Internet.
# Ofuscando AWS recursos (,,) BP1 BP4 BP5
Normalmente, os usuários podem usar um aplicativo de forma rápida e fácil sem exigir que AWS os recursos sejam totalmente expostos à Internet.
# Grupos de segurança e rede ACLs (BP5)
A Amazon Virtual Private Cloud (AmazonVPC) permite que você provisione uma seção logicamente isolada da Nuvem AWS qual você pode lançar AWS recursos em uma rede virtual que você define.
Os grupos de segurança e a rede ACLs são semelhantes, pois permitem que você controle o acesso aos AWS recursos dentro do seuVPC. Mas os grupos de segurança permitem que você controle o tráfego de entrada e saída no nível da instância, enquanto a rede ACLs oferece recursos semelhantes no nível da VPC sub-rede. Não há cobrança adicional pelo uso de grupos de segurança ou redeACLs.
Você pode escolher se deseja especificar grupos de segurança ao executar uma instância ou associar a instância a um grupo de segurança posteriormente. *Todo o tráfego da Internet para um grupo de segurança é negado implicitamente, a menos que você crie uma regra de permissão para permitir o tráfego.*
Por exemplo, quando você tem EC2 instâncias da Amazon por trás de um Elastic Load Balancer, as instâncias em si não precisam estar acessíveis ao público e devem ser apenas privadasIPs. Em vez disso, você poderia fornecer ao Elastic Load Balancer acesso às portas necessárias do ouvinte de destino usando uma regra de grupo de segurança que permite acesso a 0.0.0.0/0 (para evitar problemas de rastreamento de conexão — veja a observação abaixo) em conjunto com uma Lista de Controle de Acesso à Rede (NACL) na sub-rede do grupo-alvo para permitir que somente os intervalos de IP do Elastic Load Balancing se comuniquem com as instâncias. Isso garante que o tráfego da Internet não possa se comunicar diretamente com suas EC2 instâncias da Amazon, o que torna mais difícil para um invasor conhecer e impactar seu aplicativo.
Ao criar uma redeACLs, você pode especificar as regras de permissão e negação. Isso é útil se você quiser negar explicitamente certos tipos de tráfego para seu aplicativo. Por exemplo, você pode definir endereços IP (como CIDR intervalos), protocolos e portas de destino aos quais o acesso à sub-rede inteira é negado. Se seu aplicativo for usado somente para TCP tráfego, você poderá criar uma regra para negar todo o UDP tráfego ou vice-versa. Essa opção é útil ao responder a DDoS ataques porque permite criar suas próprias regras para mitigar o ataque quando você conhece a origem IPs ou outra assinatura.
Se você estiver inscrito AWS Shield Advanced, poderá registrar endereços IP elásticos como recursos protegidos. DDoSataques contra endereços IP elásticos que foram registrados como recursos protegidos são detectados mais rapidamente, o que pode resultar em um tempo mais rápido de mitigação. Quando um ataque é detectado, os sistemas de DDoS mitigação lêem a rede ACL que corresponde ao endereço IP elástico de destino e a aplicam na borda da AWS rede, e não no nível da sub-rede. Isso reduz significativamente o risco de impacto de vários DDoS ataques na camada de infraestrutura.
Para obter mais informações sobre como configurar grupos de segurança e rede ACLs para otimizar a DDoS resiliência, consulte [Como ajudar a se preparar para DDoS ataques reduzindo sua superfície de ataque](https://aws.amazon.com/blogs/security/how-to-help-prepare-for-ddos-attacks-by-reducing-your-attack-surface/).
Para obter mais informações sobre o uso do Shield Advanced com endereços IP elásticos como recursos protegidos, consulte as etapas [para se inscrever AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/enable-ddos-prem.html).
# Protegendo sua origem (BP1,BP5)
Se você estiver usando a Amazon CloudFront com uma origem dentro da suaVPC, convém garantir que somente sua CloudFront distribuição possa encaminhar solicitações para sua origem. Com os cabeçalhos de solicitação Edge-to-Origin, você pode adicionar ou substituir o valor dos cabeçalhos de solicitação existentes ao CloudFront encaminhar solicitações para sua origem. Você pode usar os *cabeçalhos personalizados de origem*, por exemplo, o `X-Shared-Secret` cabeçalho, para ajudar a validar se as solicitações feitas à sua origem foram enviadas de. CloudFront
Para obter mais informações sobre como proteger sua origem com *cabeçalhos personalizados de origem, consulte [Adicionar](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html) cabeçalhos* [personalizados às solicitações de origem](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html) e [restringir o acesso aos Application](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html) Load Balancers.
Para obter um guia sobre a implementação de uma solução de amostra para alternar automaticamente o valor dos *cabeçalhos personalizados de origem* para a restrição de acesso à origem, consulte [Como aprimorar a segurança de CloudFront origem da Amazon com o Secrets AWS WAF Manager](https://aws.amazon.com/blogs/security/how-to-enhance-amazon-cloudfront-origin-security-with-aws-waf-and-aws-secrets-manager/).
Como alternativa, você pode usar uma [AWS Lambda](https://aws.amazon.com/lambda/)função para atualizar automaticamente as regras do seu grupo de segurança para permitir somente CloudFront tráfego. Isso melhora a segurança de sua origem, ajudando a garantir que usuários mal-intencionados não possam contornar CloudFront e AWS WAF acessar seu aplicativo web.
Para obter mais informações sobre como proteger sua origem atualizando automaticamente seus grupos de segurança e o `X-Shared-Secret` cabeçalho, consulte [Como atualizar automaticamente seus grupos de segurança para a Amazon CloudFront e AWS WAF usando AWS Lambda](https://aws.amazon.com/blogs/security/how-to-automatically-update-your-security-groups-for-amazon-cloudfront-and-aws-waf-by-using-aws-lambda/).
No entanto, a solução envolve configuração adicional e o custo de execução das funções Lambda. Para simplificar isso, agora introduzimos uma [lista AWS de prefixos gerenciada para CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list) limitar o HTTPS tráfego de HTTP entrada/às suas origens a partir apenas dos endereços IP voltados para a CloudFront origem. AWS-as listas de prefixos gerenciadas são criadas e mantidas por AWS e estão disponíveis para uso sem custo adicional. Você pode referenciar a lista de prefixos gerenciados CloudFront em suas regras de grupo de segurança (AmazonVPC), tabelas de rotas de sub-rede, regras comuns de grupos de segurança com AWS Firewall Manager e quaisquer outros AWS recursos que possam usar uma lista de [prefixos gerenciados](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html).
Para obter mais informações sobre o uso da lista AWS de prefixos gerenciada para a Amazon CloudFront, consulte [Limitar o acesso às suas origens usando a lista de prefixos AWS gerenciada](https://aws.amazon.com/blogs/networking-and-content-delivery/limit-access-to-your-origins-using-the-aws-managed-prefix-list-for-amazon-cloudfront/) para a Amazon. CloudFront
**nota**
Conforme discutido em outras seções deste documento, confiar em grupos de segurança para proteger sua origem pode adicionar o [rastreamento de conexões de grupos de segurança](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) como um possível gargalo durante uma inundação de solicitações. A menos que você consiga filtrar solicitações maliciosas CloudFront usando uma política de armazenamento em cache que permita o armazenamento em cache, talvez seja melhor confiar nos *cabeçalhos personalizados de origem*, discutidos anteriormente, para ajudar a validar se as solicitações feitas à sua origem foram enviadas de CloudFront, em vez de usar grupos de segurança. O uso de um cabeçalho de solicitação personalizado com uma regra de ouvinte do Application Load Balancer evita a limitação devido aos limites de rastreamento que podem afetar o estabelecimento de novas conexões com um balanceador de carga, permitindo que o Application Load Balancer escale com base no aumento do tráfego em caso de ataque. DDoS
# Protegendo API endpoints () BP4
Quando você precisa expor um API ao público, existe o risco de o API front-end ser alvo de um DDoS ataque. Para ajudar a reduzir o risco, você pode usar o [Amazon API Gateway como porta](https://aws.amazon.com/api-gateway/) de entrada para aplicativos executados na Amazon ou em EC2 outros AWS Lambda lugares. Ao usar o Amazon API Gateway, você não precisa de seus próprios servidores para o API front-end e pode ofuscar outros componentes do seu aplicativo. Ao dificultar a detecção dos componentes do seu aplicativo, você pode ajudar a evitar que esses AWS recursos sejam alvo de um DDoS ataque.
Ao usar o Amazon API Gateway, você pode escolher entre dois tipos de API endpoints. A primeira é a opção padrão: API endpoints otimizados para borda que são acessados por meio de uma distribuição da Amazon. CloudFront No entanto, a distribuição é criada e gerenciada pelo API Gateway, então você não tem controle sobre ela. A segunda opção é usar um API endpoint regional que seja acessado do mesmo Região da AWS em que o seu REST API está implantado. AWS recomenda que você use o segundo tipo de endpoint e o associe à sua própria CloudFront distribuição da Amazon. Isso lhe dá controle sobre a CloudFront distribuição da Amazon e a capacidade de uso AWS WAF para proteção da camada de aplicação. Esse modo fornece acesso à capacidade de DDoS mitigação escalonada em toda a rede de borda AWS global.
Ao usar a Amazon CloudFront e AWS WAF com o Amazon API Gateway, configure as seguintes opções:
+ Configure o comportamento do cache de suas distribuições para encaminhar todos os cabeçalhos para o endpoint regional do API Gateway. Ao fazer isso, CloudFront tratará o conteúdo como dinâmico e ignorará o armazenamento em cache do conteúdo.
+ Proteja seu API Gateway contra acesso direto configurando a distribuição para incluir o cabeçalho personalizado de origem x-api-key, definindo o valor da [APIchave](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-setup-api-key-with-console.html) no API Gateway.
+ Proteja o back-end do excesso de tráfego configurando limites padrão ou de taxa de intermitência para cada método em seu. REST APIs
Para obter mais informações sobre a criação APIs com o Amazon API Gateway, consulte [Amazon API Gateway](https://aws.amazon.com/api-gateway/getting-started/) [Getting Started](https://aws.amazon.com/api-gateway/getting-started/).