Amazon SCS-C02: Journalisation, audit et analyse forensique — 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.

Détections et remédiation Amazon GuardDuty

GuardDuty est un service géré de détection des menaces qui ingère en continu trois flux de télémétrie en arrière-plan : les événements de gestion CloudTrail (et éventuellement les événements de données S3), les VPC Flow Logs et les journaux de requêtes DNS de Route 53. Vous n’avez pas besoin d’activer, de livrer ou de payer séparément pour ces sources de journaux afin que GuardDuty les consomme — le service lit directement un flux dupliqué. C’est pourquoi GuardDuty peut être activé avec un seul appel d’API et commencer à générer des détections (findings) en quelques minutes, sans aucune ingénierie de pipeline de journaux.

Les détections ont une valeur de gravité comprise entre 0,1 et 8,9, correspondant à Faible (0,1–3,9), Moyenne (4,0–6,9) et Élevée (7,0–8,9). Les détections typiques nécessitant une action incluent UnauthorizedAccess:EC2/SSHBruteForce, Backdoor:EC2/C&CActivity.B!DNS, CryptoCurrency:EC2/BitcoinTool.B et Recon:IAMUser/MaliciousIPCaller. Les modèles de remédiation varient selon la détection : une compromission basée sur EC2 justifie généralement d’isoler l’instance avec un groupe de sécurité de quarantaine, de créer des snapshots des volumes pour l’analyse forensique, et de la terminer ; une détection basée sur IAM nécessite d’effectuer une rotation des clés d’accès et d’examiner l’activité CloudTrail récente du principal.

Pour les environnements multi-comptes, activez GuardDuty via AWS Organizations et désignez un compte administrateur délégué (généralement le compte d’outillage de sécurité). L’administrateur délégué peut activer automatiquement GuardDuty dans chaque compte membre existant et nouveau, dans chaque région où le service est activé. Sans la configuration de l’administrateur délégué, les détections GuardDuty par compte restent isolées dans chaque membre — l’activation individuelle des détecteurs ne les agrège pas de manière centralisée.

AWS Security Hub et agrégation multi-comptes

Security Hub est la couche de normalisation et d’agrégation. Il ingère les détections de GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config et de dizaines de produits partenaires, les convertissant au format AWS Security Finding Format (ASFF). Il exécute également ses propres contrôles par rapport à des standards tels que CIS AWS Foundations, AWS Foundational Security Best Practices, PCI DSS et NIST 800-53.

L’agrégation multi-comptes et multi-régions fonctionne de la même manière que pour GuardDuty : enregistrez Security Hub auprès de l’administrateur délégué d’Organizations, puis désignez une région d’agrégation afin que les détections des autres régions se répliquent dans ce panneau unique. Une erreur courante est d’activer Security Hub dans chaque compte et de s’attendre à une vue consolidée — sans l’administrateur délégué et la région d’agrégation, chaque compte ne voit toujours que ses propres détections.

Security Hub n’envoie pas d’e-mails lui-même. Les notifications et les automatisations sont construites en faisant correspondre les événements de détection de Security Hub sur le bus d’événements par défaut d’EventBridge et en les transmettant à des documents SNS, Lambda, Step Functions ou Systems Manager Automation.

CloudTrail : Événements de gestion vs Événements de données

CloudTrail enregistre deux catégories d’activité, et les confondre est la lacune la plus courante en matière de couverture de détection.

Événements de gestion : opérations du plan de contrôle — RunInstances, CreateBucket, AttachRolePolicy, PutBucketAcl. Activés par défaut sur tout nouveau journal de suivi (trail).
Événements de données : opérations à haut volume au niveau des ressources — appels au niveau des objets S3 (GetObject, PutObject, DeleteObject, PutObjectAcl), l’appel Invoke de Lambda, les appels d’API au niveau des éléments DynamoDB. Désactivés par défaut et facturés séparément.

Si une exigence de sécurité est de « détecter quand quelqu’un rend un objet S3 public via PutObjectAcl », un journal de suivi (trail) d’événements de gestion simple ne le capturera pas car les changements d’ACL sur des objets individuels sont des événements de données. De même, une sortie de données (GetObject) d’un compartiment sensible est invisible sans les événements de données. PutBucketAcl (au niveau du compartiment) est un événement de gestion et serait journalisé ; PutObjectAcl (au niveau de l’objet) ne l’est pas.

