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.
# Réduction de la surface d'attaque
Lors de l'architecture d'une AWS solution, il est également important de limiter les chances qu'un attaquant cible votre application. Ce concept est connu sous le nom de *réduction de la surface* d'attaque. Les ressources qui ne sont pas exposées à Internet sont plus difficiles à attaquer, ce qui limite les options dont dispose un attaquant pour cibler la disponibilité de votre application.
Par exemple, si vous ne vous attendez pas à ce que les utilisateurs interagissent directement avec certaines ressources, assurez-vous que ces ressources ne sont pas accessibles depuis Internet. De même, n'acceptez pas le trafic provenant d'utilisateurs ou d'applications externes sur des ports ou des protocoles qui ne sont pas nécessaires à la communication.
Dans la section suivante, vous AWS trouverez les meilleures pratiques pour vous aider à réduire votre surface d'attaque et à limiter l'exposition de votre application à Internet.
# Masquer les AWS ressources (,,) BP1 BP4 BP5
En règle générale, les utilisateurs peuvent utiliser rapidement et facilement une application sans avoir besoin que les AWS ressources soient entièrement exposées à Internet.
# Groupes de sécurité et réseau ACLs (BP5)
Amazon Virtual Private Cloud (AmazonVPC) vous permet de fournir une section isolée de manière logique AWS Cloud où vous pouvez lancer AWS des ressources dans un réseau virtuel que vous définissez.
Les groupes de sécurité et le réseau ACLs sont similaires en ce sens qu'ils vous permettent de contrôler l'accès aux AWS ressources de votreVPC. Mais les groupes de sécurité vous permettent de contrôler le trafic entrant et sortant au niveau de l'instance, tandis que le réseau ACLs offre des fonctionnalités similaires au niveau du VPC sous-réseau. L'utilisation des groupes de sécurité ou du réseau est gratuiteACLs.
Vous pouvez choisir de spécifier des groupes de sécurité lorsque vous lancez une instance ou d'associer l'instance à un groupe de sécurité ultérieurement. *Tout le trafic Internet vers un groupe de sécurité est implicitement refusé, sauf si vous créez une règle d'autorisation pour autoriser le trafic.*
Par exemple, lorsque des EC2 instances Amazon sont associées à un Elastic Load Balancer, il n'est pas nécessaire que les instances elles-mêmes soient accessibles au public et doivent être uniquement privéesIPs. Vous pouvez plutôt fournir à Elastic Load Balancer l'accès aux ports d'écoute cibles requis en utilisant une règle de groupe de sécurité qui autorise l'accès à 0.0.0.0/0 (pour éviter les problèmes de suivi des connexions, voir note ci-dessous) en conjonction avec une liste de contrôle d'accès réseau (NACL) sur le sous-réseau du groupe cible afin d'autoriser uniquement les plages d'adresses IP d'Elastic Load Balancing à communiquer avec les instances. Cela garantit que le trafic Internet ne peut pas communiquer directement avec vos EC2 instances Amazon, ce qui rend plus difficile pour un attaquant de découvrir et d'influencer votre application.
Lorsque vous créez un réseauACLs, vous pouvez définir des règles d'autorisation et de refus. Cela est utile si vous souhaitez refuser explicitement certains types de trafic vers votre application. Par exemple, vous pouvez définir des adresses IP (sous forme de CIDR plages), des protocoles et des ports de destination auxquels l'accès à l'ensemble du sous-réseau est refusé. Si votre application est utilisée uniquement pour TCP le trafic, vous pouvez créer une règle pour refuser tout UDP trafic, ou vice versa. Cette option est utile lorsque vous répondez à DDoS des attaques, car elle vous permet de créer vos propres règles pour atténuer l'attaque lorsque vous connaissez la source IPs ou une autre signature.
Si vous êtes abonné AWS Shield Advanced, vous pouvez enregistrer les adresses IP Elastic en tant que ressources protégées. DDoSles attaques contre les adresses IP Elastic enregistrées en tant que ressources protégées sont détectées plus rapidement, ce qui permet de réduire les délais d'atténuation. Lorsqu'une attaque est détectée, les systèmes DDoS d'atténuation lisent le réseau ACL correspondant à l'adresse IP élastique ciblée et l'appliquent à la frontière du AWS réseau plutôt qu'au niveau du sous-réseau. Cela réduit considérablement le risque d'impact d'un certain nombre d'DDoSattaques au niveau de l'infrastructure.
Pour plus d'informations sur la configuration des groupes de sécurité et du réseau ACLs afin d'optimiser DDoS la résilience, consultez [Comment vous préparer aux DDoS attaques en réduisant votre surface d'attaque](https://aws.amazon.com/blogs/security/how-to-help-prepare-for-ddos-attacks-by-reducing-your-attack-surface/).
Pour plus d'informations sur l'utilisation de Shield Advanced avec des adresses IP élastiques en tant que ressources protégées, reportez-vous aux étapes de [souscription AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/enable-ddos-prem.html).
# Protéger votre origine (BP1,BP5)
Si vous utilisez Amazon CloudFront avec une origine qui se trouve dans le vôtreVPC, vous voudrez peut-être vous assurer que seule votre CloudFront distribution peut transmettre les demandes à votre origine. Avec les en-têtes de demande Edge-to-Origin, vous pouvez ajouter ou remplacer la valeur des en-têtes de demande existants lorsque CloudFront vous transférez des demandes à votre origine. Vous pouvez utiliser les *en-têtes personnalisés d'Origin*, par exemple l'`X-Shared-Secret`en-tête, pour vérifier que les demandes adressées à votre origine ont été envoyées depuis CloudFront.
Pour plus d'informations sur la protection de votre origine avec des *en-têtes personnalisés Origin, reportez-vous aux* sections [Ajouter](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html) des [en-têtes personnalisés aux demandes d'origine](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html) et [Restreindre l'accès aux équilibreurs de charge d'application](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html).
Pour un guide sur la mise en œuvre d'un exemple de solution permettant de faire automatiquement pivoter la valeur des *en-têtes personnalisés d'Origin* pour la restriction d'accès à l'origine, reportez-vous à la section [Comment améliorer la sécurité des CloudFront origines d'Amazon avec AWS WAF et Secrets Manager](https://aws.amazon.com/blogs/security/how-to-enhance-amazon-cloudfront-origin-security-with-aws-waf-and-aws-secrets-manager/).
Vous pouvez également utiliser une [AWS Lambda](https://aws.amazon.com/lambda/)fonction pour mettre à jour automatiquement les règles de votre groupe de sécurité afin d'autoriser uniquement CloudFront le trafic. Cela améliore la sécurité de votre origine en empêchant les utilisateurs malveillants de contourner CloudFront et AWS WAF d'accéder à votre application Web.
Pour plus d'informations sur la manière de protéger votre origine en mettant automatiquement à jour vos groupes de sécurité et l'`X-Shared-Secret`en-tête, consultez [Comment mettre à jour automatiquement vos groupes de sécurité pour Amazon CloudFront et en AWS WAF utilisant AWS Lambda](https://aws.amazon.com/blogs/security/how-to-automatically-update-your-security-groups-for-amazon-cloudfront-and-aws-waf-by-using-aws-lambda/).
Cependant, la solution implique une configuration supplémentaire et le coût d'exécution des fonctions Lambda. Pour simplifier les choses, nous avons introduit une [liste de AWS préfixes gérée](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list) afin de limiter le HTTPS trafic entrant CloudFront HTTP vers vos origines à partir des seules adresses IP orientées vers l' CloudFrontorigine. AWS-les listes de préfixes gérées sont créées et maintenues par AWS et peuvent être utilisées sans frais supplémentaires. Vous pouvez faire référence à la liste des préfixes gérés CloudFront dans les règles de votre groupe de sécurité (AmazonVPC), dans les tables de routage des sous-réseaux, dans les règles communes des AWS Firewall Manager groupes de sécurité et dans toute autre AWS ressource pouvant utiliser une liste de [préfixes gérés](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html).
Pour plus d'informations sur l'utilisation de la liste de préfixes AWS gérée par -pour Amazon CloudFront, consultez [Limiter l'accès à vos origines à l'aide de la liste de AWS préfixes -gérée](https://aws.amazon.com/blogs/networking-and-content-delivery/limit-access-to-your-origins-using-the-aws-managed-prefix-list-for-amazon-cloudfront/) pour Amazon. CloudFront
**Note**
Comme indiqué dans d'autres sections de ce document, le fait de s'appuyer sur des groupes de sécurité pour protéger votre origine peut ajouter au [suivi des connexions des groupes de sécurité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) un obstacle potentiel lors d'un afflux de demandes. À moins que vous ne soyez en mesure de filtrer les demandes malveillantes à CloudFront l'aide d'une politique de mise en cache qui active la mise en cache, il peut être préférable de vous fier aux *en-têtes personnalisés d'origine*, évoqués précédemment, pour vérifier que les demandes adressées à votre origine ont été envoyées depuis CloudFront, plutôt que d'utiliser des groupes de sécurité. L'utilisation d'un en-tête de demande personnalisé avec une règle d'écoute Application Load Balancer permet d'éviter les ralentissements dus aux limites de suivi susceptibles d'affecter l'établissement de nouvelles connexions à un équilibreur de charge, ce qui permet à Application Load Balancer de s'adapter en fonction de l'augmentation du trafic en cas d'attaque. DDoS
# Protection des API terminaux () BP4
Lorsque vous devez exposer un API fichier au public, il existe un risque que le API frontend soit la cible d'une DDoS attaque. Pour réduire les risques, vous pouvez utiliser [Amazon API Gateway comme point](https://aws.amazon.com/api-gateway/) d'accès aux applications exécutées sur Amazon EC2 ou AWS Lambda ailleurs. En utilisant Amazon API Gateway, vous n'avez pas besoin de vos propres serveurs pour le API frontend et vous pouvez masquer d'autres composants de votre application. En rendant plus difficile la détection des composants de votre application, vous pouvez empêcher que ces AWS ressources ne soient ciblées par une DDoS attaque.
Lorsque vous utilisez Amazon API Gateway, vous pouvez choisir entre deux types de API points de terminaison. La première est l'option par défaut : des API points de terminaison optimisés pour les périphériques accessibles via une distribution Amazon. CloudFront Cependant, la distribution est créée et gérée par API Gateway, vous n'en avez donc aucun contrôle. La deuxième option consiste à utiliser un point de API terminaison régional accessible depuis le même point de terminaison que celui Région AWS dans lequel le vôtre REST API est déployé. AWS vous recommande d'utiliser le second type de point de terminaison et de l'associer à votre propre CloudFront distribution Amazon. Cela vous permet de contrôler la CloudFront distribution Amazon et de pouvoir l'utiliser AWS WAF pour la protection de la couche application. Ce mode vous donne accès à une capacité DDoS d'atténuation étendue sur l'ensemble du réseau périphérique AWS mondial.
Lorsque vous utilisez Amazon CloudFront et AWS WAF Amazon API Gateway, configurez les options suivantes :
+ Configurez le comportement du cache pour vos distributions afin de transférer tous les en-têtes au point de terminaison régional API Gateway. Ce faisant, CloudFront vous traiterez le contenu comme dynamique et vous éviterez de le mettre en cache.
+ Protégez votre API passerelle contre l'accès direct en configurant la distribution pour inclure l'en-tête personnalisé d'origine x-api-key, en définissant la valeur [APIclé](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-setup-api-key-with-console.html) dans API Gateway.
+ Protégez le backend contre le trafic excessif en configurant des limites de fréquence standard ou de fréquence de rafale pour chaque méthode de votre RESTAPIs.
Pour plus d'informations sur la création APIs avec Amazon API Gateway, consultez [Amazon API Gateway](https://aws.amazon.com/api-gateway/getting-started/) [Getting Started](https://aws.amazon.com/api-gateway/getting-started/).