ExamRoll
French
EnglishFrenchSpanishDeutschPortuguese (Brazil)ItalianDutchPolishRussianTurkishJapaneseKoreanChinese SimplifiedChinese TraditionalPortuguese (Portugal)CzechIndonesianSlovakThaiVietnameseSwedish
Réussissez votre examen →

Amazon SCS-C02: Sécurité des conteneurs et serverless — Guide d'étude

By Laurynas Brazys · · #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.

ECS Exec et inspection d’exécution sans SSH

ECS Exec fournit un shell interactif dans un conteneur en cours d’exécution — y compris pour les tâches Fargate — sans exposer de SSH, de bastions ou d’adresses IP publiques. Il fonctionne en s’appuyant sur l’agent SSM qu’AWS injecte dans l’environnement d’exécution sidecar de la tâche. Comme il n’y a pas de démon SSH, pas de matériel de clé et pas de chemin réseau entrant à sécuriser, la charge opérationnelle est minimale et chaque session est auditable via CloudTrail et (en option) consignée dans S3 ou CloudWatch Logs.

Trois conditions doivent toutes être remplies pour qu’ECS Exec fonctionne :

Un flux d’inspection typique ressemble à ceci :

aws ecs update-service --cluster prod --service api \
  --enable-execute-command --force-new-deployment

aws ecs execute-command --cluster prod \
  --task 5f8c...c2 --container api \
  --interactive --command "/bin/sh"

Depuis ce shell, un ingénieur peut copier des journaux vers S3, déclencher un vidage de tas (heap dump) ou lire /proc pour une analyse forensique. L’alternative — tenter d’atteindre le conteneur via SSH ou redémarrer la tâche pour activer un agent de débogage — échoue sur Fargate ou détruit les preuves que vous essayiez de collecter.

Blocage de l’accès à l’IMDS depuis les conteneurs sur EC2

Une idée fausse courante est que les paramètres de limite de sauts (hop-limit) de l’IMDSv2 sur l’instance EC2 protègent les conteneurs sur cette instance. Ce n’est pas le cas, du moins pas par défaut en mode réseau pont (bridge) ou hôte (host) : les conteneurs partagent l’espace de noms réseau de l’hôte ou un pont NAT et peuvent atteindre 169.254.169.254 et récupérer les informations d’identification du profil d’instance, qui sont généralement beaucoup plus privilégiées que le rôle de tâche. Cela va totalement à l’encontre du principe de moindre privilège.

La solution, lorsqu’une migration vers Fargate n’est pas possible, comporte deux parties :

echo 'ECS_AWSVPC_BLOCK_IMDS=true' >> /etc/ecs/ecs.config
systemctl restart ecs

Combinez cela avec un profil d’instance minimal (essentiellement juste ce dont l’agent ECS a besoin : AmazonEC2ContainerServiceforEC2Role) et des rôles IAM par tâche pour les permissions applicatives. Définir la limite de sauts IMDS de l’instance à 1 avec IMDSv2 requis est une mesure de défense en profondeur utile, mais ne constitue pas un substitut — les conteneurs en mode pont peuvent toujours atteindre l’IMDS au premier saut (hop 1) car la requête provient de l’hôte.

Surveillance d’exécution GuardDuty, EKS Protection et journaux du plan de contrôle

GuardDuty propose une détection de conteneurs à plusieurs niveaux :

EKS Protection est inutile si le journal d’audit du plan de contrôle EKS n’est pas réellement émis vers CloudWatch Logs. Activez au moins les types de journaux audit et authenticator sur le cluster :

aws eks update-cluster-config --name prod \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

Sans cela, GuardDuty n’a pas de plan de données à inspecter pour les résultats d’EKS Protection — un piège qui apparaît fréquemment car les opérateurs activent la fonctionnalité GuardDuty mais laissent la configuration de journalisation du cluster désactivée, puis se demandent pourquoi aucun résultat Kubernetes n’apparaît.