Utilisez un journal de suivi d’organisation (organization trail) créé dans le compte de gestion ou le compte administrateur délégué afin que les événements de chaque compte membre soient capturés dans un seul compartiment S3 et ne puissent pas être désactivés par les principaux des comptes membres. Protégez le journal de suivi avec :

Le chiffrement SSE-KMS sur le compartiment de destination, avec une politique de clé KMS qui refuse le déchiffrement non autorisé.
Une politique de compartiment qui refuse s3:PutObject sans le principal de service CloudTrail et qui refuse la suppression.
La validation de l’intégrité des fichiers journaux activée, qui produit des fichiers de synthèse (digest) horaires signés avec SHA-256 afin que toute falsification puisse être prouvée.

Exemple de création :

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name central-ct-logs \
  --is-organization-trail \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

aws cloudtrail put-event-selectors \
  --trail-name org-trail \
  --event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":true,
                       "DataResources":[{"Type":"AWS::S3::Object",
                                         "Values":["arn:aws:s3:::sensitive-bucket/"]}]}]'

Alertes EventBridge et SNS

EventBridge est la structure de routage qui connecte les détections aux intervenants humains et automatisés. Chaque détection GuardDuty, chaque mise à jour de détection Security Hub et chaque événement dérivé de CloudTrail arrive sur le bus d’événements par défaut. Les règles utilisent des modèles d’événements (event patterns) JSON pour filtrer, puis distribuer (fan out) vers une ou plusieurs cibles (SNS, Lambda, SQS, Kinesis Data Firehose, Step Functions, Systems Manager).

Un modèle canonique pour les détections GuardDuty de haute gravité, transmises à la fois à un sujet SNS pour les e-mails et à un flux de livraison Firehose alimentant OpenSearch pour l’analyse :

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

Pour les détections CRITICAL de Security Hub acheminées par e-mail :

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["CRITICAL"] },
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

Le point de terminaison de l’e-mail est un simple abonnement SNS ; l’abonné doit confirmer via le lien envoyé par e-mail avant que la livraison ne commence. Une seule règle peut avoir jusqu’à cinq cibles, de sorte que les alertes et l’analyse en aval ne nécessitent pas de règles en double.

Lors de la création de modèles, n’oubliez pas que les événements de gestion CloudTrail arrivent avec "detail-type": "AWS API Call via CloudTrail", tandis que les événements de données n’apparaissent pas sur le bus par défaut, sauf si vous configurez un journal de suivi qui publie vers CloudWatch Logs et utilisez un filtre de métrique ou vous abonnez via l’intégration des événements de données CloudTrail d’EventBridge. Écrire une règle EventBridge correspondant à "eventName": "PutObjectAcl" sur le bus par défaut sans activer les événements de données ne produira aucune correspondance.

CloudWatch Logs, Insights, Filtres de métriques et Alarmes

L’envoi des journaux CloudTrail (ainsi que des VPC Flow Logs et des journaux d’application) vers CloudWatch Logs permet une détection quasi en temps réel. Les filtres de métriques (Metric filters) analysent chaque événement de journal entrant par rapport à un modèle et incrémentent une métrique CloudWatch personnalisée ; une alarme CloudWatch sur cette métrique déclenche SNS.

Exemple : alarme sur des échecs répétés de connexion à la console.

aws logs put-metric-filter \
  --log-group-name /aws/cloudtrail/org \
  --filter-name ConsoleSignInFailures \
  --filter-pattern '{ ($.eventName = "ConsoleLogin") && ($.errorMessage = "Failed authentication") }' \
  --metric-transformations metricName=ConsoleLoginFailures,metricNamespace=Security,metricValue=1

CloudWatch Logs Insights permet d’effectuer des requêtes ad-hoc à l’aide d’un langage de requête spécialement conçu, utile pour la réponse aux incidents après le déclenchement d’une alarme :

fields @timestamp, userIdentity.arn, sourceIPAddress, eventName

