Amazon SCS-C02: Sécurité en périphérie et des applications — Guide d'étude

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Fait partie du AWS Security Specialty SCS-C02 — 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.

Restriction géographique de CloudFront et blocage par pays

CloudFront propose deux mécanismes pour bloquer le trafic par pays, et le choix entre les deux a un impact sur le coût et la fonctionnalité. La fonctionnalité intégrée de restriction géographique (aussi appelée géoblocage) est configurée directement sur la distribution et évalue les requêtes en périphérie par rapport à une liste d’autorisation ou de blocage de pays, dérivée de l’adresse IP du visiteur. Elle est gratuite, ne nécessite aucune évaluation de règle, et renvoie un code HTTP 403 avant toute requête vers l’origine. Pour les scénarios de conformité simples — « bloquer les visiteurs du pays X » — c’est l’option la moins chère et la plus simple.

L’alternative est une règle de correspondance géographique WAF (geo match statement), qui est plus flexible : vous pouvez combiner des correspondances de pays avec des chemins d’URI, des en-têtes, des limites de débit, ou les inverser (« autoriser le pays A uniquement pour /admin »). WAF est nécessaire lorsque la logique est conditionnelle ; la restriction géographique seule ne peut pas exprimer « bloquer le pays X uniquement pour un chemin spécifique ». Choisissez la restriction géographique native lorsque l’exigence est un blocage de pays simple et que vous souhaitez éviter le coût par requête de WAF.

URL signées versus Cookies signés pour le contenu privé

CloudFront prend en charge deux méthodes pour servir du contenu privé autorisé tout en gardant l’origine (bucket S3, ALB ou origine Média) cachée derrière un contrôle d’accès à l’origine ou un en-tête personnalisé :

URL signées : chaque URL contient une signature et une politique. Idéal pour le téléchargement d’un fichier unique ou lorsque vous avez besoin d’un contrôle d’accès par fichier (par exemple, un lien ponctuel pour un installateur de logiciel).
Cookies signés : le client reçoit un ensemble de cookies CloudFront-Policy, CloudFront-Signature et CloudFront-Key-Pair-Id une seule fois par votre service d’authentification. Toutes les requêtes ultérieures vers des chemins correspondants sont autorisées automatiquement sans avoir à réécrire les URL.

Pour le streaming vidéo HLS, où une seule session de lecture récupère des milliers de segments .ts référencés par un manifeste, les cookies signés sont considérablement plus simples. Réécrire chaque URL de segment dans le manifeste avec une URL signée distincte est possible, mais cela ajoute de la latence et de la complexité. Définissez le cookie après que l’abonné s’est authentifié auprès de votre base d’utilisateurs interne, en le limitant au modèle de chemin du streaming.

Une politique canonique pour un cookie signé avec joker ressemble à ceci :

{
  "Statement": [{
    "Resource": "https://d123.cloudfront.net/videos/*",
    "Condition": {
      "DateLessThan": {"AWS:EpochTime": 1735689600},
      "IpAddress":    {"AWS:SourceIp": "203.0.113.0/24"}
    }
  }]
}

Associez cela à un contrôle d’accès à l’origine (OAC) ou à un en-tête personnalisé secret validé par WAF au niveau de l’origine, afin que les utilisateurs ne puissent pas contourner CloudFront et accéder directement à l’origine.

AWS WAF : Règles gérées, ATP et Règles basées sur le débit

Attachez la Web ACL à la distribution CloudFront plutôt qu’à un ALB régional lorsque la charge de travail se trouve derrière CloudFront. L’attachement en périphérie met fin aux requêtes malveillantes à l’un des centaines de points de présence (POP) — plus près de l’attaquant — ce qui réduit la charge sur l’origine pendant une attaque DDoS et diminue le trafic sortant de l’origine, car le trafic bloqué ne traverse jamais votre VPC. Attacher WAF uniquement à l’ALB signifie que l’attaque volumétrique atteint toujours le load balancer régional et consomme des LCU, et que les attaques inter-régionales sont gérées par une seule région plutôt que par le réseau de périphérie mondial.

Groupes de règles clés à combiner :