Analyse d’images avec ECR Enhanced Scanning

ECR Enhanced Scanning est optimisé par Amazon Inspector et fournit une analyse continue des images de conteneurs pour les CVE du système d’exploitation et des paquets de langage (Python, Node, Java, Go, Ruby). L’analyse de base est ponctuelle au moment du push et ne couvre que les paquets du système d’exploitation ; l’analyse améliorée est continue et inclut les dépendances applicatives, là où se trouvent la plupart des vulnérabilités modernes.

Les résultats remontent automatiquement vers Security Hub lorsque les deux services sont activés, offrant une vue centralisée (single pane of glass) pour la conformité et vous permettant d’écrire des règles EventBridge qui font échouer les builds CI/CD. Un modèle d’application typique :

Problème pratique : Scénario d’utilisation

Scénario : NovaTech Corp exploite des microservices orientés client sur une infrastructure de calcul mixte : plusieurs clusters ECS sur EC2, un cluster EKS pour le traitement des données, et des fonctions Lambda serverless pour la gestion d’événements. Les images sont stockées dans ECR, les opérations utilisent SSM pour l’accès aux hôtes, et GuardDuty/CloudWatch sont activés mais la visibilité est inégale entre les conteneurs et les composants du plan de contrôle.

Défi : Un conteneur en production a montré des connexions sortantes suspectes et un ingénieur a découvert qu’un pod pouvait atteindre le service de métadonnées d’instance EC2, risquant une exfiltration d’identifiants ; des vulnérabilités dans les images et une journalisation insuffisante du plan de contrôle pourraient masquer la cause première.

Approche recommandée :

  1. Activer ECS Exec pour les tâches et exiger AWS Systems Manager Session Manager pour l’inspection de l’hôte et de l’environnement d’exécution des conteneurs (ECS Exec + SSM), éliminant le besoin de SSH et garantissant que l’activité des sessions est journalisée dans CloudTrail et CloudWatch Logs.
  2. Imposer IMDSv2 sur les instances EC2 (Instance Metadata Service HttpTokens=required, hop limit=1) et appliquer des règles réseau au niveau de l’hôte pour bloquer 169.254.169.254 depuis les espaces de noms réseau des conteneurs, afin que les conteneurs ne puissent pas interroger les métadonnées de l’instance.
  3. Activer la surveillance d’exécution (runtime monitoring) et la protection contre les malwares (Malware Protection) d’Amazon GuardDuty pour les conteneurs et Lambda, transférer les résultats (findings) à Security Hub et EventBridge pour des scénarios de confinement automatisés (playbooks).
  4. Renforcer la sécurité d’EKS en activant les journaux du plan de contrôle (audit, authenticator, controllerManager, scheduler) vers CloudWatch Logs, adopter les rôles IAM pour les comptes de service (IRSA), et mettre en œuvre des contrôles d’admission (Pod Security ou OPA Gatekeeper) pour limiter les capacités à risque.
  5. Activer l’analyse d’image améliorée d’Amazon ECR (Inspector/ECR scanning) avec l’option d’analyse lors du push (scan-on-push) et intégrer les résultats dans la CI pour bloquer/mettre en quarantaine les images via EventBridge + Lambda pour la mise en application.
  6. Centraliser la télémétrie : envoyer les journaux CloudTrail, les résultats GuardDuty, les journaux du plan de contrôle EKS et les résultats d’analyse ECR vers un pipeline centralisé S3/Lambda/Security Hub et alimenter les règles AWS Config pour une conformité continue.

Justification : Cette séquence supprime l’accès basé sur SSH, prévient le vol d’identifiants via les métadonnées, fournit une détection d’exécution et une réponse automatisée, impose une hygiène des images et offre une visibilité sur le plan de contrôle — s’alignant sur les meilleures pratiques AWS du moindre privilège, de la défense en profondeur et de l’observabilité centralisée.

