Amazon ANS-C01: Sécurité réseau et conformité — Guide d'étude

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Fait partie du AWS Advanced Networking Specialty ANS-C01 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Concept de base

La sécurité réseau dans AWS est en couches : contrôles de périmètre, contrôles au niveau du VPC, contrôles au niveau de l’hôte et de l’application, et surveillance/inspection. Au périmètre du VPC, vous utilisez des groupes de sécurité (pare-feux virtuels stateful, centrés sur l’hôte et appliqués aux ENIs) et des ACLs réseau (NACLs) (filtrage stateless au niveau du sous-réseau, évalué par numéro de règle) pour appliquer des contrôles d’accès généraux. Les groupes de sécurité suivent l’état de la connexion, de sorte qu’un flux de réponse établi est automatiquement autorisé, ce qui les rend idéaux pour autoriser les connexions initiées par les clients vers des pods ou des instances. Les NACLs nécessitent des entrées d’autorisation explicites dans les deux sens ou des règles complémentaires pour le trafic de retour ; elles sont évaluées dans l’ordre croissant des numéros de règle et sont donc appropriées pour un durcissement général au niveau du sous-réseau, comme l’élimination de plages CIDR entières ou l’application d’échappatoires éphémères pour des listes de blocage d’urgence.

L’inspection et l’application centralisée des politiques sont fournies par des services gérés et autogérés. AWS Network Firewall peut mettre en œuvre des protections stateful de type Suricata, un filtrage par liste de domaines et des signatures de type prévention d’intrusion au périmètre du VPC avec des politiques de pare-feu et des groupes de règles explicites. Web Application Firewall (AWS WAF) est axé sur l’application pour la protection de la couche HTTP(S) et s’intègre avec Application Load Balancer, Amazon CloudFront et API Gateway pour appliquer les protections OWASP, des règles basées sur le débit et des vérifications d’en-têtes personnalisés. Les protections DDoS sont fournies par AWS Shield (la version Standard est automatique et gratuite ; Shield Advanced fournit l’ingénierie du trafic, la protection des coûts et l’intégration avec WAF pour l’atténuation au niveau de la couche applicative). Les services de détection tels qu’Amazon GuardDuty analysent les VPC Flow Logs, les journaux DNS et CloudTrail pour faire remonter les activités de reconnaissance, les scans de ports et les comportements d’instances compromises.

La visibilité et la capture de paquets complètent le modèle. Les VPC Flow Logs enregistrent les métadonnées de flux par ENI et peuvent être livrés à CloudWatch Logs, Amazon S3 ou Kinesis Data Firehose pour analyse avec Athena. Pour la capture complète de paquets ou une inspection plus approfondie, Traffic Mirroring permet de dupliquer (mirroring) le trafic d’une ENI vers une appliance IDS/capture de paquets (un capteur EC2 avec une ENI dupliquée ou une cible Network Load Balancer) où s’exécutent des outils comme Suricata ou Zeek. Ensemble, ces contrôles permettent une posture de défense en profondeur où la prévention, la détection et l’investigation numérique (forensics) sont toutes présentes.

Services clés et configuration

Plusieurs services AWS sont essentiels à la sécurité réseau, et chacun possède des modèles de configuration et des API spécifiques à connaître :

• Groupes de sécurité (Security Groups)
• ACLs réseau (NACLs)
• AWS Network Firewall
• AWS WAF
• AWS Shield (Standard et Advanced)
• Amazon GuardDuty
• VPC Flow Logs
• Traffic Mirroring

Les groupes de sécurité sont configurés par ENI via l’API EC2 ou la Console ; pour ajouter une règle d’entrée, utilisez

undefined

. N’oubliez pas d’utiliser les CIDRs du moindre privilège et d’attacher des SGs distincts pour les load balancers et les pods backend afin d’éviter des règles trop permissives. Créez des NACLs via

undefined

et ajoutez des entrées numérotées avec

undefined

en spécifiant le numéro de règle, l’action de la règle, le protocole, la plage de ports et l’indicateur de sortie (egress).

AWS Network Firewall utilise des groupes de règles et des politiques de pare-feu liés à une ressource de pare-feu créée dans un sous-réseau du VPC. Utilisez

undefined

pour définir des règles stateless ou stateful,

undefined

pour les composer, et

undefined

pour déployer. Choisissez les groupes de règles stateful pour l’inspection sensible au protocole et les règles de signature compatibles avec Suricata ; utilisez les règles stateless pour un filtrage de premier niveau à très haut débit.

AWS WAF attache une Web ACL à un ALB et peut appliquer des correspondances d’ensembles d’IP (IP set), des correspondances de chaînes dans les en-têtes ou des règles basées sur le débit. Utilisez