Ensembles de règles gérées par AWS : AWSManagedRulesCommonRuleSet (type top 10 de l’OWASP), AWSManagedRulesKnownBadInputsRuleSet et AWSManagedRulesAmazonIpReputationList offrent une large couverture avec un ajustement quasi nul.
Prévention de prise de contrôle de compte (ATP) : AWSManagedRulesATPRuleSet inspecte le point de terminaison de connexion que vous désignez, suit les schémas d’attaques par bourrage d’identifiants (credential stuffing), vérifie les identifiants soumis par rapport à une base de données d’identifiants compromis, et bloque les bots qui réutilisent des mots de passe divulgués. Configurez-le avec le chemin de connexion exact et les noms des champs du corps JSON pour le nom d’utilisateur et le mot de passe.
Règles basées sur le débit : limitent le nombre de requêtes provenant d’une même adresse IP sur une fenêtre de 5 minutes (par exemple, 2 000 requêtes). Limitez leur portée par URI ou par méthode afin que le scraping de /search n’affecte pas la navigation anonyme sur /. Les règles de débit atténuent les attaques volumétriques de couche 7 et l’énumération par force brute.

Un bloc de règles WAF simplifié :

Rules:
  - Name: RateLimitLogin
    Priority: 1
    Action: { Block: {} }
    Statement:
      RateBasedStatement:
        Limit: 500
        AggregateKeyType: IP
        ScopeDownStatement:
          ByteMatchStatement:
            SearchString: /api/login
            FieldToMatch: { UriPath: {} }
            PositionalConstraint: STARTS_WITH
            TextTransformations: [{ Priority: 0, Type: LOWERCASE }]

Certificats ACM, Validation DNS et CloudFront

Pour CloudFront, le certificat doit être provisionné dans ACM dans la région us-east-1 (N. Virginia), quel que soit l’emplacement de votre origine — c’est une exigence stricte car CloudFront est un service mondial qui lit les certificats depuis cette région. Les services régionaux comme ALB lisent les certificats de la propre région de l’ALB.

Utilisez toujours la validation DNS avec un enregistrement CNAME dans Route 53 pour tout certificat public que vous souhaitez renouveler automatiquement. ACM renouvelle automatiquement les certificats validés par DNS tant que le CNAME de validation reste publié ; Route 53 rend cela trivial (la console propose « Créer des enregistrements dans Route 53 » lors de la demande). La validation par e-mail, en revanche, envoie une confirmation à cinq adresses du domaine (admin@, administrator@, hostmaster@, postmaster@, webmaster@) ainsi qu’au contact WHOIS. Ces boîtes aux lettres sont souvent inexistantes ou mises en quarantaine par les filtres de messagerie d’entreprise, ce qui entraîne l’échec des renouvellements 60 jours avant l’expiration et provoque des pannes évitables. Il n’y a aucun moyen d’automatiser les clics de validation par e-mail.

Le modèle de renouvellement correct pour les ALB multi-régions est le suivant : demander un certificat ACM validé par DNS par région, publier le CNAME de validation dans Route 53 une seule fois, attacher le certificat à l’écouteur de l’ALB, et laisser ACM gérer le renouvellement et le redéploiement. L’intervention humaine s’arrête après l’émission.

DNSSEC et Route 53

Activez la signature DNSSEC sur la zone hébergée Route 53 pour empêcher l’usurpation DNS (spoofing) et l’empoisonnement du cache contre votre domaine. Route 53 gère la KSK dans KMS (clé ECC asymétrique dans us-east-1) ; vous devez publier l’enregistrement DS auprès de votre bureau d’enregistrement (registrar). Notez que la signature DNSSEC protège la résolution de votre zone — elle ne chiffre pas le trafic DNS (ça, c’est le rôle de DoH/DoT) et n’affecte pas le TLS de CloudFront.

En-têtes de réponse : Politiques versus Lambda@Edge

CloudFront n’injecte pas automatiquement les en-têtes de sécurité tels que Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options ou Content-Security-Policy. Si votre origine ne peut pas être modifiée (un site S3 hérité, une origine tierce), vous avez deux options :

