Amazon SCS-C02: Vulnérabilités, correctifs et sécurité des hôtes — 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.

Amazon Inspector : Analyse améliorée pour EC2, Lambda et ECR

Amazon Inspector est un service de gestion continue des vulnérabilités, assisté par un agent, qui découvre les CVE dans les instances EC2, les images de conteneurs stockées dans ECR et les fonctions Lambda (à la fois le code de l’application et les couches de dépendances). L’activation d’Inspector au niveau du compte inscrit automatiquement les ressources éligibles — il n’y a pas de flux d’adhésion par ressource — et les résultats sont automatiquement transmis à AWS Security Hub au format standardisé ASFF, ce qui constitue le modèle d’intégration correct lorsqu’un tableau de bord central de la posture de sécurité est requis.

Pour EC2, Inspector utilise un modèle d’analyse hybride. L’agent SSM (avec l’association fournie par AWS) collecte un inventaire logiciel utilisé pour une évaluation de l’accessibilité réseau et des paquets de type sans agent, tandis que l’évaluation approfondie de l’hôte nécessite que l’agent soit en cours d’exécution et que l’instance soit accessible via SSM. C’est pourquoi l’approche « uniquement sans agent » est un piège : sans le canal de l’agent SSM (ou l’inspection approfondie basée sur l’agent d’Inspector si nécessaire), vous obtenez des résultats superficiels — l’exposition réseau et les CVE dérivées du manifeste — mais vous manquez les inventaires des bibliothèques d’exécution, les paquets non gérés et les configurations. Le mode hybride est ce dont la plupart des parcs de production ont besoin.

Pour Lambda, Inspector effectue deux types d’analyse : standard (vulnérabilités des paquets dans les couches et les dépendances de la fonction) et analyse de code (analyse statique du code de la fonction pour les failles d’injection, les secrets codés en dur et les API non sécurisées). Une règle d’éligibilité critique : une fonction Lambda doit avoir été invoquée au moins une fois au cours des 90 derniers jours pour être analysée. Les fonctions inactives ou archivées sortent silencieusement du champ d’application d’Inspector. Les équipes qui supposent qu’« Inspector est activé, donc chaque fonction est couverte » se font piéger lorsque les auditeurs demandent des preuves sur les fonctions rarement exécutées. La remédiation consiste soit à invoquer les fonctions selon un calendrier (EventBridge), soit à accepter l’exclusion et à la documenter.

