Amazon SCS-C02: Détection des menaces et alertes — 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.

Centralisation de GuardDuty au sein d’une organisation

Amazon GuardDuty est un service de détection des menaces en continu qui analyse les événements de gestion et de données de CloudTrail, les logs de flux VPC, les logs de requêtes DNS, les logs d’audit EKS, l’activité de connexion RDS et la télémétrie d’exécution. Il produit des résultats (findings) classés par objectif de la menace (Backdoor, CryptoCurrency, Recon, UnauthorizedAccess, PenTest, Policy, Stealth, Trojan, Impact) et par type de ressource (EC2, IAMUser, S3, Kubernetes, RDS, Lambda, Runtime).

L’exploitation de GuardDuty compte par compte n’est pas une solution évolutive. L’architecture correcte dans un environnement AWS Organizations consiste à désigner un administrateur délégué — généralement le compte dédié à la sécurité ou à l’audit — en utilisant le compte de gestion de l’organisation. Depuis l’administrateur délégué, vous activez GuardDuty à l’échelle de l’organisation et basculez sur l’activation automatique (auto-enable) afin que les nouveaux comptes membres et les nouvelles régions soient protégés automatiquement dès leur création. Sans l’activation automatique, un compte nouvellement provisionné reste sans visibilité jusqu’à ce qu’un opérateur active manuellement la détection, ce qui est exactement la faille que les attaquants exploitent lors de l’intégration.

Problème pratique : Scénario d’utilisation

Scénario : Meridian Financial gère un environnement AWS multi-comptes réparti sur 28 comptes pour la production, le développement et les services partagés. Leur compte de gestion gouverne les comptes via AWS Organizations, avec une journalisation centralisée de CloudTrail et S3, mais les alertes de sécurité et les données d’investigation sont dispersées entre les comptes membres, ce qui rend le triage des incidents lent et incohérent.

Défi : Une récente détection de mouvement latéral dans un compte a produit des résultats GuardDuty qui n’étaient pas visibles assez rapidement par les outils centraux du SOC, retardant le confinement et l’investigation forensique.

Approche recommandée :

Désigner un administrateur GuardDuty délégué dans le compte de gestion et activer GuardDuty dans toute l’organisation via AWS Organizations afin que tous les comptes membres transfèrent les résultats vers un détecteur central.
Activer AWS Security Hub de manière centralisée dans le compte de gestion en tant qu’agrégateur et activer Security Hub pour tous les comptes et régions afin de normaliser les résultats de GuardDuty ainsi que d’autres standards de sécurité.
Configurer des règles Amazon EventBridge dans le compte de gestion pour capturer les résultats de GuardDuty et de Security Hub et les acheminer vers des cibles centralisées telles qu’Amazon SNS pour l’envoi d’alertes, Amazon Kinesis Data Firehose vers S3 pour l’archivage, ou une livraison directe à votre SIEM.
Déployer des répondeurs Lambda déclenchés par EventBridge pour des actions de confinement automatisées (par exemple, isoler une instance EC2 via l’API EC2 et créer un incident AWS Systems Manager) et étiqueter les résultats pour investigation.
Intégrer Amazon Detective pour une investigation centralisée et transférer les résultats archivés dans S3 vers votre solution d’analytique/SIEM pour une corrélation et un reporting à long terme.

Justification : L’utilisation d’un administrateur GuardDuty délégué avec Security Hub et EventBridge centralise la détection, normalise les alertes et permet des réponses automatisées et auditables conformément aux meilleures pratiques AWS pour la détection des menaces à l’échelle de l’organisation et une réponse aux incidents en temps opportun.

# From the Organizations management account
aws organizations enable-aws-service-access \
  --service-principal guardduty.amazonaws.com

aws guardduty enable-organization-admin-account \
  --admin-account-id 111122223333

