Exfiltration de données S3 : ce que les journaux prouvent

En bref. À la question « Ont-ils pris les données ? », on ne peut répondre pour les objets S3 que si les événements de données S3 de CloudTrail ou les journaux d'accès au serveur S3 étaient activés avant l'incident. Avec eux : comptez les GetObject par principal, par bucket et par heure, additionnez bytesTransferredOut / Bytes Sent, et listez les clés d'objets. Sans eux : vous pouvez montrer que l'attaquant pouvait lire (permissions, ListBuckets ; ListObjects est lui aussi un événement de données) et si un bucket a été rendu public ou un snapshot partagé (événements de gestion), mais pas quels objets sont sortis. Vérifiez aussi les canaux qui ne nécessitent aucun téléchargement : politiques publiques, ACL, snapshots EBS/RDS et AMI partagés.

Le vol de données est la première question que posent les juristes, les clients et les autorités de contrôle, et c'est celle où la couverture des journaux compte le plus. Cet article passe en revue ce que chaque source de journaux AWS permet de prouver sur une exfiltration via S3 ou via des snapshots, et comment rédiger un rapport honnête quand elle ne permet pas de conclure.

Deux sources pour les lectures d'objets

L'idéal est d'avoir les deux : CloudTrail fournit une identité fiable, les journaux d'accès offrent un second enregistrement indépendant. Une seule des deux sources suffit pour répondre à la question.

Lire les événements de données CloudTrail

Un événement de données correspondant à une lecture d'objet ressemble à ceci (version abrégée) :

{
  "eventSource": "s3.amazonaws.com",
  "eventName": "GetObject",
  "eventCategory": "Data",
  "userIdentity": {"arn": "arn:aws:iam::111122223333:user/backup-admin", "accessKeyId": "AKIA..."},
  "sourceIPAddress": "203.0.113.77",
  "requestParameters": {"bucketName": "acme-customer-exports", "key": "exports/customers-0001.csv.gz"},
  "additionalEventData": {"bytesTransferredOut": 12345678}
}

Les questions à se poser, et comment y répondre :

• Combien d'objets ? Comptez les valeurs distinctes de requestParameters.key par principal et par bucket.
• Quel volume ? Additionnez bytesTransferredOut. Les lectures partielles (requêtes de plage) comptent pour leurs octets réellement transférés.
• Quels objets ? La liste des clés constitue votre inventaire des données divulguées. Exportez-la.
• D'où ? sourceIPAddress et userAgent : un client boto3 sur un VPS qui récupère 300 objets en 20 minutes n'est pas votre tâche de sauvegarde.
• Avant les lectures : ListObjects / ListObjectsV2 (également des événements de données), et les événements de gestion ListBuckets, GetBucketPolicy, GetBucketAcl, GetBucketLocation émis par le même principal.

La technique correspondante est MITRE ATT&CK T1530 Data from Cloud Storage.

Lire les journaux d'accès au serveur S3

Les journaux d'accès au serveur contiennent une ligne par requête ; les champs utiles ici sont le bucket, l'heure, l'IP distante, le demandeur, l'opération, la clé, le code HTTP et les octets envoyés (format des journaux).

79a59df9... acme-customer-exports [14/Sep/2026:09:15:04 +0000] 203.0.113.77
arn:aws:iam::111122223333:user/backup-admin 3E57427F3EXAMPLE REST.GET.OBJECT
exports/2026/customers/customers-0001.csv.gz "GET /exports/... HTTP/1.1" 200 - 12345678 ...

(Coupé ici pour la lisibilité ; chaque enregistrement tient sur une seule ligne.)

Filtrez sur REST.GET.OBJECT avec un code 200 ou 206, puis regroupez par demandeur et par bucket. Un demandeur - signifie une requête anonyme : normal pour un bucket d'hébergement de site web public, une fuite pour tout le reste.

Exfiltration sans téléchargement

Certains des vols de données les plus efficaces sur AWS ne produisent jamais le moindre GetObject dans votre compte : l'attaquant rend les données accessibles et les copie depuis ailleurs. Ce sont tous des événements de gestion, donc visibles même sans événements de données :

Un snapshot partagé signifie que les données peuvent être copiées dans le compte de l'attaquant sans laisser d'autre trace dans le vôtre. Considérez son contenu comme divulgué.

Quand vous n'avez aucune des deux sources

Soyez précis dans le rapport. Vous pouvez établir :

• quels principaux avaient la permission de lire quels buckets (politiques IAM, politiques de bucket) ;
• si l'attaquant a listé les buckets ou lu leurs politiques (événements de gestion) ;
• si un bucket a été rendu public ou un snapshot partagé ;
• si les flux réseau de vos instances montrent d'importants transferts sortants (analyse des VPC Flow Logs) : utile pour des données regroupées au préalable sur EC2, pas pour des téléchargements S3 directs, qui ne traversent pas votre VPC.

Vous ne pouvez pas affirmer que des objets n'ont pas été lus. « Aucune preuve d'accès » n'a de sens que si la preuve aurait pu exister. L'article sur les limites explique comment formuler ce point.

Le compte à rebours de la notification

Si des données personnelles peuvent être concernées, les délais légaux courent à partir du moment où vous en avez connaissance, et non à la fin de l'investigation : selon le RGPD, 72 heures pour notifier l'autorité de contrôle (article 33). Impliquez tôt votre délégué à la protection des données (DPO), et transmettez-lui la liste des objets dès que vous l'avez.

Dans l'analyseur

AWS Forensics signale les téléchargements massifs issus de l'une ou l'autre source (plus de 100 objets d'un même bucket par un même principal en une heure), les téléchargements anonymes depuis des adresses publiques, les politiques de bucket et ACL publiques, la suppression de Block Public Access, les snapshots ou AMI partagés avec d'autres comptes, et la lecture massive de secrets. Les remarques de couverture indiquent explicitement lorsque ni événements de données ni journaux d'accès n'ont été fournis. Pivotez sur le bucket dans l'onglet « Entités » pour voir toutes les requêtes qui le visent, depuis les deux sources. Pour le contexte complet, partez de la vue d'ensemble de la réponse à incident.