undefined

et spécifiez des règles qui vérifient les en-têtes (par exemple, bloquer les requêtes qui ne contiennent pas un en-tête personnalisé que vous injectez à votre porte d’entrée de confiance). AWS Shield Advanced est activé par compte et fournit un accès à l’équipe de réponse DDoS ainsi que des protections supplémentaires pour les ressources enregistrées auprès de Shield Advanced.

Activez GuardDuty via

undefined

et intégrez les résultats (findings) avec CloudWatch Events ou EventBridge pour l’automatisation. Pour la télémétrie, créez des VPC Flow Logs via

undefined

. Pour la capture de paquets, utilisez

undefined

,

undefined

, et

undefined

pour diriger le trafic dupliqué (mirrored) vers une ENI d’appliance ou un NLB.

Patrons de conception et compromis

Le chiffrement de bout en bout avec mutual TLS où l’équilibreur de charge ne doit pas terminer la session TLS requiert un patron de conception de type pass-through de couche 4. Utilisez un Network Load Balancer (NLB) devant les pods backend afin que la session TLS soit négociée directement avec les points de terminaison du service. Dans Kubernetes sur EKS, déployez un Service de type LoadBalancer s’appuyant sur un NLB et enregistrez les pods comme cibles par IP ; l’AWS Load Balancer Controller ou les anciennes annotations de Service garantissent que le type de cible est IP et que le protocole du groupe de cibles est TCP. Pour la haute simultanéité caractéristique de gRPC et des nombreuses connexions HTTP/2 de longue durée, le NLB préserve les IP sources et impose une surcharge par connexion plus faible que les proxys L7. Si la terminaison TLS au niveau de l’ALB est requise (par ex., pour le routage basé sur l’URL), vous devez terminer la session TLS sur l’ALB en utilisant un certificat ACM, puis transférer le trafic vers les backends ; préservez l’IP du client en vous basant sur l’en-tête X-Forwarded-For (ALB) ou en utilisant un NLB compatible avec le Proxy Protocol v2 pour les backends qui ont besoin de l’IP source originale au niveau L4.

Pour les architectures multi-comptes et multi-VPC évolutives où des services centraux sont nécessaires, PrivateLink (AWS VPC Endpoint Services) est le choix le plus sécurisé et le plus évolutif. Exposez les services centraux depuis le VPC de services partagés en tant que service de point de terminaison AWS PrivateLink. Chaque compte consommateur crée un point de terminaison d’interface VPC vers ce service ; le propriétaire du service peut exiger l’acceptation du point de terminaison et appliquer des contrôles basés sur les groupes de sécurité sur les ENI du point de terminaison. Ce modèle maintient le trafic sur le réseau AWS, évite les limites de mise à l’échelle du peering et fournit une sécurité granulaire par consommateur. Transit Gateway avec la segmentation et Network Firewall peuvent être utilisés pour le transit au niveau du réseau et l’inspection centralisée, mais cette solution est plus appropriée lorsqu’une connectivité entièrement routée avec des politiques de routage complexes est requise, plutôt qu’un isolement par service.

Lors du diagnostic de l’utilisation de la bande passante sur plusieurs VIFs sur Direct Connect, donnez la priorité aux métadonnées : activez et interrogez les VPC Flow Logs agrégés dans S3 ou CloudWatch et analysez-les via Athena pour mapper les flux IP à volume élevé à des VPCs et sous-réseaux spécifiques. Complétez les journaux de flux avec les métriques CloudWatch pour les interfaces virtuelles Direct Connect, et si vous avez besoin d’une inspection au niveau de la charge utile ou de protocoles hétérogènes, déployez Traffic Mirroring pour capturer les paquets vers un IDS basé sur EC2. Traffic Mirroring est une solution lourde et coûteuse ; ne l’utilisez que pour les sessions/fenêtres où les journaux de flux et les résultats de GuardDuty sont insuffisants.

Pièges courants et critères de décision