# From the delegated admin
aws guardduty update-organization-configuration \
  --detector-id abc123 \
  --auto-enable-organization-members ALL \
  --features '[{"Name":"RDS_LOGIN_EVENTS","AutoEnable":"NEW"},
               {"Name":"EKS_AUDIT_LOGS","AutoEnable":"NEW"},
               {"Name":"RUNTIME_MONITORING","AutoEnable":"NEW"}]'

GuardDuty est un service régional, donc la relation d’administrateur délégué et les paramètres d’activation automatique doivent être établis dans chaque région où vous opérez. C’est une source fréquente d’angles morts — une équipe active GuardDuty dans us-east-1 et suppose une couverture mondiale.

Protections spécifiques aux services

La version de base de GuardDuty couvre les sources de données fondamentales, mais plusieurs plans de protection doivent être explicitement activés car ils ajoutent des coûts et une ingestion de télémétrie supplémentaire :

RDS Protection : profile l’activité de connexion aux moteurs Aurora MySQL/PostgreSQL et RDS, générant des résultats tels que CredentialAccess:RDS/AnomalousBehavior.SuccessfulLogin lorsque des utilisateurs inconnus s’authentifient sur un point de terminaison de base de données. C’est la source correcte pour détecter les connexions suspectes à la base de données — ne construisez pas de filtres de métriques CloudWatch personnalisés sur les journaux d’audit de la base de données alors que RDS Protection émet déjà le résultat de manière native.
EKS Protection : ingère les journaux d’audit de Kubernetes pour détecter les accès anormaux à l’API, la création de pods privilégiés et l’utilisation de tableaux de bord exposés.
Runtime Monitoring : déploie un agent léger basé sur eBPF sur EC2, ECS/Fargate ou EKS pour faire remonter les événements de processus, de fichiers et de réseau — nécessaire pour détecter les logiciels malveillants sans fichier ou les shells inversés au moment de l’exécution.
Malware Protection : analyse par snapshot les volumes EBS attachés aux instances signalées par d’autres résultats, ou effectue des analyses à la demande des objets S3 lors de leur mise en ligne.
Lambda Protection et S3 Protection : couvrent respectivement les modèles d’invocation de fonctions et l’accès au plan de données S3.

Activer uniquement le service de base et s’attendre à ce que des anomalies de connexion à la base de données apparaissent est une erreur de configuration courante — les types de résultats ne sont tout simplement pas produits tant que la fonctionnalité correspondante n’est pas activée.

Security Hub comme plan d’agrégation

Security Hub ingère les résultats de GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config, Health et de produits ISV tiers, en les normalisant au format AWS Security Finding Format (ASFF). Il exécute également ses propres standards de conformité (AWS Foundational Security Best Practices, CIS, PCI DSS, NIST 800-53).

Pour centraliser au sein d’une Organization :

Activez Security Hub en tant que service dans Organizations et désignez un administrateur délégué (généralement le même compte de sécurité que pour GuardDuty).
Activez l’activation automatique pour les nouveaux comptes afin que les membres soient enrôlés automatiquement.
Configurez une région d’agrégation des résultats (également appelée région d’origine ou “home Region”) et liez-y toutes les autres régions. Sans agrégation inter-régions, chaque région conserve une instance Security Hub indépendante et les analystes doivent pivoter entre les consoles.

Le modèle pour un déploiement organisationnel global nécessite donc deux paramètres coordonnés : la liaison de la région d’agrégation et le commutateur d’activation automatique à l’échelle de l’organisation. Activer l’un sans l’autre laisse soit les nouveaux comptes non couverts, soit les nouvelles régions cloisonnées.

Une limitation importante : Security Hub agrège et priorise mais ne corrige pas. Le considérer comme une plateforme de correction est une erreur de catégorie — la correction se produit en aval via EventBridge.

EventBridge comme tissu d’automatisation

GuardDuty et Security Hub publient tous deux des résultats sur le bus d’événements par défaut. aws.guardduty émet des événements GuardDuty Finding, et aws.securityhub émet des événements Security Hub Findings - Imported (créés/mis à jour par Hub) et Security Hub Findings - Custom Action (déclenchés par un opérateur).