# CodeBuild buildspec fragment
post_build:
  commands:
    - aws ecr describe-image-scan-findings \
        --repository-name api --image-id imageTag=$TAG \
        --query 'imageScanFindings.findingSeverityCounts' > findings.json
      CRIT=$(jq '.CRITICAL // 0' findings.json)
      if [ "$CRIT" -gt 0 ]; then echo "Critical CVEs present"; exit 1; fi

L’intégration dans le pipeline est ce qui transforme l’analyse d’un simple exercice de tableau de bord en un véritable contrôle.

Lambda : Autoriseurs, secrets et rôles d’exécution

La sécurité au niveau d’une fonction Lambda comporte trois plans qui sont fréquemment confondus :

import boto3, os, json
_ssm = boto3.client("ssm")
_cached = None

def get_db_password():
    global _cached
    if _cached is None:
        r = _ssm.get_parameter(Name=os.environ["DB_PWD_PARAM"], WithDecryption=True)
        _cached = r["Parameter"]["Value"]
    return _cached

Le rôle d’exécution a besoin des permissions ssm:GetParameter et kms:Decrypt sur la CMK. Mettez en cache dans la portée du module pour que les invocations à chaud (warm invocations) évitent l’appel API ; utilisez l’extension Lambda de Secrets Manager pour une mise en cache automatique tenant compte de la rotation dans les fonctions à plus haut débit.

Chiffrement ECR et protection des dépôts

Par défaut, Amazon ECR chiffre toutes les images au repos en utilisant AES-256 avec une clé gérée par AWS, mais les charges de travail réglementées exigent généralement une clé KMS gérée par le client (customer-managed key) afin que la rotation des clés, les politiques de clé et l’auditabilité via CloudTrail soient sous le contrôle du client. Le chiffrement KMS est configuré uniquement au moment de la création du dépôt ; un dépôt ECR existant ne peut pas être basculé d’AES-256 à KMS après sa création. La migration nécessite donc de créer un nouveau dépôt chiffré avec KMS, de répliquer ou de repousser les images, de mettre à jour les consommateurs en aval, et de supprimer l’ancien dépôt. Les consommateurs inter-comptes qui extraient (pull) depuis un dépôt chiffré par KMS doivent se voir accorder la permission kms:Decrypt sur la CMK en plus des permissions de lecture ECR, sinon l’extraction échouera avec une erreur d’accès KMS même si la politique du dépôt autorise le principal.

{
  "encryptionConfiguration": {
    "encryptionType": "KMS",
    "kmsKey": "arn:aws:kms:us-east-1:111122223333:key/abcd-...-ef01"
  },
  "imageScanningConfiguration": { "scanOnPush": true },
  "imageTagMutability": "IMMUTABLE"
}

Les balises immuables (immutable tags) empêchent les attaques de détournement de balise (tag-hijack) où une balise validée v1.2.3 est silencieusement écrasée par une image malveillante après l’analyse.

Analyse d’images : Basic, Enhanced et Inspector

ECR propose deux modes d’analyse. L’analyse de base (Basic scanning) utilise la base de données open-source de CVE Clair, s’exécute uniquement lors d’un push (ou d’un déclenchement manuel) et renvoie les résultats dans la console ECR. Elle est gratuite, mais n’effectue pas de ré-analyses en continu, ne couvre pas à la fois les paquets du système d’exploitation et ceux des langages de programmation, et n’a pas d’intégration native avec Security Hub. L’analyse améliorée (Enhanced scanning) est optimisée par Amazon Inspector et couvre à la fois les paquets du système d’exploitation et les paquets des langages applicatifs (Python, Java, Node.js, Go, Ruby, .NET). Inspector surveille en continu les images poussées en les comparant aux renseignements sur les vulnérabilités mis à jour, de sorte qu’une CVE divulguée une semaine après le push de l’image produit tout de même un résultat (finding) sans nécessiter une nouvelle construction (rebuild).

