**Présentation d'une nouvelle expérience de console pour AWS WAF**
Vous pouvez désormais utiliser l'expérience mise à jour pour accéder aux AWS WAF fonctionnalités n'importe où dans la console. Pour plus de détails, consultez la section [Utilisation de la console](https://docs.aws.amazon.com/waf/latest/developerguide/working-with-console.html).
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# AWS Shield
La protection contre les attaques par déni de service (DDoS) distribué est d'une importance capitale pour vos applications connectées à Internet. Lorsque vous créez votre application AWS, vous pouvez utiliser les protections AWS fournies sans frais supplémentaires. En outre, vous pouvez utiliser le service AWS Shield Advanced géré de protection contre les menaces pour améliorer votre niveau de sécurité grâce à des fonctionnalités supplémentaires de détection, d'atténuation et de réponse DDo S.
AWS s'engage à vous fournir les outils, les meilleures pratiques et les services nécessaires pour garantir une haute disponibilité, une sécurité et une résilience dans le cadre de votre défense contre les acteurs malveillants sur Internet. Ce guide est destiné à aider les décideurs informatiques et les ingénieurs en sécurité à comprendre comment utiliser Shield et Shield Advanced pour mieux protéger leurs applications contre les attaques DDo S et autres menaces externes.
Lorsque vous créez votre application sur AWS, vous bénéficiez d'une protection automatique AWS contre les vecteurs d'attaque volumétriques DDo S courants, tels que les attaques par réflexion UDP et les inondations TCP SYN. Vous pouvez tirer parti de ces protections pour garantir la disponibilité des applications sur lesquelles vous exécutez AWS en concevant et en configurant votre architecture pour la résilience DDo S.
Ce guide fournit des recommandations qui peuvent vous aider à concevoir, créer et configurer vos architectures d'applications pour la résilience DDo S. Les applications qui respectent les meilleures pratiques décrites dans ce guide peuvent bénéficier d'une meilleure continuité de disponibilité lorsqu'elles sont ciblées par des attaques DDo S de plus grande envergure et par une gamme plus étendue de vecteurs d'attaque DDo S. En outre, ce guide explique comment utiliser Shield Advanced pour implémenter une posture de protection DDo S optimisée pour vos applications critiques. Il s'agit notamment des applications pour lesquelles vous avez garanti un certain niveau de disponibilité à vos clients et de celles qui nécessitent une assistance opérationnelle AWS lors d'événements DDo S.
La sécurité est une responsabilité partagée entre vous AWS et vous. Le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) décrit cette notion par les termes sécurité *du* cloud et sécurité *dans* le cloud :
+ **Sécurité du cloud** : AWS est chargée de protéger l'infrastructure qui exécute les AWS services dans le AWS Cloud. AWS vous fournit également des services que vous pouvez utiliser en toute sécurité. L’efficacité de notre sécurité est régulièrement testée et vérifiée par des auditeurs tiers dans le cadre des [programmes de conformitéAWS](https://aws.amazon.com/compliance/programs/). Pour en savoir plus sur les programmes de conformité qui s'appliquent à Shield Advanced, consultez la section [AWS Services concernés par le programme de conformité](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sécurité dans le cloud** — Votre responsabilité est déterminée par le AWS service que vous utilisez. Vous êtes également responsable d’autres facteurs, y compris la sensibilité de vos données, les exigences de votre organisation, et la législation et la réglementation applicables.
![\[Un diagramme montre un rectangle divisé horizontalement. La partie supérieure est intitulée Client : Responsabilité en matière de sécurité « dans » le cloud et la moitié inférieure s'intitule AWS: Responsabilité en matière de sécurité « du » cloud. La moitié supérieure réservée aux clients comprend quatre niveaux. La première concerne les données clients. Le second concerne la gestion des plateformes, des applications, des identités et des accès. Le troisième concerne la configuration du système d'exploitation, du réseau et du pare-feu. Le quatrième niveau et le niveau inférieur de l'espace client sont divisés en trois sections situées côte à côte. À gauche, il y a les données côté client, le chiffrement et l'intégrité des données, l'authentification. Le chiffrement central est le chiffrement côté serveur ( and/or données du système de fichiers). La bonne solution est la protection du trafic réseau (chiffrement, intégrité, identité). Cela conclut le contenu du premier client sur la moitié du chiffre. La AWS moitié inférieure de la figure contient un niveau intitulé Logiciel en haut et en dessous, un niveau intitulé Matériel/infrastructure AWS globale. Le niveau logiciel est divisé en quatre sous-sections situées côte à côte et intitulées Calcul, Stockage, Base de données, Mise en réseau. Le niveau matériel est divisé en trois sous-sections situées côte à côte et qui indiquent les régions, les zones de disponibilité et les emplacements périphériques.\]](http://docs.aws.amazon.com/fr_fr/waf/latest/developerguide/images/shared-responsibility-model.png)
# Comment fonctionnent AWS Shield et Shield Advanced
Cette page explique la différence entre AWS Shield Standard et AWS Shield Advanced. Il décrit également les catégories d'attaques détectées par Shield.
AWS Shield Standard et AWS Shield Advanced fournissent des protections contre les attaques par déni de service distribué (DDoS) visant les AWS ressources au niveau des couches réseau et transport (couches 3 et 4) et de la couche application (couche 7). Une attaque DDo S est une attaque au cours de laquelle plusieurs systèmes compromis tentent d'inonder une cible de trafic. Une attaque DDo S peut empêcher les utilisateurs finaux légitimes d'accéder aux services cibles et provoquer le blocage de la cible en raison d'un volume de trafic écrasant.
AWS Shield fournit une protection contre un large éventail de vecteurs d'attaque DDo S connus et de vecteurs d'attaque zero-day. La détection et l'atténuation du Shield sont conçues pour fournir une couverture contre les menaces même si elles ne sont pas explicitement connues du service au moment de la détection.
Shield Standard est fourni automatiquement et sans frais supplémentaires lorsque vous l'utilisez AWS. Pour les plus hauts niveaux de protection contre les attaques, vous pouvez vous abonner à AWS Shield Advanced.
Les catégories d'attaques détectées par Shield sont les suivantes :
+ **Attaques volumétriques du réseau (couche 3)** : il s'agit d'une sous-catégorie des vecteurs d'attaque de la couche d'infrastructure. Ces vecteurs tentent de saturer la capacité du réseau ou de la ressource ciblée, afin de refuser le service aux utilisateurs légitimes.
+ **Attaques de protocole réseau (couche 4)** — Il s'agit d'une sous-catégorie de vecteurs d'attaque de couche d'infrastructure. Ces vecteurs abusent d'un protocole pour refuser le service à la ressource ciblée. Un exemple courant d'attaque de protocole réseau est l'inondation TCP SYN, qui peut épuiser l'état de connexion sur des ressources telles que les serveurs, les équilibreurs de charge ou les pare-feux. Une attaque de protocole réseau peut également être volumétrique. Par exemple, une inondation TCP SYN plus importante peut avoir pour but de saturer la capacité d'un réseau tout en épuisant l'état de la ressource ciblée ou des ressources intermédiaires.
+ **Attaques au niveau de l'application (couche 7)** : cette catégorie de vecteurs d'attaque tente de refuser le service à des utilisateurs légitimes en inondant une application de requêtes valides pour la cible, telles que des inondations de requêtes Web.
**Contents**
+ [Présentation de AWS Shield Standard](ddos-standard-summary.md)
+ [Présentation de AWS Shield Advanced](ddos-advanced-summary.md)
+ [Liste des AWS ressources qui AWS Shield Advanced protègent](ddos-advanced-summary-protected-resources.md)
+ [AWS Shield Advanced capacités et options](ddos-advanced-summary-capabilities.md)
+ [Décider s'il convient de souscrire à des protections supplémentaires AWS Shield Advanced et d'appliquer des protections supplémentaires](ddos-advanced-summary-deciding.md)
+ [Exemples d'attaques DDo S](types-of-ddos-attacks.md)
+ [Comment AWS Shield détecte les événements](ddos-event-detection.md)
+ [AWS Shield logique de détection des menaces au niveau de l'infrastructure (couche 3 et couche 4)](ddos-event-detection-infrastructure.md)
+ [Shield : logique de détection avancée pour les menaces de la couche application (couche 7)](ddos-event-detection-application.md)
+ [Shield : logique de détection avancée pour plusieurs ressources dans une application](ddos-event-detection-multiple-resources.md)
+ [Comment AWS Shield atténuer les événements](ddos-event-mitigation.md)
+ [Liste des fonctionnalités d'atténuation AWS Shield DDo S](ddos-event-mitigation-features.md)
+ [AWS Shield logique d'atténuation pour CloudFront et Route 53](ddos-event-mitigation-logic-continuous-inspection.md)
+ [AWS Shield logique d'atténuation pour les AWS régions](ddos-event-mitigation-logic-regions.md)
+ [AWS Shield logique d'atténuation pour les accélérateurs AWS Global Accelerator standard](ddos-event-mitigation-logic-gax.md)
+ [AWS Shield Advanced logique d'atténuation pour Elastic IPs](ddos-event-mitigation-logic-adv-eip.md)
+ [AWS Shield Advanced logique d'atténuation pour les applications Web](ddos-event-mitigation-logic-adv-web-app.md)
# Présentation de AWS Shield Standard
AWS Shield est un service géré de protection contre les menaces qui protège le périmètre de votre application. Le périmètre est le premier point d'entrée pour le trafic applicatif provenant de l'extérieur du AWS réseau.
Pour déterminer le périmètre de votre application, considérez la manière dont les utilisateurs accèdent à votre application depuis Internet. Si le premier point d'entrée se trouve dans une AWS région, le périmètre de l'application est votre Amazon Virtual Private Cloud (VPC). Si les utilisateurs sont dirigés vers votre application par Amazon Route 53 et accèdent d'abord à l'application via Amazon CloudFront ou AWS Global Accelerator, le périmètre de l'application commence à la périphérie du AWS réseau.
Shield offre des avantages en matière de détection et d'atténuation du DDo S pour toutes les applications qui s'exécutent AWS, mais les décisions que vous prenez lors de la conception de l'architecture de votre application influenceront votre niveau de résilience DDo S. DDoS La résilience est la capacité de votre application à continuer à fonctionner selon les paramètres attendus lors d'une attaque.
Tous les AWS clients bénéficient de la protection automatique de Shield Standard, sans frais supplémentaires. Shield Standard protège votre site Web ou vos applications contre les attaques de couche DDo S les plus courantes et les plus fréquentes qui ciblent votre site Web ou vos applications. Shield Standard contribue à protéger tous les AWS clients, mais vous bénéficiez d'avantages particuliers grâce aux zones hébergées Amazon Route 53, aux CloudFront distributions Amazon et aux accélérateurs AWS Global Accelerator standard. Ces ressources bénéficient d'une protection de disponibilité complète contre toutes les attaques connues au niveau du réseau et de la couche de transport.
# Présentation de AWS Shield Advanced
AWS Shield Advanced est un service géré qui vous aide à protéger votre application contre les menaces externes, telles que les attaques DDo S, les bots volumétriques et les tentatives d'exploitation de vulnérabilités. Pour les plus hauts niveaux de protection contre les attaques, vous pouvez vous abonner à AWS Shield Advanced.
Lorsque vous vous abonnez à Shield Advanced et que vous ajoutez une protection à vos ressources, Shield Advanced fournit une protection étendue contre les attaques DDo S pour ces ressources. Les protections que vous offre Shield Advanced peuvent varier en fonction de votre architecture et de vos choix de configuration. Utilisez les informations contenues dans ce guide pour créer et protéger des applications résilientes à l'aide de Shield Advanced, et pour monter en puissance lorsque vous avez besoin de l'aide d'un expert.
**Abonnements et AWS WAF coûts de Shield Advanced**
Votre abonnement Shield Advanced couvre les coûts liés à l'utilisation des AWS WAF fonctionnalités standard pour les ressources que vous protégez avec Shield Advanced. Les AWS WAF frais standard couverts par vos protections Shield Advanced sont le coût par pack de protection (ACL Web), le coût par règle et le prix de base par million de demandes d'inspection de requêtes Web, jusqu'à 1 500 WCUs et jusqu'à la taille corporelle par défaut.
L'activation de l'atténuation automatique de la couche d'application DDo S de Shield Advanced ajoute un groupe de règles à votre pack de protection (ACL Web) qui utilise 150 unités de capacité ACL Web (WCUs). Ils sont WCUs pris en compte dans l'utilisation de la WCU dans votre pack de protection (ACL Web). Pour plus d’informations, consultez [Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md), [Protection de la couche applicative avec le groupe de règles Shield Advanced](ddos-automatic-app-layer-response-rg.md) et [Unités de capacité Web ACL (WCUs) en AWS WAF](aws-waf-capacity-units.md).
Votre abonnement à Shield Advanced ne couvre pas l'utilisation de AWS WAF ressources que vous ne protégez pas à l'aide de Shield Advanced. Il ne couvre pas non plus les AWS WAF coûts non standard supplémentaires liés aux ressources protégées. Des exemples de AWS WAF coûts non standard sont ceux liés au contrôle des robots, à l'action des CAPTCHA règles, aux sites Web ACLs qui en utilisent plus de 1 500 WCUs et à l'inspection du corps de la demande au-delà de la taille par défaut. La liste complète est disponible sur la page de AWS WAF tarification. Votre abonnement à Shield Advanced inclut l'accès au groupe Layer 7 Anti- DDo S Amazon Managed Rule. Dans le cadre de votre abonnement, vous recevrez jusqu'à 50 milliards de demandes adressées aux AWS WAF ressources protégées de Shield Advanced au cours d'un mois civil. Les demandes supérieures à 50 milliards seront facturées conformément à la page de AWS Shield Advanced tarification.
Pour obtenir des informations complètes et des exemples de tarification, consultez [Shield Pricing](https://aws.amazon.com/shield/pricing/) and [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/).
**Facturation de l'abonnement Shield Advanced**
Si vous êtes revendeur de AWS chaînes, contactez l'équipe chargée de votre compte pour obtenir des informations et des conseils. Ces informations de facturation sont destinées aux clients qui ne sont pas des revendeurs de AWS canaux.
Pour tous les autres, les directives d'abonnement et de facturation suivantes s'appliquent :
+ Pour les comptes membres d'une AWS Organizations organisation, facturez AWS les abonnements Shield Advanced sur le compte payeur de l'organisation, que le compte payeur lui-même soit souscrit ou non.
+ Lorsque vous souscrivez plusieurs comptes appartenant à la même [famille de comptes de facturation AWS Organizations consolidée](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html), un seul prix d'abonnement couvre tous les comptes souscrits de la famille. L'organisation doit être propriétaire de Comptes AWS la totalité de ses ressources.
+ Lorsque vous souscrivez plusieurs comptes pour plusieurs organisations, vous pouvez toujours payer les mêmes frais d'abonnement pour l'ensemble des organisations, des comptes et des ressources, à condition que vous les possédiez tous. Contactez votre responsable de compte ou le service d' AWS assistance et demandez une exemption des frais AWS Shield Advanced d'abonnement pour toutes les organisations sauf une.
Pour obtenir des informations détaillées sur les prix et des exemples, consultez la section [AWS Shield Tarification](https://aws.amazon.com/shield/pricing/).
**Topics**
# Liste des AWS ressources qui AWS Shield Advanced protègent
**Note**
Les protections Shield Advanced ne sont activées que pour les ressources que vous avez explicitement spécifiées dans Shield Advanced ou que vous protégez par le biais d'une politique AWS Firewall Manager Shield Advanced. Shield Advanced ne protège pas automatiquement vos ressources.
Vous pouvez utiliser Shield Advanced pour une surveillance et une protection avancées avec les types de ressources suivants :
+ CloudFront Distributions Amazon. Pour CloudFront un déploiement continu, Shield Advanced protège toute distribution intermédiaire associée à une distribution principale protégée.
+ Zones hébergées Amazon Route 53.
+ AWS Global Accelerator accélérateurs standard.
+ Adresses IP Amazon EC2 Elastic. Shield Advanced protège les ressources associées aux adresses IP Elastic protégées.
+ EC2 Instances Amazon, par association à des adresses IP Amazon EC2 Elastic.
+ Les équilibreurs de charge Elastic Load Balancing (ELB) suivants :
+ Équilibreurs de charge des applications.
+ Équilibreurs Classic Load Balancer.
+ Équilibreurs de charge réseau, via des associations aux adresses IP Amazon EC2 Elastic.
Pour plus d'informations sur les protections pour ces types de ressources, consultez[Liste des ressources qui AWS Shield Advanced protègent](ddos-protections-by-resource-type.md).
# AWS Shield Advanced capacités et options
AWS Shield Advanced l'abonnement inclut les fonctionnalités et options suivantes. Elles complètent les capacités de détection et d'atténuation du DDo S dont vous bénéficiez déjà AWS.
+ **AWS WAF intégration** — Shield Advanced utilise le AWS WAF Web ACLs, les règles et les groupes de règles dans le cadre de ses protections de la couche applicative. Pour plus d'informations sur AWS WAF, voir[Comment AWS WAF fonctionne](how-aws-waf-works.md).
**Note**
Votre abonnement Shield Advanced couvre les coûts liés à l'utilisation des AWS WAF fonctionnalités standard pour les ressources que vous protégez avec Shield Advanced. Les AWS WAF frais standard couverts par vos protections Shield Advanced sont le coût par pack de protection (ACL Web), le coût par règle et le prix de base par million de demandes d'inspection de requêtes Web, jusqu'à 1 500 WCUs et jusqu'à la taille corporelle par défaut.
L'activation de l'atténuation automatique de la couche d'application DDo S de Shield Advanced ajoute un groupe de règles à votre pack de protection (ACL Web) qui utilise 150 unités de capacité ACL Web (WCUs). Ils sont WCUs pris en compte dans l'utilisation de la WCU dans votre pack de protection (ACL Web). Pour plus d’informations, consultez [Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md), [Protection de la couche applicative avec le groupe de règles Shield Advanced](ddos-automatic-app-layer-response-rg.md) et [Unités de capacité Web ACL (WCUs) en AWS WAF](aws-waf-capacity-units.md).
Votre abonnement à Shield Advanced ne couvre pas l'utilisation de AWS WAF ressources que vous ne protégez pas à l'aide de Shield Advanced. Il ne couvre pas non plus les AWS WAF coûts non standard supplémentaires liés aux ressources protégées. Des exemples de AWS WAF coûts non standard sont ceux liés au contrôle des robots, à l'action des CAPTCHA règles, aux sites Web ACLs qui en utilisent plus de 1 500 WCUs et à l'inspection du corps de la demande au-delà de la taille par défaut. La liste complète est disponible sur la page de AWS WAF tarification. Votre abonnement à Shield Advanced inclut l'accès au groupe Layer 7 Anti- DDo S Amazon Managed Rule. Dans le cadre de votre abonnement, vous recevrez jusqu'à 50 milliards de demandes adressées aux AWS WAF ressources protégées de Shield Advanced au cours d'un mois civil. Les demandes supérieures à 50 milliards seront facturées conformément à la page de AWS Shield Advanced tarification.
Pour obtenir des informations complètes et des exemples de tarification, consultez [Shield Pricing](https://aws.amazon.com/shield/pricing/) and [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/).
+ **Atténuation automatique de la couche d'application DDo S** : vous pouvez configurer Shield Advanced pour qu'il réponde automatiquement afin d'atténuer les attaques de la couche application (couche 7) contre vos ressources protégées. Grâce à l'atténuation automatique, Shield Advanced impose une limite de AWS WAF débit aux demandes provenant de sources DDo S connues, et ajoute et gère automatiquement des AWS WAF protections personnalisées en réponse aux attaques DDo S détectées. Vous pouvez configurer l'atténuation automatique pour compter ou bloquer les requêtes Web qui font partie d'une attaque.
Pour de plus amples informations, veuillez consulter [Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md).
+ **Détection basée sur l'état de santé** : vous pouvez utiliser les contrôles de santé d'Amazon Route 53 avec Shield Advanced pour détecter et atténuer les événements. Les bilans de santé surveillent votre application conformément à vos spécifications, signalant qu'elle est saine lorsque vos spécifications sont respectées et qu'elle n'est pas saine lorsqu'elles ne le sont pas. L'utilisation de tests de santé avec Shield Advanced permet d'éviter les faux positifs et de détecter et d'atténuer plus rapidement les problèmes de santé d'une ressource protégée. Vous pouvez utiliser la détection basée sur l'état de santé pour tous les types de ressources, à l'exception des zones hébergées Route 53. L'engagement proactif de Shield Advanced n'est disponible que pour les ressources dont la détection basée sur l'état de santé est activée.
Pour de plus amples informations, veuillez consulter [Détection basée sur l'état à l'aide de contrôles de santé avec Shield Advanced et Route 53](ddos-advanced-health-checks.md).
+ **Groupes de protection** : vous pouvez utiliser des groupes de protection pour créer des regroupements logiques de vos ressources protégées, afin d'améliorer la détection et l'atténuation du groupe dans son ensemble. Vous pouvez définir les critères d'appartenance à un groupe de protection afin que les ressources nouvellement protégées soient automatiquement incluses. Une ressource protégée peut appartenir à plusieurs groupes de protection.
Pour de plus amples informations, veuillez consulter [Regrouper vos AWS Shield Advanced protections](ddos-protection-groups.md).
+ **Visibilité améliorée sur DDo les événements et les attaques S** — Shield Advanced vous donne accès à des statistiques et à des rapports avancés en temps réel pour une visibilité étendue des événements et des attaques visant vos AWS ressources protégées. Vous pouvez accéder à ces informations via l'API et la console Shield Advanced, ainsi que via Amazon CloudWatch Metrics.
Pour de plus amples informations, veuillez consulter [Visibilité des événements DDo S avec Shield Advanced](ddos-viewing-events.md).
+ **Gestion centralisée des protections Shield Advanced par AWS Firewall Manager** : vous pouvez utiliser Firewall Manager pour appliquer automatiquement les protections Shield Advanced à vos nouveaux comptes et ressources et pour déployer des AWS WAF règles sur votre site Web ACLs. Les politiques de protection de Firewall Manager Shield Advanced sont incluses sans frais supplémentaires pour les clients de Shield Advanced. Vous pouvez également centraliser vos activités de surveillance Shield Advanced pour vos comptes en utilisant Firewall Manager avec une rubrique Amazon Simple Notification Service (SNS) ou. AWS Security Hub CSPM
Pour plus d'informations sur l'utilisation de Firewall Manager pour gérer les protections Shield Advanced, consultez [AWS Firewall Manager](fms-chapter.md) et[Utilisation des AWS Shield Advanced politiques dans Firewall Manager](shield-policies.md). Pour plus d'informations sur la tarification de Firewall Manager, consultez la section [AWS Firewall Manager Tarification](https://aws.amazon.com/firewall-manager/pricing/).
+ **AWS Shield Response Team (SRT)** — La SRT possède une vaste expérience dans le domaine de la protection AWS d'Amazon.com et de ses filiales. En tant que AWS Shield Advanced client, vous pouvez contacter le SRT à tout moment pour obtenir de l'aide lors d'une attaque DDo S affectant la disponibilité de votre application. Vous pouvez également travailler avec le SRT pour créer et gérer des mesures d'atténuation personnalisées pour vos ressources. Pour utiliser les services du SRT, vous devez également être abonné au plan [Business Support ou au plan](https://aws.amazon.com/premiumsupport/business-support/) [Enterprise Support](https://aws.amazon.com/premiumsupport/enterprise-support/).
Pour de plus amples informations, veuillez consulter [Réponse aux événements Managed DDo S avec le support de la Shield Response Team (SRT)](ddos-srt-support.md).
+ **Engagement proactif** : grâce à un engagement proactif, la Shield Response Team (SRT) vous contacte directement si le bilan de santé Amazon Route 53 que vous avez associé à votre ressource protégée ne fonctionne pas correctement lors d'un événement détecté par Shield Advanced. Cela vous permet de communiquer plus rapidement avec des experts lorsque la disponibilité de votre application est susceptible d'être affectée par une attaque présumée.
Pour de plus amples informations, veuillez consulter [Mettre en place un engagement proactif pour que le SRT vous contacte directement](ddos-srt-proactive-engagement.md).
+ **Opportunités de protection** des coûts — Shield Advanced offre une certaine protection contre les pics de votre AWS facture qui pourraient résulter d'une attaque DDo S contre vos ressources protégées. Cela peut inclure une couverture en cas de hausse des frais d'utilisation du Shield Advanced data transfer out (DTO). Shield Advanced fournit une protection contre les coûts sous forme de crédits de service Shield Advanced.
Pour de plus amples informations, veuillez consulter [Demande de crédit AWS Shield Advanced après une attaque](ddos-request-service-credit.md).
# Décider s'il convient de souscrire à des protections supplémentaires AWS Shield Advanced et d'appliquer des protections supplémentaires
Consultez les scénarios décrits dans cette section pour vous aider à choisir les comptes auxquels vous souhaitez vous abonner AWS Shield Advanced et les domaines dans lesquels appliquer des protections supplémentaires. Avec Shield Advanced, vous payez un abonnement mensuel pour tous les comptes créés sous un compte de facturation consolidé, plus les frais d'utilisation basés sur le Go de données transférées. Pour plus d'informations sur les tarifs de Shield Advanced, consultez la section [AWS Shield Advanced Tarification](https://aws.amazon.com/shield/pricing/).
Pour protéger une application et ses ressources avec Shield Advanced, vous devez abonner les comptes qui gèrent l'application à Shield Advanced, puis vous ajoutez des protections aux ressources de l'application. Pour plus d'informations sur la souscription de comptes et la protection des ressources, consultez[Con AWS Shield Advanced figuration](getting-started-ddos.md).
**Abonnements et AWS WAF coûts de Shield Advanced**
Votre abonnement Shield Advanced couvre les coûts liés à l'utilisation des AWS WAF fonctionnalités standard pour les ressources que vous protégez avec Shield Advanced. Les AWS WAF frais standard couverts par vos protections Shield Advanced sont le coût par pack de protection (ACL Web), le coût par règle et le prix de base par million de demandes d'inspection de requêtes Web, jusqu'à 1 500 WCUs et jusqu'à la taille corporelle par défaut.
L'activation de l'atténuation automatique de la couche d'application DDo S de Shield Advanced ajoute un groupe de règles à votre pack de protection (ACL Web) qui utilise 150 unités de capacité ACL Web (WCUs). Ils sont WCUs pris en compte dans l'utilisation de la WCU dans votre pack de protection (ACL Web). Pour plus d’informations, consultez [Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md), [Protection de la couche applicative avec le groupe de règles Shield Advanced](ddos-automatic-app-layer-response-rg.md) et [Unités de capacité Web ACL (WCUs) en AWS WAF](aws-waf-capacity-units.md).
Votre abonnement à Shield Advanced ne couvre pas l'utilisation de AWS WAF ressources que vous ne protégez pas à l'aide de Shield Advanced. Il ne couvre pas non plus les AWS WAF coûts non standard supplémentaires liés aux ressources protégées. Des exemples de AWS WAF coûts non standard sont ceux liés au contrôle des robots, à l'action des CAPTCHA règles, aux sites Web ACLs qui en utilisent plus de 1 500 WCUs et à l'inspection du corps de la demande au-delà de la taille par défaut. La liste complète est disponible sur la page de AWS WAF tarification. Votre abonnement à Shield Advanced inclut l'accès au groupe Layer 7 Anti- DDo S Amazon Managed Rule. Dans le cadre de votre abonnement, vous recevrez jusqu'à 50 milliards de demandes adressées aux AWS WAF ressources protégées de Shield Advanced au cours d'un mois civil. Les demandes supérieures à 50 milliards seront facturées conformément à la page de AWS Shield Advanced tarification.
Pour obtenir des informations complètes et des exemples de tarification, consultez [Shield Pricing](https://aws.amazon.com/shield/pricing/) and [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/).
**Facturation de l'abonnement Shield Advanced**
Si vous êtes revendeur de AWS chaînes, contactez l'équipe chargée de votre compte pour obtenir des informations et des conseils. Ces informations de facturation sont destinées aux clients qui ne sont pas des revendeurs de AWS canaux.
Pour tous les autres, les directives d'abonnement et de facturation suivantes s'appliquent :
+ Pour les comptes membres d'une AWS Organizations organisation, facturez AWS les abonnements Shield Advanced sur le compte payeur de l'organisation, que le compte payeur lui-même soit souscrit ou non.
+ Lorsque vous souscrivez plusieurs comptes appartenant à la même [famille de comptes de facturation AWS Organizations consolidée](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html), le prix d'abonnement unique couvre tous les comptes souscrits de la famille. L'organisation doit être propriétaire de Comptes AWS la totalité de ses ressources.
+ Lorsque vous souscrivez plusieurs comptes pour plusieurs organisations, vous pouvez toujours payer les mêmes frais d'abonnement pour l'ensemble des organisations, des comptes et des ressources, à condition que vous les possédiez tous. Contactez votre responsable de compte ou le service d' AWS assistance et demandez une exemption des frais AWS Shield Advanced d'abonnement pour toutes les organisations sauf une.
Pour obtenir des informations détaillées sur les prix et des exemples, consultez la section [AWS Shield Tarification](https://aws.amazon.com/shield/pricing/).
**Identification des applications à protéger**
Envisagez d'implémenter les protections Shield Advanced pour les applications nécessitant l'un des éléments suivants :
+ Disponibilité garantie pour les utilisateurs de l'application.
+ Accès rapide à des experts en mitigation DDo S si l'application est affectée par une attaque DDo S.
+ Prise de conscience du AWS fait que l'application peut être affectée par une attaque DDo S et notification des attaques par vos équipes chargées de la sécurité ou des opérations AWS et notification de leur escalade.
+ La prévisibilité des coûts de votre cloud, y compris lorsqu'une attaque DDo S affecte votre utilisation des AWS services.
Si une application ou ses ressources nécessitent l'un des éléments ci-dessus, pensez à créer des abonnements pour les comptes associés.
**Identifier les ressources à protéger**
Pour chaque compte abonné, pensez à ajouter une protection Shield Advanced à chaque ressource présentant l'une des caractéristiques suivantes :
+ La ressource est destinée aux utilisateurs externes sur Internet.
+ La ressource est exposée à Internet et fait également partie d'une application critique. Tenez compte de chaque ressource exposée, que vous souhaitiez ou non qu'elle soit accessible aux utilisateurs sur Internet.
+ La ressource est protégée par une ACL AWS WAF Web.
Pour en savoir plus sur la création et la gestion de protections pour vos ressources, consultez[Protection des ressources dans AWS Shield Advanced](ddos-resource-protections.md).
En outre, suivez les recommandations de ce guide pour vous assurer que vous concevez votre application en fonction de la résilience DDo S et que vous avez correctement configuré les fonctionnalités de Shield Advanced pour des protections optimales.
# Exemples d'attaques DDo S
AWS Shield Advanced fournit une protection étendue contre de nombreux types d'attaques.
La liste suivante décrit certains types d'attaques courants :
**Attaques par réflexion UDP (User Datagram Protocol)**
Dans les attaques par réflexion UDP, un attaquant peut usurper la source d'une requête et utiliser le protocole UDP pour obtenir une réponse importante de la part du serveur. Le trafic réseau supplémentaire dirigé vers l'adresse IP usurpée et attaquée peut ralentir le serveur ciblé et empêcher les utilisateurs finaux légitimes d'accéder aux ressources nécessaires.
**Inondation TCP SYN**
Le but d'une attaque TCP SYN flood est d'épuiser les ressources disponibles d'un système en laissant les connexions dans un état semi-ouvert. Lorsqu'un utilisateur se connecte à un service TCP tel qu'un serveur Web, le client envoie un paquet TCP SYN. Le serveur retourne un accusé de réception et le client retourne son propre accusé de réception, ce qui termine la connexion en trois temps. Lors d'un afflux TCP SYN, le troisième accusé de réception n'est jamais renvoyé et le serveur attend une réponse. Cela peut empêcher d'autres utilisateurs de se connecter au serveur.
**Inondation de requêtes DNS**
Lors d'un afflux de requêtes DNS, un attaquant utilise plusieurs requêtes DNS pour épuiser les ressources d'un serveur DNS. AWS Shield Advanced peut aider à fournir une protection contre les attaques par inondation de requêtes DNS sur les serveurs DNS Route 53.
**Attaques par Cache Busting/inondation HTTP (couche 7)**
Dans le cas d'une inondation HTTP, y compris `GET` et `POST` d'une inondation, un attaquant envoie plusieurs requêtes HTTP qui semblent provenir d'un utilisateur réel de l'application Web. Les attaques par Cache Busting constituent un type d'inondation HTTP qui utilise des variations dans la chaîne de requête de la requête HTTP qui empêchent l'utilisation de contenu mis en cache sur un emplacement périphérique et qui forcent le contenu à être fourni à partir du serveur web d'origine, ce qui entraîne des contraintes supplémentaires et potentiellement dangereuses sur le serveur web d'origine.
# Comment AWS Shield détecte les événements
AWS exploite des systèmes de détection de niveau de service pour le AWS réseau et les AWS services individuels, afin de garantir leur disponibilité lors d'une attaque DDo S. En outre, les systèmes de détection au niveau des ressources surveillent chaque AWS ressource individuelle pour s'assurer que le trafic vers la ressource reste dans les limites des paramètres attendus. Cette combinaison protège à la fois les AWS ressources et les AWS services ciblés, en appliquant des mesures d'atténuation qui suppriment les paquets défectueux connus, mettent en évidence le trafic potentiellement malveillant et hiérarchisent le trafic provenant des utilisateurs finaux.
Les événements détectés apparaissent dans les résumés des événements de votre Shield Advanced, les détails des attaques et CloudWatch les statistiques Amazon sous forme de nom du vecteur d'attaque DDo S ou comme `Volumetric` si l'évaluation était basée sur le volume de trafic plutôt que sur la signature. Pour plus d'informations sur les dimensions du vecteur d'attaque disponibles dans la `DDoSDetected` CloudWatch métrique, consultez[AWS Shield Advanced métriques](shield-metrics.md).
**Topics**
+ [AWS Shield logique de détection des menaces au niveau de l'infrastructure (couche 3 et couche 4)](ddos-event-detection-infrastructure.md)
+ [Shield : logique de détection avancée pour les menaces de la couche application (couche 7)](ddos-event-detection-application.md)
+ [Shield : logique de détection avancée pour plusieurs ressources dans une application](ddos-event-detection-multiple-resources.md)
# AWS Shield logique de détection des menaces au niveau de l'infrastructure (couche 3 et couche 4)
Cette page explique le fonctionnement de la détection d'événements pour les couches d'infrastructure (réseau et transport).
La logique de détection utilisée pour protéger les AWS ressources ciblées contre les attaques DDo S dans les couches d'infrastructure (couche 3 et couche 4) dépend du type de ressource et du fait que la ressource est protégée ou non AWS Shield Advanced.
**Détection pour Amazon CloudFront et Amazon Route 53**
Lorsque vous servez votre application Web avec CloudFront et Route 53, tous les paquets envoyés à l'application sont inspectés par un système d'atténuation DDo S entièrement intégré, qui n'introduit aucune latence observable. DDoLes attaques contre les CloudFront distributions et les zones hébergées Route 53 sont atténuées en temps réel. Ces protections s'appliquent indépendamment du fait que vous les utilisiez ou non AWS Shield Advanced.
Suivez les meilleures pratiques en utilisant CloudFront Route 53 comme point d'entrée de votre application Web dans la mesure du possible pour détecter et atténuer les événements DDo S le plus rapidement possible.
**Détection pour AWS Global Accelerator les services régionaux**
La détection au niveau des ressources protège les accélérateurs AWS Global Accelerator standard et les ressources lancés dans les AWS régions, tels que les équilibreurs de charge classiques, les équilibreurs de charge d'application et les adresses IP élastiques (). EIPs Ces types de ressources sont surveillés pour détecter les élévations de trafic susceptibles d'indiquer la présence d'une attaque DDo S nécessitant une atténuation. Chaque minute, le trafic vers chaque AWS ressource est évalué. Si le trafic vers une ressource est élevé, des contrôles supplémentaires sont effectués pour mesurer la capacité de la ressource.
Shield effectue les contrôles standard suivants :
+ Instances **Amazon Elastic Compute Cloud (Amazon EC2), EIP associées aux instances Amazon EC2** — Shield récupère la capacité de la ressource protégée. La capacité dépend du type d'instance cible, de la taille de l'instance et d'autres facteurs tels que le fait que l'instance utilise ou non une mise en réseau améliorée.
+ Équilibreurs de **charge classiques et équilibreurs de charge d'application : Shield récupère la capacité du nœud d'équilibreur** de charge ciblé.
+ **EIPs connecté aux équilibreurs de charge réseau** — Shield récupère la capacité de l'équilibreur de charge ciblé. La capacité est indépendante de la configuration de groupe de l'équilibreur de charge cible.
+ **AWS Global Accelerator accélérateurs standard** — Shield récupère la capacité, qui est basée sur la configuration du terminal.
Ces évaluations portent sur plusieurs dimensions du trafic réseau, telles que le port et le protocole. Si la capacité de la ressource ciblée est dépassée, Shield place une atténuation DDo S. Les mesures d'atténuation mises en place par Shield réduiront le trafic DDo S, mais ne l'élimineront peut-être pas. Shield peut également mettre en place une mesure d'atténuation si une fraction de la capacité de la ressource est dépassée sur une dimension de trafic compatible avec les vecteurs d'attaque DDo S connus. Shield applique à cette atténuation une durée de vie limitée (TTL), qu'elle prolonge tant que l'attaque est en cours.
**Note**
Les mesures d'atténuation mises en place par Shield réduiront le trafic DDo S, mais ne l'élimineront peut-être pas. Vous pouvez compléter Shield avec des solutions telles AWS Network Firewall qu'un pare-feu sur l'hôte, iptables afin d'empêcher votre application de traiter le trafic qui n'est pas valide pour votre application ou qui n'a pas été généré par des utilisateurs finaux légitimes.
Les protections Shield Advanced ajoutent les éléments suivants aux activités de détection Shield existantes :
+ **Seuils de détection inférieurs** — Shield Advanced place les mesures d'atténuation à la moitié de la capacité calculée. Cela permet d'atténuer plus rapidement les attaques qui s'intensifient lentement et d'atténuer les attaques dont la signature volumétrique est plus ambiguë.
+ **Protection contre les attaques intermittentes** — Shield Advanced propose des mesures d'atténuation liées à l'augmentation exponentielle de la durée de vie (TTL), en fonction de la fréquence et de la durée des attaques. Cela permet de maintenir les mesures d'atténuation en place plus longtemps lorsqu'une ressource est fréquemment ciblée et lorsqu'une attaque se produit en rafales brèves.
+ **Détection basée sur l'état de santé** : lorsque vous associez un bilan de santé Route 53 à une ressource protégée par Shield Advanced, l'état du bilan de santé est utilisé dans la logique de détection. Lors d'un événement détecté, si le bilan de santé est correct, Shield Advanced doit être plus sûr qu'il s'agit d'une attaque avant de mettre en place une mesure d'atténuation. Si, au contraire, le bilan de santé n'est pas satisfaisant, Shield Advanced peut mettre en place une mesure d'atténuation avant même que la confiance ne soit établie. Cette fonctionnalité permet d'éviter les faux positifs et de réagir plus rapidement aux attaques qui affectent votre application. Pour plus d'informations sur les contrôles de santé réalisés avec Shield Advanced, consultez[Détection basée sur l'état à l'aide de contrôles de santé avec Shield Advanced et Route 53](ddos-advanced-health-checks.md).
# Shield : logique de détection avancée pour les menaces de la couche application (couche 7)
Cette page explique le fonctionnement de la détection d'événements pour la couche application.
AWS Shield Advanced fournit une détection de la couche d'application Web pour les CloudFront distributions Amazon protégées et les équilibreurs de charge d'application. Lorsque vous protégez ces types de ressources avec Shield Advanced, vous pouvez associer une ACL AWS WAF Web à votre protection pour permettre la détection de la couche d'application Web. Shield Advanced utilise les données de demande pour l'ACL Web associée et crée une base de trafic pour votre application. La détection de la couche d'application Web repose sur l'intégration native entre Shield Advanced et AWS WAF. Pour en savoir plus sur les protections de la couche application, notamment sur l'association d'une ACL AWS WAF Web à une ressource protégée Shield Advanced, consultez[Protection de la couche applicative (couche 7) avec AWS Shield Advanced et AWS WAF](ddos-app-layer-protections.md).
Pour la détection de la couche d'application Web, Shield Advanced surveille le trafic des applications et le compare aux lignes de base historiques à la recherche d'anomalies. Cette surveillance couvre le volume total et la composition du trafic. Lors d'une attaque DDo S, nous nous attendons à ce que le volume et la composition du trafic changent, et Shield Advanced exige un écart statistiquement significatif dans les deux cas pour déclarer un événement.
Shield Advanced effectue ses mesures par rapport à des fenêtres temporelles historiques. Cette approche permet de réduire les notifications faussement positives résultant de modifications légitimes du volume de trafic ou de modifications du trafic correspondant à un schéma attendu, comme une vente proposée à la même heure chaque jour.
**Note**
Évitez les faux positifs dans vos protections Shield Advanced en laissant à Shield Advanced le temps d'établir des bases de référence représentant des modèles de trafic normaux et légitimes. Shield Advanced commence à collecter des informations pour sa base de référence lorsque vous associez une ACL Web à votre ressource protégée. Associez une ACL Web à votre ressource protégée au moins 24 heures avant tout événement planifié susceptible de provoquer des modèles inhabituels dans votre trafic Web. La détection de la couche d'application Web Shield Advanced est plus précise lorsqu'elle a observé 30 jours de trafic normal.
Le temps nécessaire à Shield Advanced pour détecter un événement dépend de l'évolution du volume de trafic observée. Pour les variations de volume plus faibles, Shield Advanced observe le trafic pendant une période plus longue, afin de s'assurer qu'un événement se produit. Pour les variations de volume plus importantes, Shield Advanced détecte et signale un événement plus rapidement.
Une règle basée sur le taux dans votre ACL Web, qu'elle soit ajoutée par vous-même ou par la fonction d'atténuation automatique de la couche d'application Shield Advanced, peut atténuer une attaque avant qu'elle n'atteigne un niveau détectable. Pour plus d'informations sur l'atténuation automatique de la couche d'application DDo S, consultez[Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md).
**Note**
Vous pouvez concevoir votre application de manière à ce qu'elle évolue en réponse à un trafic ou à une charge élevés afin de garantir qu'elle ne soit pas affectée par de faibles volumes de demandes. Avec Shield Advanced, vos ressources protégées sont couvertes par une protection des coûts. Cela vous permet de vous protéger contre les augmentations inattendues de votre facture cloud qui pourraient survenir à la suite d'une attaque DDo S. Pour en savoir plus sur la protection des coûts Shield Advanced, consultez[Demande de crédit AWS Shield Advanced après une attaque](ddos-request-service-credit.md).
# Shield : logique de détection avancée pour plusieurs ressources dans une application
Cette page explique le fonctionnement de la détection d'événements pour plusieurs ressources d'une application.
Vous pouvez utiliser AWS Shield Advanced des groupes de protection pour créer des ensembles de ressources protégées faisant partie de la même application. Vous pouvez choisir les ressources protégées à placer dans un groupe ou indiquer que toutes les ressources du même type doivent être traitées comme un seul groupe. Par exemple, vous pouvez créer un groupe de tous les équilibreurs de charge d'application. Lorsque vous créez un groupe de protection, la détection Shield Advanced agrège tout le trafic des ressources protégées au sein du groupe. Cela est utile si vous disposez de nombreuses ressources dont chacune génère un faible volume de trafic, mais dont le volume agrégé est important. Vous pouvez également utiliser des groupes de protection pour préserver les lignes de base des applications, dans le cas de déploiements bleu-vert où le trafic est transféré entre des ressources protégées.
Vous pouvez choisir d'agréger le trafic au sein de votre groupe de protection de l'une des manières suivantes :
+ **Somme** : cette agrégation combine l'ensemble du trafic entre les ressources du groupe de protection. Vous pouvez utiliser cette agrégation pour garantir que les ressources nouvellement créées disposent d'une base de référence existante et pour réduire la sensibilité de détection, ce qui permet d'éviter les faux positifs.
+ **Moyenne** : cette agrégation utilise la moyenne de l'ensemble du trafic au sein du groupe de protection. Vous pouvez utiliser cette agrégation pour les applications où le trafic entre les ressources est uniforme, comme les équilibreurs de charge.
+ **Max** : cette agrégation utilise le trafic le plus élevé de toutes les ressources du groupe de protection. Vous pouvez utiliser cette agrégation lorsqu'il existe plusieurs niveaux d'une application dans un groupe de protection. Par exemple, vous pouvez avoir un groupe de protection qui inclut une CloudFront distribution, son origine d'Application Load Balancer et les cibles d'instance Amazon EC2 de l'Application Load Balancer.
Vous pouvez également utiliser des groupes de protection pour améliorer la vitesse à laquelle Shield Advanced met en place des mesures d'atténuation, en cas d'attaques ciblant plusieurs accélérateurs Elastic IPs ou AWS Global Accelerator standard connectés à Internet. Lorsqu'une ressource d'un groupe de protection est ciblée, Shield Advanced établit la confiance des autres ressources du groupe. Cela met la détection Shield Advanced en alerte et peut réduire le temps nécessaire pour créer des mesures d'atténuation supplémentaires.
Pour en savoir plus sur les groupes de protection, consultez[Regrouper vos AWS Shield Advanced protections](ddos-protection-groups.md).
# Comment AWS Shield atténuer les événements
Cette page explique le fonctionnement de AWS Shield l'atténuation des événements.
La logique d'atténuation qui protège votre application peut varier en fonction de l'architecture de votre application. Lorsque vous protégez une application Web avec Amazon CloudFront et Amazon Route 53, vous bénéficiez de mesures d'atténuation spécifiques aux cas d'utilisation du Web et du DNS et qui protègent l'ensemble du trafic lié aux services. Lorsque le point d'entrée de votre application est une ressource qui s'exécute dans une AWS région, la logique d'atténuation varie en fonction du service, du type de ressource et de l'utilisation que vous en faites AWS Shield Advanced.
AWS DDoLes systèmes d'atténuation S sont développés par les ingénieurs de Shield et ils sont étroitement intégrés aux AWS services. Les ingénieurs prennent en compte les aspects de votre architecture tels que la capacité et l'état de santé des ressources ciblées. Les ingénieurs de Shield surveillent en permanence l'efficacité et les performances des systèmes d'atténuation DDo S et sont en mesure de réagir rapidement lorsque de nouvelles menaces sont découvertes ou anticipées.
Vous pouvez concevoir votre application de manière à ce qu'elle évolue en réponse à un trafic ou à une charge élevés, afin de garantir qu'elle ne soit pas affectée par de faibles volumes de demandes. Si vous utilisez Shield Advanced pour protéger vos ressources, vous bénéficiez d'une couverture contre les augmentations inattendues de votre facture cloud qui pourraient survenir à la suite d'une attaque DDo S.
**Atténuations liées aux infrastructures**
Pour les attaques au niveau de l'infrastructure, les systèmes d'atténuation AWS Shield DDo S sont présents à la frontière du AWS réseau et aux emplacements AWS périphériques. La mise en place de plusieurs niveaux de contrôles de sécurité dans l'ensemble de l' AWS infrastructure fournit defense-in-depth à vos applications cloud.
Shield gère des systèmes d'atténuation DDo S à tous les points d'entrée depuis Internet. Lorsque Shield détecte une attaque DDo S, pour chaque point d'entrée, il redirige le trafic via les systèmes d'atténuation DDo S situés au même endroit. Cela n'introduit aucune latence supplémentaire observable et fournit une capacité d'atténuation de plus de TeraBits 100 Tbit/s dans toutes les AWS régions et tous les emplacements périphériques. Shield protège la disponibilité de vos ressources sans rediriger le trafic vers des centres de nettoyage externes ou distants, ce qui pourrait augmenter la latence.
+ À la frontière du AWS réseau, quel que soit le AWS service ou la ressource, les systèmes d'atténuation DDo S atténuent les attaques au niveau de l'infrastructure provenant d'Internet. Les systèmes effectuent leurs mesures d'atténuation lorsqu'ils sont signalés par le système de détection du Shield ou par un ingénieur de la Shield Response Team (SRT).
+ Sur les sites AWS périphériques, les systèmes d'atténuation DDo S inspectent en permanence chaque paquet transféré vers les CloudFront distributions Amazon et les zones hébergées Amazon Route 53, quelle que soit leur origine. Au besoin, les systèmes appliquent des mesures d'atténuation spécifiquement conçues pour le trafic Web et DNS. Un autre avantage de l'utilisation d'Amazon CloudFront et d'Amazon Route 53 pour protéger vos applications Web est que les attaques DDo S sont immédiatement atténuées, sans qu'un signal de détection de Shield ne soit nécessaire.
**Atténuations de la couche applicative**
Shield Advanced fournit des mesures d'atténuation de la couche d'application Web pour les CloudFront distributions Amazon et les équilibreurs de charge d'application pour lesquels vous avez activé les protections Shield Advanced. Lorsque vous activez la protection, vous associez une ACL AWS WAF Web à la ressource afin de permettre la détection de la couche d'application Web. En outre, vous avez la possibilité d'activer l'atténuation automatique de la couche d'application, qui demande à Shield Advanced de gérer les protections pour vous lors d'une attaque DDo S.
Shield fournit uniquement des mesures d'atténuation personnalisées pour les attaques de la couche application sur les ressources pour lesquelles vous avez activé Shield Advanced et l'atténuation automatique de la couche application. Grâce à l'atténuation automatique, Shield Advanced impose une limite de AWS WAF débit aux demandes provenant de sources DDo S connues, et ajoute et gère automatiquement des AWS WAF protections personnalisées en réponse aux attaques DDo S détectées. Pour des informations détaillées sur les mesures d'atténuation de ce type, consultez[Comment Shield Advanced gère l'atténuation automatique](ddos-automatic-app-layer-response-behavior.md).
Une règle basée sur le taux dans votre ACL Web, qu'elle soit ajoutée par vous-même ou par la fonction d'atténuation automatique de la couche d'application Shield Advanced, peut atténuer une attaque avant qu'elle n'atteigne un niveau détectable. Pour plus d'informations sur la détection, consultez[Shield : logique de détection avancée pour les menaces de la couche application (couche 7)](ddos-event-detection-application.md).
**Topics**
+ [Liste des fonctionnalités d'atténuation AWS Shield DDo S](ddos-event-mitigation-features.md)
+ [AWS Shield logique d'atténuation pour CloudFront et Route 53](ddos-event-mitigation-logic-continuous-inspection.md)
+ [AWS Shield logique d'atténuation pour les AWS régions](ddos-event-mitigation-logic-regions.md)
+ [AWS Shield logique d'atténuation pour les accélérateurs AWS Global Accelerator standard](ddos-event-mitigation-logic-gax.md)
+ [AWS Shield Advanced logique d'atténuation pour Elastic IPs](ddos-event-mitigation-logic-adv-eip.md)
+ [AWS Shield Advanced logique d'atténuation pour les applications Web](ddos-event-mitigation-logic-adv-web-app.md)
# Liste des fonctionnalités d'atténuation AWS Shield DDo S
Les principales caractéristiques de l'atténuation AWS Shield DDo S sont les suivantes :
+ **Validation des paquets** — Cela garantit que chaque paquet inspecté est conforme à une structure attendue et est valide pour son protocole. Les validations de protocole prises en charge incluent IP, TCP (y compris l'en-tête et les options), UDP, ICMP, DNS et NTP.
+ **Listes de contrôle d'accès (ACLs) et shapers** : une ACL évalue le trafic par rapport à des attributs spécifiques et supprime le trafic correspondant ou le mappe à un shaper. Le shaper limite le débit de paquets pour le trafic correspondant, en supprimant les paquets excédentaires afin de contenir le volume qui atteint la destination. AWS Shield les ingénieurs de détection et de Shield Response Team (SRT) peuvent fournir des allocations de débit dédiées au trafic attendu et des allocations de débit plus restrictives au trafic dont les attributs correspondent aux vecteurs d'attaque DDo S connus. Les attributs auxquels une ACL peut correspondre incluent le port, le protocole, les indicateurs TCP, l'adresse de destination, le pays source et les modèles arbitraires de la charge utile du paquet.
+ **Notation de suspicion** — Cela utilise les connaissances que Shield possède du trafic attendu pour appliquer un score à chaque paquet. Les paquets qui suivent de plus près les modèles de trafic dont on sait qu'ils sont bons se voient attribuer un score de suspicion inférieur. L'observation d'attributs de trafic défectueux connus peut augmenter le score de suspicion d'un paquet. Lorsqu'il est nécessaire de limiter le débit des paquets, Shield supprime d'abord les paquets présentant des scores de suspicion plus élevés. Cela permet à Shield d'atténuer les attaques DDo S connues et de type « jour zéro » tout en évitant les faux positifs.
+ **Proxy TCP SYN** : il fournit une protection contre les inondations TCP SYN en envoyant des cookies TCP SYN pour contester les nouvelles connexions avant de les autoriser à passer au service protégé. Le proxy TCP SYN fourni par Shield DDo S Mitigation est apatride, ce qui lui permet d'atténuer les plus grandes attaques TCP SYN connues sans atteindre l'état d'épuisement. Ceci est réalisé en intégrant les AWS services pour transférer l'état de connexion au lieu de maintenir un proxy continu entre le client et le service protégé. Le proxy TCP SYN est actuellement disponible sur Amazon et CloudFront Amazon Route 53.
+ **Distribution du débit** — Cela ajuste en permanence les valeurs du shaper par emplacement en fonction du schéma d'entrée du trafic vers une ressource protégée. Cela permet d'éviter de limiter le débit du trafic client susceptible de ne pas pénétrer uniformément sur le AWS réseau.
# AWS Shield logique d'atténuation pour CloudFront et Route 53
Cette page explique comment l'atténuation du Shield DDo S inspecte en permanence le trafic pour CloudFront la Route 53. Ces services fonctionnent à partir d'un réseau mondial d'emplacements AWS périphériques qui vous offrent un accès étendu à la capacité d'atténuation DDo S de Shield et fournissent votre application à partir d'une infrastructure plus proche de vos utilisateurs finaux.
**Important**
AWS Shield Advanced ne soutient pas CloudFront les locataires.
+ **CloudFront**— Les mesures d'atténuation du Shield DDo S autorisent uniquement le trafic valide pour les applications Web à passer vers le service. Cela fournit une protection automatique contre de nombreux vecteurs DDo S courants, tels que les attaques par réflexion UDP.
CloudFront maintient des connexions persistantes avec l'origine de votre application, les inondations TCP SYN sont automatiquement atténuées grâce à l'intégration avec la fonctionnalité proxy Shield TCP SYN, et le protocole TLS (Transport Layer Security) est interrompu à la périphérie. Ces fonctionnalités combinées garantissent que l'origine de votre application ne reçoit que des requêtes Web bien formulées et qu'elle est protégée contre les attaques de couche DDo S inférieure, les inondations de connexions et les abus du TLS.
CloudFront utilise une combinaison de direction du trafic DNS et de routage anycast. Ces techniques améliorent la résilience de votre application en atténuant les attaques à proximité de la source, en isolant les défaillances et en garantissant l'accès aux capacités nécessaires pour atténuer les plus importantes attaques connues.
+ Les mesures d'atténuation de **Route 53** — Shield autorisent uniquement les requêtes DNS valides à atteindre le service. Shield atténue le flot de requêtes DNS grâce à un score de suspicion qui donne la priorité aux requêtes dont le bon fonctionnement est avéré et ne donne pas la priorité aux requêtes contenant des attributs d'attaque S suspects ou connus. DDo
Route 53 utilise le shuffle sharding pour fournir un ensemble unique de quatre adresses IP de résolution à chaque zone hébergée, pour les deux et. IPv4 IPv6 Chaque adresse IP correspond à un sous-ensemble différent d'emplacements Route 53. Chaque sous-ensemble de localisation est constitué de serveurs DNS officiels qui ne recouvrent que partiellement l'infrastructure de tout autre sous-ensemble. Cela garantit que si une requête utilisateur échoue pour une raison quelconque, elle sera traitée avec succès lors d'une nouvelle tentative.
Route 53 utilise le routage anycast pour diriger les requêtes DNS vers l'emplacement périphérique le plus proche, en fonction de la proximité du réseau. Anycast répartit également le trafic DDo S vers de nombreux emplacements périphériques, ce qui empêche les attaques de se concentrer sur un seul emplacement.
Outre la rapidité de l'atténuation, CloudFront Route 53 fournit un accès étendu à la capacité distribuée à l'échelle mondiale de Shield. Pour tirer parti de ces fonctionnalités, utilisez ces services comme point d'entrée de vos applications Web dynamiques ou statiques.
Pour en savoir plus sur l'utilisation CloudFront de Route 53 pour protéger les applications Web, consultez [Comment protéger les applications Web dynamiques contre les attaques DDo S en utilisant Amazon CloudFront et 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/). Pour en savoir plus sur l'isolation des défauts sur la Route 53, consultez [une étude de cas sur l'isolation globale des défauts](https://aws.amazon.com/blogs/architecture/a-case-study-in-global-fault-isolation/).
# AWS Shield logique d'atténuation pour les AWS régions
Cette page explique le fonctionnement de la logique d'atténuation des événements du Shield dans AWS les régions.
Les ressources lancées dans les AWS régions sont protégées par des systèmes d'atténuation AWS Shield DDo S placés par le système de détection au niveau des ressources de Shield. Les ressources régionales incluent Elastic IPs (EIPs), les équilibreurs de charge classiques et les équilibreurs de charge d'application.
Avant de mettre en place une mesure d'atténuation, Shield identifie la ressource ciblée et sa capacité. Shield utilise cette capacité pour déterminer le trafic total maximal que ses mesures d'atténuation devraient permettre de transférer vers la ressource. Les listes de contrôle d'accès (ACLs) et les autres shapers inclus dans le cadre de l'atténuation peuvent réduire les volumes autorisés pour certains trafics, par exemple le trafic qui correspond à des vecteurs d'attaque DDo S connus ou qui ne devrait pas arriver en gros volume. Cela limite davantage le volume de trafic autorisé par les mesures d'atténuation pour les attaques par réflexion UDP ou pour le trafic TCP doté d'indicateurs TCP SYN ou FIN.
Shield détermine la capacité et place les mesures d'atténuation différemment pour chaque type de ressource.
+ Pour une instance Amazon EC2 ou une EIP attachée à une instance Amazon EC2, Shield calcule la capacité en fonction du type d'instance et d'autres attributs de l'instance, par exemple si la mise en réseau améliorée est activée sur l'instance.
+ Pour un Application Load Balancer ou un Classic Load Balancer, Shield calcule la capacité individuellement pour chaque nœud cible de l'équilibreur de charge. DDoLes mesures d'atténuation des attaques S pour ces ressources sont fournies par une combinaison de mesures d'atténuation du Shield DDo S et d'une mise à l'échelle automatique par l'équilibreur de charge. Lorsque la Shield Response Team (SRT) est engagée dans une attaque contre une ressource Application Load Balancer ou Classic Load Balancer, elle peut accélérer le dimensionnement comme mesure de protection supplémentaire.
+ Shield calcule la capacité de certaines AWS ressources en fonction de la capacité disponible de l' AWS infrastructure sous-jacente. Ces types de ressources incluent les équilibreurs de charge réseau (NLBs) et les ressources qui acheminent le trafic via des équilibreurs de charge de passerelle ou. AWS Network Firewall
**Note**
Protégez vos équilibreurs de charge réseau en les connectant à EIPs des dispositifs protégés par Shield Advanced. Vous pouvez travailler avec SRT pour créer des mesures d'atténuation personnalisées basées sur le trafic attendu et la capacité de l'application sous-jacente.
Lorsque Shield place une atténuation, les limites de taux initiales définies par Shield dans la logique d'atténuation sont appliquées de la même manière à chaque système d'atténuation Shield DDo S. Par exemple, si Shield place une atténuation avec une limite de 100 000 paquets par seconde (pps), il autorisera initialement 100 000 pps sur chaque site. Shield agrège ensuite en permanence les mesures d'atténuation pour déterminer le ratio réel de trafic, et utilise ce ratio pour adapter la limite de débit pour chaque site. Cela permet d'éviter les faux positifs et de garantir que les mesures d'atténuation ne sont pas trop permissives.
# AWS Shield logique d'atténuation pour les accélérateurs AWS Global Accelerator standard
Cette page explique comment fonctionne la logique d'atténuation des événements Shield pour les accélérateurs AWS Global Accelerator standard. Les mesures d'atténuation du Shield permettent uniquement au trafic valide d'atteindre les points de terminaison d'un accélérateur standard Global Accelerator.
Les accélérateurs standard sont déployés dans le monde entier et vous fournissent des adresses IP que vous pouvez utiliser pour acheminer le trafic vers les AWS ressources de n'importe quelle AWS région. Les limites de débit appliquées par Shield pour atténuer les effets des accélérateurs mondiaux sont basées sur les capacités des ressources vers lesquelles l'accélérateur standard achemine le trafic. Shield met en place des mesures d'atténuation lorsque le trafic total dépasse le débit déterminé, et également lorsqu'une fraction de ce taux est dépassée pour les vecteurs DDo S connus.
Lorsque vous configurez un accélérateur standard, vous définissez des groupes de points de terminaison pour chaque AWS région dans laquelle vous acheminerez le trafic pour votre application. Lorsque Shield place une atténuation, il calcule la capacité de chaque groupe de terminaux et met à jour les limites de débit de chaque système d'atténuation Shield DDo S en conséquence. Le tarif varie pour chaque emplacement, en fonction des hypothèses formulées par Shield quant à la manière dont le trafic sera acheminé d'Internet vers vos AWS ressources. La capacité d'un groupe de points de terminaison est calculée comme le nombre de ressources du groupe multiplié par la capacité la plus faible de toutes les ressources du groupe. À intervalles réguliers, Shield recalcule la capacité de votre application et met à jour les limites de débit selon les besoins.
**Note**
L'utilisation de cadrans de trafic pour modifier le pourcentage de trafic dirigé vers un groupe de terminaux ne change pas la façon dont Shield calcule ou distribue les limites de débit à ses systèmes d'atténuation DDo S. Si vous utilisez des numéros de trafic, configurez vos groupes de points de terminaison pour qu'ils se reflètent mutuellement en termes de type et de quantité de ressources. Cela permet de garantir que la capacité calculée par Shield est représentative des ressources qui acheminent le trafic pour votre application.
Pour plus d'informations sur les groupes de points de terminaison et les numéros de trafic dans Global Accelerator, consultez la section [Groupes de points de terminaison dans les accélérateurs AWS Global Accelerator standard](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoint-groups.html).
# AWS Shield Advanced logique d'atténuation pour Elastic IPs
Cette page explique comment fonctionne la logique d'atténuation des événements de Shield pour Elastic IPs with AWS Shield Advanced. Lorsque vous protégez une adresse IP élastique (EIP) avec AWS Shield Advanced, Shield Advanced améliore les mesures d'atténuation mises en place par Shield lors d'un événement DDo S.
Les systèmes d'atténuation Shield Advanced DDo S répliquent la configuration Network ACL (NACL) pour le sous-réseau public auquel l'EIP est associé. Par exemple, si votre NACL est configurée pour bloquer tout le trafic UDP, Shield Advanced fusionne cette règle dans les mesures d'atténuation mises en place par Shield.
Cette fonctionnalité supplémentaire peut vous aider à éviter les risques de disponibilité liés à un trafic non valide pour votre application. Vous pouvez également l'utiliser NACLs pour bloquer des adresses IP sources individuelles ou des plages CIDR d'adresses IP source. Cela peut être un outil d'atténuation utile pour les attaques DDo S qui ne sont pas distribuées. Il vous permet également de gérer facilement vos propres listes d'autorisations ou de bloquer les adresses IP qui ne devraient pas communiquer avec votre application, sans l'intervention d' AWS ingénieurs.
# AWS Shield Advanced logique d'atténuation pour les applications Web
AWS Shield Advanced utilisés AWS WAF pour atténuer les attaques contre la couche applicative Web. AWS WAF est inclus dans Shield Advanced sans frais supplémentaires.
**Protection standard de la couche d'application**
Lorsque vous protégez une CloudFront distribution Amazon ou une Application Load Balancer avec Shield Advanced, vous pouvez utiliser Shield Advanced pour associer une ACL AWS WAF Web à votre ressource protégée, si ce n'est pas déjà fait. Si vous n'avez pas encore configuré d'ACL Web, vous pouvez utiliser l'assistant de console Shield Advanced pour en créer une et y ajouter une règle basée sur le taux. Une règle basée sur le taux limite le nombre de demandes par fenêtre de cinq minutes pour chaque adresse IP, fournissant ainsi des protections de base contre les inondations de demandes au niveau de la couche application Web. Vous pouvez configurer le taux en commençant par 10. Pour de plus amples informations, veuillez consulter [Protection de la couche applicative avec AWS WAF Web ACLs et Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md).
Vous pouvez également utiliser le AWS WAF service pour gérer l'ACL Web. Vous pouvez ainsi étendre la configuration de l'ACL Web pour inspecter des composants de requêtes Web spécifiques pour détecter des correspondances ou des modèles de chaînes, ajouter un traitement personnalisé des demandes et des réponses et les comparer à la géolocalisation de l'origine de la demande. AWS WAF Pour plus d'informations sur AWS WAF les règles, consultez[AWS WAF règles](waf-rules.md).
**Atténuation automatique des couches applicatives**
Pour une protection améliorée, activez l'atténuation automatique de la couche d'application Shield Advanced. Avec cette option, Shield Advanced maintient une règle de limitation du AWS WAF débit pour les requêtes provenant de sources DDo S connues et fournit des mesures d'atténuation personnalisées pour les attaques DDo S détectées.
Lorsque Shield Advanced détecte une attaque contre une ressource protégée, il tente d'identifier une signature d'attaque qui isole le trafic d'attaque du trafic normal vers votre application. Shield Advanced évalue la signature d'attaque identifiée par rapport aux modèles de trafic historiques pour la ressource attaquée, ainsi que pour toute autre ressource associée à la même ACL Web.
Si Shield Advanced détermine que la signature d'attaque isole uniquement le trafic impliqué dans l'attaque DDo S, il implémente la signature dans des AWS WAF règles au sein de l'ACL Web associée. Vous pouvez demander à Shield Advanced de mettre en place des mesures d'atténuation qui ne prennent en compte que le trafic auquel il correspond ou qui le bloque, et vous pouvez modifier le paramètre à tout moment. Lorsque Shield Advanced détermine que ses règles d'atténuation ne sont plus nécessaires, il les supprime de l'ACL Web. Pour plus d'informations sur l'atténuation des événements au niveau de la couche application, consultez[Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md).
Pour plus d'informations sur les mesures d'atténuation de la couche d'application Shield Advanced, consultez[Protection de la couche applicative (couche 7) avec AWS Shield Advanced et AWS WAF](ddos-app-layer-protections.md).
# Création d'architectures résilientes aux systèmes DDo S de base avec Shield Advanced
Cette page explique la résilience du déni de service (DDoS) distribué et présente deux exemples d'architectures.
DDoLa résilience S est la capacité de l'architecture de votre application à résister aux attaques DDo S tout en continuant à servir les utilisateurs finaux légitimes. Une application hautement résiliente peut rester disponible pendant une attaque avec un impact minimal sur les indicateurs de performance tels que les erreurs ou la latence. Cette section présente quelques exemples d'architectures courants et décrit comment utiliser les fonctionnalités de détection et d'atténuation DDo S fournies par AWS Shield Advanced pour augmenter leur résilience DDo S.
Les exemples d'architectures présentés dans cette section mettent en évidence les AWS services qui offrent les meilleurs avantages en termes de résilience DDo S à vos applications déployées. Les avantages des services mis en avant sont les suivants :
+ **Accès à une capacité réseau distribuée dans le monde entier** — Les services Amazon CloudFront AWS Global Accelerator, et Amazon Route 53 vous fournissent un accès à Internet et à une capacité d'atténuation du DDo S sur l'ensemble du réseau périphérique AWS mondial. Cela est utile pour atténuer les attaques volumétriques de plus grande envergure, qui peuvent atteindre des térabits. Vous pouvez exécuter votre application dans n'importe quelle AWS région et utiliser ces services pour protéger la disponibilité et optimiser les performances pour vos utilisateurs légitimes.
+ **Protection contre les vecteurs d'attaque de la couche DDo S** des applications Web : il est préférable d'atténuer les attaques de la couche DDo S des applications Web en combinant l'échelle de l'application et un pare-feu d'application Web (WAF). Shield Advanced utilise les journaux d'inspection des requêtes Web AWS WAF pour détecter les anomalies qui peuvent être atténuées automatiquement ou via un engagement avec l'équipe de réponse du AWS Shield (SRT). L'atténuation automatique est disponible par le biais de règles AWS WAF basées sur le taux déployées ainsi que par le biais de l'atténuation automatique de la couche DDo S d'application Shield Advanced.
En plus de passer en revue ces exemples, consultez et suivez les meilleures pratiques applicables dans [AWS Best Practices for DDo S Resiliency.](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency)
**Topics**
+ [Exemple d'architecture de résilience Shield Advanced DDo S pour les applications Web courantes](ddos-resiliency-example-web.md)
+ [Exemple d'architecture de résilience Shield Advanced DDo S pour les applications TCP et UDP](ddos-resiliency-example-tcp-udp.md)
# Exemple d'architecture de résilience Shield Advanced DDo S pour les applications Web courantes
Cette page fournit un exemple d'architecture permettant d'optimiser la résilience contre les attaques DDo S avec des applications AWS Web.
Vous pouvez créer une application Web dans n'importe quelle AWS région et bénéficier d'une protection DDo S automatique grâce aux fonctionnalités de détection et d' AWS atténuation proposées dans la région.
Cet exemple concerne les architectures qui acheminent les utilisateurs vers une application Web à l'aide de ressources telles que les Classic Load Balancers, les Application Load Balancers, les Network Load Balancers, les solutions AWS Marketplace ou votre propre couche proxy. Vous pouvez améliorer la résilience DDo S en insérant les zones hébergées Amazon Route 53, les CloudFront distributions Amazon et le AWS WAF Web ACLs entre ces ressources d'applications Web et vos utilisateurs. Ces insertions peuvent masquer l'origine de l'application, traiter les demandes au plus près de vos utilisateurs finaux et détecter et atténuer les inondations de demandes au niveau de la couche application. Les applications qui diffusent du contenu statique ou dynamique à vos utilisateurs avec Route 53 sont protégées par un système d'atténuation DDo S intégré CloudFront et entièrement intégré qui atténue les attaques au niveau de l'infrastructure en temps réel.
Une fois ces améliorations architecturales mises en place, vous pouvez protéger vos zones hébergées par Route 53 et vos CloudFront distributions avec Shield Advanced. Lorsque vous protégez CloudFront des distributions, Shield Advanced vous invite à associer le AWS WAF Web ACLs et à créer des règles basées sur le taux pour celles-ci, et vous donne la possibilité d'activer l'atténuation automatique de la couche DDo S de l'application ou un engagement proactif. L'engagement proactif et l'atténuation automatique de la couche DDo S de l'application utilisent les contrôles de santé Route 53 que vous associez à la ressource. Pour en savoir plus sur ces options, consultez [Protection des ressources dans AWS Shield Advanced](ddos-resource-protections.md).
Le schéma de référence suivant décrit cette architecture résiliente DDo S pour une application Web.
![\[Le diagramme montre un rectangle intituléAWS cloud, avec un groupe d'utilisateurs à sa gauche. À l'intérieur du rectangle du nuage se trouvent deux autres rectangles, côte à côte. Le rectangle de gauche est intitulé AWS Shield Advanced et le rectangle de droite est titréVPC. Le AWS Shield Advanced triangle de gauche contient trois AWS icônes empilées verticalement. De haut en bas, les icônes sont Amazon Route 53 CloudFront, Amazon et AWS WAF. L'icône pour CloudFront comporte des flèches qui pointent vers et depuis l'icône pour AWS WAF. Le groupe d'utilisateurs a une flèche qui sort horizontalement vers sa droite et qui se divise pour pointer vers les icônes de Route 53 et CloudFront. À droite du rectangle Shield Advanced, le rectangle VPC contient deux icônes situées côte à côte. De gauche à droite, ces icônes sont Elastic Load Balancing et Amazon Elastic Compute Cloud. L' CloudFront icône comporte une flèche qui sort horizontalement vers sa droite et qui mène à l'icône Elastic Load Balancing. L'icône Elastic Load Balancing possède une flèche qui sort horizontalement vers la droite et mène à l'icône Amazon EC2. Les demandes des utilisateurs sont donc envoyées à Route 53 et CloudFront. CloudFront interagit avec l'équilibreur de charge AWS WAF et lui envoie également des demandes, qui à son tour envoie des demandes sur l'Amazon EC2.\]](http://docs.aws.amazon.com/fr_fr/waf/latest/developerguide/images/shield-resilient-web-app-arch.png)
Les avantages que cette approche apporte à votre application Web sont les suivants :
+ Protection contre les attaques de couche d'infrastructure (couche 3 et couche 4) DDo S fréquemment utilisées, sans délai de détection. En outre, si une ressource est fréquemment ciblée, Shield Advanced applique des mesures d'atténuation pendant de plus longues périodes. Shield Advanced utilise également le contexte de l'application déduit de Network ACLs (NACLs) pour bloquer le trafic indésirable en amont. Cela permet d'isoler les défaillances au plus près de leur source, minimisant ainsi l'effet sur les utilisateurs légitimes.
+ Protection contre les inondations TCP SYN. Les systèmes d'atténuation DDo S qui sont intégrés à CloudFront Route 53 et AWS Global Accelerator fournissent une fonctionnalité de proxy TCP SYN qui défie les nouvelles tentatives de connexion et ne sert que les utilisateurs légitimes.
+ Protection contre les attaques de la couche applicative du DNS, car Route 53 est chargée de fournir des réponses DNS faisant autorité.
+ Protection contre les inondations de demandes au niveau de la couche applicative Web. La règle basée sur le débit que vous configurez dans votre ACL AWS WAF Web bloque les sources IPs lorsqu'elles envoient plus de demandes que ce que la règle autorise.
+ Atténuation automatique de la couche DDo S de l'application pour vos CloudFront distributions, si vous choisissez d'activer cette option. Grâce à l'atténuation automatique du DDo S, Shield Advanced maintient une règle basée sur le débit dans l'ACL AWS WAF Web associée à la distribution, qui limite le volume de demandes provenant de sources DDo S connues. En outre, lorsque Shield Advanced détecte un événement qui affecte l'état de votre application, il crée, teste et gère automatiquement des règles d'atténuation dans l'ACL Web.
+ Engagement proactif avec la Shield Response Team (SRT), si vous choisissez d'activer cette option. Lorsque Shield Advanced détecte un événement qui affecte l'état de santé de votre application, le SRT répond et communique de manière proactive avec vos équipes chargées de la sécurité ou des opérations en utilisant les informations de contact que vous fournissez. Le SRT analyse les tendances de votre trafic et peut mettre à jour vos AWS WAF règles pour bloquer l'attaque.
# Exemple d'architecture de résilience Shield Advanced DDo S pour les applications TCP et UDP
Cet exemple montre une architecture résiliente DDo S pour les applications TCP et UDP dans une AWS région qui utilise des instances Amazon Elastic Compute Cloud (Amazon EC2) ou des adresses IP élastiques (EIP).
Vous pouvez suivre cet exemple général pour améliorer la résilience DDo S pour les types d'applications suivants :
+ Applications TCP ou UDP. Par exemple, les applications utilisées pour les jeux, l'IoT et la voix sur IP.
+ Applications Web qui nécessitent des adresses IP statiques ou qui utilisent des protocoles non pris CloudFront en charge par Amazon. Par exemple, votre application peut avoir besoin d'adresses IP que vos utilisateurs peuvent ajouter à leurs listes d'autorisation de pare-feu et qui ne sont utilisées par aucun autre AWS client.
Vous pouvez améliorer la résilience DDo S pour ces types d'applications en introduisant Amazon Route 53 et AWS Global Accelerator. Ces services peuvent rediriger les utilisateurs vers votre application et fournir à celle-ci des adresses IP statiques qui sont acheminées de manière anycast sur le réseau périphérique AWS mondial. Les accélérateurs standard de Global Accelerator peuvent améliorer la latence des utilisateurs jusqu'à 60 %. Si vous possédez une application Web, vous pouvez détecter et atténuer les inondations de demandes au niveau de la couche d'application Web en exécutant l'application sur un Application Load Balancer, puis en le protégeant à l'aide AWS WAF d'une ACL Web.
Après avoir créé votre application, protégez vos zones hébergées Route 53, les accélérateurs standard de Global Accelerator et tous les équilibreurs de charge d'application avec Shield Advanced. Lorsque vous protégez vos équilibreurs de charge d'application, vous pouvez associer le AWS WAF Web ACLs et créer des règles basées sur le taux pour ceux-ci. Vous pouvez configurer un engagement proactif avec le SRT à la fois pour vos accélérateurs standard Global Accelerator et pour vos équilibreurs de charge d'application en associant des bilans de santé Route 53 nouveaux ou existants. Pour en savoir plus sur les options, voir[Protection des ressources dans AWS Shield Advanced](ddos-resource-protections.md).
Le schéma de référence suivant décrit un exemple d'architecture résiliente DDo S pour les applications TCP et UDP.
![\[Le schéma montre les utilisateurs connectés à la Route 53 et à un AWS Global Accelerator. L'accélérateur est connecté à une icône Elastic Load Balancing protégée par AWS Shield Advanced et AWS WAF. L'Elastic Load Balancing est lui-même connecté à une instance Amazon EC2. Cette instance Elastic Load Balancing et l'instance Amazon EC2 se trouvent dans la région 1. AWS Global Accelerator Il est également directement connecté à une autre instance Amazon EC2, qui ne se trouve pas derrière une instance protégée d'Elastic Load Balancing. Cette deuxième instance Amazon EC2 se trouve dans la région n.\]](http://docs.aws.amazon.com/fr_fr/waf/latest/developerguide/images/shield-resilient-tcp-udp-app-arch.png)
Les avantages que cette approche apporte à votre application sont les suivants :
+ Protection contre les plus grandes attaques connues au niveau de la couche d'infrastructure (couche 3 et couche 4) DDo S. Si le volume d'une attaque provoque une congestion en amont AWS, la panne sera isolée plus près de sa source et aura un impact minimisé sur vos utilisateurs légitimes.
+ Protection contre les attaques de la couche applicative du DNS, car Route 53 est chargée de fournir des réponses DNS faisant autorité.
+ Si vous avez une application Web, cette approche fournit une protection contre les inondations de demandes au niveau de la couche d'application Web. La règle basée sur le débit que vous configurez dans votre ACL AWS WAF Web bloque les sources IPs lorsqu'elles envoient plus de demandes que ce que la règle autorise.
+ Engagement proactif avec la Shield Response Team (SRT), si vous choisissez d'activer cette option pour les ressources éligibles. Lorsque Shield Advanced détecte un événement qui affecte l'état de santé de votre application, le SRT répond et communique de manière proactive avec vos équipes chargées de la sécurité ou des opérations en utilisant les informations de contact que vous fournissez.
# Combiner Shield Advanced avec d'autres Services AWS
Vous pouvez utiliser Shield Advanced pour protéger vos ressources dans de nombreux types de scénarios. Toutefois, dans certains cas, vous devez utiliser d'autres services ou combiner d'autres services avec Shield Advanced afin d'offrir la meilleure protection. Vous trouverez ci-dessous des exemples d'utilisation de Shield Advanced ou d'autres AWS services pour protéger vos ressources.
| Objectif | Services suggérés | Documentation du service relatif |
| --- | --- | --- |
| Protéger une application Web RESTful APIs contre une attaque DDo S | Shield Advanced protège une CloudFront distribution Amazon et un Application Load Balancer | Documentation sur [Elastic Load Balancing, CloudFront documentation](https://docs.aws.amazon.com/elasticloadbalancing/) [Amazon](https://docs.aws.amazon.com/cloudfront/) |
| Protéger une application basée sur le protocole TCP contre une attaque S DDo | Shield Advanced protège un accélérateur AWS Global Accelerator standard ; associé à une adresse IP élastique | [AWS Global Accelerator Documentation, documentation](https://docs.aws.amazon.com/global-accelerator/) [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/) |
| Protégez un serveur de jeu basé sur UDP contre une attaque S DDo | Shield Advanced protège une EC2 instance Amazon associée à une adresse IP élastique | [Documentation Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/ec2/) |
Par exemple, si vous utilisez Shield Advanced pour protéger une adresse IP élastique, Shield Advanced protège toutes les ressources qui y sont associées. Lors d'une attaque, Shield Advanced déploie automatiquement votre réseau ACLs jusqu'à la limite du AWS réseau. Lorsque votre réseau ACLs se trouve à la limite du réseau, Shield Advanced peut fournir une protection contre les événements DDo S plus importants. Généralement, le réseau ACLs est appliqué à proximité de vos EC2 instances Amazon au sein de votre Amazon VPC. L'ACL réseau ne peut atténuer les attaques que dans la mesure où votre VPC Amazon et votre instance peuvent les gérer. Si l'interface réseau attachée à votre EC2 instance Amazon peut traiter jusqu'à 10 Gbit/s, les volumes supérieurs à 10 Gbit/s ralentissent et bloquent éventuellement le trafic vers cette instance. Lors d'une attaque, Shield Advanced promeut l'ACL de votre réseau jusqu'à la AWS frontière, qui peut traiter plusieurs téraoctets de trafic. Votre ACL réseau est capable de fournir une protection pour votre ressource bien au-delà de la capacité typique de votre réseau. Pour plus d'informations sur le réseau ACLs, consultez la section [Réseau ACLs](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html).
# Con AWS Shield Advanced figuration
Ce didacticiel vous explique comment commencer à AWS Shield Advanced utiliser la console Shield Advanced.
**Note**
Shield Advanced nécessite un abonnement, ce qui n' AWS Shield Standard est pas le cas. Les protections fournies par Shield Standard sont disponibles gratuitement pour tous les AWS clients.
Shield Advanced fournit une protection avancée de détection et d'atténuation DDo S pour les attaques au niveau de la couche réseau (couche 3), de la couche transport (couche 4) et de la couche application (couche 7). Pour plus d'informations sur Shield Advanced, consultez[Présentation de AWS Shield Advanced](ddos-advanced-summary.md).
La communauté AWS technique a publié un exemple de processus automatisé de configuration de Shield Advanced à l'aide des outils d'infrastructure en tant que code (IaC) AWS CloudFormation et de Terraform. Vous pouvez utiliser AWS Firewall Manager cette solution si vos comptes font partie d'une organisation AWS Organizations et si vous protégez des types de ressources, à l'exception d'Amazon Route 53 ou AWS Global Accelerator. [Pour explorer cette option, consultez le référentiel de code sur [aws-samples/ aws-shield-advanced-one-click-deployment et le didacticiel sur le déploiement](https://github.com/aws-samples/aws-shield-advanced-one-click-deployment) en un clic de Shield Advanced.](https://youtu.be/LCA3FwMk_QE)
**Note**
Il est important de configurer complètement Shield Advanced avant un événement de déni de service distribué (DDoS). Terminez la configuration pour vous assurer que votre application est protégée et que vous êtes prêt à réagir si votre application est affectée par une attaque DDo S.
Effectuez les étapes suivantes dans l'ordre pour commencer à utiliser Shield Advanced.
**Contents**
+ [S'abonner à AWS Shield Advanced](enable-ddos-prem.md)
+ [Ajouter et configurer des protections de ressources avec Shield Advanced](ddos-choose-resources.md)
+ [Configuration des protections de la couche application (couche 7) DDo S avec AWS WAF](ddos-get-started-web-acl-rbr.md)
+ [Configuration de la détection basée sur l'état de santé pour vos protections avec Shield Advanced et Route 53](ddos-get-started-health-checks.md)
+ [Configuration des alarmes et des notifications avec Shield Advanced et Amazon SNS](ddos-get-started-create-alarms.md)
+ [Révision et finalisation de votre configuration de protection dans Shield Advanced](ddos-get-started-review-and-configure.md)
+ [Configuration du support de la AWS Shield Response Team (SRT) pour la réponse aux événements DDo S](authorize-srt.md)
+ [Création d'un tableau de bord DDo S CloudWatch et définition d' CloudWatch alarmes](deploy-waf-dashboard.md)
# S'abonner à AWS Shield Advanced
Cette page explique comment abonner vos comptes à Shield Advanced pour commencer à utiliser le service.
Vous devez vous abonner à Shield Advanced pour chaque produit Compte AWS que vous souhaitez protéger. Il n'est pas nécessaire de s'abonner à Shield Standard.
**Facturation de l'abonnement Shield Advanced**
Si vous êtes revendeur de AWS chaînes, contactez l'équipe chargée de votre compte pour obtenir des informations et des conseils. Ces informations de facturation sont destinées aux clients qui ne sont pas des revendeurs de AWS canaux.
Pour tous les autres, les directives d'abonnement et de facturation suivantes s'appliquent :
+ Pour les comptes membres d'une AWS Organizations organisation, facturez AWS les abonnements Shield Advanced sur le compte payeur de l'organisation, que le compte payeur lui-même soit souscrit ou non.
+ Lorsque vous souscrivez plusieurs comptes appartenant à la même [famille de comptes de facturation AWS Organizations consolidée](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html), le prix d'abonnement unique couvre tous les comptes souscrits de la famille. L'organisation doit être propriétaire de Comptes AWS la totalité de ses ressources.
+ Lorsque vous souscrivez plusieurs comptes pour plusieurs organisations, vous pouvez toujours payer les mêmes frais d'abonnement pour l'ensemble des organisations, des comptes et des ressources, à condition que vous les possédiez tous. Contactez votre responsable de compte ou le service d' AWS assistance et demandez une exemption des frais AWS Shield Advanced d'abonnement pour toutes les organisations sauf une.
Pour obtenir des informations détaillées sur les prix et des exemples, consultez la section [AWS Shield Tarification](https://aws.amazon.com/shield/pricing/).
**Envisagez de simplifier les abonnements avec AWS Firewall Manager**
Si vos comptes font partie d'une organisation, nous vous recommandons de les utiliser AWS Firewall Manager , dans la mesure du possible, pour automatiser vos abonnements et vos protections pour l'organisation. Firewall Manager prend en charge tous les types de ressources protégées, à l'exception d'Amazon Route 53 et AWS Global Accelerator. Pour utiliser Firewall Manager, consultez [AWS Firewall Manager](fms-chapter.md) et[Configuration de AWS Firewall Manager AWS Shield Advanced politiques](getting-started-fms-shield.md).
Si vous n'utilisez pas Firewall Manager, pour chaque compte disposant de ressources à protéger, abonnez-vous et ajoutez des protections en suivant les procédures suivantes.
**Pour créer un compte à AWS Shield Advanced**
1. Connectez-vous à la console AWS WAF & Shield AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Dans la barre **AWS Shield**de navigation, choisissez **Getting started**. Choisissez **Subscribe to Shield Advanced**.
1. Sur la page **Subscribe to Shield Advanced**, lisez chaque terme du contrat, puis cochez toutes les cases pour indiquer que vous acceptez les termes. Pour les comptes appartenant à une famille de facturation consolidée, vous devez accepter les conditions de chaque compte.
**Important**
Lorsque vous êtes inscrit, pour vous désinscrire, vous devez contacter [AWS Support](https://console.aws.amazon.com/support).
[Pour désactiver le renouvellement automatique de votre abonnement, vous devez utiliser l'opération Shield API ou [UpdateSubscription](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_UpdateSubscription.html)la commande CLI update-subscription.](https://docs.aws.amazon.com/cli/latest/reference/shield/update-subscription.html)
Choisissez **Subscribe to Shield Advanced**. Cela permet d'abonner votre compte à Shield Advanced et d'activer le service.
Votre compte est inscrit. Suivez les étapes suivantes pour protéger les ressources de votre compte avec Shield Advanced.
**Note**
Shield Advanced ne protège pas automatiquement vos ressources après votre inscription. Vous devez spécifier les ressources que Shield Advanced doit protéger.
# Ajouter et configurer des protections de ressources avec Shield Advanced
Cette page fournit des instructions pour ajouter et configurer des protections pour vos ressources.
Shield Advanced protège uniquement les ressources que vous spécifiez, soit via Shield Advanced, soit dans le cadre d'une politique Firewall Manager Shield Advanced. Il ne protège pas automatiquement les ressources d'un compte abonné.
**Note**
Si vous utilisez une politique AWS Firewall Manager Shield Advanced pour vos protections, vous n'avez pas besoin de suivre cette étape. Vous configurez la politique avec les types de ressources à protéger, et Firewall Manager ajoute automatiquement des protections aux ressources couvertes par la politique.
Si vous n'utilisez pas Firewall Manager, suivez les procédures suivantes pour chaque compte disposant de ressources à protéger.
**Pour choisir les ressources à protéger à l'aide de Shield Advanced**
1. Choisissez **Ajouter des ressources à protéger** sur la page de confirmation d'abonnement de la procédure précédente, sur la page **Ressources protégées** ou **sur la page Aperçu**.
1. Sur la page **Choisissez les ressources à protéger avec Shield Advanced**, dans **Spécifiez la région et les types de ressources**, indiquez les spécifications de région et de type de ressource pour les ressources que vous souhaitez protéger. Vous pouvez protéger les ressources de plusieurs régions en sélectionnant **Toutes les régions** et vous pouvez restreindre la sélection aux ressources mondiales en sélectionnant **Global**. Vous pouvez désélectionner les types de ressources que vous ne souhaitez pas protéger. Pour plus d'informations sur les protections de vos types de ressources, consultez[Liste des ressources qui AWS Shield Advanced protègent](ddos-protections-by-resource-type.md).
1. Choisissez **Charger les ressources**. Shield Advanced renseigne la section **Select Resources** avec les AWS ressources correspondant à vos critères.
1. Dans la section **Sélectionner les ressources**, vous pouvez filtrer la liste des ressources en saisissant une chaîne à rechercher dans les listes de ressources.
Sélectionnez les ressources que vous souhaitez protéger.
1. Dans la section **Tags**, si vous souhaitez ajouter des balises aux protections Shield Advanced que vous créez, spécifiez-les. Pour plus d'informations sur le balisage AWS des ressources, consultez la section [Utilisation de l'éditeur de balises](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html).
1. Choisissez **Protect with Shield Advanced**. Cela ajoute les protections Shield Advanced aux ressources.
Parcourez les écrans de l'assistant de console pour terminer la configuration de la protection de vos ressources.
**Topics**
+ [Configuration des protections de la couche application (couche 7) DDo S avec AWS WAF](ddos-get-started-web-acl-rbr.md)
+ [Configuration de la détection basée sur l'état de santé pour vos protections avec Shield Advanced et Route 53](ddos-get-started-health-checks.md)
+ [Configuration des alarmes et des notifications avec Shield Advanced et Amazon SNS](ddos-get-started-create-alarms.md)
+ [Révision et finalisation de votre configuration de protection dans Shield Advanced](ddos-get-started-review-and-configure.md)
# Configuration des protections de la couche application (couche 7) DDo S avec AWS WAF
Cette page fournit des instructions pour configurer les protections de la couche d'application avec AWS WAF le Web ACLs.
Pour protéger une ressource de la couche application, Shield Advanced utilise une ACL AWS WAF Web avec une règle basée sur le débit comme point de départ. AWS WAF est un pare-feu d'applications Web qui vous permet de surveiller les requêtes HTTP et HTTPS qui sont transmises aux ressources de la couche application et de contrôler l'accès à votre contenu en fonction des caractéristiques des demandes. Une règle basée sur le débit limite le volume de trafic en fonction de vos critères d'agrégation des demandes, fournissant ainsi une protection DDo S de base à votre application. Pour plus d’informations, consultez [Comment AWS WAF fonctionne](how-aws-waf-works.md) et [Utilisation d'instructions de règles basées sur le taux dans AWS WAF](waf-rule-statement-type-rate-based.md).
Vous pouvez également activer l'atténuation automatique de la couche d'application DDo S de Shield Advanced, afin que Shield Advanced limite le débit des demandes provenant de sources DDo S connues et vous fournisse automatiquement des protections spécifiques à l'incident.
**Important**
Si vous gérez vos protections Shield Advanced à AWS Firewall Manager l'aide d'une politique Shield Advanced, vous ne pouvez pas gérer les protections de la couche application ici. Vous devez les gérer dans votre politique Firewall Manager Shield Advanced.
**Abonnements et AWS WAF coûts de Shield Advanced**
Votre abonnement Shield Advanced couvre les coûts liés à l'utilisation des AWS WAF fonctionnalités standard pour les ressources que vous protégez avec Shield Advanced. Les AWS WAF frais standard couverts par vos protections Shield Advanced sont le coût par pack de protection (ACL Web), le coût par règle et le prix de base par million de demandes d'inspection de requêtes Web, jusqu'à 1 500 WCUs et jusqu'à la taille corporelle par défaut.
L'activation de l'atténuation automatique de la couche d'application DDo S de Shield Advanced ajoute un groupe de règles à votre pack de protection (ACL Web) qui utilise 150 unités de capacité ACL Web (WCUs). Ils sont WCUs pris en compte dans l'utilisation de la WCU dans votre pack de protection (ACL Web). Pour plus d’informations, consultez [Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md), [Protection de la couche applicative avec le groupe de règles Shield Advanced](ddos-automatic-app-layer-response-rg.md) et [Unités de capacité Web ACL (WCUs) en AWS WAF](aws-waf-capacity-units.md).
Votre abonnement à Shield Advanced ne couvre pas l'utilisation de AWS WAF ressources que vous ne protégez pas à l'aide de Shield Advanced. Il ne couvre pas non plus les AWS WAF coûts non standard supplémentaires liés aux ressources protégées. Des exemples de AWS WAF coûts non standard sont ceux liés au contrôle des robots, à l'action des CAPTCHA règles, aux sites Web ACLs qui en utilisent plus de 1 500 WCUs et à l'inspection du corps de la demande au-delà de la taille par défaut. La liste complète est disponible sur la page de AWS WAF tarification. Votre abonnement à Shield Advanced inclut l'accès au groupe Layer 7 Anti- DDo S Amazon Managed Rule. Dans le cadre de votre abonnement, vous recevrez jusqu'à 50 milliards de demandes adressées aux AWS WAF ressources protégées de Shield Advanced au cours d'un mois civil. Les demandes supérieures à 50 milliards seront facturées conformément à la page de AWS Shield Advanced tarification.
Pour obtenir des informations complètes et des exemples de tarification, consultez [Shield Pricing](https://aws.amazon.com/shield/pricing/) and [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/).
**Pour configurer les protections de couche 7 DDo S pour une région**
Shield Advanced vous donne la possibilité de configurer l'atténuation de la couche 7 DDo S pour chaque région où se trouvent les ressources que vous avez choisies. Si vous ajoutez des protections dans plusieurs régions, l'assistant vous explique la procédure suivante pour chaque région.
1. La page **Configurer les protections de la couche 7 DDo S** répertorie chaque ressource qui n'est pas encore associée à une ACL Web. Pour chacune d'entre elles, choisissez une ACL Web existante ou créez une nouvelle ACL Web. Pour toute ressource qui possède déjà une ACL Web associée, vous pouvez changer de site Web ACLs en dissociant d'abord l'ACL en cours. AWS WAF Pour de plus amples informations, veuillez consulter [Associer ou dissocier une protection à une ressource AWS](web-acl-associating-aws-resource.md).
Pour les sites Web ACLs qui ne disposent pas encore d'une règle basée sur le taux, l'assistant de configuration vous invite à en ajouter une. Une règle basée sur le débit limite le trafic provenant des adresses IP lorsque celles-ci envoient un volume élevé de demandes. Les règles basées sur le débit aident à protéger votre application contre les inondations de requêtes Web et peuvent fournir des alertes en cas de pics de trafic soudains susceptibles d'indiquer une attaque DDo S potentielle. Ajoutez une règle basée sur le taux à une ACL Web en choisissant **Ajouter une règle de limite de débit**, puis en fournissant une limite de débit et une action de règle. Vous pouvez configurer des protections supplémentaires dans l'ACL Web via AWS WAF.
Pour plus d'informations sur l'utilisation de règles basées sur le Web ACLs et sur les taux dans vos protections Shield Advanced, y compris des options de configuration supplémentaires pour les règles basées sur les taux, consultez. [Protection de la couche applicative avec AWS WAF Web ACLs et Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md)
1. Pour l'**atténuation automatique de la couche d'application DDo S**, si vous souhaitez que Shield Advanced atténue automatiquement les attaques DDo S contre les ressources de votre couche d'application, choisissez **Activer**, puis sélectionnez l'action de AWS WAF règle que vous souhaitez que Shield Advanced utilise dans ses règles personnalisées. Ce paramètre s'applique à l'ensemble du Web ACLs pour les ressources que vous gérez dans cette session de l'assistant.
Grâce à l'atténuation automatique de la couche DDo S de l'application, Shield Advanced maintient une règle basée sur le débit dans l'ACL AWS WAF Web de la ressource qui limite le volume de demandes provenant de sources DDo S connues. En outre, Shield Advanced compare les modèles de trafic actuels aux données de référence du trafic historiques afin de détecter les écarts susceptibles d'indiquer une attaque DDo S. Lorsque Shield Advanced détecte une attaque DDo S, il répond en créant, en évaluant et en déployant des AWS WAF règles personnalisées pour y répondre. Vous spécifiez si les règles personnalisées comptent ou bloquent les attaques en votre nom.
**Note**
L'atténuation automatique de la couche DDo S de l'application fonctionne uniquement avec les packs de protection (Web ACLs) créés à l'aide de la dernière version de AWS WAF (v2).
Pour plus d'informations sur l'atténuation automatique de la couche d'application DDo S de Shield Advanced, y compris les mises en garde et les meilleures pratiques relatives à l'utilisation de cette fonctionnalité, consultez. [Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md)
1. Choisissez **Suivant**. L'assistant de console passe à la page de détection basée sur l'état de santé.
# Configuration de la détection basée sur l'état de santé pour vos protections avec Shield Advanced et Route 53
Cette page fournit des instructions pour configurer Shield Advanced afin d'utiliser la détection basée sur l'état de santé. Cela peut contribuer à améliorer la réactivité et la précision de la détection et de l'atténuation des attaques.
Des bilans de santé bien configurés sont essentiels pour une détection précise des événements. Vous pouvez configurer la détection basée sur l'état de santé pour tous les types de ressources, à l'exception des zones hébergées Route 53.
Pour utiliser la détection basée sur l'état de santé, définissez un bilan de santé pour votre ressource dans Route 53, puis associez le bilan de santé à votre protection Shield Advanced. Il est important que le bilan de santé que vous configurez reflète précisément l'état de santé de la ressource. Pour obtenir des informations et des exemples de configuration des contrôles de santé à utiliser avec Shield Advanced, consultez[Détection basée sur l'état à l'aide de contrôles de santé avec Shield Advanced et Route 53](ddos-advanced-health-checks.md).
Des bilans de santé sont requis pour le support d'engagement proactif de la Shield Response Team (SRT). Pour plus d'informations sur l'engagement proactif, consultez[Mettre en place un engagement proactif pour que le SRT vous contacte directement](ddos-srt-proactive-engagement.md).
**Note**
Les bilans de santé doivent indiquer qu'ils sont sains lorsque vous les associez à vos protections Shield Advanced.
**Pour configurer la détection basée sur l'état**
1. Sous **Associated Health Check (Vérification de l’état de santé associée)**, choisissez l'ID de la vérification de l’état de santé que vous souhaitez associer à la protection.
**Note**
Si le bilan de santé dont vous avez besoin ne s'affiche pas, accédez à la console Route 53 et vérifiez le bilan de santé et son identifiant. Pour plus d'informations, consultez [Creating and Updating Health Checks (Création et mise à jour des vérifications de l’état de santé)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html).
1. Choisissez **Suivant**. L'assistant de console passe à la page des alarmes et des notifications.
# Configuration des alarmes et des notifications avec Shield Advanced et Amazon SNS
Cette page fournit des instructions pour configurer éventuellement les notifications Amazon Simple Notification Service pour les CloudWatch alarmes Amazon détectées et l'activité des règles basées sur les taux. Vous pouvez les utiliser pour recevoir une notification lorsque Shield détecte un événement sur une ressource protégée ou lorsqu'une limite de débit configurée dans une règle basée sur le taux est dépassée.
Pour plus d'informations sur CloudWatch les métriques Shield Advanced, consultez[AWS Shield Advanced métriques](shield-metrics.md). Pour plus d'informations sur Amazon SNS, consultez le guide du [développeur Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/).
**Pour configurer les alarmes et les notifications**
1. Sélectionnez les rubriques Amazon SNS pour lesquelles vous souhaitez recevoir une notification. Vous pouvez utiliser une seule rubrique Amazon SNS pour toutes les ressources protégées et les règles basées sur les tarifs, ou vous pouvez choisir différents sujets, adaptés à votre organisation. Par exemple, vous pouvez créer une rubrique SNS pour chaque équipe chargée de répondre aux incidents pour un ensemble spécifique de ressources.
1. Choisissez **Suivant**. L'assistant de console passe à la page de révision de la protection des ressources.
# Révision et finalisation de votre configuration de protection dans Shield Advanced
**Pour vérifier et terminer vos paramètres**
1. Sur la page **Vérifier et configurer l'atténuation et la visibilité de DDo S**, passez en revue vos paramètres. Pour apporter des modifications, choisissez **Modifier** dans la zone que vous souhaitez modifier. Cela vous ramène à la page associée dans l'assistant de console. Apportez vos modifications, puis choisissez **Suivant** dans les pages suivantes jusqu'à ce que vous reveniez à la page **Révision et configuration DDo des mesures d'atténuation et de visibilité**.
1. Choisissez **Terminer la configuration**. La page **Ressources protégées** répertorie les ressources que vous venez de protéger.
# Configuration du support de la AWS Shield Response Team (SRT) pour la réponse aux événements DDo S
Cette page fournit des instructions pour configurer le support de Shield Response Team (SRT).
Le SRT comprend des ingénieurs de sécurité spécialisés dans la réponse aux événements DDo S. Vous pouvez éventuellement ajouter des autorisations qui permettent au SRT de gérer les ressources en votre nom lors d'un événement DDo S. En outre, vous pouvez configurer le SRT pour qu'il interagisse de manière proactive avec vous si les bilans de santé de Route 53 associés à vos ressources protégées ne fonctionnent pas correctement lors d'un événement détecté. Ces deux ajouts à vos protections permettent de réagir plus rapidement aux événements DDo S.
**Note**
Pour utiliser les services de la Shield Response Team (SRT), vous devez être abonné au plan [Business Support ou au plan](https://aws.amazon.com/premiumsupport/business-support/) [Enterprise Support](https://aws.amazon.com/premiumsupport/enterprise-support/).
Le SRT peut surveiller les données des AWS WAF demandes et les journaux lors des événements de la couche application afin d'identifier le trafic anormal. Ils peuvent aider à élaborer des AWS WAF règles personnalisées pour atténuer les sources de trafic offensantes. Le cas échéant, le SRT peut formuler des recommandations architecturales pour vous aider à mieux aligner vos ressources sur les AWS recommandations.
Pour plus d'informations sur le SRT, consultez[Réponse aux événements Managed DDo S avec le support de la Shield Response Team (SRT)](ddos-srt-support.md).
**Pour accorder des autorisations au SRT**
1. Sur la page de **présentation** de la AWS Shield console, sous **Configurer le support AWS SRT**, choisissez **Modifier l'accès SRT.** La page d'**accès à l'Edit AWS Shield Response Team (SRT)** s'ouvre.
1. Pour le **réglage de l'accès SRT**, sélectionnez l'une des options suivantes :
+ **Ne pas autoriser le SRT à accéder à mon compte** — Shield supprime toutes les autorisations que vous avez précédemment accordées au SRT pour accéder à votre compte et à vos ressources.
+ **Créer un nouveau rôle pour que le SRT accède à mon compte** — Shield crée un rôle qui fait confiance au principal du service`drt.shield.amazonaws.com`, qui représente le SRT, et y associe la politique `AWSShieldDRTAccessPolicy` gérée. La politique gérée permet au SRT de passer des AWS Shield Advanced appels d' AWS WAF API en votre nom et d'accéder à vos AWS WAF journaux. Pour plus d’informations sur la stratégie gérée, consultez [AWS stratégie gérée : AWSShield DRTAccess Politique](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy).
+ **Choisissez un rôle existant pour que le SRT accède à mes comptes**. Pour cette option, vous devez modifier la configuration du rôle dans Gestion des identités et des accès AWS (IAM) comme suit :
+ Attachez la stratégie gérée `AWSShieldDRTAccessPolicy` au rôle. Cette politique gérée permet au SRT de passer des AWS Shield Advanced appels d' AWS WAF API en votre nom et d'accéder à vos AWS WAF journaux. Pour plus d’informations sur la stratégie gérée, consultez [AWS stratégie gérée : AWSShield DRTAccess Politique](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy). Pour plus d'informations sur l'attachement de la politique gérée à votre rôle, consultez la section [Attacher et détacher des politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
+ Modifiez le rôle pour approuver l'entité de service `drt.shield.amazonaws.com`. Il s'agit du principal de service qui représente le SRT. Pour de plus amples informations, veuillez consulter [Éléments de stratégie IAM JSON : Mandataire](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html).
1. Choisissez **Save** pour enregistrer les changements.
Pour plus d'informations sur la façon de donner à la SRT l'accès à vos protections et à vos données, consultez[Octroi de l'accès au SRT](ddos-srt-access.md).
**Pour permettre un engagement proactif de la SRT**
1. Sur la page de **présentation** de la AWS Shield console, sous **Engagement proactif et contacts**, dans la zone des contacts, choisissez **Modifier**.
Sur la page **Modifier les contacts**, fournissez les coordonnées des personnes que vous souhaitez que le SRT contacte pour un engagement proactif.
Si vous indiquez plusieurs contacts, dans les **notes**, indiquez les circonstances dans lesquelles chaque contact doit être utilisé. Incluez les désignations des contacts principaux et secondaires, et indiquez les heures de disponibilité et les fuseaux horaires de chaque contact.
Exemples de notes de contact :
+ Il s'agit d'une hotline ouverte 24 heures sur 24, 7 jours sur 7, 365 jours par an. Travaillez avec l'analyste qui répond et il désignera la personne appropriée pour l'appel.
+ Merci de me contacter si la hotline ne répond pas dans les 5 minutes.
1. Choisissez **Enregistrer**.
La page **d'aperçu** reflète les informations de contact mises à jour.
1. Choisissez **Modifier la fonctionnalité d'engagement proactif**, sélectionnez **Activer**, puis sélectionnez **Enregistrer** pour activer l'engagement proactif.
Pour plus d'informations sur l'engagement proactif, consultez[Mettre en place un engagement proactif pour que le SRT vous contacte directement](ddos-srt-proactive-engagement.md).
# Création d'un tableau de bord DDo S CloudWatch et définition d' CloudWatch alarmes
Cette page fournit des instructions pour créer un tableau de bord DDo S dans CloudWatch et configurer des CloudWatch alarmes.
Vous pouvez surveiller l'activité potentielle de DDo S à l'aide d'Amazon CloudWatch, qui collecte des données brutes auprès de Shield Advanced et les traite en indicateurs lisibles en temps quasi réel. Vous pouvez utiliser les statistiques CloudWatch pour avoir une idée des performances de votre application ou service Web. Pour plus d'informations sur l'utilisation CloudWatch, [consultez CloudWatch le](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html) *guide de CloudWatch l'utilisateur Amazon*.
+ Pour obtenir des instructions sur la création d'un CloudWatch tableau de bord, consultez[Surveillance avec Amazon CloudWatch](monitoring-cloudwatch.md).
+ Pour une description des métriques Shield Advanced que vous pouvez ajouter à votre tableau de bord, consultez[AWS Shield Advanced métriques](shield-metrics.md).
Shield Advanced communique les indicateurs de ressources CloudWatch plus fréquemment pendant DDo les événements S que lorsqu'aucun événement n'est en cours. Shield Advanced fournit des statistiques une fois par minute pendant un événement, puis une fois juste après la fin de l'événement. Tant qu'aucun événement n'est en cours, Shield Advanced fournit des statistiques une fois par jour, à l'heure assignée à la ressource. Ce rapport périodique maintient les métriques actives et disponibles pour une utilisation dans vos CloudWatch alarmes personnalisées.
Ceci complète le didacticiel pour démarrer avec Shield Advanced. Pour profiter pleinement des protections que vous avez choisies, continuez à explorer les fonctionnalités et options de Shield Advanced. Pour commencer, familiarisez-vous avec les options qui s'offrent à vous pour consulter les événements [Visibilité des événements DDo S avec Shield Advanced](ddos-viewing-events.md) et y répondre[Réagir aux événements DDo S dans AWS](ddos-responding.md).
# Réponse aux événements Managed DDo S avec le support de la Shield Response Team (SRT)
Cette page décrit le fonctionnement de la Shield Response Team (SRT).
Le SRT fournit une assistance supplémentaire aux clients de Shield Advanced. Les SRT sont des ingénieurs de sécurité spécialisés dans la réponse aux événements DDo S. Pour apporter un soutien supplémentaire à votre AWS Support plan, vous pouvez travailler directement avec le SRT, en tirant parti de son expertise dans le cadre de votre flux de travail de réponse aux événements. Pour plus d'informations sur les options et pour obtenir des conseils de configuration, consultez les rubriques suivantes.
**Note**
Pour utiliser les services de la Shield Response Team (SRT), vous devez être abonné au plan [Business Support ou au plan](https://aws.amazon.com/premiumsupport/business-support/) [Enterprise Support](https://aws.amazon.com/premiumsupport/enterprise-support/).
Shield Response Team (SRT) fournit des services dans les régions où Shield Advanced est disponible, ainsi qu'aux clients des GovCloud régions AWS GovCloud (USA Est) et AWS GovCloud (USA Ouest).
**Activités de soutien à la SRT**
L'objectif principal d'un engagement avec le SRT est de protéger la disponibilité et les performances de votre application. Selon le type d'événement DDo S et l'architecture de votre application, le SRT peut effectuer une ou plusieurs des actions suivantes :
+ **AWS WAF analyse des journaux et règles** : pour les ressources qui utilisent une ACL AWS WAF Web, le SRT peut analyser vos AWS WAF journaux afin d'identifier les caractéristiques des attaques dans les requêtes Web de votre application. Avec votre approbation lors de l'engagement, le SRT peut apporter des modifications à votre ACL Web afin de bloquer les attaques qu'il a identifiées.
+ **Créez des mesures d'atténuation personnalisées pour le réseau** — Le SRT peut rédiger des mesures d'atténuation personnalisées pour vous en cas d'attaques contre la couche d'infrastructure. Le SRT peut travailler avec vous pour comprendre le trafic attendu pour votre application, pour bloquer le trafic inattendu et pour optimiser les limites de débit de paquets par seconde. Pour de plus amples informations, veuillez consulter [Mettre en place des mesures d'atténuation personnalisées contre les attaques DDo S avec le SRT](ddos-srt-custom-mitigations.md).
+ **Ingénierie du trafic réseau** — Le SRT travaille en étroite collaboration avec les équipes AWS réseau pour protéger les clients de Shield Advanced. Le cas échéant, AWS vous pouvez modifier la façon dont le trafic Internet arrive sur le AWS réseau afin d'allouer une plus grande capacité d'atténuation à votre application.
+ **Recommandations architecturales** — Le SRT peut déterminer que la meilleure façon d'atténuer une attaque nécessite des modifications architecturales afin de mieux s'aligner sur les AWS meilleures pratiques, et il vous aidera à mettre en œuvre ces pratiques. Pour plus d'informations, consultez la section [AWS Meilleures pratiques pour la résilience DDo des S](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency).
Les sections suivantes fournissent des instructions pour interagir avec le SRT
**Topics**
+ [Octroi de l'accès au SRT](ddos-srt-access.md)
+ [Mettre en place un engagement proactif pour que le SRT vous contacte directement](ddos-srt-proactive-engagement.md)
+ [Contacter le SRT pour obtenir de l'aide en cas de suspicion d'événement DDo S](ddos-srt-contacting.md)
+ [Mettre en place des mesures d'atténuation personnalisées contre les attaques DDo S avec le SRT](ddos-srt-custom-mitigations.md)
# Octroi de l'accès au SRT
Cette page fournit des instructions pour autoriser le SRT à agir en votre nom, afin qu'il puisse accéder à vos AWS WAF journaux et passer des appels au AWS Shield Advanced et AWS WAF APIs pour gérer les protections.
Lors des événements de la couche DDo S de l'application, le SRT peut surveiller les AWS WAF demandes afin d'identifier le trafic anormal et d'aider à élaborer des AWS WAF règles personnalisées pour atténuer les sources de trafic offensantes.
En outre, vous pouvez accorder à la SRT l'accès à d'autres données que vous avez stockées dans des compartiments Amazon S3, telles que des captures de paquets ou des journaux provenant d'un Application Load Balancer, d' CloudFrontAmazon ou de sources tierces.
**Note**
Pour utiliser les services de la Shield Response Team (SRT), vous devez être abonné au plan [Business Support ou au plan](https://aws.amazon.com/premiumsupport/business-support/) [Enterprise Support](https://aws.amazon.com/premiumsupport/enterprise-support/).
**Pour gérer les autorisations pour le SRT**
1. Sur la page de **présentation** de la AWS Shield console, sous **Configurer le support AWS SRT**, choisissez **Modifier l'accès SRT.** La page d'**accès à l'Edit AWS Shield Response Team (SRT)** s'ouvre.
1. Pour le **réglage de l'accès SRT**, sélectionnez l'une des options suivantes :
+ **Ne pas autoriser le SRT à accéder à mon compte** — Shield supprime toutes les autorisations que vous avez précédemment accordées au SRT pour accéder à votre compte et à vos ressources.
+ **Créer un nouveau rôle pour que le SRT accède à mon compte** — Shield crée un rôle qui fait confiance au principal du service`drt.shield.amazonaws.com`, qui représente le SRT, et y associe la politique `AWSShieldDRTAccessPolicy` gérée. La politique gérée permet au SRT de passer des AWS Shield Advanced appels d' AWS WAF API en votre nom et d'accéder à vos AWS WAF journaux. Pour plus d’informations sur la stratégie gérée, consultez [AWS stratégie gérée : AWSShield DRTAccess Politique](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy).
+ **Choisissez un rôle existant pour que le SRT accède à mes comptes**. Pour cette option, vous devez modifier la configuration du rôle dans Gestion des identités et des accès AWS (IAM) comme suit :
+ Attachez la stratégie gérée `AWSShieldDRTAccessPolicy` au rôle. Cette politique gérée permet au SRT de passer des AWS Shield Advanced appels d' AWS WAF API en votre nom et d'accéder à vos AWS WAF journaux. Pour plus d’informations sur la stratégie gérée, consultez [AWS stratégie gérée : AWSShield DRTAccess Politique](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy). Pour plus d'informations sur l'attachement de la politique gérée à votre rôle, consultez la section [Attacher et détacher des politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
+ Modifiez le rôle pour approuver l'entité de service `drt.shield.amazonaws.com`. Il s'agit du principal de service qui représente le SRT. Pour de plus amples informations, veuillez consulter [Éléments de stratégie IAM JSON : Mandataire](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html).
1. Pour **(facultatif) : accordez l'accès SRT à un compartiment Amazon S3**. Si vous devez partager des données qui ne figurent pas dans vos journaux ACL AWS WAF Web, configurez-le. Par exemple, les journaux d'accès à Application Load Balancer, les CloudFront journaux Amazon ou les journaux provenant de sources tierces.
**Note**
Vous n'avez pas besoin de le faire pour vos journaux ACL AWS WAF Web. Le SRT y accède lorsque vous autorisez l'accès à votre compte.
1. Configurez les compartiments Amazon S3 conformément aux directives suivantes :
+ Les emplacements des compartiments doivent être identiques Compte AWS à ceux auxquels vous avez accordé l'accès général à la SRT, lors de l'étape précédente, à l'accès à la **AWS Shield Response Team (SRT).**
+ Les compartiments peuvent être chiffrés en texte brut ou par SSE-S3. Pour plus d'informations sur le chiffrement Amazon S3 SSE-S3, consultez la section [Protection des données à l'aide du chiffrement côté serveur avec des clés de chiffrement gérées par Amazon S3 (SSE-S3) dans le guide de l'utilisateur Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html).
Le SRT ne peut pas afficher ni traiter les journaux stockés dans des compartiments chiffrés avec des clés stockées dans AWS Key Management Service ()AWS KMS.
1. Dans le Shield Advanced **(facultatif) : accordez à SRT l'accès à une section de compartiment Amazon S3**. Pour chaque compartiment Amazon S3 dans lequel vos données ou vos journaux sont stockés, entrez le nom du compartiment et choisissez **Add Bucket**. Vous pouvez ajouter jusqu'à 10 compartiments.
Cela accorde au SRT les autorisations suivantes sur chaque compartiment :`s3:GetBucketLocation`,`s3:GetObject`, et`s3:ListBucket`.
Si vous souhaitez autoriser le SRT à accéder à plus de 10 compartiments, vous pouvez le faire en modifiant les politiques de compartiment supplémentaires et en accordant manuellement les autorisations répertoriées ici pour le SRT.
Vous trouverez ci-dessous un exemple de liste de politiques.
```
{
"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. Choisissez **Save** pour enregistrer les changements.
[Vous pouvez également autoriser le SRT via l'API en créant un rôle IAM, en y attachant la politique de AWSShield DRTAccess politique, puis en transmettant le rôle à l'opération Associate. DRTRole](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_AssociateDRTRole.html)
# Mettre en place un engagement proactif pour que le SRT vous contacte directement
Cette page fournit des instructions pour configurer un engagement proactif avec le SRT.
Grâce à un engagement proactif, le SRT vous contacte directement lorsque la disponibilité ou les performances de votre application sont affectées par une éventuelle attaque. Nous recommandons ce modèle d'engagement car il fournit la réponse SRT la plus rapide et permet au SRT de commencer le dépannage avant même d'avoir établi un contact avec vous.
Un engagement proactif est disponible pour les événements liés à la couche réseau et à la couche transport sur les adresses IP élastiques et les accélérateurs AWS Global Accelerator standard, ainsi qu'en cas d'afflux de requêtes Web sur les CloudFront distributions Amazon et les équilibreurs de charge d'application. L'engagement proactif n'est disponible que pour les protections des ressources Shield Advanced associées à un bilan de santé Amazon Route 53. Pour plus d'informations sur la gestion et l'utilisation des bilans de santé, consultez[Détection basée sur l'état à l'aide de contrôles de santé avec Shield Advanced et Route 53](ddos-advanced-health-checks.md).
Lors d'un événement détecté par Shield Advanced, le SRT utilise l'état de vos bilans de santé pour déterminer si l'événement est éligible à un engagement proactif. Si tel est le cas, le SRT vous contactera conformément aux instructions de contact que vous fournissez dans votre configuration d'engagement proactif.
Vous pouvez configurer jusqu'à dix contacts pour un engagement proactif, et vous pouvez fournir des notes pour aider le SRT à vous contacter. Vos contacts proactifs devraient être disponibles pour communiquer avec le SRT lors d'événements. Si vous ne disposez pas d'un centre des opérations ouvert 24 heures sur 24, 7 jours sur 7, vous pouvez fournir un téléavertisseur et indiquer cette préférence de contact dans vos notes de contact.
L'engagement proactif exige que vous preniez les mesures suivantes :
+ Vous devez être abonné au [plan Business Support](https://aws.amazon.com/premiumsupport/business-support/) ou au [plan Enterprise Support](https://aws.amazon.com/premiumsupport/enterprise-support/).
+ Vous devez associer un bilan de santé d'Amazon Route 53 à toute ressource que vous souhaitez protéger grâce à un engagement proactif. Le SRT utilise l'état de vos bilans de santé pour déterminer si un événement nécessite un engagement proactif. Il est donc important que vos bilans de santé reflètent avec précision l'état de vos ressources protégées. Pour plus d'informations et de conseils, consultez[Détection basée sur l'état à l'aide de contrôles de santé avec Shield Advanced et Route 53](ddos-advanced-health-checks.md).
+ Pour une ressource associée à une ACL AWS WAF Web, vous devez créer l'ACL Web à l'aide de AWS WAF (v2), qui est la dernière version de AWS WAF.
+ Vous devez fournir au moins un contact que le SRT utilisera pour un engagement proactif lors d'un événement. Veillez à ce que vos informations de contact soient complètes et à jour.
**Pour permettre un engagement proactif de la SRT**
1. Sur la page de **présentation** de la AWS Shield console, sous **Engagement proactif et contacts**, dans la zone des contacts, choisissez **Modifier**.
Sur la page **Modifier les contacts**, fournissez les coordonnées des personnes que vous souhaitez que le SRT contacte pour un engagement proactif.
Si vous indiquez plusieurs contacts, dans les **notes**, indiquez les circonstances dans lesquelles chaque contact doit être utilisé. Incluez les désignations des contacts principaux et secondaires, et indiquez les heures de disponibilité et les fuseaux horaires de chaque contact.
Exemples de notes de contact :
+ Il s'agit d'une hotline ouverte 24 heures sur 24, 7 jours sur 7, 365 jours par an. Travaillez avec l'analyste qui répond et il désignera la personne appropriée pour l'appel.
+ Merci de me contacter si la hotline ne répond pas dans les 5 minutes.
1. Choisissez **Enregistrer**.
La page **d'aperçu** reflète les informations de contact mises à jour.
1. Choisissez **Modifier la fonctionnalité d'engagement proactif**, sélectionnez **Activer**, puis sélectionnez **Enregistrer** pour activer l'engagement proactif.
# Contacter le SRT pour obtenir de l'aide en cas de suspicion d'événement DDo S
Vous pouvez contacter le SRT de l'une des manières suivantes :
**Cas de support**
Vous pouvez ouvrir un dossier **AWS Shield**dans la console du **AWS Support Center**.
Pour obtenir des conseils sur la création d'un dossier de support, consultez le [AWS Support Centre](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html).
Sélectionnez la gravité adaptée à votre situation et fournissez vos coordonnées. Dans la description, veuillez fournir le plus de détails possible. Fournissez des informations sur les ressources protégées qui, selon vous, pourraient être affectées, ainsi que sur l'état actuel de votre expérience utilisateur final. Par exemple, si votre expérience utilisateur est dégradée ou que certaines parties de votre application ne sont pas disponibles, fournissez ces informations.
+ **Pour les attaques DDo S présumées** : si la disponibilité ou les performances de votre application sont actuellement affectées par une éventuelle attaque DDo S, choisissez les options de gravité et de contact suivantes :
+ Pour ce qui est du niveau de sévérité, choisissez le niveau de sévérité le plus élevé disponible pour votre plan de support :
+ Pour le support aux entreprises, il s'agit d'une **panne du système de production : < 1 heure**.
+ Pour le support aux entreprises, il s'agit **d'une panne du système critique : < 15 minutes**.
+ Pour l'option de contact, sélectionnez **Téléphone** ou **Chat** et fournissez vos coordonnées. L'utilisation d'une méthode de contact en direct fournit la réponse la plus rapide.
**Engagement proactif**
Grâce à un engagement AWS Shield Advanced proactif, le SRT vous contacte directement si le bilan de santé d'Amazon Route 53 associé à votre ressource protégée ne fonctionne pas correctement lors d'un événement détecté. Pour plus d’informations sur cette option, consultez [Mettre en place un engagement proactif pour que le SRT vous contacte directement](ddos-srt-proactive-engagement.md).
# Mettre en place des mesures d'atténuation personnalisées contre les attaques DDo S avec le SRT
Cette page fournit des instructions pour travailler avec le SRT afin de créer des mesures d'atténuation personnalisées contre les attaques DDo S.
Pour votre Elastic IPs (EIPs) et vos accélérateurs AWS Global Accelerator standard, vous pouvez utiliser le SRT pour configurer des mesures d'atténuation personnalisées. Cela est utile si vous connaissez une logique spécifique qui doit être appliquée lors de la mise en place d'une mesure d'atténuation. Par exemple, vous souhaiterez peut-être autoriser uniquement le trafic provenant de certains pays, appliquer des limites de débit spécifiques, configurer des validations facultatives, interdire les fragments ou n'autoriser que le trafic correspondant à un modèle spécifique de charge utile des paquets.
Voici des exemples de mesures d'atténuation personnalisées courantes :
+ **Correspondance** de modèles : si vous exploitez un service qui interagit avec des applications côté client, vous pouvez choisir de faire correspondre des modèles connus propres à ces applications. Par exemple, vous pouvez exploiter un service de jeu ou de communication qui oblige l'utilisateur final à installer un logiciel spécifique que vous distribuez. Vous pouvez inclure un chiffre magique dans chaque paquet envoyé par l'application à votre service. Vous pouvez faire correspondre jusqu'à 128 octets (séparés ou contigus) d'une charge utile et d'en-têtes de paquets TCP ou UDP non fragmentés. La correspondance peut être exprimée en notation hexadécimale sous la forme d'un décalage spécifique par rapport au début de la charge utile du paquet ou d'un décalage dynamique suivant une valeur connue. Par exemple, l'atténuation peut rechercher l'octet, `0x01` puis `0x12345678` s'attendre aux quatre octets suivants.
+ **Spécifique au DNS** : si vous gérez votre propre service DNS faisant autorité à l'aide de services tels que Global Accelerator ou Amazon Elastic Compute Cloud (Amazon EC2), vous pouvez demander une atténuation personnalisée qui valide les paquets afin de garantir la validité des requêtes DNS et appliquer un score de suspicion qui évalue les attributs spécifiques au trafic DNS.
Pour en savoir plus sur l'utilisation de SRT pour créer des mesures d'atténuation personnalisées, créez un dossier d'assistance sous. AWS Shield Pour en savoir plus sur la création de AWS Support dossiers, consultez [Getting started with AWS Support](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html).
# Protection des ressources dans AWS Shield Advanced
Vous pouvez ajouter et configurer AWS Shield Advanced des protections pour vos ressources. Vous pouvez gérer les protections pour une seule ressource et vous pouvez regrouper vos ressources protégées dans des collections logiques pour une meilleure gestion des événements. Vous pouvez également suivre les modifications apportées à vos protections Shield Advanced à l'aide de AWS Config.
**Note**
Shield Advanced protège uniquement les ressources que vous avez spécifiées soit dans Shield Advanced, soit par le biais d'une politique AWS Firewall Manager Shield Advanced. Il ne protège pas automatiquement vos ressources.
Si vous utilisez une politique AWS Firewall Manager Shield Advanced, vous n'avez pas besoin de gérer la protection des ressources couvertes par cette politique. Firewall Manager gère automatiquement les protections des comptes et des ressources concernés par une politique, conformément à la configuration de la politique. Pour de plus amples informations, veuillez consulter [Utilisation des AWS Shield Advanced politiques dans Firewall Manager](shield-policies.md).
**Topics**
+ [Liste des ressources qui AWS Shield Advanced protègent](ddos-protections-by-resource-type.md)
+ [Protection des EC2 instances Amazon et des équilibreurs de charge réseau avec Shield Advanced](ddos-protections-ec2-nlb.md)
+ [Protection de la couche applicative (couche 7) avec AWS Shield Advanced et AWS WAF](ddos-app-layer-protections.md)
+ [Détection basée sur l'état à l'aide de contrôles de santé avec Shield Advanced et Route 53](ddos-advanced-health-checks.md)
+ [Ajouter AWS Shield Advanced une protection aux AWS ressources](configure-new-protection.md)
+ [AWS Shield Advanced Protections d'édition](manage-protection.md)
+ [Création d'alarmes et de notifications pour les ressources protégées par Shield Advanced](add-alarm-ddos.md)
+ [Supprimer AWS Shield Advanced la protection d'une AWS ressource](remove-protection.md)
+ [Regrouper vos AWS Shield Advanced protections](ddos-protection-groups.md)
+ [Modifications apportées à la protection avancée des ressources par Tracking Shield dans AWS Config](ddos-add-config.md)
# Liste des ressources qui AWS Shield Advanced protègent
Cette section fournit des informations sur les protections Shield Advanced pour chaque type de ressource.
Shield Advanced protège les AWS ressources des couches réseau et transport (couches 3 et 4) et de la couche application (couche 7). Vous pouvez protéger certaines ressources directement et d'autres en les associant à des ressources protégées. Shield Advanced prend IPv4 en charge et ne prend pas en charge IPv6.
**Note**
Shield Advanced protège uniquement les ressources que vous avez spécifiées soit dans Shield Advanced, soit par le biais d'une politique AWS Firewall Manager Shield Advanced. Il ne protège pas automatiquement vos ressources.
Vous pouvez utiliser Shield Advanced pour une surveillance et une protection avancées avec les types de ressources suivants :
+ CloudFront Distributions Amazon. Pour CloudFront un déploiement continu, Shield Advanced protège toute distribution intermédiaire associée à une distribution principale protégée.
+ Zones hébergées Amazon Route 53.
+ AWS Global Accelerator accélérateurs standard.
+ Adresses IP Amazon EC2 Elastic. Shield Advanced protège les ressources associées aux adresses IP Elastic protégées.
+ EC2 Instances Amazon, par association à des adresses IP Amazon EC2 Elastic.
+ Les équilibreurs de charge Elastic Load Balancing (ELB) suivants :
+ Équilibreurs de charge des applications.
+ Équilibreurs Classic Load Balancer.
+ Équilibreurs de charge réseau, via des associations aux adresses IP Amazon EC2 Elastic.
**Note**
Vous ne pouvez pas utiliser Shield Advanced pour protéger un autre type de ressource. Par exemple, vous ne pouvez pas protéger les accélérateurs de routage AWS Global Accelerator personnalisés ou les équilibreurs de charge de passerelle.
**Note**
Les passerelles NAT gèrent uniquement le trafic sortant, tandis que Shield Advanced protège contre le trafic entrant S. DDo Pour la protection du trafic sortant, utilisez [AWS Network Firewall](https://docs.aws.amazon.com//network-firewall/latest/developerguide/what-is-aws-network-firewall.html).
Vous pouvez surveiller et protéger jusqu'à 1 000 ressources pour chaque type de ressource Compte AWS. Par exemple, dans un seul compte, vous pouvez protéger 1 000 adresses IP Amazon EC2 Elastic, 1 000 CloudFront distributions et 1 000 équilibreurs de charge d'application. Vous pouvez demander une augmentation du nombre de ressources que vous pouvez protéger avec Shield Advanced via la console Service Quotas à l'adresse [https://console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/).
# Protection des EC2 instances Amazon et des équilibreurs de charge réseau avec Shield Advanced
Cette page explique comment utiliser les AWS Shield Advanced protections pour les EC2 instances Amazon et les Network Load Balancers.
Vous pouvez protéger les EC2 instances Amazon et les Network Load Balancers en associant d'abord ces ressources aux adresses IP Elastic, puis en protégeant les adresses IP Elastic dans Shield Advanced.
Lorsque vous protégez les adresses IP Elastic, Shield Advanced identifie et protège les ressources auxquelles elles sont associées. Shield Advanced identifie automatiquement le type de ressource associée à une adresse IP élastique et applique les détections et mesures d'atténuation appropriées pour cette ressource. Cela inclut la configuration ACLs d'un réseau spécifique à l'adresse IP élastique. Pour plus d'informations sur l'utilisation des adresses IP élastiques avec vos AWS ressources, consultez les guides suivants : documentation [Amazon Elastic Compute Cloud ou documentation](https://docs.aws.amazon.com/ec2/) [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/).
Lors d'une attaque, Shield Advanced déploie automatiquement votre réseau ACLs jusqu'à la limite du AWS réseau. Lorsque votre réseau ACLs se trouve à la limite du réseau, Shield Advanced peut fournir une protection contre les événements DDo S plus importants. Généralement, le réseau ACLs est appliqué à proximité de vos EC2 instances Amazon au sein de votre Amazon VPC. L'ACL réseau ne peut atténuer les attaques que dans la mesure où votre VPC Amazon et votre instance peuvent les gérer. Par exemple, si l'interface réseau attachée à votre EC2 instance Amazon peut traiter jusqu'à 10 Gbit/s, les volumes supérieurs à 10 Gbit/s ralentiront et bloqueront éventuellement le trafic vers cette instance. Lors d'une attaque, Shield Advanced promeut l'ACL de votre réseau jusqu'à la AWS frontière, qui peut traiter plusieurs téraoctets de trafic. Votre ACL réseau est capable de fournir une protection pour votre ressource bien au-delà de la capacité typique de votre réseau. Pour plus d'informations sur le réseau ACLs, consultez la section [Réseau ACLs](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html).
Certains outils de dimensionnement, tels que AWS Elastic Beanstalk, ne vous permettent pas d'associer automatiquement une adresse IP élastique à un Network Load Balancer. Dans ces cas, vous devez associer manuellement l'adresse IP élastique.
# Protection de la couche applicative (couche 7) avec AWS Shield Advanced et AWS WAF
Cette page explique comment Shield Advanced et Shield AWS WAF travaillent ensemble pour protéger les ressources au niveau de la couche application (couche 7).
Pour protéger les ressources de la couche application avec Shield Advanced, vous devez d'abord associer une ACL AWS WAF Web à la ressource et y ajouter une ou plusieurs règles basées sur le débit. Vous pouvez également activer l'atténuation automatique de la couche d'application DDo S, ce qui permet à Shield Advanced de créer et de gérer automatiquement des règles ACL Web en votre nom en réponse aux attaques DDo S.
Lorsque vous protégez une ressource de la couche d'application avec Shield Advanced, Shield Advanced analyse le trafic au fil du temps afin d'établir et de maintenir des bases de référence. Shield Advanced utilise ces lignes de base pour détecter les anomalies dans les modèles de trafic susceptibles d'indiquer une attaque DDo S. Le moment où Shield Advanced détecte une attaque dépend du trafic que Shield Advanced a pu observer avant l'attaque et de l'architecture que vous utilisez pour vos applications Web. Les variations architecturales qui peuvent affecter le comportement de Shield Advanced incluent le type d'instance que vous utilisez, la taille de votre instance et si le type d'instance prend en charge la mise en réseau améliorée. Vous pouvez également configurer Shield Advanced pour mettre automatiquement en place des mesures d'atténuation en cas d'attaques au niveau de la couche applicative.
**Abonnements et AWS WAF coûts de Shield Advanced**
Votre abonnement Shield Advanced couvre les coûts liés à l'utilisation des AWS WAF fonctionnalités standard pour les ressources que vous protégez avec Shield Advanced. Les AWS WAF frais standard couverts par vos protections Shield Advanced sont le coût par pack de protection (ACL Web), le coût par règle et le prix de base par million de demandes d'inspection de requêtes Web, jusqu'à 1 500 WCUs et jusqu'à la taille corporelle par défaut.
L'activation de l'atténuation automatique de la couche d'application DDo S de Shield Advanced ajoute un groupe de règles à votre pack de protection (ACL Web) qui utilise 150 unités de capacité ACL Web (WCUs). Ils sont WCUs pris en compte dans l'utilisation de la WCU dans votre pack de protection (ACL Web). Pour plus d’informations, consultez [Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md), [Protection de la couche applicative avec le groupe de règles Shield Advanced](ddos-automatic-app-layer-response-rg.md) et [Unités de capacité Web ACL (WCUs) en AWS WAF](aws-waf-capacity-units.md).
Votre abonnement à Shield Advanced ne couvre pas l'utilisation de AWS WAF ressources que vous ne protégez pas à l'aide de Shield Advanced. Il ne couvre pas non plus les AWS WAF coûts non standard supplémentaires liés aux ressources protégées. Des exemples de AWS WAF coûts non standard sont ceux liés au contrôle des robots, à l'action des CAPTCHA règles, aux sites Web ACLs qui en utilisent plus de 1 500 WCUs et à l'inspection du corps de la demande au-delà de la taille par défaut. La liste complète est disponible sur la page de AWS WAF tarification. Votre abonnement à Shield Advanced inclut l'accès au groupe Layer 7 Anti- DDo S Amazon Managed Rule. Dans le cadre de votre abonnement, vous recevrez jusqu'à 50 milliards de demandes adressées aux AWS WAF ressources protégées de Shield Advanced au cours d'un mois civil. Les demandes supérieures à 50 milliards seront facturées conformément à la page de AWS Shield Advanced tarification.
Pour obtenir des informations complètes et des exemples de tarification, consultez [Shield Pricing](https://aws.amazon.com/shield/pricing/) and [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/).
**Topics**
+ [Liste des facteurs qui affectent la détection et l'atténuation des événements au niveau de la couche application avec Shield Advanced](ddos-app-layer-detection-mitigation.md)
+ [Protection de la couche applicative avec AWS WAF Web ACLs et Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md)
+ [Protection de la couche applicative grâce à des règles AWS WAF basées sur le débit et à Shield Advanced](ddos-app-layer-rbr.md)
+ [Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md)
# Liste des facteurs qui affectent la détection et l'atténuation des événements au niveau de la couche application avec Shield Advanced
Cette section décrit les facteurs qui affectent la détection et l'atténuation des événements de la couche application par Shield Advanced.
**Surveillance de l'état**
Les bilans de santé qui indiquent avec précision l'état général de votre application fournissent à Shield Advanced des informations sur les conditions de trafic rencontrées par votre application. Shield Advanced nécessite moins d'informations indiquant une attaque potentielle lorsque votre application signale un dysfonctionnement et davantage de preuves d'une attaque si votre application indique qu'elle est saine.
Il est important de configurer vos bilans de santé de manière à ce qu'ils indiquent avec précision l'état de santé des applications. Pour plus d'informations et de conseils, consultez[Détection basée sur l'état à l'aide de contrôles de santé avec Shield Advanced et Route 53](ddos-advanced-health-checks.md).
**Lignes de référence relatives au trafic**
Les lignes de base de trafic fournissent à Shield Advanced des informations sur les caractéristiques du trafic normal pour votre application. Shield Advanced utilise ces lignes de base pour identifier les cas où votre application ne reçoit pas de trafic normal, afin de vous avertir et, une fois configurée, de commencer à concevoir et à tester des options d'atténuation pour contrer une attaque potentielle. Pour plus d'informations sur la manière dont Shield Advanced utilise les bases de trafic pour détecter les événements potentiels, consultez la section [Shield : logique de détection avancée pour les menaces de la couche application (couche 7)](ddos-event-detection-application.md) de présentation.
Shield Advanced crée ses lignes de base à partir des informations fournies par l'ACL Web associée à la ressource protégée. L'ACL Web doit être associée à la ressource pendant au moins 24 heures et jusqu'à 30 jours avant que Shield Advanced puisse déterminer de manière fiable les bases de référence de l'application. Le temps requis commence lorsque vous associez l'ACL Web, soit via Shield Advanced, soit via AWS WAF.
Pour plus d'informations sur l'utilisation d'une ACL Web avec les protections de la couche d'application Shield Advanced, consultez[Protection de la couche applicative avec AWS WAF Web ACLs et Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md).
**Règles basées sur un débit**
Les règles basées sur le taux peuvent aider à atténuer les attaques. Ils peuvent également masquer les attaques, en les atténuant avant qu'elles ne deviennent un problème suffisamment important pour apparaître par rapport aux données de référence normales en matière de trafic ou dans les rapports d'état des bilans de santé.
Nous vous recommandons d'utiliser des règles basées sur le taux dans votre ACL Web lorsque vous protégez une ressource d'application avec Shield Advanced. Même si leurs mesures d'atténuation peuvent masquer une attaque potentielle, elles constituent une première ligne de défense précieuse, car elles permettent de garantir que votre application reste accessible à vos clients légitimes. Le trafic détecté par vos règles basées sur les taux et les limites de débit est visible dans vos AWS WAF statistiques.
Outre vos propres règles basées sur le débit, si vous activez l'atténuation automatique de la couche d'application DDo S, Shield Advanced ajoute un groupe de règles à votre ACL Web qu'il utilise pour atténuer les attaques. Dans ce groupe de règles, Shield Advanced dispose toujours d'une règle basée sur le débit qui limite le volume de demandes provenant d'adresses IP connues pour être à l'origine d'attaques DDo S. Vous ne pouvez pas consulter les statistiques relatives au trafic que les règles Shield Advanced atténuent.
Pour plus d'informations sur les règles basées sur les taux, consultez[Utilisation d'instructions de règles basées sur le taux dans AWS WAF](waf-rule-statement-type-rate-based.md). Pour plus d'informations sur la règle basée sur le débit utilisée par Shield Advanced pour l'atténuation automatique de la couche d'application DDo S, consultez[Protection de la couche applicative avec le groupe de règles Shield Advanced](ddos-automatic-app-layer-response-rg.md).
Pour plus d'informations sur Shield Advanced et AWS WAF les métriques, consultez[Surveillance avec Amazon CloudWatch](monitoring-cloudwatch.md).
# Protection de la couche applicative avec AWS WAF Web ACLs et Shield Advanced
Cette page explique comment AWS WAF Web ACLs et Shield Advanced fonctionnent ensemble pour créer des protections de base au niveau de la couche applicative.
Pour protéger une ressource de la couche application avec Shield Advanced, vous devez commencer par associer une ACL AWS WAF Web à la ressource. AWS WAF est un pare-feu d'applications Web qui vous permet de surveiller les requêtes HTTP et HTTPS qui sont transmises aux ressources de la couche application et de contrôler l'accès à votre contenu en fonction des caractéristiques des demandes. Vous pouvez configurer une ACL Web pour surveiller et gérer les demandes en fonction de facteurs tels que l'origine de la demande, le contenu des chaînes de requête et des cookies, et le taux de demandes provenant d'une seule adresse IP. Au minimum, votre protection Shield Advanced vous oblige à associer une ACL Web à une règle basée sur le débit, qui limite le taux de demandes pour chaque adresse IP.
Si aucune règle basée sur le taux n'est définie dans l'ACL Web associée, Shield Advanced vous invite à en définir au moins une. Les règles basées sur le débit bloquent automatiquement le trafic provenant de la source IPs lorsqu'il dépasse les seuils que vous définissez. Ils aident à protéger votre application contre les inondations de requêtes Web et peuvent fournir des alertes en cas de pics de trafic soudains susceptibles d'indiquer une attaque DDo S potentielle.
**Note**
Une règle basée sur le taux répond très rapidement aux pics de trafic surveillés par la règle. De ce fait, une règle basée sur le taux peut empêcher non seulement une attaque, mais également la détection d'une attaque potentielle par le biais de la fonction de détection Shield Advanced. Ce compromis privilégie la prévention plutôt que la visibilité complète des modèles d'attaque. Nous vous recommandons d'utiliser une règle basée sur le taux comme première ligne de défense contre les attaques.
Une fois votre ACL Web en place, si une attaque DDo S se produit, vous appliquez des mesures d'atténuation en ajoutant et en gérant des règles dans l'ACL Web. Vous pouvez le faire directement, avec l'aide de la Shield Response Team (SRT), ou automatiquement grâce à l'atténuation automatique de la couche DDo S de l'application.
**Important**
Si vous utilisez également l'atténuation automatique de la couche d'application DDo S, consultez les meilleures pratiques pour gérer votre ACL Web à l'adresse[Bonnes pratiques pour l'utilisation de l'atténuation automatique de la couche d'application DDo S](ddos-automatic-app-layer-response-bp.md).
Pour plus d'informations sur l'utilisation AWS WAF des règles de surveillance et de gestion de vos requêtes Web pour gérer, consultez[Création d'un pack de protection (ACL Web) dans AWS WAF](web-acl-creating.md).
# Protection de la couche applicative grâce à des règles AWS WAF basées sur le débit et à Shield Advanced
Cette page explique comment les règles AWS WAF basées sur le débit et Shield Advanced fonctionnent ensemble pour créer des protections de base au niveau de la couche d'application.
Lorsque vous utilisez une règle basée sur le taux avec sa configuration par défaut, elle évalue AWS WAF régulièrement le trafic pour la période de 5 minutes précédente. AWS WAF bloque les demandes provenant de toute adresse IP qui dépasse le seuil de la règle jusqu'à ce que le taux de demandes descende à un niveau acceptable. Lorsque vous configurez une règle basée sur le débit via Shield Advanced, configurez son seuil de débit à une valeur supérieure au débit de trafic normal que vous attendez d'une adresse IP source sur une fenêtre de cinq minutes.
Vous souhaiterez peut-être utiliser plusieurs règles basées sur le taux dans une ACL Web. Par exemple, vous pouvez avoir une règle basée sur le taux pour tout le trafic dont le seuil est élevé, plus une ou plusieurs règles supplémentaires configurées pour correspondre à certaines parties de votre application Web et dont les seuils sont inférieurs. Par exemple, vous pouvez faire correspondre l'URI `/login.html` avec un seuil inférieur, afin de limiter les abus commis contre une page de connexion.
Vous pouvez configurer une règle basée sur le taux pour utiliser une fenêtre temporelle d'évaluation différente et pour agréger les demandes en fonction d'un certain nombre de composants de demande, tels que les valeurs d'en-tête, les étiquettes et les arguments de requête. Pour de plus amples informations, veuillez consulter [Utilisation d'instructions de règles basées sur le taux dans AWS WAF](waf-rule-statement-type-rate-based.md).
Pour plus d'informations et de conseils, consultez le billet de blog sur la sécurité [Les trois règles AWS WAF basées sur les taux les plus importantes](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/).
**Options de configuration étendues grâce à AWS WAF**
La console Shield Advanced vous permet d'ajouter une règle basée sur le taux et de la configurer avec les paramètres de base par défaut. Vous pouvez définir des options de configuration supplémentaires en gérant vos règles basées sur les taux via AWS WAF. Par exemple, vous pouvez configurer la règle pour agréger les demandes en fonction de clés telles qu'une adresse IP transférée, une chaîne de requête et une étiquette. Vous pouvez également ajouter une instruction scope-down à la règle afin de soustraire certaines demandes à l'évaluation et à la limitation du débit. Pour de plus amples informations, veuillez consulter [Utilisation d'instructions de règles basées sur le taux dans AWS WAF](waf-rule-statement-type-rate-based.md).
# Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced
**Note**
À compter du 26 mars 2026, le groupe de règles gérées DDo anti-S (Anti-DDoS AMR) AWS WAF devient la solution par défaut pour la protection contre les attaques par afflux de requêtes HTTP (voir le blog de lancement d'[Anti- DDo S AMR](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-the-aws-waf-application-layer-ddos-protection/)). Elle remplace la fonction d'atténuation automatique de la couche 7 (L7AM). Si vous êtes déjà client de Shield Advanced, vous pouvez continuer à utiliser l'ancienne solution avec des AWS comptes existants ou nouveaux. Cependant, nous vous encourageons à adopter le groupe de règles gérées DDo anti-S. Le groupe de règles gérées DDo anti-S détecte et atténue les attaques en quelques secondes plutôt qu'en quelques minutes. Si vous êtes un nouveau client de Shield Advanced et que vous avez besoin d'accéder à l'ancienne solution, contactez le AWS Support.
Cette page présente le sujet de l'atténuation automatique de la couche d'application DDo S et répertorie les mises en garde associées.
Vous pouvez configurer Shield Advanced pour qu'il réponde automatiquement afin d'atténuer les attaques de la couche application (couche 7) contre les ressources de la couche application protégée, en comptant ou en bloquant les requêtes Web faisant partie de l'attaque. Cette option vient s'ajouter à la protection de la couche application que vous ajoutez via Shield Advanced avec une ACL AWS WAF Web et votre propre règle basée sur le taux.
Lorsque l'atténuation automatique est activée pour une ressource, Shield Advanced gère un groupe de règles dans l'ACL Web associée à la ressource, dans lequel il gère les règles d'atténuation au nom de la ressource. Le groupe de règles contient une règle basée sur le débit qui suit le volume de demandes provenant d'adresses IP connues pour être à l'origine d'attaques DDo S.
En outre, Shield Advanced compare les modèles de trafic actuels aux données de référence du trafic historiques afin de détecter les écarts susceptibles d'indiquer une attaque DDo S. Shield Advanced répond aux attaques DDo S détectées en créant, en évaluant et en déployant des AWS WAF règles personnalisées supplémentaires dans le groupe de règles.
## Mises en garde relatives à l'utilisation de l'atténuation automatique de la couche DDo d'application S
La liste suivante décrit les mises en garde relatives à l'atténuation automatique de la couche DDo S des applications Shield Advanced et décrit les mesures que vous souhaiterez peut-être suivre pour y répondre.
+ L'atténuation automatique de la couche DDo S de l'application fonctionne uniquement avec les packs de protection (Web ACLs) créés à l'aide de la dernière version de AWS WAF (v2).
+ Shield Advanced a besoin de temps pour établir une base de référence du trafic historique normal de votre application, qu'il utilise pour détecter et isoler le trafic d'attaque du trafic normal, afin d'atténuer le trafic d'attaque. Le délai d'établissement d'une base de référence est compris entre 24 heures et 30 jours à compter du moment où vous associez une ACL Web à la ressource d'application protégée. Pour plus d'informations sur les lignes de base du trafic, consultez[Liste des facteurs qui affectent la détection et l'atténuation des événements au niveau de la couche application avec Shield Advanced](ddos-app-layer-detection-mitigation.md).
+ L'activation de l'atténuation automatique de la couche DDo S de l'application ajoute un groupe de règles à votre pack de protection (ACL Web) qui utilise 150 unités de capacité ACL Web (WCUs). Ils sont WCUs pris en compte dans l'utilisation de la WCU dans votre pack de protection (ACL Web). Pour plus d'informations, consultez [Protection de la couche applicative avec le groupe de règles Shield Advanced](ddos-automatic-app-layer-response-rg.md) et [Unités de capacité Web ACL (WCUs) en AWS WAF](aws-waf-capacity-units.md).
+ Le groupe de règles Shield Advanced génère AWS WAF des métriques, mais elles ne peuvent pas être consultées. Il en va de même pour tous les autres groupes de règles que vous utilisez dans votre pack de protection (ACL Web) mais que vous ne possédez pas, tels que les groupes de règles AWS Managed Rules. Pour plus d'informations sur AWS WAF les métriques, consultez[AWS WAF métriques et dimensions](waf-metrics.md). Pour plus d'informations sur cette option de protection Shield Advanced, consultez[Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](#ddos-automatic-app-layer-response).
+ Pour les sites Web ACLs qui protègent plusieurs ressources, l'atténuation automatique déploie uniquement des mesures d'atténuation personnalisées qui n'ont aucun impact négatif sur les ressources protégées.
+ Le délai entre le début d'une attaque DDo S et le moment où Shield Advanced place des règles d'atténuation automatiques personnalisées varie en fonction de chaque événement. Certaines attaques DDo S peuvent prendre fin avant que les règles personnalisées ne soient déployées. D'autres attaques peuvent se produire lorsqu'une atténuation est déjà en place et peuvent donc être atténuées par ces règles dès le début de l'événement. En outre, les règles basées sur le taux dans le groupe de règles Web ACL et Shield Advanced peuvent atténuer le trafic d'attaque avant qu'il ne soit détecté comme un événement potentiel.
+ Pour les équilibreurs de charge d'application qui reçoivent du trafic via un réseau de diffusion de contenu (CDN), tel qu'Amazon CloudFront, les capacités d'atténuation automatique de la couche applicative de Shield Advanced pour ces ressources d'Application Load Balancer seront réduites. Shield Advanced utilise les attributs du trafic client pour identifier et isoler le trafic d'attaque du trafic normal vers votre application, et CDNs peut ne pas préserver ou transmettre les attributs du trafic client d'origine. Si vous l'utilisez CloudFront, nous vous recommandons d'activer l'atténuation automatique sur la CloudFront distribution.
+ L'atténuation automatique de la couche DDo S de l'application n'interagit pas avec les groupes de protection. Vous pouvez activer l'atténuation automatique pour les ressources appartenant à des groupes de protection, mais Shield Advanced n'applique pas automatiquement les mesures d'atténuation des attaques en fonction des résultats des groupes de protection. Shield Advanced applique des mesures d'atténuation automatiques des attaques pour les ressources individuelles.
**Contents**
+ [Mises en garde relatives à l'utilisation de l'atténuation automatique de la couche DDo d'application S](#ddos-automatic-app-layer-response-caveats)
+ [Bonnes pratiques pour l'utilisation de l'atténuation automatique de la couche d'application DDo S](ddos-automatic-app-layer-response-bp.md)
+ [Activation de l'atténuation automatique de la couche DDo S de l'application](ddos-automatic-app-layer-response-config.md)
+ [Que se passe-t-il lorsque vous activez l'atténuation automatique ?](ddos-automatic-app-layer-response-config.md#ddos-automatic-app-layer-response-enable)
+ [Comment Shield Advanced gère l'atténuation automatique](ddos-automatic-app-layer-response-behavior.md)
+ [Comment Shield Advanced répond aux attaques DDo S grâce à une atténuation automatique](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-ddos-attack)
+ [Comment Shield Advanced gère le paramètre d'action des règles](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-rule-action)
+ [Comment Shield Advanced gère les mesures d'atténuation lorsqu'une attaque s'atténue](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-after-attack)
+ [Que se passe-t-il lorsque vous désactivez l'atténuation automatique](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-disable)
+ [Protection de la couche applicative avec le groupe de règles Shield Advanced](ddos-automatic-app-layer-response-rg.md)
+ [Affichage de la configuration d'atténuation automatique de la couche d'application DDo S pour une ressource](view-automatic-app-layer-response-configuration.md)
+ [Activation et désactivation de l'atténuation automatique de la couche d'application DDo S](enable-disable-automatic-app-layer-response.md)
+ [Modification de l'action utilisée pour l'atténuation automatique de la couche d'application DDo S](change-action-of-automatic-app-layer-response.md)
+ [Utilisation AWS CloudFormation avec atténuation automatique de la couche DDo S de l'application](manage-automatic-mitigation-in-cfn.md)
# Bonnes pratiques pour l'utilisation de l'atténuation automatique de la couche d'application DDo S
Respectez les instructions fournies dans cette section lorsque vous utilisez l'atténuation automatique.
**Gestion générale des protections**
Suivez ces directives pour planifier et mettre en œuvre vos protections d'atténuation automatiques.
+ Gérez toutes vos protections d'atténuation automatique via Shield Advanced ou, si vous utilisez AWS Firewall Manager pour gérer vos paramètres d'atténuation automatique de Shield Advanced, via Firewall Manager. Ne mélangez pas l'utilisation de Shield Advanced et de Firewall Manager pour gérer ces protections.
+ Gérez des ressources similaires en utilisant le même Web ACLs et les mêmes paramètres de protection, et gérez des ressources différentes en utilisant des sites Web ACLs différents. Lorsque Shield Advanced atténue une attaque DDo S sur une ressource protégée, il définit des règles pour l'ACL Web associée à la ressource, puis teste les règles par rapport au trafic de toutes les ressources associées à l'ACL Web. Shield Advanced n'appliquera les règles que si elles n'ont aucun impact négatif sur les ressources associées. Pour de plus amples informations, veuillez consulter [Comment Shield Advanced gère l'atténuation automatique](ddos-automatic-app-layer-response-behavior.md).
+ Pour les équilibreurs de charge d'application dont tout le trafic Internet est transmis par proxy via une CloudFront distribution Amazon, activez uniquement l'atténuation automatique sur la distribution. CloudFront La CloudFront distribution comportera toujours le plus grand nombre d'attributs de trafic d'origine, que Shield Advanced exploite pour atténuer les attaques.
**Optimisation de la détection et de l'atténuation**
Suivez ces directives pour optimiser les protections que l'atténuation automatique fournit aux ressources protégées. Pour une vue d'ensemble de la détection et de l'atténuation de la couche d'application, voir[Liste des facteurs qui affectent la détection et l'atténuation des événements au niveau de la couche application avec Shield Advanced](ddos-app-layer-detection-mitigation.md).
+ Configurez les contrôles de santé de vos ressources protégées et utilisez-les pour activer la détection basée sur l'état dans vos protections Shield Advanced. Pour de plus amples informations, consultez [Détection basée sur l'état à l'aide de contrôles de santé avec Shield Advanced et Route 53](ddos-advanced-health-checks.md).
+ Activez l'atténuation automatique en Count mode jusqu'à ce que Shield Advanced ait établi une base de référence pour le trafic historique normal. Shield Advanced a besoin de 24 heures à 30 jours pour établir une base de référence.
L'établissement d'une base de référence des modèles de trafic normaux nécessite les éléments suivants :
+ L'association d'une ACL Web à la ressource protégée. Vous pouvez l'utiliser AWS WAF directement pour associer votre ACL Web ou vous pouvez demander à Shield Advanced de l'associer lorsque vous activez la protection de la couche d'application Shield Advanced et que vous spécifiez une ACL Web à utiliser.
+ Flux de trafic normal vers votre application protégée. Si le trafic de votre application n'est pas normal, par exemple avant son lancement ou si le trafic de production est insuffisant pendant de longues périodes, les données historiques ne peuvent pas être collectées.
**Gestion des ACL Web**
Suivez ces directives pour gérer le Web ACLs que vous utilisez avec une atténuation automatique.
+ Si vous devez remplacer l'ACL Web associée à la ressource protégée, apportez les modifications suivantes dans l'ordre :
1. Dans Shield Advanced, désactivez l'atténuation automatique.
1. Dans AWS WAF, dissociez l'ancienne ACL Web et associez la nouvelle ACL Web.
1. Dans Shield Advanced, activez l'atténuation automatique.
Shield Advanced ne transfère pas automatiquement l'atténuation automatique de l'ancienne ACL Web vers la nouvelle.
+ Ne supprimez aucune règle de groupe de règles de votre site Web ACLs dont le nom commence par`ShieldMitigationRuleGroup`. Si vous supprimez ce groupe de règles, vous désactivez les protections fournies par l'atténuation automatique de Shield Advanced pour chaque ressource associée à l'ACL Web. En outre, Shield Advanced peut mettre un certain temps à recevoir la notification du changement et à mettre à jour ses paramètres. Pendant ce temps, les pages de la console Shield Advanced fourniront des informations incorrectes.
Pour plus d'informations sur le groupe de règles, consultez[Protection de la couche applicative avec le groupe de règles Shield Advanced](ddos-automatic-app-layer-response-rg.md).
+ Ne modifiez pas le nom d'une règle de groupe de règles dont le nom commence par`ShieldMitigationRuleGroup`. Cela peut interférer avec les protections fournies par l'atténuation automatique de Shield Advanced via l'ACL Web.
+ Lorsque vous créez des règles et des groupes de règles, n'utilisez pas de noms commençant par`ShieldMitigationRuleGroup`. Cette chaîne est utilisée par Shield Advanced pour gérer vos mesures d'atténuation automatiques.
+ Dans le cadre de la gestion de vos règles ACL Web, n'attribuez pas de paramètre de priorité de 10 000 000. Shield Advanced attribue ce paramètre de priorité à sa règle de groupe de règles d'atténuation automatique lorsqu'il l'ajoute.
+ Priorisez la `ShieldMitigationRuleGroup` règle afin qu'elle s'exécute quand vous le souhaitez par rapport aux autres règles de votre ACL Web. Shield Advanced ajoute la règle du groupe de règles à l'ACL Web avec une priorité de 10 000 000, à exécuter après vos autres règles. Si vous utilisez l'assistant de AWS WAF console pour gérer votre ACL Web, ajustez les paramètres de priorité selon vos besoins après avoir ajouté des règles à l'ACL Web.
+ Si vous avez l' AWS CloudFormation habitude de gérer votre site Web ACLs, vous n'avez pas besoin de gérer la `ShieldMitigationRuleGroup` règle du groupe de règles. Suivez les instructions à l'adresse[Utilisation AWS CloudFormation avec atténuation automatique de la couche DDo S de l'application](manage-automatic-mitigation-in-cfn.md).
# Activation de l'atténuation automatique de la couche DDo S de l'application
Cette page explique comment configurer Shield Advanced pour répondre automatiquement aux attaques de la couche application.
Vous activez l'atténuation automatique Shield Advanced dans le cadre des protections de la couche d'application DDo S de votre ressource. Pour plus d'informations sur cette opération via la console, consultez[Configurer les protections de la couche DDo S de l'application](manage-protection.md#configure-app-layer-protection).
La fonctionnalité d'atténuation automatique vous oblige à effectuer les opérations suivantes :
+ **Associez une ACL Web à la ressource** : cela est nécessaire pour toute protection de la couche d'application Shield Advanced. Vous pouvez utiliser la même ACL Web pour plusieurs ressources. Nous vous recommandons de le faire uniquement pour les ressources ayant un trafic similaire. Pour plus d'informations sur le WebACLs, y compris les exigences relatives à son utilisation avec plusieurs ressources, consultez[Comment AWS WAF fonctionne](how-aws-waf-works.md).
+ **Activez et configurez l'atténuation automatique de la couche d'application DDo S de Shield Advanced** : lorsque vous activez cette option, vous indiquez si vous souhaitez que Shield Advanced bloque ou compte automatiquement les requêtes Web qu'il considère comme faisant partie d'une attaque DDo S. Shield Advanced ajoute un groupe de règles à l'ACL Web associée et l'utilise pour gérer dynamiquement sa réponse aux attaques DDo S sur la ressource. Pour plus d'informations sur les options d'action des règles, consultez[Utilisation des actions liées aux règles dans AWS WAF](waf-rule-action.md).
+ **(Facultatif, mais recommandé) Ajoutez une règle basée sur le débit à l'ACL Web** — Par défaut, la règle basée sur le débit fournit à votre ressource une protection de base contre les attaques DDo S en empêchant toute adresse IP individuelle d'envoyer trop de demandes en peu de temps. Pour plus d'informations sur les règles basées sur le taux, y compris les options d'agrégation de demandes personnalisées et des exemples, consultez[Utilisation d'instructions de règles basées sur le taux dans AWS WAF](waf-rule-statement-type-rate-based.md).
## Que se passe-t-il lorsque vous activez l'atténuation automatique ?
Shield Advanced effectue les opérations suivantes lorsque vous activez l'atténuation automatique :
+ Le **cas échéant, ajoute un groupe de règles pour une utilisation dans Shield Advanced**. Si l'ACL AWS WAF Web que vous avez associée à la ressource ne possède pas encore de AWS WAF règle de groupe de règles dédiée à l'atténuation automatique de la couche d'application DDo S, Shield Advanced en ajoute une.
Le nom de la règle du groupe de règles commence par`ShieldMitigationRuleGroup`. Le groupe de règles contient toujours une règle basée sur le débit nommée`ShieldKnownOffenderIPRateBasedRule`, qui limite le volume de demandes provenant d'adresses IP connues pour être à l'origine d'attaques DDo S. Pour plus de détails sur le groupe de règles Shield Advanced et la règle ACL Web qui y fait référence, consultez[Protection de la couche applicative avec le groupe de règles Shield Advanced](ddos-automatic-app-layer-response-rg.md).
+ **Commence à répondre aux attaques DDo S contre la ressource** — Shield Advanced répond automatiquement aux attaques DDo S visant la ressource protégée. Outre la règle basée sur le taux, qui est toujours présente, Shield Advanced utilise son groupe de AWS WAF règles pour déployer des règles personnalisées visant à atténuer les attaques DDo S. Shield Advanced adapte ces règles à votre application et aux attaques qu'elle subit, et les teste par rapport au trafic historique de la ressource avant de les déployer.
Shield Advanced utilise une règle de groupe de règles unique dans toutes les ACL Web que vous utilisez pour une atténuation automatique. Si Shield Advanced a déjà ajouté le groupe de règles pour une autre ressource protégée, il n'ajoute aucun autre groupe de règles à l'ACL Web.
L'atténuation automatique de la couche d'application DDo S dépend de la présence du groupe de règles pour atténuer les attaques. Si le groupe de règles est supprimé de l'ACL AWS WAF Web pour une raison quelconque, la suppression désactive l'atténuation automatique pour toutes les ressources associées à l'ACL Web.
# Comment Shield Advanced gère l'atténuation automatique
Les rubriques de cette section décrivent comment Shield Advanced gère vos modifications de configuration pour l'atténuation automatique de la couche applicative DDo S et comment il gère les attaques DDo S lorsque l'atténuation automatique est activée.
**Topics**
+ [Comment Shield Advanced répond aux attaques DDo S grâce à une atténuation automatique](#ddos-automatic-app-layer-response-ddos-attack)
+ [Comment Shield Advanced gère le paramètre d'action des règles](#ddos-automatic-app-layer-response-rule-action)
+ [Comment Shield Advanced gère les mesures d'atténuation lorsqu'une attaque s'atténue](#ddos-automatic-app-layer-response-after-attack)
+ [Que se passe-t-il lorsque vous désactivez l'atténuation automatique](#ddos-automatic-app-layer-response-disable)
## Comment Shield Advanced répond aux attaques DDo S grâce à une atténuation automatique
Lorsque l'atténuation automatique est activée sur une ressource protégée, la règle `ShieldKnownOffenderIPRateBasedRule` basée sur le taux du groupe de règles Shield Advanced répond automatiquement aux volumes de trafic élevés provenant de sources DDo S connues. Cette limitation de débit est appliquée rapidement et constitue une défense de première ligne contre les attaques.
Lorsque Shield Advanced détecte une attaque, il effectue les opérations suivantes :
1. Tente d'identifier une signature d'attaque qui isole le trafic d'attaque du trafic normal vers votre application. L'objectif est de produire des règles d'atténuation DDo S de haute qualité qui, une fois mises en place, n'affectent que le trafic d'attaque et n'ont aucun impact sur le trafic normal vers votre application.
1. Évalue la signature d'attaque identifiée par rapport aux modèles de trafic historiques pour la ressource attaquée ainsi que pour toute autre ressource associée à la même ACL Web. Shield Advanced le fait avant de déployer des règles en réponse à l'événement.
En fonction des résultats de l'évaluation, Shield Advanced effectue l'une des opérations suivantes :
+ Si Shield Advanced détermine que la signature d'attaque isole uniquement le trafic impliqué dans l'attaque DDo S, il implémente la signature dans les AWS WAF règles du groupe de règles d'atténuation Shield Advanced de l'ACL Web. Shield Advanced attribue à ces règles le paramètre d'action que vous avez configuré pour l'atténuation automatique de la ressource, Count soitBlock.
+ Dans le cas contraire, Shield Advanced ne place aucune mesure d'atténuation.
Tout au long d'une attaque, Shield Advanced envoie les mêmes notifications et fournit les mêmes informations sur les événements que pour les protections de base de la couche d'application Shield Advanced. Vous pouvez consulter les informations sur les événements et les attaques DDo S, ainsi que sur les mesures d'atténuation mises en place par Shield Advanced en cas d'attaques, dans la console d'événements Shield Advanced. Pour plus d'informations, consultez [Visibilité des événements DDo S avec Shield Advanced](ddos-viewing-events.md).
Si vous avez configuré l'atténuation automatique pour utiliser l'action des Block règles et que les règles d'atténuation déployées par Shield Advanced présentent des faux positifs, vous pouvez modifier l'action de la règle enCount. Pour plus d'informations sur la procédure à suivre, consultez[Modification de l'action utilisée pour l'atténuation automatique de la couche d'application DDo S](change-action-of-automatic-app-layer-response.md).
## Comment Shield Advanced gère le paramètre d'action des règles
Vous pouvez définir l'action de la règle pour vos mesures d'atténuation automatiques sur Block ouCount.
Lorsque vous modifiez le paramètre d'action de la règle d'atténuation automatique pour une ressource protégée, Shield Advanced met à jour tous les paramètres des règles pour la ressource. Il met à jour toutes les règles actuellement en place pour la ressource du groupe de règles Shield Advanced et utilise le nouveau paramètre d'action lorsqu'il crée de nouvelles règles.
Pour les ressources qui utilisent la même ACL Web, si vous spécifiez des actions différentes, Shield Advanced utilise le paramètre Block d'action de la règle `ShieldKnownOffenderIPRateBasedRule` basée sur le taux du groupe de règles. Shield Advanced crée et gère les autres règles du groupe de règles pour le compte d'une ressource protégée spécifique, et utilise le paramètre d'action que vous avez spécifié pour la ressource. Toutes les règles du groupe de règles Shield Advanced d'une ACL Web sont appliquées au trafic Web de toutes les ressources associées.
La modification du paramètre d'action peut prendre quelques secondes pour se propager. Pendant ce temps, il est possible que vous voyiez l'ancien paramètre à certains endroits où le groupe de règles est utilisé, et le nouveau paramètre à d'autres endroits.
Vous pouvez modifier le paramètre d'action des règles pour votre configuration d'atténuation automatique sur la page des événements de la console et via la page de configuration de la couche application. Pour plus d'informations sur la page des événements, consultez[Réagir aux événements DDo S dans AWS](ddos-responding.md). Pour plus d'informations sur la page de configuration, consultez[Configurer les protections de la couche DDo S de l'application](manage-protection.md#configure-app-layer-protection).
## Comment Shield Advanced gère les mesures d'atténuation lorsqu'une attaque s'atténue
Lorsque Shield Advanced détermine que les règles d'atténuation déployées pour une attaque particulière ne sont plus nécessaires, il les supprime du groupe de règles d'atténuation Shield Advanced.
La suppression des règles atténuantes ne coïncidera pas nécessairement avec la fin d'une attaque. Shield Advanced surveille les types d'attaques qu'il détecte sur vos ressources protégées. Il peut se défendre de manière proactive contre la récurrence d'une attaque portant une signature spécifique en maintenant en place les règles qu'il a déployées contre la survenue initiale de cette attaque. Au besoin, Shield Advanced augmente la période pendant laquelle il maintient les règles en place. Shield Advanced peut ainsi atténuer les attaques répétées avec une signature spécifique avant qu'elles n'affectent vos ressources protégées.
Shield Advanced ne supprime jamais la règle basée sur le débit`ShieldKnownOffenderIPRateBasedRule`, qui limite le volume de demandes provenant d'adresses IP connues pour être à l'origine d'attaques DDo S.
## Que se passe-t-il lorsque vous désactivez l'atténuation automatique
Shield Advanced effectue les opérations suivantes lorsque vous désactivez l'atténuation automatique pour une ressource :
+ **Arrête de répondre automatiquement aux attaques DDo S** : Shield Advanced arrête ses activités de réponse automatique pour la ressource.
+ **Supprime les règles inutiles du groupe de règles Shield Advanced** : si Shield Advanced gère des règles dans son groupe de règles géré pour le compte de la ressource protégée, il les supprime.
+ **Supprime le groupe de règles Shield Advanced s'il n'est plus utilisé** : si l'ACL Web que vous avez associée à la ressource n'est associée à aucune autre ressource pour laquelle l'atténuation automatique est activée, Shield Advanced supprime sa règle de groupe de règles de l'ACL Web.
# Protection de la couche applicative avec le groupe de règles Shield Advanced
Cette page explique le fonctionnement du groupe de règles Shield Advanced dans votre ACL Web.
Shield Advanced gère les activités d'atténuation automatique à l'aide des règles d'un groupe de règles qu'il possède et gère pour vous. Shield Advanced fait référence au groupe de règles par une règle de l'ACL Web que vous avez associée à votre ressource protégée.
**La règle du groupe de règles dans votre ACL Web**
La règle de groupe de règles Shield Advanced de votre ACL Web possède les propriétés suivantes :
+ **Nom** – `ShieldMitigationRuleGroup``_account-id_web-acl-id_unique-identifier`
+ **Unités de capacité Web ACL (WCU)** — 150. Ils sont WCUs pris en compte dans l'utilisation de la WCU dans votre ACL Web.
Shield Advanced crée cette règle dans votre ACL Web avec un paramètre de priorité de 10 000 000, afin qu'elle s'exécute après vos autres règles et groupes de règles dans l'ACL Web. AWS WAF exécute les règles dans une ACL Web à partir du paramètre de priorité numérique le plus bas. Au cours de votre gestion de l'ACL Web, ce paramètre de priorité peut changer.
La fonctionnalité d'atténuation automatique ne consomme aucune AWS WAF ressource supplémentaire dans votre compte, à l'exception de celles WCUs utilisées par le groupe de règles de votre ACL Web. Par exemple, le groupe de règles Shield Advanced n'est pas considéré comme l'un des groupes de règles de votre compte. Pour plus d'informations sur les limites de compte dans AWS WAF, voir[AWS WAF quotas](limits.md).
**Règles du groupe de règles**
Au sein du groupe de règles Shield Advanced référencé, Shield Advanced applique une règle basée sur le débit`ShieldKnownOffenderIPRateBasedRule`, qui limite le volume de demandes provenant d'adresses IP connues pour être à l'origine d'attaques DDo S. Cette règle constitue la première ligne de défense contre toute attaque, car elle est toujours présente dans le groupe de règles et ne repose pas sur l'analyse des modèles de trafic pour contenir les attaques. L'action de cette règle est définie en fonction de l'action que vous avez choisie pour vos atténuations automatiques, tout comme les autres règles du groupe de règles. Pour plus d'informations sur les règles basées sur les taux, consultez[Utilisation d'instructions de règles basées sur le taux dans AWS WAF](waf-rule-statement-type-rate-based.md).
**Note**
La règle basée sur le taux `ShieldKnownOffenderIPRateBasedRule` fonctionne indépendamment de la détection d'événements Shield Advanced. Lorsque l'atténuation automatique est activée, cette règle limite le débit des adresses IP connues pour être à l'origine des attaques DDo S. Pour ces adresses IP, la limitation du débit prévue par la règle permet de prévenir les attaques et d'empêcher les attaques d'apparaître dans les informations de détection du Shield Advanced. Ce compromis privilégie la prévention plutôt que la visibilité complète des modèles d'attaque.
Outre la règle permanente basée sur le taux décrite ci-dessus, le groupe de règles contient toutes les règles que Shield Advanced utilise actuellement pour atténuer les attaques DDo S. Shield Advanced ajoute, modifie et supprime ces règles selon les besoins. Pour plus d'informations, consultez [Comment Shield Advanced gère l'atténuation automatique](ddos-automatic-app-layer-response-behavior.md).
**Métriques**
Le groupe de règles génère AWS WAF des métriques, mais comme ce groupe de règles appartient à Shield Advanced, ces métriques ne peuvent pas être consultées. Pour de plus amples informations, veuillez consulter [AWS WAF métriques et dimensions](waf-metrics.md).
# Affichage de la configuration d'atténuation automatique de la couche d'application DDo S pour une ressource
Vous pouvez consulter la configuration d'atténuation automatique de la couche DDo S de l'application pour une ressource sur la page **Ressources protégées** et sur les pages de protection individuelles.
**Pour afficher la configuration d'atténuation automatique de la couche d'application DDo S**
1. Connectez-vous à la console AWS WAF & Shield AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Dans le volet AWS Shield de navigation, sélectionnez **Ressources protégées**. Dans la liste des ressources protégées, la colonne **Atténuation automatique de la couche d'application DDo S** indique si l'atténuation automatique est activée et, le cas échéant, l'action que Shield Advanced doit utiliser pour ses mesures d'atténuation.
Vous pouvez également sélectionner n'importe quelle ressource de la couche application pour voir les mêmes informations répertoriées sur la page de protection de la ressource.
# Activation et désactivation de l'atténuation automatique de la couche d'application DDo S
La procédure suivante indique comment activer ou désactiver la réponse automatique pour une ressource protégée.
**Pour activer ou désactiver l'atténuation automatique de la couche d'application DDo S pour une seule ressource**
1. Connectez-vous à la console AWS WAF & Shield AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Dans le volet AWS Shield de navigation, sélectionnez **Ressources protégées**.
1. Dans l'onglet **Protections**, sélectionnez la ressource de couche d'application pour laquelle vous souhaitez activer l'atténuation automatique. La page de protection de la ressource s'ouvre.
1. Sur la page de protection de la ressource, choisissez **Modifier**.
1. Sur la page **Configurer l'atténuation de la couche 7 DDo S pour les ressources globales - *facultatif***, pour l'**atténuation automatique de la couche DDo S de l'application**, choisissez l'option que vous souhaitez utiliser pour les atténuations automatiques. Les options de la console sont les suivantes :
+ **Conserver les paramètres actuels** : n'apportez aucune modification aux paramètres d'atténuation automatique de la ressource protégée.
+ **Activer** — Activez l'atténuation automatique pour la ressource protégée. Lorsque vous choisissez cette option, sélectionnez également l'action de règle que vous souhaitez que les atténuations automatiques utilisent dans les règles ACL Web. Pour plus d'informations sur les paramètres d'action des règles, consultez[Utilisation des actions liées aux règles dans AWS WAF](waf-rule-action.md).
Si votre ressource protégée n'a pas encore d'historique du trafic normal des applications, activez l'atténuation automatique en Count mode jusqu'à ce que Shield Advanced puisse établir une base de référence. Shield Advanced commence à collecter des informations pour sa base de référence lorsque vous associez une ACL Web à votre ressource protégée, et l'établissement d'une bonne base de trafic normal peut prendre de 24 heures à 30 jours.
+ **Désactiver** : désactive l'atténuation automatique pour la ressource protégée.
1. Parcourez le reste des pages jusqu'à ce que vous ayez terminé et enregistrez la configuration.
Sur la page **Protections**, les paramètres d'atténuation automatique sont mis à jour pour la ressource.
# Modification de l'action utilisée pour l'atténuation automatique de la couche d'application DDo S
Vous pouvez modifier l'action utilisée par Shield Advanced pour sa réponse automatique de la couche application à plusieurs emplacements de la console :
+ **Configuration de l'atténuation automatique** : modifiez l'action lorsque vous configurez l'atténuation automatique pour votre ressource. Pour la procédure, reportez-vous à la section précédente[Activation et désactivation de l'atténuation automatique de la couche d'application DDo S](enable-disable-automatic-app-layer-response.md).
+ **Page de détails de l'événement** : modifiez l'action dans la page des détails de l'événement lorsque vous consultez les informations relatives à l'événement dans la console. Pour plus d'informations, consultez [Afficher les détails de AWS Shield Advanced l'événement](ddos-event-details.md).
Si vous avez deux ressources protégées qui partagent une ACL Web et que vous définissez l'action sur l'une et Count Block pour l'autre, Shield Advanced définit l'action de la règle `ShieldKnownOffenderIPRateBasedRule` basée sur le taux du groupe de règles sur. Block
# Utilisation AWS CloudFormation avec atténuation automatique de la couche DDo S de l'application
Cette page explique comment utiliser CloudFormation pour gérer vos protections et AWS WAF le Web ACLs.
**Activation ou désactivation de l'atténuation automatique de la couche d'application DDo S**
Vous pouvez activer et désactiver l'atténuation automatique de la couche DDo S de l'application par AWS CloudFormation le biais de la `AWS::Shield::Protection` ressource. L'effet est le même que lorsque vous activez ou désactivez la fonctionnalité via la console ou toute autre interface. Pour plus d'informations sur CloudFormation cette ressource, reportez-vous [AWS::Shield::Protection](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-shield-protection.html)au *guide de l'AWS CloudFormation utilisateur*.
**Gestion de l' ACLs utilisation du Web avec atténuation automatique**
Shield Advanced gère l'atténuation automatique de votre ressource protégée à l'aide d'une règle de groupe de règles dans l'ACL AWS WAF Web de la ressource protégée. Par le biais de la AWS WAF console APIs, vous verrez la règle répertoriée dans vos règles ACL Web, avec un nom commençant par`ShieldMitigationRuleGroup`. Cette règle est dédiée à l'atténuation automatique de la couche DDo S de votre application et elle est gérée pour vous par Shield Advanced et AWS WAF. Pour plus d’informations, consultez [Protection de la couche applicative avec le groupe de règles Shield Advanced](ddos-automatic-app-layer-response-rg.md) et [Comment Shield Advanced gère l'atténuation automatique](ddos-automatic-app-layer-response-behavior.md).
Si vous avez l' CloudFormation habitude de gérer votre site Web ACLs, n'ajoutez pas la règle de groupe de règles Shield Advanced à votre modèle d'ACL Web. Lorsque vous mettez à jour une ACL Web qui est utilisée avec vos protections d'atténuation automatiques, gère AWS WAF automatiquement la règle du groupe de règles dans l'ACL Web.
Vous constaterez les différences suivantes par rapport aux autres sites Web ACLs que vous gérez CloudFormation :
+ CloudFormation ne signalera aucune dérive de l'état de dérive de la pile entre la configuration réelle de l'ACL Web, avec la règle du groupe de règles Shield Advanced, et votre modèle d'ACL Web, sans la règle. La règle Shield Advanced n'apparaîtra pas dans la liste réelle de la ressource dans les détails de dérive.
Vous pourrez voir la règle du groupe de règles Shield Advanced dans les listes d'ACL Web que vous AWS WAF recherchez, par exemple via la AWS WAF console ou AWS WAF APIs.
+ Si vous modifiez le modèle d'ACL Web dans une pile AWS WAF et que Shield Advanced conserve automatiquement la règle d'atténuation automatique Shield Advanced dans l'ACL Web mise à jour. Les protections d'atténuation automatiques fournies par Shield Advanced ne sont pas interrompues par votre mise à jour de l'ACL Web.
Ne gérez pas la règle Shield Advanced dans votre modèle ACL CloudFormation Web. Le modèle ACL Web ne doit pas répertorier la règle Shield Advanced. Suivez les meilleures pratiques en matière de gestion des ACL Web à l'adresse[Bonnes pratiques pour l'utilisation de l'atténuation automatique de la couche d'application DDo S](ddos-automatic-app-layer-response-bp.md).
# Détection basée sur l'état à l'aide de contrôles de santé avec Shield Advanced et Route 53
Vous pouvez configurer Shield Advanced pour utiliser la détection basée sur l'état de santé afin d'améliorer la réactivité et la précision de la détection et de l'atténuation des attaques. Vous pouvez utiliser cette option avec n'importe quel type de ressource, à l'exception des zones hébergées Route 53.
Pour configurer la détection basée sur l'état de santé, vous définissez un bilan de santé pour votre ressource dans Route 53, vous vérifiez qu'elle indique qu'elle est saine, puis vous l'associez à votre protection Shield Advanced. Pour plus d'informations sur les bilans de santé de Route 53, consultez [Comment Amazon Route 53 vérifie l'état de vos ressources](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/welcome-health-checks.html) et [Création, mise à jour et suppression de bilans de santé](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-deleting.html) dans le guide du développeur Amazon Route 53.
**Note**
Des bilans de santé sont requis pour le support d'engagement proactif de la Shield Response Team (SRT). Pour plus d'informations sur l'engagement proactif, consultez[Mettre en place un engagement proactif pour que le SRT vous contacte directement](ddos-srt-proactive-engagement.md).
Les bilans de santé mesurent l'état de santé de vos ressources en fonction des exigences que vous définissez. L'état du bilan de santé fournit des informations essentielles aux mécanismes de détection Shield Advanced, leur conférant une plus grande sensibilité à l'état actuel de vos applications spécifiques.
Vous pouvez activer la détection basée sur l'état de santé pour tous les types de ressources, à l'exception des zones hébergées Route 53.
+ **Ressources du réseau et de la couche transport (couche 3/couche 4)** : la détection basée sur l'intégrité améliore la précision de la détection et de l'atténuation des événements au niveau des couches réseau et transport pour les équilibreurs de charge réseau, les adresses IP élastiques et les accélérateurs standard Global Accelerator. Lorsque vous protégez ces types de ressources avec Shield Advanced, Shield Advanced peut atténuer les attaques de moindre envergure et atténuer plus rapidement les attaques, même lorsque le trafic est dans les limites des capacités de l'application.
Lorsque vous ajoutez une détection basée sur l'état de santé, pendant les périodes où le bilan de santé associé n'est pas satisfaisant, Shield Advanced peut appliquer des mesures d'atténuation encore plus rapidement et à des seuils encore plus bas.
+ **Ressources de la couche application (couche 7)** : la détection basée sur l'état de santé améliore la précision de la détection des inondations de requêtes Web pour les CloudFront distributions et les équilibreurs de charge des applications. Lorsque vous protégez ces types de ressources avec Shield Advanced, vous recevez des alertes de détection des inondations de requêtes Web en cas d'écart statistiquement significatif du volume de trafic combiné à des modifications importantes des modèles de trafic, en fonction des caractéristiques des demandes.
Grâce à la détection basée sur l'état de santé, lorsque le bilan de santé associé à Route 53 ne fonctionne pas correctement, Shield Advanced nécessite des écarts minimes pour alerter et signale les événements plus rapidement. À l'inverse, lorsque le bilan de santé associé à Route 53 est sain, Shield Advanced nécessite des écarts plus importants pour émettre une alerte.
L'utilisation d'un bilan de santé avec Shield Advanced vous sera particulièrement utile si le bilan de santé indique uniquement que votre application fonctionne selon des paramètres acceptables et qu'il ne l'est pas lorsque ce n'est pas le cas. Suivez les instructions de cette section pour gérer vos associations de bilans de santé dans Shield Advanced.
**Note**
Shield Advanced ne gère pas automatiquement vos bilans de santé.
Les éléments suivants sont nécessaires pour utiliser un bilan de santé avec Shield Advanced :
+ Le bilan de santé doit indiquer qu'il est sain lorsque vous l'associez à votre protection Shield Advanced.
+ Le bilan de santé doit être pertinent par rapport à l'état de santé de votre ressource protégée. Vous êtes responsable de définir et de maintenir des bilans de santé qui indiquent avec précision l'état de santé de votre application, en fonction des exigences spécifiques de votre application.
+ Le bilan de santé doit rester disponible pour être utilisé par la protection Shield Advanced. Ne supprimez pas un bilan de santé dans Route 53 que vous utilisez pour une protection Shield Advanced.
**Contents**
+ [Bonnes pratiques pour l'utilisation des contrôles de santé avec Shield Advanced](health-checks-best-practices.md)
+ [CloudWatch métriques couramment utilisées pour les bilans de santé avec Shield Advanced](health-checks-metrics.md)
+ [Métriques utilisées pour surveiller l'état de santé des applications](health-checks-metrics.md#health-checks-metrics-common)
+ [Statistiques CloudWatch Amazon pour chaque type de ressource](health-checks-metrics.md#health-checks-protected-resource-metrics)
+ [Associer un bilan de santé à votre ressource protégée par Shield Advanced](associate-health-check.md)
+ [Dissocier un bilan de santé de votre ressource protégée par Shield Advanced](disassociate-health-check.md)
+ [Afficher le statut d'une association de vérification de l'état dans Shield Advanced](health-check-association-status.md)
+ [Exemples de bilans de santé pour Shield Advanced](health-checks-examples.md)
+ [CloudFront Distributions Amazon](health-checks-examples.md#health-checks-example-cloudfront)
+ [Équilibreurs de charge](health-checks-examples.md#health-checks-example-load-balancer)
+ [Adresse IP Amazon EC2 Elastic (EIP)](health-checks-examples.md#health-checks-example-elastic-ip)
# Bonnes pratiques pour l'utilisation des contrôles de santé avec Shield Advanced
Suivez les meilleures pratiques décrites dans cette section lorsque vous créez et utilisez des tests de santé avec Shield Advanced.
+ Planifiez vos bilans de santé en identifiant les composants de votre infrastructure que vous souhaitez surveiller. Tenez compte des types de ressources suivants pour les bilans de santé :
+ Ressources critiques.
+ Toutes les ressources pour lesquelles vous souhaitez une plus grande sensibilité dans le cadre de la détection et de l'atténuation Shield Advanced.
+ Ressources pour lesquelles vous souhaitez que Shield Advanced vous contacte de manière proactive. L'engagement proactif est influencé par l'état de vos bilans de santé.
Parmi les ressources que vous souhaiterez peut-être surveiller, citons les CloudFront distributions Amazon, les équilibreurs de charge connectés à Internet et les instances Amazon EC2.
+ Définissez des contrôles de santé qui reflètent avec précision l'état de santé de l'origine de votre application avec le moins de notifications possible.
+ Rédigez des bilans de santé de manière à ce qu'ils ne soient défectueux que lorsque votre application n'est pas disponible ou ne fonctionne pas selon les paramètres acceptables. Vous êtes responsable de définir et de maintenir les bilans de santé en fonction des exigences spécifiques de votre application.
+ Effectuez le moins de bilans de santé possible tout en fournissant des rapports précis sur l'état de santé de votre application. Par exemple, plusieurs alarmes provenant de plusieurs domaines de votre application qui signalent toutes le même problème peuvent alourdir vos activités de réponse sans ajouter de valeur informative.
+ Utilisez des bilans de santé calculés pour surveiller l'état de santé des applications à l'aide d'une combinaison de CloudWatch mesures Amazon. Par exemple, vous pouvez calculer l'état de santé combiné en fonction de la latence de vos serveurs d'applications et de leurs taux d'erreur 5xx, ce qui indique que le serveur d'origine n'a pas répondu à la demande.
+ Créez et publiez vos propres indicateurs de santé des applications sous forme de métriques CloudWatch personnalisées selon les besoins et utilisez-les dans un bilan de santé calculé.
+ Mettez en œuvre et gérez vos bilans de santé afin d'améliorer la détection et de réduire les activités de maintenance inutiles.
+ Avant d'associer un bilan de santé à une protection Shield Advanced, assurez-vous qu'elle est en bon état. Associer un bilan de santé signalant un dysfonctionnement peut fausser les mécanismes de détection de Shield Advanced pour vos ressources protégées.
+ Gardez vos bilans de santé à la disposition de Shield Advanced. Ne supprimez pas un bilan de santé dans Route 53 que vous utilisez pour une protection Shield Advanced.
+ Utilisez des environnements de test et de test uniquement pour tester vos bilans de santé. Conservez les associations de contrôle de santé uniquement pour les environnements nécessitant des performances et une disponibilité au niveau de la production. Ne maintenez pas l'association entre les contrôles de santé dans Shield Advanced pour les environnements de préparation et de test.
# CloudWatch métriques couramment utilisées pour les bilans de santé avec Shield Advanced
Cette section répertorie les CloudWatch métriques Amazon couramment utilisées dans les bilans de santé pour mesurer l'état des applications lors d'événements de déni de service (DDoS) distribué. Pour obtenir des informations complètes sur les CloudWatch mesures pour chaque type de ressource, consultez la liste qui suit le tableau.
**Topics**
+ [Métriques utilisées pour surveiller l'état de santé des applications](#health-checks-metrics-common)
+ [Statistiques CloudWatch Amazon pour chaque type de ressource](#health-checks-protected-resource-metrics)
## Métriques utilisées pour surveiller l'état de santé des applications
| Ressource | Métrique | Description |
| --- | --- | --- |
| Route 53 | `HealthCheckStatus` | État du point de terminaison du bilan de santé. |
| CloudFront | `5xxErrorRate` | Pourcentage de toutes les demandes pour lesquelles le code d'état HTTP est 5xx. Cela indique une attaque qui a un impact sur l'application. |
| Application Load Balancer | `HTTPCode_ELB_5XX_Count` | Nombre de codes d'erreur client HTTP 5xx générés par l'équilibreur de charge. |
| Application Load Balancer | `RejectedConnectionCount` | Nombre de connexions rejetées parce que l'équilibreur de charge a atteint son nombre maximal de connexions. |
| Application Load Balancer | `TargetConnectionErrorCount` | Nombre de connexions qui n'ont pas été établies avec succès entre l'équilibreur de charge et la cible. |
| Application Load Balancer | `TargetResponseTime` | Temps écoulé en secondes après que la demande a quitté l'équilibreur de charge et lorsqu'elle a reçu une réponse de la cible. |
| Application Load Balancer | `UnHealthyHostCount` | Nombre de cibles considérées non saines. |
| Amazon EC2 | `CPUUtilization` | Pourcentage d'unités de EC2 calcul allouées actuellement utilisées. |
## Statistiques CloudWatch Amazon pour chaque type de ressource
Pour plus d'informations sur les mesures disponibles pour vos ressources protégées, consultez les sections suivantes des guides de ressources :
+ Amazon Route 53 — [Surveillez vos ressources grâce aux bilans de santé d'Amazon Route 53 et CloudWatch à Amazon](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html) dans le guide du développeur Amazon Route 53.
+ Amazon CloudFront — [La surveillance CloudFront avec Amazon est décrite CloudWatch](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/monitoring-using-cloudwatch.html) dans le manuel Amazon CloudFront Developer Guide.
+ Application Load Balancer : [CloudWatch indicateurs relatifs à votre Application Load](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) Balancer dans le guide d'utilisation des Application Load Balancer.
+ Network Load Balancer : [CloudWatch indicateurs relatifs à votre Network Load](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html) Balancer dans le guide de l'utilisateur pour les Network Load Balancers.
+ AWS Global Accelerator — [Utilisation CloudWatch d'Amazon AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/cloudwatch-monitoring.html) dans le manuel du AWS Global Accelerator développeur.
+ Amazon Elastic Compute Cloud — [Répertoriez les CloudWatch métriques disponibles pour vos instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) dans les https://docs.aws.amazon.com/AWSEC2/ dernières/ /. UserGuide
+ Amazon EC2 Auto Scaling — [Surveillez CloudWatch les métriques pour vos groupes et instances Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) dans le guide de l'utilisateur d'Amazon EC2 Auto Scaling.
# Associer un bilan de santé à votre ressource protégée par Shield Advanced
La procédure suivante explique comment associer un bilan de santé Amazon Route 53 à une ressource protégée.
**Note**
Avant d'associer un bilan de santé à une protection Shield Advanced, assurez-vous qu'elle est en bon état. Pour plus d'informations, consultez la section [Surveillance de l'état du bilan de santé et réception de notifications](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-monitor-view-status.html) dans le guide du développeur Amazon Route 53.
**Pour associer un bilan de santé**
1. Connectez-vous à la console AWS WAF & Shield AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Dans le volet AWS Shield de navigation, sélectionnez **Ressources protégées**.
1. Dans l'onglet **Protections**, sélectionnez la ressource que vous souhaitez associer à un bilan de santé.
1. Choisissez **Configurer les protections**.
1. Choisissez **Suivant** jusqu'à ce que vous arriviez à la page **Configurer le contrôle de santé basé sur la détection DDo S *(facultatif)***.
1. Sous **Associated Health Check (Vérification de l’état de santé associée)**, choisissez l'ID de la vérification de l’état de santé que vous souhaitez associer à la protection.
**Note**
Si le bilan de santé dont vous avez besoin ne s'affiche pas, accédez à la console Route 53 et vérifiez le bilan de santé et son identifiant. Pour plus d'informations, consultez [Creating and Updating Health Checks (Création et mise à jour des vérifications de l’état de santé)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html).
1. Parcourez le reste des pages jusqu'à ce que vous ayez terminé la configuration. Sur la page **Protections**, votre association de contrôle de santé mise à jour est répertoriée pour la ressource.
1. Sur la page **Protections**, vérifiez que le bilan de santé que vous venez d'associer indique que vous êtes en bonne santé.
Vous ne pouvez pas commencer à utiliser un bilan de santé dans Shield Advanced alors que le bilan de santé indique un dysfonctionnement. Cela permet à Shield Advanced de détecter les faux positifs à des seuils très bas et peut également avoir un impact négatif sur la capacité de la Shield Response Team (SRT) à impliquer de manière proactive la ressource.
Si le nouveau bilan de santé associé indique un état insalubre, procédez comme suit :
1. Dissociez le bilan de santé de votre protection dans Shield Advanced.
1. Consultez les spécifications de votre bilan de santé dans Amazon Route 53 et vérifiez les performances et la disponibilité globales de vos applications.
1. Lorsque les performances de votre application sont conformes à vos paramètres de santé et que votre bilan de santé indique qu'il est bon, essayez à nouveau d'associer le bilan de santé dans Shield Advanced.
La procédure d'association de bilans de santé est terminée lorsque vous avez créé votre nouvelle association de bilans de santé et qu'elle indique qu'elle est saine dans Shield Advanced.
# Dissocier un bilan de santé de votre ressource protégée par Shield Advanced
La procédure suivante explique comment dissocier un bilan de santé Amazon Route 53 d'une ressource protégée.
**Pour dissocier un bilan de santé**
1. Connectez-vous à la console AWS WAF & Shield AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Dans le volet AWS Shield de navigation, sélectionnez **Ressources protégées**.
1. Dans l'onglet **Protections**, sélectionnez la ressource que vous souhaitez dissocier d'un bilan de santé.
1. Choisissez **Configurer les protections**.
1. Choisissez **Suivant** jusqu'à ce que vous arriviez à la page **Configurer le contrôle de santé basé sur la détection DDo S *(facultatif)***.
1. Sous **Associated Health Check**, choisissez l'option vide, répertoriée sous la forme **-**.
1. Parcourez le reste des pages jusqu'à ce que vous ayez terminé la configuration.
Sur la page **Protections**, le champ de vérification de l'état de votre ressource est défini sur **-**, ce qui indique qu'il n'y a aucune association avec le bilan de santé.
# Afficher le statut d'une association de vérification de l'état dans Shield Advanced
Vous pouvez consulter l'état du bilan de santé associé à une protection sur la page des **ressources protégées** de la console AWS WAF & Shield et sur la page de détails de chaque ressource.
+ **En bonne** santé — Le bilan de santé est disponible et indique que vous êtes en bonne santé.
+ **Malsain** — Le bilan de santé est disponible et indique un état de santé malsain.
+ Non **disponible** — Le bilan de santé n'est pas disponible pour Shield Advanced.
**Pour résoudre un bilan de santé **non disponible****
Créez et utilisez un nouveau bilan de santé. N'essayez pas d'associer à nouveau un bilan de santé lorsqu'il est devenu indisponible dans Shield Advanced.
Pour obtenir des instructions détaillées sur la manière de suivre ces étapes, consultez les rubriques précédentes.
1. Dans Shield Advanced, dissociez le bilan de santé de la ressource.
1. Dans Route 53, créez un nouveau bilan de santé pour la ressource et notez son identifiant. Pour plus d'informations, consultez [Creating and Updating Health Checks](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html) dans le manuel Amazon Route 53 Developer Guide.
1. Dans Shield Advanced, associez le nouveau bilan de santé à la ressource.
# Exemples de bilans de santé pour Shield Advanced
Cette section présente des exemples de bilans de santé que vous pourriez utiliser dans un bilan de santé calculé. Un bilan de santé calculé utilise un certain nombre de bilans de santé individuels pour déterminer un statut combiné. Le statut de chaque bilan de santé individuel est basé sur l'état d'un terminal ou sur l'état d'une CloudWatch métrique Amazon. Vous combinez les bilans de santé dans un bilan de santé calculé, puis vous configurez votre bilan de santé calculé pour signaler l'état de santé en fonction de l'état de santé combiné des bilans de santé individuels. Ajustez la sensibilité de vos bilans de santé calculés en fonction de vos exigences en matière de performances et de disponibilité des applications.
Pour plus d'informations sur les bilans de santé calculés, consultez [la section Surveillance des autres bilans de santé (bilans de santé calculés)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-values.html#health-checks-creating-values-calculated) dans le manuel Amazon Route 53 Developer Guide. Pour plus d'informations, consultez le billet de blog [Améliorations de Route 53 — Calculated Health Checks and Latency Checks](https://aws.amazon.com/blogs/aws/route-53-improvements-calculated-health-checks-and-latency-checks/).
**Topics**
+ [CloudFront Distributions Amazon](#health-checks-example-cloudfront)
+ [Équilibreurs de charge](#health-checks-example-load-balancer)
+ [Adresse IP Amazon EC2 Elastic (EIP)](#health-checks-example-elastic-ip)
## CloudFront Distributions Amazon
Les exemples suivants décrivent les bilans de santé qui peuvent être combinés dans un bilan de santé calculé pour une CloudFront distribution :
+ Surveillez un point de terminaison en spécifiant un nom de domaine vers un chemin sur la distribution qui diffuse du contenu dynamique. Une réponse saine inclurait les codes de réponse HTTP 2xx et 3xx.
+ Surveillez l'état d'une CloudWatch alarme qui mesure l'état de santé de CloudFront son origine. Par exemple, vous pouvez maintenir une CloudWatch alarme sur la métrique `TargetResponseTime` Application Load Balancer et créer un bilan de santé qui reflète l'état de l'alarme. Le bilan de santé peut être défaillant lorsque le temps de réponse, entre la demande quittant l'équilibreur de charge et le moment où l'équilibreur de charge reçoit une réponse de la cible, dépasse le seuil configuré dans l'alarme.
+ Surveillez l'état d'une CloudWatch alarme qui mesure le pourcentage de demandes pour lesquelles le code d'état HTTP de la réponse est 5xx. Si le taux d'erreur 5xx de la CloudFront distribution est supérieur au seuil défini dans l' CloudWatch alarme, le statut de ce bilan de santé passe en état de mauvais état.
## Équilibreurs de charge
Les exemples suivants décrivent les contrôles de santé qui peuvent être utilisés dans les contrôles de santé calculés pour un accélérateur standard Application Load Balancer, Network Load Balancer ou Global Accelerator.
+ Surveillez l'état d'une CloudWatch alarme qui mesure le nombre de nouvelles connexions établies par les clients à l'équilibreur de charge. Vous pouvez définir le seuil d'alarme pour le nombre moyen de nouvelles connexions à un certain degré supérieur à votre moyenne quotidienne. Les mesures pour chaque type de ressource sont les suivantes :
+ Application Load Balancer : `NewConnectionCount`
+ Network Load Balancer : `ActiveFlowCount`
+ Accélérateur mondial : `NewFlowCount`
+ Pour Application Load Balancer et Network Load Balancer, surveillez l'état d' CloudWatch une alarme qui mesure le nombre d'équilibreurs de charge considérés comme sains. Vous pouvez définir le seuil d'alarme soit sur la zone de disponibilité, soit sur le nombre minimum d'hôtes sains requis par votre équilibreur de charge. Les mesures disponibles pour les ressources de l'équilibreur de charge sont les suivantes :
+ Application Load Balancer : `HealthyHostCount`
+ Network Load Balancer : `HealthyHostCount`
+ Pour Application Load Balancer, surveillez l'état d'une CloudWatch alarme qui mesure le nombre de codes de réponse HTTP 5xx générés par les cibles de l'équilibreur de charge. Pour un Application Load Balancer, vous pouvez utiliser la métrique `HTTPCode_Target_5XX_Count` et baser le seuil d'alarme sur la somme de toutes les erreurs 5xx de l'équilibreur de charge.
## Adresse IP Amazon EC2 Elastic (EIP)
Les exemples de tests de santé suivants peuvent être combinés dans un bilan de santé calculé pour une adresse IP Amazon EC2 Elastic :
+ Surveillez un point de terminaison en spécifiant une adresse IP pour l'adresse IP élastique. Le bilan de santé restera sain tant qu'une connexion TCP pourra être établie avec la ressource qui se trouve derrière l'adresse IP.
+ Surveillez l'état d'une CloudWatch alarme qui mesure le pourcentage d'unités de EC2 calcul Amazon allouées actuellement utilisées sur l'instance. Vous pouvez utiliser la EC2 métrique Amazon `CPUUtilization` et baser le seuil d'alarme sur ce que vous considérez comme un taux d'utilisation du processeur élevé pour votre application, tel que 90 %.
# Ajouter AWS Shield Advanced une protection aux AWS ressources
Suivez les instructions de cette section pour ajouter la protection Shield Advanced à une ou plusieurs ressources.
**Pour ajouter une protection à une AWS ressource**
1. Connectez-vous à la console AWS WAF & Shield AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Dans le volet de navigation, AWS Shield sélectionnez **Ressources protégées**.
1. Choisissez **Ajouter des ressources à protéger**.
1. Sur la page **Choisissez les ressources à protéger avec Shield Advanced**, dans **Spécifiez la région et les types de ressources**, indiquez les spécifications de région et de type de ressource pour les ressources que vous souhaitez protéger. Vous pouvez protéger les ressources de plusieurs régions en sélectionnant **Toutes les régions** et vous pouvez restreindre la sélection aux ressources mondiales en sélectionnant **Global**. Vous pouvez désélectionner les types de ressources que vous ne souhaitez pas protéger. Pour plus d'informations sur les protections de vos types de ressources, consultez[Liste des ressources qui AWS Shield Advanced protègent](ddos-protections-by-resource-type.md).
1. Choisissez **Charger les ressources**. Shield Advanced renseigne la section **Select Resources** avec les AWS ressources correspondant à vos critères.
1. Dans la section **Sélectionner les ressources**, vous pouvez filtrer la liste des ressources en saisissant une chaîne à rechercher dans les listes de ressources.
Sélectionnez les ressources que vous souhaitez protéger.
1. Dans la section **Tags**, si vous souhaitez ajouter des balises aux protections Shield Advanced que vous créez, spécifiez-les. Pour plus d'informations sur le balisage AWS des ressources, consultez la section [Utilisation de l'éditeur de balises](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html).
1. Choisissez **Protect with Shield Advanced**. Cela ajoute les protections Shield Advanced aux ressources.
# AWS Shield Advanced Protections d'édition
Vous pouvez modifier les paramètres de vos AWS Shield Advanced protections à tout moment. Pour ce faire, parcourez les options correspondant aux protections que vous avez sélectionnées et modifiez les paramètres que vous devez modifier.
**Pour gérer les ressources protégées**
1. Connectez-vous à la console AWS WAF & Shield AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Dans le volet AWS Shield de navigation, sélectionnez **Ressources protégées**.
1. Dans l'onglet **Protections**, sélectionnez les ressources que vous souhaitez protéger.
1. Choisissez **Configurer les protections** et l'option de spécification des ressources que vous souhaitez.
1. Passez en revue chacune des options de protection des ressources et apportez les modifications nécessaires.
## Configurer les protections de la couche DDo S de l'application
Pour vous protéger contre les attaques visant les ressources Amazon CloudFront et Application Load Balancer, vous pouvez ajouter des règles AWS WAF Web ACLs et des règles basées sur le taux. Pour plus d'informations à ce sujet, consultez[Protection de la couche applicative avec AWS WAF Web ACLs et Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md).
Vous pouvez également activer l'atténuation automatique de la couche d'application DDo S de Shield Advanced. Pour plus d'informations sur le AWS WAF fonctionnement, voir[AWS WAF](waf-chapter.md). Pour plus d'informations sur la fonction d'atténuation automatique, consultez[Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md).
**Important**
Si vous gérez vos protections Shield Advanced à AWS Firewall Manager l'aide d'une politique Shield Advanced, vous ne pouvez pas gérer les protections de la couche application ici. Pour toutes les autres ressources, nous vous recommandons d'associer au minimum une ACL Web à chaque ressource, même si l'ACL Web ne contient aucune règle.
**Note**
Lorsque vous activez l'atténuation automatique de la couche DDo S de l'application pour une ressource, si nécessaire, l'opération ajoute automatiquement un rôle lié à un service à votre compte afin de donner à Shield Advanced les autorisations dont il a besoin pour gérer vos protections ACL Web. Pour plus d'informations, consultez [Utilisation de rôles liés à un service pour Shield Advanced](shd-using-service-linked-roles.md).
**Pour configurer les protections de la couche DDo d'application S**
1. Sur la page **Configurer les protections de la couche 7 DDo S**, si la ressource n'est pas déjà associée à une ACL Web, vous pouvez choisir une ACL Web existante ou créer la vôtre.
Pour créer une liste ACL web, procédez comme suit :
1. Sélectionnez **Create web ACL**.
1. Entrez un nom. Vous ne pouvez pas modifier le nom une fois que vous créez la liste ACL web.
1. Choisissez **Créer**.
**Note**
Si une ressource est déjà associée à une liste ACL web, vous ne pouvez pas passer à une autre liste ACL web. Si vous souhaitez modifier l'ACL Web, vous devez d'abord supprimer le site Web associé ACLs de la ressource. Pour de plus amples informations, veuillez consulter [Associer ou dissocier une protection à une ressource AWS](web-acl-associating-aws-resource.md).
1. Si aucune règle basée sur le taux n'est définie dans l'ACL Web, vous pouvez en ajouter une en choisissant **Ajouter une règle de limite de débit**, puis en effectuant les étapes suivantes :
1. Entrez un nom.
1. Entrez une limite de débit. Il s'agit du nombre maximum de demandes autorisées sur une période de cinq minutes à partir d'une adresse IP unique avant que l'action de la règle basée sur le taux ne soit appliquée à l'adresse IP. Lorsque les demandes provenant de l'adresse IP tombent en dessous de la limite, l'action est interrompue.
1. Définissez l'action de règle pour compter ou bloquer les demandes provenant d'adresses IP lorsque le nombre de demandes dépasse la limite. L'action d'application et de suppression de la règle peut prendre effet une minute ou deux après la modification du taux de demandes d'adresse IP.
1. Choisissez **Ajouter une règle**.
1. Pour l'**atténuation automatique de la couche DDo S de l'application**, choisissez si vous souhaitez que Shield Advanced atténue automatiquement les attaques DDo S en votre nom, comme suit :
+ Pour activer l'atténuation automatique, choisissez **Enable**, puis sélectionnez l'action de AWS WAF règle que Shield Advanced doit utiliser dans ses règles personnalisées. Vos choix sont Count etBlock. Pour plus d'informations sur ces actions liées aux AWS WAF règles, consultez[Utilisation des actions liées aux règles dans AWS WAF](waf-rule-action.md). Pour plus d'informations sur la façon dont Shield Advanced gère ce paramètre d'action, consultez[Comment Shield Advanced gère le paramètre d'action des règles](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-rule-action).
+ Pour désactiver l'atténuation automatique, choisissez **Désactiver**.
+ Pour que les paramètres d'atténuation automatique restent inchangés pour les ressources que vous gérez, laissez le choix par défaut **Conserver les paramètres actuels**.
Pour plus d'informations sur l'atténuation automatique de la couche d'application DDo S de Shield Advanced, consultez[Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md).
1. Choisissez **Suivant**.
# Création d'alarmes et de notifications pour les ressources protégées par Shield Advanced
La procédure suivante indique comment gérer les CloudWatch alarmes pour les ressources protégées.
**Note**
CloudWatch entraîne des coûts supplémentaires. Pour CloudWatch connaître les tarifs, consultez [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/).
**Pour créer des alarmes et des notifications**
1. Sur la page de protection **Créer des alarmes et des notifications *(facultatif)***, configurez les rubriques SNS pour les alarmes et les notifications que vous souhaitez recevoir. Pour les ressources pour lesquelles vous ne souhaitez pas de notifications, choisissez **No topic (Aucune rubrique)**. Vous pouvez ajouter une rubrique Amazon SNS ou en créer une nouvelle.
1. Pour créer une rubrique Amazon SNS, procédez comme suit :
1. Dans la liste déroulante, choisissez **Créer une rubrique SNS.**
1. Saisissez un nom de rubrique.
1. Entrez éventuellement une adresse e-mail à laquelle les messages Amazon SNS seront envoyés, puis choisissez **Ajouter** un e-mail. Vous pouvez en saisir plusieurs.
1. Choisissez **Créer**.
1. Choisissez **Suivant**.
# Supprimer AWS Shield Advanced la protection d'une AWS ressource
Vous pouvez supprimer AWS Shield Advanced la protection de n'importe laquelle de vos AWS ressources à tout moment.
**Important**
La suppression d'une AWS ressource n'entraîne pas la suppression de la ressource de AWS Shield Advanced. Vous devez également supprimer la protection de la ressource AWS Shield Advanced, comme décrit dans cette procédure.
**Supprimer AWS Shield Advanced la protection d'une AWS ressource**
1. Connectez-vous à la console AWS WAF & Shield AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Dans le volet AWS Shield de navigation, sélectionnez **Ressources protégées**.
1. Dans l'onglet **Protections**, sélectionnez les ressources dont vous souhaitez supprimer les protections.
1. Choisissez **Supprimer les protections**.
1. Si une CloudWatch alarme Amazon est configurée pour une protection, vous avez la possibilité de supprimer l'alarme en même temps que la protection. Si vous choisissez de ne pas supprimer l'alarme à ce stade, vous pouvez la supprimer ultérieurement à l'aide de la CloudWatch console.
**Note**
Pour les protections pour lesquelles un bilan de santé Amazon Route 53 est configuré, si vous ajoutez à nouveau la protection ultérieurement, la protection inclut toujours le bilan de santé.
Les étapes précédentes suppriment AWS Shield Advanced la protection de AWS ressources spécifiques. Ils n'annulent pas votre AWS Shield Advanced abonnement. Le service continuera de vous être facturé. Pour plus d'informations sur votre AWS Shield Advanced abonnement, contactez le [AWS Support Centre](https://console.aws.amazon.com/support/home#/).
## Supprimer une CloudWatch alarme de vos protections Shield Advanced
Pour supprimer une CloudWatch alarme de vos protections Shield Advanced, effectuez l'une des opérations suivantes :
+ Supprimer la protection comme décrit dans [Supprimer AWS Shield Advanced la protection d'une AWS ressource](#remove-protection). Assurez-vous de cocher la case à côté de **Supprimer également l' DDoSDetection alarme associée**.
+ Supprimez l'alarme à l'aide de la CloudWatch console. Le nom de l'alarme à supprimer commence par **DDoSDetectedAlarmForProtection**.
# Regrouper vos AWS Shield Advanced protections
Utilisez des groupes de protection pour créer des collections logiques de vos ressources protégées et gérer leurs protections en tant que groupe. Pour plus d'informations sur la gestion de la protection des ressources, consultez[AWS Shield Advanced Protections d'édition](manage-protection.md).
**Note**
L'atténuation automatique de la couche DDo S de l'application n'interagit pas avec les groupes de protection. Vous pouvez activer l'atténuation automatique pour les ressources appartenant à des groupes de protection, mais Shield Advanced n'applique pas automatiquement les mesures d'atténuation des attaques en fonction des résultats des groupes de protection. Shield Advanced applique des mesures d'atténuation automatiques des attaques pour les ressources individuelles.
AWS Shield Advanced les groupes de protection vous offrent un moyen en libre-service de personnaliser l'étendue de la détection et de l'atténuation en traitant plusieurs ressources protégées comme une seule unité. Le regroupement des ressources peut présenter de nombreux avantages.
+ Améliorez la précision de détection.
+ Réduisez les notifications d'événements non exploitables.
+ Augmenter la couverture des mesures d'atténuation pour inclure les ressources protégées qui pourraient également être affectées lors d'un événement.
+ Accélérez le temps nécessaire pour atténuer les attaques visant plusieurs cibles similaires.
+ Facilitez la protection automatique des ressources protégées nouvellement créées.
Les groupes de protection peuvent contribuer à réduire les faux positifs dans des situations telles que le blue/green swap, où les ressources alternent entre une charge proche de zéro et une charge complète. Un autre exemple est celui où vous créez et supprimez fréquemment des ressources tout en maintenant un niveau de charge partagé entre les membres du groupe. Dans de telles situations, la surveillance de ressources individuelles peut donner lieu à des faux positifs, ce qui n'est pas le cas de la surveillance de l'état du groupe de ressources.
Vous pouvez configurer les groupes de protection pour inclure toutes les ressources protégées, toutes les ressources de types de ressources spécifiques ou les ressources spécifiées individuellement. Les ressources nouvellement protégées qui répondent aux critères de votre groupe de protection sont automatiquement incluses dans votre groupe de protection. Une ressource protégée peut appartenir à plusieurs groupes de protection.
# Création d'un groupe de protection Shield Advanced
**Pour créer un groupe de protection**
1. Connectez-vous à la console AWS WAF & Shield AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Dans le volet AWS Shield de navigation, sélectionnez **Ressources protégées**.
1. Choisissez l'onglet **Groupes de protection**, puis choisissez **Créer un groupe de protection**.
1. Sur la page **Créer un groupe de protection**, donnez un nom à votre groupe. Vous utiliserez ce nom pour identifier le groupe dans votre liste de ressources protégées. Vous ne pouvez pas modifier le nom d'un groupe de protection après l'avoir créé.
1. Pour les **critères de regroupement de protection**, sélectionnez les critères que Shield Advanced doit utiliser pour identifier les ressources protégées à inclure dans le groupe. Effectuez vos sélections supplémentaires en fonction des critères que vous avez choisis.
1. Pour **l'agrégation**, sélectionnez la manière dont vous souhaitez que Shield Advanced combine les données des ressources du groupe afin de détecter, d'atténuer et de signaler les événements.
+ **Somme** — Utilise le trafic total du groupe. C'est un bon choix dans la plupart des cas. Parmi les exemples, citons les adresses IP élastiques pour EC2 les instances Amazon qui évoluent manuellement ou automatiquement.
+ **Moyenne** : utilisez la moyenne du trafic au sein du groupe. C'est un bon choix pour les ressources qui partagent le trafic de manière uniforme. Les accélérateurs et les équilibreurs de charge en sont des exemples.
+ **Max** — Utilisez le trafic le plus élevé provenant de chaque ressource. Cela est utile pour les ressources qui ne partagent pas le trafic et pour les ressources qui partagent le trafic de manière non uniforme. Les exemples incluent les CloudFront distributions Amazon et les ressources d'origine pour les CloudFront distributions.
1. Choisissez **Enregistrer** pour enregistrer votre groupe de protection et revenir à la page **Ressources protégées**.
Sur la page **Shield** **Events**, vous pouvez consulter les événements relatifs à votre groupe de protection et effectuer une recherche détaillée pour obtenir des informations supplémentaires sur les ressources protégées du groupe.
# Mettre à jour un groupe de protection Shield Advanced
**Pour mettre à jour un groupe de protection**
1. Connectez-vous à la console AWS WAF & Shield AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Dans le volet AWS Shield de navigation, sélectionnez **Ressources protégées**.
1. Dans l'onglet **Groupes de protection**, cochez la case à côté du groupe de protection que vous souhaitez modifier.
1. Sur la page du groupe de protection, choisissez **Modifier**. Apportez vos modifications aux paramètres du groupe de protection.
1. Choisissez **Save** pour enregistrer les changements.
# Supprimer un groupe de protection Shield Advanced
**Pour supprimer un groupe de protection**
1. Connectez-vous à la console AWS WAF & Shield AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Dans le volet AWS Shield de navigation, sélectionnez **Ressources protégées**.
1. Dans l'onglet **Groupes de protection**, cochez la case à côté du groupe de protection que vous souhaitez supprimer.
1. Sur la page du groupe de protection, choisissez **Supprimer** et confirmez l'action.
# Modifications apportées à la protection avancée des ressources par Tracking Shield dans AWS Config
Cette page explique comment enregistrer les modifications apportées à la AWS Shield Advanced protection de vos ressources à l'aide de AWS Config. Vous pouvez ensuite utiliser ces informations pour conserver un historique des changements de configuration à des fins d'audit et de dépannage.
Pour enregistrer les modifications de protection, activez-les AWS Config pour chaque ressource que vous souhaitez suivre. Pour plus d’informations, consultez [ Mise en route avec AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/getting-started.html) dans le *AWS Config Guide du développeur*.
Vous devez l'activer AWS Config pour chaque ressource Région AWS qui contient les ressources suivies. Vous pouvez l'activer AWS Config manuellement ou utiliser le CloudFormation modèle « Activer AWS Config » dans la section [CloudFormation StackSets Exemples de modèles](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-sampletemplates.html) du *guide de l'CloudFormation utilisateur*.
Si vous l'activez AWS Config, vous êtes débité comme indiqué sur la page de [AWS Config tarification](https://aws.amazon.com/config/pricing/).
**Note**
Si vous avez déjà AWS Config activé les régions et les ressources nécessaires, vous n'avez rien à faire. AWS Config les journaux concernant les modifications de protection apportées à vos ressources commencent à se remplir automatiquement.
Après l'activation AWS Config, utilisez la région USA Est (Virginie du Nord) dans la AWS Config console pour afficher l'historique des modifications de configuration pour les ressources AWS Shield Advanced globales.
Consultez l'historique des modifications des ressources AWS Shield Advanced régionales via la AWS Config console dans les régions USA Est (Virginie du Nord), USA Est (Ohio), USA Ouest (Oregon), USA Ouest (Californie du Nord), Europe (Irlande), Europe (Francfort), Asie-Pacifique (Tokyo) et Asie-Pacifique (Sydney).
# Visibilité des événements DDo S avec Shield Advanced
AWS Shield fournit une visibilité sur les catégories d'événements et d'activités événementielles suivantes :
+ **Global** — Tous les clients peuvent accéder à une vue agrégée de l'activité des menaces mondiales au cours des deux dernières semaines. Vous pouvez consulter ces informations sur les pages **Getting Started** et **Global Threat Dashboard** de la AWS Shield console. Pour de plus amples informations, veuillez consulter [Affichage de AWS Shield l'activité globale et de l'activité du compte](ddos-standard-event-visibility.md).
+ **Compte** — Tous les clients peuvent accéder à un résumé des événements liés à leur compte au cours de l'année précédente. Vous pouvez consulter ces informations sur la page **Getting Started** de la AWS Shield console. Pour de plus amples informations, veuillez consulter [Affichage de AWS Shield l'activité globale et de l'activité du compte](ddos-standard-event-visibility.md).
Lorsque vous vous abonnez à Shield Advanced et que vous ajoutez des protections à vos ressources, vous avez accès à des informations supplémentaires sur les événements et les attaques DDo S contre les ressources protégées :
+ **Événements sur des ressources protégées** : Shield Advanced fournit des informations détaillées sur chaque événement via la page **Événements** de la AWS Shield console. Pour de plus amples informations, veuillez consulter [Affichage des AWS Shield Advanced événements](ddos-events.md).
+ **Mesures relatives aux événements pour les ressources protégées** : Shield Advanced publie les CloudWatch statistiques Amazon relatives à la détection, à l'atténuation et aux principaux contributeurs pour toutes les ressources qu'elle protège. Vous pouvez utiliser ces métriques pour configurer des CloudWatch tableaux de bord et des alarmes. Pour de plus amples informations, veuillez consulter [AWS Shield Advanced métriques](shield-metrics.md).
+ **Visibilité des événements entre comptes pour les ressources protégées** — Si vous gérez vos protections Shield Advanced, vous pouvez activer la visibilité des protections sur plusieurs comptes en utilisant Firewall Manager associé AWS Security Hub CSPMà. AWS Firewall Manager Pour de plus amples informations, veuillez consulter [Affichage des événements Shield Advanced sur plusieurs Comptes AWS avec AWS Firewall Manager et AWS Security Hub CSPM](ddos-viewing-multiple-accounts.md).
Si vous activez l'atténuation automatique de la couche d'application DDo S pour une protection de la couche d'application, Shield Advanced ajoute un groupe de règles à votre pack de protection (ACL Web) qu'il utilise pour gérer les protections automatisées. Ce groupe de règles génère AWS WAF des métriques, mais elles ne peuvent pas être consultées. Il en va de même pour tous les autres groupes de règles que vous utilisez dans votre pack de protection (ACL Web) mais que vous ne possédez pas, tels que les groupes de règles AWS Managed Rules. Pour plus d'informations sur AWS WAF les métriques, consultez[AWS WAF métriques et dimensions](waf-metrics.md). Pour plus d'informations sur cette option de protection Shield Advanced, consultez[Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md).
**Topics**
+ [Affichage de AWS Shield l'activité globale et de l'activité du compte](ddos-standard-event-visibility.md)
+ [Affichage des AWS Shield Advanced événements](ddos-events.md)
+ [Affichage des événements Shield Advanced sur plusieurs Comptes AWS avec AWS Firewall Manager et AWS Security Hub CSPM](ddos-viewing-multiple-accounts.md)
# Affichage de AWS Shield l'activité globale et de l'activité du compte
Cette page fournit des instructions pour accéder à une vue agrégée de l'activité globale des menaces et à un résumé des événements par compte dans les pages **Getting Started** et **Global Threat Dashboard de la AWS Shield ** console.
La capture d'écran suivante montre un exemple **de page de démarrage**.
![\[La AWS Shield console affiche la page Getting started, qui contient les volets de synthèse des menaces globales et des événements liés au compte.\]](http://docs.aws.amazon.com/fr_fr/waf/latest/developerguide/images/shield-console-global-account.png)
**Pour accéder à la AWS Shield console**
+ Connectez-vous à la console AWS WAF & Shield AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
Vous n'avez pas besoin d'un abonnement à Shield Advanced pour accéder aux informations récapitulatives sur l'activité globale et les événements du compte.
**Activité mondiale**
Ces informations sont disponibles via le tableau de **bord des menaces mondiales** de la AWS Shield console et les pages **Getting Started**. La capture d'écran suivante montre un exemple du volet d'activité global.
![\[Un volet de AWS Shield console intitulé Global activity detected by Shield montre une carte du monde superposée par des marquages de type heatmap pour les zones où des menaces mondiales ont été détectées au cours des deux dernières semaines.\]](http://docs.aws.amazon.com/fr_fr/waf/latest/developerguide/images/shield-console-global-activity.png)
L'activité globale décrit DDo les événements S observés chez tous les AWS clients. Une fois par heure, AWS met à jour les informations des deux semaines précédentes. Dans le volet de la console, vous pouvez voir les résultats, partitionnés par AWS région et affichés sur une carte thermique mondiale. À côté de la carte, Shield affiche des informations récapitulatives telles que l'attaque de paquets la plus importante, le débit le plus élevé, le vecteur le plus courant, le nombre total d'attaques et le niveau de menace. Le niveau de menace est une évaluation de l'activité mondiale actuelle par rapport à ce qui est AWS généralement observé. La valeur du niveau de menace par défaut est **Normal**. AWS met automatiquement à jour la valeur sur **Élevé** en cas d'activité DDo S élevée.
Le **tableau de bord des menaces mondiales** fournit également des statistiques chronologiques et vous permet de changer de durée. Pour consulter l'historique des attaques DDo S importantes, vous pouvez personnaliser le tableau de bord en fonction des vues du dernier jour aux deux dernières semaines. Les métriques chronologiques fournissent une vue du débit binaire, du débit de paquets ou du débit de demandes le plus élevé pour tous les événements détectés par AWS Shield les applications exécutées AWS pendant la fenêtre temporelle que vous sélectionnez.
**Activité du compte**
Ces informations sont disponibles sur la page **Getting AWS Shield Started** de la console.
La capture d'écran suivante montre un exemple de volet d'activité du compte.
![\[Un volet de AWS Shield console intitulé Account activity detected by Shield répertorie un résumé des événements survenus au cours de l'année écoulée, avec des informations telles que le nombre total d'événements ainsi que le débit de paquets et le taux de demandes les plus élevés.\]](http://docs.aws.amazon.com/fr_fr/waf/latest/developerguide/images/shield-console-account-activity.png)
L'activité du compte décrit les événements DDo S détectés par Shield pour vos ressources éligibles à la protection de Shield Advanced. Chaque jour, Shield crée des statistiques récapitulatives pour l'année se terminant à 00h00 UTC la veille, puis affiche le total des événements, le débit binaire le plus élevé, le débit de paquets le plus élevé et le plus grand débit de demandes.
+ L'indicateur du nombre total d'événements reflète chaque fois que Shield a détecté des attributs suspects dans le trafic destiné à votre application. Les attributs suspects peuvent inclure un trafic dont le volume est supérieur à la normale, le trafic qui ne correspond pas au profil historique de votre application ou le trafic qui ne correspond pas aux heuristiques définies par Shield pour le trafic d'applications valide.
+ Les statistiques de débit et de débit de paquets les plus élevés sont disponibles pour chaque ressource.
+ La statistique de taux de demande la plus importante n'est disponible que pour les CloudFront distributions Amazon et les équilibreurs de charge d'application associés à une ACL AWS WAF Web.
**Note**
Vous pouvez également accéder au résumé des événements au niveau du compte via l'opération AWS Shield API [DescribeAttackStatistics](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_DescribeAttack.html).
# Affichage des AWS Shield Advanced événements
Cette page fournit des instructions pour accéder aux informations relatives aux événements dans Shield Advanced.
Lorsque vous vous abonnez à Shield Advanced et que vous protégez vos ressources, vous avez accès à des fonctionnalités de visibilité supplémentaires pour les ressources. Il s'agit notamment de la notification en temps quasi réel des événements détectés par Shield Advanced et d'informations supplémentaires sur les événements détectés et les mesures d'atténuation.
**Note**
Les informations relatives à vos événements dans la console Shield Advanced sont basées sur les métriques de Shield Advanced. Pour plus d'informations sur les métriques Shield Advanced, voir [AWS Shield Advanced métriques](shield-metrics.md)
AWS Shield évalue le trafic vers votre ressource protégée selon plusieurs dimensions. Lorsqu'une anomalie est détectée, Shield Advanced crée un événement distinct pour chaque ressource affectée.
Vous pouvez accéder aux résumés et aux détails des événements via la page **Événements** de la console Shield. La page **Événements** de haut niveau fournit un aperçu des événements actuels et passés.
La capture d'écran suivante montre un exemple de page d'**événements** avec un seul événement en cours. Cet événement actif est également signalé dans le volet de navigation de gauche.
![\[Dans le volet de navigation gauche de la AWS Shield console, la sélection Événements est surlignée en rouge, avec le chiffre 1 à côté, dans un cercle rouge. La page Événements est ouverte et n'affiche qu'une seule ligne dans la liste des événements. La ligne répertorie une AWS ressource de type CloudFront distribution. Le champ État actuel contient une icône rouge triangulaire à côté des mots Atténuation en cours. Le champ État des vecteurs d'attaque contient le trafic UDP. Le champ Heure de début contient le 16 septembre 2020, 14h43 SAST. Le champ Durée contient 6 minutes.\]](http://docs.aws.amazon.com/fr_fr/waf/latest/developerguide/images/shield-console-event-summary1.png)
Shield Advanced peut également mettre en place automatiquement des mesures d'atténuation contre les attaques, en fonction du type de trafic et des protections que vous avez configurées. Ces mesures d'atténuation peuvent empêcher votre ressource de recevoir du trafic excessif ou du trafic correspondant à une signature d'attaque DDo S connue.
La capture d'écran suivante montre un exemple de liste d'**événements** dans lequel tous les événements ont été atténués par Shield Advanced ou se sont atténués d'eux-mêmes.
![\[Une page de AWS Shield console intitulée Events répertorie les événements récemment détectés ainsi que leur état actuel.\]](http://docs.aws.amazon.com/fr_fr/waf/latest/developerguide/images/shield-console-events.png)
**Protégez vos ressources avant un événement**
Améliorez la précision de la détection des événements en protégeant les ressources avec Shield Advanced alors qu'elles reçoivent le trafic normal attendu, avant qu'elles ne soient soumises à une attaque DDo S.
Afin de signaler avec précision les événements relatifs à une ressource protégée, Shield Advanced doit d'abord établir une base de référence des modèles de trafic attendus pour cette ressource.
+ Shield Advanced signale les événements liés à la couche d'infrastructure relatifs aux ressources après qu'elles ont été protégées pendant au moins 15 minutes.
+ Shield Advanced signale les événements de la couche d'application Web pour les ressources après qu'elles ont été protégées pendant au moins 24 heures. La précision de détection des événements liés à la couche application est optimale une fois que Shield Advanced a observé le trafic attendu pendant 30 jours.
**Pour accéder aux informations relatives aux événements dans la AWS Shield console**
1. Connectez-vous à la console AWS WAF & Shield AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Dans le volet AWS Shield de navigation, sélectionnez **Events**. La console affiche la page **Événements**.
1. Sur la page **Événements**, vous pouvez sélectionner n'importe quel événement dans la liste pour voir des informations récapitulatives et des détails supplémentaires sur l'événement.
**Topics**
+ [Liste des champs dans les résumés des AWS Shield Advanced événements](ddos-event-summaries.md)
+ [Afficher les détails de AWS Shield Advanced l'événement](ddos-event-details.md)
# Liste des champs dans les résumés des AWS Shield Advanced événements
Cette page répertorie et définit les champs des résumés des événements de Shield Advanced.
Vous pouvez consulter le résumé et les informations détaillées d'un événement sur la page de console de l'événement. Pour ouvrir la page d'un événement, sélectionnez le nom de sa AWS ressource dans la liste des pages **Événements**.
La capture d'écran suivante montre un exemple de résumé d'événement pour un événement de couche réseau.
![\[Le volet récapitulatif de la page des événements de la AWS Shield console répertorie les informations relatives à un événement et inclut la AWS ressource affectée, les vecteurs d'attaque, les heures de début et de fin, ainsi que les informations d'atténuation et d'état.\]](http://docs.aws.amazon.com/fr_fr/waf/latest/developerguide/images/shield-console-event-summary2.png)
Les informations récapitulatives de la page de l'événement incluent les informations suivantes.
+ État **actuel** : valeurs qui indiquent l'état de l'événement et les mesures prises par Shield Advanced pour y remédier. Les valeurs d'état s'appliquent aux événements de la couche infrastructure (couche 3 ou 4) et de la couche application (couche 7).
+ **Identifié (en cours)** et **Identifié (atténué)** — Cela indique que Shield Advanced a détecté un événement, mais n'a pris aucune mesure pour y remédier jusqu'à présent. **Identifié (diminué)** indique que le trafic suspect détecté par Shield s'est arrêté sans intervention.
+ **Atténuation en cours** et **atténuation** : cela indique que Shield Advanced a détecté un événement et a pris des mesures pour y remédier. La **méthode Mitiated est également utilisée lorsque la ressource ciblée est une CloudFront distribution Amazon ou une zone hébergée Amazon Route 53, qui disposent de leurs propres mesures d'atténuation** automatiques intégrées.
+ **Vecteurs d'attaque : vecteurs** d'attaque DDo S tels que les inondations TCP SYN et les heuristiques de détection Shield Advanced, telles que les inondations de requêtes. Ils peuvent être des indicateurs d'une attaque DDo S.
+ **Heure de début** : date et heure auxquelles le premier point de données de trafic anormal a été détecté.
+ **Durée ou heure de fin** : indique le temps écoulé entre l'heure de début de l'événement et le dernier point de données anormal observé par Shield Advanced. Pendant qu'un événement est en cours, ces valeurs continueront d'augmenter.
+ **Protection** : nomme la protection Shield Advanced associée à la ressource et fournit un lien vers sa page de protection. Ceci est disponible sur la page de chaque événement.
+ **Atténuation automatique de la couche d'application DDo S** : utilisée pour les protections de la couche d'application, pour indiquer si l'atténuation automatique de la couche d'application DDo S de Shield Advanced est activée pour la ressource. S'il est activé, il fournit un lien permettant d'accéder à la configuration et de la gérer. Ceci est disponible sur la page de chaque événement.
+ **Atténuation automatique de la couche réseau** : indique si la ressource dispose d'une atténuation automatique au niveau de la couche réseau. Si une ressource possède un composant de couche réseau, celui-ci sera activé. Ces informations sont disponibles sur la page de chaque événement.
Pour les ressources fréquemment ciblées, Shield peut laisser des mesures d'atténuation en place une fois que le trafic excédentaire aura diminué, afin d'éviter de nouveaux événements récurrents.
**Note**
Vous pouvez également accéder aux résumés des événements relatifs aux ressources protégées par le biais de l'opération AWS Shield [ListAttacks](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_ListAttacks.html)API.
# Afficher les détails de AWS Shield Advanced l'événement
Vous pouvez consulter les détails relatifs à la détection, à l'atténuation et aux principaux contributeurs d'un événement dans la section inférieure de la page de console de l'événement. Cette section peut inclure un mélange de trafic légitime et potentiellement indésirable, et peut représenter à la fois le trafic transmis à votre ressource protégée et le trafic bloqué par les mesures d'atténuation du Shield.
+ **Détection et atténuation** : fournit des informations sur l'événement observé et les mesures d'atténuation appliquées pour le contrer. Pour plus d'informations sur l'atténuation des événements, consultez[Réagir aux événements DDo S dans AWS](ddos-responding.md).
+ **Principaux contributeurs** : classe le trafic impliqué dans l'événement et répertorie les principales sources de trafic identifiées par Shield pour chaque catégorie. Pour les événements de la couche application, utilisez les informations des principaux contributeurs pour avoir une idée générale de la nature d'un événement, mais utilisez les AWS WAF journaux pour vos décisions en matière de sécurité. Pour plus d'informations, consultez les sections suivantes.
Les informations relatives à vos événements dans la console Shield Advanced sont basées sur les métriques de Shield Advanced. Pour plus d'informations sur les métriques Shield Advanced, voir [AWS Shield Advanced métriques](shield-metrics.md)
Les mesures d'atténuation ne sont pas incluses pour les ressources Amazon CloudFront ou Amazon Route 53, car ces services sont protégés par un système d'atténuation toujours activé et ne nécessitant pas de mesures d'atténuation pour les ressources individuelles.
Les sections détaillées varient selon que les informations concernent une couche d'infrastructure ou un événement de couche d'application.
**Topics**
+ [Affichage des détails des événements de la couche d'application (couche 7) dans Shield Advanced](ddos-event-details-application-layer.md)
+ [Affichage des détails des événements de la couche d'infrastructure (couche 3 ou 4) dans Shield Advanced](ddos-event-details-infrastructure-layer.md)
# Affichage des détails des événements de la couche d'application (couche 7) dans Shield Advanced
Vous pouvez consulter les détails relatifs à la détection, à l'atténuation et aux principaux contributeurs d'un événement de couche application dans la section inférieure de la page de console de l'événement. Cette section peut inclure un mélange de trafic légitime et potentiellement indésirable, et peut représenter à la fois le trafic transmis à votre ressource protégée et le trafic bloqué par les mesures d'atténuation de Shield Advanced.
Les détails de l'atténuation concernent toutes les règles de l'ACL Web associées à la ressource, y compris les règles déployées spécifiquement en réponse à une attaque et les règles basées sur le taux définies dans l'ACL Web. Si vous activez l'atténuation automatique de la couche DDo S de l'application pour une application, les mesures d'atténuation incluent des mesures pour ces règles supplémentaires. Pour plus d'informations sur ces protections de la couche d'application, consultez[Protection de la couche applicative (couche 7) avec AWS Shield Advanced et AWS WAF](ddos-app-layer-protections.md).
## Détection et atténuation
Pour un événement de couche d'application (couche 7), l'onglet **Détection et atténuation** affiche les mesures de détection basées sur les informations obtenues à partir des AWS WAF journaux. Les mesures d'atténuation sont basées sur AWS WAF les règles de l'ACL Web associée qui sont configurées pour bloquer le trafic indésirable.
Pour les CloudFront distributions Amazon, vous pouvez configurer Shield Advanced pour appliquer des mesures d'atténuation automatiques à votre place. Quelles que soient les ressources de la couche application, vous pouvez choisir de définir vos propres règles d'atténuation dans votre ACL Web et demander de l'aide à la Shield Response Team (SRT). Pour de plus amples informations sur ces options, consultez [Réagir aux événements DDo S dans AWS](ddos-responding.md).
La capture d'écran suivante montre un exemple de mesures de détection pour un événement de couche application qui s'est atténué après un certain nombre d'heures.
![\[Un graphique des mesures de détection montre la détection du trafic de demandes inondé entre 11 h 30 et 16 h 00.\]](http://docs.aws.amazon.com/fr_fr/waf/latest/developerguide/images/shield-app-detection-metrics.png)
Le trafic d'événements qui s'atténue avant l'entrée en vigueur d'une règle d'atténuation n'est pas représenté dans les mesures d'atténuation. Cela peut entraîner une différence entre le trafic de requêtes Web indiqué dans les graphiques de détection et les mesures d'autorisation et de blocage indiquées dans les graphiques d'atténuation.
## Principaux contributeurs
L'onglet **Principaux contributeurs** pour les événements de la couche application affiche les 5 principaux contributeurs identifiés par Shield pour l'événement, sur la base AWS WAF des journaux qu'il a récupérés. Shield classe les informations des principaux contributeurs par des dimensions telles que l'adresse IP source, le pays source et l'URL de destination.
**Note**
Pour obtenir les informations les plus précises sur le trafic qui contribue à un événement de couche application, utilisez les AWS WAF journaux.
Utilisez les informations sur les principaux contributeurs de la couche d'application Shield uniquement pour avoir une idée générale de la nature d'une attaque, et ne basez pas vos décisions en matière de sécurité sur ces informations. En ce qui concerne les événements liés à la couche application, les AWS WAF journaux constituent la meilleure source d'informations pour comprendre les facteurs à l'origine d'une attaque et pour concevoir vos stratégies d'atténuation.
Les informations sur les principaux contributeurs du Shield ne reflètent pas toujours complètement les données contenues dans les AWS WAF journaux. Lorsqu'il ingère les journaux, Shield donne la priorité à la réduction de l'impact sur les performances du système plutôt qu'à la récupération de l'ensemble complet des données des journaux. Cela peut entraîner une perte de granularité des données mises à la disposition de Shield pour analyse. Dans la plupart des cas, la majorité des informations sont disponibles, mais il est possible que les données des principaux contributeurs soient faussées dans une certaine mesure en cas d'attaque.
La capture d'écran suivante montre un exemple d'onglet **Principaux contributeurs** pour un événement de couche application.
![\[L'onglet « Principaux contributeurs » d'un événement de couche d'application décrit les 5 principaux contributeurs pour un certain nombre de caractéristiques de requête Web. L'écran affiche les 5 principales adresses IP sources, les 5 principales destinations URLs, les 5 principaux pays sources et les 5 meilleurs agents utilisateurs.\]](http://docs.aws.amazon.com/fr_fr/waf/latest/developerguide/images/shield-app-event-top-contributors.png)
Les informations des contributeurs sont basées sur les demandes de trafic légitime et potentiellement indésirable. Les événements de plus grand volume et les événements dont les sources de requêtes ne sont pas très distribuées sont plus susceptibles d'avoir des contributeurs de premier plan identifiables. Une attaque distribuée de manière significative peut avoir plusieurs sources, ce qui complique l'identification des principaux contributeurs à l'attaque. Si Shield Advanced n'identifie pas les contributeurs importants pour une catégorie spécifique, il affiche les données comme non disponibles.
# Affichage des détails des événements de la couche d'infrastructure (couche 3 ou 4) dans Shield Advanced
Vous pouvez consulter les détails relatifs à la détection, à l'atténuation et aux principaux contributeurs d'un événement au niveau de la couche d'infrastructure dans la section inférieure de la page de console de l'événement. Cette section peut inclure un mélange de trafic légitime et potentiellement indésirable, et peut représenter à la fois le trafic transmis à votre ressource protégée et le trafic bloqué par les mesures d'atténuation du Shield.
## Détection et atténuation
Pour un événement de couche d'infrastructure (couche 3 ou 4), l'onglet **Détection et atténuation** affiche les mesures de détection basées sur des flux réseau échantillonnés et les mesures d'atténuation basées sur le trafic observé par les systèmes d'atténuation. Les mesures d'atténuation sont une mesure plus précise du trafic vers votre ressource.
Shield crée automatiquement une atténuation pour les types de ressources protégés Elastic IP (EIP), Classic Load Balancer (CLB), Application Load Balancer (ALB) et accélérateur standard. AWS Global Accelerator Les mesures d'atténuation pour les adresses EIP et les accélérateurs AWS Global Accelerator standard indiquent le nombre de paquets transmis et abandonnés.
La capture d'écran suivante montre un exemple d'onglet **Détection et atténuation** pour un événement de couche d'infrastructure.
![\[Les graphiques de détection et d'atténuation d'un événement réseau montrent une augmentation du trafic SYN flood et du trafic de paquets dans les métriques de détection, associée à une augmentation des mesures d'atténuation entraînant une baisse du trafic quelques secondes plus tard, dans les métriques d'atténuation. Après une trentaine de secondes de mesures d'atténuation accrues, les inondations de circulation cessent.\]](http://docs.aws.amazon.com/fr_fr/waf/latest/developerguide/images/shield-network-event-detection-mitigation.png)
Le trafic d'événements qui s'atténue avant que Shield ne mette en place une mesure d'atténuation n'est pas représenté dans les mesures d'atténuation. Cela peut entraîner une différence entre le trafic indiqué dans les graphiques de détection et les mesures de réussite et de baisse indiquées dans les graphiques d'atténuation.
## Principaux contributeurs
L'onglet **Principaux contributeurs** pour les événements de la couche infrastructure répertorie les mesures relatives à un maximum de 100 principaux contributeurs sur plusieurs dimensions du trafic. Les détails incluent les propriétés de la couche réseau pour toutes les dimensions dans lesquelles au moins cinq sources importantes de trafic peuvent être identifiées. L'adresse IP source et l'ASN source sont des exemples de sources de trafic.
La capture d'écran suivante montre un exemple d'onglet **Principaux contributeurs** pour un événement de couche d'infrastructure.
![\[L'onglet « Principaux contributeurs » d'un événement réseau indique les catégories de trafic qui ont le plus contribué à l'événement. Dans ce cas, les catégories incluent le volume par protocole, le volume par protocole et le port de destination, le volume par protocole et l'ASN source, et le volume par indicateurs TCP.\]](http://docs.aws.amazon.com/fr_fr/waf/latest/developerguide/images/shield-network-event-top-contributors.png)
Les indicateurs des contributeurs sont basés sur des échantillons de flux réseau pour le trafic légitime et potentiellement indésirable. Les événements de plus grand volume et les événements dont les sources de trafic ne sont pas très distribuées sont plus susceptibles d'avoir des contributeurs de premier plan identifiables. Une attaque distribuée de manière significative peut avoir plusieurs sources, ce qui complique l'identification des principaux contributeurs à l'attaque. Si Shield n'identifie aucun contributeur significatif pour une métrique ou une catégorie spécifique, il affiche les données comme non disponibles.
Lors d'une attaque de couche DDo S de l'infrastructure, les sources de trafic peuvent être falsifiées ou reflétées. Une source falsifiée est forgée intentionnellement par l'attaquant. Une source réfléchie est la véritable source du trafic détecté, mais elle ne participe pas volontairement à l'attaque. Par exemple, un attaquant peut générer un flux important et amplifié de trafic vers une cible en reflétant l'attaque dirigée contre des services sur Internet qui sont généralement légitimes. Dans ce cas, les informations de source peuvent être valides alors qu'elles ne sont pas la véritable source de l'attaque. Ces facteurs peuvent limiter la viabilité des techniques d'atténuation qui bloquent les sources en fonction des en-têtes de paquets.
# Affichage des événements Shield Advanced sur plusieurs Comptes AWS avec AWS Firewall Manager et AWS Security Hub CSPM
Vous pouvez utiliser, AWS Security Hub CSPM gérer AWS Firewall Manager et surveiller les ressources AWS Shield Advanced protégées sur plusieurs comptes.
Avec Firewall Manager, vous pouvez créer une politique de sécurité Shield Advanced qui signale et applique la conformité à la protection DDo S sur tous vos comptes. Firewall Manager surveille vos ressources protégées, notamment en ajoutant des protections aux nouvelles ressources couvertes par la politique Shield Advanced.
Vous pouvez intégrer Firewall Manager AWS Security Hub CSPM pour obtenir un tableau de bord unique signalant les événements DDo S détectés par Shield Advanced et les résultats de conformité de Firewall Manager, lorsque Firewall Manager identifie une ressource non conforme à votre politique de sécurité Shield Advanced.
La figure suivante décrit une architecture typique de surveillance des ressources protégées de Shield Advanced avec Firewall Manager et Security Hub CSPM.
![\[En haut de la figure se trouve une AWS Organizations icône. Il possède une flèche pointant vers le bas qui se divise pour pointer vers deux icônes situées côte à côte. L'icône de gauche porte le titre Production OU et l'icône de droite le titreSecurity OU. Sous ces icônes se trouvent trois icônes, intitulées de gauche à droite : AWS Shield Advanced AWS Firewall Manager, et AWS Security Hub CSPM. L'icône de l'unité d'organisation de production comporte une flèche pointant vers le bas vers l'icône Shield Advanced. L'icône de l'unité d'organisation de sécurité comporte une flèche pointant vers le bas qui se divise pour pointer vers les icônes Firewall Manager et Security Hub CSPM. L'icône Shield Advanced comporte une flèche pointant vers le bas vers un rectangle avec le titreShield Advanced protected resources. À l'intérieur du rectangle se trouvent des icônes pour Application Load Balancer, CloudFront la distribution et l'adresse IP Elastic. L'icône Firewall Manager comporte également une flèche pointant vers le bas vers le Shield Advanced protected resources rectangle, et elle est étiquetéeEnforces compliance of protected resources. L'icône Shield Advanced comporte une flèche horizontale pointant vers l'icône Firewall Manager étiquetéeDDoS alarm. L'icône Firewall Manager comporte une flèche horizontale pointant vers la droite, vers l'icône Security Hub CSPM étiquetée. DDoS alarm and compliance findings\]](http://docs.aws.amazon.com/fr_fr/waf/latest/developerguide/images/shield-arch-fms-ash-integration.png)
Lorsque vous intégrez Firewall Manager à Security Hub CSPM, vous pouvez consulter les résultats de sécurité en un seul endroit, ainsi que les autres alertes et informations sur le statut de conformité des applications sur lesquelles vous exécutez. AWS
La capture d'écran suivante met en évidence les informations que vous pouvez voir concernant un événement Shield Advanced dans la console Security Hub CSPM lorsque vous disposez d'une intégration de ce type.
![\[La capture d'écran montre la page des résultats de la console Security Hub CSPM, sous-titrée A finding is a security issue or a failed security check. . La section comporte des lignes rouges surlignant les chaînes : Titre EQUALS Shield Advanced a détecté une attaque contre une ressource surveillée et nom du produit EQUAL Firewall Manager. L'écran affiche un ensemble de détails sur l'attaque spécifique et son statut.\]](http://docs.aws.amazon.com/fr_fr/waf/latest/developerguide/images/shield-console-security-hub-event.png)
Pour savoir comment intégrer Firewall Manager et Security Hub CSPM à Shield Advanced afin de centraliser la surveillance des événements et de la conformité sur vos comptes protégés, consultez le blog sur la AWS sécurité [Configurer une surveillance centralisée pour les événements DDo S et corriger automatiquement](https://aws.amazon.com/blogs/security/set-up-centralized-monitoring-for-ddos-events-and-auto-remediate-noncompliant-resources/) les ressources non conformes.
# Réagir aux événements DDo S dans AWS
Cette page explique comment AWS réagir aux attaques DDo S et propose des options sur la manière dont vous pouvez y répondre ultérieurement.
AWS atténue automatiquement les attaques du réseau et des couches de transport (couches 3 et 4) DDo S. Si vous utilisez Shield Advanced pour protéger vos EC2 instances Amazon, lors d'une attaque, Shield Advanced déploie automatiquement votre réseau Amazon VPC jusqu'à la limite du ACLs AWS réseau. Cela permet à Shield Advanced de fournir une protection contre les événements DDo S plus importants. Pour plus d'informations sur le réseau ACLs, consultez la section [Réseau ACLs](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html).
Pour les attaques au niveau de la couche applicative (couche 7) DDo S, AWS tentatives de détection et de notification des AWS Shield Advanced clients par le biais d' CloudWatch alarmes. Par défaut, il n'applique pas automatiquement les mesures d'atténuation, afin d'éviter de bloquer par inadvertance le trafic utilisateur valide.
Pour les ressources de la couche application (couche 7), les options suivantes sont disponibles pour répondre à une attaque.
+ **Proposez vos propres mesures d'atténuation** — Vous pouvez étudier et atténuer vous-même l'attaque. Pour plus d'informations, consultez [Atténuation manuelle d'une attaque de couche applicative DDo S](ddos-responding-manual.md).
+ **Contacter l'assistance** — Si vous êtes un client de Shield Advanced, vous pouvez contacter le [AWS Support Centre](https://console.aws.amazon.com/support/home#/) pour obtenir de l'aide concernant les mesures d'atténuation. Les cas critiques et urgents sont transmis directement aux experts DDo S. Pour plus d'informations, consultez [Contacter le centre de support lors d'une attaque de couche DDo applicative S](ddos-responding-contact-support.md).
En outre, avant qu'une attaque ne se produise, vous pouvez activer de manière proactive les options d'atténuation suivantes :
+ **Atténuations automatiques sur les CloudFront distributions Amazon** : avec cette option, Shield Advanced définit et gère les règles d'atténuation pour vous dans votre ACL Web. Pour plus d'informations sur l'atténuation automatique de la couche d'application, consultez[Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md).
+ **Engagement proactif** : lorsqu'il AWS Shield Advanced détecte une attaque de grande envergure contre l'une de vos applications, le SRT peut vous contacter de manière proactive. Le SRT trie l'événement DDo S et crée AWS WAF des mesures d'atténuation. La SRT vous contacte et, avec votre accord, peut appliquer les AWS WAF règles. Pour plus d’informations sur cette option, consultez [Mettre en place un engagement proactif pour que le SRT vous contacte directement](ddos-srt-proactive-engagement.md).
# Contacter le centre de support lors d'une attaque de couche DDo applicative S
Cette page fournit des instructions pour contacter le centre de support lors d'une attaque de la couche applicative DDo S.
Si vous êtes AWS Shield Advanced client, vous pouvez contacter le [AWS Support Centre](https://console.aws.amazon.com/support/home#/) pour obtenir de l'aide concernant les mesures d'atténuation. Les cas critiques et urgents sont transmis directement aux experts DDo S. Les cas complexes peuvent ainsi être transmis à la AWS Shield Response Team (SRT), qui possède une vaste expérience dans le domaine de la protection AWS d'Amazon.com et de ses filiales. AWS Shield Advanced Pour plus d'informations sur le SRT, consultez[Réponse aux événements Managed DDo S avec le support de la Shield Response Team (SRT)](ddos-srt-support.md).
Pour obtenir l'assistance de la Shield Response Team (SRT), contactez le [AWS Support Center](https://console.aws.amazon.com/support/home#/). Le temps de réponse de votre dossier dépend de la gravité que vous sélectionnez et des temps de réponse, qui sont documentés sur la page [AWS Support Plans](https://aws.amazon.com/premiumsupport/compare-plans/).
Sélectionnez les options suivantes :
+ Type de cas : Support technique
+ Service : déni de service distribué (DDoS)
+ Catégorie : Entrant vers AWS
+ Gravité : *Choisissez une action appropriée*
Lorsque vous discutez avec notre représentant, expliquez que vous êtes un AWS Shield Advanced client victime d'une éventuelle attaque DDo S. Notre représentant dirigera votre appel vers les experts DDo S appropriés. Si vous ouvrez un dossier auprès du [AWS Support Centre](https://console.aws.amazon.com/support/home#/) en utilisant le type **de service de déni de service distribué (DDoS)**, vous pouvez parler directement à un expert DDo S par chat ou par téléphone. DDoLes ingénieurs du support S peuvent vous aider à identifier les attaques, à recommander des améliorations à apporter à votre AWS architecture et à vous conseiller sur l'utilisation des AWS services pour atténuer les attaques DDo S.
Pour les attaques de la couche applicative, le SRT peut vous aider à analyser les activités suspectes. Si l'atténuation automatique est activée pour votre ressource, le SRT peut examiner les mesures d'atténuation que Shield Advanced place automatiquement contre l'attaque. Dans tous les cas, le SRT peut vous aider à examiner et à atténuer le problème. Les mesures d'atténuation recommandées par le SRT nécessitent souvent que le SRT crée ou mette à jour des listes de contrôle d'accès AWS WAF Web (Web ACLs) dans votre compte. Le SRT aura besoin de votre autorisation pour effectuer ce travail.
**Important**
Dans le cadre de l'activation AWS Shield Advanced, nous vous recommandons de suivre les étapes ci-dessous [Octroi de l'accès au SRT](ddos-srt-access.md) pour fournir de manière proactive au SRT les autorisations dont il a besoin pour vous aider lors d'une attaque. La fourniture préalable de l'autorisation permet d'éviter tout retard en cas d'attaque réelle.
Le SRT vous aide à trier l'attaque DDo S afin d'identifier les signatures et les modèles d'attaque. Avec votre accord, le SRT crée et déploie des AWS WAF règles pour atténuer l'attaque.
Vous pouvez également contacter le SRT avant ou pendant une éventuelle attaque pour examiner les mesures d'atténuation et pour développer et déployer des mesures d'atténuation personnalisées. Par exemple, si vous exécutez une application Web et que seuls les ports 80 et 443 sont ouverts, vous pouvez utiliser le SRT pour préconfigurer une ACL Web afin d' « autoriser » uniquement les ports 80 et 443.
Vous autorisez et contactez le SRT au niveau du compte. En d'autres termes, si vous utilisez Shield Advanced dans le cadre d'une politique de Firewall Manager Shield Advanced, c'est le propriétaire du compte, et non l'administrateur de Firewall Manager, qui doit contacter le SRT pour obtenir de l'aide. L'administrateur de Firewall Manager ne peut contacter le SRT que pour les comptes qu'il possède.
# Atténuation manuelle d'une attaque de couche applicative DDo S
Cette page fournit des instructions pour atténuer manuellement une attaque de couche d'application DDo S.
Si vous déterminez que l'activité de la page des événements de votre ressource représente une attaque DDo S, vous pouvez créer vos propres AWS WAF règles dans votre ACL Web pour atténuer l'attaque. C'est la seule option disponible si vous n'êtes pas client de Shield Advanced. AWS WAF est inclus sans AWS Shield Advanced frais supplémentaires. Pour plus d'informations sur la création de règles dans votre ACL Web, consultez[Configuration de la protection dans AWS WAF](web-acl.md).
Si vous l'utilisez AWS Firewall Manager, vous pouvez ajouter vos AWS WAF règles à une AWS WAF politique de Firewall Manager.
**Pour atténuer manuellement une attaque potentielle de couche DDo applicative S**
1. Créez des instructions de règles dans votre ACL Web avec des critères correspondant au comportement inhabituel. Pour commencer, configurez-les pour compter les demandes correspondantes. Pour plus d'informations sur la configuration de votre ACL Web et de vos instructions de règles, consultez [Utilisation de packs de protection (Web ACLs) avec des règles et des groupes de règles dans AWS WAF](web-acl-processing.md) et[Tester et ajuster vos AWS WAF protections](web-acl-testing.md).
**Note**
Testez toujours vos règles d'abord en utilisant initialement l'action de la règle Count au lieu deBlock. Une fois que vous êtes certain que vos nouvelles règles identifient les bonnes demandes, vous pouvez les modifier pour bloquer les demandes.
1. Surveillez le nombre de demandes pour déterminer si vous souhaitez bloquer les demandes correspondantes. Si le volume de demandes continue d'être anormalement élevé et que vous êtes certain que vos règles tiennent compte des demandes à l'origine de ce volume élevé, modifiez les règles de votre ACL Web pour bloquer les demandes.
1. Continuez à surveiller la page des événements pour vous assurer que votre trafic est traité comme vous le souhaitez.
AWS fournit des modèles préconfigurés pour vous aider à démarrer rapidement. Les modèles incluent un ensemble de AWS WAF règles que vous pouvez personnaliser et utiliser pour bloquer les attaques Web courantes. Pour plus d'informations, consultez le document sur les [automatisations de sécuritéAWS WAF](https://aws.amazon.com/solutions/aws-waf-security-automations/).
# Demande de crédit AWS Shield Advanced après une attaque
Si vous êtes abonné AWS Shield Advanced et que vous êtes victime d'une attaque DDo S qui augmente l'utilisation d'une ressource protégée par Shield Advanced, vous pouvez demander un crédit de service Shield Advanced pour les frais liés à cette utilisation accrue, dans la mesure où cette utilisation n'est pas atténuée par Shield Advanced.
**Note**
Vous ne pouvez appliquer les crédits reçus dans le cadre de ce processus qu'à l'utilisation de Shield Advanced. Les crédits Shield Advanced ne peuvent pas être utilisés avec d'autres services.
Les crédits ne sont disponibles que pour les types de frais suivants :
+ Transfert de données Shield Advanced
+ Requêtes CloudFront HTTP/HTTPS d'Amazon
+ CloudFront transfert de données sortantes
+ Requêtes Amazon Route 53
+ AWS Global Accelerator transfert de données par accélérateur standard
+ Unités de capacité d'équilibrage de charge pour Application Load Balancer
+ Coûts d'instance pour les instances Amazon Elastic Compute Cloud (Amazon EC2) protégées créées par une politique d'auto-scaling en réponse à l'attaque
**Conditions préalables à la demande de crédit**
Pour être éligible à recevoir un crédit, avant le début de l'attaque, vous devez avoir effectué les opérations suivantes :
+ Vous devez avoir ajouté la protection Shield Advanced aux ressources pour lesquelles vous souhaitez demander un crédit. Les ressources protégées ajoutées lors d'une attaque ne sont pas éligibles à la protection des coûts.
**Note**
L'activation de Shield Advanced sur votre Compte AWS ordinateur n'active pas automatiquement la protection Shield Advanced pour les ressources individuelles.
Pour plus d'informations sur la façon de protéger les AWS ressources à l'aide de Shield Advanced, consultez[Ajouter AWS Shield Advanced une protection aux AWS ressources](configure-new-protection.md).
+ Pour les ressources applicables CloudFront et protégées par Application Load Balancer, vous devez avoir associé une ACL AWS WAF Web et implémenté une règle basée sur le taux dans l'ACL Web en mode. Block Pour plus d'informations sur les règles AWS WAF basées sur les taux, consultez[Utilisation d'instructions de règles basées sur le taux dans AWS WAF](waf-rule-statement-type-rate-based.md). Pour plus d'informations sur la façon d' ACLs associer le Web à AWS des ressources, consultez[Configuration de la protection dans AWS WAF](web-acl.md).
+ Vous devez avoir mis en œuvre les meilleures pratiques appropriées dans [AWS Best Practices for DDo S Resiliency](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency) afin de configurer votre application de manière à minimiser les coûts lors d'une attaque DDo S.
**Comment faire une demande de crédit**
Pour être éligible à un crédit, vous devez soumettre votre demande de crédit dans les 15 jours suivant immédiatement le mois de facturation au cours duquel l'attaque s'est produite.
Pour demander un crédit, soumettez un dossier de facturation par l'intermédiaire du [AWS Support Centre](https://console.aws.amazon.com/support/home#/). Incluez les éléments suivants dans votre demande :
+ Les mots « DDo S Concession » dans la ligne d'objet
+ Les dates et heures de chaque événement ou interruption de disponibilité pour lequel vous demandez un crédit
+ Les AWS services et les ressources spécifiques concernés
Après avoir soumis une demande, la AWS Shield Response Team (SRT) validera si une attaque DDo S s'est produite et, dans l'affirmative, si des ressources protégées ont été redimensionnées pour absorber l'attaque DDo S. S'il est AWS déterminé que les ressources protégées ont été dimensionnées pour absorber l'attaque DDo S, AWS il émettra un crédit pour la partie du trafic qui a été AWS déterminée comme ayant été causée par l'attaque DDo S. Les crédits sont valides pendant 12 mois.
# Sécurité lors de votre utilisation du AWS Shield service
Cette section explique comment le modèle de responsabilité partagée s'applique à AWS Shield.
La sécurité du cloud AWS est la priorité absolue. En tant que AWS client, vous bénéficiez d'un centre de données et d'une architecture réseau conçus pour répondre aux exigences des entreprises les plus sensibles en matière de sécurité.
**Note**
Cette section fournit des conseils AWS de sécurité standard pour votre utilisation du AWS Shield service et de ses AWS ressources, telles que les protections Shield Advanced.
Pour plus d'informations sur la protection de vos AWS ressources à l'aide de Shield et Shield Advanced, consultez le reste du AWS Shield guide.
La sécurité est une responsabilité partagée entre vous AWS et vous. Le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) décrit cette notion par les termes sécurité *du* cloud et sécurité *dans* le cloud :
+ **Sécurité du cloud** : AWS est chargée de protéger l'infrastructure qui exécute les AWS services dans le AWS Cloud. AWS vous fournit également des services que vous pouvez utiliser en toute sécurité. L’efficacité de notre sécurité est régulièrement testée et vérifiée par des auditeurs tiers dans le cadre des [programmes de conformitéAWS](https://aws.amazon.com/compliance/programs/). Pour en savoir plus sur les programmes de conformité qui s'appliquent à Shield, consultez la section [AWS Services concernés par programme de conformité](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sécurité dans le cloud** — Votre responsabilité est déterminée par le AWS service que vous utilisez. Vous êtes également responsable d’autres facteurs, y compris la sensibilité de vos données, les exigences de votre organisation, et la législation et la réglementation applicables.
Cette documentation vous aide à comprendre comment appliquer le modèle de responsabilité partagée lors de l'utilisation de Shield. Les rubriques suivantes expliquent comment configurer Shield pour répondre à vos objectifs de sécurité et de conformité. Vous apprendrez également à utiliser d'autres AWS services qui vous aident à surveiller et à sécuriser vos ressources du Shield.
**Topics**
+ [Protection de vos données dans Shield](shd-data-protection.md)
+ [Utilisation d'IAM avec AWS Shield](shd-security-iam.md)
+ [Journalisation et surveillance dans Shield](shd-incident-response.md)
+ [Validation de la conformité dans Shield](shd-security-compliance.md)
+ [Construire pour la résilience dans Shield](shd-disaster-recovery-resiliency.md)
+ [Sécurité de l'infrastructure dans AWS Shield](shd-infrastructure-security.md)
# Protection de vos données dans Shield
Cette section explique comment le modèle de responsabilité AWS partagée s'applique à la protection des données dans Shield.
Le [modèle de responsabilité AWS partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) de s'applique à la protection des données dans AWS Shield. Comme décrit dans ce modèle, AWS est chargé de protéger l'infrastructure mondiale qui gère tous les AWS Cloud. La gestion du contrôle de votre contenu hébergé sur cette infrastructure relève de votre responsabilité. Vous êtes également responsable des tâches de configuration et de gestion de la sécurité des Services AWS que vous utilisez. Pour plus d’informations sur la confidentialité des données, consultez [Questions fréquentes (FAQ) sur la confidentialité des données](https://aws.amazon.com/compliance/data-privacy-faq/). Pour en savoir plus sur la protection des données en Europe, consultez le billet de blog [Modèle de responsabilité partagée d’AWS et RGPD (Règlement général sur la protection des données)](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) sur le *Blog de sécuritéAWS *.
À des fins de protection des données, nous vous recommandons de protéger les Compte AWS informations d'identification et de configurer les utilisateurs individuels avec AWS IAM Identity Center ou Gestion des identités et des accès AWS (IAM). Ainsi, chaque utilisateur se voit attribuer uniquement les autorisations nécessaires pour exécuter ses tâches. Nous vous recommandons également de sécuriser vos données comme indiqué ci-dessous :
+ Utilisez l’authentification multifactorielle (MFA) avec chaque compte.
+ SSL/TLS À utiliser pour communiquer avec AWS les ressources. Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Configurez l'API et la journalisation de l'activité des utilisateurs avec AWS CloudTrail. Pour plus d'informations sur l'utilisation des CloudTrail sentiers pour capturer AWS des activités, consultez la section [Utilisation des CloudTrail sentiers](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) dans le *guide de AWS CloudTrail l'utilisateur*.
+ Utilisez des solutions de AWS chiffrement, ainsi que tous les contrôles de sécurité par défaut qu'ils contiennent Services AWS.
+ Utilisez des services de sécurité gérés avancés tels qu’Amazon Macie, qui contribuent à la découverte et à la sécurisation des données sensibles stockées dans Amazon S3.
+ Si vous avez besoin de modules cryptographiques validés par la norme FIPS 140-3 pour accéder AWS via une interface de ligne de commande ou une API, utilisez un point de terminaison FIPS. Pour plus d’informations sur les points de terminaison FIPS disponibles, consultez [Norme FIPS (Federal Information Processing Standard) 140-3](https://aws.amazon.com/compliance/fips/).
Nous vous recommandons fortement de ne jamais placer d’informations confidentielles ou sensibles, telles que les adresses e-mail de vos clients, dans des balises ou des champs de texte libre tels que le champ **Nom**. Cela inclut lorsque vous travaillez avec Shield ou un autre utilisateur Services AWS à l'aide de la console AWS CLI, de l'API ou AWS SDKs. Toutes les données que vous entrez dans des balises ou des champs de texte de forme libre utilisés pour les noms peuvent être utilisées à des fins de facturation ou dans les journaux de diagnostic. Si vous fournissez une adresse URL à un serveur externe, nous vous recommandons fortement de ne pas inclure d’informations d’identification dans l’adresse URL permettant de valider votre demande adressée à ce serveur.
Les entités du Shield, telles que les protections, sont cryptées au repos, sauf dans certaines régions où le chiffrement n'est pas disponible, notamment en Chine (Pékin) et en Chine (Ningxia). Des clés de chiffrement uniques sont utilisées pour chaque région.
# Utilisation d'IAM avec AWS Shield
Cette section explique comment utiliser IAM avec AWS Shield.
Gestion des identités et des accès AWS (IAM) est un outil Service AWS qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. Les administrateurs IAM contrôlent qui peut être *authentifié* (connecté) et *autorisé (autorisé*) à utiliser les ressources du Shield. IAM est un Service AWS outil que vous pouvez utiliser sans frais supplémentaires.
**Topics**
+ [Public ciblé](#security_iam_audience)
+ [Authentification par des identités](#security_iam_authentication)
+ [Gestion de l’accès à l’aide de politiques](#security_iam_access-manage)
+ [Comment AWS Shield fonctionne avec IAM](shd-security_iam_service-with-iam.md)
+ [Exemples de politiques basées sur l'identité pour AWS Shield](shd-security_iam_id-based-policy-examples.md)
+ [AWS politiques gérées pour AWS Shield](shd-security-iam-awsmanpol.md)
+ [Résolution des problèmes AWS Shield d'identité et d'accès](shd-security_iam_troubleshoot.md)
+ [Utilisation de rôles liés à un service pour Shield Advanced](shd-using-service-linked-roles.md)
## Public ciblé
La façon dont vous utilisez Gestion des identités et des accès AWS (IAM) varie en fonction du travail que vous effectuez dans Shield.
**Utilisateur du service** : si vous utilisez le service Shield pour effectuer votre travail, votre administrateur vous fournit les informations d'identification et les autorisations dont vous avez besoin. Au fur et à mesure que vous utilisez de plus en plus de fonctionnalités du Shield pour effectuer votre travail, il se peut que vous ayez besoin d'autorisations supplémentaires. Si vous comprenez bien la gestion des accès, vous saurez demander les autorisations appropriées à votre administrateur. Si vous ne parvenez pas à accéder à une fonctionnalité dans Shield, consultez[Résolution des problèmes AWS Shield d'identité et d'accès](shd-security_iam_troubleshoot.md).
**Administrateur du service** — Si vous êtes responsable des ressources du Shield au sein de votre entreprise, vous avez probablement un accès complet à Shield. C'est à vous de déterminer les fonctionnalités et les ressources du Shield auxquelles les utilisateurs de votre service doivent accéder. Vous devez ensuite soumettre les demandes à votre administrateur IAM pour modifier les autorisations des utilisateurs de votre service. Consultez les informations sur cette page pour comprendre les concepts de base d’IAM. Pour en savoir plus sur la manière dont votre entreprise peut utiliser IAM with Shield, consultez[Comment AWS Shield fonctionne avec IAM](shd-security_iam_service-with-iam.md).
**Administrateur IAM** — Si vous êtes administrateur IAM, vous souhaiterez peut-être en savoir plus sur la manière dont vous pouvez rédiger des politiques pour gérer l'accès à Shield. Pour consulter des exemples de politiques basées sur l'identité du Shield que vous pouvez utiliser dans IAM, consultez. [Exemples de politiques basées sur l'identité pour AWS Shield](shd-security_iam_id-based-policy-examples.md)
## Authentification par des identités
L'authentification est la façon dont vous vous connectez à AWS l'aide de vos informations d'identification. Vous devez être authentifié en tant qu'utilisateur IAM ou en assumant un rôle IAM. Utilisateur racine d'un compte AWS
Vous pouvez vous connecter en tant qu'identité fédérée à l'aide d'informations d'identification provenant d'une source d'identité telle que AWS IAM Identity Center (IAM Identity Center), d'une authentification unique ou d'informations d'identification. Google/Facebook Pour plus d’informations sur la connexion, consultez [Connexion à votre Compte AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) dans le *Guide de l’utilisateur Connexion à AWS *.
Pour l'accès par programmation, AWS fournit un SDK et une CLI pour signer les demandes de manière cryptographique. Pour plus d’informations, consultez [Signature AWS Version 4 pour les demandes d’API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) dans le *Guide de l’utilisateur IAM*.
### Compte AWS utilisateur root
Lorsque vous créez un Compte AWS, vous commencez par une seule identité de connexion appelée *utilisateur Compte AWS root* qui dispose d'un accès complet à toutes Services AWS les ressources. Il est vivement déconseillé d’utiliser l’utilisateur racine pour vos tâches quotidiennes. Pour les tâches qui requièrent des informations d’identification de l’utilisateur racine, consultez [Tâches qui requièrent les informations d’identification de l’utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) dans le *Guide de l’utilisateur IAM*.
### Identité fédérée
Il est recommandé d'obliger les utilisateurs humains à utiliser la fédération avec un fournisseur d'identité pour accéder à Services AWS l'aide d'informations d'identification temporaires.
Une *identité fédérée* est un utilisateur provenant de votre annuaire d'entreprise, de votre fournisseur d'identité Web ou Directory Service qui y accède à Services AWS l'aide d'informations d'identification provenant d'une source d'identité. Les identités fédérées assument des rôles qui fournissent des informations d’identification temporaires.
Pour une gestion des accès centralisée, nous vous recommandons d’utiliser AWS IAM Identity Center. Pour plus d’informations, consultez [Qu’est-ce que IAM Identity Center ?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
### Utilisateurs et groupes IAM
Un *[utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* est une identité qui dispose d’autorisations spécifiques pour une seule personne ou application. Nous vous recommandons d’utiliser ces informations d’identification temporaires au lieu des utilisateurs IAM avec des informations d’identification à long terme. Pour plus d'informations, voir [Exiger des utilisateurs humains qu'ils utilisent la fédération avec un fournisseur d'identité pour accéder à AWS l'aide d'informations d'identification temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) dans le *guide de l'utilisateur IAM*.
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) spécifient une collection d’utilisateurs IAM et permettent de gérer plus facilement les autorisations pour de grands ensembles d’utilisateurs. Pour plus d’informations, consultez [Cas d’utilisation pour les utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) dans le *Guide de l’utilisateur IAM*.
### Rôles IAM
Un *[rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* est une identité dotée d’autorisations spécifiques qui fournit des informations d’identification temporaires. Vous pouvez assumer un rôle en [passant d'un rôle d'utilisateur à un rôle IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ou en appelant une opération d' AWS API AWS CLI ou d'API. Pour plus d’informations, consultez [Méthodes pour endosser un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) dans le *Guide de l’utilisateur IAM*.
Les rôles IAM sont utiles pour l’accès des utilisateurs fédérés, les autorisations temporaires des utilisateurs IAM, les accès intercompte, les accès entre services et les applications exécutées sur Amazon EC2. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
## Gestion de l’accès à l’aide de politiques
Vous contrôlez l'accès en AWS créant des politiques et en les associant à AWS des identités ou à des ressources. Une politique définit les autorisations lorsqu'elles sont associées à une identité ou à une ressource. AWS évalue ces politiques lorsqu'un directeur fait une demande. La plupart des politiques sont stockées AWS sous forme de documents JSON. Pour plus d’informations les documents de politique JSON, consultez [Vue d’ensemble des politiques JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) dans le *Guide de l’utilisateur IAM*.
À l’aide de politiques, les administrateurs précisent qui a accès à quoi en définissant quel **principal** peut effectuer des **actions** sur quelles **ressources** et dans quelles **conditions**.
Par défaut, les utilisateurs et les rôles ne disposent d’aucune autorisation. Un administrateur IAM crée des politiques IAM et les ajoute aux rôles, que les utilisateurs peuvent ensuite assumer. Les politiques IAM définissent les autorisations quelle que soit la méthode que vous utilisez pour exécuter l’opération.
### Politiques basées sur l’identité
Les stratégies basées sur l’identité sont des documents de stratégie d’autorisations JSON que vous attachez à une identité (utilisateur, groupe ou rôle). Ces politiques contrôlent les actions que peuvent exécuter ces identités, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.
Les politiques basées sur l’identité peuvent être des *politiques intégrées* (intégrées directement dans une seule identité) ou des *politiques gérées (politiques* autonomes associées à plusieurs identités). Pour découvrir comment choisir entre des politiques gérées et en ligne, consultez [Choix entre les politiques gérées et les politiques en ligne](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) dans le *Guide de l’utilisateur IAM*.
### Politiques basées sur les ressources
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Les exemples incluent *les politiques de confiance de rôle* IAM et les *stratégies de compartiment* Amazon S3. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources.
Les politiques basées sur les ressources sont des politiques en ligne situées dans ce service. Vous ne pouvez pas utiliser les politiques AWS gérées par IAM dans une stratégie basée sur les ressources.
### Listes de contrôle d'accès (ACLs)
Les listes de contrôle d'accès (ACLs) contrôlent les principaux (membres du compte, utilisateurs ou rôles) autorisés à accéder à une ressource. ACLs sont similaires aux politiques basées sur les ressources, bien qu'elles n'utilisent pas le format de document de politique JSON.
Amazon S3 et AWS WAF Amazon VPC sont des exemples de services compatibles. ACLs Pour en savoir plus ACLs, consultez la [présentation de la liste de contrôle d'accès (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) dans le *guide du développeur Amazon Simple Storage Service*.
### Autres types de politique
AWS prend en charge des types de politiques supplémentaires qui peuvent définir les autorisations maximales accordées par les types de politiques les plus courants :
+ **Limites d’autorisations** : une limite des autorisations définit le nombre maximum d’autorisations qu’une politique basée sur l’identité peut accorder à une entité IAM. Pour plus d’informations, consultez [Limites d’autorisations pour des entités IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) dans le *Guide de l’utilisateur IAM*.
+ **Politiques de contrôle des services (SCPs)** — Spécifiez les autorisations maximales pour une organisation ou une unité organisationnelle dans AWS Organizations. Pour plus d’informations, consultez [Politiques de contrôle de service](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dans le *Guide de l’utilisateur AWS Organizations *.
+ **Politiques de contrôle des ressources (RCPs)** : définissez le maximum d'autorisations disponibles pour les ressources de vos comptes. Pour plus d'informations, voir [Politiques de contrôle des ressources (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) dans le *guide de AWS Organizations l'utilisateur*.
+ **Politiques de session** : politiques avancées que vous passez en tant que paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur fédéré. Pour plus d’informations, consultez [Politiques de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) dans le *Guide de l’utilisateur IAM*.
### Plusieurs types de politique
Lorsque plusieurs types de politiques s’appliquent à la requête, les autorisations en résultant sont plus compliquées à comprendre. Pour savoir comment AWS déterminer s'il faut autoriser une demande lorsque plusieurs types de politiques sont impliqués, consultez la section [Logique d'évaluation des politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) dans le *guide de l'utilisateur IAM*.
# Comment AWS Shield fonctionne avec IAM
Cette section explique comment utiliser les fonctionnalités d'IAM avec AWS Shield.
Avant d'utiliser IAM pour gérer l'accès à Shield, découvrez quelles fonctionnalités IAM peuvent être utilisées avec Shield.
**Fonctionnalités IAM que vous pouvez utiliser avec AWS Shield**
| Fonctionnalité IAM | Support Shield |
| --- | --- |
| [Politiques basées sur l’identité](#shd-security_iam_service-with-iam-id-based-policies) | Oui |
| [Politiques basées sur les ressources](#shd-security_iam_service-with-iam-resource-based-policies) | Non |
| [Actions de politique](#shd-security_iam_service-with-iam-id-based-policies-actions) | Oui |
| [Ressources de politique](#shd-security_iam_service-with-iam-id-based-policies-resources) | Oui |
| [Clés de condition de politique (spécifiques au service)](#shd-security_iam_service-with-iam-id-based-policies-conditionkeys) | Oui |
| [ACLs](#shd-security_iam_service-with-iam-acls) | Non |
| [ABAC (identifications dans les politiques)](#shd-security_iam_service-with-iam-tags) | Partielle |
| [Informations d’identification temporaires](#shd-security_iam_service-with-iam-roles-tempcreds) | Oui |
| [Transmission des sessions d’accès (FAS)](#shd-security_iam_service-with-iam-principal-permissions) | Oui |
| [Rôles de service](#shd-security_iam_service-with-iam-roles-service) | Oui |
| [Rôles liés à un service](#shd-security_iam_service-with-iam-roles-service-linked) | Oui |
Pour obtenir une vue d'ensemble de la façon dont Shield et les autres AWS services fonctionnent avec la plupart des fonctionnalités IAM, consultez la section [AWS Services compatibles avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le guide de l'utilisateur *IAM*.
## Politiques basées sur l'identité pour Shield
Cette section fournit des exemples de politiques basées sur l'identité pour. AWS Shield
**Prend en charge les politiques basées sur l’identité :** oui
Les politiques basées sur l’identité sont des documents de politique d’autorisations JSON que vous pouvez attacher à une identité telle qu’un utilisateur, un groupe d’utilisateurs ou un rôle IAM. Ces politiques contrôlent quel type d’actions des utilisateurs et des rôles peuvent exécuter, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.
Avec les politiques IAM basées sur l’identité, vous pouvez spécifier des actions et ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. Pour découvrir tous les éléments que vous utilisez dans une politique JSON, consultez [Références des éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dans le *Guide de l’utilisateur IAM*.
Pour consulter des exemples de politiques basées sur l'identité du Shield, consultez. [Exemples de politiques basées sur l'identité pour AWS Shield](shd-security_iam_id-based-policy-examples.md)
## Politiques basées sur les ressources au sein de Shield
**Prend en charge les politiques basées sur les ressources :** non
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Par exemple, les *politiques de confiance de rôle* IAM et les *politiques de compartiment* Amazon S3 sont des politiques basées sur les ressources. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Pour la ressource dans laquelle se trouve la politique, cette dernière définit quel type d’actions un principal spécifié peut effectuer sur cette ressource et dans quelles conditions. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources. Les principaux peuvent inclure des comptes, des utilisateurs, des rôles, des utilisateurs fédérés ou. Services AWS
Pour permettre un accès intercompte, vous pouvez spécifier un compte entier ou des entités IAM dans un autre compte en tant que principal dans une politique basée sur les ressources. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
## Actions politiques pour Shield
**Prend en charge les actions de politique :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Action` d’une politique JSON décrit les actions que vous pouvez utiliser pour autoriser ou refuser l’accès à une politique. Intégration d’actions dans une politique afin d’accorder l’autorisation d’exécuter les opérations associées.
Pour consulter la liste des actions du Shield, consultez la section [Actions définies par AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions) dans le *Service Authorization Reference*.
Les actions politiques dans Shield utilisent le préfixe suivant avant l'action :
```
shield
```
Pour indiquer plusieurs actions dans une seule déclaration, séparez-les par des virgules.
```
"Action": [
"shield:action1",
"shield:action2"
]
```
Vous pouvez aussi spécifier plusieurs actions à l’aide de caractères génériques (\$1). Par exemple, pour spécifier toutes les actions commençant par « Shield »`List`, incluez l'action suivante :
```
"Action": "shield:List*"
```
Pour consulter des exemples de politiques basées sur l'identité du Shield, consultez. [Exemples de politiques basées sur l'identité pour AWS Shield](shd-security_iam_id-based-policy-examples.md)
## Ressources relatives aux politiques pour Shield
**Prend en charge les ressources de politique :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément de politique JSON `Resource` indique le ou les objets auxquels l’action s’applique. Il est recommandé de définir une ressource à l’aide de son [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Pour les actions qui ne sont pas compatibles avec les autorisations de niveau ressource, utilisez un caractère générique (\$1) afin d’indiquer que l’instruction s’applique à toutes les ressources.
```
"Resource": "*"
```
Pour consulter la liste des types de ressources Shield et leurs caractéristiques ARNs, consultez la section [Ressources définies par AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-resources-for-iam-policies) dans le *Service Authorization Reference*. Pour savoir grâce à quelles actions vous pouvez spécifier l’ARN de chaque ressource, consultez [Actions définies par AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions). Pour autoriser ou refuser l'accès à un sous-ensemble de ressources du Shield, incluez l'ARN de la ressource dans l'`resource`élément de votre politique.
Dans AWS Shield, les ressources sont les *protections* et *les attaques*. Ces ressources sont associées à des noms de ressources Amazon uniques (ARNs), comme indiqué dans le tableau suivant.
****
| Nom dans la AWS Shield console | Nom dans le AWS Shield SDK/CLI | Format ARN |
| --- | --- | --- |
| Événement ou attaque | AttackDetail | `arn:aws:shield::account:attack/ID` |
| Protection | Protection | `arn:aws:shield::account:protection/ID` |
Pour autoriser ou refuser l'accès à un sous-ensemble de ressources du Shield, incluez l'ARN de la ressource dans l'`resource`élément de votre politique. Les ARNs for Shield ont le format suivant :
```
arn:partition:shield::account:resource/ID
```
Remplacez les *ID* variables *account**resource*, et par des valeurs valides. Les valeurs valides peuvent être les suivantes :
+ *account*: L'identifiant de votre Compte AWS. Vous devez spécifier une valeur.
+ *resource*: le type de ressource Shield, `attack` soit`protection`.
+ *ID*: L'ID de la ressource Shield, ou un caractère générique (`*`) pour indiquer toutes les ressources du type spécifié associées à la ressource spécifiée Compte AWS.
Par exemple, l'ARN suivante spécifie toutes les protections pour le compte `111122223333` :
```
arn:aws:shield::111122223333:protection/*
```
Les ressources ARNs du Shield ont le format suivant :
```
arn:partition:shield:region:account-id:scope/resource-type/resource-name/resource-id
```
Pour des informations générales sur les spécifications de l'ARN, consultez [Amazon Resource Names (ARNs)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) dans le Référence générale d'Amazon Web Services.
La liste suivante répertorie les exigences spécifiques ARNs aux `wafv2` ressources :
+ *region*: pour les ressources Shield que vous utilisez pour protéger les CloudFront distributions Amazon, définissez ce paramètre sur`us-east-1`. Sinon, définissez ce paramètre sur la région que vous utilisez avec vos ressources régionales protégées.
+ *scope*: définissez le champ d'application `global` pour une utilisation avec une CloudFront distribution Amazon ou `regional` pour une utilisation avec l'une des ressources régionales prises AWS WAF en charge. Les ressources régionales sont une API REST Amazon API Gateway, un Application Load Balancer, une API AWS AppSync GraphQL, un groupe d'utilisateurs Amazon Cognito, un AWS App Runner service et une instance Verified Access. AWS
+ *resource-type*: Spécifiez l'une des valeurs suivantes : `attack` pour les événements ou les attaques, `protection` pour les protections.
+ *resource-name*: Spécifiez le nom que vous avez donné à la ressource Shield ou spécifiez un caractère générique (`*`) pour indiquer toutes les ressources qui répondent aux autres spécifications de l'ARN. Vous devez soit spécifier le nom et l'ID de la ressource, soit spécifier un caractère générique pour les deux.
+ *resource-id*: Spécifiez l'ID de la ressource Shield ou spécifiez un caractère générique (`*`) pour indiquer toutes les ressources qui répondent aux autres spécifications de l'ARN. Vous devez soit spécifier le nom et l'ID de la ressource, soit spécifier un caractère générique pour les deux.
Par exemple, l'ARN suivant spécifie tous les sites Web ACLs ayant une portée régionale pour le compte `111122223333` dans Region `us-west-1` :
```
arn:aws:wafv2:us-west-1:111122223333:regional/webacl/*/*
```
L'ARN suivant spécifie le groupe de règles nommé `MyIPManagementRuleGroup` avec une portée globale pour le compte `111122223333` dans Region `us-east-1` :
```
arn:aws:wafv2:us-east-1:111122223333:global/rulegroup/MyIPManagementRuleGroup/1111aaaa-bbbb-cccc-dddd-example-id
```
Pour consulter des exemples de politiques basées sur l'identité du Shield, consultez. [Exemples de politiques basées sur l'identité pour AWS Shield](shd-security_iam_id-based-policy-examples.md)
## Clés relatives aux conditions de politique pour Shield
**Prend en charge les clés de condition de politique spécifiques au service :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Condition` indique à quel moment les instructions s’exécutent en fonction de critères définis. Vous pouvez créer des expressions conditionnelles qui utilisent des [opérateurs de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tels que les signes égal ou inférieur à, pour faire correspondre la condition de la politique aux valeurs de la demande. Pour voir toutes les clés de condition AWS globales, voir les clés de [contexte de condition AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.
Pour consulter la liste des clés de condition du Shield, reportez-vous à la section [Clés de condition correspondantes AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-policy-keys) dans le *Service Authorization Reference*. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, consultez la section [Actions définies par AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions).
Pour consulter des exemples de politiques basées sur l'identité du Shield, consultez. [Exemples de politiques basées sur l'identité pour AWS Shield](shd-security_iam_id-based-policy-examples.md)
## ACLs dans Shield
**Supports ACLs :** Non
Les listes de contrôle d'accès (ACLs) contrôlent les principaux (membres du compte, utilisateurs ou rôles) autorisés à accéder à une ressource. ACLs sont similaires aux politiques basées sur les ressources, bien qu'elles n'utilisent pas le format de document de politique JSON.
## ABAC avec Shield
**Prend en charge ABAC (identifications dans les politiques) :** partiellement
Le contrôle d’accès par attributs (ABAC) est une stratégie d’autorisation qui définit les autorisations en fonction des attributs nommés balise. Vous pouvez associer des balises aux entités et aux AWS ressources IAM, puis concevoir des politiques ABAC pour autoriser les opérations lorsque la balise du principal correspond à la balise de la ressource.
Pour contrôler l’accès basé sur des étiquettes, vous devez fournir les informations d’étiquette dans l’[élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d’une politique utilisant les clés de condition `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou `aws:TagKeys`.
Si un service prend en charge les trois clés de condition pour tous les types de ressources, alors la valeur pour ce service est **Oui**. Si un service prend en charge les trois clés de condition pour certains types de ressources uniquement, la valeur est **Partielle**.
Pour plus d’informations sur ABAC, consultez [Définition d’autorisations avec l’autorisation ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*. Pour accéder à un didacticiel décrivant les étapes de configuration de l’ABAC, consultez [Utilisation du contrôle d’accès par attributs (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*.
## Utilisation d'informations d'identification temporaires avec Shield
**Prend en charge les informations d’identification temporaires :** oui
Les informations d'identification temporaires fournissent un accès à court terme aux AWS ressources et sont automatiquement créées lorsque vous utilisez la fédération ou que vous changez de rôle. AWS recommande de générer dynamiquement des informations d'identification temporaires au lieu d'utiliser des clés d'accès à long terme. Pour plus d’informations, consultez [Informations d’identification de sécurité temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) et [Services AWS compatibles avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le *Guide de l’utilisateur IAM*.
## Sessions d'accès transmises pour Shield
**Prend en charge les sessions d’accès direct (FAS) :** oui
Les sessions d'accès direct (FAS) utilisent les autorisations du principal appelant et Service AWS, combinées Service AWS à la demande d'envoi de demandes aux services en aval. Pour plus de détails sur la politique relative à la transmission de demandes FAS, consultez la section [Sessions de transmission d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Rôles de service pour Shield
**Prend en charge les rôles de service :** oui
Un rôle de service est un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) qu’un service endosse pour accomplir des actions en votre nom. Un administrateur IAM peut créer, modifier et supprimer un rôle de service à partir d’IAM. Pour plus d’informations, consultez [Création d’un rôle pour la délégation d’autorisations à un Service AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le *Guide de l’utilisateur IAM*.
**Avertissement**
La modification des autorisations associées à un rôle de service peut perturber les fonctionnalités du Shield. Modifiez les rôles de service uniquement lorsque Shield fournit des instructions à cet effet.
## Rôles liés à un service pour Shield
**Prend en charge les rôles liés à un service :** oui
Un rôle lié à un service est un type de rôle de service lié à un. Service AWS Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés à un service apparaissent dans votre Compte AWS répertoire et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service.
Pour plus d'informations sur la création ou la gestion des rôles liés aux services Shield, consultez. [Utilisation de rôles liés à un service pour Shield Advanced](shd-using-service-linked-roles.md)
# Exemples de politiques basées sur l'identité pour AWS Shield
Par défaut, les utilisateurs et les rôles ne sont pas autorisés à créer ou à modifier les ressources du Shield. Pour octroyer aux utilisateurs des autorisations d’effectuer des actions sur les ressources dont ils ont besoin, un administrateur IAM peut créer des politiques IAM.
Pour apprendre à créer une politique basée sur l’identité IAM à l’aide de ces exemples de documents de politique JSON, consultez [Création de politiques IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) dans le *Guide de l’utilisateur IAM*.
Pour plus de détails sur les actions et les types de ressources définis par Shield, y compris le format de ARNs pour chacun des types de ressources, voir [Actions, ressources et clés de condition AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html) dans le *Service Authorization Reference*.
**Topics**
+ [Bonnes pratiques en matière de politiques](#shd-security_iam_service-with-iam-policy-best-practices)
+ [Utilisation de la console Shield](#shd-security_iam_id-based-policy-examples-console)
+ [Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations](#shd-security_iam_id-based-policy-examples-view-own-permissions)
+ [Accordez un accès en lecture à vos protections Shield Advanced](#shd-example0)
+ [Accordez un accès en lecture seule à Shield, et CloudFront CloudWatch](#shd-example1)
+ [Accordez un accès complet à Shield CloudFront, et CloudWatch](#shd-example2)
## Bonnes pratiques en matière de politiques
Les politiques basées sur l'identité déterminent si quelqu'un peut créer, accéder ou supprimer les ressources du Shield dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :
+ **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
+ **Accordez les autorisations de moindre privilège** : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées *autorisations de moindre privilège*. Pour plus d’informations sur l’utilisation d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez des conditions dans les politiques IAM pour restreindre davantage l’accès** : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*.
+ **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dans le *Guide de l’utilisateur IAM*.
Pour plus d’informations sur les bonnes pratiques dans IAM, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*.
## Utilisation de la console Shield
Pour accéder à la AWS Shield console, vous devez disposer d'un ensemble minimal d'autorisations. Ces autorisations doivent vous permettre de répertorier et de consulter les informations relatives aux ressources du Shield présentes dans votre Compte AWS. Si vous créez une politique basée sur l’identité qui est plus restrictive que l’ensemble minimum d’autorisations requis, la console ne fonctionnera pas comme prévu pour les entités (utilisateurs ou rôles) tributaires de cette politique.
Il n'est pas nécessaire d'accorder des autorisations de console minimales aux utilisateurs qui appellent uniquement l'API AWS CLI ou l' AWS API. Autorisez plutôt l’accès à uniquement aux actions qui correspondent à l’opération d’API qu’ils tentent d’effectuer.
Les utilisateurs autorisés à accéder à la AWS console et à l'utiliser peuvent également accéder à AWS Shield celle-ci. Aucune autorisation supplémentaire n'est requise.
### Uniquement sur console APIs
Vous pouvez accéder aux informations suivantes sur les attaques par déni de service (DDoS) distribué dans la console. Spécifiez les autorisations d'API suivantes dans une politique IAM pour autoriser ou refuser des actions spécifiques.
| Action | Description |
| --- | --- |
| DescribeAttackContributors | Permet d'obtenir des informations détaillées sur les contributeurs à une attaque DDo S spécifique. |
| ListMitigations | Accorde l'autorisation de récupérer une liste des mesures d'atténuation qui ont été appliquées lors d'attaques DDo S. |
| GetGlobalThreatData | Permet de récupérer les données et les tendances du renseignement mondial sur les menaces à partir des systèmes de surveillance des menaces de AWS Shield. |
Cet exemple montre comment créer une politique vous permettant de consulter les informations relatives à l'attaque DDo S dans la 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": "*"
}
]
}
```
------
## Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations
Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d’afficher les politiques en ligne et gérées attachées à leur identité d’utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide de l'API AWS CLI or 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": "*"
}
]
}
```
## Accordez un accès en lecture à vos protections Shield Advanced
AWS Shield autorise l'accès aux ressources entre comptes, mais ne vous permet pas de créer des protections des ressources entre comptes. Vous pouvez uniquement créer des protections pour les ressources à partir du compte propriétaire de ces ressources.
Voici un exemple de stratégie qui accorde les autorisations requises pour l'action `shield:ListProtections` au niveau de toutes les ressources. Shield ne prend pas en charge l'identification de ressources spécifiques à l'aide de la ressource ARNs (également appelées autorisations au niveau des ressources) pour certaines actions d'API. Vous devez donc spécifier un caractère générique (\$1). Cela permet uniquement d'accéder aux ressources que vous pouvez récupérer par le biais de l'action`ListProtections`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ListProtections",
"Effect": "Allow",
"Action": [
"shield:ListProtections"
],
"Resource": "*"
}
]
}
```
------
## Accordez un accès en lecture seule à Shield, et CloudFront CloudWatch
La politique suivante accorde aux utilisateurs un accès en lecture seule à Shield et aux ressources associées, y compris les CloudFront ressources Amazon et les métriques Amazon CloudWatch . Il est utile pour les utilisateurs qui ont besoin d'une autorisation pour consulter les paramètres des protections et des attaques du Shield et pour surveiller les indicateurs dans CloudWatch. Ces utilisateurs ne peuvent pas créer, mettre à jour ou supprimer les ressources du 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": "*"
}
]
}
```
------
## Accordez un accès complet à Shield CloudFront, et CloudWatch
La politique suivante permet aux utilisateurs d'effectuer n'importe quelle opération du Shield, d'effectuer n'importe quelle opération sur les distributions CloudFront Web et de surveiller les métriques et un échantillon de requêtes introduites CloudWatch. C'est utile pour les utilisateurs qui sont administrateurs du 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": "*"
}
]
}
```
------
Nous vous recommandons vivement de configurer Multi-Factor Authentication (MFA) pour les utilisateurs qui ont des autorisations d'administration. *Pour plus d'informations, consultez la section [Using Multi-Factor Authentication (MFA) Devices AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_ManagingMFA.html) with dans le guide de l'utilisateur IAM.*
# AWS politiques gérées pour AWS Shield
Une politique AWS gérée est une politique autonome créée et administrée par AWS. AWS les politiques gérées sont conçues pour fournir des autorisations pour de nombreux cas d'utilisation courants afin que vous puissiez commencer à attribuer des autorisations aux utilisateurs, aux groupes et aux rôles.
N'oubliez pas que les politiques AWS gérées peuvent ne pas accorder d'autorisations de moindre privilège pour vos cas d'utilisation spécifiques, car elles sont accessibles à tous les AWS clients. Nous vous recommandons de réduire encore les autorisations en définissant des [politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) qui sont propres à vos cas d’utilisation.
Vous ne pouvez pas modifier les autorisations définies dans les politiques AWS gérées. Si les autorisations définies dans une politique AWS gérée sont AWS mises à jour, la mise à jour affecte toutes les identités principales (utilisateurs, groupes et rôles) auxquelles la politique est attachée. AWS est le plus susceptible de mettre à jour une politique AWS gérée lorsqu'une nouvelle Service AWS est lancée ou lorsque de nouvelles opérations d'API sont disponibles pour les services existants.
Pour plus d’informations, consultez [Politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dans le *Guide de l’utilisateur IAM*.
## AWS stratégie gérée : AWSShield DRTAccess Politique
Cette section explique comment utiliser les politiques AWS gérées pour Shield.
AWS Shield utilise cette politique gérée lorsque vous autorisez la Shield Response Team (SRT) à agir en votre nom. Cette politique donne à la SRT un accès limité à votre AWS compte, afin de contribuer à atténuer les attaques DDo S lors d'événements très graves. Cette politique permet à la SRT de gérer vos AWS WAF règles et les protections de Shield Advanced et d'accéder à vos AWS WAF journaux.
Pour plus d'informations sur l'autorisation à la SRT d'opérer en votre nom, consultez[Octroi de l'accès au SRT](ddos-srt-access.md).
[Pour plus de détails sur cette politique, consultez AWSShield DRTAccess la section Stratégie dans la console IAM.](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSShieldDRTAccessPolicy)
## AWS politique gérée : AWSShield ServiceRolePolicy
Shield Advanced utilise cette politique gérée lorsque vous activez l'atténuation automatique de la couche DDo S de l'application, afin de définir les autorisations nécessaires pour gérer les ressources de votre compte. Cette politique permet à Shield Advanced de créer et d'appliquer des AWS WAF règles et des groupes de règles sur le Web ACLs que vous avez associés à vos ressources protégées, afin de répondre automatiquement aux attaques DDo S.
Vous ne pouvez pas vous associer AWSShield ServiceRolePolicy à vos entités IAM. Shield associe cette politique au rôle lié au service afin de permettre `AWSServiceRoleForAWSShield` à Shield d'effectuer des actions en votre nom.
Shield Advanced permet d'utiliser cette politique lorsque vous activez l'atténuation automatique de la couche DDo S de l'application. Pour plus d'informations sur l'utilisation de cette politique, consultez[Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md).
Pour plus d'informations sur le rôle lié à un service AWSService RoleFor AWSShield qui utilise cette politique, voir [Utilisation de rôles liés à un service pour Shield Advanced](shd-using-service-linked-roles.md)
Pour plus de détails sur cette politique, consultez [AWSShieldServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/AWSShieldServiceRolePolicy)la console IAM.
## Shield : mises à jour des politiques AWS gérées
Consultez les informations relatives aux mises à jour apportées aux politiques AWS gérées pour Shield depuis que ce service a commencé à suivre ces modifications. Pour recevoir des alertes automatiques concernant les modifications apportées à cette page, abonnez-vous au flux RSS sur la page d'historique des documents du Shield à l'adresse[Historique du document](doc-history.md).
| Politique | Description du changement | Date |
| --- | --- | --- |
| `AWSShieldServiceRolePolicy` Cette politique permet à Shield d'accéder aux AWS ressources et de les gérer afin de répondre automatiquement aux attaques de couche DDo S de l'application en votre nom. Détails de la console IAM : [AWSShieldServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/AWSShieldServiceRolePolicy) Le rôle lié au service `AWSServiceRoleForAWSShield` utilise cette politique. Pour plus d'informations, consultez [Utilisation de rôles liés à un service pour Shield Advanced](shd-using-service-linked-roles.md). | Cette politique a été ajoutée pour fournir à Shield Advanced les autorisations requises pour la fonctionnalité d'atténuation automatique de la couche DDo S de l'application. Pour plus d'informations sur cette fonctionnalité, consultez[Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md). | 1er décembre 2021 |
| Shield a commencé à suivre les modifications | Shield a commencé à suivre les modifications apportées AWS à ses politiques gérées. | 3 mars 2021 |
# Résolution des problèmes AWS Shield d'identité et d'accès
Utilisez les informations suivantes pour vous aider à diagnostiquer et à résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec Shield et IAM.
**Topics**
+ [Je ne suis pas autorisé à effectuer une action dans Shield](#shd-security_iam_troubleshoot-no-permissions)
+ [Je ne suis pas autorisé à effectuer iam : PassRole](#shd-security_iam_troubleshoot-passrole)
+ [Je souhaite autoriser des personnes extérieures à moi Compte AWS à accéder à mes ressources Shield](#shd-security_iam_troubleshoot-cross-account-access)
## Je ne suis pas autorisé à effectuer une action dans Shield
Si vous recevez une erreur qui indique que vous n’êtes pas autorisé à effectuer une action, vos politiques doivent être mises à jour afin de vous permettre d’effectuer l’action.
L’exemple d’erreur suivant se produit quand l’utilisateur IAM `mateojackson` tente d’utiliser la console pour afficher des informations détaillées sur une ressource `my-example-widget` fictive, mais ne dispose pas des autorisations `shield:GetWidget` fictives.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: shield:GetWidget on resource: my-example-widget
```
Dans ce cas, la politique qui s’applique à l’utilisateur `mateojackson` doit être mise à jour pour autoriser l’accès à la ressource `my-example-widget` à l’aide de l’action `shield:GetWidget`.
Si vous avez besoin d'aide, contactez votre AWS administrateur. Votre administrateur vous a fourni vos informations d’identification de connexion.
## Je ne suis pas autorisé à effectuer iam : PassRole
Si vous recevez un message d'erreur indiquant que vous n'êtes pas autorisé à effectuer l'`iam:PassRole`action, vos politiques doivent être mises à jour pour vous permettre de transmettre un rôle à Shield.
Certains vous Services AWS permettent de transmettre un rôle existant à ce service au lieu de créer un nouveau rôle de service ou un rôle lié à un service. Pour ce faire, vous devez disposer des autorisations nécessaires pour transmettre le rôle au service.
L'exemple d'erreur suivant se produit lorsqu'un utilisateur IAM nommé `marymajor` essaie d'utiliser la console pour effectuer une action dans Shield. Toutefois, l’action nécessite que le service ait des autorisations accordées par un rôle de service. Mary n'est pas autorisée à transmettre le rôle au service.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
Dans ce cas, les politiques de Mary doivent être mises à jour pour lui permettre d’exécuter l’action `iam:PassRole`.
Si vous avez besoin d'aide, contactez votre AWS administrateur. Votre administrateur vous a fourni vos informations d’identification de connexion.
## Je souhaite autoriser des personnes extérieures à moi Compte AWS à accéder à mes ressources Shield
Vous pouvez créer un rôle que les utilisateurs provenant d’autres comptes ou les personnes extérieures à votre organisation pourront utiliser pour accéder à vos ressources. Vous pouvez spécifier qui est autorisé à assumer le rôle. Pour les services qui prennent en charge les politiques basées sur les ressources ou les listes de contrôle d'accès (ACLs), vous pouvez utiliser ces politiques pour autoriser les utilisateurs à accéder à vos ressources.
Pour plus d’informations, consultez les éléments suivants :
+ Pour savoir si Shield prend en charge ces fonctionnalités, consultez[Comment AWS Shield fonctionne avec IAM](shd-security_iam_service-with-iam.md).
+ Pour savoir comment fournir l'accès à vos ressources sur celles Comptes AWS que vous possédez, consultez la section [Fournir l'accès à un utilisateur IAM dans un autre utilisateur Compte AWS que vous possédez](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) dans le Guide de l'*utilisateur IAM*.
+ Pour savoir comment fournir l'accès à vos ressources à des tiers Comptes AWS, consultez la section [Fournir un accès à des ressources Comptes AWS détenues par des tiers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) dans le *guide de l'utilisateur IAM*.
+ Pour savoir comment fournir un accès par le biais de la fédération d’identité, consultez [Fournir un accès à des utilisateurs authentifiés en externe (fédération d’identité)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) dans le *Guide de l’utilisateur IAM*.
+ Pour découvrir quelle est la différence entre l’utilisation des rôles et l’utilisation des politiques basées sur les ressources pour l’accès entre comptes, consultez [Différence entre les rôles IAM et les politiques basées sur les ressources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) dans le *Guide de l’utilisateur IAM*.
# Utilisation de rôles liés à un service pour Shield Advanced
Cette section explique comment utiliser les rôles liés à un service pour donner à Shield Advanced l'accès aux ressources de votre AWS compte.
AWS Shield Advanced utilise des Gestion des identités et des accès AWS rôles liés à un [service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Un rôle lié à un service est un type unique de rôle IAM directement lié à Shield Advanced. Les rôles liés au service sont prédéfinis par Shield Advanced et incluent toutes les autorisations dont le service a besoin pour appeler d'autres AWS services en votre nom.
Un rôle lié à un service facilite la configuration de Shield Advanced, car vous n'avez pas à ajouter manuellement les autorisations nécessaires. Shield Advanced définit les autorisations associées à ses rôles liés aux services et, sauf indication contraire, seul Shield Advanced peut assumer ses rôles. Les autorisations définies comprennent la politique de confiance et la politique d’autorisation. De plus, cette politique d’autorisation ne peut pas être attachée à une autre entité IAM.
Vous pouvez supprimer un rôle lié à un service uniquement après la suppression préalable de ses ressources connexes. Cela protège vos ressources Shield Advanced, car vous ne pouvez pas supprimer par inadvertance l'autorisation d'accès aux ressources.
Pour plus d’informations sur les autres services qui prennent en charge les rôles liés à un service, consultez [Services AWS qui fonctionnent avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) et recherchez les services avec un **Oui ** dans la colonne **Rôle lié à un service**. Choisissez un **Oui** ayant un lien permettant de consulter les détails du rôle pour ce service.
## Autorisations de rôle liées à un service pour Shield Advanced
Shield Advanced utilise le rôle lié au service nommé. **AWSServiceRoleForAWSShield** Ce rôle permet à Shield Advanced d'accéder aux AWS ressources et de les gérer afin de répondre automatiquement aux attaques de couche DDo S de l'application en votre nom. Pour plus d'informations sur cette fonctionnalité, consultez[Automatiser l'atténuation de la couche DDo S de l'application avec Shield Advanced](ddos-automatic-app-layer-response.md).
Le rôle AWSService RoleFor AWSShield lié à un service fait confiance aux services suivants pour assumer le rôle :
+ `shield.amazonaws.com`
La politique d'autorisation des rôles nommée AWSShield ServiceRolePolicy permet à Shield Advanced d'effectuer les actions suivantes sur toutes les AWS ressources :
+ `wafv2:GetWebACL`
+ `wafv2:UpdateWebACL`
+ `wafv2:GetWebACLForResource`
+ `wafv2:ListResourcesForWebACL`
+ `cloudfront:ListDistributions`
+ `cloudfront:GetDistribution`
Lorsque des actions sont autorisées sur toutes les AWS ressources, cela est indiqué dans la politique sous la forme`"Resource": "*"`. Cela signifie uniquement que le rôle lié au service peut effectuer chaque action indiquée sur toutes les AWS ressources prises en charge par *l'action*. Par exemple, l'action n'`wafv2:GetWebACL`est prise en charge que pour les ressources ACL `wafv2` Web.
Shield Advanced effectue des appels d'API au niveau des ressources uniquement pour les ressources protégées pour lesquelles vous avez activé la fonctionnalité de protection de la couche d'application et pour le Web ACLs associé à ces ressources protégées.
Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service. Pour en savoir plus, consultez [Service-Linked Role Permissions (autorisations du rôle lié à un service)](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l’utilisateur IAM*.
## Création d'un rôle lié à un service pour Shield Advanced
Vous n’avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous activez l'atténuation automatique de la couche DDo S de l'application pour une ressource de l'API AWS Management Console, de l' AWS CLI API ou de l' AWS API, Shield Advanced crée le rôle lié au service pour vous.
Si vous supprimez ce rôle lié à un service et que vous avez ensuite besoin de le recréer, vous pouvez utiliser la même procédure pour recréer le rôle dans votre compte. Lorsque vous activez l'atténuation automatique de la couche DDo S de l'application pour une ressource, Shield Advanced crée à nouveau le rôle lié au service pour vous.
## Modification d'un rôle lié à un service pour Shield Advanced
Shield Advanced ne vous permet pas de modifier le rôle AWSService RoleFor AWSShield lié au service. Après avoir créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent faire référence à ce rôle. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM. Pour en savoir plus, consultez [Modification d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le *Guide de l’utilisateur IAM*.
## Supprimer un rôle lié à un service pour Shield Advanced
Si vous n’avez plus besoin d’utiliser une fonctionnalité ou un service qui nécessite un rôle lié à un service, nous vous recommandons de supprimer ce rôle. De cette façon, vous n’avez aucune entité inutilisée qui n’est pas surveillée ou gérée activement. Cependant, vous devez nettoyer les ressources de votre rôle lié à un service avant de pouvoir les supprimer manuellement.
**Note**
Si Shield Advanced utilise le rôle lorsque vous essayez de supprimer les ressources, la suppression risque d'échouer. Si cela se produit, patientez quelques minutes et réessayez.
**Pour supprimer les ressources Shield Advanced utilisées par le AWSService RoleFor AWSShield**
Pour toutes vos ressources pour lesquelles des protections de couche d'application DDo S sont configurées, désactivez l'atténuation automatique de la couche d'application DDo S. Pour des instructions sur l’utilisation de la console, consultez [Configurer les protections de la couche DDo S de l'application](manage-protection.md#configure-app-layer-protection).
**Pour supprimer manuellement le rôle lié au service à l’aide d’IAM**
Utilisez la console IAM AWS CLI, le ou l' AWS API pour supprimer le rôle lié au AWSService RoleFor AWSShield service. Pour en savoir plus, consultez [Suppression d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dans le *Guide de l’utilisateur IAM*.
## Régions prises en charge pour les rôles liés aux services Shield Advanced
Shield Advanced prend en charge l'utilisation de rôles liés au service dans toutes les régions où le service est disponible. Pour plus d'informations, consultez la section [Points de terminaison et quotas Shield Advanced](https://docs.aws.amazon.com/general/latest/gr/shield.html).
# Journalisation et surveillance dans Shield
Cette section explique comment utiliser les AWS outils de surveillance et de réponse aux événements dans AWS Shield.
La surveillance joue un rôle important dans le maintien de la fiabilité, de la disponibilité et des performances de Shield et de vos AWS solutions. Vous devez collecter des données de surveillance provenant de toutes les parties de votre AWS solution afin de pouvoir corriger plus facilement une défaillance multipoint, le cas échéant. AWS fournit plusieurs outils pour surveiller les ressources de votre Shield et répondre à des événements potentiels :
** CloudWatch Alarmes Amazon**
À l'aide d' CloudWatch alarmes, vous observez une seule métrique sur une période que vous spécifiez. Si la métrique dépasse un seuil donné, CloudWatch envoie une notification à une rubrique ou AWS Auto Scaling à une politique Amazon SNS. Pour de plus amples informations, veuillez consulter [Surveillance avec Amazon CloudWatch](monitoring-cloudwatch.md).
**AWS CloudTrail Journaux**
CloudTrail fournit un enregistrement des actions entreprises par un utilisateur, un rôle ou un AWS service dans Shield. À l'aide des informations collectées par CloudTrail, vous pouvez déterminer la demande qui a été faite à Shield, l'adresse IP à partir de laquelle la demande a été faite, l'auteur de la demande, la date à laquelle elle a été faite et des informations supplémentaires. Pour de plus amples informations, veuillez consulter [Journalisation des appels d'API AWS CloudTrail avec](logging-using-cloudtrail.md).
# Validation de la conformité dans Shield
Cette section explique votre responsabilité en matière de conformité lors de l'utilisation AWS Shield.
Pour savoir si un [programme Services AWS de conformité Service AWS s'inscrit dans le champ d'application de programmes de conformité](https://aws.amazon.com/compliance/services-in-scope/) spécifiques, consultez Services AWS la section de conformité et sélectionnez le programme de conformité qui vous intéresse. Pour des informations générales, voir Programmes de [AWS conformité Programmes AWS](https://aws.amazon.com/compliance/programs/) de .
Vous pouvez télécharger des rapports d'audit tiers à l'aide de AWS Artifact. Pour plus d'informations, voir [Téléchargement de rapports dans AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
Votre responsabilité en matière de conformité lors de l'utilisation Services AWS est déterminée par la sensibilité de vos données, les objectifs de conformité de votre entreprise et les lois et réglementations applicables. Pour plus d'informations sur votre responsabilité en matière de conformité lors de l'utilisation Services AWS, consultez [AWS la documentation de sécurité](https://docs.aws.amazon.com/security/).
# Construire pour la résilience dans Shield
Cette section explique comment AWS l'architecture prend en charge la redondance des données pour. AWS Shield
L'infrastructure AWS mondiale est construite autour Régions AWS de zones de disponibilité. Régions AWS fournissent plusieurs zones de disponibilité physiquement séparées et isolées, connectées par un réseau à faible latence, à haut débit et hautement redondant. Avec les zones de disponibilité, vous pouvez concevoir et exploiter des applications et des bases de données qui basculent automatiquement d’une zone de disponibilité à l’autre sans interruption. Les zones de disponibilité sont plus hautement disponibles, tolérantes aux pannes et évolutives que les infrastructures traditionnelles à un ou plusieurs centres de données.
Pour plus d'informations sur les zones de disponibilité Régions AWS et les zones de disponibilité, consultez la section [Infrastructure AWS globale](https://aws.amazon.com/about-aws/global-infrastructure/).
# Sécurité de l'infrastructure dans AWS Shield
Cette section explique comment AWS Shield isoler le trafic des services.
En tant que service géré, AWS Shield il est protégé par la sécurité du réseau AWS mondial. Pour plus d'informations sur les services AWS de sécurité et sur la manière dont AWS l'infrastructure est protégée, consultez la section [Sécurité du AWS cloud](https://aws.amazon.com/security/). Pour concevoir votre AWS environnement en utilisant les meilleures pratiques en matière de sécurité de l'infrastructure, consultez la section [Protection de l'infrastructure](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) dans le cadre * AWS bien architecturé du pilier de sécurité*.
Vous utilisez des appels d'API AWS publiés pour accéder à Shield via le réseau. Les clients doivent prendre en charge les éléments suivants :
+ Protocole TLS (Transport Layer Security). Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Ses suites de chiffrement PFS (Perfect Forward Secrecy) comme DHE (Ephemeral Diffie-Hellman) ou ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La plupart des systèmes modernes tels que Java 7 et les versions ultérieures prennent en charge ces modes.
# AWS Shield Advanced quotas
AWS Shield Advanced dispose de quotas par défaut sur le nombre d'entités par région. Vous pouvez [demander une augmentation](https://console.aws.amazon.com/servicequotas/home/services/shield/quotas) de ces quotas.
| Ressource | Quota par défaut |
| --- | --- |
| Nombre maximum de ressources protégées pour chaque type de ressource AWS Shield Advanced offrant une protection, par compte. | 1 000 |
| Nombre maximum de groupes de protection par compte. | 100 |
| Nombre maximal de ressources protégées individuelles que vous pouvez inclure spécifiquement dans un groupe de protection. Dans l'API, cela s'applique à celui `Members` que vous spécifiez lorsque vous définissez le groupe `Pattern` de protection sur`ARBITRARY`. Dans la console, cela s'applique aux ressources que vous sélectionnez pour le groupe de protection **Choisissez parmi les ressources protégées**. | 1 000 |