Politique d’en-têtes de réponse : une fonctionnalité CloudFront native et déclarative. Attachez une politique gérée ou personnalisée à un comportement de cache pour ajouter des en-têtes HSTS, CORS, de sécurité et personnalisés. Cela devrait être le choix par défaut — pas de code, pas de démarrages à froid, pas de coût par invocation.
Lambda@Edge (réponse du visualiseur ou réponse de l’origine) : à utiliser lorsque vous avez besoin d’une logique dynamique, comme faire varier les nonces CSP par requête ou réécrire les en-têtes en fonction des attributs de la requête. Échange la simplicité contre la flexibilité et ajoute un coût par requête.

La politique d’en-têtes de réponse gérée SecurityHeadersPolicy couvre la base commune en une seule pièce jointe.

Explication des pièges courants

Demander des certificats ACM publics avec validation par e-mail est fragile précisément parce que le renouvellement dépend d’humains lisant des e-mails envoyés à des adresses génériques que la plupart des organisations ne surveillent pas ou qui sont acheminées vers les spams. La validation DNS avec Route 53 supprime entièrement la boucle humaine.

Attacher WAF uniquement à l’ALB semble équivalent sur le papier, mais force le trafic d’attaque à entrer dans votre Région et consomme la capacité de l’ALB. Un WAF attaché en périphérie (Edge) sur CloudFront bloque au niveau de centaines de POPs, de sorte qu’une inondation distribuée est absorbée globalement et que l’egress de l’origine reste faible — ce qui est essentiel lors d’une attaque DDoS.

Supposer que CloudFront ajoute automatiquement des en-têtes de sécurité conduit à l’échec des tests d’intrusion. La distribution relaie les en-têtes envoyés par l’origine ; vous devez attacher explicitement une politique d’en-têtes de réponse ou une fonction Lambda@Edge pour injecter X-Frame-Options: DENY, HSTS et CSP.

Problème pratique : Scénario d’utilisation

Scénario : Meridian Financial exploite un portail client distribué mondialement et un portail de rapports internes sur AWS. Le trafic public est acheminé via Amazon CloudFront vers des Application Load Balancers pour les API dynamiques et vers des origines S3 pour les rapports privés ; le DNS est dans Route 53 et les certificats TLS sont émis par AWS Certificate Manager (ACM).

Défi : Des attaquants font du scraping et du credential stuffing sur des comptes depuis plusieurs pays, contournant CloudFront en accédant directement aux points de terminaison de l’origine pour télécharger des rapports privés, provoquant une surcharge de l’origine et une exposition des données.

Approche recommandée :

Configurer CloudFront comme unique point d’entrée public et appliquer la Géo-Restriction CloudFront pour bloquer les pays incriminés ; activer l’Origin Access Control (OAC) et verrouiller les politiques d’origine S3/ALB pour que seul CloudFront puisse récupérer le contenu de l’origine.
Servir les rapports privés par utilisateur avec des URL signées CloudFront (TTL court) plutôt qu’avec des cookies signés, afin que chaque téléchargement soit autorisé et auditable individuellement.
Attacher AWS WAF à la distribution CloudFront en utilisant les AWS Managed Rules, activer AWS WAF Bot Control (protection avancée contre les menaces) et créer des règles basées sur le débit (rate-based) ainsi que des défis CAPTCHA pour atténuer le scraping et le credential stuffing.
Provisionner les certificats TLS dans ACM (us-east-1 pour les distributions CloudFront) en utilisant la validation DNS via Route 53, et publier des enregistrements Alias Route 53 vers la distribution CloudFront.
Activer DNSSEC sur la zone hébergée Route 53, activer les journaux d’accès CloudFront et WAF vers S3, et créer des alarmes CloudWatch et éventuellement AWS Shield Advanced pour la visibilité et les alertes DDoS.

Justification : Forcer tout le trafic à passer par CloudFront avec OAC et WAF applique un accès à l’origine selon le principe du moindre privilège, la Géo-Restriction et les protections basées sur le débit/WAF arrêtent le trafic abusif, les URL signées fournissent une autorisation par objet, et la validation ACM+DNS avec DNSSEC assure un TLS de confiance et l’intégrité DNS conformément aux meilleures pratiques AWS.

Règles AWS WAF et intégration avec ALB et CloudFront

