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.
# Inspection entrante centralisée
De par leur nature, les applications connectées à Internet ont une plus grande surface d'attaque et sont exposées à des catégories de menaces auxquelles la plupart des autres types d'applications n'ont pas à faire face. La protection nécessaire contre les attaques visant ce type d'applications et la minimisation de la surface d'impact sont au cœur de toute stratégie de sécurité.
Lorsque vous déployez des applications dans votre zone de destination, de nombreuses applications seront accessibles aux utilisateurs via l'Internet public (par exemple, via un réseau de diffusion de contenu (CDN) ou via une application Web destinée au public) via un équilibreur de charge public, une passerelle API ou directement via une passerelle Internet. Dans ce cas, vous pouvez sécuriser vos charges de travail et vos applications en utilisant AWS Web Application Firewall (AWS WAF) pour l'inspection des applications entrantes, ou IDS/IPS bien l'inspection entrante à l'aide de Gateway Load Balancer ou. AWS Network Firewall
Au fur et à mesure que vous déployez des applications dans votre zone d'atterrissage, vous devrez peut-être inspecter le trafic Internet entrant. Vous pouvez y parvenir de plusieurs manières, en utilisant des architectures d'inspection distribuées, centralisées ou combinées en utilisant Gateway Load Balancer exécutant vos dispositifs de pare-feu tiers ou AWS Network Firewall en utilisant des DPI et des IDS/IPS fonctionnalités avancées grâce à l'utilisation de règles Suricata open source. Cette section couvre à la fois Gateway Load Balancer et un déploiement centralisé, AWS Network Firewall en faisant AWS Transit Gateway office de hub central pour le routage du trafic.
## AWS WAF et AWS Firewall Manager pour inspecter le trafic entrant en provenance d'Internet
AWS WAF est un pare-feu pour applications Web qui aide à protéger vos applications Web APIs contre les exploits Web courants et les robots susceptibles d'affecter la disponibilité, de compromettre la sécurité ou de consommer des ressources excessives. AWS WAF vous permet de contrôler la manière dont le trafic atteint vos applications en vous permettant de créer des règles de sécurité qui contrôlent le trafic des robots et bloquent les modèles d'attaque courants, tels que l'injection SQL ou le cross-site scripting (XSS). Vous pouvez également personnaliser les règles qui filtrent des modèles de trafic spécifiques.
Vous pouvez déployer AWS WAF sur Amazon dans le CloudFront cadre de votre solution CDN, l'Application Load Balancer qui fait face à vos serveurs Web, Amazon API Gateway pour votre REST AWS AppSync ou pour votre APIs GraphQL. APIs
Une fois le déploiement AWS WAF effectué, vous pouvez créer vos propres règles de filtrage du trafic à l'aide du générateur de règles visuel, du code en JSON, des règles gérées gérées par AWS, ou vous pouvez vous abonner à des règles tierces à partir du AWS Marketplace. Ces règles peuvent filtrer le trafic indésirable en évaluant le trafic par rapport aux modèles spécifiés. Vous pouvez également utiliser Amazon CloudWatch pour surveiller les statistiques du trafic entrant et la journalisation.
Pour une gestion centralisée de tous vos comptes et applications AWS Organizations, vous pouvez utiliser AWS Firewall Manager. AWS Firewall Manager est un service de gestion de la sécurité qui vous permet de configurer et de gérer de manière centralisée les règles de pare-feu. Au fur et à mesure que vos nouvelles applications sont créées, AWS Firewall Manager vous pouvez facilement mettre en conformité les nouvelles applications et ressources en appliquant un ensemble commun de règles de sécurité.
À l'aide de AWS Firewall Manager, vous pouvez facilement déployer des AWS WAF règles pour vos équilibreurs de charge d'application, vos instances d'API Gateway et vos CloudFront distributions Amazon. AWS Firewall Manager s'intègre AWS Managed Rules à for AWS WAF, qui vous permet de déployer facilement des AWS WAF règles préconfigurées et sélectionnées sur vos applications. Pour plus d'informations sur la gestion centralisée AWS WAF avec AWS Firewall Manager, reportez-vous à [Gestion centralisée AWS WAF (API v2) et AWS Managed Rules à grande échelle avec AWS Firewall Manager](https://aws.amazon.com/blogs/security/centrally-manage-aws-waf-api-v2-and-aws-managed-rules-at-scale-with-firewall-manager/).
![\[Schéma illustrant l'inspection centralisée du trafic entrant à l'aide de AWS WAF\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/inbound-traffic-inspection-with-waf.png)
Dans l'architecture précédente, les applications s'exécutent sur des instances Amazon EC2 dans plusieurs zones de disponibilité des sous-réseaux privés. Un Application Load Balancer (ALB) destiné au public est déployé devant les instances Amazon EC2 pour équilibrer la charge des demandes entre les différentes cibles. Le AWS WAF est associé à l'ALB.
### Avantages
+ Avec [AWS WAF Bot Control](https://aws.amazon.com/waf/features/bot-control/), vous bénéficiez d'une visibilité et d'un contrôle sur le trafic de bots courant et omniprésent vers vos applications.
+ Avec [Managed Rules for AWS WAF](https://aws.amazon.com/marketplace/solutions/security/waf-managed-rules), vous pouvez démarrer rapidement et protéger votre application Web ou APIs contre les menaces courantes. Vous pouvez choisir parmi de nombreux types de règles, notamment celles qui traitent de problèmes tels que les 10 principaux risques de sécurité de l'Open Web Application Security Project (OWASP), les menaces spécifiques aux systèmes de gestion de contenu (CMS) tels que Joomla WordPress ou même les vulnérabilités et expositions communes émergentes (CVE). Les règles gérées sont automatiquement mises à jour à mesure que de nouveaux problèmes apparaissent, ce qui vous permet de consacrer plus de temps à la création d'applications.
+ AWS WAF est un service géré et aucune appliance n'est nécessaire pour l'inspection dans cette architecture. En outre, il fournit des journaux en temps quasi réel via [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/). AWS WAF donne une visibilité en temps quasi réel de votre trafic Web, que vous pouvez utiliser pour créer de nouvelles règles ou alertes sur Amazon. CloudWatch
### Considérations clés
+ Cette architecture convient parfaitement à l'inspection des en-têtes HTTP et aux inspections distribuées, car elle AWS WAF est intégrée à un ALB, à une CloudFront distribution et à une API Gateway. AWS WAF n'enregistre pas le corps de la demande.
+ Le trafic destiné à un deuxième ensemble d'ALB (le cas échéant) peut ne pas être inspecté par la même AWS WAF instance, car une nouvelle demande serait envoyée au deuxième ensemble d'ALB.
# Inspection entrante centralisée avec des appareils tiers
Dans ce modèle de conception architecturale, vous déployez des dispositifs de pare-feu tiers sur Amazon EC2 dans plusieurs zones de disponibilité derrière un Elastic Load Balancer (ELB) tel qu'un Load Application/Network Balancer dans un VPC d'inspection distinct.
Le VPC d'inspection et les autres Spoke VPCs sont connectés ensemble via un Transit Gateway sous forme de pièces jointes VPC. Les applications de Spoke VPCs sont dirigées par un ELB interne qui peut être ALB ou NLB selon le type d'application. Les clients se connectent via Internet au DNS de l'ELB externe dans le VPC d'inspection qui achemine le trafic vers l'un des dispositifs de pare-feu. Le pare-feu inspecte le trafic, puis achemine le trafic vers le VPC Spoke via Transit Gateway en utilisant le DNS de l'ELB interne, comme illustré dans la figure suivante. Pour plus d'informations sur l'inspection de sécurité entrante avec des appliances tierces, consultez le billet de blog [Comment intégrer des dispositifs de pare-feu tiers dans un environnement AWS](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-integrate-third-party-firewall-appliances-into-an-aws-environment/).
![\[Schéma illustrant l'inspection centralisée du trafic entrant à l'aide d'appareils tiers et d'ELB\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/ingress-inspection-third-party.png)
## Avantages
+ Cette architecture peut prendre en charge tous les types d'applications d'inspection et les fonctionnalités d'inspection avancées proposées par des dispositifs de pare-feu tiers.
+ Ce modèle prend en charge le routage basé sur le DNS entre les dispositifs de pare-feu et VPCs Spoke, ce qui permet aux applications de VPCs Spoke de s'adapter indépendamment derrière un ELB.
+ Vous pouvez utiliser Auto Scaling avec l'ELB pour dimensionner les dispositifs de pare-feu du VPC d'inspection.
## Considérations clés
+ Vous devez déployer plusieurs dispositifs de pare-feu dans les zones de disponibilité pour garantir une haute disponibilité.
+ Le pare-feu doit être configuré avec et exécuter le NAT source afin de maintenir la symétrie du flux, ce qui signifie que l'adresse IP du client ne sera pas visible pour l'application.
+ Envisagez de déployer Transit Gateway et Inspection VPC dans le compte Network Services.
+ licensing/support Coût supplémentaire du pare-feu fourni par un fournisseur tiers. Les frais Amazon EC2 dépendent du type d'instance.
# Inspection du trafic entrant en provenance d'Internet à l'aide de dispositifs de pare-feu dotés de Gateway Load Balancer
Les clients utilisent des pare-feux de nouvelle génération (NGFW) et des systèmes de prévention des intrusions (IPS) tiers dans le cadre de leur stratégie de défense approfondie. Traditionnellement, il s'agit souvent de matériel ou d' software/virtual appareils dédiés. Vous pouvez utiliser Gateway Load Balancer pour dimensionner ces dispositifs virtuels horizontalement afin d'inspecter le trafic en provenance et à destination de votre VPC, comme illustré dans la figure suivante.
![\[Schéma illustrant l'inspection centralisée du trafic entrant à l'aide de dispositifs de pare-feu dotés de Gateway Load Balancer\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/ingress-inspection-fa.png)
Dans l'architecture précédente, les points de terminaison Gateway Load Balancer sont déployés dans chaque zone de disponibilité dans un VPC périphérique distinct. Les pare-feux de nouvelle génération, les systèmes de prévention des intrusions, etc. sont déployés derrière le Gateway Load Balancer dans le VPC de l'appliance centralisée. Ce VPC d'appliance peut se trouver dans le même compte AWS que le Spoke VPCs ou dans un autre compte AWS. Les appliances virtuelles peuvent être configurées pour utiliser des groupes Auto Scaling et sont enregistrées automatiquement auprès du Gateway Load Balancer, ce qui permet le dimensionnement automatique de la couche de sécurité.
Ces dispositifs virtuels peuvent être gérés en accédant à leurs interfaces de gestion via une passerelle Internet (IGW) ou en utilisant une configuration d'hôte bastion dans le VPC de l'appliance.
À l'aide de la fonctionnalité de routage d'entrée VPC, la table de routage périphérique est mise à jour pour acheminer le trafic entrant depuis Internet vers les dispositifs de pare-feu situés derrière Gateway Load Balancer. Le trafic inspecté est acheminé via les points de terminaison Gateway Load Balancer vers l'instance VPC cible. Consultez le billet de blog [Introducing AWS Gateway Load Balancer : Supported architecture patterns](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-supported-architecture-patterns/) pour plus de détails sur les différentes manières d'utiliser Gateway Load Balancer.
# Utilisation du AWS Network Firewall pour une entrée centralisée
Dans cette architecture, le trafic entrant est inspecté par AWS Network Firewall avant d'atteindre le reste du VPCs. Dans cette configuration, le trafic est réparti entre tous les points de terminaison du pare-feu déployés dans le VPC Edge. Vous déployez un sous-réseau public entre le point de terminaison du pare-feu et le sous-réseau Transit Gateway. Vous pouvez utiliser un ALB ou un NLB, qui contiennent des cibles IP dans votre rayon VPCs tout en gérant Auto Scaling pour les cibles situées derrière elles.
![\[Schéma illustrant l'inspection du trafic entrant à l'aide d'AWS Network Firewall\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/ingress-inspection-using-aws-nf.png)
Pour simplifier le déploiement et la gestion AWS Network Firewall de ce modèle, il AWS Firewall Manager peut être utilisé. Firewall Manager vous permet d'administrer de manière centralisée vos différents pare-feux en appliquant automatiquement à plusieurs comptes la protection que vous créez dans un emplacement centralisé. Firewall Manager prend en charge les modèles de déploiement distribués et centralisés pour Network Firewall. Le billet de blog [How to deploy AWS Network Firewall by using AWS Firewall Manager](https://aws.amazon.com/blogs/security/how-to-deploy-aws-network-firewall-by-using-aws-firewall-manager/) fournit plus de détails sur le modèle.
## Inspection approfondie des paquets (DPI) avec AWS Network Firewall
Network Firewall peut effectuer une inspection approfondie des paquets (DPI) sur le trafic entrant. À l'aide d'un certificat TLS (Transport Layer Security) stocké dans AWS Certificate Manager (ACM), Network Firewall peut déchiffrer des paquets, effectuer un DPI et rechiffrer les paquets. Quelques considérations doivent être prises en compte lors de la configuration du DPI avec Network Firewall. Tout d'abord, un certificat TLS fiable doit être stocké dans ACM. Ensuite, les règles du Network Firewall doivent être configurées pour envoyer correctement les paquets à des fins de déchiffrement et de rechiffrement. Reportez-vous au billet de blog [Configuration de l'inspection TLS pour le trafic chiffré et AWS Network Firewall](https://aws.amazon.com/blogs/security/tls-inspection-configuration-for-encrypted-traffic-and-aws-network-firewall/) pour plus de détails.
## Considérations clés relatives AWS Network Firewall à une architecture d'entrée centralisée
+ Elastic Load Balancing in Edge VPC ne peut avoir que des adresses IP comme types de cibles, et non un nom d'hôte. Dans la figure précédente, les cibles sont le privé IPs du Network Load Balancer en rayons. VPCs L'utilisation de cibles IP situées derrière l'ELB dans le VPC Edge entraîne la perte d'Auto Scaling.
+ Envisagez de l'utiliser AWS Firewall Manager comme panneau de verre unique pour les points de terminaison de votre pare-feu.
+ Ce modèle de déploiement utilise l'inspection du trafic dès son entrée dans le VPC de périphérie, ce qui permet de réduire le coût global de votre architecture d'inspection.