Pièges courants

Activité manquante au niveau des objets S3 : PutObjectAcl, GetObject et DeleteObject sont des événements de données. Un journal de suivi par défaut ne capture que les événements de gestion ; vous devez ajouter des sélecteurs d’événements de données, sinon le résultat, l’alarme ou la règle EventBridge ciblant ces noms d’API ne se déclenchera jamais silencieusement.
Visibilité centrale sans administrateur délégué : l’activation de GuardDuty ou de Security Hub dans chaque compte n’agrège pas les résultats. Les résultats ne sont regroupés de manière centralisée qu’après l’enregistrement d’un administrateur délégué dans AWS Organizations et, pour Security Hub, le choix d’une région d’agrégation. Les invitations inter-comptes fonctionnent pour les petits parcs mais ne sont pas adaptées à grande échelle et nécessitent une acceptation pour chaque compte.
Confusion entre gestion et données dans les filtres : PutBucketAcl (bucket) est un événement de gestion et fonctionne dans n’importe quel filtre de métrique ou EventBridge standard ; PutObjectAcl (objet) ne fonctionne pas, quelle que soit la qualité du modèle, à moins que les événements de données ne soient activés et livrés au même pipeline.

Problème pratique : Scénario d’utilisation

Scénario : Meridian Financial gère une AWS Organization multi-comptes avec un compte de sécurité dédié et un compte de journalisation centralisé. Leur parc informatique contient des informations personnelles identifiables (PII) de clients dans S3, des API transactionnelles sur EC2/Lambda, et CloudTrail écrit déjà les événements de gestion dans un bucket S3 central ; les équipes souhaitent une détection plus rapide et une réponse coordonnée entre les comptes.

Défi : Les ingénieurs en sécurité ont détecté un pic soudain de GETs S3 et des résultats GuardDuty associés suggérant une potentielle exfiltration de données, mais les alertes sont bruyantes et manquent de contexte CloudTrail corrélé et de confinement automatisé entre les comptes.

Approche recommandée :

Activer Amazon GuardDuty dans chaque compte membre et désigner le compte de sécurité comme administrateur délégué de GuardDuty ; activer la protection des événements de données S3 pour que les résultats incluent les anomalies d’accès au niveau des objets.
Configurer CloudTrail par compte pour livrer les événements de gestion au S3 central pour la rétention et pour transférer les événements de données de grande valeur sélectionnés (S3 GetObject/PutObject/DeleteObject et Lambda Invoke) vers CloudWatch Logs dans le compte de sécurité pour une inspection à faible latence.
Activer AWS Security Hub dans le compte de sécurité et activer l’agrégation inter-comptes avec les comptes membres afin que les résultats de GuardDuty, les résultats dérivés de CloudTrail et les résultats de Config/Inspector soient centralisés et normalisés.
Créer des règles EventBridge qui correspondent aux résultats de haute sévérité de GuardDuty et de Security Hub et les acheminer vers SNS pour des notifications par pager et vers une Lambda de remédiation qui utilise le contexte CloudTrail pour prendre des mesures de confinement (révoquer les clés d’API, supprimer la session IAM, isoler l’ENI EC2).
Ajouter des filtres de métriques CloudWatch Logs pour les taux anormaux de s3:GetObject par principal IAM et une alarme qui déclenche le même pipeline EventBridge/SNS/Lambda ; utiliser les requêtes CloudWatch Logs Insights dans le compte de sécurité pour enrichir les alertes avec des événements CloudTrail corrélés pour le tri des incidents.

Justification : La centralisation des résultats (GuardDuty + Security Hub) et l’envoi d’événements de données CloudTrail ciblés à CloudWatch permettent une corrélation, une alerte et un confinement automatisé à faible latence via EventBridge/SNS/Lambda, s’alignant sur les meilleures pratiques AWS pour la détection, l’agrégation inter-comptes et la réponse automatisée.

CloudTrail centralisé et intégrité des journaux

