**Apresentando uma nova experiência de console para AWS WAF**
Agora você pode usar a experiência atualizada para acessar a AWS WAF funcionalidade em qualquer lugar do console. Para obter mais detalhes, consulte [Trabalhando com o console](https://docs.aws.amazon.com/waf/latest/developerguide/working-with-console.html).
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á.
# AWS Shield
A proteção contra ataques distribuídos de negação de serviço (DDoS) é de fundamental importância para seus aplicativos voltados para a Internet. Ao criar seu aplicativo AWS, você pode usar proteções que são AWS fornecidas sem custo adicional. Além disso, você pode usar o serviço AWS Shield Advanced gerenciado de proteção contra ameaças para melhorar sua postura de segurança com recursos adicionais de detecção, mitigação e resposta de DDo S.
AWS tem o compromisso de fornecer a você as ferramentas, as melhores práticas e os serviços para ajudar a garantir alta disponibilidade, segurança e resiliência em sua defesa contra agentes mal-intencionados na Internet. Este guia é fornecido para ajudar os tomadores de decisão de TI e engenheiros de segurança a entender como usar o Shield e o Shield Advanced para proteger melhor seus aplicativos contra ataques DDo S e outras ameaças externas.
Ao criar seu aplicativo AWS, você recebe proteção automática AWS contra vetores de ataque DDo S volumétricos comuns, como ataques de reflexão UDP e inundações de TCP SYN. Você pode aproveitar essas proteções para garantir a disponibilidade dos aplicativos nos quais você executa AWS projetando e configurando sua arquitetura para resiliência DDo S.
Este guia fornece recomendações que podem ajudá-lo a projetar, criar e configurar suas arquiteturas de aplicativos para resiliência DDo S. Os aplicativos que seguem as melhores práticas fornecidas neste guia podem se beneficiar de uma continuidade aprimorada da disponibilidade quando são alvo de ataques DDo S maiores e de faixas mais amplas de vetores de ataque DDo S. Além disso, este guia mostra como usar o Shield Advanced para implementar uma postura de proteção DDo S otimizada para seus aplicativos críticos. Isso inclui aplicativos para os quais você garantiu um certo nível de disponibilidade para seus clientes e aqueles que exigem suporte operacional AWS durante DDo os eventos S.
A segurança é uma responsabilidade compartilhada entre você AWS e você. O [modelo de responsabilidade compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/) descreve isto como segurança *da* nuvem e segurança *na* nuvem.
+ **Segurança da nuvem** — AWS é responsável por proteger a infraestrutura que executa AWS os serviços no Nuvem AWS. AWS também fornece serviços que você pode usar com segurança. A eficácia da nossa segurança é regularmente testada e verificada por auditores de terceiros como parte dos [Programas de conformidade da AWS](https://aws.amazon.com/compliance/programs/). Para saber mais sobre os programas de conformidade que se aplicam ao Shield Advanced, consulte [Serviços da AWS no escopo pelo programa de conformidade](https://aws.amazon.com/compliance/services-in-scope/).
+ **Segurança na nuvem** — Sua responsabilidade é determinada pelo AWS serviço que você usa. Também existe a responsabilidade por outros fatores, incluindo a confidencialidade de dados, os requisitos da organização e as leis e regulamentos aplicáveis.
![\[Um diagrama mostra um retângulo dividido horizontalmente. A metade superior é intitulada Cliente: responsabilidade pela segurança “na” nuvem e a metade inferior é intitulada AWS: responsabilidade pela segurança “da” nuvem. A metade principal do cliente contém quatro níveis. O primeiro deles é Dados do cliente. O segundo é Gerenciamento de plataforma, aplicativos, identidade e acesso. O terceiro é Configuração do sistema operacional, da rede e do firewall. O quarto e último nível da área do cliente é dividido em três seções que estão lado a lado. A seção à esquerda deles é Dados do lado do cliente, criptografia e integridade de dados, autenticação. A do meio é a criptografia do lado do servidor (dados do sistema and/or de arquivos). A seção à direita é Proteção do tráfego de rede (criptografia, integridade, identidade). Isso conclui o conteúdo da metade superior da figura do cliente. A AWS metade inferior da figura contém uma camada intitulada Software na parte superior e abaixo dela, uma camada intitulada Hardware/infraestrutura AWS global. A camada de software é dividida em quatro subseções que estão lado a lado, onde se lê Computação, Armazenamento, Banco de dados e Rede. O nível de hardware é dividido em três subseções que estão lado a lado, onde se lê Regiões, Zonas de disponibilidade e locais da borda.\]](http://docs.aws.amazon.com/pt_br/waf/latest/developerguide/images/shared-responsibility-model.png)
# Como o AWS Shield Shield Advanced funcionam
Esta página explica a diferença entre AWS Shield Standard AWS Shield Advanced e. Também descreve as classes de ataques que o Shield detecta.
AWS Shield Standard e AWS Shield Advanced forneça proteções contra ataques distribuídos de negação de serviço (DDoS) para AWS recursos nas camadas de rede e transporte (camadas 3 e 4) e na camada de aplicação (camada 7). Um ataque DDo S é um ataque no qual vários sistemas comprometidos tentam inundar um alvo com tráfego. Um ataque DDo S pode impedir que usuários finais legítimos acessem os serviços de destino e pode fazer com que o alvo falhe devido ao grande volume de tráfego.
AWS Shield fornece proteção contra uma ampla variedade de vetores de ataque DDo S e vetores de ataque de dia zero conhecidos. A detecção e mitigação do Shield foram projetadas para fornecer cobertura contra ameaças, mesmo que elas não sejam explicitamente conhecidas pelo serviço no momento da detecção.
O Shield Básico é fornecido automaticamente e sem custos adicionais quando você usa a AWS. Para níveis mais altos de proteção contra ataques, você pode se inscrever no AWS Shield Advanced.
As classes de ataques que o Shield detecta incluem as seguintes:
+ **Ataques volumétricos de rede (camada 3)**: essa é uma subcategoria de vetores de ataque da camada de infraestrutura. Esses vetores tentam saturar a capacidade da rede ou do recurso-alvo, para negar o serviço a usuários legítimos.
+ **Ataques de protocolo de rede (camada 4)**: essa é uma subcategoria de vetores de ataque da camada de infraestrutura. Esses vetores abusam de um protocolo para negar serviço ao recurso-alvo. Um exemplo comum de ataque de protocolo de rede é um flood TCP SYN, que pode esgotar o estado da conexão em recursos como servidores, balanceadores de carga ou firewalls. Um ataque de protocolo de rede também pode ser volumétrico. Por exemplo, um flood TCP SYN maior pode ter a intenção de saturar a capacidade de uma rede e, ao mesmo tempo, esgotar o estado do recurso-alvo ou dos recursos intermediários.
+ **Ataques na camada de aplicação (camada 7)**: essa categoria de vetor de ataque tenta negar serviço a usuários legítimos inundando um aplicativo com consultas válidas para o alvo, como inundações de solicitações da web.
**Contents**
+ [Visão geral do AWS Shield Standard](ddos-standard-summary.md)
+ [Visão geral do AWS Shield Advanced](ddos-advanced-summary.md)
+ [Lista de AWS recursos que AWS Shield Advanced protegem](ddos-advanced-summary-protected-resources.md)
+ [AWS Shield Advanced capacidades e opções](ddos-advanced-summary-capabilities.md)
+ [Decidir se deseja assinar AWS Shield Advanced e aplicar proteções adicionais](ddos-advanced-summary-deciding.md)
+ [Exemplos de ataques DDo S](types-of-ddos-attacks.md)
+ [Como AWS Shield detecta eventos](ddos-event-detection.md)
+ [AWS Shield lógica de detecção para ameaças na camada de infraestrutura (camada 3 e camada 4)](ddos-event-detection-infrastructure.md)
+ [Lógica de detecção do Shield Advanced para ameaças na camada de aplicativo (camada 7)](ddos-event-detection-application.md)
+ [Lógica de detecção do Shield Advanced para vários recursos em um aplicativo](ddos-event-detection-multiple-resources.md)
+ [Como AWS Shield atenua os eventos](ddos-event-mitigation.md)
+ [Lista de recursos de mitigação de AWS Shield DDo S](ddos-event-mitigation-features.md)
+ [AWS Shield lógica de mitigação para CloudFront e Route 53](ddos-event-mitigation-logic-continuous-inspection.md)
+ [AWS Shield lógica de mitigação para regiões AWS](ddos-event-mitigation-logic-regions.md)
+ [AWS Shield lógica de mitigação para aceleradores padrão AWS Global Accelerator](ddos-event-mitigation-logic-gax.md)
+ [AWS Shield Advanced lógica de mitigação para a Elastic IPs](ddos-event-mitigation-logic-adv-eip.md)
+ [AWS Shield Advanced lógica de mitigação para aplicativos web](ddos-event-mitigation-logic-adv-web-app.md)
# Visão geral do AWS Shield Standard
AWS Shield é um serviço gerenciado de proteção contra ameaças que protege o perímetro do seu aplicativo. O perímetro é o primeiro ponto de entrada para o tráfego de aplicativos vindo de fora da AWS rede.
Para determinar qual é o perímetro do seu aplicativo, considere como os usuários acessam seu aplicativo pela internet. Se o primeiro ponto de entrada estiver em uma AWS região, o perímetro do aplicativo será sua Amazon Virtual Private Cloud (VPC). Se os usuários forem direcionados ao seu aplicativo pelo Amazon Route 53 e acessarem primeiro o aplicativo usando o Amazon CloudFront ou AWS Global Accelerator, o perímetro do aplicativo começará na borda da AWS rede.
O Shield fornece benefícios de detecção e mitigação de DDo S para todos os aplicativos em execução AWS, mas as decisões que você toma ao projetar sua arquitetura de aplicativos influenciarão seu nível de resiliência DDo S. DDoS Resiliência é a capacidade do seu aplicativo de continuar operando dentro dos parâmetros esperados durante um ataque.
Todos os AWS clientes se beneficiam da proteção automática do Shield Standard, sem custo adicional. O Shield Standard se defende contra os ataques mais comuns e frequentes da camada DDo S de rede e transporte que têm como alvo seu site ou aplicativos. Embora o Shield Standard ajude a proteger todos os AWS clientes, você obtém benefícios especiais com as zonas hospedadas do Amazon Route 53, CloudFront as distribuições da Amazon e os aceleradores AWS Global Accelerator padrão. Esses recursos recebem proteção abrangente de disponibilidade contra todos os ataques conhecidos das camadas de rede e transporte.
# Visão geral do AWS Shield Advanced
AWS Shield Advanced é um serviço gerenciado que ajuda você a proteger seu aplicativo contra ameaças externas, como ataques DDo S, bots volumétricos e tentativas de exploração de vulnerabilidades. Para níveis mais altos de proteção contra ataques, você pode se inscrever no AWS Shield Advanced.
Quando você assina o Shield Advanced e adiciona proteção aos seus recursos, o Shield Advanced fornece proteção expandida contra ataques DDo S para esses recursos. As proteções que você recebe do Shield Advanced podem variar dependendo de suas opções de arquitetura e configuração. Use as informações deste guia para criar e proteger aplicativos resilientes usando o Shield Advanced e para encaminhar quando precisar de ajuda especializada.
**Assinaturas e custos do Shield Advanced AWS WAF**
Sua assinatura do Shield Advanced cobre os custos de uso dos AWS WAF recursos padrão dos recursos que você protege com o Shield Advanced. As AWS WAF taxas padrão cobertas pelas proteções Shield Advanced são o custo por pacote de proteção (web ACL), o custo por regra e o preço base por milhão de solicitações para inspeção de solicitações na web, até 1.500 WCUs e até o tamanho padrão do corpo.
Ativar a mitigação automática da camada DDo S do aplicativo Shield Advanced adiciona um grupo de regras ao seu pacote de proteção (Web ACL) que usa 150 unidades de capacidade Web ACL (). WCUs Isso WCUs conta contra o uso da WCU em seu pacote de proteção (web ACL). Para obter mais informações, consulte [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md), [Como proteger a camada de aplicativos com o grupo de regras do Shield Advanced](ddos-automatic-app-layer-response-rg.md) e [Unidades de capacidade do Web ACL (WCUs) em AWS WAF](aws-waf-capacity-units.md).
Sua assinatura do Shield Advanced não cobre o uso AWS WAF de recursos que você não protege usando o Shield Advanced. Também não cobre nenhum custo adicional não padronizado AWS WAF para recursos protegidos. Exemplos de AWS WAF custos não padronizados são aqueles para o Bot Control, para a ação da CAPTCHA regra, para a web ACLs que usa mais de 1.500 WCUs e para inspecionar o corpo da solicitação além do tamanho padrão. A lista completa é fornecida na página AWS WAF de preços. Sua assinatura do Shield Advanced inclui acesso ao grupo Amazon Managed Rule de camada 7 DDo anti-S. Como parte de sua assinatura, você receberá até 50 bilhões de solicitações para AWS WAF recursos protegidos do Shield Advanced em um mês civil. Solicitações acima de 50 bilhões serão cobradas de acordo com a página AWS Shield Advanced de preços.
Para obter informações completas e exemplos de preços, consulte [Preços do Shield](https://aws.amazon.com/shield/pricing/) e [Preços do AWS WAF](https://aws.amazon.com/waf/pricing/).
**Cobrança da assinatura do Shield Advanced**
Se você for um revendedor de AWS canais, fale com a equipe da sua conta para obter informações e orientações. Essas informações de cobrança são para clientes que não são revendedores de AWS canais.
Para todos os outros, as seguintes diretrizes de assinatura e cobrança se aplicam:
+ Para contas que são membros de uma AWS Organizations organização, AWS as assinaturas do Shield Advanced são cobradas da conta pagante da organização, independentemente de a própria conta do pagador estar assinada.
+ Quando você assina várias contas que estão na mesma [família AWS Organizations de contas de faturamento consolidado](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html), um preço de assinatura cobre todas as contas inscritas na família. A organização deve possuir todas as Contas da AWS e todos os seus recursos.
+ Ao assinar várias contas para várias organizações, você ainda pode pagar uma taxa de assinatura em todas as organizações, contas e recursos, desde que seja proprietário de todas elas. Entre em contato com seu gerente de conta ou AWS suporte e solicite uma isenção de taxa sobre as cobranças de AWS Shield Advanced assinatura para todas as organizações, exceto uma.
Para obter informações detalhadas sobre preços e exemplos, consulte [Preços do AWS Shield](https://aws.amazon.com/shield/pricing/).
**Topics**
# Lista de AWS recursos que AWS Shield Advanced protegem
**nota**
As proteções Shield Advanced só estão habilitadas para recursos que você especificou explicitamente no Shield Advanced ou que você protege por meio de uma política AWS Firewall Manager Shield Advanced. O Shield Advanced não protege automaticamente seus recursos.
Você pode usar o Shield Advanced para monitoramento e proteção avançados com os seguintes tipos de recursos:
+ CloudFront Distribuições da Amazon. Para implantação CloudFront contínua, o Shield Advanced protege qualquer distribuição temporária associada a uma distribuição primária protegida.
+ Zonas hospedadas do Amazon Route 53.
+ AWS Global Accelerator aceleradores padrão.
+ Endereços IP EC2 elásticos da Amazon. O Shield Advanced protege os recursos associados aos endereços IP elásticos protegidos.
+ EC2 Instâncias da Amazon, por meio da associação com endereços IP EC2 elásticos da Amazon.
+ Os seguintes balanceadores de carga do Elastic Load Balancing (ELB):
+ Application Load Balancers.
+ Classic Load Balancers.
+ Balanceadores de carga de rede, por meio de associações com endereços IP da Amazon EC2 Elastic.
Para obter informações adicionais sobre proteções para esses tipos de recursos, consulte [Lista de recursos que AWS Shield Advanced protegem](ddos-protections-by-resource-type.md).
# AWS Shield Advanced capacidades e opções
AWS Shield Advanced a assinatura inclui os seguintes recursos e opções. Eles complementam os recursos de detecção e mitigação de DDo S que você já recebe. AWS
+ **AWS WAF integração** — o Shield Advanced usa AWS WAF web ACLs, regras e grupos de regras como parte das proteções da camada de aplicação. Para obter mais informações sobre AWS WAF, consulte[Como AWS WAF funciona](how-aws-waf-works.md).
**nota**
Sua assinatura do Shield Advanced cobre os custos de uso dos AWS WAF recursos padrão dos recursos que você protege com o Shield Advanced. As AWS WAF taxas padrão cobertas pelas proteções Shield Advanced são o custo por pacote de proteção (web ACL), o custo por regra e o preço base por milhão de solicitações para inspeção de solicitações na web, até 1.500 WCUs e até o tamanho padrão do corpo.
Ativar a mitigação automática da camada DDo S do aplicativo Shield Advanced adiciona um grupo de regras ao seu pacote de proteção (Web ACL) que usa 150 unidades de capacidade Web ACL (). WCUs Isso WCUs conta contra o uso da WCU em seu pacote de proteção (web ACL). Para obter mais informações, consulte [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md), [Como proteger a camada de aplicativos com o grupo de regras do Shield Advanced](ddos-automatic-app-layer-response-rg.md) e [Unidades de capacidade do Web ACL (WCUs) em AWS WAF](aws-waf-capacity-units.md).
Sua assinatura do Shield Advanced não cobre o uso AWS WAF de recursos que você não protege usando o Shield Advanced. Também não cobre nenhum custo adicional não padronizado AWS WAF para recursos protegidos. Exemplos de AWS WAF custos não padronizados são aqueles para o Bot Control, para a ação da CAPTCHA regra, para a web ACLs que usa mais de 1.500 WCUs e para inspecionar o corpo da solicitação além do tamanho padrão. A lista completa é fornecida na página AWS WAF de preços. Sua assinatura do Shield Advanced inclui acesso ao grupo Amazon Managed Rule de camada 7 DDo anti-S. Como parte de sua assinatura, você receberá até 50 bilhões de solicitações para AWS WAF recursos protegidos do Shield Advanced em um mês civil. Solicitações acima de 50 bilhões serão cobradas de acordo com a página AWS Shield Advanced de preços.
Para obter informações completas e exemplos de preços, consulte [Preços do Shield](https://aws.amazon.com/shield/pricing/) e [Preços do AWS WAF](https://aws.amazon.com/waf/pricing/).
+ **Mitigação automática da camada DDo S do aplicativo** — Você pode configurar o Shield Advanced para responder automaticamente para mitigar os ataques da camada de aplicativo (camada 7) contra seus recursos protegidos. Com a mitigação automática, o Shield Advanced impõe a limitação de AWS WAF taxa nas solicitações de fontes DDo S conhecidas e adiciona e gerencia automaticamente AWS WAF proteções personalizadas em resposta aos ataques S detectados. DDo Você pode configurar a mitigação automática para contar ou bloquear as solicitações da web que fazem parte de um ataque.
Para obter mais informações, consulte [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md).
+ **Detecção baseada em integridade**: você pode usar as verificações de integridade do Amazon Route 53 com o Shield Advanced para informar a detecção e mitigação de eventos. As verificações de integridade monitoram seu aplicativo de acordo com suas especificações, relatando integridade quando suas especificações são atendidas e não integridade quando não são. O uso de verificações de integridade com o Shield Advanced ajuda a evitar falsos positivos e fornece detecção e mitigação mais rápidas quando um recurso protegido não está íntegro. Você pode usar a detecção baseada em integridade para qualquer tipo de recurso, exceto as zonas hospedadas do Route 53. O engajamento proativo do Shield Advanced está disponível somente para recursos que tenham a detecção baseada em saúde habilitada.
Para obter mais informações, consulte [Detecção baseada em integridade usando verificações de integridade com o Shield Advanced e o Route 53](ddos-advanced-health-checks.md).
+ **Grupos de proteção**: você pode usar grupos de proteção para criar agrupamentos lógicos de seus recursos protegidos, para melhorar a detecção e a mitigação do grupo como um todo. Você pode definir os critérios de participação em um grupo de proteção para que os recursos recém-protegidos sejam incluídos automaticamente. Um recurso protegido pode pertencer a vários grupos de proteção.
Para obter mais informações, consulte [Agrupando suas proteções AWS Shield Advanced](ddos-protection-groups.md).
+ **Visibilidade aprimorada DDo dos eventos e ataques do S** — o Shield Advanced fornece acesso a métricas e relatórios avançados em tempo real para ampla visibilidade dos eventos e ataques aos seus AWS recursos protegidos. Você pode acessar essas informações por meio da API e do console Shield Advanced e por meio das CloudWatch métricas da Amazon.
Para obter mais informações, consulte [Visibilidade DDo dos eventos S com o Shield Advanced](ddos-viewing-events.md).
+ **Gerenciamento centralizado das proteções Shield Advanced por AWS Firewall Manager** — Você pode usar o Firewall Manager para aplicar automaticamente as proteções Shield Advanced às suas novas contas e recursos e para implantar AWS WAF regras na sua web. ACLs As políticas de proteção do Shield Advanced para o Firewall Manager estão incluídas sem custo adicional para os clientes do Shield Advanced. Você também pode centralizar as atividades de monitoramento do Shield Advanced para suas contas usando o Firewall Manager com um tópico do Amazon Simple Notification Service (SNS) ou do AWS Security Hub CSPM.
Para obter mais informações sobre o uso do Firewall Manager para gerenciar as proteções do Shield Advanced, consulte [AWS Firewall Manager](fms-chapter.md) e [Usando AWS Shield Advanced políticas no Firewall Manager](shield-policies.md). Para saber mais sobre a definição de preço de solicitações, consulte [Preços do AWS Firewall Manager](https://aws.amazon.com/firewall-manager/pricing/).
+ **AWS Shield Response Team (SRT)** — A SRT tem profunda experiência em proteger AWS a Amazon.com e suas subsidiárias. Como AWS Shield Advanced cliente, você pode entrar em contato com o SRT a qualquer momento para obter assistência durante um ataque DDo S que afete a disponibilidade do seu aplicativo. Você também pode trabalhar com a SRT para criar e gerenciar mitigações personalizadas para seus recursos. Para usar os serviços da DRT, você deve ser assinante do plano [Business Support](https://aws.amazon.com/premiumsupport/business-support/) ou [Enterprise Support](https://aws.amazon.com/premiumsupport/enterprise-support/).
Para obter mais informações, consulte [Resposta gerenciada a eventos DDo S com suporte do Shield Response Team (SRT)](ddos-srt-support.md).
+ **Envolvimento proativo**: com envolvimento proativo, o Shield Response Team (SRT) entrará em contato diretamente com você se a verificação de integridade do Amazon Route 53 associada ao seu recurso protegido tornar-se não íntegra durante um evento detectado pelo Shield Advanced. Isso permite que você interaja com especialistas mais rapidamente quando a disponibilidade do seu aplicativo puder ser afetada por um ataque suspeito.
Para obter mais informações, consulte [Como configurar um engajamento proativo para que o SRT entre em contato diretamente com você](ddos-srt-proactive-engagement.md).
+ **Oportunidades de proteção de custos** — O Shield Advanced oferece alguma proteção de custo contra picos em sua AWS fatura que podem resultar de um ataque DDo S contra seus recursos protegidos. Isso pode incluir cobertura para picos nas taxas de uso de transferência de dados (DTO) do Shield Advanced. O Shield Advanced fornece qualquer proteção de custo na forma de créditos de serviço do Shield Advanced.
Para obter mais informações, consulte [Solicitando um crédito AWS Shield Advanced após um ataque](ddos-request-service-credit.md).
# Decidir se deseja assinar AWS Shield Advanced e aplicar proteções adicionais
Analise os cenários desta seção para obter ajuda para decidir quais contas inscrever no AWS Shield Advanced e onde aplicar proteções adicionais. Com o Shield Advanced, você paga uma taxa de assinatura mensal para todas as contas criadas em uma conta de cobrança consolidada, além de taxas de uso com base em GB de dados transferidos. Para saber mais sobre os preços do Shield Advanced, consulte [Preços do AWS Shield Advanced](https://aws.amazon.com/shield/pricing/).
Para proteger um aplicativo e seus recursos com o Shield Advanced, você inscreve as contas que gerenciam o aplicativo no Shield Advanced e, em seguida, adiciona proteções aos recursos do aplicativo. Para saber mais sobre como inscrever contas e proteger recursos, consulte [Conf AWS Shield Advanced iguração](getting-started-ddos.md).
**Assinaturas e custos do Shield Advanced AWS WAF**
Sua assinatura do Shield Advanced cobre os custos de uso dos AWS WAF recursos padrão dos recursos que você protege com o Shield Advanced. As AWS WAF taxas padrão cobertas pelas proteções Shield Advanced são o custo por pacote de proteção (web ACL), o custo por regra e o preço base por milhão de solicitações para inspeção de solicitações na web, até 1.500 WCUs e até o tamanho padrão do corpo.
Ativar a mitigação automática da camada DDo S do aplicativo Shield Advanced adiciona um grupo de regras ao seu pacote de proteção (Web ACL) que usa 150 unidades de capacidade Web ACL (). WCUs Isso WCUs conta contra o uso da WCU em seu pacote de proteção (web ACL). Para obter mais informações, consulte [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md), [Como proteger a camada de aplicativos com o grupo de regras do Shield Advanced](ddos-automatic-app-layer-response-rg.md) e [Unidades de capacidade do Web ACL (WCUs) em AWS WAF](aws-waf-capacity-units.md).
Sua assinatura do Shield Advanced não cobre o uso AWS WAF de recursos que você não protege usando o Shield Advanced. Também não cobre nenhum custo adicional não padronizado AWS WAF para recursos protegidos. Exemplos de AWS WAF custos não padronizados são aqueles para o Bot Control, para a ação da CAPTCHA regra, para a web ACLs que usa mais de 1.500 WCUs e para inspecionar o corpo da solicitação além do tamanho padrão. A lista completa é fornecida na página AWS WAF de preços. Sua assinatura do Shield Advanced inclui acesso ao grupo Amazon Managed Rule de camada 7 DDo anti-S. Como parte de sua assinatura, você receberá até 50 bilhões de solicitações para AWS WAF recursos protegidos do Shield Advanced em um mês civil. Solicitações acima de 50 bilhões serão cobradas de acordo com a página AWS Shield Advanced de preços.
Para obter informações completas e exemplos de preços, consulte [Preços do Shield](https://aws.amazon.com/shield/pricing/) e [Preços do AWS WAF](https://aws.amazon.com/waf/pricing/).
**Cobrança da assinatura do Shield Advanced**
Se você for um revendedor de AWS canais, fale com a equipe da sua conta para obter informações e orientações. Essas informações de cobrança são para clientes que não são revendedores de AWS canais.
Para todos os outros, as seguintes diretrizes de assinatura e cobrança se aplicam:
+ Para contas que são membros de uma AWS Organizations organização, AWS as assinaturas do Shield Advanced são cobradas da conta pagante da organização, independentemente de a própria conta do pagador estar assinada.
+ Quando você assina várias contas que estão na mesma [família AWS Organizations de contas de faturamento consolidado](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html), um preço de assinatura cobre todas as contas inscritas na família. A organização deve possuir todas as Contas da AWS e todos os seus recursos.
+ Ao assinar várias contas para várias organizações, você ainda pode pagar uma taxa de assinatura em todas as organizações, contas e recursos, desde que seja proprietário de todas elas. Entre em contato com seu gerente de conta ou AWS suporte e solicite uma isenção de taxa sobre as cobranças de AWS Shield Advanced assinatura para todas as organizações, exceto uma.
Para obter informações detalhadas sobre preços e exemplos, consulte [Preços do AWS Shield](https://aws.amazon.com/shield/pricing/).
**Identificação dos aplicativos a serem protegidos**
Considere a implementação das proteções do Shield Advanced para aplicativos em que você precisa de qualquer um dos seguintes:
+ Disponibilidade garantida para os usuários do aplicativo.
+ Acesso rápido a especialistas em mitigação de DDo S se o aplicativo for afetado por um ataque DDo S.
+ Conscientização de AWS que o aplicativo pode ser afetado por um ataque DDo S e notificação de ataques AWS e escalonamento para suas equipes de segurança ou operações.
+ Previsibilidade nos custos da nuvem, inclusive quando um ataque DDo S afeta o uso dos AWS serviços.
Se um aplicativo ou seus recursos exigirem alguma das opções acima, considere criar assinaturas para as contas relacionadas.
**Identificando os recursos a serem protegidos**
Para cada conta inscrita, considere adicionar uma proteção do Shield Advanced a cada recurso que tenha qualquer uma das seguintes características:
+ O recurso atende usuários externos na internet.
+ O recurso está exposto à internet e também faz parte de um aplicativo crítico. Considere cada recurso exposto, independentemente de você pretender que seja acessado por usuários na internet.
+ O recurso é protegido por uma AWS WAF Web ACL.
Para saber mais sobre como criar e gerenciar proteções para seus recursos, consulte [Proteções de recursos em AWS Shield Advanced](ddos-resource-protections.md).
Além disso, siga as recomendações deste guia para ajudar a garantir a arquitetura de seu aplicativo para a resiliência DDo S e a configuração adequada dos recursos do Shield Advanced para obter proteções ideais.
# Exemplos de ataques DDo S
AWS Shield Advanced fornece proteção expandida contra vários tipos de ataques.
A lista a seguir descreve alguns tipos de ataques comuns:
**Ataques de reflexão de UDP**
Em ataques de reflexão UDP, um invasor pode fazer o spoofing da origem de uma solicitação e usar UDP para obter uma grande resposta do servidor. O tráfego de rede extra direcionado para o endereço IP atacado mascarado pode deixar o servidor de destino mais lento e evitar que usuários legítimos acessem os recursos necessários.
**flood TCP SYN**
O objetivo de um ataque SYN é esgotar os recursos disponíveis de um sistema, deixando conexões em estado meio aberto. Quando um usuário se conecta a um serviço de TCP, como um servidor web, o cliente envia um pacote SYN. O servidor retorna a confirmação e o cliente retorna sua própria confirmação, concluindo um handshake de três vias. Em um flood TCP SYN, a terceira confirmação nunca é retornada e o servidor fica aguardando uma resposta. Isso pode impedir que outros usuários se conectem ao servidor.
**DNS query flood**
Em uma inundação de consultas de DNS, um invasor usa várias consultas de DNS para esgotar os recursos de um servidor DNS. AWS Shield Advanced pode ajudar a fornecer proteção contra ataques de inundação de consultas de DNS nos servidores DNS do Route 53.
**Ataques de HTTP flood/cache busting (camada 7)**
Com um HTTP flood, incluindo floods `GET` e `POST`, um invasor envia várias solicitações HTTP que parecem ser de um usuário real do aplicativo web. Ataques cache busting são um tipo de HTTP flood que usa variações na string de consulta HTTP que impede o uso de conteúdo em cache localizado no edge e força o conteúdo a ser servido pelo servidor da web de origem, causando esforço adicional e potencialmente prejudicial no servidor web de origem.
# Como AWS Shield detecta eventos
AWS opera sistemas de detecção de nível de serviço para a AWS rede e AWS serviços individuais, para garantir que eles permaneçam disponíveis durante um ataque DDo S. Além disso, os sistemas de detecção em nível de recurso monitoram cada AWS recurso individual para garantir que o tráfego em direção ao recurso permaneça dentro dos parâmetros esperados. Essa combinação protege o AWS recurso e os AWS serviços direcionados, aplicando mitigações que eliminam pacotes inválidos conhecidos, destacam o tráfego potencialmente malicioso e priorizam o tráfego dos usuários finais.
Os eventos detectados aparecem nos resumos de eventos, nos detalhes do ataque e nas CloudWatch métricas da Amazon do Shield Advanced como o nome do vetor de ataque DDo S ou como `Volumetric` se a avaliação fosse baseada no volume de tráfego em vez da assinatura. Para obter mais informações sobre as dimensões do vetor de ataque que estão disponíveis na `DDoSDetected` CloudWatch métrica, consulte[AWS Shield Advanced métricas](shield-metrics.md).
**Topics**
+ [AWS Shield lógica de detecção para ameaças na camada de infraestrutura (camada 3 e camada 4)](ddos-event-detection-infrastructure.md)
+ [Lógica de detecção do Shield Advanced para ameaças na camada de aplicativo (camada 7)](ddos-event-detection-application.md)
+ [Lógica de detecção do Shield Advanced para vários recursos em um aplicativo](ddos-event-detection-multiple-resources.md)
# AWS Shield lógica de detecção para ameaças na camada de infraestrutura (camada 3 e camada 4)
Esta página explica como a detecção de eventos funciona nas camadas de infraestrutura (rede e transporte).
A lógica de detecção usada para proteger AWS os recursos direcionados contra ataques DDo S nas camadas de infraestrutura (camada 3 e camada 4) depende do tipo de recurso e se o recurso está protegido com AWS Shield Advanced.
**Detecção para Amazon CloudFront e Amazon Route 53**
Quando você serve seu aplicativo web com CloudFront o Route 53, todos os pacotes para o aplicativo são inspecionados por um sistema de mitigação DDo S totalmente embutido, que não introduz nenhuma latência observável. DDoOs ataques S contra CloudFront distribuições e zonas hospedadas do Route 53 são mitigados em tempo real. Essas proteções se aplicam independentemente de você usar o AWS Shield Advanced.
Siga as melhores práticas de uso CloudFront do Route 53 como ponto de entrada do seu aplicativo web sempre que possível para a detecção e mitigação mais rápidas dos eventos DDo S.
**AWS Global Accelerator Detecção para serviços regionais**
A detecção em nível de recurso protege aceleradores e recursos AWS Global Accelerator padrão que são lançados em AWS regiões, como Classic Load Balancers, Application Load Balancers e endereços IP elásticos (). EIPs Esses tipos de recursos são monitorados em busca de elevações de tráfego que podem indicar a presença de um ataque DDo S que requer uma mitigação. A cada minuto, o tráfego de cada recurso da AWS é avaliado. Se o tráfego para um recurso for elevado, verificações adicionais serão realizadas para medir a capacidade do recurso.
O Shield executa as seguintes verificações padrão:
+ **Instâncias do Amazon Elastic Compute Cloud (Amazon EC2), EIPs anexados às instâncias do Amazon EC2**: o Shield recupera a capacidade do recurso protegido. A capacidade depende do tipo de instância do alvo, do tamanho da instância e de outros fatores, como se a instância está usando redes avançadas.
+ **Classic Load Balancers e Application Load Balancers**: o Shield recupera a capacidade do nó do balanceador de carga alvo.
+ **EIPs conectado aos Network Load Balancers** — o Shield recupera a capacidade do balanceador de carga de destino. A capacidade é independente da configuração do grupo do balanceador de carga alvo.
+ **AWS Global Accelerator aceleradores padrão** — o Shield recupera a capacidade, que é baseada na configuração do endpoint.
Essas avaliações ocorrem em várias dimensões do tráfego de rede, como porta e protocolo. Se a capacidade do recurso alvo for excedida, a Shield coloca uma mitigação DDo S. As mitigações impostas pela Shield reduzirão o tráfego DDo S, mas talvez não o eliminem. O Shield também pode oferecer uma mitigação se uma fração da capacidade do recurso for excedida em uma dimensão de tráfego consistente com os vetores de ataque DDo S conhecidos. A Shield coloca essa mitigação em um tempo de vida limitado (TTL), que se estende enquanto o ataque estiver em andamento.
**nota**
As mitigações impostas pelo Shield reduzirão o tráfego DDo S, mas talvez não o eliminem. Você pode aumentar o Shield com soluções como AWS Network Firewall ou um firewall no host, como iptables para impedir que seu aplicativo processe tráfego que não é válido para seu aplicativo ou que não foi gerado por usuários finais legítimos.
As proteções do Shield Advanced adicionam o seguinte às atividades existentes de detecção do Shield:
+ **Limites de detecção mais baixos**: o Shield Advanced coloca as mitigações em metade da capacidade calculada. Isso pode fornecer mitigações mais rápidas para ataques que aumentam lentamente e mitigação de ataques que têm uma assinatura volumétrica mais ambígua.
+ **Proteção contra ataques intermitentes**: o Shield Advanced coloca mitigações com um aumento exponencial do tempo de vida (TTL), com base na frequência e duração dos ataques. Isso mantém as mitigações em vigor por mais tempo quando um recurso é atacado com frequência e quando um ataque ocorre em intervalos curtos.
+ **Detecção baseada em integridade**: quando você associa uma verificação de integridade do Route 53 a um recurso protegido do Shield Advanced, o status da verificação de saúde é usado na lógica de detecção. Durante um evento detectado, se a verificação de integridade estiver íntegra, o Shield Advanced exige mais confiança de que o evento é um ataque antes de fazer uma mitigação. Se, em vez disso, a verificação de integridade não estiver íntegra, o Shield Advanced poderá fazer uma mitigação antes mesmo que a confiança seja estabelecida. Esse atributo ajuda a evitar falsos positivos e fornece reações mais rápidas aos ataques que afetam seu aplicativo. Para saber mais sobre verificações de integridade com o Shield Advanced, consulte [Detecção baseada em integridade usando verificações de integridade com o Shield Advanced e o Route 53](ddos-advanced-health-checks.md).
# Lógica de detecção do Shield Advanced para ameaças na camada de aplicativo (camada 7)
Essa página explica como a detecção de eventos funciona para a camada de aplicativo.
AWS Shield Advanced fornece detecção de camadas de aplicativos web para CloudFront distribuições protegidas da Amazon e Application Load Balancers. Ao proteger esses tipos de recursos com o Shield Advanced, você pode associar uma ACL da web do AWS WAF à sua proteção para permitir a detecção da camada do aplicativo da web. O Shield Advanced consome dados de solicitação para a ACL da web associada e cria uma linha de base de tráfego para seu aplicativo. A detecção da camada de aplicativos da web depende da integração nativa entre o Shield Advanced e o AWS WAF. Para saber mais sobre as proteções da camada de aplicação, incluindo a associação de uma ACL AWS WAF da web a um recurso protegido do Shield Advanced, consulte. [Protegendo a camada de aplicação (camada 7) com AWS Shield Advanced e AWS WAF](ddos-app-layer-protections.md)
Para a detecção da camada de aplicativos web, o Shield Advanced monitora o tráfego do aplicativo e o compara às linhas de base históricas em busca de anomalias. Esse monitoramento abrange o volume total e a composição do tráfego. Durante um ataque DDo S, esperamos que o volume e a composição do tráfego mudem, e o Shield Advanced exige um desvio estatisticamente significativo em ambos para declarar um evento.
O Shield Advanced realiza suas medições em relação a janelas de tempo históricas. Essa abordagem reduz as notificações de falsos positivos provenientes de mudanças legítimas no volume de tráfego ou de alterações no tráfego que correspondam a um padrão esperado, como uma venda oferecida no mesmo horário todos os dias.
**nota**
Evite falsos positivos em suas proteções do Shield Advanced dando tempo ao Shield Advanced para estabelecer linhas de base que representem padrões de tráfego normais e legítimos. O Shield Advanced começa a coletar informações para sua linha de base quando você associa uma ACL da Web ao seu recurso protegido. Associe uma ACL da web ao seu recurso protegido pelo menos 24 horas antes de qualquer evento planejado que possa causar padrões incomuns em seu tráfego na web. A detecção da camada de aplicativo da web do Shield Advanced é mais precisa quando se observa 30 dias de tráfego normal.
O tempo que o Shield Advanced leva para detectar um evento é afetado pela quantidade de mudanças que ele observa no volume de tráfego. Para mudanças de volume menores, o Shield Advanced observa o tráfego por um período mais longo, a fim de aumentar a confiança de que um evento está ocorrendo. Para mudanças de volume maiores, o Shield Advanced detecta e relata um evento mais rapidamente.
Uma regra baseada em intervalos em sua ACL da Web, seja adicionada por você ou pelo atributo de mitigação automática da camada de aplicativo do Shield Advanced, pode mitigar um ataque antes que ele atinja um nível detectável. Para obter mais informações sobre a mitigação automática da camada DDo S do aplicativo, consulte. [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md)
**nota**
Você pode arquitetar seu aplicativo para reduzir a escala horizontalmente em resposta ao tráfego ou à carga elevados para garantir que ele não seja afetado por pequenas inundações de solicitações. Com o Shield Advanced, seus recursos protegidos são cobertos pela proteção de custos. Isso ajuda a protegê-lo contra aumentos inesperados em sua conta de nuvem que podem ocorrer como resultado de um ataque DDo S. Para saber mais sobre a proteção de custos do Shield Advanced, consulte [Solicitando um crédito AWS Shield Advanced após um ataque](ddos-request-service-credit.md).
# Lógica de detecção do Shield Advanced para vários recursos em um aplicativo
Essa página explica como a detecção de eventos funciona para vários recursos em um aplicativo.
Você pode usar grupos de AWS Shield Advanced proteção para criar coleções de recursos protegidos que fazem parte do mesmo aplicativo. Você pode escolher quais recursos protegidos colocar em um grupo ou indicar que todos os recursos do mesmo tipo devem ser tratados como um grupo. Por exemplo, você pode criar um grupo de todos os Application Load Balancers. Quando você cria um grupo de proteção, a detecção do Shield Advanced agrega todo o tráfego dos recursos protegidos dentro do grupo. Isso é útil se você tiver muitos recursos, cada um com uma pequena quantidade de tráfego, mas com um grande volume agregado. Você também pode usar grupos de proteção para preservar as linhas de base do aplicativo, no caso de implantações azuis/verdes em que o tráfego é transferido entre recursos protegidos.
É possível optar por agregar o tráfego do seu grupo de proteção de uma das seguintes maneiras:
+ **Soma**: essa agregação combina todo o tráfego entre os recursos no grupo de proteção. Você pode usar essa agregação para garantir que os recursos recém-criados tenham uma linha de base existente e para reduzir a sensibilidade de detecção, o que pode ajudar a evitar falsos positivos.
+ **Média**: essa agregação usa a média de todo o tráfego no grupo de proteção. Você pode usar essa agregação para aplicativos em que o tráfego entre recursos é uniforme, como balanceadores de carga.
+ **Máximo**: essa agregação usa o maior tráfego de qualquer recurso no grupo de proteção. Você pode usar essa agregação quando há vários níveis de um aplicativo em um grupo de proteção. Por exemplo, você pode ter um grupo de proteção que inclua uma CloudFront distribuição, sua origem do Application Load Balancer e os alvos da instância Amazon EC2 do Application Load Balancer.
Você também pode usar grupos de proteção para melhorar a velocidade com que a Shield Advanced aplica mitigações, para ataques que visam vários aceleradores Elastic ou padrão voltados para a Internet. IPs AWS Global Accelerator Quando um recurso em um grupo de proteção é o alvo, o Shield Advanced estabelece confiança nos outros recursos do grupo. Isso coloca a detecção do Shield Advanced em alerta e pode reduzir o tempo necessário para criar mitigações adicionais.
Para saber mais sobre os grupos, consulte [Agrupando suas proteções AWS Shield Advanced](ddos-protection-groups.md).
# Como AWS Shield atenua os eventos
Esta página apresenta como funciona a mitigação de AWS Shield eventos.
A lógica de mitigação que protege seu aplicativo pode variar dependendo da arquitetura do aplicativo. Ao proteger uma aplicação web com a Amazon CloudFront e o Amazon Route 53, você se beneficia de mitigações específicas para casos de uso da web e do DNS e que protegem todo o tráfego dos serviços. Quando o ponto de entrada do seu aplicativo é um recurso executado em uma AWS região, a lógica de mitigação varia de acordo com o serviço, o tipo de recurso e o uso do. AWS Shield Advanced
AWS DDoOs sistemas de mitigação S são desenvolvidos pelos engenheiros da Shield e estão intimamente integrados aos AWS serviços. Os engenheiros levam em consideração aspectos de sua arquitetura, como a capacidade e a integridade dos recursos alvo. Os engenheiros da Shield monitoram continuamente a eficácia e o desempenho dos sistemas de mitigação DDo S e são capazes de responder rapidamente quando novas ameaças são descobertas ou antecipadas.
Você pode arquitetar seu aplicativo para escalar em resposta ao tráfego elevado ou à carga elevada, para ajudar a garantir que ele não seja afetado por pequenos fluxos de solicitações. Se você usa o Shield Advanced para proteger seus recursos, receberá cobertura contra aumentos inesperados em sua conta de nuvem que possam ocorrer como resultado de um ataque DDo S.
**Mitigações da infraestrutura**
Para ataques na camada de infraestrutura, AWS Shield DDo os sistemas de mitigação S estão presentes na fronteira da AWS rede e nos locais AWS periféricos. A colocação de vários níveis de controles de segurança em toda a AWS infraestrutura fornece defense-in-depth aos seus aplicativos em nuvem.
O Shield mantém DDo os sistemas de mitigação S em todos os pontos de entrada da Internet. Quando o Shield detecta um ataque DDo S, para cada ponto de entrada, ele redireciona o tráfego pelos sistemas de mitigação DDo S no mesmo local. Isso não introduz nenhuma latência adicional observável e fornece uma capacidade de mitigação de mais de 100 TeraBits por segundo (Tbps) em todas as AWS regiões e todos os pontos de presença. O Shield protege a disponibilidade dos seus recursos sem redirecionar o tráfego para centros de depuração externos ou remotos, o que pode aumentar a latência.
+ Na fronteira da AWS rede, para qualquer AWS serviço ou recurso, DDo os sistemas de mitigação S mitigam os ataques da camada de infraestrutura provenientes da Internet. Os sistemas realizam suas mitigações quando sinalizados pela detecção do Shield ou por um engenheiro no Shield Response Team (SRT).
+ Nos pontos AWS de presença, DDo os sistemas de mitigação S inspecionam continuamente cada pacote que é encaminhado para as distribuições da Amazon CloudFront e para as zonas hospedadas do Amazon Route 53, independentemente de sua origem. Quando necessário, os sistemas aplicam mitigações que são projetadas especificamente para o tráfego da web e do DNS. Um benefício adicional de usar a Amazon CloudFront e o Amazon Route 53 para proteger seus aplicativos web é que DDo os ataques S são imediatamente mitigados, sem exigir um sinal da detecção do Shield.
**Mitigações da camada de aplicação**
O Shield Advanced fornece mitigações na camada de aplicativos web para as CloudFront distribuições e os balanceadores de carga de aplicativos da Amazon nos quais você habilitou as proteções do Shield Advanced. Ao habilitar a proteção, você associa uma AWS WAF Web ACL ao recurso para habilitar a detecção da camada de aplicação Web. Além disso, você tem a opção de ativar a mitigação automática da camada de aplicação, o que instrui o Shield Advanced a gerenciar as proteções para você durante DDo um ataque S.
O Shield fornece apenas mitigações personalizadas para ataques na camada de aplicativo em recursos para os quais você habilitou o Shield Advanced e a mitigação automática da camada de aplicativo. Com a mitigação automática, o Shield Advanced impõe a limitação de AWS WAF taxa nas solicitações de fontes DDo S conhecidas e adiciona e gerencia automaticamente AWS WAF proteções personalizadas em resposta aos ataques S detectados. DDo Para obter informações detalhadas sobre mitigações desse tipo, consulte [Como o Shield Advanced gerencia a mitigação automática](ddos-automatic-app-layer-response-behavior.md).
Uma regra baseada em intervalos em sua ACL da Web, seja adicionada por você ou adicionada pelo atributo de mitigação automática da camada de aplicativo do Shield Advanced, pode mitigar um ataque antes que ele atinja um nível detectável. Para obter mais informações sobre a detecção, consulte [Lógica de detecção do Shield Advanced para ameaças na camada de aplicativo (camada 7)](ddos-event-detection-application.md).
**Topics**
+ [Lista de recursos de mitigação de AWS Shield DDo S](ddos-event-mitigation-features.md)
+ [AWS Shield lógica de mitigação para CloudFront e Route 53](ddos-event-mitigation-logic-continuous-inspection.md)
+ [AWS Shield lógica de mitigação para regiões AWS](ddos-event-mitigation-logic-regions.md)
+ [AWS Shield lógica de mitigação para aceleradores padrão AWS Global Accelerator](ddos-event-mitigation-logic-gax.md)
+ [AWS Shield Advanced lógica de mitigação para a Elastic IPs](ddos-event-mitigation-logic-adv-eip.md)
+ [AWS Shield Advanced lógica de mitigação para aplicativos web](ddos-event-mitigation-logic-adv-web-app.md)
# Lista de recursos de mitigação de AWS Shield DDo S
As principais características da mitigação de AWS Shield DDo S são as seguintes:
+ **Validação de pacotes**: isso garante que cada pacote inspecionado esteja em conformidade com uma estrutura esperada e seja válido para seu protocolo. As validações de protocolo suportadas incluem IP, TCP (incluindo cabeçalho e opções), UDP, ICMP, DNS e NTP.
+ **Listas de controle de acesso (ACLs) e modeladores** — Uma ACL avalia o tráfego em relação a atributos específicos e descarta o tráfego correspondente ou o mapeia para um modelador. O shaper limita a taxa de pacotes para o tráfego correspondente, descartando pacotes em excesso para conter o volume que chega ao destino. AWS Shield Os engenheiros de detecção e do Shield Response Team (SRT) podem fornecer alocações de taxas dedicadas para o tráfego esperado e alocações de taxas mais restritivas para o tráfego com atributos que correspondem aos vetores de ataque S conhecidos DDo. Os atributos que uma ACL pode combinar incluem porta, protocolo, sinalizadores TCP, endereço de destino, país de origem e padrões arbitrários na carga útil do pacote.
+ **Pontuação de suspeita**: usa o conhecimento que o Shield tem do tráfego esperado para aplicar uma pontuação a cada pacote. Pacotes que seguem mais de perto os padrões de tráfego em boas condições recebem uma pontuação de suspeita mais baixa. A observação de atributos conhecidos de tráfego incorreto pode aumentar a pontuação de suspeita de um pacote. Quando é necessário limitar a taxa de pacotes, o Shield descarta primeiro os pacotes com maior pontuação de suspeita. Isso ajuda a Shield a mitigar ataques DDo S conhecidos e de dia zero, evitando falsos positivos.
+ **Proxy TCP SYN**: isso fornece proteção contra floods TCP SYN enviando cookies TCP SYN para desafiar novas conexões antes de permitir que elas passem para o serviço protegido. O proxy TCP SYN fornecido pela mitigação Shield DDo S não tem estado, o que permite mitigar os maiores ataques de inundação TCP SYN conhecidos sem atingir a exaustão do estado. Isso é obtido por meio da integração com AWS os serviços para transferir o estado da conexão, em vez de manter um proxy contínuo entre o cliente e o serviço protegido. Atualmente, o proxy TCP SYN está disponível na Amazon e no CloudFront Amazon Route 53.
+ **Distribuição de intervalos**: isso ajusta continuamente os valores do shaper por local com base no padrão de entrada de tráfego em direção a um recurso protegido. Isso evita a limitação da taxa de tráfego de clientes que podem não entrar na AWS rede uniformemente.
# AWS Shield lógica de mitigação para CloudFront e Route 53
Esta página explica como a mitigação do Shield DDo S inspeciona continuamente o tráfego e o Route 53. CloudFront Esses serviços operam a partir de uma rede distribuída AWS globalmente de pontos de presença que fornecem amplo acesso à capacidade de mitigação DDo S da Shield e entregam seu aplicativo a partir de uma infraestrutura mais próxima de seus usuários finais.
**Importante**
AWS Shield Advanced não suporta CloudFront inquilinos.
+ **CloudFront**— As mitigações do Shield DDo S só permitem que o tráfego válido para aplicativos da web passe para o serviço. Isso fornece proteção automática contra muitos vetores DDo S comuns, como ataques de reflexão UDP.
CloudFront mantém conexões persistentes com a origem do aplicativo, as inundações de TCP SYN são automaticamente mitigadas por meio da integração com o recurso de proxy Shield TCP SYN e o Transport Layer Security (TLS) é encerrado na borda. Esses recursos combinados garantem que a origem do seu aplicativo receba apenas solicitações da web bem formadas e que esteja protegida contra ataques de camada DDo S inferior, inundações de conexão e abuso de TLS.
CloudFront usa uma combinação de direção de tráfego DNS e roteamento anycast. Essas técnicas melhoram a resiliência do seu aplicativo mitigando ataques próximos à origem, fornecendo isolamento de falhas e garantindo acesso à capacidade de mitigar os maiores ataques conhecidos.
+ **Route 53**: as mitigações do Shield só permitem que solicitações de DNS válidas cheguem ao serviço. O Shield atenua as inundações de consultas de DNS usando a pontuação de suspeita que prioriza consultas reconhecidamente válidas e desprioriza as consultas que contêm atributos de ataque S suspeitos ou conhecidos. DDo
O Route 53 usa fragmentação aleatória para fornecer um conjunto exclusivo de quatro endereços IP do resolvedor para cada zona hospedada, tanto para e. IPv4 IPv6 Cada endereço IP corresponde a um subconjunto diferente de localizações do Route 53. Cada subconjunto de localização consiste em servidores DNS autoritativos que se sobrepõem apenas parcialmente à infraestrutura em qualquer outro subconjunto. Isso garante que, se uma consulta do usuário falhar por qualquer motivo, ela será atendida com sucesso em uma nova tentativa.
O Route 53 usa o roteamento anycast para direcionar consultas ao DNS ao ponto de presença mais próximo, com base no local da borda. O Anycast também distribui o tráfego DDo S para vários locais periféricos, o que impede que os ataques se concentrem em um único local.
Além da velocidade de mitigação, CloudFront o Route 53 fornece amplo acesso à capacidade distribuída globalmente do Shield. Para aproveitar esses recursos, use esses serviços como ponto de entrada de seus aplicativos web dinâmicos ou estáticos.
Para saber mais sobre como usar o CloudFront Route 53 para proteger aplicativos web, consulte [Como ajudar a proteger aplicativos web dinâmicos contra ataques DDo S usando o Amazon CloudFront e o Amazon Route 53](https://aws.amazon.com/blogs/security/how-to-protect-dynamic-web-applications-against-ddos-attacks-by-using-amazon-cloudfront-and-amazon-route-53/). Para saber mais sobre isolamento de falhas no Route 53, consulte [Um estudo de caso sobre isolamento global de falhas](https://aws.amazon.com/blogs/architecture/a-case-study-in-global-fault-isolation/).
# AWS Shield lógica de mitigação para regiões AWS
Esta página explica como a lógica de mitigação de eventos do Shield funciona nas AWS regiões.
Os recursos lançados nas AWS regiões são protegidos por sistemas de mitigação AWS Shield DDo S colocados pela detecção em nível de recurso do Shield. Os recursos regionais incluem Elastic IPs (EIPs), Classic Load Balancers e Application Load Balancers.
Antes de fazer uma mitigação, o Shield identifica o recurso alvo e sua capacidade. O Shield usa a capacidade de determinar o tráfego total máximo que suas mitigações devem permitir que seja encaminhado para o recurso. As listas de controle de acesso (ACLs) e outros modeladores dentro da mitigação podem diminuir os volumes permitidos para algum tráfego, por exemplo, tráfego que corresponde a vetores de ataque DDo S conhecidos ou que não se espera que venha em grande volume. Isso limita ainda mais a quantidade de tráfego que as mitigações permitem para ataques de reflexão UDP ou para tráfego TCP que possuem sinalizadores TCP SYN ou FIN.
O Shield determina a capacidade e coloca as mitigações de forma diferente para cada tipo de recurso.
+ Para uma instância do Amazon EC2 ou um EIP anexado a uma instância do Amazon EC2, o Shield calcula a capacidade com base no tipo de instância e em outros atributos da instância, como se a instância tivesse uma rede aprimorada habilitada.
+ Para um Application Load Balancer ou Classic Load Balancer, o Shield calcula a capacidade individualmente para cada nó de destino do balanceador de carga. DDoAs mitigações de ataque S para esses recursos são fornecidas por uma combinação de mitigações Shield DDo S e escalabilidade automática pelo balanceador de carga. Quando o Shield Response Team (SRT) está envolvido em um ataque contra um recurso do Application Load Balancer ou do Classic Load Balancer, ele pode acelerar o escalonamento como uma medida adicional de proteção.
+ O Shield calcula a capacidade de alguns AWS recursos com base na capacidade disponível da AWS infraestrutura subjacente. Esses tipos de recursos incluem balanceadores de carga de rede (NLBs) e recursos que roteiam o tráfego por meio de balanceadores de carga de gateway ou. AWS Network Firewall
**nota**
Proteja seus balanceadores de carga de rede conectando dispositivos EIPs protegidos pelo Shield Advanced. Você pode trabalhar com o SRT para criar mitigações personalizadas com base no tráfego e na capacidade esperados do aplicativo subjacente.
Quando a Shield coloca uma mitigação, os limites de taxa iniciais que a Shield define na lógica de mitigação são aplicados igualmente a cada sistema de mitigação Shield S. DDo Por exemplo, se o Shield colocar uma mitigação com um limite de 100.000 pacotes por segundo (pps), ele inicialmente permitirá 100.000 pps em cada local. Em seguida, o Shield agrega continuamente métricas de mitigação para determinar a proporção real de tráfego e usa a proporção para adaptar o limite de taxa para cada local. Isso evita falsos positivos e garante que as mitigações não sejam excessivamente permissivas.
# AWS Shield lógica de mitigação para aceleradores padrão AWS Global Accelerator
Esta página explica como a lógica de mitigação de eventos do Shield funciona para aceleradores AWS Global Accelerator padrão. As mitigações do Shield permitem apenas que o tráfego válido alcance os endpoints de receptor de um acelerador padrão do Global Accelerator.
Os aceleradores padrão são implantados globalmente e fornecem endereços IP que você pode usar para rotear o tráfego para AWS recursos em qualquer AWS região. Os limites de taxa que o Shield impõe para a mitigação do Global Accelerator são baseados nas capacidades dos recursos para os quais o acelerador padrão direciona o tráfego. O Shield coloca mitigações quando o tráfego total excede a taxa determinada e também quando uma fração dessa taxa é excedida para vetores S conhecidos DDo.
Ao configurar um acelerador padrão, você define grupos de endpoints para cada região AWS para a qual direcionará o tráfego para seu aplicativo. Quando a Shield faz uma mitigação, ela calcula a capacidade de cada grupo de endpoints e atualiza adequadamente os limites de taxa em cada sistema de mitigação Shield DDo S. A taxa varia para cada local, com base nas suposições feitas pela Shield sobre como o tráfego será roteado da Internet para seus AWS recursos. A capacidade de um grupo de endpoints é calculada como o número de recursos no grupo multiplicado pela menor capacidade de qualquer recurso no grupo. Em intervalos regulares, o Shield recalcula a capacidade do seu aplicativo e atualiza os limites de taxa conforme necessário.
**nota**
Usar discagens de tráfego para alterar a porcentagem de tráfego direcionado a um grupo de endpoints não altera a forma como a Shield calcula ou distribui os limites de taxa para seus DDo sistemas de mitigação S. Se você usa discagens de tráfego, configure seus grupos de endpoints para se espelharem em termos de tipo e quantidade de recursos. Isso ajuda a garantir que a capacidade calculada pelo Shield seja representativa dos recursos que estão fornecendo tráfego para seu aplicativo.
Para obter mais informações sobre grupos de endpoints e discagens de tráfego no Global Accelerator, consulte [Grupos de endpoints em aceleradores padrão AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoint-groups.html).
# AWS Shield Advanced lógica de mitigação para a Elastic IPs
Esta página explica como a lógica de mitigação de eventos do Shield funciona para a Elastic IPs com. AWS Shield Advanced Quando você protege um Elastic IP (EIP) com AWS Shield Advanced, o Shield Advanced aprimora as mitigações que a Shield coloca durante DDo um evento S.
Os sistemas de mitigação Shield Advanced DDo S replicam a configuração Network ACL (NACL) para a sub-rede pública à qual o EIP está associado. Por exemplo, se sua NACL estiver configurada para bloquear todo o tráfego UDP, o Shield Advanced mescla essa regra com as mitigações que o Shield coloca.
Essa funcionalidade adicional pode ajudá-lo a evitar riscos de disponibilidade devido ao tráfego que não é válido para seu aplicativo. Você também pode usar NACLs para bloquear endereços IP de origem individuais ou intervalos CIDR de endereços IP de origem. Essa pode ser uma ferramenta de mitigação útil para ataques DDo S que não são distribuídos. Ele também permite que você gerencie facilmente suas próprias listas de permissões ou bloqueie endereços IP que não deveriam se comunicar com seu aplicativo, sem depender da intervenção de AWS engenheiros.
# AWS Shield Advanced lógica de mitigação para aplicativos web
AWS Shield Advanced usa AWS WAF para mitigar ataques na camada de aplicativos da web. AWS WAF está incluído no Shield Advanced sem custo adicional.
**Proteção padrão da camada da aplicação**
Ao proteger uma CloudFront distribuição da Amazon ou um Application Load Balancer com o Shield Advanced, você pode usar o Shield Advanced para associar uma ACL AWS WAF da web ao seu recurso protegido, caso ainda não tenha uma associada. Se você ainda não configurou uma web ACL, pode usar o assistente de console Shield Advanced para criar uma e adicionar uma regra baseada em intervalos a ela. Uma regra baseada em intervalos limita o número de solicitações por janela de tempo de cinco minutos para cada endereço IP, fornecendo proteções básicas contra floods de solicitações na camada de aplicativos web. Você pode configurar o intervalo, começando em 10. Para obter mais informações, consulte [Protegendo a camada de aplicação com AWS WAF web ACLs e Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md).
Você também pode usar o AWS WAF serviço para gerenciar a Web ACL. Por meio AWS WAF disso, você pode expandir a configuração da ACL da web para fazer coisas como inspecionar componentes específicos da solicitação da web em busca de correspondências ou padrões de seqüências de caracteres, adicionar tratamento personalizado de solicitações e respostas e comparar com a geolocalização da origem da solicitação. Para obter mais informações sobre AWS WAF regras, consulte[AWS WAF regras](waf-rules.md).
**Mitigação automática da camada de aplicativos**
Para maior proteção, ative a mitigação automática da camada de aplicação do Shield Advanced. Com essa opção, o Shield Advanced mantém uma regra de limitação de AWS WAF taxa para solicitações de fontes DDo S conhecidas e fornece mitigações personalizadas para ataques S detectados DDo.
Quando o Shield Avançado detecta um ataque a um recurso protegido, ele tenta identificar uma assinatura de ataque que isole o tráfego de ataque do tráfego normal para a aplicação. O Shield Advanced avalia a assinatura de ataque identificada em relação aos padrões históricos de tráfego do recurso que está sob ataque, bem como de qualquer outro recurso associado à mesma ACL da web.
Se o Shield Advanced determinar que a assinatura do ataque isola somente o tráfego envolvido no ataque DDo S, ele implementará a assinatura em AWS WAF regras dentro da ACL da web associada. Você pode instruir o Shield Advanced para implementar mitigações que contabilizem apenas o tráfego com o qual elas coincidem ou que o bloqueiem, e você pode alterar a configuração a qualquer momento. Quando o Shield Advanced determina que suas regras de mitigação não são mais necessárias, ele as remove da ACL da web. Para obter mais informações sobre a mitigação de eventos para a camada da aplicação, consulte [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md).
Para obter mais informações sobre as mitigações para a camada da aplicação do Shield Avançado, consulte [Protegendo a camada de aplicação (camada 7) com AWS Shield Advanced e AWS WAF](ddos-app-layer-protections.md).
# Construindo arquiteturas resilientes DDo S básicas com o Shield Advanced
Esta página explica a resiliência do Distributed Denial of Service (DDoS) e apresenta dois exemplos de arquiteturas.
DDoA resiliência S é a capacidade da arquitetura de seu aplicativo de resistir aos ataques DDo S e, ao mesmo tempo, continuar atendendo aos usuários finais legítimos. Um aplicativo altamente resiliente pode permanecer disponível durante um ataque com impacto mínimo nas métricas de desempenho, como erros ou latência. Esta seção mostra alguns exemplos comuns de arquiteturas e descreve como usar os recursos de detecção e mitigação de DDo S fornecidos pelo AWS Shield Advanced para aumentar sua DDo resiliência S.
Os exemplos de arquiteturas nesta seção destacam os AWS serviços que oferecem os maiores benefícios de resiliência DDo S para seus aplicativos implantados. Os benefícios dos serviços destacados incluem os seguintes:
+ **Acesso à capacidade de rede distribuída globalmente** — Os serviços Amazon CloudFront, AWS Global Accelerator, e Amazon Route 53 fornecem acesso à Internet e capacidade de mitigação de DDo S em toda a rede de borda AWS global. Isso é útil para mitigar ataques volumétricos maiores, que podem atingir terabits em escala. Você pode executar seu aplicativo em qualquer AWS região e usar esses serviços para proteger a disponibilidade e otimizar o desempenho para seus usuários legítimos.
+ **Proteção contra vetores de ataque da camada DDo S do aplicativo Web — Os** ataques da camada DDo S do aplicativo Web são melhor mitigados usando uma combinação de escala do aplicativo e um firewall de aplicativo da web (WAF). O Shield Advanced usa registros de inspeção de solicitações da web AWS WAF para detectar anomalias que podem ser mitigadas automaticamente ou por meio da interação com a AWS Shield Response Team (SRT). A mitigação automática está disponível por meio de regras AWS WAF baseadas em taxas implantadas e também por meio da mitigação automática da camada S do aplicativo Shield Advanced. DDo
Além de analisar esses exemplos, analise e siga as melhores práticas aplicáveis em [AWS Best DDo Practices for S Resiliency.](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency)
**Topics**
+ [Exemplo de arquitetura de resiliência Shield Advanced DDo S para aplicativos web comuns](ddos-resiliency-example-web.md)
+ [Exemplo de arquitetura de resiliência Shield Advanced DDo S para aplicativos TCP e UDP](ddos-resiliency-example-tcp-udp.md)
# Exemplo de arquitetura de resiliência Shield Advanced DDo S para aplicativos web comuns
Esta página fornece um exemplo de arquitetura para maximizar a resiliência contra ataques DDo S com aplicativos AWS web.
Você pode criar um aplicativo web em qualquer AWS região e receber proteção DDo S automática dos recursos de detecção e mitigação AWS fornecidos na região.
Este exemplo é para arquiteturas que direcionam usuários para um aplicativo web usando recursos como Classic Load Balancers, Application Load Balancers, Network Load Balancers, soluções do Marketplace da AWS ou sua própria camada de proxy. Você pode melhorar a resiliência DDo S inserindo zonas hospedadas do Amazon Route 53, CloudFront distribuições da Amazon e AWS WAF web ACLs entre esses recursos de aplicativos web e seus usuários. Essas inserções podem ofuscar a origem do aplicativo, atender às solicitações mais perto dos usuários finais e detectar e mitigar as inundações de solicitações na camada de aplicação. Os aplicativos que fornecem conteúdo estático ou dinâmico para seus usuários com o Route 53 são protegidos por um sistema de mitigação DDo S integrado CloudFront e totalmente embutido que atenua os ataques à camada de infraestrutura em tempo real.
Com essas melhorias arquitetônicas implementadas, você pode proteger suas zonas hospedadas do Route 53 e suas CloudFront distribuições com o Shield Advanced. Quando você protege CloudFront distribuições, o Shield Advanced solicita que você associe a AWS WAF web ACLs e crie regras baseadas em taxas para elas, além de oferecer a opção de ativar a mitigação automática da camada DDo S do aplicativo ou o engajamento proativo. O engajamento proativo e a mitigação automática da camada DDo S do aplicativo usam as verificações de saúde do Route 53 que você associa ao recurso. Para saber mais sobre essas opções, consulte [Proteções de recursos em AWS Shield Advanced](ddos-resource-protections.md).
O diagrama de referência a seguir mostra essa arquitetura resiliente DDo S para um aplicativo web.
![\[O diagrama mostra um retângulo intitulado AWS cloud, com um grupo de usuários à esquerda. Dentro do retângulo da nuvem estão dois outros retângulos, lado a lado. O retângulo esquerdo é intitulado AWS Shield Advanced e o retângulo direito é intitulado VPC. O AWS Shield Advanced triângulo esquerdo contém três AWS ícones, empilhados verticalmente. De cima para baixo, os ícones são Amazon Route 53 CloudFront, Amazon AWS WAF e. O ícone de CloudFront tem setas que vão de e para o ícone de. AWS WAF O grupo de usuários tem uma seta saindo horizontalmente à direita que se divide para apontar para os ícones do Route 53 e. CloudFront À direita do retângulo Shield Advanced, o retângulo VPC contém dois ícones lado a lado. Da esquerda para a direita, esses ícones são Elastic Load Balancing e Amazon Elastic Compute Cloud. O CloudFront ícone tem uma seta saindo horizontalmente à direita que vai até o ícone do Elastic Load Balancing. O ícone do Elastic Load Balancing tem uma seta saindo horizontalmente à direita que vai até o ícone do Amazon EC2. Portanto, as solicitações do usuário são enviadas para o Route 53 CloudFront e. CloudFront interage AWS WAF e também envia solicitações para o balanceador de carga, que por sua vez envia solicitações no Amazon EC2.\]](http://docs.aws.amazon.com/pt_br/waf/latest/developerguide/images/shield-resilient-web-app-arch.png)
Os benefícios que essa abordagem oferece ao seu aplicativo web incluem os seguintes:
+ Proteção contra ataques da camada de infraestrutura (camada 3 e camada 4) DDo S usados com frequência, sem atraso na detecção. Além disso, se um recurso for um alvo frequente, o Shield Advanced coloca mitigações por longos períodos de tempo. O Shield Advanced também usa o contexto do aplicativo inferido de Network ACLs (NACLs) para bloquear o tráfego indesejado ainda mais acima. Isso isola as falhas mais perto de sua origem, minimizando o efeito sobre usuários legítimos.
+ Proteção contra inundações TCP SYN. Os sistemas de mitigação DDo S, integrados ao Route 53CloudFront, AWS Global Accelerator fornecem um recurso de proxy TCP SYN que desafia novas tentativas de conexão e atende apenas a usuários legítimos.
+ Proteção contra ataques à camada de aplicação de DNS, porque o Route 53 é responsável por fornecer respostas autorizadas de DNS.
+ Proteção contra inundações de solicitações na camada de aplicação da web. A regra baseada em taxa que você configura na sua AWS WAF Web ACL bloqueia a origem IPs quando eles estão enviando mais solicitações do que o permitido pela regra.
+ Mitigação automática da camada DDo S de aplicação para suas CloudFront distribuições, se você optar por ativar essa opção. Com a mitigação automática de DDo S, o Shield Advanced mantém uma regra baseada em taxas na ACL da AWS WAF web associada à distribuição que limita o volume de solicitações de fontes S conhecidas. DDo Além disso, quando o Shield Avançado detecta um evento que afeta a integridade da aplicação, ele cria, testa e gerencia automaticamente as regras de mitigação na ACL da Web.
+ Engajamento proativo com a Shield Response Team (SRT), se você optar por ativar essa opção. Quando o Shield Advanced detecta um evento que afeta a integridade do seu aplicativo, o SRT responde e interage proativamente com suas equipes de segurança ou operações usando as informações de contato fornecidas por você. O SRT analisa padrões em seu tráfego e pode atualizar suas AWS WAF regras para bloquear o ataque.
# Exemplo de arquitetura de resiliência Shield Advanced DDo S para aplicativos TCP e UDP
Este exemplo mostra uma arquitetura resiliente DDo S para aplicativos TCP e UDP em uma AWS região que usa instâncias do Amazon Elastic Compute Cloud (Amazon EC2) ou endereços IP elásticos (EIP).
Você pode seguir esse exemplo geral para melhorar a resiliência DDo S para os seguintes tipos de aplicativos:
+ Aplicativos TCP ou UDP. Por exemplo, aplicativos usados para jogos, IoT e voz sobre IP.
+ Aplicativos da web que exigem endereços IP estáticos ou que usam protocolos que a Amazon CloudFront não suporta. Por exemplo, seu aplicativo pode exigir endereços IP que seus usuários possam adicionar às listas de permissões de firewall e que não sejam usados por nenhum outro AWS cliente.
Você pode melhorar a resiliência DDo S para esses tipos de aplicativos introduzindo o Amazon Route 53 e. AWS Global Accelerator Esses serviços podem direcionar os usuários para o seu aplicativo e fornecer ao seu aplicativo endereços IP estáticos que são anycast de qualquer forma pela rede de borda global da AWS . Os aceleradores padrão do Global Accelerator podem melhorar a latência do usuário em até 60%. Se você tiver uma aplicação Web, poderá detectar e mitigar as inundações de solicitações da camada da aplicação Web executando a aplicação em um Application Load Balancer e, em seguida, protegendo o Application Load Balancer com uma ACL da web. AWS WAF
Depois de criar seu aplicativo, proteja suas zonas hospedadas do Route 53, os aceleradores padrão do Global Accelerator e quaisquer Application Load Balancers de carga de aplicativos com o Shield Advanced. Ao proteger seus Application Load Balancers, você pode associar a AWS WAF web ACLs e criar regras baseadas em taxas para eles. Você pode configurar o engajamento proativo com o SRT tanto para seus aceleradores padrão do Global Accelerator quanto para seus Application Load Balancers associando verificações de integridade novas ou existentes do Route 53. Para saber mais sobre as opções, consulte [Proteções de recursos em AWS Shield Advanced](ddos-resource-protections.md).
O diagrama de referência a seguir mostra um exemplo de arquitetura resiliente DDo S para aplicativos TCP e UDP.
![\[O diagrama mostra os usuários conectados ao Route 53 e a um AWS Global Accelerator. O acelerador está conectado a um ícone do Elastic Load Balancing que é protegido por e. AWS Shield Advanced AWS WAF O próprio Elastic Load Balancing está conectado a uma instância do Amazon EC2. Essa instância do Elastic Load Balancing e a instância do Amazon EC2 estão na Região 1. Ele também AWS Global Accelerator está diretamente conectado a outra instância do Amazon EC2, que não está por trás de uma instância protegida do Elastic Load Balancing. Essa segunda instância do Amazon EC2 está na Região n.\]](http://docs.aws.amazon.com/pt_br/waf/latest/developerguide/images/shield-resilient-tcp-udp-app-arch.png)
Os benefícios que essa abordagem oferece ao seu aplicativo incluem o seguinte:
+ Proteção contra os maiores ataques conhecidos na camada de infraestrutura (camada 3 e camada 4) DDo S. Se o volume de um ataque causar congestionamento a montante AWS, a falha será isolada mais perto de sua origem e terá um efeito minimizado em seus usuários legítimos.
+ Proteção contra ataques à camada de aplicação de DNS, porque o Route 53 é responsável por fornecer respostas autorizadas de DNS.
+ Se você tiver um aplicativo web, essa abordagem fornece proteção contra inundações de solicitações na camada de aplicação web. A regra baseada em taxa que você configura na sua AWS WAF Web ACL bloqueia a origem IPs enquanto eles estão enviando mais solicitações do que o permitido pela regra.
+ Engajamento proativo com a Shield Response Team (SRT), se você optar por ativar essa opção para os recursos elegíveis. Quando o Shield Advanced detecta um evento que afeta a integridade do seu aplicativo, o SRT responde e interage proativamente com suas equipes operaiconais ou de segurança usando as informações de contato fornecidas por você.
# Combinando o Shield Advanced com outros Serviços da AWS
Você pode usar o Shield Advanced para proteger seus recursos em muitos tipos de cenários. No entanto, em alguns casos, você deve usar outros serviços ou combinar outros serviços com o Shield Advanced para oferecer a melhor proteção. Veja a seguir exemplos de como usar o Shield Advanced ou outros AWS serviços para ajudar a proteger seus recursos.
| Objetivo | Serviços sugeridos | Documentação do serviço relacionado |
| --- | --- | --- |
| Proteja um aplicativo web e RESTful APIs contra um ataque DDo S | Shield Advanced protegendo uma CloudFront distribuição da Amazon e um Application Load Balancer | [Documentação do [Elastic Load Balancing, documentação](https://docs.aws.amazon.com/elasticloadbalancing/) da Amazon CloudFront ](https://docs.aws.amazon.com/cloudfront/) |
| Proteja um aplicativo baseado em TCP contra um ataque S DDo | Shield Advanced protegendo um acelerador AWS Global Accelerator padrão; conectado a um endereço IP elástico | [AWS Global Accelerator Documentação, documentação](https://docs.aws.amazon.com/global-accelerator/) do [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/) |
| Proteja um servidor de jogos baseado em UDP contra um DDo ataque S | Shield Advanced protegendo uma EC2 instância da Amazon conectada a um endereço IP elástico | [Documentação do Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/ec2/) |
Por exemplo, se você usa o Shield Advanced para proteger um endereço IP elástico, o Shield Advanced protege qualquer recurso associado a ele. Durante um ataque, o Shield Advanced implanta automaticamente sua rede ACLs na borda da AWS rede. Quando sua rede ACLs está na fronteira da rede, o Shield Advanced pode fornecer proteção contra eventos DDo S maiores. Normalmente, a rede ACLs é aplicada perto de suas EC2 instâncias da Amazon em sua Amazon VPC. A rede ACL pode atenuar ataques somente até a capacidade máxima de processamento da Amazon VPC e da instância. Se a interface de rede conectada à sua EC2 instância da Amazon puder processar até 10 Gbps, os volumes acima de 10 Gbps diminuirão a velocidade e possivelmente bloquearão o tráfego para essa instância. Durante um ataque, o Shield Advanced promove sua network ACL para a borda da AWS , que pode processar vários terabytes de tráfego. Sua network ACL é capaz de oferecer proteção para seu recurso muito além da capacidade típica da sua rede. Para obter mais informações sobre rede ACLs, consulte [Rede ACLs](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html).
# Conf AWS Shield Advanced iguração
Este tutorial explica como começar a AWS Shield Advanced usar o console Shield Advanced.
**nota**
O Shield Advanced exige uma assinatura, AWS Shield Standard mas não exige. As proteções fornecidas pelo Shield Básico estão disponíveis gratuitamente para todos os clientes da AWS .
O Shield Advanced fornece proteção avançada de detecção e mitigação de DDo S para ataques na camada de rede (camada 3), camada de transporte (camada 4) e camada de aplicação (camada 7). Para obter mais informações sobre o Shield Advanced, consulte [Visão geral do AWS Shield Advanced](ddos-advanced-summary.md).
A comunidade AWS técnica publicou um exemplo de um processo automatizado para configurar o Shield Advanced usando as ferramentas de infraestrutura como código (IaC) AWS CloudFormation e o Terraform. Você pode usar AWS Firewall Manager essa solução se suas contas fizerem parte de uma organização AWS Organizations e se você estiver protegendo qualquer tipo de recurso, exceto o Amazon Route 53 ou AWS Global Accelerator. [Para explorar essa opção, consulte o repositório de código em [aws-samples/ aws-shield-advanced-one-click-deployment](https://github.com/aws-samples/aws-shield-advanced-one-click-deployment) e o tutorial em Implantação com um clique do Shield Advanced.](https://youtu.be/LCA3FwMk_QE)
**nota**
É importante que você configure totalmente o Shield Advanced antes de um evento de negação distribuída de serviço (DDoS). Conclua a configuração para ajudar a garantir que seu aplicativo esteja protegido e que você esteja pronto para responder se o aplicativo for afetado por um ataque DDo S.
Execute as etapas a seguir em sequência para começar a usar o Shield Advanced.
**Contents**
+ [Inscrevendo-se em AWS Shield Advanced](enable-ddos-prem.md)
+ [Como adicionar e configurar proteções de recursos com o Shield Advanced](ddos-choose-resources.md)
+ [Configurando as proteções da camada de aplicativo (camada 7) DDo S com AWS WAF](ddos-get-started-web-acl-rbr.md)
+ [Como configurar a detecção baseada em integridade às suas proteções com o Shield Advanced e o Route 53](ddos-get-started-health-checks.md)
+ [Como configurar alarmes e notificações com o Shield Advanced e o Amazon SNS](ddos-get-started-create-alarms.md)
+ [Como revisar e concluir sua configuração de proteção no Shield Advanced](ddos-get-started-review-and-configure.md)
+ [Configurando o suporte AWS do Shield Response Team (SRT) para resposta a eventos DDo S](authorize-srt.md)
+ [Criação de um painel DDo S CloudWatch e configuração de CloudWatch alarmes](deploy-waf-dashboard.md)
# Inscrevendo-se em AWS Shield Advanced
Essa página explica como assinar com as suas contas o Shield Advanced para começar a usar o serviço.
Você deve assinar o Shield Advanced para cada um Conta da AWS que você deseja proteger. Não é necessário assinar o Shield Básico.
**Cobrança da assinatura do Shield Advanced**
Se você for um revendedor de AWS canais, fale com a equipe da sua conta para obter informações e orientações. Essas informações de cobrança são para clientes que não são revendedores de AWS canais.
Para todos os outros, as seguintes diretrizes de assinatura e cobrança se aplicam:
+ Para contas que são membros de uma AWS Organizations organização, AWS as assinaturas do Shield Advanced são cobradas da conta pagante da organização, independentemente de a própria conta do pagador estar assinada.
+ Quando você assina várias contas que estão na mesma [família AWS Organizations de contas de faturamento consolidado](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html), um preço de assinatura cobre todas as contas inscritas na família. A organização deve possuir todas as Contas da AWS e todos os seus recursos.
+ Ao assinar várias contas para várias organizações, você ainda pode pagar uma taxa de assinatura em todas as organizações, contas e recursos, desde que seja proprietário de todas elas. Entre em contato com seu gerente de conta ou AWS suporte e solicite uma isenção de taxa sobre as cobranças de AWS Shield Advanced assinatura para todas as organizações, exceto uma.
Para obter informações detalhadas sobre preços e exemplos, consulte [Preços do AWS Shield](https://aws.amazon.com/shield/pricing/).
**Considere simplificar as assinaturas com AWS Firewall Manager**
Se suas contas fizerem parte de uma organização, recomendamos que você use o AWS Firewall Manager , se possível, para automatizar suas assinaturas e proteções para a organização. O Firewall Manager oferece suporte a todos os tipos de recursos protegidos, exceto o Amazon Route 53 e AWS Global Accelerator. Para usar o Firewall Manager, consulte [AWS Firewall Manager](fms-chapter.md) e [Configurando AWS Firewall Manager AWS Shield Advanced políticas](getting-started-fms-shield.md).
Se você não usa o Firewall Manager, para cada conta com recursos para proteger, assine e adicione proteções usando os procedimentos a seguir.
**Para assinar uma conta em AWS Shield Advanced**
1. Faça login Console de gerenciamento da AWS e abra o console AWS WAF & Shield em [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Na barra de navegação **AWS Shield**, escolha **Conceitos básicos**. Escolha **Inscrever-se no Shield Advanced**.
1. Na página **Assine o Shield Advanced**, leia cada termo do contrato e marque todas as caixas de seleção para indicar que você aceita os termos. Para contas em uma família de faturamento consolidado, você deve concordar com os termos de cada conta.
**Importante**
Quando você está inscrito, para cancelar a inscrição, você deve entrar em contato com [AWS Support](https://console.aws.amazon.com/support).
[Para desativar a renovação automática de sua assinatura, você deve usar a operação da API Shield ou o comando CLI [UpdateSubscription](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_UpdateSubscription.html)update-subscription.](https://docs.aws.amazon.com/cli/latest/reference/shield/update-subscription.html)
Escolha **Inscrever-se no Shield Advanced**. Isso inscreve sua conta no Shield Advanced e ativa o serviço.
Sua conta está inscrita. Continue com as etapas a seguir para proteger os recursos da sua conta com o Shield Advanced.
**nota**
O Shield Advanced não protege automaticamente seus recursos após você assinar. Você deve especificar os recursos que deseja que o Shield Advanced proteja.
# Como adicionar e configurar proteções de recursos com o Shield Advanced
Esta página fornece instruções para adicionar e configurar proteções para seus recursos.
O Shield Advanced protege somente os recursos que você especifica, seja por meio do Shield Advanced ou em uma política Shield Advanced do Firewall Manager. Ele não protege automaticamente os recursos de uma conta assinada.
**nota**
Se você usa uma política AWS Firewall Manager Shield Advanced para suas proteções, não precisa executar essa etapa. Você configura a política com os tipos de recursos a serem protegidos, e o Firewall Manager adiciona automaticamente proteções aos recursos que estão dentro do escopo da política.
Se você não usa o Firewall Manager, siga os procedimentos a seguir para cada conta que tenha recursos para proteger.
**Para escolher os recursos a serem protegidos usando o Shield Advanced**
1. Escolha **Adicionar recursos para proteger** na página de confirmação da assinatura do procedimento anterior ou na página **Recursos protegidos** ou **Visão geral**.
1. Na página **Escolher recursos para proteger com o Shield Advanced**, em **Especificar a região e os tipos de recursos**, forneça as especificações de região e tipo de recurso para os recursos que você deseja proteger. Você pode proteger recursos em várias regiões selecionando **Todas as regiões**, e pode restringir a seleção a recursos globais selecionando **Global**. Você pode desmarcar qualquer tipo de recurso que não queira proteger. Para saber mais sobre proteções para seus tipos de recursos, consulte [Lista de recursos que AWS Shield Advanced protegem](ddos-protections-by-resource-type.md).
1. Escolha **Carregar recursos**. O Shield Advanced preenche a seção **Selecionar recursos** com os recursos AWS que correspondem aos seus critérios.
1. Na seção **Selecionar recursos**, você pode filtrar a lista de recursos inserindo uma string para pesquisar nas listas de recursos.
Escolha os recursos que você deseja proteger.
1. Na seção **Tags**, se você quiser adicionar tags às proteções Shield Advanced que estiver criando, especifique-as. Para saber mais sobre como marcar recursos AWS , consulte [Trabalhar com o Tag Editor](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html).
1. Escolha **Proteger com o Shield Advanced**. Isso adiciona as proteções do Shield Advanced aos recursos.
Continue nas telas do assistente do console para concluir a configuração de suas proteções de recursos.
**Topics**
+ [Configurando as proteções da camada de aplicativo (camada 7) DDo S com AWS WAF](ddos-get-started-web-acl-rbr.md)
+ [Como configurar a detecção baseada em integridade às suas proteções com o Shield Advanced e o Route 53](ddos-get-started-health-checks.md)
+ [Como configurar alarmes e notificações com o Shield Advanced e o Amazon SNS](ddos-get-started-create-alarms.md)
+ [Como revisar e concluir sua configuração de proteção no Shield Advanced](ddos-get-started-review-and-configure.md)
# Configurando as proteções da camada de aplicativo (camada 7) DDo S com AWS WAF
Esta página fornece instruções para configurar as proteções da camada de aplicação com AWS WAF a web. ACLs
Para proteger um recurso da camada de aplicação, o Shield Advanced usa uma AWS WAF Web ACL com uma regra baseada em taxas como ponto de partida. AWS WAF é um firewall de aplicativo web que permite monitorar as solicitações HTTP e HTTPS que são encaminhadas para os recursos da camada de aplicativos e permite controlar o acesso ao seu conteúdo com base nas características das solicitações. Uma regra baseada em taxas limita o volume de tráfego com base nos critérios de agregação de solicitações, fornecendo proteção DDo S básica ao seu aplicativo. Para obter mais informações, consulte [Como AWS WAF funciona](how-aws-waf-works.md) e [Usando declarações de regras baseadas em taxas em AWS WAF](waf-rule-statement-type-rate-based.md).
Opcionalmente, você também pode ativar a mitigação automática da camada DDo S do aplicativo Shield Advanced, para que o Shield Advanced solicite o limite de taxa de fontes DDo S conhecidas e forneça automaticamente proteções específicas de incidentes para você.
**Importante**
Se você gerencia suas proteções Shield Advanced AWS Firewall Manager usando uma política Shield Advanced, não poderá gerenciar as proteções da camada de aplicativos aqui. Você deve gerenciá-las na política do Shield Advanced do Firewall Manager.
**Assinaturas e custos do Shield Advanced AWS WAF**
Sua assinatura do Shield Advanced cobre os custos de uso dos AWS WAF recursos padrão dos recursos que você protege com o Shield Advanced. As AWS WAF taxas padrão cobertas pelas proteções Shield Advanced são o custo por pacote de proteção (web ACL), o custo por regra e o preço base por milhão de solicitações para inspeção de solicitações na web, até 1.500 WCUs e até o tamanho padrão do corpo.
Ativar a mitigação automática da camada DDo S do aplicativo Shield Advanced adiciona um grupo de regras ao seu pacote de proteção (Web ACL) que usa 150 unidades de capacidade Web ACL (). WCUs Isso WCUs conta contra o uso da WCU em seu pacote de proteção (web ACL). Para obter mais informações, consulte [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md), [Como proteger a camada de aplicativos com o grupo de regras do Shield Advanced](ddos-automatic-app-layer-response-rg.md) e [Unidades de capacidade do Web ACL (WCUs) em AWS WAF](aws-waf-capacity-units.md).
Sua assinatura do Shield Advanced não cobre o uso AWS WAF de recursos que você não protege usando o Shield Advanced. Também não cobre nenhum custo adicional não padronizado AWS WAF para recursos protegidos. Exemplos de AWS WAF custos não padronizados são aqueles do Bot Control, da ação da CAPTCHA regra, da web ACLs que usa mais de 1.500 WCUs e da inspeção do corpo da solicitação além do tamanho padrão. A lista completa é fornecida na página AWS WAF de preços. Sua assinatura do Shield Advanced inclui acesso ao grupo Amazon Managed Rule de camada 7 DDo anti-S. Como parte de sua assinatura, você receberá até 50 bilhões de solicitações para AWS WAF recursos protegidos do Shield Advanced em um mês civil. Solicitações acima de 50 bilhões serão cobradas de acordo com a página AWS Shield Advanced de preços.
Para obter informações completas e exemplos de preços, consulte [Preços do Shield](https://aws.amazon.com/shield/pricing/) e [Preços do AWS WAF](https://aws.amazon.com/waf/pricing/).
**Para configurar as proteções da camada 7 DDo S para uma região**
O Shield Advanced oferece a opção de configurar a mitigação da camada 7 DDo S para cada região em que os recursos escolhidos estão localizados. Se você estiver adicionando proteções em várias regiões, o assistente o guiará pelo procedimento a seguir para cada região.
1. A página **Configurar proteções da camada 7 DDo S** lista cada recurso que ainda não está associado a uma Web ACL. Para cada uma delas, escolha uma web ACL existente ou crie uma nova web ACL. Para qualquer recurso que já tenha uma ACL da web associada, você pode alterar a web ACLs desassociando primeiro a atual. AWS WAF Para obter mais informações, consulte [Associar ou desassociar a proteção a um recurso AWS](web-acl-associating-aws-resource.md).
Para sites ACLs que ainda não têm uma regra baseada em taxas, o assistente de configuração solicita que você adicione uma. Uma regra baseada em intervalos limita o tráfego de endereços IP quando eles estão enviando um grande volume de solicitações. As regras baseadas em taxas ajudam a proteger seu aplicativo contra inundações de solicitações da web e podem fornecer alertas sobre picos repentinos no tráfego que podem indicar um possível ataque S. DDo Adicione uma regra baseada em intervalos a uma web ACL escolhendo **Adicionar regra de limite de intervalo** e, em seguida, fornecendo um limite de intervalo e uma ação de regra. Você pode configurar proteções adicionais na Web ACL por meio de. AWS WAF
Para obter informações sobre o uso de regras baseadas na web ACLs e em taxas em suas proteções Shield Advanced, incluindo opções adicionais de configuração para regras baseadas em taxas, consulte. [Protegendo a camada de aplicação com AWS WAF web ACLs e Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md)
1. Para a **mitigação automática da camada DDo S do aplicativo**, se você quiser que o Shield Advanced mitigue automaticamente DDo os ataques S contra seus recursos da camada de aplicativo, escolha **Habilitar** e, em seguida, selecione a ação de AWS WAF regra que você deseja que o Shield Advanced use em suas regras personalizadas. Essa configuração se aplica a toda a Web ACLs para os recursos que você está gerenciando nesta sessão do assistente.
Com a mitigação automática da camada DDo S do aplicativo, o Shield Advanced mantém uma regra baseada em taxas na ACL da AWS WAF web do recurso que limita o volume de solicitações de fontes S conhecidas. DDo Além disso, o Shield Advanced compara os padrões de tráfego atuais com as linhas de base do tráfego histórico para detectar desvios que possam indicar um ataque S. DDo Quando o Shield Advanced detecta um ataque DDo S, ele responde criando, avaliando e implantando regras personalizadas AWS WAF para responder. Você especifica se as regras personalizadas contam ou bloqueiam ataques em seu nome.
**nota**
A mitigação automática da camada DDo S do aplicativo funciona somente com pacotes de proteção (web ACLs) que foram criados usando a versão mais recente do AWS WAF (v2).
Para obter mais informações sobre a mitigação automática da camada DDo S do aplicativo Shield Advanced, incluindo advertências e melhores práticas para usar esse recurso, consulte. [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md)
1. Escolha **Próximo**. O assistente do console avança para a página de detecção baseada em integridade.
# Como configurar a detecção baseada em integridade às suas proteções com o Shield Advanced e o Route 53
Esta página fornece instruções para configurar o Shield Advanced para usar a detecção baseada em integridade. Isso pode ajudar a melhorar a capacidade de resposta e a precisão na detecção e mitigação de ataques.
Verificações de integridade bem configuradas são essenciais para a detecção precisa de eventos. Você pode configurar a detecção baseada em integridade para qualquer tipo de recurso, exceto as zonas hospedadas do Route 53.
Para usar a detecção baseada em integridade, defina uma verificação de integridade para seu recurso no Route 53 e, em seguida, associe essa verificação à sua proteção Shield Advanced. É importante que a verificação de integridade que você configura reflita com precisão a integridade do recurso. Para saber mais e exemplos de configuração de verificações de integridade para uso com o Shield Advanced, consulte [Detecção baseada em integridade usando verificações de integridade com o Shield Advanced e o Route 53](ddos-advanced-health-checks.md).
As verificações de integridade são necessárias para o suporte de engajamento proativo da Shield Response Team (SRT). Para saber mais sobre engajamento proativo, consulte [Como configurar um engajamento proativo para que o SRT entre em contato diretamente com você](ddos-srt-proactive-engagement.md).
**nota**
As verificações de integridade devem ser relatadas como íntegras quando você as associa às proteções do Shield Advanced.
**Para configurar a detecção baseada em integridade**
1. Em **Verificação de integridade associada**, escolha o ID da verificação de integridade que deseja associar à proteção.
**nota**
Se você não vir a verificação de integridade necessária, vá até o console do Route 53 e verifique a verificação de integridade e seu ID. Para saber mais, consulte [Criar e atualizar verificações de integridade](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html).
1. Escolha **Próximo**. O assistente do console avança para a página de alarmes e notificações.
# Como configurar alarmes e notificações com o Shield Advanced e o Amazon SNS
Esta página fornece instruções para configurar opcionalmente as notificações do Amazon Simple Notification Service para CloudWatch alarmes detectados da Amazon e atividades de regras baseadas em taxas. Você pode usá-los para receber notificações quando o Shield detectar um evento em um recurso protegido, ou ainda quando um limite de taxa configurado em uma regra baseada em intervalos for excedido.
Para obter informações sobre as CloudWatch métricas do Shield Advanced, consulte[AWS Shield Advanced métricas](shield-metrics.md). Para saber mais sobre tópicos do Amazon SNS, consulte o [Guia do desenvolvedor do Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/).
**Para configurar alarmes e notificações**
1. Selecione os tópicos do Amazon SNS para os quais deseja receber notificações. Você pode usar um único tópico do Amazon SNS para todos os recursos protegidos e regras baseadas em intervalos, ou você pode escolher tópicos diferentes, personalizados para sua organização. Por exemplo, você pode criar um tópico de SNS para cada equipe responsável pela resposta a incidentes para um conjunto específico de recursos.
1. Escolha **Próximo**. O assistente do console avança para a página de revisão da proteção de recursos.
# Como revisar e concluir sua configuração de proteção no Shield Advanced
**Para revisar e concluir as configurações**
1. Na página **Revisar e configurar a mitigação e visibilidade do DDo S**, revise suas configurações. Para fazer modificações, escolha **Editar** na área que você deseja modificar. Isso o levará de volta à página associada no assistente do console. Faça suas alterações e escolha **Avançar** nas páginas subsequentes até retornar à página **Revisar e configurar a mitigação e visibilidade DDo S.**
1. Escolha **Concluir configuração**. A página **Recursos protegidos** lista seus recursos recém-protegidos.
# Configurando o suporte AWS do Shield Response Team (SRT) para resposta a eventos DDo S
Esta página fornece instruções para configurar o suporte do Shield Response Team (SRT).
O SRT inclui engenheiros de segurança especializados em resposta a eventos DDo S. Opcionalmente, você pode adicionar permissões que permitam ao SRT gerenciar recursos em seu nome durante um evento DDo S. Além disso, você pode configurar o SRT para interagir proativamente com você se as verificações de integridade do Route 53 associadas aos seus recursos protegidos não estiverem íntegras durante um evento detectado. Essas duas adições às suas proteções permitem respostas mais rápidas aos eventos S. DDo
**nota**
Para usar os serviços do Shield Response Team (SRT), você deve ser assinante do plano [Business Support](https://aws.amazon.com/premiumsupport/business-support/) ou do [Enterprise Support](https://aws.amazon.com/premiumsupport/enterprise-support/).
O SRT pode monitorar dados e registros de AWS WAF solicitações durante eventos da camada de aplicação para identificar tráfego anômalo. Eles podem ajudar a criar AWS WAF regras personalizadas para mitigar fontes de tráfego ofensivas. Conforme necessário, o SRT pode fazer recomendações arquitetônicas para ajudá-lo a alinhar melhor seus recursos às AWS recomendações.
Para obter mais informações sobre o SRT, consulte [Resposta gerenciada a eventos DDo S com suporte do Shield Response Team (SRT)](ddos-srt-support.md).
**Para conceder permissões ao SRT**
1. Na página **Visão geral** do AWS Shield console, em **Configurar suporte ao AWS SRT**, escolha **Editar acesso ao SRT.** A página de **acesso AWS do Edit Shield Response Team (SRT)** é aberta.
1. Para **Configuração de acesso SRT**, selecione uma das opções:
+ **Não conceder ao SRT acesso à minha conta**: o Shield remove todas as permissões que você concedeu anteriormente ao SRT para acessar sua conta e recursos.
+ **Criar uma nova função para o SRT acessar minha conta**: o Shield cria uma função que confia na entidade principal do serviço `drt.shield.amazonaws.com`, que representa o SRT, e anexa a política `AWSShieldDRTAccessPolicy` gerenciada a ele. A política gerenciada permite que o SRT faça AWS Shield Advanced chamadas de AWS WAF API em seu nome e acesse seus AWS WAF registros. Para saber mais sobre a política gerenciada , consulte [AWS política gerenciada: AWSShield DRTAccess Política](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy).
+ **Escolha uma função existente para o SRT acessar minhas contas** — Para essa opção, você deve modificar a configuração da função no AWS Identity and Access Management (IAM) da seguinte forma:
+ Anexe a política gerenciada `AWSShieldDRTAccessPolicy` à função. Essa política gerenciada permite que o SRT faça AWS Shield Advanced chamadas de AWS WAF API em seu nome e acesse seus AWS WAF registros. Para saber mais sobre a política gerenciada , consulte [AWS política gerenciada: AWSShield DRTAccess Política](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy). Para saber mais sobre como anexar a política gerenciada à sua função, consulte [Anexar e desanexar políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
+ Modifique a função para confiar no serviço principal `drt.shield.amazonaws.com`. Esta é a entidade principal do serviço que representa o SRT. Para mais informações, consulte [Elementos de política JSON do IAM: principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html).
1. Escolha **Salvar** para salvar as alterações.
Para obter mais informações sobre como dar ao SRT acesso às suas proteções e dados, consulte [Como conceder acesso ao SRT](ddos-srt-access.md).
**Como habilitar o envolvimento proativo do SRT**
1. Na página **Visão geral** do AWS Shield console, em **Engajamento proativo e contatos**, na área de contatos, escolha **Editar**.
Na página **Editar contatos**, forneça as informações de contato das pessoas com as quais você deseja que o SRT entre em contato para um engajamento proativo.
Se você fornecer mais de um ponto de contato, em **Notas**, indique as circunstâncias em que cada contato deve ser usado. Inclua designações de contato primário e secundário e forneça os horários de disponibilidade e os fusos horários de cada contato.
Exemplos de notas de contato:
+ Esta é uma linha direta que funciona 24 horas por dia, 7 dias por semana, 365 dias por ano. Trabalhe com o analista atendente, que colocará a pessoa apropriada na chamada.
+ Entre em contato comigo se a linha direta não responder em 5 minutos.
1. Escolha **Salvar**.
A página **Visão geral** reflete as informações de contato atualizadas.
1. Escolha **Editar atributo de engajamento proativo**, escolha **Habilitar** e, em seguida, escolha **Salvar** para ativar o engajamento proativo.
Para obter mais informações sobre engajamento proativo, consulte [Como configurar um engajamento proativo para que o SRT entre em contato diretamente com você](ddos-srt-proactive-engagement.md).
# Criação de um painel DDo S CloudWatch e configuração de CloudWatch alarmes
Esta página fornece instruções para criar um painel DDo S CloudWatch e configurar CloudWatch alarmes.
Você pode monitorar a atividade potencial de DDo S usando a Amazon CloudWatch, que coleta dados brutos do Shield Advanced e os processa em métricas legíveis, quase em tempo real. Você pode usar estatísticas CloudWatch para obter uma perspectiva sobre o desempenho de seu aplicativo ou serviço da Web. Para obter mais informações sobre o uso CloudWatch, consulte [O que está CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html) no *Guia CloudWatch do usuário da Amazon*.
+ Para obter instruções sobre como criar um CloudWatch painel, consulte[Monitoramento com a Amazon CloudWatch](monitoring-cloudwatch.md).
+ Para obter descrições das métricas do Shield Advanced que você pode adicionar ao painel, consulte [AWS Shield Advanced métricas](shield-metrics.md).
O Shield Advanced reporta as métricas de recursos com CloudWatch mais frequência durante os eventos DDo S do que quando nenhum evento está em andamento. O Shield Advanced relata métricas uma vez por minuto durante um evento e, em seguida, uma vez logo após o término do evento. Enquanto não há nenhum ataque em andamento, o Shield Advanced relata métricas uma vez ao dia, no horário atribuído ao recurso. Esse relatório periódico mantém as métricas ativas e disponíveis para uso em seus alarmes personalizados CloudWatch .
Isso conclui o tutorial para começar a usar o Shield Advanced. Para aproveitar ao máximo as proteções que você escolheu, continue explorando os atributos e opções do Shield Advanced. Para começar, familiarize-se com suas opções para visualizar e responder aos eventos em [Visibilidade DDo dos eventos S com o Shield Advanced](ddos-viewing-events.md) e [Respondendo aos eventos DDo S em AWS](ddos-responding.md).
# Resposta gerenciada a eventos DDo S com suporte do Shield Response Team (SRT)
Esta página descreve a função do Shield Response Team (SRT).
O SRT fornece suporte adicional aos clientes do Shield Advanced. Os SRT são engenheiros de segurança especializados em resposta a eventos DDo S. Como uma camada adicional de suporte ao seu plano AWS Support , você pode trabalhar diretamente com o SRT, aproveitando sua experiência como parte do seu fluxo de trabalho de resposta a eventos. Para saber mais sobre as opções e orientações de configuração, consulte os tópicos a seguir.
**nota**
Para usar os serviços do Shield Response Team (SRT), você deve ser assinante do plano [Business Support](https://aws.amazon.com/premiumsupport/business-support/) ou do [Enterprise Support](https://aws.amazon.com/premiumsupport/enterprise-support/).
A Shield Response Team (SRT) fornece serviços em regiões onde o Shield Advanced está disponível e para clientes em GovCloud regiões (Leste dos EUA) e AWS GovCloud AWS GovCloud (Oeste dos EUA).
**Atividades de suporte do SRT**
O objetivo principal em um contrato com o SRT é proteger a disponibilidade e o desempenho do seu aplicativo. Dependendo do tipo de evento DDo S e da arquitetura do seu aplicativo, o SRT pode realizar uma ou mais das seguintes ações:
+ **AWS WAF análise de registros e regras** — Para recursos que usam uma ACL AWS WAF da web, o SRT pode analisar seus AWS WAF registros para identificar características de ataque nas solicitações da web do seu aplicativo. Com sua aprovação durante o engajamento, o SRT pode aplicar alterações em sua web ACL para bloquear os ataques que eles identificaram.
+ **Crie mitigações de rede personalizadas**: o SRT pode criar mitigações personalizadas para você para ataques na camada de infraestrutura. O SRT pode trabalhar com você para entender o tráfego esperado para seu aplicativo, bloquear tráfego inesperado e otimizar os limites de taxa de pacotes por segundo. Para obter mais informações, consulte [Configurando mitigações personalizadas contra ataques DDo S com o SRT](ddos-srt-custom-mitigations.md).
+ **Engenharia de tráfego de rede** — O SRT trabalha em estreita colaboração com as equipes AWS de rede para proteger os clientes do Shield Advanced. Quando necessário, AWS pode alterar a forma como o tráfego da Internet chega à AWS rede para alocar mais capacidade de mitigação ao seu aplicativo.
+ **Recomendações arquitetônicas** — O SRT pode determinar que a melhor mitigação para um ataque requer mudanças na arquitetura para melhor se alinhar às AWS melhores práticas, e elas ajudarão a apoiar a implementação dessas práticas. Para obter informações, consulte [AWS Melhores práticas para resiliência DDo S.](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency)
As seções a seguir fornecem instruções para interagir com o SRT
**Topics**
+ [Como conceder acesso ao SRT](ddos-srt-access.md)
+ [Como configurar um engajamento proativo para que o SRT entre em contato diretamente com você](ddos-srt-proactive-engagement.md)
+ [Entrar em contato com o SRT para obter ajuda com um evento DDo S suspeito](ddos-srt-contacting.md)
+ [Configurando mitigações personalizadas contra ataques DDo S com o SRT](ddos-srt-custom-mitigations.md)
# Como conceder acesso ao SRT
Esta página fornece instruções para conceder permissão ao SRT para agir em seu nome, para que ele possa acessar seus AWS WAF registros e fazer chamadas para o AWS Shield Advanced e gerenciar as AWS WAF APIs proteções.
Durante DDo os eventos da camada S do aplicativo, o SRT pode monitorar AWS WAF solicitações para identificar tráfego anômalo e ajudar a criar AWS WAF regras personalizadas para mitigar fontes de tráfego ofensivas.
Além disso, você pode conceder ao SRT acesso a outros dados armazenados nos buckets do Amazon S3, como capturas de pacotes ou registros de um Application Load Balancer, da CloudFront Amazon ou de fontes de terceiros.
**nota**
Para usar os serviços do Shield Response Team (SRT), você deve ser assinante do plano [Business Support](https://aws.amazon.com/premiumsupport/business-support/) ou [Enterprise Support](https://aws.amazon.com/premiumsupport/enterprise-support/).
**Para gerenciar permissões para o SRT**
1. Na página **Visão geral** do AWS Shield console, em **Configurar suporte ao AWS SRT**, escolha **Editar acesso ao SRT.** A página de **acesso AWS do Edit Shield Response Team (SRT)** é aberta.
1. Para **Configuração de acesso SRT**, selecione uma das opções:
+ **Não conceder ao SRT acesso à minha conta**: o Shield remove todas as permissões que você concedeu anteriormente ao SRT para acessar sua conta e recursos.
+ **Criar uma nova função para o SRT acessar minha conta**: o Shield cria uma função que confia na entidade principal do serviço `drt.shield.amazonaws.com`, que representa o SRT, e anexa a política `AWSShieldDRTAccessPolicy` gerenciada a ele. A política gerenciada permite que o SRT faça AWS Shield Advanced chamadas de AWS WAF API em seu nome e acesse seus AWS WAF registros. Para saber mais sobre a política gerenciada , consulte [AWS política gerenciada: AWSShield DRTAccess Política](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy).
+ **Escolha uma função existente para o SRT acessar minhas contas** — Para essa opção, você deve modificar a configuração da função no AWS Identity and Access Management (IAM) da seguinte forma:
+ Anexe a política gerenciada `AWSShieldDRTAccessPolicy` à função. Essa política gerenciada permite que o SRT faça AWS Shield Advanced chamadas de AWS WAF API em seu nome e acesse seus AWS WAF registros. Para saber mais sobre a política gerenciada , consulte [AWS política gerenciada: AWSShield DRTAccess Política](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy). Para saber mais sobre como anexar a política gerenciada à sua função, consulte [Anexar e desanexar políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
+ Modifique a função para confiar no serviço principal `drt.shield.amazonaws.com`. Esta é a entidade principal do serviço que representa o SRT. Para mais informações, consulte [Elementos de política JSON do IAM: principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html).
1. Para **(opcional): conceda acesso SRT a um bucket do Amazon S3**. Se você precisar compartilhar dados que não estejam nos AWS WAF seus registros de ACL da web, configure isso. Por exemplo, registros de acesso do Application Load Balancer, CloudFront registros da Amazon ou registros de fontes de terceiros.
**nota**
Você não precisa fazer isso para seus registros de ACL AWS WAF da web. O SRT obtém acesso a eles quando você concede acesso à sua conta.
1. Configure os buckets do Amazon S3 de acordo com as seguintes diretrizes:
+ Os locais dos buckets devem ser os Conta da AWS mesmos aos quais você concedeu acesso geral ao SRT, na etapa anterior, acesso ao **AWS Shield Response Team (SRT).**
+ Os buckets podem ser texto simples ou criptografados por SSE-S3. Para obter mais informações sobre a criptografia por SSE-S3 do Amazon S3, consulte [Proteger dados usando criptografia no lado do servidor com chaves de criptografia gerenciadas pelo Amazon S3 (SSE-S3)](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html) no Guia do usuário do Amazon S3.
O SRT não pode visualizar ou processar registros armazenados em buckets criptografados com chaves armazenadas em AWS Key Management Service ()AWS KMS.
1. No Shield Advanced **(Opcional): conceder ao SRT acesso a uma seção de bucket do Amazon S3**, para cada bucket do Amazon S3 em que seus dados ou logs estão armazenados, insira o nome do bucket e escolha **Adicionar Bucket.** Você pode adicionar até 10 buckets.
Isso concede ao SRT as seguintes permissões no bucket: `s3:GetBucketLocation`, `s3:GetObject` e `s3:ListBucket`.
Se quiser dar permissão ao SRT para acessar mais de 10 buckets, você pode fazer isso editando as políticas adicionais do bucket e concedendo manualmente as permissões listadas aqui para o SRT.
A política a seguir mostra um exemplo de listagem de políticas.
```
{
"Sid": "AWSDDoSResponseTeamAccessS3Bucket",
"Effect": "Allow",
"Principal": {
"Service": "drt.shield.amazonaws.com"
},
"Action": [
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"
]
}
```
1. Escolha **Salvar** para salvar as alterações.
[Você também pode autorizar o SRT por meio da API criando uma função do IAM, anexando a AWSShield DRTAccess política a ela e, em seguida, passando a função para o associado da operação. DRTRole](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_AssociateDRTRole.html)
# Como configurar um engajamento proativo para que o SRT entre em contato diretamente com você
Esta página fornece instruções para a configuração do engajamento proativo com o SRT.
Com o engajamento proativo, o SRT entra em contato com você diretamente quando a disponibilidade ou o desempenho do seu aplicativo são afetados por causa de um possível ataque. Recomendamos esse modelo de engajamento porque ele fornece a resposta SRT mais rápida e permite que o SRT comece a solucionar problemas mesmo antes de estabelecer contato com você.
O engajamento proativo está disponível para eventos de camada de rede e camada de transporte em endereços IP elásticos e aceleradores AWS Global Accelerator padrão, e para inundações de solicitações da web em distribuições da Amazon e Application Load Balancers. CloudFront O engajamento proativo está disponível somente para proteções de recursos do Shield Advanced que tenham uma verificação de integridade associada ao Amazon Route 53. Para mais informações sobre como gerenciar e usar as verificações de integridade, consulte [Detecção baseada em integridade usando verificações de integridade com o Shield Advanced e o Route 53](ddos-advanced-health-checks.md).
Durante um evento detectado pelo Shield Advanced, o SRT usa o estado de suas verificações de integridade para determinar se o evento se qualifica para um engajamento proativo. Em caso positivo, o SRT entrará em contato com você de acordo com as orientações de contato fornecidas em sua configuração de engajamento proativo.
Você pode configurar até dez contatos para engajamento proativo e fornecer notas para orientar o SRT a entrar em contato com você. Seus contatos proativos de engajamento devem estar disponíveis para interagir com o SRT durante os eventos. Se você não tiver um centro de operações 24 horas por dia, 7 dias por semana, você pode fornecer um contato por pager e indicar essa preferência de contato em suas notas de contato.
O envolvimento proativo exige que você faça o seguinte:
+ Você deve ser assinante do plano [Business Support](https://aws.amazon.com/premiumsupport/business-support/) ou [Enterprise Support](https://aws.amazon.com/premiumsupport/enterprise-support/).
+ Você deve associar uma verificação de integridade do Amazon Route 53 a qualquer recurso que você queira proteger com um engajamento proativo. O SRT usa o status de suas verificações de integridade para ajudar a determinar se um evento exige engajamento proativo, por isso é importante que suas verificações de integridade reflitam com precisão o estado de seus recursos protegidos. Para obter mais informações e orientações, consulte [Detecção baseada em integridade usando verificações de integridade com o Shield Advanced e o Route 53](ddos-advanced-health-checks.md).
+ Para um recurso que tenha uma ACL AWS WAF da Web associada, você deve criar a ACL da Web usando AWS WAF (v2), que é a versão mais recente do. AWS WAF
+ Você deve fornecer pelo menos um contato para o SRT usar para engajamento proativo durante um evento. Mantenha suas informações de contato completas e atualizadas.
**Como habilitar o envolvimento proativo do SRT**
1. Na página **Visão geral** do AWS Shield console, em **Engajamento proativo e contatos**, na área de contatos, escolha **Editar**.
Na página **Editar contatos**, forneça as informações de contato das pessoas com as quais você deseja que o SRT entre em contato para um engajamento proativo.
Se você fornecer mais de um ponto de contato, em **Notas**, indique as circunstâncias em que cada contato deve ser usado. Inclua designações de contato primário e secundário e forneça os horários de disponibilidade e os fusos horários de cada contato.
Exemplos de notas de contato:
+ Esta é uma linha direta que funciona 24 horas por dia, 7 dias por semana, 365 dias por ano. Trabalhe com o analista atendente, que colocará a pessoa apropriada na chamada.
+ Entre em contato comigo se a linha direta não responder em 5 minutos.
1. Escolha **Salvar**.
A página **Visão geral** reflete as informações de contato atualizadas.
1. Escolha **Editar atributo de engajamento proativo**, escolha **Habilitar** e, em seguida, escolha **Salvar** para ativar o engajamento proativo.
# Entrar em contato com o SRT para obter ajuda com um evento DDo S suspeito
É possível entrar em contato com o SRT de uma das seguintes formas:
**Caso de suporte**
É possível abrir um caso no **AWS Shield** no console do **AWS Support Center**.
Para obter orientação sobre como criar um caso de suporte, consulte [AWS Support Center](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html).
Selecione a gravidade adequada à sua situação e forneça seus dados de contato. Na descrição, forneça o máximo de detalhes possível. Forneça informações sobre os recursos protegidos que você acredita que podem ser afetados e o estado atual da experiência do usuário final. Por exemplo, se a experiência do usuário for degradada ou partes do aplicativo estiverem indisponíveis no momento, forneça estas informações.
+ **Para ataques DDo S suspeitos** — Se a disponibilidade ou o desempenho do seu aplicativo estiverem atualmente afetados por um possível ataque DDo S, escolha as seguintes opções de gravidade e contato:
+ Para gravidade, escolha a maior gravidade disponível para seu plano de suporte:
+ Para suporte comercial, **Sistema de produção inativo: < 1 hora**.
+ Para suporte corporativo, **Sistema essencial para os negócios inativo: < 15 minutos**.
+ Para a opção de contato, selecione **Telefone** ou **Chat** e forneça seus detalhes. Usar um método de contato ao vivo fornece a resposta mais rápida.
**Envolvimento proativo**
Com o engajamento AWS Shield Advanced proativo, o SRT entra em contato com você diretamente se a verificação de saúde do Amazon Route 53 associada ao seu recurso protegido ficar insalubre durante um evento detectado. Para obter mais informações sobre essa opção, consulte [Como configurar um engajamento proativo para que o SRT entre em contato diretamente com você](ddos-srt-proactive-engagement.md).
# Configurando mitigações personalizadas contra ataques DDo S com o SRT
Esta página fornece instruções para trabalhar com o SRT para criar mitigações personalizadas contra ataques S. DDo
Para seu Elastic IPs (EIPs) e seus aceleradores AWS Global Accelerator padrão, você pode trabalhar com o SRT para configurar mitigações personalizadas. Isso é útil caso você conheça uma lógica específica que deve ser aplicada quando uma mitigação é feita. Por exemplo, talvez você queira permitir somente o tráfego de determinados países, impor limites de taxa específicos, configurar validações opcionais, proibir fragmentos ou permitir somente o tráfego que corresponda a um padrão específico na carga útil do pacote.
Exemplos de soluções de mitigação personalizadas comuns incluem:
+ **Correspondência de padrões**: se você opera um serviço que interage com aplicativos do lado do cliente, você pode optar por combinar padrões conhecidos que são exclusivos desses aplicativos. Por exemplo, você pode operar um serviço de jogos ou comunicações que exija que o usuário final instale um software específico que você distribui. Você pode incluir um número mágico em cada pacote enviado pelo aplicativo ao seu serviço. Você pode combinar até 128 bytes (separados ou contíguos) de uma carga útil e cabeçalhos de pacotes TCP ou UDP não fragmentados. A correspondência pode ser expressa em notação hexadecimal como um deslocamento específico do início da carga útil do pacote ou um deslocamento dinâmico após um valor conhecido. Por exemplo, a mitigação pode procurar o byte `0x01` e esperar `0x12345678` como os próximos quatro bytes.
+ **Específico de DNS** — Se você opera seu próprio serviço de DNS autoritativo usando serviços como o Global Accelerator ou o Amazon Elastic Compute Cloud (Amazon EC2), você pode solicitar uma mitigação personalizada que valide pacotes para garantir que sejam consultas de DNS válidas e aplicar uma pontuação de suspeita que avalie atributos específicos do tráfego de DNS.
Para saber mais sobre como trabalhar com o SRT para criar mitigações personalizadas, crie um caso de suporte em AWS Shield. Para saber mais sobre a criação de AWS Support casos, consulte [Introdução ao AWS Support](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html).
# Proteções de recursos em AWS Shield Advanced
Você pode adicionar e configurar AWS Shield Advanced proteções para seus recursos. Você pode gerenciar as proteções de um único recurso e agrupar seus recursos protegidos em coleções lógicas para melhorar o gerenciamento de eventos. Você também pode monitorar as alterações nas proteções do Shield Advanced usando AWS Config.
**nota**
O Shield Advanced protege somente os recursos que você especificou no Shield Advanced ou por meio de uma política AWS Firewall Manager do Shield Advanced. Ele não protege automaticamente seus recursos.
Se você estiver usando uma política AWS Firewall Manager Shield Advanced, não precisará gerenciar as proteções dos recursos que estão no escopo da política. O Firewall Manager gerencia automaticamente as proteções de contas e recursos que estão no escopo de uma política, de acordo com a configuração da política. Para obter mais informações, consulte [Usando AWS Shield Advanced políticas no Firewall Manager](shield-policies.md).
**Topics**
+ [Lista de recursos que AWS Shield Advanced protegem](ddos-protections-by-resource-type.md)
+ [Protegendo EC2 instâncias da Amazon e balanceadores de carga de rede com o Shield Advanced](ddos-protections-ec2-nlb.md)
+ [Protegendo a camada de aplicação (camada 7) com AWS Shield Advanced e AWS WAF](ddos-app-layer-protections.md)
+ [Detecção baseada em integridade usando verificações de integridade com o Shield Advanced e o Route 53](ddos-advanced-health-checks.md)
+ [Adicionando AWS Shield Advanced proteção aos AWS recursos](configure-new-protection.md)
+ [AWS Shield Advanced Proteções de edição](manage-protection.md)
+ [Como criar alarmes e notificações para recursos protegidos pelo Shield Advanced](add-alarm-ddos.md)
+ [Removendo a AWS Shield Advanced proteção de um AWS recurso](remove-protection.md)
+ [Agrupando suas proteções AWS Shield Advanced](ddos-protection-groups.md)
+ [A proteção avançada de recursos do Tracking Shield muda em AWS Config](ddos-add-config.md)
# Lista de recursos que AWS Shield Advanced protegem
Esta seção fornece informações sobre as proteções do Shield Advanced para cada tipo de recurso.
O Shield Advanced protege AWS recursos nas camadas de rede e transporte (camadas 3 e 4) e na camada de aplicação (camada 7). Você pode proteger alguns recursos diretamente e outros por meio da associação com recursos protegidos. O Shield Advanced suporta IPv4 e não suporta IPv6.
**nota**
O Shield Advanced protege somente os recursos que você especificou no Shield Advanced ou por meio de uma política AWS Firewall Manager do Shield Advanced. Ele não protege automaticamente seus recursos.
Você pode usar o Shield Advanced para monitoramento e proteção avançados com os seguintes tipos de recursos:
+ CloudFront Distribuições da Amazon. Para implantação CloudFront contínua, o Shield Advanced protege qualquer distribuição temporária associada a uma distribuição primária protegida.
+ Zonas hospedadas do Amazon Route 53.
+ AWS Global Accelerator aceleradores padrão.
+ Endereços IP EC2 elásticos da Amazon. O Shield Advanced protege os recursos associados aos endereços IP elásticos protegidos.
+ EC2 Instâncias da Amazon, por meio da associação com endereços IP EC2 elásticos da Amazon.
+ Os seguintes balanceadores de carga do Elastic Load Balancing (ELB):
+ Application Load Balancers.
+ Classic Load Balancers.
+ Balanceadores de carga de rede, por meio de associações com endereços IP da Amazon EC2 Elastic.
**nota**
Você não pode usar o Shield Advanced para proteger nenhum outro tipo de recurso. Por exemplo, você não pode proteger aceleradores de roteamento personalizados do AWS Global Accelerator ou balanceadores de carga de gateway.
**nota**
Os gateways NAT lidam somente com tráfego de saída, enquanto o Shield Advanced protege contra S de entrada. DDo Para proteção do tráfego de saída, use [AWS Network Firewall](https://docs.aws.amazon.com//network-firewall/latest/developerguide/what-is-aws-network-firewall.html).
Você pode monitorar e proteger até 1.000 recursos de cada um desses tipos de recurso por Conta da AWS. Por exemplo, em uma única conta, você pode proteger 1.000 endereços IP EC2 elásticos da Amazon, 1.000 CloudFront distribuições e 1.000 Application Load Balancers. Você pode solicitar um aumento no número de recursos que você pode proteger com o Shield Advanced por meio do console Service Quotas em. [https://console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/)
# Protegendo EC2 instâncias da Amazon e balanceadores de carga de rede com o Shield Advanced
Esta página explica como usar AWS Shield Advanced proteções para EC2 instâncias da Amazon e balanceadores de carga de rede.
Você pode proteger as EC2 instâncias da Amazon e os Network Load Balancers anexando primeiro esses recursos aos endereços IP elásticos e, em seguida, protegendo os endereços IP elásticos no Shield Advanced.
Quando você protege endereços IP elásticos, o Shield Advanced identifica e protege os recursos aos quais eles estão conectados. O Shield Advanced identifica automaticamente o tipo de recurso anexado a um endereço IP elástico e aplica as detecções e mitigações apropriadas para esse recurso. Isso inclui a configuração de redes ACLs específicas para o endereço IP elástico. Para obter mais informações sobre como usar endereços IP elásticos com seus recursos da AWS , consulte o guia apropriado: [documentação do Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/ec2/) ou [Documentação do Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/).
Durante um ataque, o Shield Advanced implanta automaticamente sua rede ACLs na borda da AWS rede. Quando sua rede ACLs está na fronteira da rede, o Shield Advanced pode fornecer proteção contra eventos DDo S maiores. Normalmente, a rede ACLs é aplicada perto de suas EC2 instâncias da Amazon em sua Amazon VPC. A rede ACL pode atenuar ataques somente até a capacidade máxima de processamento da Amazon VPC e da instância. Por exemplo, se a interface de rede conectada à sua EC2 instância da Amazon puder processar até 10 Gbps, os volumes acima de 10 Gbps ficarão mais lentos e possivelmente bloquearão o tráfego para essa instância. Durante um ataque, o Shield Advanced promove sua network ACL para a borda da AWS , que pode processar vários terabytes de tráfego. Sua network ACL é capaz de oferecer proteção para seu recurso muito além da capacidade típica da sua rede. Para obter mais informações sobre rede ACLs, consulte [Rede ACLs](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html).
Algumas ferramentas de escalabilidade, por exemplo AWS Elastic Beanstalk, não permitem que você anexe automaticamente um endereço IP elástico a um Network Load Balancer. Nesses casos, você precisa anexar manualmente o endereço IP elástico.
# Protegendo a camada de aplicação (camada 7) com AWS Shield Advanced e AWS WAF
Esta página explica como a Shield Advanced e a Shield AWS WAF trabalham juntas para proteger os recursos na camada de aplicação (camada 7).
Para proteger os recursos da camada de aplicação com o Shield Advanced, você começa associando uma web ACL do AWS WAF ao recurso e adicionando uma ou mais regras baseadas em intervalos a ela. Além disso, você pode ativar a mitigação automática da camada DDo S do aplicativo, o que faz com que o Shield Advanced crie e gerencie automaticamente regras de ACL da web em seu nome em resposta aos DDo ataques S.
Quando você protege um recurso da camada de aplicação com o Shield Advanced, o Shield Advanced analisa o tráfego ao longo do tempo para estabelecer e manter as referências. O Shield Advanced usa essas linhas de base para detectar anomalias nos padrões de tráfego que podem indicar um ataque S. DDo O ponto em que o Shield Advanced detecta um ataque depende do tráfego que o Shield Advanced conseguiu observar antes do ataque e da arquitetura que você usa para seus aplicativos web. As variações arquitetônicas que podem afetar o comportamento do Shield Advanced incluem o tipo de instância que você usa, o tamanho da instância e se o tipo de instância oferece suporte a redes aprimoradas. Você também pode configurar o Shield Advanced para colocar automaticamente mitigações para ataques na camada de aplicação.
**Assinaturas e custos do Shield Advanced AWS WAF**
Sua assinatura do Shield Advanced cobre os custos de uso dos AWS WAF recursos padrão dos recursos que você protege com o Shield Advanced. As AWS WAF taxas padrão cobertas pelas proteções Shield Advanced são o custo por pacote de proteção (web ACL), o custo por regra e o preço base por milhão de solicitações para inspeção de solicitações na web, até 1.500 WCUs e até o tamanho padrão do corpo.
Ativar a mitigação automática da camada DDo S do aplicativo Shield Advanced adiciona um grupo de regras ao seu pacote de proteção (Web ACL) que usa 150 unidades de capacidade Web ACL (). WCUs Isso WCUs conta contra o uso da WCU em seu pacote de proteção (web ACL). Para obter mais informações, consulte [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md), [Como proteger a camada de aplicativos com o grupo de regras do Shield Advanced](ddos-automatic-app-layer-response-rg.md) e [Unidades de capacidade do Web ACL (WCUs) em AWS WAF](aws-waf-capacity-units.md).
Sua assinatura do Shield Advanced não cobre o uso AWS WAF de recursos que você não protege usando o Shield Advanced. Também não cobre nenhum custo adicional não padronizado AWS WAF para recursos protegidos. Exemplos de AWS WAF custos não padronizados são aqueles do Bot Control, da ação da CAPTCHA regra, da web ACLs que usa mais de 1.500 WCUs e da inspeção do corpo da solicitação além do tamanho padrão. A lista completa é fornecida na página AWS WAF de preços. Sua assinatura do Shield Advanced inclui acesso ao grupo Amazon Managed Rule de camada 7 DDo anti-S. Como parte de sua assinatura, você receberá até 50 bilhões de solicitações para AWS WAF recursos protegidos do Shield Advanced em um mês civil. Solicitações acima de 50 bilhões serão cobradas de acordo com a página AWS Shield Advanced de preços.
Para obter informações completas e exemplos de preços, consulte [Preços do Shield](https://aws.amazon.com/shield/pricing/) e [Preços do AWS WAF](https://aws.amazon.com/waf/pricing/).
**Topics**
+ [Lista de fatores que afetam a detecção e mitigação de eventos na camada de aplicativo com o Shield Advanced](ddos-app-layer-detection-mitigation.md)
+ [Protegendo a camada de aplicação com AWS WAF web ACLs e Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md)
+ [Protegendo a camada de aplicativos com regras AWS WAF baseadas em taxas e Shield Advanced](ddos-app-layer-rbr.md)
+ [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md)
# Lista de fatores que afetam a detecção e mitigação de eventos na camada de aplicativo com o Shield Advanced
Esta seção descreve os fatores que afetam a detecção e a mitigação dos eventos da camada de aplicativo pelo Shield Advanced.
**Verificações de integridade**
As verificações de integridade que relatam com precisão a integridade geral do seu aplicativo fornecem ao Shield Advanced informações sobre as condições de tráfego que seu aplicativo está enfrentando. O Shield Advanced exige menos informações que apontem para um possível ataque quando seu aplicativo está relatando problemas de integridade e exige mais evidências de um ataque se seu aplicativo estiver relatando integridade.
É importante configurar suas verificações de integridade para que elas relatem com precisão a integridade do aplicativo. Para obter mais informações e orientações, consulte [Detecção baseada em integridade usando verificações de integridade com o Shield Advanced e o Route 53](ddos-advanced-health-checks.md).
**Linhas de base de tráfego**
As linhas de base de tráfego fornecem ao Shield Advanced informações sobre as características do tráfego normal do seu aplicativo. O Shield Advanced usa essas linhas de base para reconhecer quando seu aplicativo não está recebendo tráfego normal, para que ele possa notificá-lo e, conforme configurado, começar a criar e testar opções de mitigação para combater um possível ataque. Para obter informações adicionais sobre como o Shield Advanced usa linhas de base de tráfego para detectar possíveis eventos, consulte a seção de visão geral [Lógica de detecção do Shield Advanced para ameaças na camada de aplicativo (camada 7)](ddos-event-detection-application.md).
O Shield Advanced cria suas linhas de base a partir das informações fornecidas pela ACL da Web que estão associadas ao recurso protegido. A ACL da Web deve estar associada ao recurso por pelo menos 24 horas e até 30 dias antes que o Shield Advanced possa determinar com segurança as linhas de base do aplicativo. O tempo necessário começa quando você associa a Web ACL, por meio do Shield Advanced ou por meio do AWS WAF.
Para obter mais informações sobre o uso de uma Web ACL com as proteções da camada de aplicativo do Shield Advanced, consulte [Protegendo a camada de aplicação com AWS WAF web ACLs e Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md).
**Regras com base em taxa**
Regras baseadas em intervalos podem ajudar a mitigar ataques. Elas também podem obscurecer os ataques, mitigando-os antes que se tornem um problema grande o suficiente para aparecer nas linhas de base do tráfego normal ou nos relatórios de status da verificação de integridade.
Recomendamos o uso de regras baseadas em intervalos em sua ACL da Web ao proteger um recurso de aplicativo com o Shield Advanced. Embora suas mitigações possam ocultar um possível ataque, elas são uma valiosa primeira linha de defesa, ajudando a garantir que seu aplicativo permaneça disponível para seus clientes legítimos. O tráfego que suas regras baseadas em intervalos detectam e limitam a taxa é visível em suas métricas do AWS WAF .
Além de suas próprias regras baseadas em taxas, se você ativar a mitigação automática da camada DDo S do aplicativo, o Shield Advanced adicionará um grupo de regras à sua ACL da web que ele usa para mitigar ataques. Nesse grupo de regras, o Shield Advanced sempre tem uma regra baseada em taxas que limita o volume de solicitações de endereços IP que são conhecidos como fontes de ataques DDo S. As métricas do tráfego que as regras do Shield Advanced mitigam não estão disponíveis para você visualizar.
Para obter mais informações sobre regras baseadas em intervalo, consulte [Usando declarações de regras baseadas em taxas em AWS WAF](waf-rule-statement-type-rate-based.md). Para obter informações sobre a regra baseada em taxas que o Shield Advanced usa para mitigação automática da camada DDo S do aplicativo, consulte. [Como proteger a camada de aplicativos com o grupo de regras do Shield Advanced](ddos-automatic-app-layer-response-rg.md)
Para obter mais informações sobre Shield Advanced e AWS WAF métricas, consulte[Monitoramento com a Amazon CloudWatch](monitoring-cloudwatch.md).
# Protegendo a camada de aplicação com AWS WAF web ACLs e Shield Advanced
Esta página explica como a AWS WAF web ACLs e o Shield Advanced trabalham juntos para criar proteções básicas na camada de aplicação.
Para proteger um recurso da camada de aplicativo com o Shield Advanced, você começa associando uma ACL AWS WAF da web ao recurso. AWS WAF é um firewall de aplicativo web que permite monitorar as solicitações HTTP e HTTPS que são encaminhadas para os recursos da camada de aplicativos e permite controlar o acesso ao seu conteúdo com base nas características das solicitações. Você pode configurar uma web ACL para monitorar e gerenciar solicitações com base em fatores como a origem da solicitação, o conteúdo das sequências de caracteres de consulta e dos cookies e a taxa de solicitações provenientes de um único endereço IP. No mínimo, sua proteção Shield Advanced exige que você associe uma web ACL a uma regra baseada em intervalos, que limita a taxa de solicitações para cada endereço IP.
Se a web ACL associada não tiver uma regra baseada em intervalos definida, o Shield Advanced solicitará que você defina pelo menos uma. As regras baseadas em taxas bloqueiam automaticamente o tráfego da origem IPs quando excedem os limites definidos por você. Eles ajudam a proteger seu aplicativo contra inundações de solicitações da web e podem fornecer alertas sobre picos repentinos no tráfego que podem indicar um possível ataque DDo S.
**nota**
Uma regra baseada em intervalos responde muito rapidamente aos picos no tráfego que a regra está monitorando. Por esse motivo, uma regra baseada em intervalos pode impedir não apenas um ataque, mas também a detecção de um possível ataque pela detecção do Shield Advanced. Essa compensação favorece a prevenção em vez da visibilidade completa dos padrões de ataque. Recomendamos usar uma regra baseada em intervalos como sua primeira linha de defesa contra ataques.
Com sua ACL da web em vigor, se ocorrer um ataque DDo S, você aplica mitigações adicionando e gerenciando regras na ACL da web. Você pode fazer isso diretamente, com a ajuda da Shield Response Team (SRT), ou automaticamente por meio da mitigação automática da camada DDo S do aplicativo.
**Importante**
Se você também usa a mitigação automática da camada DDo S do aplicativo, consulte as melhores práticas para gerenciar sua ACL da web em. [Melhores práticas para usar a mitigação automática da camada DDo S de aplicação](ddos-automatic-app-layer-response-bp.md)
Para obter informações sobre como usar AWS WAF para gerenciar suas regras de monitoramento e gerenciamento de solicitações da web, consulte[Criando um pacote de proteção (web ACL) no AWS WAF](web-acl-creating.md).
# Protegendo a camada de aplicativos com regras AWS WAF baseadas em taxas e Shield Advanced
Esta página explica como as regras AWS WAF baseadas em taxas e o Shield Advanced trabalham juntos para criar proteções básicas na camada de aplicação.
Quando você usa uma regra baseada em taxa com sua configuração padrão, avalia AWS WAF periodicamente o tráfego na janela de tempo anterior de 5 minutos. AWS WAF bloqueia solicitações de qualquer endereço IP que exceda o limite da regra até que a taxa de solicitação caia para um nível aceitável. Ao configurar uma regra baseada em intervalos usando o Shield Advanced, configure seu limite de intervalo para um valor maior do que o intervalo de tráfego normal que você espera de qualquer IP de origem em qualquer janela de cinco minutos.
Talvez você queira usar mais de uma regra baseada em intervalos em uma web ACL. Por exemplo, você pode ter uma regra baseada em intervalos para todo o tráfego que tenha um limite alto, além de uma ou mais regras adicionais configuradas para corresponder a partes selecionadas do seu aplicativo web e que tenham limites mais baixos. Por exemplo, você pode combinar o URI `/login.html` com um limite mais baixo para mitigar o abuso em uma página de login.
Você pode configurar uma regra baseada em intervalo para usar uma janela de tempo de avaliação diferente e agregar solicitações por vários componentes da solicitação, como valores de cabeçalho, rótulos e argumentos de consulta. Para obter mais informações, consulte [Usando declarações de regras baseadas em taxas em AWS WAF](waf-rule-statement-type-rate-based.md).
Para obter informações e orientações adicionais, consulte a postagem do blog de segurança [As três regras AWS WAF baseadas em taxas mais importantes](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/).
**Opções de configuração expandidas por meio de AWS WAF**
O console do Shield Advanced permite que você adicione uma regra baseada em intervalos e a configure com as configurações básicas e padrão. Você pode definir opções de configuração adicionais gerenciando suas regras baseadas em taxas por meio de. AWS WAF Por exemplo, você pode configurar a regra para agregar solicitações com base em chaves como um endereço IP encaminhado, uma sequência de caracteres de consulta e um rótulo. Você também pode adicionar uma declaração de redução de escopo à regra para filtrar algumas solicitações de avaliação e limitação de intervalo. Para obter mais informações, consulte [Usando declarações de regras baseadas em taxas em AWS WAF](waf-rule-statement-type-rate-based.md).
# Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced
**nota**
A partir de 26 de março de 2026, o DDo Anti-S Managed Rule Group (Anti-DDoS AMR) AWS WAF se torna a solução padrão para proteção contra ataques de inundação de solicitações HTTP (consulte o blog de lançamento do [DDoAnti-S](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-the-aws-waf-application-layer-ddos-protection/) AMR). Ele substitui o recurso de mitigação automática da camada 7 (L7AM). Se você já é cliente do Shield Advanced, pode continuar usando a solução antiga com AWS contas novas ou existentes. No entanto, recomendamos que você adote o DDo Anti-S Managed Rule Group. O DDo Anti-S Managed Rule Group detecta e mitiga ataques em segundos, em vez de minutos. Se você for um novo cliente do Shield Advanced e precisar de acesso à solução antiga, entre em contato com o AWS Support.
Esta página apresenta o tópico da mitigação automática da camada DDo S do aplicativo e lista as advertências associadas.
Você pode configurar o Shield Advanced para responder automaticamente para mitigar os ataques na camada de aplicação (camada 7) contra seus recursos protegidos da camada de aplicação, contando ou bloqueando as solicitações da web que fazem parte do ataque. Essa opção é uma adição à proteção da camada de aplicação que você adiciona por meio do Shield Advanced com uma ACL AWS WAF da web e sua própria regra baseada em taxas.
Quando a mitigação automática está habilitada para um recurso, o Shield Avançado mantém um grupo de regras na ACL da Web que está associada ao recurso, em que gerencia as regras de mitigação em nome do recurso. O grupo de regras contém uma regra baseada em taxas que rastreia o volume de solicitações de endereços IP que são conhecidos por serem fontes de ataques DDo S.
Além disso, o Shield Advanced compara os padrões de tráfego atuais com as linhas de base do tráfego histórico para detectar desvios que possam indicar um ataque S. DDo O Shield Advanced responde aos ataques DDo S detectados criando, avaliando e implantando AWS WAF regras personalizadas adicionais no grupo de regras.
## Advertências para usar a mitigação automática da camada S de DDo aplicação
A lista a seguir descreve as advertências da mitigação automática da camada DDo S do aplicativo Shield Advanced e descreve as etapas que talvez você queira seguir em resposta.
+ A mitigação automática da camada DDo S do aplicativo funciona somente com pacotes de proteção (web ACLs) que foram criados usando a versão mais recente do AWS WAF (v2).
+ O Shield Advanced requer tempo para estabelecer uma linha de base do tráfego normal e histórico do seu aplicativo, que ele utiliza para detectar e isolar o tráfego de ataque do tráfego normal, a fim de mitigar o tráfego de ataque. O tempo para estabelecer uma linha de base é entre 24 horas e 30 dias a partir do momento em que você associa uma ACL da Web ao recurso de aplicativo protegido. Para obter mais informações sobre linhas de base de tráfego, consulte [Lista de fatores que afetam a detecção e mitigação de eventos na camada de aplicativo com o Shield Advanced](ddos-app-layer-detection-mitigation.md).
+ A ativação da mitigação automática da camada DDo S do aplicativo adiciona um grupo de regras ao seu pacote de proteção (Web ACL) que usa 150 unidades de capacidade da Web ACL (). WCUs Isso WCUs conta contra o uso da WCU em seu pacote de proteção (web ACL). Para ter mais informações, consulte [Como proteger a camada de aplicativos com o grupo de regras do Shield Advanced](ddos-automatic-app-layer-response-rg.md) e [Unidades de capacidade do Web ACL (WCUs) em AWS WAF](aws-waf-capacity-units.md).
+ O grupo de regras Shield Advanced gera AWS WAF métricas, mas elas não estão disponíveis para visualização. Isso é o mesmo que para qualquer outro grupo de regras que você usa em seu pacote de proteção (web ACL), mas não possui, como grupos de regras de regras AWS gerenciadas. Para obter mais informações sobre AWS WAF métricas, consulte[AWS WAF métricas e dimensões](waf-metrics.md). Para saber mais sobre essa opção de proteção do Shield Advanced, consulte [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](#ddos-automatic-app-layer-response).
+ Para a web ACLs que protege vários recursos, a mitigação automática implementa apenas mitigações personalizadas que não afetam negativamente nenhum dos recursos protegidos.
+ O tempo entre o início de um ataque DDo S e o momento em que o Shield Advanced coloca regras personalizadas de mitigação automática varia de acordo com cada evento. Alguns ataques DDo S podem terminar antes que as regras personalizadas sejam implantadas. Outros ataques podem ocorrer quando já existe uma mitigação e, portanto, podem ser mitigados por essas regras desde o início do evento. Além disso, as regras baseadas em intervalo no grupo de regras da ACL da Web e do Shield Advanced podem mitigar o tráfego de ataque antes que ele seja detectado como um possível evento.
+ Para Application Load Balancers que recebem qualquer tráfego por meio de uma rede de distribuição de conteúdo (CDN), como a Amazon CloudFront, os recursos de mitigação automática da camada de aplicação do Shield Advanced para esses recursos do Application Load Balancer serão reduzidos. O Shield Advanced usa atributos de tráfego do cliente para identificar e isolar o tráfego de ataque do tráfego normal para seu aplicativo e CDNs pode não preservar ou encaminhar os atributos originais do tráfego do cliente. Se você usa CloudFront, recomendamos ativar a mitigação automática na CloudFront distribuição.
+ A mitigação automática da camada DDo S do aplicativo não interage com os grupos de proteção. Você pode ativar a mitigação automática para recursos que estão em grupos de proteção, mas o Shield Advanced não aplica automaticamente mitigações de ataques com base nas descobertas do grupo de proteção. O Shield Advanced aplica mitigações automáticas de ataques para recursos individuais.
**Contents**
+ [Advertências para usar a mitigação automática da camada S de DDo aplicação](#ddos-automatic-app-layer-response-caveats)
+ [Melhores práticas para usar a mitigação automática da camada DDo S de aplicação](ddos-automatic-app-layer-response-bp.md)
+ [Habilitando a mitigação automática da camada DDo S do aplicativo](ddos-automatic-app-layer-response-config.md)
+ [O que acontece quando você ativa a mitigação automática](ddos-automatic-app-layer-response-config.md#ddos-automatic-app-layer-response-enable)
+ [Como o Shield Advanced gerencia a mitigação automática](ddos-automatic-app-layer-response-behavior.md)
+ [Como o Shield Advanced responde aos ataques DDo S com mitigação automática](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-ddos-attack)
+ [Como o Shield Avançado gerencia a configuração de ação de regra](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-rule-action)
+ [Como o Shield Advanced gerencia as mitigações quando um ataque diminui](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-after-attack)
+ [O que acontece quando você desativa a mitigação automática](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-disable)
+ [Como proteger a camada de aplicativos com o grupo de regras do Shield Advanced](ddos-automatic-app-layer-response-rg.md)
+ [Visualizando a configuração automática de mitigação DDo da camada S de aplicação para um recurso](view-automatic-app-layer-response-configuration.md)
+ [Ativando e desativando a mitigação automática da camada DDo S do aplicativo](enable-disable-automatic-app-layer-response.md)
+ [Alterando a ação usada para mitigação automática da camada DDo S de aplicação](change-action-of-automatic-app-layer-response.md)
+ [Usando AWS CloudFormation com a mitigação automática da camada DDo S de aplicação](manage-automatic-mitigation-in-cfn.md)
# Melhores práticas para usar a mitigação automática da camada DDo S de aplicação
Siga as orientações fornecidas nesta seção ao usar a mitigação automática.
**Gerenciamento geral de proteções**
Siga estas diretrizes para planejar e implementar suas proteções de mitigação automática.
+ Gerencie todas as suas proteções de mitigação automática por meio do Shield Advanced ou, se você estiver usando AWS Firewall Manager para gerenciar suas configurações de mitigação automática do Shield Advanced, por meio do Firewall Manager. Não misture o uso do Shield Advanced com o Firewall Manager para gerenciar essas proteções.
+ Gerencie recursos semelhantes usando as mesmas configurações da Web ACLs e de proteção e gerencie recursos diferentes usando uma Web ACLs diferente. Quando o Shield Advanced mitiga um ataque DDo S a um recurso protegido, ele define regras para a ACL da web associada ao recurso e, em seguida, testa as regras em relação ao tráfego de todos os recursos associados à ACL da web. O Shield Advanced só aplicará as regras se elas não afetarem negativamente nenhum dos recursos associados. Para obter mais informações, consulte [Como o Shield Advanced gerencia a mitigação automática](ddos-automatic-app-layer-response-behavior.md).
+ Para balanceadores de carga de aplicativos que têm todo o tráfego da Internet enviado por proxy por meio de uma CloudFront distribuição da Amazon, ative apenas a mitigação automática na distribuição. CloudFront A CloudFront distribuição sempre terá o maior número de atributos de tráfego originais, que o Shield Advanced aproveita para mitigar os ataques.
**Otimização de detecção e mitigação**
Siga essas diretrizes para otimizar as proteções que a mitigação automática fornece aos recursos protegidos. Para obter uma visão geral da detecção e mitigação da camada de aplicativo, consulte [Lista de fatores que afetam a detecção e mitigação de eventos na camada de aplicativo com o Shield Advanced](ddos-app-layer-detection-mitigation.md).
+ Configure verificações de integridade para seus recursos protegidos e use-as para habilitar a detecção baseada na integridade em suas proteções do Shield Advanced. Para obter orientações, consulte [Detecção baseada em integridade usando verificações de integridade com o Shield Advanced e o Route 53](ddos-advanced-health-checks.md).
+ Ative a mitigação automática no modo Count até que o Shield Advanced estabeleça uma linha de base para o tráfego normal e histórico. O Shield Advanced precisa de 24 horas a 30 dias para estabelecer uma referência.
Como estabelecer uma linha de base dos padrões normais de tráfego é preciso o seguinte:
+ A associação de uma ACL da Web com o recurso protegido. Você pode usar AWS WAF diretamente para associar sua ACL da web ou pode fazer com que o Shield Advanced a associe ao habilitar a proteção da camada de aplicação Shield Advanced e especificar uma ACL da web a ser usada.
+ Fluxo de tráfego normal para seu aplicativo protegido. Se seu aplicativo não estiver recebendo tráfego normal, como antes do lançamento do aplicativo, ou se não tiver tráfego de produção por longos períodos de tempo, os dados históricos não poderão ser coletados.
**Gerenciamento da web ACL**
Siga estas diretrizes para gerenciar a web ACLs que você usa com mitigação automática.
+ Se você precisar substituir a ACL da Web associada ao recurso protegido, faça as seguintes alterações na ordem:
1. Desative a mitigação automática no Shield Advanced.
1. Em AWS WAF, desassocie a ACL da web antiga e associe a nova ACL da web.
1. Ative a mitigação automática no Shield Advanced.
O Shield Advanced não transfere automaticamente a mitigação automática da ACL da Web antiga para a nova.
+ Não exclua nenhuma regra de grupo de regras da sua web ACLs cujo nome comece com`ShieldMitigationRuleGroup`. Se você excluir esse grupo de regras, você desabilitará as proteções fornecidas pela mitigação automática do Shield Advanced para cada recurso associado à ACL da Web. Além disso, o Shield Advanced pode levar algum tempo para receber a notificação da alteração e atualizar as configurações. Durante esse período, as páginas do console Shield Advanced fornecerão informações incorretas.
Para saber mais sobre o grupo de regras, consulte [Como proteger a camada de aplicativos com o grupo de regras do Shield Advanced](ddos-automatic-app-layer-response-rg.md).
+ Não modifique o nome de uma regra do grupo de regras cujo nome comece por `ShieldMitigationRuleGroup`. Isso também pode interferir nas proteções fornecidas pela mitigação automática do Shield Advanced por meio da web ACL.
+ Ao criar regras e grupos de regras, não use nomes que comecem com `ShieldMitigationRuleGroup`. Essa sequência de caracteres é usada pelo Shield Advanced para gerenciar suas mitigações automáticas.
+ No gerenciamento de suas regras de web ACL, não atribua uma configuração de prioridade de 10.000.000. O Shield Advanced atribui essa configuração de prioridade à sua regra de grupo de regras de mitigação automática quando a adiciona.
+ Mantenha a regra `ShieldMitigationRuleGroup` priorizada para que ela seja executada quando você quiser em relação às outras regras em sua web ACL. O Shield Advanced adiciona a regra do grupo de regras à web ACL com prioridade 10.000.000, para ser executada após suas outras regras. Se você usar o assistente do AWS WAF console para gerenciar sua ACL da web, ajuste as configurações de prioridade conforme necessário depois de adicionar regras à ACL da web.
+ Se você usa AWS CloudFormation para gerenciar sua web ACLs, não precisa gerenciar a `ShieldMitigationRuleGroup` regra do grupo de regras. Siga as orientações em [Usando AWS CloudFormation com a mitigação automática da camada DDo S de aplicação](manage-automatic-mitigation-in-cfn.md).
# Habilitando a mitigação automática da camada DDo S do aplicativo
Essa página explica como configurar o Shield Advanced para responder automaticamente aos ataques na camada de aplicativo.
Você ativa a mitigação automática do Shield Advanced como parte das proteções da camada DDo S do aplicativo para seu recurso. Para saber mais sobre fazer isso no console, consulte [Configurar as proteções da camada DDo S do aplicativo](manage-protection.md#configure-app-layer-protection).
A funcionalidade de mitigação automática exige que você faça o seguinte:
+ **Associe uma web ACL ao recurso** — Isso é necessário para qualquer proteção da camada de aplicação Shield Advanced. É possível usar a mesma web ACL para vários recursos. Recomendamos fazer isso somente para recursos com tráfego semelhante. Para obter informações sobre a WebACLs, incluindo os requisitos para usá-las com vários recursos, consulte[Como AWS WAF funciona](how-aws-waf-works.md).
+ **Ativar e configurar a mitigação automática da camada DDo S do aplicativo Shield Advanced** — Ao habilitar isso, você especifica se deseja que o Shield Advanced bloqueie ou conte automaticamente as solicitações da web que ele determina como parte de um ataque DDo S. O Shield Advanced adiciona um grupo de regras à ACL da web associada e o usa para gerenciar dinamicamente sua resposta aos ataques DDo S ao recurso. Para saber mais sobre as opções de ações de regras, consulte [Usando ações de regras em AWS WAF](waf-rule-action.md).
+ **(Opcional, mas recomendado) Adicione uma regra baseada em taxa à ACL da web** — Por padrão, a regra baseada em taxa fornece ao seu recurso proteção básica contra ataques DDo S, impedindo que qualquer endereço IP individual envie muitas solicitações em pouco tempo. Para saber mais sobre regras baseadas em intervalos, incluindo opções e exemplos personalizados de agregação de solicitações, consulte [Usando declarações de regras baseadas em taxas em AWS WAF](waf-rule-statement-type-rate-based.md).
## O que acontece quando você ativa a mitigação automática
O Shield Advanced faz o seguinte quando você ativa a mitigação automática:
+ **Conforme necessário, adiciona um grupo de regras para uso do Shield Advanced** — Se a ACL AWS WAF da web que você associou ao recurso ainda não tiver uma AWS WAF regra de grupo de regras dedicada à mitigação automática da camada DDo S do aplicativo, o Shield Advanced adicionará uma.
O nome da regra do grupo de regras começa com `ShieldMitigationRuleGroup`. O grupo de regras sempre contém uma regra baseada em taxas chamada`ShieldKnownOffenderIPRateBasedRule`, que limita o volume de solicitações de endereços IP que são conhecidos por serem fontes de ataques DDo S. Para obter detalhes adicionais sobre o grupo de regras do Shield Avançado e a regra de ACL da Web que faz referência a ele, consulte [Como proteger a camada de aplicativos com o grupo de regras do Shield Advanced](ddos-automatic-app-layer-response-rg.md).
+ **Começa a responder aos ataques DDo S contra o recurso** — o Shield Advanced responde automaticamente aos ataques DDo S do recurso protegido. Além da regra baseada em taxas, que está sempre presente, o Shield Advanced usa seu grupo de regras para implantar AWS WAF regras personalizadas para mitigação de ataques DDo S. O Shield Advanced adapta essas regras ao seu aplicativo e aos ataques que seu aplicativo enfrenta e as testa em relação ao tráfego histórico do recurso antes de implantá-las.
O Shield Advanced usa uma única regra de grupo de regras em qualquer web ACL que você usa para mitigação automática. Se o Shield Avançado já tiver adicionado o grupo de regras para outro recurso protegido, ele não adicionará outro grupo de regras à ACL da Web.
A mitigação automática da camada DDo S do aplicativo depende da presença do grupo de regras para mitigar os ataques. Se o grupo de regras for removido da ACL da AWS WAF web por qualquer motivo, a remoção desativará a mitigação automática de todos os recursos associados à ACL da web.
# Como o Shield Advanced gerencia a mitigação automática
Os tópicos desta seção descrevem como o Shield Advanced lida com suas alterações de configuração para mitigação automática da camada DDo S do aplicativo e como ele lida com ataques DDo S quando a mitigação automática está ativada.
**Topics**
+ [Como o Shield Advanced responde aos ataques DDo S com mitigação automática](#ddos-automatic-app-layer-response-ddos-attack)
+ [Como o Shield Avançado gerencia a configuração de ação de regra](#ddos-automatic-app-layer-response-rule-action)
+ [Como o Shield Advanced gerencia as mitigações quando um ataque diminui](#ddos-automatic-app-layer-response-after-attack)
+ [O que acontece quando você desativa a mitigação automática](#ddos-automatic-app-layer-response-disable)
## Como o Shield Advanced responde aos ataques DDo S com mitigação automática
Quando você tem a mitigação automática ativada em um recurso protegido, a regra baseada em taxa no `ShieldKnownOffenderIPRateBasedRule` grupo de regras Shield Advanced responde automaticamente a volumes elevados de tráfego de fontes S conhecidas. DDo Essa limitação de volume é aplicada rapidamente e atua como uma defesa de linha de frente contra os ataques.
Quando o Shield Avançado detecta um ataque, ele faz o seguinte:
1. Tenta identificar uma assinatura de ataque que isole o tráfego de ataque do tráfego normal para seu aplicativo. O objetivo é produzir regras de mitigação DDo S de alta qualidade que, quando implementadas, afetem somente o tráfego de ataque e não afetem o tráfego normal do seu aplicativo.
1. Avalia a assinatura de ataque identificada em relação aos padrões históricos de tráfego do recurso que está sob ataque, bem como de qualquer outro recurso associado à mesma web ACL. O Shield Advanced faz isso antes de implantar qualquer regra em resposta ao evento.
Dependendo dos resultados da avaliação, o Shield Advanced executará um dos seguintes procedimentos:
+ Se o Shield Advanced determinar que a assinatura do ataque isola somente o tráfego envolvido no ataque DDo S, ele implementa a assinatura nas AWS WAF regras do grupo de regras de mitigação do Shield Advanced na ACL da web. O Shield Advanced fornece a essas regras a configuração de ação que você configurou para a mitigação automática do recurso - Count ou Block.
+ Caso contrário, o Shield Advanced não coloca uma mitigação.
Durante um ataque, o Shield Advanced envia as mesmas notificações e fornece as mesmas informações de eventos das proteções básicas da camada de aplicação do Shield Advanced. Você pode ver as informações sobre eventos e ataques DDo S, e sobre qualquer mitigação de ataques do Shield Advanced, no console de eventos do Shield Advanced. Para mais informações, consulte [Visibilidade DDo dos eventos S com o Shield Advanced](ddos-viewing-events.md).
Se você configurou a mitigação automática para usar a ação da regra Block e detectou falsos positivos nas regras de mitigação implantadas pelo Shield Advanced, você pode alterar a ação da regra para Count. Para saber mais sobre como fazer isso, consulte [Alterando a ação usada para mitigação automática da camada DDo S de aplicação](change-action-of-automatic-app-layer-response.md).
## Como o Shield Avançado gerencia a configuração de ação de regra
É possível definir a ação de regra para suas mitigações automáticas como Block ou Count.
Quando você altera a configuração de ação da regra de mitigação automática para um recurso protegido, o Shield Advanced atualiza todas as configurações de regra do recurso. Ele atualiza todas as regras atualmente em vigor para o recurso no grupo de regras do Shield Avançado e usa a nova configuração de ação ao criar novas regras.
Para os recursos que usam a mesma ACL da Web, se você especificar ações diferentes, o Shield Avançado usará a configuração de ação Block para a regra baseada em intervalos `ShieldKnownOffenderIPRateBasedRule` do grupo de regras. O Shield Avançado cria e gerencia outras regras no grupo de regras em nome de um recurso protegido específico e usa a configuração de ação que você especificou para o recurso. Todas as regras do grupo de regras do Shield Avançado em uma ACL da Web são aplicadas ao tráfego da Web de todos os recursos associados.
A alteração da configuração de ação pode levar alguns segundos para ser propagada. Durante esse período, você pode ver a configuração antiga em alguns lugares onde o grupo de regras está em uso, e a nova configuração em outros lugares.
Você pode alterar a configuração da ação da regra para sua configuração de mitigação automática na página de eventos do console e por meio da página de configuração da camada de aplicação. Para saber mais sobre eventos, consulte o [Respondendo aos eventos DDo S em AWS](ddos-responding.md). Para saber mais sobre a página de configuração, consulte [Configurar as proteções da camada DDo S do aplicativo](manage-protection.md#configure-app-layer-protection).
## Como o Shield Advanced gerencia as mitigações quando um ataque diminui
Quando o Shield Advanced determina que as regras de mitigação que foram implantadas para um ataque específico não são mais necessárias, ele as remove do grupo de regras de mitigação do Shield Advanced.
A remoção das regras de mitigação não coincidirá necessariamente com o fim de um ataque. O Shield Advanced monitora os padrões de ataque que ele detecta em seus recursos protegidos. Ele pode se defender proativamente contra a recorrência de um ataque com uma assinatura específica, mantendo em vigor as regras que implantou contra a ocorrência inicial desse ataque. Conforme necessário, o Shield Advanced aumenta a janela de tempo em que mantém as regras em vigor. Dessa forma, o Shield Advanced pode mitigar ataques repetidos com uma assinatura específica antes que eles afetem seus recursos protegidos.
O Shield Advanced nunca remove a regra baseada em taxas`ShieldKnownOffenderIPRateBasedRule`, que limita o volume de solicitações de endereços IP que são conhecidos por serem fontes de ataques DDo S.
## O que acontece quando você desativa a mitigação automática
O Shield Advanced faz o seguinte quando você desativa a mitigação automática para um recurso:
+ **Para de responder automaticamente aos ataques DDo S** — o Shield Advanced interrompe suas atividades de resposta automática para o recurso.
+ **Remove regras desnecessárias do grupo de regras do Shield Advanced** — Se o Shield Advanced estiver mantendo alguma regra em seu grupo de regras gerenciadas em nome do recurso protegido, ele as removerá.
+ **Remove o grupo de regras Shield Advanced, se ele não estiver mais em uso** — Se a web ACL que você associou ao recurso não estiver associada a nenhum outro recurso com a mitigação automática ativada, o Shield Advanced removerá sua regra de grupo de regras da web ACL.
# Como proteger a camada de aplicativos com o grupo de regras do Shield Advanced
Esta página explica como o grupo de regras do Shield Advanced funciona em sua ACL da Web.
O Shield Avançado gerencia atividades de mitigação automática usando regras em um grupo de regras de que ele é proprietário e gerencia para você. O Shield Avançado faz referência ao grupo de regras com uma regra na ACL da Web que você associou ao seu recurso protegido.
**A regra do grupo de regras em sua ACL da Web**
A regra do grupo de regras do Shield Avançado em sua ACL da Web tem as seguintes propriedades:
+ **Nome**: `ShieldMitigationRuleGroup``_account-id_web-acl-id_unique-identifier`
+ **Unidades de capacidade de web ACL (WCU)**: 150. Eles WCUs contam contra o uso da WCU em sua ACL da web.
O Shield Advanced cria essa regra em sua ACL da web com uma configuração de prioridade de 10.000.000, para que ela seja executada após suas outras regras e grupos de regras na ACL da web. AWS WAF executa as regras em uma ACL da web a partir da configuração de prioridade numérica mais baixa. Durante o gerenciamento da web ACL, essa configuração de prioridade pode mudar.
A funcionalidade de mitigação automática não consome nenhum AWS WAF recurso adicional em sua conta, além do WCUs usado pelo grupo de regras em sua ACL da web. Por exemplo, o grupo de regras do Shield Advanced não é contado como um dos grupos de regras da sua conta. Para obter informações sobre os limites da conta em AWS WAF, consulte[AWS WAF cotas](limits.md).
**Regras no grupo de regras**
Dentro do grupo de regras Shield Advanced referenciado, o Shield Advanced mantém uma regra baseada em taxas`ShieldKnownOffenderIPRateBasedRule`, que limita o volume de solicitações de endereços IP que são conhecidos como fontes de ataques S. DDo Essa regra atua como a primeira linha de defesa contra qualquer ataque, pois está sempre presente no grupo de regras e não depende da análise de padrões de tráfego para conter os ataques. A ação desta regra é definida como a ação que você escolhe para suas mitigações automáticas, assim como ocorre com as outras regras no grupo de regras. Para saber mais sobre regras baseadas em intervalos, consulte [Usando declarações de regras baseadas em taxas em AWS WAF](waf-rule-statement-type-rate-based.md).
**nota**
A regra baseada em intervalos `ShieldKnownOffenderIPRateBasedRule` opera independentemente da detecção de eventos do Shield Advanced. Embora a mitigação automática esteja ativada, essa taxa de regra limita os endereços IP que são conhecidos por serem fontes de ataques DDo S. Para esses endereços IP, a limitação de taxa da regra pode evitar ataques e também impedir que os ataques apareçam nas informações de detecção do Shield Advanced. Essa compensação favorece a prevenção em vez da visibilidade completa dos padrões de ataque.
Além da regra permanente baseada em taxas descrita acima, o grupo de regras contém todas as regras que o Shield Advanced está usando atualmente para mitigar os ataques S. DDo O Shield Avançado adiciona, modifica e remove essas regras, conforme necessário. Para mais informações, consulte [Como o Shield Advanced gerencia a mitigação automática](ddos-automatic-app-layer-response-behavior.md).
**Metrics**
O grupo de regras gera AWS WAF métricas, mas como esse grupo de regras é de propriedade da Shield Advanced, essas métricas não estão disponíveis para visualização. Para obter mais informações, consulte [AWS WAF métricas e dimensões](waf-metrics.md).
# Visualizando a configuração automática de mitigação DDo da camada S de aplicação para um recurso
Você pode visualizar a configuração automática de mitigação da camada DDo S da aplicação para um recurso na página **Recursos protegidos** e nas páginas de proteções individuais.
**Para visualizar a configuração automática de mitigação da camada DDo S do aplicativo**
1. Faça login Console de gerenciamento da AWS e abra o console AWS WAF & Shield em [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. No painel AWS Shield de navegação, escolha **Recursos protegidos**. Na lista de recursos protegidos, a coluna Mitigação **automática da camada DDo S do aplicativo indica se a mitigação** automática está ativada e, quando ativada, a ação que o Shield Advanced deve usar em suas mitigações.
Você também pode selecionar qualquer recurso da camada de aplicação para ver as mesmas informações listadas na página de proteções do recurso.
# Ativando e desativando a mitigação automática da camada DDo S do aplicativo
O procedimento a seguir mostra como ativar ou desativar a resposta automática para um recurso protegido.
**Para habilitar ou desabilitar a mitigação automática DDo da camada S de aplicação para um único recurso**
1. Faça login Console de gerenciamento da AWS e abra o console AWS WAF & Shield em [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. No painel AWS Shield de navegação, escolha **Recursos protegidos**.
1. Na guia **Proteções**, selecione o recurso da camada de aplicação para o qual você deseja ativar a mitigação automática. A página de proteções do recurso é aberta.
1. Na página de proteções do recurso, escolha **Editar**.
1. Na página **Configurar a mitigação da camada 7 DDo S para recursos globais - *opcional***, para a **mitigação automática da camada DDo S do aplicativo, escolha a opção que você deseja usar para mitigações** automáticas. As opções para o console são as seguintes:
+ **Manter as configurações atuais**: — Não fazer alterações nas configurações de mitigação automática do recurso protegido.
+ **Ativar**: — Ativar a mitigação automática para o recurso protegido. Ao escolher isso, selecione também a ação de regra que você deseja que as mitigações automáticas usem nas regras de web ACL. Para informações sobre as configurações de ações de regra, consulte [Usando ações de regras em AWS WAF](waf-rule-action.md).
Se seu recurso protegido ainda não tiver um histórico de tráfego normal de aplicativos, ative a mitigação automática no modo Count até que o Shield Advanced possa estabelecer uma linha de base. O Shield Advanced começa a coletar informações para sua linha de base quando você associa uma ACL da Web ao seu recurso protegido, e pode levar de 24 horas a 30 dias para estabelecer uma boa linha de base do tráfego normal.
+ **Desativar**: — Desativar a mitigação automática para o recurso protegido.
1. Percorra o restante das páginas até terminar e salve a configuração.
Na página **Proteções**, as configurações de mitigação automática são atualizadas para o recurso.
# Alterando a ação usada para mitigação automática da camada DDo S de aplicação
Você pode alterar a ação que o Shield Advanced usa para a resposta automática da camada de aplicação em vários locais no console:
+ **Configuração de mitigação automática**: — Altere a ação ao configurar a mitigação automática para seu recurso. Para ver o procedimento, consulte a seção [Ativando e desativando a mitigação automática da camada DDo S do aplicativo](enable-disable-automatic-app-layer-response.md) anterior.
+ **Página de detalhes do evento**: — Altere a ação na página de detalhes do evento ao visualizar as informações do evento no console. Para mais informações, consulte [Visualizando detalhes AWS Shield Advanced do evento](ddos-event-details.md).
Se você tem dois recursos protegidos que compartilham uma ACL da Web e define a ação como Count para um dos recursos e Block para o outro, o Shield Avançado definirá a ação da regra baseada em intervalos `ShieldKnownOffenderIPRateBasedRule` do grupo de regras como Block.
# Usando AWS CloudFormation com a mitigação automática da camada DDo S de aplicação
Esta página explica como usar CloudFormation para gerenciar suas proteções e a AWS WAF web ACLs.
**Ativando ou desativando a mitigação automática da camada DDo S do aplicativo**
Você pode ativar e desativar a mitigação automática da camada DDo S do aplicativo usando AWS CloudFormation o `AWS::Shield::Protection` recurso. O efeito é o mesmo de quando você ativa ou desativa o atributo por meio do console ou de qualquer outra interface. Para obter informações sobre o CloudFormation recurso, consulte [AWS::Shield::Protection](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-shield-protection.html)o *guia AWS CloudFormation do usuário*.
**Gerenciando a web ACLs usada com mitigação automática**
O Shield Advanced gerencia a mitigação automática para seu recurso protegido usando uma regra de grupo de regras na ACL da AWS WAF web do recurso protegido. Por meio do AWS WAF console APIs, você verá a regra listada em suas regras de ACL da web, com um nome que começa com`ShieldMitigationRuleGroup`. Essa regra é dedicada à mitigação automática da camada DDo S do aplicativo e é gerenciada para você pela Shield Advanced e. AWS WAF Para obter mais informações, consulte [Como proteger a camada de aplicativos com o grupo de regras do Shield Advanced](ddos-automatic-app-layer-response-rg.md) e [Como o Shield Advanced gerencia a mitigação automática](ddos-automatic-app-layer-response-behavior.md).
Se você usa CloudFormation para gerenciar sua web ACLs, não adicione a regra de grupo de regras Shield Advanced ao seu modelo de ACL da web. Quando você atualiza uma ACL da web que está sendo usada com suas proteções de mitigação automática, gerencia AWS WAF automaticamente a regra do grupo de regras na ACL da web.
Você verá as seguintes diferenças em comparação com outros sites ACLs que você gerencia por meio de CloudFormation:
+ CloudFormation não relatará nenhuma variação no status de desvio da pilha entre a configuração real da ACL da web, com a regra de grupo de regras Shield Advanced, e seu modelo de ACL da web, sem a regra. A regra Shield Advanced não aparecerá na listagem real do recurso nos detalhes de oscilação.
Você poderá ver a regra de grupo de regras do Shield Advanced nas listagens de ACL da web das quais você recupera AWS WAF, como por meio do AWS WAF console ou. AWS WAF APIs
+ Se você modificar o modelo de ACL da web em uma pilha, o AWS WAF Shield Advanced mantiver automaticamente a regra de mitigação automática do Shield Advanced na ACL da web atualizada. As proteções de mitigação automática fornecidas pelo Shield Advanced não são interrompidas por sua atualização na web ACL.
Não gerencie a regra Shield Advanced em seu modelo de ACL CloudFormation da web. O modelo de web ACL não deve listar a regra do Shield Advanced. Siga as práticas recomendadas para gerenciamento de web ACL em [Melhores práticas para usar a mitigação automática da camada DDo S de aplicação](ddos-automatic-app-layer-response-bp.md).
# Detecção baseada em integridade usando verificações de integridade com o Shield Advanced e o Route 53
Você pode configurar o Shield Advanced para usar a detecção baseada em integridade, o que pode melhorar a capacidade de resposta e a precisão na detecção e mitigação de ataques. Você pode usar essa opção com qualquer tipo de recurso, exceto para zonas hospedadas do Route 53.
Para configurar a detecção baseada em integridade, você define uma verificação de integridade para seu recurso no Route 53, verifica se o relatório indica integridade e, em seguida, associa-o à sua proteção Shield Advanced. Para saber mais sobre as verificações de integridade do Route 53, consulte [Como o Amazon Route 53 verifica a integridade de seus recursos](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/welcome-health-checks.html) e [Comocriar, atualizar e excluir verificações de integridade](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-deleting.html) no Guia do desenvolvedor do Amazon Route 53.
**nota**
As verificações de integridade são necessárias para o suporte de engajamento proativo da Shield Response Team (SRT). Para saber mais sobre engajamento proativo, consulte [Como configurar um engajamento proativo para que o SRT entre em contato diretamente com você](ddos-srt-proactive-engagement.md).
As verificações de integridade medem a integridade dos recursos com base nos requisitos definidos por você. O status da verificação de integridade fornece informações vitais para os mecanismos de detecção do Shield Advanced, o que lhe dá maior sensibilidade ao estado atual de seus aplicativos específicos.
Você pode usar a detecção baseada em integridade para qualquer tipo de recurso, exceto as zonas hospedadas do Route 53.
+ **Recursos da camada de rede e transporte (camada 3/camada 4)** — A detecção baseada em integridade melhora a precisão da detecção e mitigação de eventos na camada de rede e na camada de transporte para Network Load Balancers, endereços IP elásticos e aceleradores padrão do Global Accelerator. Quando você protege esses tipos de recursos com o Shield Advanced, o Shield Advanced pode fornecer mitigações para ataques menores e mitigação mais rápida para ataques, mesmo quando o tráfego está dentro da capacidade do aplicativo.
Ao adicionar detecção baseada em integridade, durante períodos em que a verificação de integridade associada não está íntegra, o Shield Advanced pode colocar mitigações ainda mais rapidamente e em limites ainda mais baixos.
+ **Recursos da camada de aplicativo (camada 7)** — A detecção baseada em integridade melhora a precisão da detecção de inundação de solicitações da web para CloudFront distribuições e balanceadores de carga de aplicativos. Ao proteger esses tipos de recursos com o Shield Advanced, você recebe alertas de detecção de inundação de solicitações da web quando há um desvio estatisticamente significativo no volume de tráfego combinado com mudanças significativas nos padrões de tráfego, com base nas características da solicitação.
Com a detecção baseada na integridade, quando a verificação de integridade do Route 53 associada revela que não há integridade, o Shield Advanced requer desvios menores para alertas e relata eventos mais rapidamente. Quando a verificação de integridade do Route 53 associada revela integridade, o Shield Advanced requer desvios maiores para alertas.
Você se beneficiará ao máximo com o uso de uma verificação de integridade com o Shield Advanced se a verificação de integridade só reportar integridade quando seu aplicativo estiver sendo executado dentro de parâmetros aceitáveis e só reportar falta de integridade quando ele não estiver. Use as orientações desta seção para gerenciar suas associações de verificação de integridade no Shield Advanced.
**nota**
O Shield Advanced não gerencia automaticamente suas verificações de integridade.
É necessário o seguinte para usar uma verificação de integridade com o Shield Advanced:
+ A verificação de integridade deve reportar integridade quando você a associa à proteção Shield Advanced.
+ A verificação de integridade deve ser relevante para a integridade do seu recurso protegido. Você é responsável por definir e manter as verificações de integridade que reportam adequadamente a integridade do seu aplicativo com base nos requisitos específicos do seu aplicativo.
+ A verificação de integridade deve permanecer disponível para ser usada pela proteção do Shield Advanced. Não exclua uma verificação de integridade no Route 53 que você está usando para obter uma proteção Shield Advanced.
**Contents**
+ [Práticas recomendadas para usar verificações de integridade com o Shield Advanced](health-checks-best-practices.md)
+ [CloudWatch métricas comumente usadas para verificações de saúde com o Shield Advanced](health-checks-metrics.md)
+ [Para monitorar a integridade do aplicativo](health-checks-metrics.md#health-checks-metrics-common)
+ [CloudWatch Métricas da Amazon para cada tipo de recurso](health-checks-metrics.md#health-checks-protected-resource-metrics)
+ [Como associar uma verificação de integridade ao seu recurso protegido pelo Shield Advanced](associate-health-check.md)
+ [Como desassociar uma verificação de integridade do seu recurso protegido pelo Shield Advanced](disassociate-health-check.md)
+ [Como visualizar o status da associação de verificação de integridade no Shield Advanced](health-check-association-status.md)
+ [Exemplos de verificação de integridade para o Shield Advanced](health-checks-examples.md)
+ [CloudFront Distribuições da Amazon](health-checks-examples.md#health-checks-example-cloudfront)
+ [Balanceadores de cargas](health-checks-examples.md#health-checks-example-load-balancer)
+ [Endereço IP EC2 elástico (EIP) da Amazon](health-checks-examples.md#health-checks-example-elastic-ip)
# Práticas recomendadas para usar verificações de integridade com o Shield Advanced
Siga as práticas recomendadas desta seção ao criar e usar verificações de integridade com o Shield Advanced.
+ Planeje suas verificações de integridade identificando os componentes da sua infraestrutura que você deseja monitorar. Considere os seguintes tipos de recursos para verificações de integridade:
+ Recursos críticos.
+ Qualquer recurso para o qual você queira maior sensibilidade na detecção e mitigação do Shield Advanced.
+ Recursos para os quais você deseja que o Shield Advanced entre em contato com você de forma proativa. O engajamento proativo é informado pelo status das suas verificações de integridade.
Exemplos de recursos que talvez você queira monitorar incluem CloudFront distribuições da Amazon, balanceadores de carga voltados para a Internet e instâncias do Amazon EC2.
+ Defina verificações de integridade que reflitam com precisão a integridade da origem do seu aplicativo com o mínimo de notificações possível.
+ Faça verificações de integridade para que elas só revelem falta de integridade quando seu aplicativo não estiver disponível ou não estiver funcionando dentro dos parâmetros aceitáveis. Você é responsável por definir e manter as verificações de integridade com base nos requisitos específicos do seu aplicativo.
+ Use o mínimo possível de verificações de integridade e, ao mesmo tempo, informe com precisão a integridade do seu aplicativo. Por exemplo, vários alarmes de várias áreas do seu aplicativo, todos relatando o mesmo problema, podem sobrecarregar suas atividades de resposta sem agregar valor informativo.
+ Use verificações de saúde calculadas para monitorar a integridade do aplicativo usando uma combinação de CloudWatch métricas da Amazon. Por exemplo, você pode calcular a integridade combinada com base na latência dos seus servidores de aplicativos e nas taxas de erro 5xx, que indicam que o servidor de origem não atendeu à solicitação.
+ Crie e publique seus próprios indicadores de integridade do aplicativo em métricas CloudWatch personalizadas conforme necessário e use-os em uma verificação de integridade calculada.
+ Implemente e gerencie suas verificações de integridade para melhorar a detecção e reduzir atividades de manutenção desnecessárias.
+ Antes de associar uma verificação de integridade a uma proteção do Shield Advanced, verifique se ela está em bom estado. Associar uma verificação de integridade que está relatando problemas de integridade pode distorcer os mecanismos de detecção do Shield Advanced para seus recursos protegidos.
+ Mantenha suas verificações de integridade disponíveis para uso pelo Shield Advanced. Não exclua uma verificação de integridade no Route 53 que você está usando para obter uma proteção Shield Advanced.
+ Use ambientes de teste e preparação somente para testar suas verificações de integridade. Mantenha associações de verificação de integridade somente para ambientes que exijam desempenho em nível de produção e disponibilidade. Não mantenha a associação de verificação de integridade no Shield Advanced para ambientes de teste e preparação.
# CloudWatch métricas comumente usadas para verificações de saúde com o Shield Advanced
Esta seção lista as CloudWatch métricas da Amazon que são comumente usadas em verificações de saúde para medir a integridade do aplicativo durante eventos distribuídos de negação de serviço (DDoS). Para obter informações completas sobre as CloudWatch métricas de cada tipo de recurso, consulte a lista que segue a tabela.
**Topics**
+ [Para monitorar a integridade do aplicativo](#health-checks-metrics-common)
+ [CloudWatch Métricas da Amazon para cada tipo de recurso](#health-checks-protected-resource-metrics)
## Para monitorar a integridade do aplicativo
| Recurso | Métrica | Description |
| --- | --- | --- |
| Route 53 | `HealthCheckStatus` | O status do endpoint da verificação de integridade. |
| CloudFront | `5xxErrorRate` | A porcentagem de todas as solicitações para as quais o código de status HTTP é 5xx. Isso indica um ataque que está afetando o aplicativo. |
| Application Load Balancer | `HTTPCode_ELB_5XX_Count` | O número de códigos de erro do cliente HTTP 5xx gerados pelo balanceador de carga. |
| Application Load Balancer | `RejectedConnectionCount` | O número de conexões que foram rejeitadas porque o balanceador de carga atingiu o número máximo de conexões. |
| Application Load Balancer | `TargetConnectionErrorCount` | O número de conexões que não foram estabelecidas com êxito entre o balanceador de carga e o destino. |
| Application Load Balancer | `TargetResponseTime` | O tempo decorrido, em segundos, depois que a solicitação deixa o balanceador de carga até o momento em que uma resposta do destino é recebida. |
| Application Load Balancer | `UnHealthyHostCount` | O número de destinos considerados sem integridade. |
| Amazon EC2 | `CPUUtilization` | A porcentagem de unidades EC2 computacionais alocadas que estão atualmente em uso. |
## CloudWatch Métricas da Amazon para cada tipo de recurso
Para obter informações adicionais sobre as métricas disponíveis para seus recursos protegidos, consulte as seções a seguir nos guias de recursos:
+ Amazon Route 53 — [Monitorando seus recursos com as verificações de saúde do Amazon Route 53 e a Amazon CloudWatch](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html) no Amazon Route 53 Developer Guide.
+ Amazon CloudFront — [Monitoramento CloudFront com a Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/monitoring-using-cloudwatch.html) no Amazon CloudFront Developer Guide.
+ Application Load Balancer — [CloudWatch métricas para seu Application Load](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) Balancer no Guia do usuário para Application Load Balancers.
+ Network Load Balancer — [CloudWatch métricas para seu Network Load](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html) Balancer no Guia do usuário para Network Load Balancers.
+ AWS Global Accelerator — [Usando a Amazon CloudWatch com AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/cloudwatch-monitoring.html) o Guia do AWS Global Accelerator Desenvolvedor.
+ Amazon Elastic Compute Cloud — [Liste as CloudWatch métricas disponíveis para suas instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) nas https://docs.aws.amazon.com/AWSEC2/ últimas UserGuide //.
+ Amazon EC2 Auto Scaling — [ CloudWatch Métricas de monitoramento para seus grupos e instâncias do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) no Guia do usuário do Amazon Auto EC2 Scaling.
# Como associar uma verificação de integridade ao seu recurso protegido pelo Shield Advanced
O procedimento a seguir mostra como associar uma verificação de integridade do Amazon Route 53 a um recurso protegido.
**nota**
Antes de associar uma verificação de integridade a uma proteção do Shield Advanced, verifique se ela está em bom estado. Para informações, consulte [Como monitorar o status da verificação de integridade e receber notificações](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-monitor-view-status.html) no Guia do desenvolvedor do Amazon Route 53.
**Para associar uma verificação de integridade**
1. Faça login Console de gerenciamento da AWS e abra o console AWS WAF & Shield em [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. No painel AWS Shield de navegação, escolha **Recursos protegidos**.
1. Na guia **Proteções**, selecione o recurso que você deseja associar a uma verificação de integridade.
1. Escolha **Configurar proteções**.
1. Escolha **Avançar** até chegar à página **Configurar a detecção DDo S com base na verificação de integridade - *opcional***.
1. Em **Verificação de integridade associada**, escolha o ID da verificação de integridade que deseja associar à proteção.
**nota**
Se você não vir a verificação de integridade necessária, vá até o console do Route 53 e verifique a verificação de integridade e seu ID. Para saber mais, consulte [Criar e atualizar verificações de integridade](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html).
1. Percorra o restante das páginas até terminar a configuração. Na página **Proteções**, sua associação de verificação de integridade atualizada está listada para o recurso.
1. Na página **Proteções**, verifique se sua verificação de integridade recém-associada está reportando integridade.
Você não pode começar a usar uma verificação de integridade no Shield Advanced enquanto a verificação de integridade estiver reportando problemas de integridade. Isso faz com que o Shield Advanced detecte falsos positivos em limites muito baixos e também pode afetar negativamente a capacidade da Shield Response Team (SRT) para fornecer engajamento proativo ao recurso.
Se a verificação de integridade recém-associada estiver reportando problemas de integridade, faça o seguinte:
1. Desassocie a verificação de integridade da sua proteção no Shield Advanced.
1. Revisite suas especificações de verificação de integridade no Amazon Route 53 e verifique o desempenho geral e a disponibilidade do aplicativo.
1. Quando seu aplicativo estiver funcionando dentro de seus parâmetros de boa integridade e sua verificação de integridade estiver reportando integridade, tente associar novamente a verificação de integridade no Shield Advanced.
O procedimento de associação de verificação de integridade é concluído quando você estabelece sua nova associação de verificação de integridade e ela é reportada como íntegra no Shield Advanced.
# Como desassociar uma verificação de integridade do seu recurso protegido pelo Shield Advanced
O procedimento a seguir mostra como desassociar uma verificação de integridade do Amazon Route 53 de um recurso protegido.
**Para desassociar uma verificação de integridade**
1. Faça login Console de gerenciamento da AWS e abra o console AWS WAF & Shield em [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. No painel AWS Shield de navegação, escolha **Recursos protegidos**.
1. Na guia **Proteções**, selecione o recurso que você deseja desassociar a uma verificação de integridade.
1. Escolha **Configurar proteções**.
1. Escolha **Avançar** até chegar à página **Configurar a detecção DDo S com base na verificação de integridade - *opcional***.
1. Em **Verificação de integridade associada**, escolha a opção vazia, listada como **-**.
1. Percorra o restante das páginas até terminar a configuração.
Na página **Proteções**, o campo de verificação de integridade do seu recurso está definido como **-**, indicando que não há associação de verificação de integridade.
# Como visualizar o status da associação de verificação de integridade no Shield Advanced
Você pode ver o status da verificação de integridade associada a uma proteção na página **Recursos protegidos** do AWS WAF e do console do Shield e na página de detalhes de cada recurso.
+ **Íntegro** - a verificação de integridade está disponível e reportando integridade.
+ **Sem integridade** - a verificação de integridade está disponível e está reportando falta de integridade.
+ **Indisponível** - a verificação de integridade não está disponível para uso pelo Shield Advanced.
**Para resolver uma verificação de integridade **Indisponível****
Crie e use uma nova verificação de integridade. Não tente associar uma verificação de integridade novamente depois que ela tiver o status de indisponível no Shield Advanced.
Para obter orientação detalhada sobre como seguir essas etapas, consulte os tópicos anteriores.
1. No Shield Advanced, desassocie a verificação de integridade do recurso.
1. No Route 53, crie uma verificação de integridade para a proteção e anote seu ID. Para informações, consulte [Criar e atualizar verificações de integridade](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html) no Guia do desenvolvedor do Amazon Route 53.
1. No Shield Advanced, associe a nova verificação de integridade ao recurso.
# Exemplos de verificação de integridade para o Shield Advanced
Esta seção mostra exemplos de verificação de integridade que você pode usar em uma verificação de integridade calculada. Uma verificação de integridade calculada usa várias verificações de integridade individuais para determinar um status combinado. O status de cada verificação de saúde individual é baseado na integridade de um endpoint ou no estado de uma CloudWatch métrica da Amazon. Você combina as verificações de integridade em uma verificação de integridade calculada e, em seguida, configura sua verificação de integridade calculada para relatar a integridade com base no status de integridade combinado das verificações de integridade individuais. Ajuste a sensibilidade de suas verificações de integridade calculadas de acordo com seus requisitos de desempenho e disponibilidade de aplicativos.
Para saber mais sobre verificações de integridade calculadas, consulte [Monitoramento de outras verificações de integridade (verificações de integridade calculadas)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-values.html#health-checks-creating-values-calculated) no Guia do desenvolvedor do Amazon Route 53. Para obter informações adicionais, consulte o post [Melhorias do Route 53 - Verificações de integridade calculadas e verificações de latência](https://aws.amazon.com/blogs/aws/route-53-improvements-calculated-health-checks-and-latency-checks/).
**Topics**
+ [CloudFront Distribuições da Amazon](#health-checks-example-cloudfront)
+ [Balanceadores de cargas](#health-checks-example-load-balancer)
+ [Endereço IP EC2 elástico (EIP) da Amazon](#health-checks-example-elastic-ip)
## CloudFront Distribuições da Amazon
Os exemplos a seguir descrevem as verificações de saúde que podem ser combinadas em uma verificação de saúde calculada para uma CloudFront distribuição:
+ Monitore um endpoint especificando um nome de domínio para um caminho na distribuição que está veiculando conteúdo dinâmico. Uma resposta de integridade incluiria os códigos de resposta HTTP 2xx e 3xx.
+ Monitore o estado de um CloudWatch alarme que está medindo a integridade da CloudFront origem. Por exemplo, você pode manter um CloudWatch alarme na métrica `TargetResponseTime` do Application Load Balancer e criar uma verificação de integridade que reflita o status do alarme. A verificação de integridade pode não reportar integridade quando o tempo de resposta, entre a solicitação que sai do balanceador de carga e o momento em que o balanceador de carga recebe uma resposta do destino, excede o limite configurado no alarme.
+ Monitore o estado de um CloudWatch alarme que mede a porcentagem de solicitações para as quais o código de status HTTP da resposta é 5xx. Se a taxa de erro 5xx da CloudFront distribuição for maior que o limite definido no CloudWatch alarme, o status dessa verificação de saúde mudará para não íntegro.
## Balanceadores de cargas
Os exemplos a seguir descrevem verificações de integridade que podem ser usadas em verificações de integridade calculadas para um Application Load Balancer, Network Load Balancer ou acelerador padrão Global Accelerator.
+ Monitore o estado de um CloudWatch alarme que mede o número de novas conexões estabelecidas pelos clientes com o balanceador de carga. Você pode definir o limite de alarme para o número médio de novas conexões em algum grau acima da média diária. As métricas para cada tipo de recurso são as seguintes:
+ Application Load Balancer: `NewConnectionCount`
+ Network Load Balancer: `ActiveFlowCount`
+ Global Accelerator: `NewFlowCount`
+ Para o Application Load Balancer e o Network Load Balancer, monitore o estado de CloudWatch um alarme que mede o número de balanceadores de carga considerados íntegros. Você pode definir o limite de alarme na Zona de Disponibilidade ou no número mínimo de hosts íntegros que seu balanceador de carga exige. As métricas disponíveis para os recursos do balanceador de carga são as seguintes:
+ Application Load Balancer: `HealthyHostCount`
+ Network Load Balancer: `HealthyHostCount`
+ Para o Application Load Balancer, monitore o estado de um CloudWatch alarme que mede o número de códigos de resposta HTTP 5xx gerados pelos destinos do balanceador de carga. Para um Application Load Balancer, você pode usar a métrica `HTTPCode_Target_5XX_Count` e basear o limite de alarme na soma de todos os 5xx erros do balanceador de carga.
## Endereço IP EC2 elástico (EIP) da Amazon
Os exemplos de verificações de saúde a seguir podem ser combinados em uma verificação de saúde calculada para um endereço IP EC2 elástico da Amazon:
+ Monitore um endpoint especificando um endereço IP para o endereço IP elástico. A verificação de integridade permanecerá íntegra enquanto uma conexão TCP puder ser estabelecida com o recurso por trás do endereço IP.
+ Monitore o estado de um CloudWatch alarme que mede a porcentagem de unidades EC2 computacionais alocadas da Amazon que estão atualmente em uso na instância. Você pode usar a EC2 métrica da Amazon `CPUUtilization` e basear o limite de alarme no que considera ser uma alta taxa de utilização da CPU para seu aplicativo, como 90%.
# Adicionando AWS Shield Advanced proteção aos AWS recursos
Siga as orientações nesta seção para adicionar a proteção Shield Advanced a um ou mais recursos.
**Para adicionar proteção a um AWS recurso**
1. Faça login Console de gerenciamento da AWS e abra o console AWS WAF & Shield em [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. No painel de navegação, em AWS Shield escolha **Recursos protegidos**.
1. Escolha **Adicionar recursos para proteger**.
1. Na página **Escolher recursos para proteger com o Shield Advanced**, em **Especificar a região e os tipos de recursos**, forneça as especificações de região e tipo de recurso para os recursos que você quer proteger. Você pode proteger recursos em várias regiões selecionando **Todas as regiões**, e pode restringir a seleção a recursos globais selecionando **Global**. Você pode desmarcar qualquer tipo de recurso que não queira proteger. Para saber mais sobre proteções para seus tipos de recursos, consulte [Lista de recursos que AWS Shield Advanced protegem](ddos-protections-by-resource-type.md).
1. Escolha **Carregar recursos**. O Shield Advanced preenche a seção **Selecionar recursos** com os recursos AWS que correspondem aos seus critérios.
1. Na seção **Selecionar recursos**, você pode filtrar a lista de recursos inserindo uma string para pesquisar nas listas de recursos.
Escolha os recursos que você deseja proteger.
1. Na seção **Tags**, se você quiser adicionar tags às proteções Shield Advanced que estiver criando, especifique-as. Para saber mais sobre como marcar recursos AWS , consulte [Trabalhar com o Tag Editor](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html).
1. Escolha **Proteger com o Shield Advanced**. Isso adiciona as proteções do Shield Advanced aos recursos.
# AWS Shield Advanced Proteções de edição
Você pode alterar as configurações de suas AWS Shield Advanced proteções a qualquer momento. Para fazer isso, você percorre as opções para as suas proteções selecionadas e modifica as configurações que precisar alterar.
**Para gerenciar recursos protegidos**
1. Faça login Console de gerenciamento da AWS e abra o console AWS WAF & Shield em [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. No painel AWS Shield de navegação, escolha **Recursos protegidos**.
1. Na aba **Proteções**, escolha os recursos que você deseja proteger.
1. Escolha **Configurar proteções** e a opção de especificação de recursos que você deseja.
1. Percorra cada uma das opções de proteção de recursos, fazendo as alterações necessárias.
## Configurar as proteções da camada DDo S do aplicativo
Para se proteger contra ataques aos recursos da Amazon CloudFront e do Application Load Balancer, você pode adicionar AWS WAF web ACLs e adicionar regras baseadas em taxas. Para obter mais informações sobre isso, consulte [Protegendo a camada de aplicação com AWS WAF web ACLs e Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md).
Você também pode ativar a mitigação automática da camada DDo S do aplicativo Shield Advanced. Para obter informações sobre como AWS WAF funciona, consulte[AWS WAF](waf-chapter.md). Para obter informações sobre o atributo de mitigação automática, consulte [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md).
**Importante**
Se você gerencia suas proteções Shield Advanced AWS Firewall Manager usando uma política Shield Advanced, não poderá gerenciar as proteções da camada de aplicação aqui. Para todos os outros recursos, recomendamos anexar pelo menos uma web ACL a cada recurso, mesmo que essa web ACL não contenha nenhuma regra.
**nota**
Quando você ativa a mitigação automática da camada DDo S do aplicativo para um recurso, se necessário, a operação adiciona automaticamente uma função vinculada ao serviço à sua conta para dar à Shield Advanced as permissões necessárias para gerenciar suas proteções de ACL da web. Para mais informações, consulte [Usar funções vinculadas ao serviço para o Shield Advanced](shd-using-service-linked-roles.md).
**Para configurar as proteções da camada DDo S do aplicativo**
1. Na página **Configurar proteções da camada 7 DDo S**, se o recurso ainda não estiver associado a uma ACL da web, você poderá escolher uma ACL da web existente ou criar a sua própria.
Para criar uma web ACL, siga estas etapas:
1. Escolha **Criar web ACL**.
1. Insira um nome. Você não pode alterar o nome depois de criar a web ACL.
1. Escolha **Criar**.
**nota**
Se um recurso já estiver associado a uma web ACL, você não poderá mudar para uma web ACL diferente. Se você quiser alterar a Web ACL, primeiro remova a Web associada ACLs do recurso. Para obter mais informações, consulte [Associar ou desassociar a proteção a um recurso AWS](web-acl-associating-aws-resource.md).
1. Se a web ACL não tiver uma regra baseada em intervalos definida, você poderá adicionar uma escolhendo **Adicionar regra de limite de intervalo** e, em seguida, executar as seguintes etapas:
1. Insira um nome.
1. Insira um limite de intervalo. Este é o número máximo de solicitações permitidas em um período de cinco minutos de um único endereço IP antes da ação da regra baseada em intervalos ser aplicada ao endereço IP. Quando as solicitações do endereço IP ficam abaixo do limite, a ação é interrompida.
1. Defina a ação da regra para contar ou bloquear solicitações de endereços IP enquanto suas contagens de solicitações estiverem acima do limite. A aplicação e a remoção da ação da regra podem entrar em vigor um ou dois minutos após a alteração do intervalo de solicitação do endereço IP.
1. Escolha **Adicionar regra**.
1. Para a **mitigação automática da camada DDo S do aplicativo**, escolha se você deseja que o Shield Advanced mitigue automaticamente DDo os ataques S em seu nome, da seguinte forma:
+ Para ativar a mitigação automática, escolha **Ativar** e selecione a ação de AWS WAF regra que você deseja que o Shield Advanced use em suas regras personalizadas. Suas escolhas são Count e Block. Para obter informações sobre essas ações de AWS WAF regras, consulte[Usando ações de regras em AWS WAF](waf-rule-action.md). Para obter informações sobre como o Shield Avançado gerencia essa configuração de ação, consulte [Como o Shield Avançado gerencia a configuração de ação de regra](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-rule-action).
+ Para desativar a mitigação automática, escolha **Desativar**.
+ Para deixar as configurações de mitigação automática inalteradas para os recursos que você está gerenciando, deixe marcada a opção padrão **Manter as configurações atuais**.
Para obter informações sobre a mitigação automática da camada DDo S do aplicativo Shield Advanced, consulte. [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md)
1. Escolha **Próximo**.
# Como criar alarmes e notificações para recursos protegidos pelo Shield Advanced
O procedimento a seguir mostra como gerenciar CloudWatch alarmes para recursos protegidos.
**nota**
CloudWatch incorre em custos adicionais. Para obter CloudWatch os preços, consulte [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/).
**Para criar alarmes e notificações**
1. Na página de proteções **Criar alarmes e notificações - *opcional***, configure os tópicos do SNS para os alarmes e notificações que você deseja receber. Para recursos para os quais você não deseja notificações, escolha **Sem tópico**. Você pode adicionar um tópico do Amazon SNS ou criar um novo tópico.
1. Para criar um tópico do Amazon SNS, siga estas etapas:
1. Na lista suspensa, escolha **Criar novo tópico SNS**.
1. Insira o nome do tópico.
1. Opcionalmente, insira um endereço de e-mail de destino para as mensagens do Amazon SNS e, em seguida, escolha **Adicionar e-mail**. Você pode inserir mais de um.
1. Escolha **Criar**.
1. Escolha **Próximo**.
# Removendo a AWS Shield Advanced proteção de um AWS recurso
Você pode remover a AWS Shield Advanced proteção de qualquer um dos seus AWS recursos a qualquer momento.
**Importante**
A exclusão de um AWS recurso não remove o recurso de AWS Shield Advanced. Você também deve remover a proteção do recurso de AWS Shield Advanced, conforme descrito neste procedimento.
**Remover a AWS Shield Advanced proteção de um AWS recurso**
1. Faça login Console de gerenciamento da AWS e abra o console AWS WAF & Shield em [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. No painel AWS Shield de navegação, escolha **Recursos protegidos**.
1. Na aba **Proteções**, escolha os recursos cujas proteções você deseja remover.
1. Escolha **Excluir proteções**.
1. Se você tiver um CloudWatch alarme da Amazon configurado para uma proteção, você terá a opção de excluir o alarme junto com a proteção. Se você optar por não excluir o alarme neste momento, poderá excluí-lo posteriormente usando o CloudWatch console.
**nota**
Para proteções que tenham uma verificação de integridade do Amazon Route 53 configurada, se você adicionar a proteção outra vez posteriormente, a proteção ainda incluirá a verificação de integridade.
As etapas anteriores removem a AWS Shield Advanced proteção de AWS recursos específicos. Eles não cancelam sua AWS Shield Advanced assinatura. Você continuará a ser cobrado pelo serviço. Para obter informações sobre sua AWS Shield Advanced assinatura, entre em contato com o [AWS Support Centro](https://console.aws.amazon.com/support/home#/).
## Removendo um CloudWatch alarme das proteções Shield Advanced
Para remover um CloudWatch alarme das proteções do Shield Advanced, faça o seguinte:
+ Exclua a proteção, como descrito em [Removendo a AWS Shield Advanced proteção de um AWS recurso](#remove-protection). Certifique-se de marcar a caixa de seleção ao lado de **Excluir também o DDo SDetection alarme relacionado**.
+ Exclua o alarme usando o CloudWatch console. O nome do alarme a ser excluído começa com **DDoSDetectedAlarmForProtection**.
# Agrupando suas proteções AWS Shield Advanced
Use grupos de proteção para criar coleções lógicas de seus recursos protegidos e gerenciar suas proteções como um grupo. Para saber mais sobre o gerenciamento de proteções de recurso, consulte [AWS Shield Advanced Proteções de edição](manage-protection.md).
**nota**
A mitigação automática da camada DDo S do aplicativo não interage com os grupos de proteção. Você pode ativar a mitigação automática para recursos que estão em grupos de proteção, mas o Shield Advanced não aplica automaticamente mitigações de ataques com base nas descobertas do grupo de proteção. O Shield Advanced aplica mitigações automáticas de ataques para recursos individuais.
AWS Shield Advanced os grupos de proteção oferecem uma forma de autoatendimento de personalizar o escopo de detecção e mitigação tratando vários recursos protegidos como uma única unidade. O agrupamento de recursos pode oferecer vários benefícios.
+ Melhorar a precisão da detecção.
+ Reduzir as notificações de eventos não acionáveis.
+ Aumentar a cobertura das ações de mitigação para incluir recursos protegidos que também possam ser afetados durante um evento.
+ Acelerar o tempo de mitigação de ataques com vários alvos semelhantes.
+ Facilitar a proteção automática de recursos protegidos recém-criados.
Os grupos de proteção podem ajudar a reduzir os falsos positivos em situações como blue/green troca, em que os recursos alternam entre estar quase sem carga e totalmente carregados. Outro exemplo é quando você cria e exclui recursos com frequência, mantendo um nível de carga compartilhado entre os membros do grupo. Para situações como essas, monitorar recursos individuais pode levar a falsos positivos, enquanto monitorar a saúde do grupo de recursos, não.
Você pode configurar grupos de proteção para incluir todos os recursos protegidos, todos os recursos de tipos de recursos específicos, ou recursos especificados individualmente. Os recursos recém-protegidos que atendem aos critérios do seu grupo de proteção são incluídos automaticamente no seu grupo de proteção. Um recurso protegido pode pertencer a vários grupos de proteção.
# Criação de um grupo de proteção Shield Advanced
**Para criar um grupo de proteção**
1. Faça login Console de gerenciamento da AWS e abra o console AWS WAF & Shield em [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. No painel AWS Shield de navegação, escolha **Recursos protegidos**.
1. Escolha a guia **Grupos de proteção** e, em seguida, escolha **Criar grupo de proteção**.
1. Na página **Criar grupo de proteção**, forneça um nome para o seu grupo. Você usará esse nome para identificar o grupo na sua lista de recursos protegidos. Você não pode alterar o nome de um grupo de proteção após criá-lo.
1. Em **Critérios de agrupamento de proteção**, selecione os critérios que você deseja que o Shield Advanced use para identificar os recursos protegidos que serão incluídos no grupo. Faça suas seleções adicionais com base nos critérios que você escolheu.
1. Em **Agregação**, selecione como você deseja que o Shield Advanced combine os dados de recursos do grupo para detectar, mitigar e relatar eventos.
+ **Soma**: use o tráfego total em todo o grupo. Essa é uma boa opção para a maioria dos casos. Os exemplos incluem endereços IP elásticos para EC2 instâncias da Amazon que escalam manual ou automaticamente.
+ **Média**: use a média do tráfego em todo o grupo. Essa é uma boa opção para recursos que compartilham tráfego de maneira uniforme. Os exemplos incluem aceleradores e balanceadores de carga.
+ **Máximo**: use o maior tráfego de cada recurso. Isso é útil para recursos que não compartilham tráfego e recursos que compartilham tráfego de forma não uniforme. Os exemplos incluem CloudFront distribuições da Amazon e recursos de origem para CloudFront distribuições.
1. Escolha **Salvar** para salvar seu grupo de proteção e retornar à página **Recursos protegidos**.
Na página **Eventos** do **Shield**, você pode visualizar os eventos do seu grupo de proteção e detalhar para ver informações adicionais sobre os recursos protegidos que estão no grupo.
# Atualização de um grupo de proteção Shield Advanced
**Como atualizar um grupo de proteção**
1. Faça login Console de gerenciamento da AWS e abra o console AWS WAF & Shield em [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. No painel AWS Shield de navegação, escolha **Recursos protegidos**.
1. Na guia **Grupos de proteção**, marque a caixa de seleção ao lado do grupo de proteção que você deseja modificar.
1. Na página do grupo de proteção, escolha **Editar**. Faça suas alterações nas configurações do grupo de proteção.
1. Escolha **Salvar** para salvar as alterações.
# Exclusão de um grupo de proteção Shield Advanced
**Para excluir um grupo de proteção**
1. Faça login Console de gerenciamento da AWS e abra o console AWS WAF & Shield em [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. No painel AWS Shield de navegação, escolha **Recursos protegidos**.
1. Na guia **Grupos de proteção**, marque a caixa de seleção ao lado do grupo de proteção que você deseja remover.
1. Na página do grupo de proteção, escolha **Excluir** e confirme a ação.
# A proteção avançada de recursos do Tracking Shield muda em AWS Config
Esta página explica como registrar as alterações na AWS Shield Advanced proteção de seus recursos usando AWS Config. Em seguida, você pode usar essas informações para manter um histórico de alterações de configuração para fins de solução de problemas e auditoria.
Para registrar as alterações de proteção, habilite AWS Config para cada recurso que você deseja rastrear. Para obter mais informações, consulte [Conceitos básicos do AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/getting-started.html) no *Guia do desenvolvedor do AWS Config *.
Você deve habilitar AWS Config para cada um Região da AWS que contenha os recursos rastreados. Você pode ativar AWS Config manualmente ou usar o CloudFormation modelo “Ativar AWS Config” em [Modelos de CloudFormation StackSets amostra](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-sampletemplates.html) no *Guia do CloudFormation usuário*.
Se você ativar AWS Config, você será cobrado conforme detalhado na página [AWS Config de preços](https://aws.amazon.com/config/pricing/).
**nota**
Se você já AWS Config habilitou as regiões e os recursos necessários, não precisa fazer nada. AWS Config os registros sobre alterações de proteção em seus recursos começam a ser preenchidos automaticamente.
Depois de habilitar AWS Config, use a região Leste dos EUA (Norte da Virgínia) no AWS Config console para ver o histórico de alterações de configuração dos recursos AWS Shield Advanced globais.
Veja o histórico de alterações dos recursos AWS Shield Advanced regionais por meio do AWS Config console nas regiões Leste dos EUA (Norte da Virgínia), Leste dos EUA (Ohio), Oeste dos EUA (Oregon), Oeste dos EUA (Norte da Califórnia), Europa (Irlanda), Europa (Frankfurt), Ásia-Pacífico (Tóquio) e Ásia-Pacífico (Sydney).
# Visibilidade DDo dos eventos S com o Shield Advanced
AWS Shield fornece visibilidade das seguintes categorias de eventos e atividades de eventos:
+ **Global**: todos os clientes podem acessar uma visão agregada da atividade global de ameaças nas últimas duas semanas. Você pode ver essas informações nas páginas **Getting Started** e **Global Threat Dashboard** do AWS Shield console. Para obter mais informações, consulte [Visualizando a atividade AWS Shield global e da conta](ddos-standard-event-visibility.md).
+ **Conta**: todos os clientes podem acessar um resumo dos eventos de sua conta no ano anterior. Você pode ver essas informações na página **Introdução** do AWS Shield console. Para obter mais informações, consulte [Visualizando a atividade AWS Shield global e da conta](ddos-standard-event-visibility.md).
Ao assinar o Shield Advanced e adicionar proteções aos seus recursos, você obtém acesso a informações adicionais sobre os eventos e DDo os ataques S aos recursos protegidos:
+ **Eventos em recursos protegidos** — O Shield Advanced fornece informações detalhadas para cada evento por meio da página **Eventos** do AWS Shield console. Para obter mais informações, consulte [Visualizando AWS Shield Advanced eventos](ddos-events.md).
+ **Métricas de eventos para recursos protegidos** — O Shield Advanced publica CloudWatch métricas de detecção, mitigação e principais colaboradores da Amazon para todos os recursos que protege. Você pode usar essas métricas para configurar CloudWatch painéis e alarmes. Para obter mais informações, consulte [AWS Shield Advanced métricas](shield-metrics.md).
+ **Visibilidade de eventos entre contas para recursos protegidos** — Se você usa AWS Firewall Manager para gerenciar suas proteções Shield Advanced, você pode habilitar a visibilidade das proteções em várias contas usando o Firewall Manager combinado com. AWS Security Hub CSPM Para obter mais informações, consulte [Visualizando eventos do Shield Advanced em vários Contas da AWS com AWS Firewall Manager e AWS Security Hub CSPM](ddos-viewing-multiple-accounts.md).
Se você habilitar a mitigação automática da camada DDo S do aplicativo para uma proteção da camada de aplicativo, o Shield Advanced adicionará um grupo de regras ao seu pacote de proteção (Web ACL) que ele usa para gerenciar proteções automatizadas. Esse grupo de regras gera AWS WAF métricas, mas elas não estão disponíveis para visualização. Isso é o mesmo que para qualquer outro grupo de regras que você usa em seu pacote de proteção (web ACL), mas não possui, como grupos de regras de regras AWS gerenciadas. Para obter mais informações sobre AWS WAF métricas, consulte[AWS WAF métricas e dimensões](waf-metrics.md). Para saber mais sobre essa opção de proteção do Shield Advanced, consulte [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md).
**Topics**
+ [Visualizando a atividade AWS Shield global e da conta](ddos-standard-event-visibility.md)
+ [Visualizando AWS Shield Advanced eventos](ddos-events.md)
+ [Visualizando eventos do Shield Advanced em vários Contas da AWS com AWS Firewall Manager e AWS Security Hub CSPM](ddos-viewing-multiple-accounts.md)
# Visualizando a atividade AWS Shield global e da conta
Esta página fornece instruções para acessar uma visão agregada da atividade global de ameaças e um resumo de eventos por conta nas páginas de **introdução** e **painel de controle de ameaças globais** do AWS Shield console.
A captura de tela a seguir mostra uma página de exemplo de **Conceitos básicos**.
![\[O AWS Shield console mostra a página de introdução, contendo os painéis de resumo de ameaças globais e eventos da conta.\]](http://docs.aws.amazon.com/pt_br/waf/latest/developerguide/images/shield-console-global-account.png)
**Para acessar o AWS Shield console**
+ Faça login Console de gerenciamento da AWS e abra o console AWS WAF & Shield em [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
Você não precisa de uma assinatura do Shield Advanced para acessar as informações resumidas de atividades globais e eventos da conta.
**Atividade global**
Essas informações estão disponíveis no AWS Shield console, no **painel global de ameaças** e nas páginas de **introdução**. A captura de tela a seguir mostra um exemplo do painel de atividades globais.
![\[Um painel AWS Shield do console intitulado Atividade global detectada pelo Shield mostra um mapa-múndi sobreposto por marcações de mapas de calor para áreas onde ameaças globais foram detectadas nas últimas duas semanas.\]](http://docs.aws.amazon.com/pt_br/waf/latest/developerguide/images/shield-console-global-activity.png)
A atividade global descreve DDo os eventos S observados em todos os AWS clientes. Uma vez por hora, AWS atualiza as informações das duas semanas anteriores. No painel do console, você pode ver os resultados, particionados por AWS região e exibidos em um mapa de aquecimento mundial. Ao lado do mapa, o Shield exibe informações resumidas, como o maior ataque de pacotes, a maior taxa de bits, o vetor mais comum, o número total de ataques e o nível de ameaça. O nível de ameaça é uma avaliação da atividade global atual em comparação com o que o AWS normalmente observa. O valor padrão do nível de ameaça é **Normal**. AWS atualiza automaticamente o valor para **Alto** para atividade DDo S elevada.
O **Painel global de ameaças ** também fornece métricas de séries temporais e permite que você alterne entre durações de tempo. Para ver o histórico de ataques DDo S significativos, você pode personalizar o painel para visualizações do último dia até as últimas duas semanas. As métricas de séries temporais fornecem uma visão da maior taxa de bits, taxa de pacotes ou taxa de solicitação de todos os eventos detectados AWS Shield pelos aplicativos em execução AWS durante a janela de tempo selecionada.
**Atividade da conta**
Essas informações estão disponíveis na página de **introdução** do AWS Shield console.
A captura de tela a seguir mostra um exemplo do painel de atividades da conta.
![\[Um painel de AWS Shield console intitulado Atividade da conta detectada pelo Shield lista um resumo dos eventos do ano passado, com informações como o número total de eventos e a maior taxa de pacotes e taxa de solicitações.\]](http://docs.aws.amazon.com/pt_br/waf/latest/developerguide/images/shield-console-account-activity.png)
A atividade da conta descreve eventos DDo S que o Shield detectou para seus recursos e que são elegíveis para proteção do Shield Advanced. Todos os dias, o Shield cria métricas resumidas para o ano encerrado às 00:00 UTC do dia anterior e, em seguida, exibe o total de eventos, a maior taxa de bits, a maior taxa de pacotes e a maior taxa de solicitações.
+ A métrica total de eventos reflete cada vez que o Shield observou atributos suspeitos no tráfego destinado ao seu aplicativo. Os atributos suspeitos podem incluir tráfego em volume maior do que o normal, tráfego que não corresponde ao perfil histórico do seu aplicativo, ou tráfego que não corresponde à heurística definida pelo Shield para tráfego válido do aplicativo.
+ As estatísticas da maior taxa de bits e da maior taxa de pacotes estão disponíveis para cada recurso.
+ A maior estatística de taxa de solicitação está disponível somente para CloudFront distribuições da Amazon e Application Load Balancers que têm uma Web ACL associada AWS WAF .
**nota**
Você também pode acessar o resumo do evento no nível da conta por meio da operação AWS Shield da API [DescribeAttackStatistics](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_DescribeAttack.html).
# Visualizando AWS Shield Advanced eventos
Esta página fornece instruções para acessar informações sobre eventos no Shield Advanced.
Ao assinar o Shield Advanced e proteger seus atributos, você obtém acesso a atributos adicionais de visibilidade dos atributos. Isso inclui notificação quase em tempo real de eventos detectados pelo Shield Advanced, além de informações adicionais sobre eventos e mitigações detectados.
**nota**
As informações do seu evento no console do Shield Advanced são baseadas nas métricas do Shield Advanced. Para saber mais sobre as métricas do Shield Advanced, consulte [AWS Shield Advanced métricas](shield-metrics.md)
AWS Shield avalia o tráfego para seu recurso protegido em várias dimensões. Quando uma anomalia é detectada, o Shield Advanced cria um evento separado para cada recurso afetado.
Você pode acessar os resumos e detalhes dos eventos na página **Eventos** do console Shield. A página **Eventos** do nível superior fornece uma visão geral dos eventos atuais e passados.
A captura de tela a seguir mostra uma página de **Eventos** de exemplo com um único evento em andamento. Esse evento ativo também é sinalizado no painel de navegação à esquerda.
![\[O painel de navegação esquerdo do AWS Shield console tem a seleção de Eventos destacada em vermelho, com um número 1 ao lado, dentro de um círculo vermelho. A página Eventos está aberta e mostra uma única linha na lista de eventos. A linha lista um AWS recurso do tipo CloudFront distribuição. O campo Status atual contém um ícone vermelho triangular ao lado das palavras Mitigação em andamento. O campo Status dos vetores de ataque contém o tráfego UDP. O campo Hora de início contém 16 de setembro de 2020, 14:43:00 SAST. O campo Duração contém 6 minutos.\]](http://docs.aws.amazon.com/pt_br/waf/latest/developerguide/images/shield-console-event-summary1.png)
O Shield Advanced também pode mitigar automaticamente os ataques, dependendo do tipo de tráfego e das proteções configuradas. Essas mitigações podem proteger seu recurso de receber tráfego excessivo ou tráfego que corresponda a uma assinatura de ataque DDo S conhecida.
A captura de tela a seguir mostra um exemplo de lista de **Eventos** na qual todos os eventos foram mitigados pelo Shield Advanced ou diminuíram sozinhos.
![\[Uma página AWS Shield do console intitulada Eventos lista os eventos que foram detectados recentemente e seu status atual.\]](http://docs.aws.amazon.com/pt_br/waf/latest/developerguide/images/shield-console-events.png)
**Proteja seus recursos antes de um evento**
Melhore a precisão da detecção de eventos protegendo os recursos com o Shield Advanced enquanto eles recebem o tráfego normal esperado, antes de serem sujeitos a um ataque DDo S.
Para relatar com precisão os eventos de um recurso protegido, o Shield Advanced deve primeiro estabelecer uma linha de base dos padrões de tráfego esperados para ele.
+ O Shield Advanced relata os eventos da camada de infraestrutura dos recursos quando eles tiverem sido protegidos por pelo menos 15 minutos.
+ O Shield Advanced relata os eventos da camada de aplicativos da web para os recursos quando eles tiverem sido protegidos por pelo menos 24 horas. A precisão da detecção de eventos da camada de aplicação é melhor após o Shield Advanced observar o tráfego esperado por 30 dias.
**Para acessar informações de eventos no AWS Shield console**
1. Faça login Console de gerenciamento da AWS e abra o console AWS WAF & Shield em [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. No painel AWS Shield de navegação, escolha **Eventos**. O console exibe a página **Eventos**.
1. Na página **Eventos**, você pode selecionar qualquer evento na lista para ver informações adicionais resumidas e detalhes do evento.
**Topics**
+ [Lista de campos nos resumos de AWS Shield Advanced eventos](ddos-event-summaries.md)
+ [Visualizando detalhes AWS Shield Advanced do evento](ddos-event-details.md)
# Lista de campos nos resumos de AWS Shield Advanced eventos
Esta página lista e define os campos contidos nos resumos de eventos do Shield Advanced.
Você pode ver informações resumidas e detalhadas de um evento na página do console do evento. Para abrir a página de um evento, selecione o nome do AWS recurso na lista da página **Eventos**.
A captura de tela a seguir mostra um exemplo de resumo para um evento de camada de rede.
![\[O painel de resumo da página de eventos do AWS Shield console lista as informações de um evento e inclui o AWS recurso afetado, vetores de ataque, horários de início e término e informações de mitigação e status.\]](http://docs.aws.amazon.com/pt_br/waf/latest/developerguide/images/shield-console-event-summary2.png)
As informações de resumo da página de eventos incluem o seguinte.
+ **Status atual**: valores que indicam o estado do evento e as ações que o Shield Advanced realizou no evento. Os valores de status se aplicam aos eventos da camada de infraestrutura (camada 3 ou 4) e da camada de aplicativo (camada 7).
+ **Identificado (em andamento)** e **Identificado (diminúído)**: indica que o Shield Advanced detectou um evento, mas não tomou nenhuma medida até o momento. **Identificado (diminuído)** indica que o tráfego suspeito detectado pelo Shield foi interrompido sem intervenção.
+ **Mitigação em andamento** e **Mitigado**: indica que o Shield Advanced detectou um evento e tomou medidas adequadas. **Mitigated** também é usado quando o recurso alvo é uma CloudFront distribuição da Amazon ou uma zona hospedada do Amazon Route 53, que têm suas próprias mitigações automáticas em linha.
+ Vetores de **ataque — vetores** de ataque DDo S, como inundações TCP SYN, e heurísticas de detecção do Shield Advanced, como inundação de solicitações. Esses podem ser indicadores de um ataque DDo S.
+ **Hora de início**: a data e a hora em que o primeiro ponto de dados de tráfego anômalo foi detectado.
+ **Duração ou hora de término**: o tempo decorrido entre a hora de início do evento e o último ponto de dados anômalo observado pelo Shield Advanced. Enquanto um evento estiver em andamento, esses valores continuarão aumentando.
+ **Proteção**: nomeia a proteção do Shield Advanced associada ao recurso e fornece um link para sua página de proteção. Isso está disponível na página do evento individual.
+ **Mitigação automática da camada DDo S do aplicativo** — Usada para proteções da camada de aplicação, para indicar se a mitigação automática da camada DDo S do aplicativo Shield Advanced está habilitada para o recurso. Caso esteja habilitada, isso fornecerá um link para acessar e gerenciar a configuração. Isso está disponível na página do evento individual.
+ **Mitigação automática da camada de rede**: indica se o recurso tem mitigação automática na camada de rede. Se um recurso tiver um componente de camada de rede, ele o terá ativado. Essas informações estão disponíveis na página individual do evento.
Para recursos que são frequentemente direcionados, o Shield pode manter as mitigações em vigor após a diminuição do excesso de tráfego, evitando assim novos eventos recorrentes.
**nota**
Você também pode acessar resumos de eventos para recursos protegidos por meio da operação [ListAttacks](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_ListAttacks.html)da AWS Shield API.
# Visualizando detalhes AWS Shield Advanced do evento
Você pode ver detalhes sobre a detecção, a mitigação e os principais responsáveis por um evento na seção inferior da página do console do evento. Essa seção pode incluir uma combinação de tráfego legítimo e potencialmente indesejado e pode representar tanto o tráfego passado para seu recurso protegido, quanto o tráfego bloqueado pelas mitigações do Shield.
+ **Detecção e mitigação**: isso fornece informações sobre o evento observado e quaisquer mitigações aplicadas contra ele. Para saber mais sobre mitigação de eventos, consulte [Respondendo aos eventos DDo S em AWS](ddos-responding.md).
+ **Principais responsáveis**: isso categoriza o tráfego envolvido no evento e lista as principais fontes de tráfego que o Shield identificou para cada categoria. Para eventos da camada de aplicação, use as informações dos principais contribuidores para ter uma ideia geral da natureza de um evento, mas use os AWS WAF registros para suas decisões de segurança. Para obter mais informações, consulte as seções abaixo.
As informações do seu evento no console do Shield Advanced são baseadas nas métricas do Shield Advanced. Para saber mais sobre as métricas do Shield Advanced, consulte [AWS Shield Advanced métricas](shield-metrics.md)
As métricas de mitigação não estão incluídas nos recursos da CloudFront Amazon ou do Amazon Route 53, porque esses serviços são protegidos por um sistema de mitigação que está sempre ativado e não exige mitigações para recursos individuais.
As seções de detalhes variam de acordo com o fato de as informações serem de uma camada de infraestrutura ou de um evento de camada de aplicativo.
**Topics**
+ [Como visualizar detalhes do evento da camada do aplicativo (camada 7) no Shield Advanced](ddos-event-details-application-layer.md)
+ [Como visualizar detalhes de eventos da camada de infraestrutura (camada 3 ou 4) no Shield Advanced](ddos-event-details-infrastructure-layer.md)
# Como visualizar detalhes do evento da camada do aplicativo (camada 7) no Shield Advanced
Você pode visualizar detalhes sobre a detecção, a mitigação e os principais responsáveis por um evento na camada de aplicação, na seção inferior da página do console do evento. Essa seção pode incluir uma combinação de tráfego legítimo e potencialmente indesejado e pode representar tanto o tráfego passado para seu recurso protegido, quanto o tráfego bloqueado pelas mitigações do Shield Advanced.
Os detalhes da mitigação são para todas as regras na ACL da Web associadas ao recurso, incluindo regras implantadas especificamente em resposta a um ataque e regras baseadas em intervalos definidas na ACL da Web. Se você habilitar a mitigação automática da camada DDo S do aplicativo para um aplicativo, as métricas de mitigação incluirão métricas para essas regras adicionais. Para saber mais sobre essas proteções da camada de aplicativo, consulte [Protegendo a camada de aplicação (camada 7) com AWS Shield Advanced e AWS WAF](ddos-app-layer-protections.md).
## Detecção e mitigação
Para um evento da camada de aplicação (camada 7), a guia **Detecção e mitigação** mostra métricas de detecção baseadas nas informações obtidas dos AWS WAF registros. As métricas de mitigação são baseadas em regras AWS WAF na web ACL associada que são configuradas para bloquear o tráfego indesejado.
Para CloudFront distribuições da Amazon, você pode configurar o Shield Advanced para aplicar mitigações automáticas para você. Com qualquer recurso da camada de aplicativo, você pode escolher definir suas próprias regras de mitigação em sua web ACL e solicitar ajuda do Shield Response Team (SRT). Para saber mais sobre essas opções, consulte [Respondendo aos eventos DDo S em AWS](ddos-responding.md).
A captura de tela a seguir mostra um exemplo das métricas de detecção de um evento da camada de aplicação que diminuiu após algumas horas.
![\[Um gráfico de métricas de detecção mostra a detecção do tráfego de flood de solicitações das 11:30 até ele diminuir às 16:00.\]](http://docs.aws.amazon.com/pt_br/waf/latest/developerguide/images/shield-app-detection-metrics.png)
O tráfego de eventos que diminui antes que uma regra de mitigação entre em vigor não é representado nas métricas de mitigação. Isso pode resultar em uma diferença entre o tráfego de solicitações da web mostrado nos gráficos de detecção e as métricas de permissão e bloqueio mostradas nos gráficos de mitigação.
## Principais responsáveis
A guia **Principais colaboradores dos** eventos da camada de aplicação exibe os 5 principais colaboradores que a Shield identificou para o evento, com base nos AWS WAF registros recuperados. O Shield categoriza as informações dos principais responsáveis por dimensões, como IP de origem, país de origem e URL de destino.
**nota**
Para obter as informações mais precisas sobre o tráfego que está contribuindo para um evento da camada de aplicação, use os AWS WAF registros.
Use as informações dos principais responsáveis da camada de aplicação Shield somente para ter uma ideia geral da natureza de um ataque, e não baseie suas decisões de segurança nessas informações. Para eventos da camada de aplicação, os AWS WAF registros são a melhor fonte de informações para entender os contribuintes de um ataque e para elaborar suas estratégias de mitigação.
As informações dos principais colaboradores do Shield nem sempre refletem completamente os dados nos AWS WAF registros. Ao processar os logs, o Shield prioriza a redução do impacto no desempenho do sistema em vez de recuperar o conjunto completo de dados dos logs. Isso pode resultar em uma perda de granularidade nos dados que estão disponíveis para o Shield analisar. Em grande parte dos casos, a maioria das informações está disponível, mas é possível que os dados do principal responsável sejam distorcidos em algum grau devido a algum ataque.
A captura de tela a seguir mostra um exemplo da guia **Principais responsáveis** para um evento na camada de aplicação.
![\[A guia principais responsáveis de um evento da camada de aplicação descreve os 5 principais responsáveis em várias características de solicitações da web. A tela mostra os 5 principais endereços IP de origem, os 5 principais destinos URLs, os 5 principais países de origem e os 5 principais agentes de usuário.\]](http://docs.aws.amazon.com/pt_br/waf/latest/developerguide/images/shield-app-event-top-contributors.png)
As informações do responsável são baseadas em solicitações de tráfego legítimo e potencialmente indesejado. Eventos de maior volume e eventos em que as fontes de solicitação não são altamente distribuídas têm maior probabilidade de ter os principais responsáveis identificáveis. Um ataque significativamente distribuído pode ter qualquer número de fontes, dificultando a identificação dos principais responsáveis pelo ataque. Se o Shield Advanced não identificar responsáveis significativos para uma categoria específica, ele exibirá os dados como indisponíveis.
# Como visualizar detalhes de eventos da camada de infraestrutura (camada 3 ou 4) no Shield Advanced
Na seção inferior da página do console do evento, você pode ver detalhes sobre a detecção, a mitigação e os principais responsáveis de um evento na camada de infraestrutura. Essa seção pode incluir uma combinação de tráfego legítimo e potencialmente indesejado e pode representar tanto o tráfego passado para seu recurso protegido, quanto o tráfego bloqueado pelas mitigações do Shield.
## Detecção e mitigação
Para um evento na camada de infraestrutura (camada 3 ou 4), a guia **Detecção e mitigação** mostra as métricas de detecção baseadas em amostras de fluxos de rede, além das métricas de mitigação baseadas no tráfego observado pelos sistemas de mitigação. As métricas de mitigação são uma medida mais precisa do tráfego em seu recurso.
O Shield cria automaticamente uma mitigação para os tipos de recursos protegidos Elastic IP (EIP), Classic Load Balancer (CLB), Application Load Balancer (ALB) e acelerador padrão. AWS Global Accelerator As métricas de mitigação para endereços EIP e aceleradores AWS Global Accelerator padrão indicam o número de pacotes aprovados e descartados.
A captura de tela a seguir mostra um exemplo da guia **Detecção e mitigação** para um evento na camada de infraestrutura.
![\[Os gráficos de detecção e mitigação de um evento na rede mostram o aumento do tráfego de flood de SYN e floods de pacotes nas métricas de detecção, acompanhado por um aumento nas mitigações que reduzem o tráfego alguns segundos depois, nas métricas de mitigação. Após cerca de trinta segundos de aumento das mitigações, os floods param.\]](http://docs.aws.amazon.com/pt_br/waf/latest/developerguide/images/shield-network-event-detection-mitigation.png)
O tráfego de eventos diminui antes que o Shield faça uma mitigação não está representado nas métricas de mitigação. Isso pode resultar em uma diferença entre o tráfego mostrado nos gráficos de detecção, as métricas de aprovação e descarte mostradas nos gráficos de mitigação.
## Principais responsáveis
A guia **Principais responsáveis** para eventos da camada de infraestrutura lista métricas para até 100 principais responsáveis em várias dimensões de tráfego. Os detalhes incluem propriedades da camada de rede para qualquer dimensão em que pelo menos cinco fontes significativas de tráfego possam ser identificadas. Exemplos de fontes de tráfego são IP de origem e ASN de origem.
A captura de tela a seguir mostra um exemplo da guia **Principais responsáveis** para um evento na camada de infraestrutura.
![\[A guia de principais responsáveis de um evento de rede mostra as categorias de tráfego que mais contribuíram para o evento. Nesse caso, as categorias incluem volume por protocolo, volume por protocolo e porta de destino, volume por protocolo e ASN de origem, e volume por sinalizadores TCP.\]](http://docs.aws.amazon.com/pt_br/waf/latest/developerguide/images/shield-network-event-top-contributors.png)
As métricas do responsável são baseadas em amostras de fluxos de rede para tráfego legítimo e potencialmente indesejado. Eventos de maior volume e eventos em que as fontes de tráfego não são altamente distribuídas têm maior probabilidade de ter os principais responsáveis identificáveis. Um ataque significativamente distribuído pode ter qualquer número de fontes, dificultando a identificação dos principais responsáveis pelo ataque. Se o Shield não identificar nenhum responsável significativo para uma métrica ou categoria específica, ele exibirá os dados como indisponíveis.
Em um ataque da camada DDo S da infraestrutura, as fontes de tráfego podem ser falsificadas ou refletidas. Uma fonte falsificada é intencionalmente forjada pelo atacante. Uma fonte refletida é a fonte real do tráfego detectado, mas não se trata de um participante voluntário do ataque. Por exemplo, um invasor pode gerar um grande e amplificado flood de tráfego para um alvo ao refletir o ataque a serviços na Internet que normalmente são legítimos. Nesse caso, as informações da fonte podem ser válidas, embora não sejam a fonte real do ataque. Esses fatores podem limitar a viabilidade das técnicas de mitigação que bloqueiam as fontes com base nos cabeçalhos dos pacotes.
# Visualizando eventos do Shield Advanced em vários Contas da AWS com AWS Firewall Manager e AWS Security Hub CSPM
Você pode usar AWS Firewall Manager e AWS Security Hub CSPM gerenciar e monitorar recursos AWS Shield Advanced protegidos em várias contas.
Com o Firewall Manager, você pode criar uma política de segurança Shield Advanced que reporta e impõe a conformidade da proteção DDo S em todas as suas contas. O Firewall Manager monitora seus recursos protegidos, incluindo a adição de proteções a novos recursos que entram no escopo da política do Shield Advanced.
Você pode integrar o Firewall Manager AWS Security Hub CSPM para obter um único painel que relata eventos DDo S detectados pelas descobertas de conformidade do Shield Advanced e do Firewall Manager, quando o Firewall Manager identifica um recurso que está fora de conformidade com sua política de segurança Shield Advanced.
A figura a seguir mostra uma arquitetura típica para monitorar os recursos protegidos do Shield Advanced com o Firewall Manager e o Security Hub CSPM.
![\[Na parte superior da figura há um AWS Organizations ícone. Ele tem uma seta apontando para baixo que se divide para apontar para dois ícones que estão lado a lado. O ícone esquerdo tem o título Production OU e o ícone direito tem o título Security OU. Abaixo desses ícones estão três ícones, intitulados da esquerda para a direita: AWS Shield Advanced AWS Firewall Manager, AWS Security Hub CSPM e. O ícone da UO de produção tem uma seta apontando para baixo até o ícone Shield Advanced. O ícone da OU de segurança tem uma seta apontando para baixo que se divide para apontar para os ícones CSPM do Firewall Manager e do Security Hub. O ícone Shield Advanced tem uma seta apontando para baixo para um retângulo com o título Shield Advanced protected resources. Dentro do retângulo estão ícones para Application Load Balancer CloudFront, distribuição e endereço IP elástico. O ícone do Firewall Manager também tem uma seta apontando para baixo para o retângulo Shield Advanced protected resources e está rotulado como Enforces compliance of protected resources. O ícone Shield Advanced tem uma seta horizontal apontando para o ícone do Firewall Manager que está rotulado como DDoS alarm. O ícone do Firewall Manager tem uma seta horizontal apontando para a direita, para o ícone CSPM do Security Hub rotulado. DDoS alarm and compliance findings\]](http://docs.aws.amazon.com/pt_br/waf/latest/developerguide/images/shield-arch-fms-ash-integration.png)
Ao integrar o Firewall Manager com o Security Hub CSPM, você pode visualizar as descobertas de segurança em um único local, junto com outros alertas e informações de status de conformidade dos aplicativos em que você executa. AWS
A captura de tela a seguir destaca as informações que você pode ver sobre um evento Shield Advanced dentro do console CSPM do Security Hub quando você tem uma integração desse tipo.
![\[A captura de tela mostra a página Descobertas do console CSPM do Security Hub, com o subtítulo Uma descoberta é um problema de segurança ou uma falha na verificação de segurança. . A seção tem contornos vermelhos destacando as strings: título EQUALS Shield Advanced detectou ataque contra recurso monitorado e Nome do produto EQUAL Firewall Manager. A tela mostra um conjunto de detalhes sobre o ataque específico e seu status.\]](http://docs.aws.amazon.com/pt_br/waf/latest/developerguide/images/shield-console-security-hub-event.png)
Para saber como integrar o Firewall Manager e o Security Hub CSPM com o Shield Advanced para centralizar o monitoramento de eventos e conformidade em suas contas protegidas, consulte o blog de AWS segurança [Configure o monitoramento centralizado para eventos DDo S e corrija](https://aws.amazon.com/blogs/security/set-up-centralized-monitoring-for-ddos-events-and-auto-remediate-noncompliant-resources/) automaticamente recursos não compatíveis.
# Respondendo aos eventos DDo S em AWS
Esta página explica como AWS responde aos ataques DDo S e fornece opções de como você pode responder ainda mais.
AWS mitiga automaticamente os ataques da rede e da camada de transporte (camada 3 e camada 4) DDo S. Se você usa o Shield Advanced para proteger suas EC2 instâncias da Amazon, durante um ataque, o Shield Advanced implanta automaticamente sua ACLs rede Amazon VPC na fronteira da AWS rede. Isso permite que o Shield Advanced forneça proteção contra eventos DDo S maiores. Para obter mais informações sobre rede ACLs, consulte [Rede ACLs](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html).
Para ataques na camada de aplicação (camada 7) DDo S, AWS tentativas de detectar e notificar AWS Shield Advanced os clientes por meio de CloudWatch alarmes. Por padrão, ele não aplica mitigações automaticamente para evitar o bloqueio inadvertido do tráfego válido de usuários.
Para recursos da camada de aplicação (camada 7), você tem as seguintes opções disponíveis para responder a um ataque.
+ **Fornecer suas próprias mitigações**: você pode investigar e mitigar o ataque sozinho. Para mais informações, consulte [Mitigação manual de um ataque na camada DDo S do aplicativo](ddos-responding-manual.md).
+ **Entrar em contato com o suporte**: se você é cliente do Shield Advanced, pode entrar em contato com o [Centro AWS Support](https://console.aws.amazon.com/support/home#/) para obter ajuda com as mitigações. Casos críticos e urgentes são encaminhados diretamente aos especialistas DDo S. Para mais informações, consulte [Entrar em contato com o centro de suporte durante um ataque à camada DDo S do aplicativo](ddos-responding-contact-support.md).
Além disso, antes que um ataque ocorra, você pode ativar proativamente as seguintes opções de mitigação:
+ **Mitigações automáticas nas CloudFront distribuições da Amazon** — Com essa opção, o Shield Advanced define e gerencia regras de mitigação para você em sua ACL web. Para saber mais sobre a mitigação automática da camada de aplicação, consulte [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md).
+ **Engajamento proativo** — Quando AWS Shield Advanced detecta um grande ataque na camada de aplicativos contra um de seus aplicativos, o SRT pode entrar em contato com você de forma proativa. O SRT faz a triagem do evento DDo S e cria AWS WAF mitigações. O SRT entra em contato com você e, com seu consentimento, pode aplicar as regras AWS WAF . Para obter mais informações sobre essa opção, consulte [Como configurar um engajamento proativo para que o SRT entre em contato diretamente com você](ddos-srt-proactive-engagement.md).
# Entrar em contato com o centro de suporte durante um ataque à camada DDo S do aplicativo
Esta página fornece instruções para entrar em contato com o centro de suporte durante um ataque na camada de aplicação DDo S.
Se você for um AWS Shield Advanced cliente, entre em contato com o [AWS Support Centro](https://console.aws.amazon.com/support/home#/) para obter ajuda com as mitigações. Casos críticos e urgentes são encaminhados diretamente aos especialistas em DDo S. Com isso AWS Shield Advanced, casos complexos podem ser encaminhados para a AWS Shield Response Team (SRT), que tem profunda experiência em proteger AWS a Amazon.com e suas subsidiárias. Para obter mais informações sobre o SRT, consulte [Resposta gerenciada a eventos DDo S com suporte do Shield Response Team (SRT)](ddos-srt-support.md).
Para obter suporte do Shield Response Team (SRT), entre em contato com a [Central AWS Support](https://console.aws.amazon.com/support/home#/). O tempo de resposta para seu caso dependerá da gravidade selecionada e dos tempos de resposta, que são documentados na página [Plano de suporte da AWS Support](https://aws.amazon.com/premiumsupport/compare-plans/).
Selecione as seguintes opções:
+ Tipo de caso: suporte técnico
+ Serviço: Negação de serviço distribuída (DDoS)
+ Categoria: Entrada para AWS
+ Gravidade: *escolha uma opção apropriada*
Ao conversar com nosso representante, explique que você é um AWS Shield Advanced cliente que está enfrentando um possível ataque DDo S. Nosso representante direcionará sua ligação para os especialistas DDo S apropriados. Se você abrir um caso no [AWS Support Centro](https://console.aws.amazon.com/support/home#/) usando o tipo de serviço **Distribuído de Negação de Serviço (DDoS)**, poderá falar diretamente com um especialista em DDo S por chat ou telefone. DDoOs engenheiros de suporte S podem ajudá-lo a identificar ataques, recomendar melhorias em sua AWS arquitetura e fornecer orientação sobre o uso de AWS serviços para mitigação de ataques DDo S.
Para ataques na camada de aplicação, o SRT pode ajudá-lo a analisar a atividade suspeita. Se você tiver a mitigação automática ativada para seu recurso, o SRT poderá analisar as mitigações que o Shield Advanced está aplicando automaticamente contra o ataque. Em qualquer caso, o SRT pode ajudá-lo a analisar e mitigar o problema. As mitigações recomendadas pelo SRT geralmente exigem que o SRT crie ou atualize listas de controle de acesso à AWS WAF web (web ACLs) em sua conta. O SRT precisará de sua permissão para fazer esse trabalho.
**Importante**
Recomendamos que, como parte da habilitação AWS Shield Advanced, você siga as etapas [Como conceder acesso ao SRT](ddos-srt-access.md) para fornecer proativamente ao SRT as permissões necessárias para ajudá-lo durante um ataque. Fornecer a permissão antecipadamente ajuda a evitar atrasos no caso de um ataque real.
O SRT ajuda você a fazer a triagem do ataque DDo S para identificar assinaturas e padrões de ataque. Com seu consentimento, o SRT cria e implanta AWS WAF regras para mitigar o ataque.
Você também pode entrar em contato com o SRT antes ou durante um possível ataque para desenvolver e implantar mitigações personalizadas. Por exemplo, se você estiver executando um aplicativo web e precisar apenas das portas 80 e 443 abertas, você pode trabalhar com o SRT para pré-configurar uma web ACL para “permitir” apenas as portas 80 e 443.
Você autoriza e entra em contato com o SRT no nível de conta. Ou seja, se você usar o Shield Advanced em uma política do Firewall Manager Shield Advanced, o proprietário da conta, e não o administrador do Firewall Manager, deverá entrar em contato com o SRT para obter suporte. O administrador do Firewall Manager poderá autorizar o SRT apenas para contas pertencentes a ele.
# Mitigação manual de um ataque na camada DDo S do aplicativo
Esta página fornece instruções para mitigar manualmente um ataque na camada DDo S do aplicativo.
Se você determinar que a atividade na página de eventos do seu recurso representa um ataque DDo S, você pode criar suas próprias AWS WAF regras em sua ACL da web para mitigar o ataque. Essa é a única opção disponível se você não for cliente do Shield Advanced. AWS WAF está incluído sem AWS Shield Advanced custo adicional. Para saber mais sobre como criar regras na sua web ACL, consulte [Configurando a proteção em AWS WAF](web-acl.md).
Se você usa AWS Firewall Manager, você pode adicionar suas AWS WAF regras a uma AWS WAF política do Firewall Manager.
**Para mitigar manualmente um possível ataque à camada DDo S do aplicativo**
1. Crie declarações de regras em sua web ACL com critérios que correspondam ao comportamento incomum. Para começar, configure-os para contar as solicitações correspondentes. Para saber mais sobre como configurar sua web ACL e declarações de regras, consulte [Usando pacotes de proteção (web ACLs) com regras e grupos de regras no AWS WAF](web-acl-processing.md) e [Testando e ajustando suas AWS WAF proteções](web-acl-testing.md).
**nota**
Sempre teste suas regras primeiro usando inicialmente a ação de regra Count em vez de Block. Assim que estiver certo de que suas novas regras estão identificando as solicitações corretas, você poderá modificá-las para bloquear essas solicitações.
1. Monitore as contagens de solicitações para determinar se você deseja bloquear as solicitações correspondentes. Se o volume de solicitações continuar incomumente alto e você tiver certeza de que suas regras estão capturando as solicitações que estão causando o alto volume, altere as regras em sua web ACL para bloquear as solicitações.
1. Continue monitorando a página de eventos para garantir que seu tráfego seja tratado como você deseja.
AWS fornece modelos pré-configurados para você começar rapidamente. Os modelos incluem um conjunto de AWS WAF regras que você pode personalizar e usar para bloquear ataques comuns baseados na web. Para obter mais informações, consulte [Automações de segurança do AWS WAF](https://aws.amazon.com/solutions/aws-waf-security-automations/).
# Solicitando um crédito AWS Shield Advanced após um ataque
Se você está inscrito AWS Shield Advanced e enfrenta um ataque DDo S que aumenta a utilização de um recurso protegido do Shield Advanced, você pode solicitar um crédito de serviço do Shield Advanced para cobranças relacionadas ao aumento da utilização, na medida em que não seja mitigado pelo Shield Advanced.
**nota**
Você pode aplicar quaisquer créditos recebidos por meio desse processo somente ao uso do Shield Advanced. Os créditos do Shield Advanced não estão disponíveis para uso com outros serviços.
Os créditos estão disponíveis somente para os seguintes tipos de cobranças:
+ Transferência de dados do Shield Advanced
+ Solicitações CloudFront HTTP/HTTPS da Amazon
+ CloudFront transferência de dados para fora
+ Consultas do Amazon Route 53
+ AWS Global Accelerator transferência de dados do acelerador padrão
+ Unidades de capacidade do balanceador de carga para Application Load Balancer
+ Custos de instância para instâncias protegidas do Amazon Elastic Compute Cloud (Amazon EC2) que foram criadas por uma política de auto-scaling em resposta ao ataque
**Pré-requisitos para solicitar um crédito**
Para estar elegível para o crédito, antes do início do ataque, você deve ter feito o seguinte:
+ É preciso ter adicionado a proteção Shield Advanced aos recursos para os quais deseja solicitar um crédito. Os recursos protegidos adicionados durante um ataque não são elegíveis para proteção de custos.
**nota**
Ativar o Shield Advanced no seu Conta da AWS não ativa automaticamente a proteção Shield Advanced para recursos individuais.
Para obter mais informações sobre como proteger AWS recursos usando o Shield Advanced, consulte[Adicionando AWS Shield Advanced proteção aos AWS recursos](configure-new-protection.md).
+ Para recursos aplicáveis CloudFront e protegidos pelo Application Load Balancer, você deve ter associado uma ACL AWS WAF da web e implementado uma regra baseada em taxa na ACL da web no modo. Block Para saber mais sobre regras baseadas em intervalos no AWS WAF , consulte [Usando declarações de regras baseadas em taxas em AWS WAF](waf-rule-statement-type-rate-based.md). Para obter informações sobre como associar a web ACLs aos AWS recursos, consulte[Configurando a proteção em AWS WAF](web-acl.md).
+ Você deve ter implementado as melhores práticas apropriadas em [AWS Best DDo Practices for S Resiliency](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency) para configurar seu aplicativo de forma a minimizar os custos durante um ataque DDo S.
**Como solicitar um crédito**
Para se qualificar para um crédito, você deve enviar sua solicitação de crédito dentro do período de 15 dias imediatamente após o mês de cobrança no qual o ataque ocorreu.
Para solicitar um crédito, envie um caso de cobrança pela [Central AWS Support](https://console.aws.amazon.com/support/home#/). Na sua solicitação, inclua:
+ As palavras "DDoS Concessão” na linha de assunto
+ As datas e horários de cada evento ou interrupção de disponibilidade para a qual você está solicitando um crédito
+ Os AWS serviços e recursos específicos que foram afetados
Depois de enviar uma solicitação, a AWS Shield Response Team (SRT) validará se um ataque DDo S ocorreu e, em caso afirmativo, se algum recurso protegido foi escalado para absorver o DDo ataque S. Se AWS determinar que os recursos protegidos foram escalados para absorver o ataque DDo S, AWS emitirá um crédito pela parte do tráfego que AWS determina que foi causada pelo ataque DDo S. Os créditos são válidos por 12 meses.
# Segurança no uso do AWS Shield serviço
Esta seção explica como o modelo de responsabilidade compartilhada se aplica AWS Shield a.
A segurança na nuvem AWS é a maior prioridade. Como AWS cliente, você se beneficia de uma arquitetura de data center e rede criada para atender aos requisitos das organizações mais sensíveis à segurança.
**nota**
Esta seção fornece diretrizes AWS de segurança padrão para o uso do AWS Shield serviço e de seus AWS recursos, como as proteções Shield Advanced.
Para obter informações sobre como proteger seus AWS recursos usando o Shield e o Shield Advanced, consulte o restante do AWS Shield guia.
A segurança é uma responsabilidade compartilhada entre você AWS e você. O [modelo de responsabilidade compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/) descreve isto como segurança *da* nuvem e segurança *na* nuvem.
+ **Segurança da nuvem** — AWS é responsável por proteger a infraestrutura que executa AWS os serviços no Nuvem AWS. AWS também fornece serviços que você pode usar com segurança. A eficácia da nossa segurança é regularmente testada e verificada por auditores de terceiros como parte dos [Programas de conformidade da AWS](https://aws.amazon.com/compliance/programs/). Para saber mais sobre os programas de conformidade que se aplicam ao Shield, consulte [Serviços da AWS no escopo pelo programa de conformidade](https://aws.amazon.com/compliance/services-in-scope/).
+ **Segurança na nuvem** — Sua responsabilidade é determinada pelo AWS serviço que você usa. Também existe a responsabilidade por outros fatores, incluindo a confidencialidade de dados, os requisitos da organização e as leis e regulamentos aplicáveis.
Esta documentação ajuda a entender como aplicar o modelo de responsabilidade compartilhada ao usar o Shield. Os tópicos a seguir mostram como configurar o Shield para atender aos seus objetivos de segurança e conformidade. Você também aprende a usar outros AWS serviços que ajudam a monitorar e proteger seus recursos do Shield.
**Topics**
+ [Como proteger seus dados no Shield](shd-data-protection.md)
+ [Usando o IAM com AWS Shield](shd-security-iam.md)
+ [Como registrar em log e monitorar no Shield](shd-incident-response.md)
+ [Como validar a conformidade no Shield](shd-security-compliance.md)
+ [Como desenvolver resiliência no Shield](shd-disaster-recovery-resiliency.md)
+ [Segurança da infraestrutura em AWS Shield](shd-infrastructure-security.md)
# Como proteger seus dados no Shield
Esta seção explica como o modelo de responsabilidade AWS compartilhada se aplica à proteção de dados no Shield.
O modelo de [responsabilidade AWS compartilhada modelo](https://aws.amazon.com/compliance/shared-responsibility-model/) se aplica à proteção de dados em AWS Shield. Conforme descrito neste modelo, AWS é responsável por proteger a infraestrutura global que executa todos os Nuvem AWS. Você é responsável por manter o controle sobre o conteúdo hospedado nessa infraestrutura. Você também é responsável pelas tarefas de configuração e gerenciamento de segurança dos Serviços da AWS que usa. Para saber mais sobre a privacidade de dados, consulte as [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). Para saber mais sobre a proteção de dados na Europa, consulte a postagem do blog [AWS Shared Responsibility Model and RGPD](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) no *Blog de segurança da AWS *.
Para fins de proteção de dados, recomendamos que você proteja Conta da AWS as credenciais e configure usuários individuais com Centro de Identidade do AWS IAM ou AWS Identity and Access Management (IAM). Dessa maneira, cada usuário receberá apenas as permissões necessárias para cumprir suas obrigações de trabalho. Recomendamos também que você proteja seus dados das seguintes formas:
+ Use uma autenticação multifator (MFA) com cada conta.
+ Use SSL/TLS para se comunicar com AWS os recursos. Exigimos TLS 1.2 e recomendamos TLS 1.3.
+ Configure a API e o registro de atividades do usuário com AWS CloudTrail. Para obter informações sobre o uso de CloudTrail trilhas para capturar AWS atividades, consulte Como [trabalhar com CloudTrail trilhas](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) no *Guia AWS CloudTrail do usuário*.
+ Use soluções de AWS criptografia, juntamente com todos os controles de segurança padrão Serviços da AWS.
+ Use serviços gerenciados de segurança avançada, como o Amazon Macie, que ajuda a localizar e proteger dados sensíveis armazenados no Amazon S3.
+ Se você precisar de módulos criptográficos validados pelo FIPS 140-3 ao acessar AWS por meio de uma interface de linha de comando ou de uma API, use um endpoint FIPS. Para saber mais sobre os endpoints FIPS disponíveis, consulte [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
É altamente recomendável que nunca sejam colocadas informações confidenciais ou sensíveis, como endereços de e-mail de clientes, em tags ou campos de formato livre, como um campo **Nome**. Isso inclui quando você trabalha com o Shield ou outro Serviços da AWS usando o console AWS CLI, a API ou AWS SDKs. Quaisquer dados inseridos em tags ou em campos de texto de formato livre usados para nomes podem ser usados para logs de faturamento ou de diagnóstico. Se você fornecer um URL para um servidor externo, é fortemente recomendável que não sejam incluídas informações de credenciais no URL para validar a solicitação nesse servidor.
As entidades do Shield, como proteções, são criptografadas em repouso, exceto em determinadas regiões onde a criptografia não está disponível, incluindo China (Pequim) e China (Ningxia). Chaves de criptografia exclusivas são usadas para cada região.
# Usando o IAM com AWS Shield
Esta seção explica como usar o IAM com AWS Shield.
AWS Identity and Access Management (IAM) é uma ferramenta AWS service (Serviço da AWS) que ajuda o administrador a controlar com segurança o acesso aos AWS recursos. Os administradores do IAM controlam quem pode ser *autenticado* (fazer login) e *autorizado* (ter permissões) para usar recursos do Shield. O IAM é um AWS service (Serviço da AWS) que você pode usar sem custo adicional.
**Topics**
+ [Público](#security_iam_audience)
+ [Autenticação com identidades](#security_iam_authentication)
+ [Gerenciar o acesso usando políticas](#security_iam_access-manage)
+ [Como AWS Shield funciona com o IAM](shd-security_iam_service-with-iam.md)
+ [Exemplos de políticas baseadas em identidade para AWS Shield](shd-security_iam_id-based-policy-examples.md)
+ [AWS políticas gerenciadas para AWS Shield](shd-security-iam-awsmanpol.md)
+ [Solução de problemas AWS Shield de identidade e acesso](shd-security_iam_troubleshoot.md)
+ [Usar funções vinculadas ao serviço para o Shield Advanced](shd-using-service-linked-roles.md)
## Público
A forma como você usa AWS Identity and Access Management (IAM) difere, dependendo do trabalho que você faz no Shield.
**Usuário do serviço**: se você usa o serviço Shield para fazer o trabalho, seu administrador fornece as credenciais e as permissões necessárias. À medida que usar mais atributos do Shield para fazer seu trabalho, você poderá precisar de permissões adicionais. Entender como o acesso é gerenciado pode ajudar a solicitar as permissões corretas ao administrador. Se não for possível acessar um atributo no Shield, consulte [Solução de problemas AWS Shield de identidade e acesso](shd-security_iam_troubleshoot.md).
**Administrador do serviço**: se você for o responsável pelos recursos do Shield na empresa, provavelmente terá acesso total ao Shield. Cabe a você determinar quais funcionalidades e atributos do Shield os usuários do serviço devem acessar. Envie as solicitações ao administrador do IAM para alterar as permissões dos usuários de serviço. Revise as informações nesta página para compreender os conceitos básicos do IAM. Para saber mais sobre como a empresa pode usar o IAM com o Shield, consulte [Como AWS Shield funciona com o IAM](shd-security_iam_service-with-iam.md).
**Administrador do IAM**: se você for um administrador do IAM, talvez queira saber detalhes sobre como é possível criar políticas para gerenciar o acesso ao Shield. Para visualizar exemplos de políticas baseadas em identidade do Shield que podem ser usadas no IAM, consulte [Exemplos de políticas baseadas em identidade para AWS Shield](shd-security_iam_id-based-policy-examples.md).
## Autenticação com identidades
A autenticação é a forma como você faz login AWS usando suas credenciais de identidade. Você deve estar autenticado como usuário do IAM ou assumindo uma função do IAM. Usuário raiz da conta da AWS
Você pode fazer login como uma identidade federada usando credenciais de uma fonte de identidade como Centro de Identidade do AWS IAM (IAM Identity Center), autenticação de login único ou credenciais. Google/Facebook Para ter mais informações sobre como fazer login, consulte [Como fazer login em sua Conta da AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) no *Guia do usuário do Início de Sessão da AWS *.
Para acesso programático, AWS fornece um SDK e uma CLI para assinar solicitações criptograficamente. Para ter mais informações, consulte [AWS Signature Version 4 para solicitações de API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) no *Guia do usuário do IAM*.
### Conta da AWS usuário root
Ao criar um Conta da AWS, você começa com uma identidade de login chamada *usuário Conta da AWS raiz* que tem acesso completo a todos Serviços da AWS os recursos. É altamente recomendável não usar o usuário-raiz em tarefas diárias. Consulte as tarefas que exigem credenciais de usuário-raiz em [Tarefas que exigem credenciais de usuário-raiz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) no *Guia do usuário do IAM*.
### Identidade federada
Como prática recomendada, exija que os usuários humanos usem a federação com um provedor de identidade para acessar Serviços da AWS usando credenciais temporárias.
Uma *identidade federada* é um usuário do seu diretório corporativo, provedor de identidade da web ou Directory Service que acessa Serviços da AWS usando credenciais de uma fonte de identidade. As identidades federadas assumem funções que oferecem credenciais temporárias.
Para o gerenciamento de acesso centralizado, recomendamos Centro de Identidade do AWS IAM. Para saber mais, consulte [O que é o IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) no *Guia do usuário do Centro de Identidade do AWS IAM *.
### Usuários e grupos do IAM
Um *[usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* é uma identidade com permissões específicas para uma única pessoa ou aplicação. É recomendável usar credenciais temporárias, em vez de usuários do IAM com credenciais de longo prazo. Para obter mais informações, consulte [Exigir que usuários humanos usem a federação com um provedor de identidade para acessar AWS usando credenciais temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) no *Guia do usuário do IAM*.
Um [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) especifica um conjunto de usuários do IAM e facilita o gerenciamento de permissões para grandes conjuntos de usuários. Para ter mais informações, consulte [Casos de uso de usuários do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) no *Guia do usuário do IAM*.
### Perfis do IAM
Uma *[perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* é uma identidade com permissões específicas que oferece credenciais temporárias. Você pode assumir uma função [mudando de um usuário para uma função do IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ou chamando uma operação de AWS API AWS CLI ou. Para saber mais, consulte [Métodos para assumir um perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) no *Manual do usuário do IAM*.
Os perfis do IAM são úteis para acesso de usuário federado, permissões de usuário do IAM temporárias, acesso entre contas, acesso entre serviços e aplicações em execução no Amazon EC2. Consulte mais informações em [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*.
## Gerenciar o acesso usando políticas
Você controla o acesso AWS criando políticas e anexando-as a AWS identidades ou recursos. Uma política define permissões quando associada a uma identidade ou recurso. AWS avalia essas políticas quando um diretor faz uma solicitação. A maioria das políticas é armazenada AWS como documentos JSON. Para ter mais informações sobre documentos de política JSON, consulte [Visão geral das políticas JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) no *Guia do usuário do IAM*.
Por meio de políticas, os administradores especificam quem tem acesso a que, definindo qual **entidade principal** pode realizar **ações** em quais **recursos** e sob quais **condições**.
Por padrão, usuários e perfis não têm permissões. Um administrador do IAM cria políticas do IAM e as adiciona aos perfis, os quais os usuários podem então assumir. As políticas do IAM definem permissões, independentemente do método usado para realizar a operação.
### Políticas baseadas em identidade
As políticas baseadas em identidade são documentos de políticas de permissão JSON que você anexa a uma identidade (usuário, grupo ou perfil). Essas políticas controlam quais ações as identidades podem realizar, em quais recursos e sob quais condições. Para saber como criar uma política baseada em identidade, consulte [Definir permissões personalizadas do IAM com as políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do Usuário do IAM*.
As políticas baseadas em identidade podem ser políticas *em linha* (incorporadas diretamente em uma única identidade) ou *políticas gerenciadas* (políticas autônomas anexadas a várias identidades). Para saber como escolher entre uma política gerenciada e políticas em linha, consulte [Escolher entre políticas gerenciadas e políticas em linha](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) no *Guia do usuário do IAM*.
### Políticas baseadas em recursos
Políticas baseadas em recursos são documentos de políticas JSON que você anexa a um recurso. Entre os exemplos estão *políticas de confiança de perfil* do IAM e *políticas de bucket* do Amazon S3. Em serviços compatíveis com políticas baseadas em recursos, os administradores de serviço podem usá-las para controlar o acesso a um recurso específico. É necessário [especificar uma entidade principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) em uma política baseada em recursos.
Políticas baseadas em recursos são políticas em linha localizadas nesse serviço. Você não pode usar políticas AWS gerenciadas do IAM em uma política baseada em recursos.
### Listas de controle de acesso (ACLs)
As listas de controle de acesso (ACLs) controlam quais diretores (membros da conta, usuários ou funções) têm permissões para acessar um recurso. ACLs são semelhantes às políticas baseadas em recursos, embora não usem o formato de documento de política JSON.
O Amazon S3 e o AWS WAF Amazon VPC são exemplos de serviços que oferecem suporte. ACLs Para saber mais ACLs, consulte a [visão geral da lista de controle de acesso (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) no *Guia do desenvolvedor do Amazon Simple Storage Service*.
### Outros tipos de política
AWS oferece suporte a tipos de políticas adicionais que podem definir o máximo de permissões concedidas por tipos de políticas mais comuns:
+ **Limites de permissões**: definem o número máximo de permissões que uma política baseada em identidade pode conceder a uma entidade do IAM. Para saber mais sobre limites de permissões, consulte [Limites de permissões para identidades do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) no *Guia do usuário do IAM*.
+ **Políticas de controle de serviço (SCPs)** — Especifique as permissões máximas para uma organização ou unidade organizacional em AWS Organizations. Para saber mais, consulte [Políticas de controle de serviço](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) no *Guia do usuário do AWS Organizations *.
+ **Políticas de controle de recursos (RCPs)** — Defina o máximo de permissões disponíveis para recursos em suas contas. Para obter mais informações, consulte [Políticas de controle de recursos (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) no *Guia AWS Organizations do usuário*.
+ **Políticas de sessão**: políticas avançadas transmitidas como um parâmetro durante a criação de uma sessão temporária para um perfil ou um usuário federado. Para saber mais, consulte [Políticas de sessão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) no *Guia do usuário do IAM*.
### Vários tipos de política
Quando vários tipos de política são aplicáveis a uma solicitação, é mais complicado compreender as permissões resultantes. Para saber como AWS determinar se uma solicitação deve ser permitida quando vários tipos de políticas estão envolvidos, consulte [Lógica de avaliação de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) no *Guia do usuário do IAM*.
# Como AWS Shield funciona com o IAM
Esta seção explica como usar os recursos do IAM com AWS Shield.
Antes de usar o IAM para gerenciar o acesso ao Shield, saiba quais atributos do IAM estão disponíveis para uso com o Shield.
**Recursos do IAM que você pode usar com AWS Shield**
| Recurso do IAM | Suporte Shield |
| --- | --- |
| [Políticas baseadas em identidade](#shd-security_iam_service-with-iam-id-based-policies) | Sim |
| [Políticas baseadas em recurso](#shd-security_iam_service-with-iam-resource-based-policies) | Não |
| [Ações de políticas](#shd-security_iam_service-with-iam-id-based-policies-actions) | Sim |
| [Recursos de políticas](#shd-security_iam_service-with-iam-id-based-policies-resources) | Sim |
| [Chaves de condição de política (específicas do serviço)](#shd-security_iam_service-with-iam-id-based-policies-conditionkeys) | Sim |
| [ACLs](#shd-security_iam_service-with-iam-acls) | Não |
| [ABAC (tags em políticas)](#shd-security_iam_service-with-iam-tags) | Parcial |
| [Credenciais temporárias](#shd-security_iam_service-with-iam-roles-tempcreds) | Sim |
| [Sessões de acesso direto (FAS)](#shd-security_iam_service-with-iam-principal-permissions) | Sim |
| [Perfis de serviço](#shd-security_iam_service-with-iam-roles-service) | Sim |
| [Perfis vinculados a serviço](#shd-security_iam_service-with-iam-roles-service-linked) | Sim |
Para ter uma visão de alto nível de como o Shield e outros AWS serviços funcionam com a maioria dos recursos do IAM, consulte [AWS os serviços que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) no *Guia do usuário do IAM*.
## Políticas baseadas em identidade para o Shield
Esta seção fornece exemplos de políticas baseadas em identidade para. AWS Shield
**Compatível com políticas baseadas em identidade:** sim
As políticas baseadas em identidade são documentos de políticas de permissões JSON que podem ser anexados a uma identidade, como usuário do IAM, grupo de usuários ou perfil. Essas políticas controlam quais ações os usuários e perfis podem realizar, em quais recursos e em que condições. Para saber como criar uma política baseada em identidade, consulte [Definir permissões personalizadas do IAM com as políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do Usuário do IAM*.
Com as políticas baseadas em identidade do IAM, é possível especificar ações e recursos permitidos ou negados, assim como as condições sob as quais as ações são permitidas ou negadas. Para saber mais sobre todos os elementos que podem ser usados em uma política JSON, consulte [Referência de elemento de política JSON do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) no *Guia do usuário do IAM*.
Para visualizar exemplos de políticas baseadas em identidade do Shield, consulte [Exemplos de políticas baseadas em identidade para AWS Shield](shd-security_iam_id-based-policy-examples.md).
## Políticas baseadas em recursos no Shield
**Compatibilidade com políticas baseadas em recursos:** não
Políticas baseadas em recursos são documentos de políticas JSON que você anexa a um recurso. São exemplos de políticas baseadas em recursos as *políticas de confiança de perfil* do IAM e as *políticas de bucket* do Amazon S3. Em serviços compatíveis com políticas baseadas em recursos, os administradores de serviço podem usá-las para controlar o acesso a um recurso específico. Para o atributo ao qual a política está anexada, a política define quais ações uma entidade principal especificado pode executar nesse atributo e em que condições. É necessário [especificar uma entidade principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) em uma política baseada em recursos. Os diretores podem incluir contas, usuários, funções, usuários federados ou. Serviços da AWS
Para permitir o acesso entre contas, é possível especificar uma conta inteira ou as entidades do IAM em outra conta como a entidade principal em uma política baseada em recursos. Consulte mais informações em [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*.
## Ações de políticas do Shield
**Compatível com ações de políticas:** sim
Os administradores podem usar políticas AWS JSON para especificar quem tem acesso ao quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**.
O elemento `Action` de uma política JSON descreve as ações que podem ser usadas para permitir ou negar acesso em uma política. Incluem ações em uma política para conceder permissões para executar a operação associada.
Para ver uma lista das ações do Shield, consulte [Ações definidas pelo AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions) na *Referência de autorização do serviço*.
As ações de políticas no Shield usam o seguinte prefixo antes da ação:
```
shield
```
Para especificar várias ações em uma única instrução, separe-as com vírgulas.
```
"Action": [
"shield:action1",
"shield:action2"
]
```
Você também pode especificar várias ações usando caracteres-curinga (\$1). Por exemplo, para especificar todas as ações no Shield que começam com `List`, inclua a seguinte ação:
```
"Action": "shield:List*"
```
Para visualizar exemplos de políticas baseadas em identidade do Shield, consulte [Exemplos de políticas baseadas em identidade para AWS Shield](shd-security_iam_id-based-policy-examples.md).
## Recursos de políticas para o Shield
**Compatível com recursos de políticas:** sim
Os administradores podem usar políticas AWS JSON para especificar quem tem acesso ao quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**.
O elemento de política JSON `Resource` especifica o objeto ou os objetos aos quais a ação se aplica. Como prática recomendada, especifique um recurso usando seu [nome do recurso da Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Para ações que não oferecem compatibilidade com permissões em nível de recurso, use um curinga (\$1) para indicar que a instrução se aplica a todos os recursos.
```
"Resource": "*"
```
Para ver a lista dos tipos de recursos do Shield e seus ARNs, consulte [Recursos definidos por AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-resources-for-iam-policies) na *Referência de Autorização de Serviço*. Para saber com quais ações é possível especificar o ARN de cada atributo, consulte [Ações definidas pelo AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions). Para permitir ou negar o acesso a um subconjunto de recursos do Shield, inclua o ARN do recurso no elemento `resource` da sua política.
Dentro AWS Shield, os recursos são *proteções* e *ataques*. Esses recursos têm nomes de recursos exclusivos da Amazon (ARNs) associados a eles, conforme mostrado na tabela a seguir.
****
| Nome no AWS Shield console | Nome no AWS Shield SDK/CLI | Formato do ARN |
| --- | --- | --- |
| Evento ou ataque | AttackDetail | `arn:aws:shield::account:attack/ID` |
| Proteção | Protection | `arn:aws:shield::account:protection/ID` |
Para permitir ou negar o acesso a um subconjunto de recursos do Shield, inclua o ARN do recurso no elemento `resource` da sua política. O ARNs for Shield tem o seguinte formato:
```
arn:partition:shield::account:resource/ID
```
Substitua as *ID* variáveis *account**resource*, e por valores válidos. Os valores válidos podem ser os seguintes:
+ *account*: O ID do seu Conta da AWS. Você deve especificar um valor.
+ *resource*: O tipo de recurso Shield, `attack` ou`protection`.
+ *ID*: o ID do recurso Shield ou um curinga (`*`) para indicar todos os recursos do tipo especificado que estão associados ao especificado Conta da AWS.
Por exemplo, o ARN a seguir especifica todas as proteções da conta `111122223333`:
```
arn:aws:shield::111122223333:protection/*
```
Os recursos ARNs do of Shield têm o seguinte formato:
```
arn:partition:shield:region:account-id:scope/resource-type/resource-name/resource-id
```
Para obter informações gerais sobre as especificações do ARN, consulte [Amazon Resource Names (ARNs)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) no. Referência geral da Amazon Web Services
A seguir, são listados os requisitos específicos ARNs dos `wafv2` recursos de:
+ *region*: Para os recursos do Shield que você usa para proteger CloudFront as distribuições da Amazon, defina `us-east-1` isso como. Caso contrário, defina isso para a região que você está usando com seus recursos regionais protegidos.
+ *scope*: defina o escopo `global` para uso com uma CloudFront distribuição da Amazon ou `regional` para uso com qualquer um dos recursos regionais que oferecem AWS WAF suporte. Os recursos regionais são uma API REST do Amazon API Gateway, um Application Load Balancer, uma API GraphQL AWS AppSync , um grupo de usuários do Amazon Cognito, um AWS App Runner serviço e uma instância de acesso verificado. AWS
+ *resource-type*: especifique um dos seguintes valores: `attack` para eventos ou ataques, `protection` para proteções.
+ *resource-name*: especifique o nome que você deu ao recurso Shield ou especifique um curinga (`*`) para indicar todos os recursos que atendem às outras especificações no ARN. Você deve especificar o nome do recurso e a ID do recurso ou especificar um caractere curinga para ambos.
+ *resource-id*: especifique o ID do recurso Shield ou especifique um curinga (`*`) para indicar todos os recursos que atendem às outras especificações no ARN. Você deve especificar o nome do recurso e a ID do recurso ou especificar um caractere curinga para ambos.
Por exemplo, o ARN a seguir especifica toda a web ACLs com escopo regional para a conta `111122223333` na Região: `us-west-1`
```
arn:aws:wafv2:us-west-1:111122223333:regional/webacl/*/*
```
O ARN a seguir especifica o grupo de regras nomeado `MyIPManagementRuleGroup` com escopo global para a conta `111122223333` na região `us-east-1`:
```
arn:aws:wafv2:us-east-1:111122223333:global/rulegroup/MyIPManagementRuleGroup/1111aaaa-bbbb-cccc-dddd-example-id
```
Para visualizar exemplos de políticas baseadas em identidade do Shield, consulte [Exemplos de políticas baseadas em identidade para AWS Shield](shd-security_iam_id-based-policy-examples.md).
## Chaves de condição de políticas para o Shield
**Compatível com chaves de condição de política específicas de serviço:** sim
Os administradores podem usar políticas AWS JSON para especificar quem tem acesso ao quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**.
O elemento `Condition` especifica quando as instruções são executadas com base em critérios definidos. É possível criar expressões condicionais que usem [agentes de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), como “igual a” ou “menor que”, para fazer a condição da política corresponder aos valores na solicitação. Para ver todas as chaves de condição AWS globais, consulte as [chaves de contexto de condição AWS global](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) no *Guia do usuário do IAM*.
Para ver uma lista de chaves de condição do Shield, consulte [Chaves de condição do AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-policy-keys) na *Referência de autorização do serviço*. Para saber com quais ações e recursos você pode usar uma chave de condição, consulte [Ações definidas por AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions).
Para visualizar exemplos de políticas baseadas em identidade do Shield, consulte [Exemplos de políticas baseadas em identidade para AWS Shield](shd-security_iam_id-based-policy-examples.md).
## ACLs em Shield
**Suportes ACLs:** Não
As listas de controle de acesso (ACLs) controlam quais diretores (membros da conta, usuários ou funções) têm permissões para acessar um recurso. ACLs são semelhantes às políticas baseadas em recursos, embora não usem o formato de documento de política JSON.
## ABAC com Shield
**Compatível com ABAC (tags em políticas):** parcial
O controle de acesso por atributo (ABAC) é uma estratégia de autorização que define permissões com base em atributos chamados de tags. Você pode anexar tags a entidades e AWS recursos do IAM e, em seguida, criar políticas ABAC para permitir operações quando a tag do diretor corresponder à tag no recurso.
Para controlar o acesso baseado em tags, forneça informações sobre as tags no [elemento de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) de uma política usando as `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou chaves de condição `aws:TagKeys`.
Se um serviço for compatível com as três chaves de condição para cada tipo de recurso, o valor será **Sim** para o serviço. Se um serviço for compatível com as três chaves de condição somente para alguns tipos de recursos, o valor será **Parcial**
Para saber mais sobre o ABAC, consulte [Definir permissões com autorização do ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) no *Guia do usuário do IAM*. Para visualizar um tutorial com etapas para configurar o ABAC, consulte [Usar controle de acesso por atributo (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) no *Guia do usuário do IAM*.
## Usar credenciais temporárias com o Shield
**Compatível com credenciais temporárias:** sim
As credenciais temporárias fornecem acesso de curto prazo aos AWS recursos e são criadas automaticamente quando você usa a federação ou troca de funções. AWS recomenda que você gere credenciais temporárias dinamicamente em vez de usar chaves de acesso de longo prazo. Para ter mais informações, consulte [Credenciais de segurança temporárias no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) e [Serviços da Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) no *Guia do usuário do IAM*.
## Sessões de acesso direto para o Shield
**Compatibilidade com o recurso de encaminhamento de sessões de acesso (FAS):** sim
As sessões de acesso direto (FAS) usam as permissões do principal chamando um AWS service (Serviço da AWS), combinadas com a solicitação AWS service (Serviço da AWS) de fazer solicitações aos serviços posteriores. Para obter detalhes da política ao fazer solicitações de FAS, consulte [Sessões de acesso direto](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Perfis de serviço do Shield
**Compatível com perfis de serviço:** sim
O perfil de serviço é um [perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que um serviço assume para executar ações em seu nome. Um administrador do IAM pode criar, modificar e excluir um perfil de serviço do IAM. Para saber mais, consulte [Criar um perfil para delegar permissões a um AWS service (Serviço da AWS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) no *Guia do Usuário do IAM*.
**Atenção**
Alterar as permissões de um perfil de serviço pode prejudicar a funcionalidade do Shield. Só edite os perfis de serviço quando o Shield orientá-lo a fazê-lo.
## Funções vinculadas ao serviço para o Shield
**Compatibilidade com perfis vinculados a serviços:** sim
Uma função vinculada ao serviço é um tipo de função de serviço vinculada a um. AWS service (Serviço da AWS) O serviço pode assumir o perfil de executar uma ação em seu nome. As funções vinculadas ao serviço aparecem em você Conta da AWS e são de propriedade do serviço. Um administrador do IAM pode visualizar, mas não editar as permissões para perfis vinculados ao serviço.
Para obter detalhes sobre como criar ou gerenciar funções vinculadas ao serviço do Shield, consulte [Usar funções vinculadas ao serviço para o Shield Advanced](shd-using-service-linked-roles.md).
# Exemplos de políticas baseadas em identidade para AWS Shield
Por padrão, usuários e funções não têm permissão para criar ou modificar recursos do Shield. Para conceder permissão aos usuários para executar ações nos recursos que eles precisam, um administrador do IAM pode criar políticas do IAM.
Para aprender a criar uma política baseada em identidade do IAM ao usar esses documentos de política em JSON de exemplo, consulte [Criar políticas do IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) no *Guia do usuário do IAM*.
Para obter detalhes sobre ações e tipos de recursos definidos pelo Shield, incluindo o formato de cada um dos tipos de recursos, consulte [Ações, recursos e chaves de condição AWS Shield na Referência de](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html) *Autorização de Serviço*. ARNs
**Topics**
+ [Práticas recomendadas de política](#shd-security_iam_service-with-iam-policy-best-practices)
+ [Como usar o console do Shield](#shd-security_iam_id-based-policy-examples-console)
+ [Permitir que os usuários visualizem suas próprias permissões](#shd-security_iam_id-based-policy-examples-view-own-permissions)
+ [Conceda acesso de leitura às suas proteções Shield Advanced](#shd-example0)
+ [Conceda acesso somente de leitura ao Shield,, e CloudFront CloudWatch](#shd-example1)
+ [Conceda acesso total ao Shield, CloudFront, e CloudWatch](#shd-example2)
## Práticas recomendadas de política
As políticas baseadas em identidade determinam se alguém pode criar, acessar ou excluir recursos do Shield em sua conta. Essas ações podem incorrer em custos para sua Conta da AWS. Ao criar ou editar políticas baseadas em identidade, siga estas diretrizes e recomendações:
+ **Comece com as políticas AWS gerenciadas e passe para as permissões de privilégios mínimos — Para começar a conceder permissões** aos seus usuários e cargas de trabalho, use as *políticas AWS gerenciadas* que concedem permissões para muitos casos de uso comuns. Eles estão disponíveis no seu Conta da AWS. Recomendamos que você reduza ainda mais as permissões definindo políticas gerenciadas pelo AWS cliente que sejam específicas para seus casos de uso. Para saber mais, consulte [Políticas gerenciadas pela AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [Políticas gerenciadas pela AWS para funções de trabalho](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) no *Guia do usuário do IAM*.
+ **Aplique permissões de privilégio mínimo**: ao definir permissões com as políticas do IAM, conceda apenas as permissões necessárias para executar uma tarefa. Você faz isso definindo as ações que podem ser executadas em recursos específicos sob condições específicas, também conhecidas como *permissões de privilégio mínimo*. Para saber mais sobre como usar o IAM para aplicar permissões, consulte [Políticas e permissões no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) no *Guia do usuário do IAM*.
+ **Use condições nas políticas do IAM para restringir ainda mais o acesso**: é possível adicionar uma condição às políticas para limitar o acesso a ações e recursos. Por exemplo, é possível escrever uma condição de política para especificar que todas as solicitações devem ser enviadas usando SSL. Você também pode usar condições para conceder acesso às ações de serviço se elas forem usadas por meio de uma ação específica AWS service (Serviço da AWS), como CloudFormation. Para saber mais, consulte [Elementos da política JSON do IAM: condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) no *Guia do usuário do IAM*.
+ **Use o IAM Access Analyzer para validar suas políticas do IAM a fim de garantir permissões seguras e funcionais**: o IAM Access Analyzer valida as políticas novas e existentes para que elas sigam a linguagem de política do IAM (JSON) e as práticas recomendadas do IAM. O IAM Access Analyzer oferece mais de cem verificações de política e recomendações práticas para ajudar a criar políticas seguras e funcionais. Para saber mais, consulte [Validação de políticas do IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) no *Guia do Usuário do IAM*.
+ **Exigir autenticação multifator (MFA**) — Se você tiver um cenário que exija usuários do IAM ou um usuário root, ative Conta da AWS a MFA para obter segurança adicional. Para exigir MFA quando as operações de API forem chamadas, adicione condições de MFA às suas políticas. Para saber mais, consulte [Configuração de acesso à API protegido por MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) no *Guia do Usuário do IAM*.
Para saber mais sobre as práticas recomendadas do IAM, consulte [Práticas recomendadas de segurança no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) no *Guia do usuário do IAM*.
## Como usar o console do Shield
Para acessar o AWS Shield console, você deve ter um conjunto mínimo de permissões. Essas permissões devem permitir que você liste e visualize detalhes sobre os recursos do Shield em seu Conta da AWS. Caso crie uma política baseada em identidade mais restritiva que as permissões mínimas necessárias, o console não funcionará como pretendido para entidades (usuários ou perfis) com essa política.
Você não precisa permitir permissões mínimas do console para usuários que estão fazendo chamadas somente para a API AWS CLI ou para a AWS API. Em vez disso, permita o acesso somente a ações que correspondam à operação de API que estiverem tentando executar.
Os usuários que podem acessar e usar o AWS console também podem acessar o AWS Shield console. Nenhuma permissão adicional é necessária.
### Somente para console APIs
Você pode acessar as seguintes informações sobre ataques de negação de serviço distribuída (DDoS) no console. Especifique as seguintes permissões de API em uma política do IAM para permitir ou negar ações específicas.
| Ação | Description |
| --- | --- |
| DescribeAttackContributors | Concede permissão para obter informações detalhadas sobre os contribuidores de um ataque DDo S específico. |
| ListMitigations | Concede permissão para recuperar uma lista de ações de mitigação que foram aplicadas durante DDo os ataques S. |
| GetGlobalThreatData | Concede permissão para recuperar dados e tendências globais de inteligência de ameaças dos sistemas de monitoramento de ameaças da AWS Shield. |
Este exemplo mostra como você pode criar uma política que permita ver DDo as informações do ataque S no console.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"shield:DescribeAttackContributors"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"shield:ListMitigations"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"shield:GetGlobalThreatData"
],
"Resource": "*"
}
]
}
```
------
## Permitir que os usuários visualizem suas próprias permissões
Este exemplo mostra como criar uma política que permita que os usuários do IAM visualizem as políticas gerenciadas e em linha anexadas a sua identidade de usuário. Essa política inclui permissões para concluir essa ação no console ou programaticamente usando a API AWS CLI ou AWS .
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## Conceda acesso de leitura às suas proteções Shield Advanced
AWS Shield permite acesso a recursos entre contas, mas não permite que você crie proteções de recursos entre contas. Você só pode criar proteções para recursos de dentro da conta que possui esses recursos.
Veja a seguir um exemplo de política que concede permissões para a ação `shield:ListProtections` em todos os recursos. O Shield não suporta a identificação de recursos específicos usando o recurso ARNs (também conhecido como permissões em nível de recurso) para algumas das ações da API, então você especifica um caractere curinga (\$1). Isso só permite o acesso aos recursos que você pode recuperar por meio da ação `ListProtections`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ListProtections",
"Effect": "Allow",
"Action": [
"shield:ListProtections"
],
"Resource": "*"
}
]
}
```
------
## Conceda acesso somente de leitura ao Shield,, e CloudFront CloudWatch
A política a seguir concede aos usuários acesso somente de leitura ao Shield e aos recursos associados, incluindo CloudFront recursos da Amazon e métricas da Amazon CloudWatch . É útil para usuários que precisam de permissão para visualizar as configurações nas proteções e ataques do Shield e monitorar as métricas em CloudWatch. Esses usuários não podem criar, atualizar nem excluir recursos do Shield.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ProtectedResourcesReadAccess",
"Effect": "Allow",
"Action": [
"cloudfront:List*",
"route53:List*",
"cloudfront:Describe*",
"elasticloadbalancing:Describe*",
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*",
"cloudfront:GetDistribution*",
"globalaccelerator:ListAccelerators",
"globalaccelerator:DescribeAccelerator"
],
"Resource": [
"arn:aws:elasticloadbalancing:*:*:*",
"arn:aws:cloudfront::*:*",
"arn:aws:route53:::hostedzone/*",
"arn:aws:cloudwatch:*:*:*:*",
"arn:aws:globalaccelerator::*:*"
]
},
{
"Sid": "ShieldReadOnly",
"Effect": "Allow",
"Action": [
"shield:List*",
"shield:Describe*",
"shield:Get*"
],
"Resource": "*"
}
]
}
```
------
## Conceda acesso total ao Shield, CloudFront, e CloudWatch
A política a seguir permite que os usuários realizem qualquer operação do Shield, realizem qualquer operação em distribuições CloudFront da web e monitorem métricas e uma amostra de solicitações recebidas. CloudWatch Ela é útil aos usuários que são administradores do Shield.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ProtectedResourcesReadAccess",
"Effect": "Allow",
"Action": [
"cloudfront:List*",
"route53:List*",
"cloudfront:Describe*",
"elasticloadbalancing:Describe*",
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*",
"cloudfront:GetDistribution*",
"globalaccelerator:ListAccelerators",
"globalaccelerator:DescribeAccelerator"
],
"Resource": [
"arn:aws:elasticloadbalancing:*:*:*",
"arn:aws:cloudfront::*:*",
"arn:aws:route53:::hostedzone/*",
"arn:aws:cloudwatch:*:*:*:*",
"arn:aws:globalaccelerator::*:*"
]
},
{
"Sid": "ShieldFullAccess",
"Effect": "Allow",
"Action": [
"shield:*"
],
"Resource": "*"
}
]
}
```
------
Recomendamos que você configure autenticação multifator (MFA) para os usuários que tiverem permissões administrativas. Para saber mais, consulte [Como usar dispositivos com autenticação multifator (MFA) com o AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_ManagingMFA.html) no *Guia do usuário do IAM*.
# AWS políticas gerenciadas para AWS Shield
Uma política AWS gerenciada é uma política autônoma criada e administrada por AWS. AWS as políticas gerenciadas são projetadas para fornecer permissões para muitos casos de uso comuns, para que você possa começar a atribuir permissões a usuários, grupos e funções.
Lembre-se de que as políticas AWS gerenciadas podem não conceder permissões de privilégio mínimo para seus casos de uso específicos porque elas estão disponíveis para uso de todos os AWS clientes. Recomendamos que você reduza ainda mais as permissões definindo as [ políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) que são específicas para seus casos de uso.
Você não pode alterar as permissões definidas nas políticas AWS gerenciadas. Se AWS atualizar as permissões definidas em uma política AWS gerenciada, a atualização afetará todas as identidades principais (usuários, grupos e funções) às quais a política está anexada. AWS é mais provável que atualize uma política AWS gerenciada quando uma nova AWS service (Serviço da AWS) for lançada ou novas operações de API forem disponibilizadas para serviços existentes.
Para saber mais, consulte [AWS Políticas gerenciadas pela ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) no *Guia do usuário do IAM*.
## AWS política gerenciada: AWSShield DRTAccess Política
Esta seção explica como usar políticas AWS gerenciadas para o Shield.
AWS Shield usa essa política gerenciada quando você concede permissão à Shield Response Team (SRT) para agir em seu nome. Essa política dá ao SRT acesso limitado à sua AWS conta, para ajudar na mitigação do ataque DDo S durante eventos de alta gravidade. Essa política permite que o SRT gerencie suas AWS WAF regras e as proteções do Shield Advanced e acesse seus AWS WAF registros.
Para obter informações sobre como conceder permissão ao SRT para operar em seu nome, consulte [Como conceder acesso ao SRT](ddos-srt-access.md).
Para obter detalhes sobre essa política, consulte [AWSShieldDRTAccessPolítica](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSShieldDRTAccessPolicy) no console do IAM.
## AWS política gerenciada: AWSShield ServiceRolePolicy
O Shield Advanced usa essa política gerenciada quando você ativa a mitigação automática da camada DDo S do aplicativo, para definir as permissões necessárias para gerenciar os recursos da sua conta. Essa política permite que o Shield Advanced crie e aplique AWS WAF regras e grupos de regras na web ACLs que você associou aos seus recursos protegidos, para responder automaticamente aos ataques DDo S.
Você não pode se vincular AWSShield ServiceRolePolicy às suas entidades do IAM. O Shield anexa esta política a uma função vinculada ao serviço `AWSServiceRoleForAWSShield` que permite que o Shield realize ações em seu nome.
O Shield Advanced permite o uso dessa política quando você ativa a mitigação automática da camada DDo S do aplicativo. Para saber mais sobre esta política, consulte [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md).
Para obter informações sobre a função vinculada ao serviço AWSService RoleFor AWSShield que usa essa política, consulte [Usar funções vinculadas ao serviço para o Shield Advanced](shd-using-service-linked-roles.md)
Para obter detalhes sobre essa política, consulte [AWSShieldServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/AWSShieldServiceRolePolicy)no console do IAM.
## Atualizações do Shield para políticas AWS gerenciadas
Veja detalhes sobre as atualizações das políticas AWS gerenciadas do Shield desde que esse serviço começou a rastrear essas alterações. Para receber alertas automáticos sobre alterações feitas nesta página, inscreva-se no feed RSS na página de histórico de documentos em [Histórico do documento](doc-history.md).
| Política | Descrição de alteração | Data |
| --- | --- | --- |
| `AWSShieldServiceRolePolicy` Essa política permite que a Shield acesse e gerencie AWS recursos para responder automaticamente aos ataques da camada DDo S do aplicativo em seu nome. Detalhes no console do IAM: [AWSShieldServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/AWSShieldServiceRolePolicy) O perfil vinculado ao serviço `AWSServiceRoleForAWSShield` usa essa política. Para mais informações, consulte [Usar funções vinculadas ao serviço para o Shield Advanced](shd-using-service-linked-roles.md). | Essa política foi adicionada para fornecer ao Shield Advanced as permissões necessárias para a funcionalidade de mitigação automática da camada DDo S do aplicativo. Para obter mais informações sobre esse atributo, consulte [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md). | 1º de dezembro de 2021 |
| O Shield começou a monitorar alterações | A Shield começou a monitorar as mudanças em suas políticas AWS gerenciadas. | 3 de março de 2021 |
# Solução de problemas AWS Shield de identidade e acesso
Use as seguintes informações para ajudar a diagnosticar e corrigir problemas comuns que podem ser encontrados ao trabalhar com o Shield e o IAM.
**Topics**
+ [Não tenho autorização para executar uma ação no Shield](#shd-security_iam_troubleshoot-no-permissions)
+ [Não estou autorizado a realizar iam: PassRole](#shd-security_iam_troubleshoot-passrole)
+ [Quero permitir que pessoas fora da minha acessem meus Conta da AWS recursos do Shield](#shd-security_iam_troubleshoot-cross-account-access)
## Não tenho autorização para executar uma ação no Shield
Se você receber uma mensagem de erro informando que não tem autorização para executar uma ação, suas políticas deverão ser atualizadas para permitir que você realize a ação.
O erro do exemplo a seguir ocorre quando o usuário do IAM `mateojackson` tenta usar o console para visualizar detalhes sobre um atributo `my-example-widget` fictício, mas não tem as permissões `shield:GetWidget` fictícias.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: shield:GetWidget on resource: my-example-widget
```
Nesse caso, a política do usuário `mateojackson` deve ser atualizada para permitir o acesso ao recurso `my-example-widget` usando a ação `shield:GetWidget`.
Se precisar de ajuda, entre em contato com seu AWS administrador. Seu administrador é a pessoa que forneceu suas credenciais de login.
## Não estou autorizado a realizar iam: PassRole
Se você receber uma mensagem de erro informando que não tem autorização para executar a ação `iam:PassRole`, as suas políticas deverão ser atualizadas para permitir a passagem de um perfil para o Shield.
Alguns Serviços da AWS permitem que você passe uma função existente para esse serviço em vez de criar uma nova função de serviço ou uma função vinculada ao serviço. Para fazer isso, é preciso ter permissões para passar o perfil para o serviço.
O erro de exemplo a seguir ocorre quando uma usuária do IAM chamada `marymajor` tenta usar o console para executar uma ação no Shield. No entanto, a ação exige que o serviço tenha permissões concedidas por um perfil de serviço. Mary não tem permissões para passar o perfil para o serviço.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
Nesse caso, as políticas de Mary devem ser atualizadas para permitir que ela realize a ação `iam:PassRole`.
Se precisar de ajuda, entre em contato com seu AWS administrador. Seu administrador é a pessoa que forneceu suas credenciais de login.
## Quero permitir que pessoas fora da minha acessem meus Conta da AWS recursos do Shield
É possível criar um perfil que os usuários de outras contas ou pessoas fora da organização podem usar para acessar seus recursos. É possível especificar quem é confiável para assumir o perfil. Para serviços que oferecem suporte a políticas baseadas em recursos ou listas de controle de acesso (ACLs), você pode usar essas políticas para conceder às pessoas acesso aos seus recursos.
Para saber mais, consulte:
+ Para saber se o Shield oferece suporte a esses atributos, consulte [Como AWS Shield funciona com o IAM](shd-security_iam_service-with-iam.md).
+ Para saber como fornecer acesso aos seus recursos em todos os Contas da AWS que você possui, consulte Como [fornecer acesso a um usuário do IAM em outro Conta da AWS que você possui](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) no *Guia do usuário do IAM*.
+ Para saber como fornecer acesso aos seus recursos a terceiros Contas da AWS, consulte Como [fornecer acesso Contas da AWS a terceiros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) no *Guia do usuário do IAM*.
+ Para saber como conceder acesso por meio da federação de identidades, consulte [Conceder acesso a usuários autenticados externamente (federação de identidades)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) no *Guia do usuário do IAM*.
+ Para saber a diferença entre usar perfis e políticas baseadas em recursos para acesso entre contas, consulte [Como os perfis do IAM diferem de políticas baseadas em recursos](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) no *Guia do usuário do IAM*.
# Usar funções vinculadas ao serviço para o Shield Advanced
Esta seção explica como usar funções vinculadas a serviços para dar ao Shield Advanced acesso aos recursos em sua AWS conta.
AWS Shield Advanced usa funções [vinculadas ao serviço AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Uma função vinculada ao serviço é um tipo exclusivo de perfil do IAM vinculado diretamente a um serviço do Shield Advanced. As funções vinculadas ao serviço são predefinidas pelo Shield Advanced e incluem todas as permissões que o serviço exige para chamar outros AWS serviços em seu nome.
Uma função vinculada ao serviço facilita a configuração do Shield Advanced porque você não precisa adicionar as permissões necessárias manualmente. O Shield Advanced define as permissões das funções vinculadas ao serviço e, exceto se definido de outra forma, somente o Shield Advanced pode assumir suas funções. As permissões definidas incluem a política de confiança e a política de permissões, que não pode ser anexada a nenhuma outra entidade do IAM.
Um perfil vinculado ao serviço poderá ser excluído somente após excluir seus atributos relacionados. Isso protege seus recursos do Shield Advanced, pois você não pode remover por engano as permissões para acessar os recursos.
Para obter informações sobre outros serviços compatíveis com perfis vinculados a serviços, consulte [Serviços da AWS compatíveis com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e procure os serviços que contenham **Sim** na coluna **Service-Linked Role**. Escolha um **Sim** com um link para visualizar a documentação do perfil vinculado para esse serviço.
## Permissões de função vinculada ao serviço para o Shield Advanced
O Shield Advanced usa a função vinculada ao serviço chamada. **AWSServiceRoleForAWSShield** Essa função permite que o Shield Advanced acesse e gerencie AWS recursos para responder automaticamente aos ataques da camada DDo S do aplicativo em seu nome. Para ter mais informações sobre essa função, consulte [Automatizando a mitigação da camada DDo S do aplicativo com o Shield Advanced](ddos-automatic-app-layer-response.md).
A função AWSService RoleFor AWSShield vinculada ao serviço confia nos seguintes serviços para assumir a função:
+ `shield.amazonaws.com`
A política de permissões de função denominada AWSShield ServiceRolePolicy permite que o Shield Advanced conclua as seguintes ações em todos os AWS recursos:
+ `wafv2:GetWebACL`
+ `wafv2:UpdateWebACL`
+ `wafv2:GetWebACLForResource`
+ `wafv2:ListResourcesForWebACL`
+ `cloudfront:ListDistributions`
+ `cloudfront:GetDistribution`
Quando ações são permitidas em todos os AWS recursos, isso é indicado na política como`"Resource": "*"`. Isso significa apenas que a função vinculada ao serviço pode realizar cada ação indicada em todos os AWS recursos *que a ação suporta*. Por exemplo, a ação `wafv2:GetWebACL` é suportada somente para recursos `wafv2` da web ACL.
O Shield Advanced só faz chamadas de API em nível de recurso para recursos protegidos para os quais você ativou o recurso de proteção da camada de aplicação e para a web ACLs que estão associados a esses recursos protegidos.
Você deve configurar permissões para que uma entidade do IAM (por exemplo, um usuário, grupo ou função) crie, edite ou exclua um perfil vinculado a serviço. Para saber mais, consulte [Permissões de função vinculada a serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) no *Guia do usuário do IAM*.
## Criação de uma função vinculada ao serviço para o Shield Advanced
Não é necessário criar manualmente um perfil vinculado ao serviço. Quando você ativa a mitigação automática da camada DDo S do aplicativo para um recurso na, na ou na AWS API Console de gerenciamento da AWS AWS CLI, o Shield Advanced cria a função vinculada ao serviço para você.
Se excluir esse perfil vinculado ao serviço e precisar criá-lo novamente, será possível usar esse mesmo processo para recriar o perfil em sua conta. Quando você ativa a mitigação automática da camada DDo S do aplicativo para um recurso, o Shield Advanced cria a função vinculada ao serviço para você novamente.
## Edição de uma função vinculada ao serviço para o Shield Advanced
O Shield Advanced não permite que você edite a função AWSService RoleFor AWSShield vinculada ao serviço. Depois que criar um perfil vinculado ao serviço, você não poderá alterar o nome do perfil, pois várias entidades podem fazer referência a ele. No entanto, será possível editar a descrição do perfil usando o IAM. Para saber mais, consulte [Editar uma função vinculada a serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) no *Guia do usuário do IAM*.
## Exclusão de uma função vinculada ao serviço para o Shield Advanced
Se você não precisar mais usar um recurso ou serviço que requer um perfil vinculado ao serviço, é recomendável excluí-lo. Dessa forma, você não tem uma entidade não utilizada que não seja monitorada ativamente ou mantida. No entanto, você deve limpar os recursos de seu perfil vinculado ao serviço antes de excluí-lo manualmente.
**nota**
Se o Shield Advanced estiver usando a função quando você tenta excluir os recursos, a exclusão poderá falhar. Se isso acontecer, espere alguns minutos e tente a operação novamente.
**Para excluir os recursos do Shield Advanced que são usados pelo AWSService RoleFor AWSShield**
Para todos os seus recursos que têm proteções da camada DDo S do aplicativo configuradas, desative a mitigação automática da camada DDo S do aplicativo. Para obter instruções sobre o console, consulte [Configurar as proteções da camada DDo S do aplicativo](manage-protection.md#configure-app-layer-protection).
**Como excluir manualmente o perfil vinculado ao serviço usando o IAM**
Use o console do IAM AWS CLI, o ou a AWS API para excluir a função AWSService RoleFor AWSShield vinculada ao serviço. Para saber mais, consulte [Excluir uma função vinculada a serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) no *Guia do usuário do IAM*.
## Regiões com suporte a funções vinculadas a serviço do Shield Advanced
O Shield Advanced oferece suporte a perfis vinculados ao serviço em todas as regiões em que o serviço está disponível. Para saber mais, consulte [Endpoints e cotas do Shield Advanced](https://docs.aws.amazon.com/general/latest/gr/shield.html).
# Como registrar em log e monitorar no Shield
Esta seção explica como usar AWS ferramentas para monitorar e responder aos eventos em AWS Shield.
O monitoramento é uma parte importante da manutenção da confiabilidade, disponibilidade e desempenho do Shield e de suas AWS soluções. Você deve coletar dados de monitoramento de todas as partes da sua AWS solução para poder depurar com mais facilidade uma falha multiponto, caso ocorra. AWS fornece várias ferramentas para monitorar seus recursos do Shield e responder a possíveis eventos:
** CloudWatch Alarmes da Amazon**
Usando CloudWatch alarmes, você observa uma única métrica durante um período de tempo especificado por você. Se a métrica exceder um determinado limite, CloudWatch envia uma notificação para um tópico AWS Auto Scaling ou política do Amazon SNS. Para obter mais informações, consulte [Monitoramento com a Amazon CloudWatch](monitoring-cloudwatch.md).
**AWS CloudTrail Registros**
CloudTrail fornece um registro das ações realizadas por um usuário, função ou AWS serviço no Shield. Usando as informações coletadas por CloudTrail, você pode determinar a solicitação que foi feita à Shield, o endereço IP do qual a solicitação foi feita, quem fez a solicitação, quando ela foi feita e detalhes adicionais. Para obter mais informações, consulte [Registro de chamadas de API do AWS CloudTrail com](logging-using-cloudtrail.md).
# Como validar a conformidade no Shield
Esta seção explica sua responsabilidade de conformidade ao usar AWS Shield.
Para saber se um AWS service (Serviço da AWS) está dentro do escopo de programas de conformidade específicos, consulte [Serviços da AWS Escopo por Programa de Conformidade Serviços da AWS](https://aws.amazon.com/compliance/services-in-scope/) e escolha o programa de conformidade em que você está interessado. Para obter informações gerais, consulte Programas de [AWS conformidade Programas AWS](https://aws.amazon.com/compliance/programs/) de .
Você pode baixar relatórios de auditoria de terceiros usando AWS Artifact. Para obter mais informações, consulte [Baixar relatórios em AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
Sua responsabilidade de conformidade ao usar Serviços da AWS é determinada pela confidencialidade de seus dados, pelos objetivos de conformidade de sua empresa e pelas leis e regulamentações aplicáveis. Para obter mais informações sobre sua responsabilidade de conformidade ao usar Serviços da AWS, consulte a [documentação AWS de segurança](https://docs.aws.amazon.com/security/).
# Como desenvolver resiliência no Shield
Esta seção explica como a AWS arquitetura oferece suporte à redundância de dados para. AWS Shield
A infraestrutura AWS global é construída em torno Regiões da AWS de zonas de disponibilidade. Regiões da AWS fornecem várias zonas de disponibilidade fisicamente separadas e isoladas, conectadas a redes de baixa latência, alta taxa de transferência e alta redundância. Com as zonas de disponibilidade, é possível projetar e operar aplicações e bancos de dados que executam o failover automaticamente entre as zonas de disponibilidade sem interrupção. As zonas de disponibilidade são mais altamente disponíveis, tolerantes a falhas e escaláveis que uma ou várias infraestruturas de data center tradicionais.
Para obter mais informações sobre zonas de disponibilidade Regiões da AWS e zonas de disponibilidade, consulte [Infraestrutura AWS global](https://aws.amazon.com/about-aws/global-infrastructure/).
# Segurança da infraestrutura em AWS Shield
Esta seção explica como AWS Shield isola o tráfego do serviço.
Como serviço gerenciado, AWS Shield é protegido pela segurança de rede AWS global. Para obter informações sobre serviços AWS de segurança e como AWS proteger a infraestrutura, consulte [AWS Cloud Security](https://aws.amazon.com/security/). Para projetar seu AWS ambiente usando as melhores práticas de segurança de infraestrutura, consulte [Proteção](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) de infraestrutura no *Security Pillar AWS Well‐Architected* Framework.
Você usa chamadas de API AWS publicadas para acessar o Shield pela rede. Os clientes devem oferecer compatibilidade com:
+ Transport Layer Security (TLS). Exigimos TLS 1.2 e recomendamos TLS 1.3.
+ Conjuntos de criptografia com perfect forward secrecy (PFS) como DHE (Ephemeral Diffie-Hellman) ou ECDHE (Ephemeral Elliptic Curve Diffie-Hellman). A maioria dos sistemas modernos, como Java 7 e versões posteriores, comporta esses modos.
# AWS Shield Advanced cotas
AWS Shield Advanced tem cotas padrão no número de entidades por região. Você pode [solicitar um aumento](https://console.aws.amazon.com/servicequotas/home/services/shield/quotas) dessas cotas.
| Recurso | Cota padrão |
| --- | --- |
| Número máximo de recursos protegidos para cada tipo de recurso que AWS Shield Advanced oferece proteção para, por conta. | 1.000 |
| Número máximo de grupos de proteção por conta. | 100 |
| Número máximo de recursos protegidos individuais que você pode incluir especificamente em um grupo de proteção. Na API, isso se aplica ao `Members` que você especifica ao definir o grupo de proteção `Pattern` como `ARBITRARY`. No console, isso se aplica aos recursos que você seleciona para o agrupamento de proteção **Escolha entre recursos protegidos**. | 1.000 |