Des règles trop larges telles que {"source": ["aws.securityhub"]} invoquent des cibles à chaque mise à jour de résultat de chaque fournisseur, inondant rapidement les sujets SNS et alertant les ingénieurs d’astreinte avec du bruit informationnel. L’approche correcte consiste à filtrer sur les valeurs severity.Label, ProductArn, Types ou des Title spécifiques :

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{ "numeric": [">=", 7] }],
    "type": [{ "prefix": "CredentialAccess:RDS/" }]
  }
}

Pour un modèle centré sur Security Hub qui ne se déclenche que sur les résultats GuardDuty de haute sévérité tout en ignorant les produits ISV tiers bruyants :

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["HIGH", "CRITICAL"] },
      "ProductArn": [
        { "wildcard": "arn:aws:securityhub:*::product/aws/guardduty" }
      ],
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

Les cibles courantes incluent un sujet SNS pour les notifications par e-mail/SMS/Slack, une fonction Lambda qui isole une instance en changeant son groupe de sécurité, un runbook SSM Automation, ou une machine à états Step Functions orchestrant une réponse en plusieurs étapes. Pour le cas d’usage de l’anomalie de connexion Aurora, le chemin le plus simple est : GuardDuty RDS Protection → règle EventBridge filtrée sur le type de résultat RDS → sujet SNS avec un abonnement par e-mail. Aucun polling personnalisé, aucune fonction Lambda, aucun SIEM tiers n’est requis.

Actions personnalisées de Security Hub

Les actions personnalisées sont des déclencheurs pilotés par un opérateur. Dans la console Security Hub, un analyste sélectionne un ou plusieurs résultats et choisit une action personnalisée (par exemple, “Quarantine EC2”). Security Hub émet un événement Security Hub Findings - Custom Action transportant les ARN des résultats sélectionnés ; une règle EventBridge correspond à l’ARN de l’action personnalisée et invoque une fonction Lambda qui exécute la réponse. Cela vous donne un bouton pour une intervention humaine (“human-in-the-loop”) sans avoir à construire une interface utilisateur sur mesure :

aws securityhub create-action-target \
  --name "Quarantine EC2" \
  --description "Attach isolation SG and snapshot volumes" \
  --id QuarantineEC2

L’ARN résultant (arn:aws:securityhub:us-east-1:111122223333:action/custom/QuarantineEC2) devient la valeur de correspondance dans le champ resources de la règle EventBridge.

Suppression et gestion du signal

La gestion du bruit est une discipline, pas un filtre ponctuel. Utilisez les règles d’automatisation de Security Hub ou les règles de suppression de GuardDuty pour archiver automatiquement les résultats connus comme étant bénins (par exemple, un résultat Recon:EC2/Portscan attendu d’un outil de test d’intrusion). Filtrez les règles EventBridge par ProductArn pour rendre silencieuse une intégration tierce bavarde sans la désactiver complètement. Combinez Severity.Label avec Workflow.Status = NEW pour que les résultats rouverts ou déjà notifiés ne génèrent pas de nouvelles alertes. L’objectif est que chaque alerte parvenant à un humain représente un événement exploitable et de haute confiance — tout le reste érode la capacité de réaction.

Pivot d’investigation

Lorsqu’un résultat de haute sévérité se déclenche — par exemple, Backdoor:EC2/C&CActivity.B!DNS — le chemin d’investigation le plus rapide n’est pas d’écrire manuellement des requêtes Athena sur CloudTrail et les VPC Flow Logs. Amazon Detective, lorsqu’il est activé en même temps que GuardDuty, pré-construit des graphes d’entités à partir de CloudTrail, des VPC Flow Logs et des résultats de GuardDuty. Pivoter depuis le résultat directement vers le rôle IAM ou le profil d’instance EC2 dans Detective fait apparaître l’activité API, les pairs réseau (“network peers”), et les décomptes de connexions réussies par rapport aux connexions échouées sur la période pertinente, sans aucun travail de requête personnalisée.

← Gestion de l’identité et des accès · Tous les domaines · Journalisation →

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