CloudTrail est l’enregistrement faisant autorité de l’activité des API AWS, et le fondement de toute architecture d’audit est un unique journal de suivi multi-régions qui livre ses données à un seul bucket S3 centralisé, idéalement dans un compte d’archivage des journaux dédié au sein d’AWS Organizations. Un journal de suivi multi-régions capture automatiquement les événements de gestion dans chaque région actuelle et dans toute région qu’AWS lancera plus tard — un journal de suivi mono-région crée des angles morts dès qu’une charge de travail est démarrée ailleurs, ce qui est l’échec de complétude classique lors des audits. Lorsqu’il est appliqué au niveau de l’organisation, le journal de suivi capture également les événements de chaque compte membre, de sorte qu’un nouveau compte rejoignant l’organisation est couvert sans aucune configuration par compte.

Activez la validation des fichiers journaux sur le journal de suivi. CloudTrail livre alors chaque heure un fichier de condensé signé dans le même bucket S3, contenant les hachages SHA-256 des fichiers journaux livrés. La commande aws cloudtrail validate-logs parcourt la chaîne de condensés et détecte toute falsification, suppression ou lacune. Sans validation, un défenseur ne peut pas prouver que les journaux n’ont pas été modifiés après l’incident, ce qui les invalide en tant que preuve forensique.

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name corp-audit-logs \
  --is-multi-region-trail \
  --is-organization-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...
aws cloudtrail start-logging --name org-trail

Les échecs de livraison sont presque toujours des problèmes de permissions en aval, et non des bugs de CloudTrail. Le bucket S3 doit exister avant la création du journal de suivi, sa politique de bucket doit accorder s3:PutObject à cloudtrail.amazonaws.com avec une condition aws:SourceArn correspondant au journal de suivi, et le propriétaire de l’objet doit être le propriétaire du bucket (bucket-owner-full-control). Si le journal de suivi utilise SSE-KMS, la politique de la CMK doit autoriser kms:GenerateDataKey* pour le principal de service CloudTrail, et chaque consommateur (Athena, ingénieurs en sécurité, analyseurs Lambda) doit avoir la permission kms:Decrypt sur cette clé. Un mode de panne courant : les journaux sont livrés correctement, mais les requêtes Athena renvoient “AccessDenied” car le rôle de la requête n’a pas la permission Decrypt sur la CMK de chiffrement des journaux. Corrigez-le sur la politique de la clé, et non en désactivant le chiffrement.

CloudWatch Logs, filtres de métriques et alarmes en temps réel

CloudTrail livre les journaux à S3 par lots toutes les 5 à 15 minutes, ce qui est adéquat pour un audit rétrospectif mais trop lent pour une détection en temps réel. Pour déclencher des alarmes sur des événements sensibles, diffusez le journal de suivi (trail) vers CloudWatch Logs (une option du trail) ou acheminez des événements spécifiques via EventBridge. L’approche avec CloudWatch Logs utilise des filtres de métriques (metric filters) qui recherchent des motifs dans les événements JSON et incrémentent une métrique CloudWatch, qui à son tour déclenche une alarme CloudWatch et une notification SNS. L’exemple classique est la connexion à la console avec l’utilisateur root :

{ $.eventName = "ConsoleLogin" && $.userIdentity.type = "Root" }

EventBridge est souvent préférable pour des événements précis et bien connus (désactivation d’une clé KMS, changements de politique IAM) car ses règles peuvent déclencher directement Lambda ou Step Functions sans aucun coût lié à Logs. Utilisez les filtres de métriques lorsque vous avez besoin de comptages agrégés ou de tableaux de bord.

La conservation des journaux dans CloudWatch Logs est par défaut sur Ne jamais expirer (Never Expire), ce qui est coûteux et rarement la bonne configuration. Définissez une conservation explicite par groupe de journaux (aws logs put-retention-policy) en accord avec le régime de conformité — généralement 90 jours à chaud dans CloudWatch avec un archivage à long terme dans S3 via un filtre d’abonnement ou Kinesis Data Firehose.