AWS WAF est un pare-feu de couche 7 qui évalue les requêtes HTTP(S) par rapport à une Web ACL composée de règles ordonnées. Chaque règle inspecte les attributs de la requête (URI, en-têtes, corps, chaîne de requête, IP source) et renvoie une action terminale (Allow, Block, Challenge, CAPTCHA) ou une action non terminale (Count). Les Web ACLs s’attachent aux distributions CloudFront, aux Application Load Balancers, à API Gateway, AppSync, aux groupes d’utilisateurs Cognito et aux services App Runner. Lorsqu’elle est attachée à CloudFront, l’ACL s’exécute en périphérie (edge) et doit être créée dans la portée us-east-1 (Globale) ; pour un ALB, elle doit être dans la même Région que le load balancer.

Les règles basées sur le débit (rate-based) suivent le nombre de requêtes provenant d’une seule IP (ou d’un en-tête d’IP transférée, ou d’une clé agrégée telle qu’une combinaison URI + IP) sur une fenêtre glissante de cinq minutes. Lorsque le décompte dépasse le seuil configuré, l’action de la règle se déclenche jusqu’à ce que le débit redescende en dessous de la limite. Comme AWS WAF met à jour en continu la liste des contrevenants en quelques secondes, les règles basées sur le débit sont la réponse canonique aux abus de grand volume provenant d’un petit ensemble d’IP en rotation — vous n’avez pas à gérer manuellement un ensemble d’IP, et la charge opérationnelle est essentiellement nulle après le déploiement de la règle initiale.

{
  "Name": "RateLimitPerIP",
  "Priority": 10,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 2000,
      "AggregateKeyType": "IP"
    }
  },
  "Action": { "Block": {} },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "RateLimitPerIP"
  }
}

Les ensembles d’IP (IP sets) sont des listes réutilisables de plages CIDR référencées par des règles avec une IPSetReferenceStatement. Ils sont la primitive appropriée lorsque vous avez une liste de blocage/autorisation déterministe — par exemple, des points de terminaison d’administration géo-restreints ou des plages d’IP malveillantes connues provenant de flux de renseignement sur les menaces. Les règles personnalisées combinent plusieurs déclarations avec les opérateurs logiques AndStatement, OrStatement et NotStatement, vous permettant d’exprimer des conditions comme « bloquer les requêtes vers /login provenant de pays autres que les États-Unis qui n’ont pas non plus un en-tête spécifique ».

CloudFront comme couche de mitigation DDoS et protection de l’origine

CloudFront absorbe les attaques volumétriques et par épuisement d’état au niveau de la périphérie AWS (edge), bien avant que le trafic n’atteigne votre flotte d’ALB ou d’EC2. Chaque emplacement périphérique exécute AWS Shield Standard automatiquement, offrant une mitigation des attaques par inondation SYN (SYN flood) et par réflexion, sans frais supplémentaires. Placer CloudFront devant un ALB réduit la surface d’attaque au réseau périphérique et permet d’activer WAF au niveau de la périphérie, la géo-restriction et la terminaison TLS.

La mitigation n’est efficace que si les attaquants ne peuvent pas contourner CloudFront en ciblant directement le nom DNS de l’ALB. Deux mécanismes permettent de renforcer ce chemin. Premièrement, configurez CloudFront pour injecter un en-tête d’origine personnalisé secret (par exemple X-Origin-Verify: <valeur-aléatoire>) et configurez une règle d’écouteur (listener) d’ALB qui renvoie un 403 pour toute requête ne contenant pas cette valeur d’en-tête exacte. Effectuez une rotation périodique du secret via AWS Secrets Manager. Deuxièmement, restreignez le groupe de sécurité de l’ALB à la liste de préfixes gérée par AWS com.amazonaws.global.cloudfront.origin-facing, qui contient les plages d’adresses IP des serveurs périphériques de CloudFront.

ALBListenerRule:
  Type: AWS::ElasticLoadBalancingV2::ListenerRule
  Properties:
    Actions:
      - Type: fixed-response
        FixedResponseConfig: { StatusCode: "403", ContentType: text/plain }
    Conditions:
      - Field: http-header
        HttpHeaderConfig:
          HttpHeaderName: X-Origin-Verify
          Values: ["!Ref OriginSecret"]
      - Field: http-header
        HttpHeaderConfig: { HttpHeaderName: X-Origin-Verify, Values: ["*"] }
    Priority: 1

