Exporter les logs CloudTrail, VPC Flow et S3 pour l'analyse

En bref. Collectez d'abord, analysez ensuite. La meilleure source CloudTrail est le bucket S3 du trail (AWSLogs/<account-id>/CloudTrail/<region>/YYYY/MM/DD/*.json.gz) : copiez-le avec aws s3 sync et gardez les fichiers compressés et intacts. Pas de trail ? Téléchargez l'historique des événements région par région : 90 jours, événements de gestion uniquement. Récupérez ensuite les VPC Flow Logs, les journaux d'accès serveur S3, les détections GuardDuty et le rapport d'identifiants IAM. Prenez aussi quelques jours calmes avant l'incident : les références de comportement normal en ont besoin.

Un attaquant doté de droits administrateur supprime les trails et les détecteurs. Les règles de rétention font expirer des objets sans bruit. L'historique des événements s'efface au bout de 90 jours. La chose la plus utile que vous puissiez faire dans la première heure d'un incident AWS, c'est placer une copie des preuves hors de portée de l'attaquant, avant que quiconque ne commence à « faire le ménage ».

Avant de commencer : périmètre et destination sûre

Fenêtre temporelle. De quelques jours avant le premier événement suspect jusqu'à maintenant. Les détections qui comparent l'activité au comportement habituel (les adresses IP usuelles d'une clé, les régions que vous utilisez normalement) ont besoin de cette période calme.
Comptes et régions. Les trails d'organisation regroupent tous les comptes dans un seul bucket ; les trails mono-compte peuvent être régionaux. Listez-les avec aws cloudtrail describe-trails --include-shadow-trails.
Identifiants de collecte. Utilisez un principal que l'attaquant n'a pas touché, idéalement un rôle dédié en lecture seule. Ne collectez pas avec la clé compromise.
Destination. Un disque local chiffré ou un compte séparé. Consignez les empreintes SHA-256 de ce que vous avez téléchargé dans le dossier d'investigation.

1. CloudTrail depuis le bucket S3 du trail (la meilleure source)

Un trail CloudTrail livre des fichiers JSON compressés en gzip dans S3, environ toutes les cinq minutes selon la description du fonctionnement de CloudTrail par AWS. L'arborescence des clés est prévisible :

s3://<bucket>/[<prefix>/]AWSLogs/[<org-id>/]<account-id>/CloudTrail/<region>/YYYY/MM/DD/<account>_CloudTrail_<region>_<timestamp>_<id>.json.gz

Copiez la fenêtre dont vous avez besoin :

aws s3 sync s3://<bucket>/AWSLogs/<account-id>/CloudTrail/ ./cloudtrail \
  --exclude "*" --include "*/2026/09/1*"

Retours de terrain :

Gardez les fichiers .json.gz tels quels. Les recompresser ou les fusionner fait perdre les noms de fichier, qui portent la région et l'heure de livraison.
Les fichiers digest sous CloudTrail-Digest/ sont des chaînes de hachage signées, pas des événements. Conservez-les au dossier (ils permettent la validation de l'intégrité des fichiers journaux), mais les outils d'analyse les ignorent.
Les événements de données (S3 GetObject, Lambda Invoke…) arrivent dans les mêmes fichiers si le trail a été configuré pour les enregistrer. Ils ne sont pas journalisés par défaut (documentation AWS) : vérifiez les sélecteurs d'événements du trail pour savoir ce que vous pouvez espérer y trouver.
Les événements CloudTrail Insights, s'ils sont activés, se trouvent sous un préfixe distinct, CloudTrail-Insight/.

2. L'historique des événements CloudTrail (aucun trail configuré)

Chaque compte dispose d'un historique des événements : les 90 derniers jours d'événements de gestion, par région, sans les événements de données. C'est mieux que rien, et c'est indépendant des trails : un attaquant qui supprime un trail ne l'efface pas.

Console : CloudTrail → Event history, dans chaque région ; retirez le filtre par défaut sur la lecture seule, choisissez la plage de dates, puis Download events → JSON (de préférence) ou CSV. Un seul téléchargement contient jusqu'à 200 000 événements.
CLI, région par région :

for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws cloudtrail lookup-events --region "$r" \
    --start-time 2026-09-01T00:00:00Z --output json > "events-$r.json"
done

lookup-events renvoie chaque événement sous forme de chaîne JSON dans le champ CloudTrailEvent ; conservez la sortie telle quelle, les outils d'analyse savent la lire.

3. CloudTrail Lake

Si vous disposez d'un event data store, interrogez-le et enregistrez les résultats dans S3 :

SELECT eventJson FROM <event-data-store-id>
WHERE eventTime > '2026-09-01 00:00:00'

Sélectionner la colonne eventJson complète conserve tous les champs. Une sélection de colonnes à plat suffit pour un examen rapide, mais perd les champs imbriqués comme requestParameters.

4. VPC Flow Logs

Les VPC Flow Logs sont envoyés vers S3, CloudWatch Logs ou Firehose.

S3 : AWSLogs/<account-id>/vpcflowlogs/<region>/YYYY/MM/DD/*.log.gz. Synchronisez-les comme CloudTrail. La livraison en texte brut comporte une ligne d'en-tête qui nomme les champs ; gardez-la, car les formats personnalisés modifient l'ordre des colonnes. Parquet est aussi une option de livraison, mais tous les outils ne savent pas le lire.
CloudWatch Logs : créez une tâche d'export vers S3 (aws logs create-export-task) ou parcourez aws logs filter-log-events page par page sur une fenêtre réduite.

Les flow logs enregistrent des métadonnées (adresses, ports, octets, acceptation ou rejet), pas le contenu des paquets. L'article sur l'analyse des VPC Flow Logs explique ce qu'ils permettent de prouver.

5. Journaux d'accès serveur S3

Si la journalisation des accès serveur était activée sur le bucket concerné, les journaux se trouvent dans le bucket cible et sous le préfixe que vous avez configurés :

aws s3 sync s3://<log-bucket>/<prefix>/ ./s3-access

Les objets n'ont pas d'extension et contiennent une ligne délimitée par des espaces pour chaque requête. La livraison se fait « au mieux » : AWS indique que ni l'exhaustivité ni les délais ne sont garantis (documentation). Utilisez-les en complément des événements de données CloudTrail lorsque les deux existent.

6. Détections GuardDuty

GuardDuty conserve les détections pendant 90 jours ; une destination de publication S3 permet de les garder plus longtemps (documentation sur l'export). Exportez-les tôt : supprimer un détecteur fait partie des gestes courants d'un attaquant.

DET=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)
aws guardduty list-findings --detector-id "$DET" --query 'FindingIds' --output text \
  | xargs -n 50 aws guardduty get-findings --detector-id "$DET" --finding-ids > findings.json

Recommencez dans chaque région où GuardDuty est activé.

7. Rapport d'identifiants IAM

Le rapport d'identifiants liste chaque utilisateur avec l'état de son mot de passe, de sa MFA et de ses clés d'accès, dates de dernière utilisation comprises. IAM génère au maximum un rapport toutes les quatre heures (documentation).

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > credential-report.csv

Checklist

Source	Emplacement	Rétention à surveiller	Priorité
Trail CloudTrail	Bucket S3 `AWSLogs/…/CloudTrail/`	Règles de cycle de vie du bucket	1
Historique des événements	Console / `lookup-events`, par région	90 jours	1 en l'absence de trail
Détections GuardDuty	`get-findings` ou export S3	90 jours dans GuardDuty	2
Rapport d'identifiants	IAM	Instantané du moment présent	2
Événements de données S3	Mêmes fichiers que le trail	Seulement s'ils sont configurés	2
Journaux d'accès serveur S3	Bucket cible	Cycle de vie du bucket	3
VPC Flow Logs	S3 / CloudWatch Logs	Rétention du groupe de logs	3

Étape suivante

Une fois la collecte terminée, déposez tout d'un coup dans l'analyseur qui fonctionne dans le navigateur : dossiers de trail, historique des événements en JSON ou CSV, CSV de CloudTrail Lake, flow logs, journaux d'accès, détections et rapport d'identifiants sont reconnus automatiquement, et rien ne quitte votre machine. Le guide d'analyse des logs CloudTrail explique comment lire les résultats, et la vue d'ensemble de la réponse à incident replace la collecte dans le plan de confinement global.