Pour l’hygiène des données sensibles, appliquez des politiques de protection des données CloudWatch Logs (data protection policies) au niveau du compte. Celles-ci utilisent des identifiants de données gérés (numéros de carte de crédit, clés secrètes AWS, numéros de sécurité sociale) pour masquer les chaînes correspondantes lors de l’ingestion. Point crucial, le démasquage nécessite la permission logs:Unmask ; ne l’accordez qu’à un rôle de type « bris de glace » (break-glass). Les utilisateurs qui peuvent lire le groupe de journaux mais n’ont pas la permission Unmask ne voient que des astérisques. Une politique à l’échelle du compte s’applique à tous les groupes de journaux actuels et futurs, ce qui est le bon contrôle — les politiques par groupe dérivent à mesure que de nouveaux services créent de nouveaux groupes.

Requêtage de journaux à grande échelle : Insights et Athena

Deux moteurs de requête répondent à différents niveaux de données.

CloudWatch Logs Insights interroge les données déjà présentes dans CloudWatch Logs à l’aide d’un langage de requête spécialement conçu. Idéal pour les données opérationnelles récentes (journaux Lambda, VPC Flow Logs dans Logs, journaux d’application). Rapide, sans configuration de schéma, mais limité par la rétention de CloudWatch et le coût par Go analysé.
Amazon Athena exécute des requêtes SQL Presto/Trino sur des données dans S3. Idéal pour les requêtes forensiques à grande échelle sur les journaux CloudTrail, les journaux d’accès ALB, les VPC Flow Logs stockés dans S3 et les journaux CloudFront. Coûte 5 $ par To analysé ; utilisez la projection de partitions (partition projection) ou les partitions Glue par date/région pour réduire drastiquement le coût de l’analyse.

Un cas d’usage forensique typique : identifier qui a désactivé une clé KMS. Comme le JSON de CloudTrail est imbriqué, la table Athena créée par CloudTrail expose userIdentity comme une structure (struct) :

SELECT eventTime,
       userIdentity.arn                                         AS principal,
       userIdentity.sessionContext.sessionIssuer.arn            AS assumed_role,
       userIdentity.sessionContext.attributes.mfaAuthenticated  AS mfa,
       sourceIPAddress,
       requestParameters
FROM   cloudtrail_logs
WHERE  eventName = 'DisableKey'
  AND  eventTime BETWEEN '2024-05-01T03:00:00Z' AND '2024-05-01T03:30:00Z';

Pour l’analyse de bots sur un ALB, activez les journaux d’accès de l’ALB vers S3, définissez une table Athena sur le préfixe des journaux, puis effectuez une jointure avec une table d’adresses IP malveillantes connues et visualisez l’agrégation dans QuickSight. QuickSight lit les données depuis Athena, le pipeline est donc : ALB → S3 → Athena → QuickSight. L’envoi des journaux ALB vers CloudWatch Logs Insights n’est pas un chemin natif pris en charge — les journaux ALB ne peuvent être envoyés que vers S3.

Les VPC Flow Logs peuvent être envoyés à l’une ou l’autre destination : choisissez Logs pour des investigations tactiques de type filter dstPort=3389 and action="REJECT", et S3 (en Parquet, partitionné) pour des requêtes de tendance à l’échelle du mois.

Collecte de preuves avec Audit Manager

AWS Audit Manager automatise la collecte continue de preuves (evidence) mappées à des référentiels tels que PCI DSS, HIPAA, SOC 2 et CIS. Il extrait les preuves des règles Config, des résultats (findings) de Security Hub, des événements CloudTrail et de l’inventaire des ressources, et les regroupe dans des évaluations de contrôles. Lorsqu’il est activé dans le compte de gestion de l’organisation ou dans un compte administrateur délégué, il collecte les données sur tous les comptes membres, produisant un rapport d’évaluation — un ensemble zippé de preuves avec un manifeste — que les auditeurs acceptent à la place de captures d’écran manuelles. C’est la bonne réponse chaque fois qu’un scénario demande une collecte de preuves continue, multi-comptes et alignée sur un référentiel : Config seul vous donne la conformité des ressources mais pas le mappage avec un référentiel ; Security Hub fournit des résultats (findings) mais pas de regroupement en évaluation ; un rapport Athena fait maison n’est pas continu.

Récapitulatif des pièges