Une erreur courante consiste à se fier uniquement aux groupes de sécurité pour l’application des règles de périmètre au sens large et à ne pas utiliser les NACL ou Network Firewall lorsqu’une inspection au niveau du sous-réseau ou avec état (stateful) est requise. Les groupes de sécurité sont appliqués par ENI et faciles à gérer, mais ils ne s’adaptent pas bien en tant que plan de contrôle centralisé pour de nombreux VPC dans différents comptes ; utilisez AWS Firewall Manager pour centraliser les règles WAF et Network Firewall entre les comptes. Un autre piège est de terminer la connexion TLS au niveau du répartiteur de charge sans tenir compte de la préservation de l’IP client ; l’ALB insère des en-têtes X-Forwarded-For, mais la journalisation applicative doit lire explicitement cet en-tête et une relation de confiance doit être établie (par exemple, seul l’ALB devrait l’envoyer). Pour garantir de manière stricte que seul Global Accelerator peut atteindre un ALB, évitez de vous fier uniquement au DNS ; à la place, restreignez les écouteurs (listeners) de l’ALB via des groupes de sécurité aux plages d’adresses IP publiées de l’accélérateur (automatisez les mises à jour avec le fichier ip-ranges.json ou les listes de préfixes gérées) ou utilisez un ALB interne uniquement lorsque c’est possible et placez-le derrière le point de terminaison de l’accélérateur.

Choisissez entre PrivateLink et Transit Gateway en pesant la granularité par service par rapport au routage en maillage complet (full-mesh). PrivateLink fournit un contrôle d’accès par service avec un filtrage au niveau des groupes de sécurité et s’adapte sans faire exploser les tables de routage ; Transit Gateway est nécessaire lorsque vous avez besoin d’une connectivité basée sur le routage entre de nombreux VPC et des réseaux sur site (on-premises) et lorsque vous exigez une inspection centralisée des paquets avec AWS Network Firewall. Pour un débit élevé, privilégiez les règles stateless de Network Firewall au périmètre, combinées à des groupes de règles stateful ciblées pour les flux critiques ; le traitement stateless s’adapte bien à la charge mais perd la connaissance du protocole.

Problème pratique : Scénario d’utilisation

Nom de l’entreprise : Meridian Payments — défi : activer une API de paiement basée sur gRPC sur EKS nécessitant du TLS mutuel de bout en bout (mutual TLS, mTLS) (sans terminaison TLS sur le chemin), supporter des milliers de connexions concurrentes de longue durée, l’autoscaling des pods, et l’identification des adresses IP clientes d’origine pour la journalisation et la détection de fraude.

1. Approche : Déployer un Amazon Network Load Balancer devant le Service EKS configuré avec le type de cible (target type) IP afin que les ENI des pods soient enregistrées directement auprès des groupes cibles (target groups) du NLB. Utiliser l’AWS Load Balancer Controller pour créer un Service adossé à un NLB avec des annotations pour garantir que le protocole du groupe cible est TCP sur le port 443 et que les vérifications de santé (health checks) utilisent TCP. Terminer la connexion mTLS au niveau des pods backend ; configurer Istio ou une bibliothèque TLS en sidecar si vous avez besoin d’une rotation de certificats standardisée, en utilisant des Kubernetes Secrets alimentés par AWS Certificate Manager Private Certificate Authority ou AWS Secrets Manager. Préserver les IP clientes car le NLB préserve l’IP source ; s’assurer que les règles networkPolicy des pods backend et les groupes de sécurité autorisent les plages sources provenant du NLB/des clients. Utiliser HPA et Cluster Autoscaler pour mettre à l’échelle les pods ; s’assurer que le délai de désenregistrement du groupe cible (deregistration delay) est ajusté pour permettre un drainage des connexions en douceur (graceful connection draining).

2. Approche d’observabilité et d’analyse forensique : Activer les VPC Flow Logs pour le VPC d’EKS vers CloudWatch Logs et les agréger dans S3 via Kinesis Firehose pour la rétention et les requêtes Athena afin de cartographier les flux à large bande passante. Activer GuardDuty pour la détection d’anomalies sur les flux VPC et le DNS. Si une inspection de paquets plus approfondie est requise pendant les fenêtres de suspicion de fraude, créer des sessions Traffic Mirror sur les ENI problématiques vers un capteur EC2 exécutant Suricata ; gérer les filtres de miroir pour ne capturer que le trafic pertinent afin de limiter les coûts.

Justification AWS : Le NLB fournit un passage direct de niveau 4 (L4 pass-through), de sorte que TLS et mTLS sont négociés de bout en bout et que le backend voit la véritable IP du client, ce qui satisfait à l’exigence que le trafic ne soit pas déchiffré par des proxys intermédiaires et que l’analyse pour la journalisation/fraude voie la source d’origine. L’enregistrement des pods par IP et l’utilisation de l’AWS Load Balancer Controller s’intègrent à l’autoscaling d’EKS. VPC Flow Logs, GuardDuty et Traffic Mirroring fournissent une visibilité graduée, des métadonnées à la capture complète de paquets, pour une conformité et une réponse aux incidents évolutives et rentables.

← Équilibrage de charge et gestion du trafic · Tous les domaines · Distribution de contenu et réseautage en périphérie →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Amazon →