Le simple fait d’attacher une ACL WAF à l’ALB sans forcer le trafic à passer par CloudFront laisse le point de terminaison de l’ALB résolvable publiquement. Les attaquants qui découvrent le nom DNS (via les journaux de transparence des certificats, l’historique DNS ou l’énumération de sous-domaines) peuvent l’attaquer directement, contournant ainsi toutes les protections en périphérie. C’est l’erreur d’architecture la plus courante dans les conceptions “CloudFront + ALB”.

Métriques, alarmes et notifications de Shield Advanced

Shield Advanced ajoute une détection améliorée, un accès 24/7 à l’équipe de réponse Shield (Shield Response Team), une protection des coûts liés à la mise à l’échelle pendant les attaques, et une visibilité sur les attaques de la couche applicative. Cependant, il n’envoie pas automatiquement d’e-mail ou de SMS lorsqu’une attaque se produit. Les notifications doivent être configurées explicitement via CloudWatch.

Shield Advanced publie la métrique DDoSDetected (valeur 1 pendant une attaque en cours) et les métriques DDoSAttackBitsPerSecond, DDoSAttackPacketsPerSecond et DDoSAttackRequestsPerSecond par ressource protégée dans l’espace de noms AWS/DDoSProtection. Créez une alarme CloudWatch sur DDoSDetected >= 1 avec un sujet SNS comme action d’alarme ; SNS se charge ensuite de diffuser la notification par e-mail, SMS, chat ou à un répondeur Lambda.

aws cloudwatch put-metric-alarm \
  --alarm-name ShieldDDoSDetected \
  --namespace AWS/DDoSProtection \
  --metric-name DDoSDetected \
  --statistic Maximum --period 60 --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:us-east-1:111122223333:secops-alerts

Supposer que Shield Advanced va “simplement vous envoyer un e-mail” est une idée fausse fréquente — sans l’alarme CloudWatch et l’abonnement SNS, le seul signal est la console Shield et l’événement sur le tableau de bord AWS Health.

AWS Network Firewall avec blocage automatisé par Lambda

Network Firewall est un pare-feu stateful (avec état) de couche 3 à 7, attaché à un VPC, qui inspecte le trafic traversant les tables de routage des sous-réseaux. Sa politique se compose de groupes de règles stateless (sans état) et stateful (avec état) ; les groupes de règles stateful utilisent une syntaxe compatible avec Suricata. Comme les groupes de règles sont gérés par API, ils sont des cibles idéales pour l’automatisation événementielle.

Un modèle courant consiste à réagir aux résultats de GuardDuty (par exemple UnauthorizedAccess:EC2/RDPBruteForce ou Backdoor:EC2/C&CActivity). Security Hub agrège le résultat, EventBridge correspond à un modèle d’événement et invoque une fonction Lambda, et la Lambda appelle UpdateRuleGroup pour insérer une règle de rejet (drop) ciblant l’IP incriminée ou l’ENI de l’instance compromise.

def handler(event, _):
    ip = event["detail"]["findings"][0]["ProductFields"]["aws/guardduty/service/action/networkConnectionAction/remoteIpDetails/ipAddressV4"]
    new_rule = f'drop ip {ip} any -> any any (msg:"GD-block"; sid:{sid()}; rev:1;)'
    rg = nfw.describe_rule_group(RuleGroupArn=RG_ARN)
    rules = rg["RuleGroup"]["RulesSource"]["RulesString"] + "\n" + new_rule
    nfw.update_rule_group(
        RuleGroupArn=RG_ARN,
        UpdateToken=rg["UpdateToken"],
        RulesSource={"RulesString": rules})

Network Firewall est le bon choix lorsque vous devez bloquer le trafic bidirectionnel vers/depuis une instance EC2 ou un CIDR au périmètre du VPC — WAF n’inspecte que les requêtes HTTP destinées aux points de terminaison de couche 7 pris en charge, il ne peut donc pas arrêter le trafic C2 sortant ou les protocoles non-HTTP.

← Réseau et sécurité VPC · Tous les domaines · Gouvernance →

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

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

Réussissez votre examen →

Parcourir Amazon →