L’analyse améliorée est activée au niveau du registre (par Région), avec des filtres d’inclusion par dépôt utilisant des motifs génériques (wildcard) tels que prod-* ou team-a/*. C’est le contrôle approprié pour l’exigence courante de « scanner la plupart des dépôts mais exclure ceux de bac à sable/expérimentation » — vous définissez des filtres positifs listant ce qui doit être analysé plutôt que des exclusions négatives sur des dépôts individuels.

aws ecr put-registry-scanning-configuration \
  --scan-type ENHANCED \
  --rules '[{
    "scanFrequency": "CONTINUOUS_SCAN",
    "repositoryFilters":[{"filter":"prod-*","filterType":"WILDCARD"}]
  },{
    "scanFrequency": "SCAN_ON_PUSH",
    "repositoryFilters":[{"filter":"dev-*","filterType":"WILDCARD"}]
  }]'

Intégration d’Inspector et agrégation avec Security Hub

Amazon Inspector doit être activé dans chaque compte et Région où l’analyse est requise. Dans une configuration AWS Organizations, le compte d’outillage de sécurité est désigné comme administrateur délégué pour Inspector, ce qui lui permet d’activer l’analyse, de configurer l’inscription automatique pour les nouveaux comptes membres et de visualiser les résultats agrégés. Oublier de déléguer — ou oublier d’activer l’inscription automatique — est un mode de défaillance subtil : les nouveaux comptes rejoignant l’organisation envoient silencieusement des conteneurs vers ECR qui ne sont jamais analysés, rompant ainsi les garanties de couverture sans aucune surface d’erreur.

Les résultats d’Inspector (findings) remontent automatiquement dans AWS Security Hub lorsque les deux services sont activés et que l’intégration d’Inspector dans Security Hub est activée. Security Hub normalise ensuite les résultats au format AWS Security Finding Format (ASFF), les corrèle avec les résultats de GuardDuty, Macie et Config, et — lorsqu’il est combiné avec un administrateur délégué pour Security Hub et l’agrégation inter-régionale — présente une vue centralisée (single pane of glass). Des règles EventBridge sur les résultats de Security Hub peuvent router les CVE critiques vers Lambda pour la création automatisée de tickets, marquer l’image incriminée avec une étiquette quarantine=true, ou bloquer le déploiement via une porte de pipeline (pipeline gate).

Analyse centralisée et CI/CD inter-comptes

Le modèle recommandé pour les charges de travail de conteneurs multi-comptes place un compte de registre central renforcé au cœur de l’architecture :

L’accès en lecture inter-comptes nécessite deux niveaux : une politique IAM dans le compte consommateur accordant ecr:GetDownloadUrlForLayer, ecr:BatchGetImage et ecr:GetAuthorizationToken, plus une politique de dépôt (repository policy) sur le dépôt ECR dans le compte central autorisant le compte ou le rôle consommateur spécifique.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowProdPull",
    "Effect": "Allow",
    "Principal": {"AWS":"arn:aws:iam::444455556666:role/EcsTaskExecutionRole"},
    "Action": ["ecr:BatchGetImage","ecr:GetDownloadUrlForLayer"]
  }]
}

Comme les politiques de dépôt ECR sont basées sur les ressources, l’intersection de la politique d’identité et de la politique de ressource détermine l’accès — l’omission de l’un ou l’autre niveau produit une AccessDeniedException. Lorsque KMS est impliqué, la politique de la clé KMS doit également accorder kms:Decrypt au principal inter-comptes.

Journalisation et observabilité du plan de contrôle EKS

Pour EKS, le plan de contrôle géré n’est pas directement accessible, donc les événements Kubernetes pertinents pour la sécurité ne sont exposés que lorsque la journalisation du plan de contrôle est explicitement activée. Cinq types de journaux sont disponibles : api, audit, authenticator, controllerManager et scheduler. Le journal audit est l’artefact de sécurité le plus précieux — il enregistre chaque appel d’API au cluster avec l’identité de l’appelant résolue via l’authentificateur IAM — et le journal authenticator enregistre les décisions de mappage entre IAM et le RBAC de Kubernetes. Tous les types sont diffusés vers CloudWatch Logs dans un groupe de journaux /aws/eks/<cluster>/cluster, à partir duquel ils peuvent être souscrits par Kinesis Data Firehose, transférés vers S3 ou expédiés vers un SIEM.

aws eks update-cluster-config --name prod-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator",
  "controllerManager","scheduler"],"enabled":true}]}'

Complétez les journaux du plan de contrôle avec GuardDuty EKS Protection (détection des menaces à l’exécution sur les nœuds) et utilisez IRSA (IAM Roles for Service Accounts) plutôt que les profils d’instance de nœud afin que les journaux d’audit attribuent l’activité de l’API AWS à des pods spécifiques.

Pièges courants

Se fier uniquement à l’analyse au moment du push (scan-on-push) : L’analyse de base au moment du push détecte les vulnérabilités connues à ce moment-là, mais n’agit pas sur les CVE divulguées ultérieurement contre des images déjà présentes dans le registre. Les cadres d’audit tels que PCI DSS et FedRAMP exigent une évaluation continue des vulnérabilités, ce qui impose une analyse améliorée avec une fréquence CONTINUOUS_SCAN ainsi qu’une agrégation dans Security Hub. Un instantané ponctuel au moment du push ne satisfait pas ce contrôle.

Ignorer KMS sur ECR lorsque le chiffrement au repos est requis : Le chiffrement AES-256 par défaut est un chiffrement réel, mais les régimes de conformité qui exigent des clés gérées par le client, des enregistrements de rotation des clés et des pistes d’audit kms:Decrypt par principal ne peuvent pas être satisfaits par des clés appartenant à AWS. Comme le type de chiffrement est immuable par dépôt, ce point doit être traité lors de la création — l’approche « nous l’activerons plus tard » est impossible sans recréer le dépôt.

Oublier l’administrateur délégué d’Inspector ou l’inscription automatique : Sans un administrateur délégué pour Inspector, chaque propriétaire de compte doit activer indépendamment l’analyse et transférer les résultats, ce qui est opérationnellement irréalisable et crée des lacunes de couverture. Sans l’activation automatique pour les nouveaux comptes membres, chaque nouveau compte créé via Control Tower ou Organizations démarre avec Inspector désactivé, de sorte que ses images ECR ne sont pas analysées, même si Security Hub dans le compte central n’affiche aucun résultat — un faux négatif silencieux plutôt qu’une erreur évidente.

Problème pratique : Scénario d’utilisation

Scénario : Meridian Financial exploite un environnement AWS multi-comptes avec des clusters EKS de production, des services ECS et plusieurs registres ECR répartis entre les comptes de production, de développement et un compte de sécurité dédié. Leurs équipes d’ingénierie poussent des images de conteneurs via des pipelines CI/CD dans ECR et les déploient sur EKS/ECS, tandis que la sécurité maintient un compte centralisé pour la surveillance et la conformité.

Défi : Un déploiement récent a livré un conteneur avec une vulnérabilité de haute sévérité qui n’a pas été détectée avant la production, et les enquêteurs ont trouvé des journaux du plan de contrôle EKS limités et des résultats d’analyse fragmentés entre les comptes, ce qui a ralenti la remédiation.

Approche recommandée :

  1. Activer les protections au niveau du dépôt ECR : imposer l’immuabilité des tags d’image, appliquer des politiques de dépôt limitant le push/pull à des rôles IAM spécifiques, et chiffrer les dépôts au repos avec une clé gérée par le client (CMK) AWS KMS dédiée.
  2. Activer l’analyse d’images au moment du push (de base) et activer l’analyse d’images améliorée d’Amazon Inspector pour ECR afin de produire des résultats de vulnérabilité ; intégrer Inspector avec AWS Security Hub pour une agrégation centralisée des sévérités entre les comptes.
  3. Mettre en œuvre une analyse centralisée inter-comptes : configurer la réplication ECR ou accorder à un rôle CodeBuild/CodePipeline du compte de sécurité des autorisations de pull inter-comptes afin que le compte de sécurité analyse chaque image avec Inspector et tout outil SCA/DAST supplémentaire, en stockant les artefacts dans un compartiment S3 centralisé chiffré avec la CMK du compte de sécurité.
  4. Mettre en place un contrôle de passage (gating) CI/CD : ajouter une étape d’analyse dans le pipeline (CodeBuild/CodePipeline ou GitHub Actions avec STS assume-role) qui interroge les résultats d’Inspector/Security Hub et bloque automatiquement ou exige une approbation pour les images présentant des résultats de sévérité élevée/critique.
  5. Améliorer l’observabilité d’EKS : activer les journaux du plan de contrôle EKS (API, Audit, Authenticator, ControllerManager, Scheduler) vers CloudWatch Logs dans un compte de journalisation centralisé, activer CloudTrail pour les événements de l’API EKS, et utiliser Container Insights et GuardDuty pour la surveillance d’exécution (runtime).

Justification : Cette approche applique la défense en profondeur : chiffrer et protéger les registres, automatiser l’analyse améliorée avec Inspector, centraliser les résultats dans Security Hub pour une application cohérente des politiques, contrôler les déploiements dans le CI/CD, et activer les journaux du plan de contrôle EKS pour une détection et une investigation rapides, en s’alignant sur les meilleures pratiques AWS de moindre privilège et de surveillance centralisée.

← Vulnérabilités · Tous les domaines · Réponse aux incidents et analyse forensique →

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 →

Related guides

Accès tout-en-un

Un seul abonnement. Chaque examen.

Chaque plan débloque la recherche de réponses illimitée, les tests pratiques, les explications IA et la bibliothèque complète de ressources — en plus de 20 langues.

Mensuel
€24.87
Just €0.83/day
Tout inclus :
  • ✓Recherche de réponses illimitée
  • ✓Tests pratiques illimités
  • ✓Explications basées sur l'IA
  • ✓Bibliothèque complète de ressources
  • ✓Plus de 20 langues
  • ✓Mises à jour de contenu hebdomadaires
  • ✓Récompenses et parrainages
  • ✓Support prioritaire
Commencer l'essai gratuit

Aucune carte de crédit requise*

Le plus populaire
6 mois
€119.87
Just €0.66/daySave 20%
Tout inclus :
  • ✓Recherche de réponses illimitée
  • ✓Tests pratiques illimités
  • ✓Explications basées sur l'IA
  • ✓Bibliothèque complète de ressources
  • ✓Plus de 20 langues
  • ✓Mises à jour de contenu hebdomadaires
  • ✓Récompenses et parrainages
  • ✓Support prioritaire
Commencer l'essai gratuit

Aucune carte de crédit requise*

Meilleur rapport qualité/prix
12 mois
€179.87
Just €0.49/daySave 40%
Tout inclus :
  • ✓Recherche de réponses illimitée
  • ✓Tests pratiques illimités
  • ✓Explications basées sur l'IA
  • ✓Bibliothèque complète de ressources
  • ✓Plus de 20 langues
  • ✓Mises à jour de contenu hebdomadaires
  • ✓Récompenses et parrainages
  • ✓Support prioritaire
Commencer l'essai gratuit

Aucune carte de crédit requise*

✓ Plan gratuit inclus · ✓ Annulez à tout moment · ✓ Tous les plans débloquent le produit complet