Pour ECR, l’analyse améliorée (propulsée par Inspector) remplace l’ancienne analyse de base basée sur Clair. L’analyse améliorée prend en charge à la fois l’analyse lors du push et l’analyse continue des images déjà présentes dans le registre. Ainsi, les CVE nouvellement divulguées pour des images précédemment poussées génèrent de nouveaux résultats sans qu’un nouveau push soit nécessaire. Activez l’analyse améliorée au niveau du registre et configurez des filtres par dépôt (par exemple, prod/* en continu, sandbox/* en analyse lors du push uniquement) pour maîtriser les coûts.

Administration déléguée et suppression

Dans une configuration multi-comptes AWS Organizations, désignez un compte administrateur délégué pour Inspector depuis le compte de gestion. L’administrateur délégué voit les résultats agrégés de tous les comptes membres et contrôle la configuration d’analyse à l’échelle de l’organisation. Cela évite d’accorder des rôles IAM inter-comptes pour la récupération des résultats et prévient l’anti-modèle consistant à activer Inspector au cas par cas pour chaque compte.

Les règles de suppression permettent à une équipe de sécurité de filtrer le bruit sans supprimer les résultats. Une règle établit une correspondance sur des attributs tels que le tag de la ressource, la sévérité, l’ID de la CVE ou le dépôt ECR. Pour exclure les résultats des fonctions Lambda de dev/test du tableau de bord de production, appliquez une règle de suppression basée sur le tag Environment=dev — les résultats existent toujours dans le datastore sous-jacent pour l’audit, mais ils sont exclus des vues par défaut et de Security Hub si cela est configuré. Ne faites pas cela en désactivant Inspector pour les comptes de dev ; vous perdriez la capacité de détecter la promotion d’un artefact vulnérable de dev en prod.

Verrouillage (Gating) CI/CD pour la promotion d’images

L’analyse améliorée d’ECR génère des résultats liés à un condensat (digest) de l’image (et pas seulement le tag), ce qu’un pipeline doit interroger. Le modèle canonique est le suivant : construire l’image → pousser vers ECR (déclenche l’analyse lors du push) → interroger ou attendre la fin de l’analyse → faire échouer le build si des résultats de sévérité High ou Critical existent → sinon, mettre à jour la tâche/le déploiement ECS/EKS.

Une étape CodeBuild minimale dans buildspec.yml :

post_build:
  commands:
      DIGEST=$(aws ecr describe-images --repository-name $REPO \
        --image-ids imageTag=$TAG --query 'imageDetails[0].imageDigest' -o text)
      aws inspector2 list-findings \
        --filter-criteria "{\"ecrImageHash\":[{\"comparison\":\"EQUALS\",\"value\":\"$DIGEST\"}],\"severity\":[{\"comparison\":\"EQUALS\",\"value\":\"HIGH\"},{\"comparison\":\"EQUALS\",\"value\":\"CRITICAL\"}]}" \
        --query 'findings[].findingArn' --output text > findings.txt
    - if [ -s findings.txt ]; then echo "Blocking - CVEs found"; exit 1; fi

Ne pas mettre en place ce verrou à cette étape — en se fiant au fait qu’« Inspector nous alertera » — est l’erreur classique : les alertes arrivent de manière asynchrone et après que l’image vulnérable est déjà en cours d’exécution. Le verrou doit être synchrone avec la promotion. De même, verrouiller uniquement sur le tag plutôt que sur le condensat n’est pas sûr car les tags sont mutables ; deux pushes avec le même tag fusionneront les résultats d’analyse.

Patch Manager, Référentiels de correctifs (Baselines) et Groupes de correctifs (Patch Groups)

SSM Patch Manager opère sur trois primitives :

Référentiel de correctifs (Patch baseline) : définit les règles d’approbation automatique, les correctifs approuvés, les correctifs rejetés et le niveau de conformité par sévérité/classification.
Groupe de correctifs (Patch group) : un tag avec la clé exacte Patch Group dont la valeur enregistre les instances auprès d’un référentiel spécifique.
Fenêtre de maintenance (Maintenance window) : la plage horaire pendant laquelle AWS-RunPatchBaseline exécute les tâches d’analyse (Scan) ou d’installation (Install).

Pour un environnement qui exige que Dev approuve automatiquement tous les correctifs de sécurité immédiatement, et que Prod n’approuve automatiquement que les correctifs critiques/importants après une période de maturation de 7 jours tout en rejetant les paquets du noyau, vous créez deux référentiels. Le référentiel de Dev utilise une règle d’approbation avec ApproveAfterDays: 0 couvrant toutes les classifications de sécurité. Le référentiel de Prod utilise ApproveAfterDays: 7, ComplianceLevel: CRITICAL, filtre sur Classification=Security et Severity in [Critical, Important], et ajoute kernel* à la liste des correctifs rejetés avec BlockAllPatchesFromRejectedList. Les instances sont taguées Patch Group=Dev ou Patch Group=Prod, et chaque groupe de correctifs est enregistré auprès du référentiel correspondant. La conformité est agrégée via les rapports de conformité des correctifs (Patch Compliance reports) et peut être exportée vers S3 pour un audit centralisé.

Un seul référentiel « avec de la logique » ne peut pas exprimer les différences Dev-vs-Prod — les référentiels sont statiques pour chaque groupe enregistré. N’essayez pas d’utiliser différentes fenêtres de maintenance pour simuler ce comportement ; la fenêtre contrôle quand le patching s’exécute, pas quels correctifs sont approuvés.

Pipeline de notification en temps réel

Pour la génération d’alertes sur Slack ou Microsoft Teams concernant de nouveaux résultats, la chaîne la plus efficace sur le plan opérationnel est la suivante :

Inspector émet des résultats vers EventBridge sur la source d’événements aws.inspector2.
Une règle EventBridge filtre par sévérité (par ex., HIGH, CRITICAL) et cible un sujet SNS.
Le sujet SNS possède un abonnement AWS Chatbot mappé sur le canal Slack ou l’espace de travail Teams.

Chatbot s’abonne directement à SNS — n’insérez pas de fonction Lambda intermédiaire pour reformater les messages, car Chatbot affiche nativement les résultats d’Inspector. Voici un exemple de modèle EventBridge :

{
  "source": ["aws.inspector2"],
  "detail-type": ["Inspector2 Finding"],
  "detail": { "severity": ["HIGH", "CRITICAL"] }
}

Deux pièges à éviter ici : le routage via Security Hub ajoute de la latence et peut faire perdre la granularité de la sévérité si les “insights” personnalisés sont mal configurés ; et l’utilisation de SES ou d’une fonction Lambda avec un webhook personnalisé augmente la charge opérationnelle sans ajouter de capacité que Chatbot fournit déjà nativement.

Problème pratique : Scénario d’utilisation

Scénario : Meridian Financial gère une organisation AWS multi-comptes qui prend en charge des services web destinés aux clients, des analyses par lots et des processeurs d’événements sans serveur. Leurs pipelines CI/CD publient des images de conteneurs sur Amazon ECR, ils hébergent des flottes EC2 pour les charges de travail héritées (legacy) et utilisent Lambda pour les services plus récents ; une équipe de sécurité centrale dans un compte de sécurité doit gérer la visibilité des vulnérabilités et l’application des correctifs sur l’ensemble des comptes.

Défi : Une image récente contenant une bibliothèque avec une vulnérabilité de haute sévérité a été promue en production car les analyses n’étaient pas obligatoires dans le CI/CD, et l’application de correctifs sur les instances EC2 est incohérente entre les environnements, ce qui laisse des fenêtres d’exposition et génère des résultats bruyants qui submergent l’équipe.

Approche recommandée :

Activer l’analyse améliorée (Enhanced Scanning) d’Amazon Inspector pour EC2, Lambda et ECR depuis le compte de sécurité en configurant l’administration déléguée dans AWS Organizations, afin que les analyses, les résultats et les règles de suppression puissent être gérés de manière centralisée.
Configurer l’analyse d’images ECR lors du push et intégrer des portes de validation des analyses (scan gates) dans CodePipeline/CodeBuild : bloquer la promotion de l’image jusqu’à ce que les résultats d’analyse d’Inspector/ECR respectent les seuils de sévérité et faire remonter les résultats via l’étape de build.
Mettre en œuvre AWS Systems Manager Patch Manager avec des bases de référence de correctifs (patch baselines) et des groupes de correctifs (patch groups) définis par environnement, planifier des fenêtres de maintenance (Maintenance Windows) pour un déploiement prioritaire en non-production, et automatiser l’approbation des correctifs pour les CVE critiques à l’aide de documents SSM Automation.
Créer un pipeline de notification en temps réel utilisant Amazon EventBridge pour capturer les résultats d’Inspector et les événements de conformité SSM, les acheminer vers Amazon SNS et une fonction AWS Lambda légère qui enrichit, déduplique et publie des alertes priorisées sur Slack et crée des tickets de suivi.
Automatiser le confinement et la remédiation : utiliser des runbooks SSM Automation ou Lambda déclenchés par EventBridge pour isoler les versions EC2/Lambda impactées ou déclencher la reconstruction d’images, et appliquer la suppression d’Inspector uniquement pour les faux positifs suivis via le compte d’administrateur délégué afin de réduire le bruit.

Justification : La gestion centralisée d’Inspector, les portes de validation dans le CI/CD, les bases de référence de Patch Manager et un pipeline piloté par EventBridge suivent les meilleures pratiques AWS en imposant une prévention automatisée, une application de correctifs cohérente et une réponse priorisée et auditable, tout en réduisant la fatigue liée aux alertes.

Découverte de vulnérabilités avec Amazon Inspector

Amazon Inspector est le principal service géré d’évaluation des vulnérabilités sur AWS, et il opère sur trois surfaces pertinentes pour la sécurité des hôtes : les instances EC2, les images de conteneurs dans Amazon ECR et les fonctions Lambda. Lorsqu’il est activé au niveau du compte ou de l’organisation (via un administrateur délégué dans la console Inspector), il effectue une analyse continue, sans agent ou basée sur SSM, plutôt que des analyses ponctuelles planifiées. Cette posture continue est importante car les flux de CVE changent quotidiennement ; un instantané de la semaine dernière peut déjà être obsolète.

Pour EC2, Inspector s’appuie sur l’agent SSM pour énumérer les paquets installés et les versions du noyau, puis les corrèle avec les avis des fournisseurs et la National Vulnerability Database. Les résultats incluent l’identifiant CVE, le score CVSS, le paquet affecté, la version corrigée et le contexte d’accessibilité réseau (les règles d’accessibilité réseau identifient les ports exposés à Internet via les ENI, les groupes de sécurité, les NACL et les tables de routage). Comme l’analyse dépend de SSM, une instance EC2 à laquelle il manque la politique gérée AmazonSSMManagedInstanceCore sur son profil d’instance n’apparaîtra tout simplement pas dans les résultats d’Inspector — une défaillance silencieuse qu’il est bon de retenir.

Pour ECR, Inspector prend en charge deux modes d’analyse :

Analyse de base (Basic scanning) : gratuite, utilise le moteur open-source Clair, s’exécute uniquement lors du push ou à la demande.
Analyse améliorée (Enhanced scanning) : optimisée par Inspector, ré-analyse en continu les images (à la fois les paquets du système d’exploitation et les paquets des langages applicatifs comme Python, Node, Java) à mesure que de nouvelles CVE sont publiées, même longtemps après l’événement de push.

Un piège courant consiste à considérer l’analyse ECR lors du push (scan-on-push) comme une sécurité d’hôte suffisante. Ce n’est pas le cas. L’analyse lors du push valide l’image au moment du build, mais le conteneur en cours d’exécution hérite de l’image plus toute dérive éventuelle, et l’hôte EC2 ou Fargate sous-jacent possède son propre noyau et ses propres paquets de système d’exploitation qui doivent être corrigés indépendamment. L’analyse améliorée, combinée à l’analyse des hôtes EC2, comble cette lacune. Tous les résultats d’Inspector doivent être acheminés vers AWS Security Hub, qui les normalise au format ASFF et permet l’agrégation inter-comptes, la déduplication et l’automatisation en aval via EventBridge.

Patch Manager et Remédiation à l’échelle du parc

AWS Systems Manager Patch Manager complète Inspector en remédiant réellement à ce qu’Inspector découvre. Alors qu’Inspector répond à la question « quelles CVE m’affectent ? », Patch Manager répond à « quels correctifs manquent et comment les installer en toute sécurité ? »

Patch Manager fonctionne via des référentiels de correctifs (patch baselines) — des règles déclaratives qui définissent quels correctifs sont approuvés, en fonction de leur classification (Sécurité, Critique, Correctif de bug), de leur sévérité et d’un délai d’approbation automatique (par exemple, approuver les correctifs de sécurité sept jours après leur publication pour garantir la stabilité du fournisseur). AWS fournit des référentiels par défaut pour chaque OS (AWS-AmazonLinux2DefaultPatchBaseline, AWS-WindowsPredefinedPatchBaseline, etc.), mais les parcs en production utilisent généralement des référentiels personnalisés liés à des groupes de correctifs (patch groups) via le tag Patch Group sur les instances.

Un flux de travail typique d’analyse et d’application de correctifs utilise deux opérations :

Scan : signale la conformité sans rien installer ; les résultats apparaissent dans le tableau de bord de conformité de Patch Manager et dans Config.
Install : applique les correctifs approuvés et, pour de nombreux OS, redémarre.

Ces opérations sont généralement planifiées via des fenêtres de maintenance (maintenance windows) avec une cible de document AWS-RunPatchBaseline. Pour les scénarios urgents de type « zero-day », Patch Manager propose Patch Now, une action à la demande qui contourne le calendrier des fenêtres de maintenance. Le modèle recommandé consiste à créer un référentiel de correctifs restreint qui approuve uniquement le KB ou le paquetage spécifique corrigeant la vulnérabilité, à cibler le groupe de correctifs affecté, à exécuter Patch Now, et à diffuser le flux de sortie d’exécution vers un bucket S3 central et un groupe CloudWatch Logs. Ce journal centralisé devient votre artefact d’audit — la preuve de la remédiation pour les auditeurs ou la réponse aux incidents.

Problème Pratique : Scénario de Cas d’Usage

Scénario : Meridian Financial exploite un environnement AWS multi-comptes avec plusieurs centaines d’instances EC2 (Windows et Amazon Linux) et un petit cluster EKS supportant des services destinés aux clients. Ils utilisent AWS Organizations, AWS Systems Manager pour l’outillage opérationnel, et maintiennent des AMI dans un compte d’images partagé, mais ne disposent pas d’une analyse de vulnérabilités automatisée et cohérente ni de déploiements de correctifs coordonnés entre les comptes.

Défi : Une CVE publique affectant OpenSSL est publiée et Amazon Inspector signale des résultats élevés sur plusieurs instances, mais l’application des correctifs a été inégale et un service de production a subi une brève tentative d’exploitation en raison d’une remédiation tardive.

Approche Recommandée :

Activer Amazon Inspector sur tous les comptes et régions pour effectuer des analyses de vulnérabilités à la fois sur les images et les instances en cours d’exécution, et transférer les résultats de haute sévérité vers AWS Security Hub et un bus d’événements personnalisé EventBridge.
Utiliser AWS Systems Manager Inventory pour identifier les instances impactées et les taguer par criticité ; créer un référentiel de correctifs Patch Manager qui inclut les correctifs OpenSSL requis et cibler les règles Windows/Linux.
Créer une règle EventBridge qui déclenche un document SSM Automation lorsque les résultats d’Inspector atteignent une sévérité définie, en passant la liste des ID d’instance à un runbook Automation qui invoque Patch Manager ou Run Command pour appliquer les correctifs et redémarrer si nécessaire.
Pour les services avec état ou à haut risque, orchestrer des mises à jour progressives en utilisant EC2 Image Builder pour intégrer les correctifs dans les AMI, mettre à jour les groupes Auto Scaling ou les groupes de nœuds EKS avec un déploiement contrôlé de type bleu/vert ou progressif, et vérifier la santé du service avec les vérifications de santé de Route 53/ALB.
Après la remédiation, ré-exécuter Amazon Inspector pour valider que les résultats sont résolus, mettre à jour les rapports de conformité SSM et envoyer un résumé à l’équipe de sécurité via SNS ; conserver le runbook Automation dans une bibliothèque Systems Manager Automation pour une réponse reproductible à l’échelle du parc.

Justification : Cette approche utilise Amazon Inspector pour la découverte continue, Systems Manager Patch Manager et Automation pour une remédiation contrôlée et automatisée, et des reconstructions basées sur des images pour une infrastructure immuable, s’alignant sur les meilleures pratiques AWS pour la détection, la réponse automatisée et un rayon d’impact minimal.

# Example: focused baseline for an urgent CVE
Name: emergency-openssl-cve
OperatingSystem: AMAZON_LINUX_2
ApprovalRules:
  PatchRules:
    - PatchFilterGroup:
        PatchFilters:
          - Key: PRODUCT
            Values: [AmazonLinux2]
          - Key: CVE_ID
            Values: [CVE-2024-XXXXX]
      ApproveAfterDays: 0
      ComplianceLevel: CRITICAL

La conformité centralisée est activée en configurant le compte administrateur délégué dans Systems Manager Explorer et en activant la synchronisation des données de ressources (resource data sync) pour agréger l’état de conformité des correctifs de chaque compte dans un unique bucket S3, qui peut ensuite être interrogé avec Athena ou visualisé dans QuickSight.

Session Manager pour une Administration Auditable

L’accès traditionnel basé sur SSH présente trois faiblesses structurelles : des clés à longue durée de vie se trouvent sur les ordinateurs portables des opérateurs, le port 22 doit être accessible (même si ce n’est que via un bastion), et l’activité du shell n’est pas enregistrée de manière centralisée sans outillage supplémentaire. Session Manager élimine ces trois faiblesses.

Session Manager établit un tunnel pour un shell interactif via la connexion HTTPS sortante de l’agent SSM vers les points de terminaison SSM. Il n’y a pas de port entrant, pas de paire de clés SSH, et pas de bastion. L’accès est autorisé par des politiques IAM (ssm:StartSession avec une portée définie par tag d’instance ou ARN), et chaque session peut être journalisée dans CloudWatch Logs ou S3, avec un chiffrement KMS en option. Sur Linux, les sessions s’exécutent par défaut en tant que ssm-user ; le comportement de sudo est contrôlé par la configuration sudoers de l’instance, et non par IAM.

Le modèle de renforcement correct pour les nouveaux parcs est le suivant : lancer des instances sans paire de clés EC2, attacher un profil d’instance avec AmazonSSMManagedInstanceCore, placer les instances dans des sous-réseaux privés avec des points de terminaison VPC pour ssm, ssmmessages, et ec2messages, et imposer la journalisation des sessions au niveau des préférences de Session Manager. Continuer à distribuer des clés SSH en parallèle de Session Manager est le piège : cela préserve la surface d’attaque même que Session Manager a été adopté pour éliminer, et cela laisse un canal d’accès non journalisé. Supprimez le provisionnement de authorized_keys de votre processus de création d’AMI.

Télémétrie de l’hôte avec l’agent CloudWatch

L’agent unifié CloudWatch collecte les métriques au niveau du système d’exploitation (mémoire, disque, CPU par processus) et les fichiers journaux que l’hyperviseur EC2 ne peut pas voir. Il est configuré via un fichier JSON généralement stocké dans Parameter Store, puis appliqué avec amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:AmazonCloudWatch-linux.

L’échec opérationnel le plus courant avec l’agent est le manque de permissions IAM sur le profil d’instance. L’agent a besoin, au minimum, de :

logs:CreateLogGroup (sauf si le groupe est pré-créé)
logs:CreateLogStream
logs:PutLogEvents
logs:DescribeLogStreams
cloudwatch:PutMetricData (pour les métriques personnalisées)
ssm:GetParameter (pour récupérer la configuration depuis Parameter Store)

La politique gérée CloudWatchAgentServerPolicy regroupe ces permissions. Lorsque les permissions sont manquantes, l’agent démarre avec succès et semble sain dans systemctl status, mais les journaux n’arrivent jamais dans CloudWatch — les échecs ne sont visibles que dans /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log. Toute conception de sécurité de l’hôte qui repose sur des journaux centralisés doit valider la livraison, et pas seulement l’état de l’agent.

Synthèse

La boucle de défense est la suivante : Inspector découvre des CVE sur les hôtes et les images de conteneurs, les résultats (findings) sont transmis à Security Hub pour agrégation, Patch Manager effectue la remédiation via des fenêtres de maintenance planifiées ou via Patch Now pour les urgences, Session Manager fournit la seule voie d’accès administratif, et l’agent CloudWatch diffuse à la fois les preuves de patching et les journaux d’exécution vers un compte centralisé. Chaque contrôle suppose l’existence des autres : Inspector sans Patch Manager produit des rapports auxquels personne ne donne suite ; Patch Manager sans journalisation centralisée ne produit aucune piste d’audit ; Session Manager sans permissions IAM appropriées laisse soit trop, soit trop peu d’accès ; et l’agent CloudWatch sans les bonnes permissions de journalisation produit l’illusion de la visibilité.

← Gouvernance · Tous les domaines · Sécurité des conteneurs et serverless →

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 →