Accuser CloudTrail pour des journaux manquants est généralement une erreur : le bucket peut ne pas exister, la politique du bucket peut rejeter le principal CloudTrail, ou la propriété des objets peut être mal configurée. Vérifiez d’abord S3.
Un journal d’audit (trail) mono-région semble moins cher mais produit un historique d’audit incomplet ; multi-région est la réponse correcte par défaut pour une couverture à l’échelle de l’organisation.
Les journaux chiffrés avec SSE-KMS sont invisibles pour Athena, les analyseurs Lambda ou les ingénieurs, sauf si la politique de la CMK accorde kms:Decrypt à ces principaux — désactiver le chiffrement n’est pas la solution ; corriger la politique de la clé l’est.

Problème pratique : Scénario d’utilisation

Scénario : Meridian Financial gère une AWS Organization multi-comptes avec des comptes de production, de pré-production (staging) et un compte dédié à la journalisation. Leur environnement héberge des API exposées aux clients, des outils d’analyse et des secrets gérés par IAM. Ils ont besoin d’une journalisation centralisée et inviolable ainsi que d’outils d’investigation rapides pour soutenir la réponse aux incidents et les demandes de conformité.

Défi : Une séquence suspecte récente de connexions à la console et de modifications de politiques IAM est passée inaperçue pendant des heures, et il existe une préoccupation que l’intégrité des journaux et les alertes rapides soient inadéquates pour la reconstruction forensique et la collecte de preuves par Audit Manager.

Approche recommandée :

Activer un journal d’audit AWS Organizations CloudTrail (organization trail) dans toutes les régions, activer la validation de l’intégrité des fichiers journaux CloudTrail, livrer les journaux et les fichiers de synthèse (digest files) dans un bucket S3 centralisé chiffré avec une CMK KMS dont la politique de clé restreint le déchiffrement à une petite équipe de sécurité, et activer la journalisation des accès S3 et le versioning.
Configurer CloudTrail pour diffuser en continu les événements de gestion et certains événements de données vers CloudWatch Logs, puis créer des filtres de métriques CloudWatch Logs pour les schémas à haut risque (échecs de connexion à la console depuis de nouvelles IP, CreateUser, PutRolePolicy) et attacher des alarmes CloudWatch Alarms à des sujets SNS pour les notifications (paging) et un playbook Lambda automatisé.
Déployer des tableaux de bord CloudWatch Logs Insights pour l’investigation interactive des événements récents et définir des règles de rétention et de cycle de vie dans le compte de journalisation pour conserver les preuves conformément à la politique.
Cataloguer les objets S3 de CloudTrail avec AWS Glue et exécuter des requêtes Athena (partitionnées par région/date/service) pour une analyse rétrospective à grande échelle et pour produire des exports de preuves au format CSV pour les enquêteurs.
Créer une évaluation AWS Audit Manager qui collecte automatiquement les preuves de CloudTrail, AWS Config et IAM dans un dossier de preuves (evidence folder) et planifie des exports périodiques pour les auditeurs de conformité.

Justification : La centralisation et la validation de CloudTrail, la diffusion en continu vers CloudWatch pour les filtres de métriques et les alarmes en temps réel, et l’utilisation d’Athena/Logs Insights pour des requêtes évolutives suivent les meilleures pratiques AWS pour la détection, la journalisation immuable et la préparation forensique, tandis qu’Audit Manager automatise la collecte de preuves pour les audits.

← Détection des menaces et alertes · Tous les domaines · Chiffrement →

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 →

Amazon SCS-C02: Journalisation, audit et analyse forensique — Guide d'étude

Détections et remédiation Amazon GuardDuty

AWS Security Hub et agrégation multi-comptes

CloudTrail : Événements de gestion vs Événements de données

Alertes EventBridge et SNS

CloudWatch Logs, Insights, Filtres de métriques et Alarmes

Pièges courants

Problème pratique : Scénario d’utilisation

CloudTrail centralisé et intégrité des journaux

CloudWatch Logs, filtres de métriques et alarmes en temps réel

Requêtage de journaux à grande échelle : Insights et Athena

Collecte de preuves avec Audit Manager

Récapitulatif des pièges

Problème pratique : Scénario d’utilisation

Pass the whole exam — not just this question

Related guides

Un seul abonnement. Chaque examen.