Limites de CloudTrail : ce que l'analyse des logs ne dit pas
Ce que CloudTrail, les VPC Flow Logs et les journaux d'accès S3 n'enregistrent pas, où les références échouent, et comment conclure honnêtement sans preuves.
En bref. Les journaux enregistrent des appels d'API et des métadonnées réseau : ni l'intention, ni le contenu, ni ce qui s'est passé à l'intérieur d'une instance. CloudTrail ne journalise pas les lectures d'objets S3 si les événements de données n'ont pas été configurés ; l'historique des événements ne conserve que 90 jours d'événements de gestion ; les flow logs ignorent le DNS vers le résolveur Amazon et le trafic vers les métadonnées d'instance ; les journaux d'accès S3 sont livrés au mieux (best effort). Les détections fondées sur une référence sont aveugles sans journées calmes avant l'incident. Rédigez des conclusions à la mesure de la couverture : « aucune preuve de X dans les sources disponibles, qui couvrent Y », jamais « X ne s'est pas produit » lorsque X n'aurait de toute façon pas pu être vu.
Un verdict tiré des journaux (d'un SIEM, de requêtes Athena ou de l'analyseur de ce site) est une affirmation sur les journaux, pas sur le compte. Cet article recense les angles morts qui reviennent dans presque toutes les investigations AWS, afin qu'ils figurent dans le rapport plutôt que de ressurgir sous forme de mauvaise surprise six mois plus tard.
Ce que CloudTrail ne voit pas
| Angle mort | Pourquoi | Que faire |
|---|---|---|
| Lectures et écritures S3 au niveau des objets | Les événements de données sont désactivés par défaut et facturés à part | Vérifier les sélecteurs du trail ; utiliser les journaux d'accès au serveur S3 s'ils sont activés |
| Invocations Lambda, lectures d'éléments DynamoDB | Ce sont aussi des événements de données | Idem |
| Tout ce qui date de plus de 90 jours en l'absence de trail | Limite de l'historique des événements | Un trail ou CloudTrail Lake pour l'avenir |
| Ce qui s'est exécuté à l'intérieur d'une instance ou d'un conteneur | CloudTrail ne journalise que le plan de contrôle | Forensique de l'hôte, EDR, journaux du système d'exploitation ; pour EKS, le journal d'audit Kubernetes (kubernetesforensics.com) |
Les user data complètes de RunInstances | Enregistrées sous la forme <sensitiveDataRemoved> | Les récupérer depuis l'instance |
| Les événements des services ou actions non couverts | La couverture varie selon les services | Services pris en charge par CloudTrail |
| L'ordre au sein d'un fichier | Les événements ne sont pas livrés dans l'ordre (concepts CloudTrail) | Toujours trier par eventTime |
La livraison n'est pas non plus instantanée : CloudTrail livre généralement en cinq minutes environ, sans garantie (fonctionnement de CloudTrail). Une collecte effectuée quelques secondes après la dernière action de l'attaquant peut la manquer.
Ce que les journaux réseau ne voient pas
Les VPC Flow Logs n'enregistrent jamais le trafic vers le serveur DNS Amazon, vers le service de métadonnées d'instance à l'adresse 169.254.169.254, ni Time Sync, DHCP ou ARP (limitations). Par conséquent :
- le tunneling DNS via le résolveur du VPC est invisible (la source adaptée, ce sont les journaux de requêtes Route 53 Resolver) ;
- le vol d'identifiants de rôle d'instance depuis IMDS ne laisse aucun flux ; sa trace éventuelle, ce sont les identifiants utilisés ailleurs, que GuardDuty signale par des détections
InstanceCredentialExfiltration; - les téléchargements S3 et autres appels d'API effectués depuis Internet ne traversent jamais votre VPC.
Les journaux d'accès au serveur S3 sont livrés au mieux ; AWS indique qu'un enregistrement peut arriver en retard, voire jamais (documentation). Utiles pour les volumes et les tendances, ils sont plus fragiles pour prouver qu'une requête précise n'a pas eu lieu.
Les angles morts liés à l'identité
- Les utilisateurs fédérés et SSO apparaissent comme des sessions de rôle assumé ; l'identité de la personne réelle se trouve dans les journaux du fournisseur d'identité (pour Okta, voir oktaforensics.com ; pour Microsoft Entra ID, m365forensics.com).
- Le chaînage de rôles répartit un même acteur sur plusieurs sessions ; suivez les réponses
AssumeRoleetsessionContext.sessionIssuer. - Les services AWS qui agissent pour votre compte font apparaître un nom de service dans
sourceIPAddress; un attaquant qui passe par un service (CloudFormation, Lambda) pour agir indirectement ressemble à ce service. - Les sorties partagées. Le NAT d'un bureau ou la plage d'adresses IP d'un fournisseur de CI rend les détections « nouvelle IP » bruyantes ; un point de sortie VPN que l'attaquant utilise aussi les rend aveugles.
- Aucune géolocalisation dans les journaux. CloudTrail enregistre des adresses IP, pas des pays ni des ASN. L'analyseur n'enrichit pas non plus les adresses IP : une « connexion depuis un nouveau pays » n'est donc pas détectée ; les détections GuardDuty apportent ce contexte lorsqu'il est disponible.
Là où les détections échouent
La détection par règles, y compris celle de l'analyseur, a des modes de défaillance prévisibles :
- Une référence exige de l'historique. « Clé d'accès à long terme utilisée depuis une nouvelle adresse IP » et « Activité dans une région jusque-là inutilisée » comparent avec le premier jour d'activité des journaux que vous chargez. Ne chargez que le jour de l'incident, et elles ne verront rien, ou tout.
- On peut rester sous les seuils. 29 appels List distincts en dix minutes ne déclencheront pas une règle « 30 en 10 minutes » ; 99 téléchargements par heure ne déclencheront pas une règle « 100 par heure ». Un attaquant patient est plus difficile à attraper qu'un attaquant scripté.
- L'administration légitime ressemble à une attaque. Créer des utilisateurs, attacher des politiques, lancer des instances GPU sont des tâches normales. Les détections pointent ; ce sont des personnes qui confirment.
- Les techniques inconnues. Les règles couvrent des chemins d'attaque connus. Le fichier de règles de l'analyseur liste ce qui est couvert ; tout le reste nécessite une revue manuelle des événements bruts.
Rédiger des conclusions honnêtes
Rattachez chaque conclusion à la couverture. Un modèle qui fonctionne :
Entre [début] et [fin], les événements de gestion CloudTrail des comptes […] dans toutes les régions, les événements de données S3 des buckets […] et les VPC Flow Logs des VPC […] ont été examinés. Les événements de données S3 n'étaient pas activés pour les buckets […] ; pour ces buckets, l'accès aux objets ne peut pas être établi. Aucune preuve de [activité] n'a été trouvée dans les sources examinées.
Consignez également : le fuseau horaire (UTC), les empreintes (hashes) des exports, les outils et versions utilisés, et chaque trou dans les journaux : trails arrêtés, régions manquantes, groupes de logs supprimés. L'article sur le contournement des défenses explique comment délimiter un trou créé par l'attaquant.
Combler les angles morts pour la prochaine fois
- Un trail multi-région (ou d'organisation) avec validation de l'intégrité des fichiers journaux, stocké dans un compte distinct et verrouillé.
- Les événements de données S3 pour les buckets contenant des données sensibles, au moins pour les lectures.
- Des VPC Flow Logs sur chaque VPC, y compris les VPC par défaut des régions que vous n'utilisez pas, ou une stratégie de contrôle des services qui interdit ces régions.
- GuardDuty dans chaque région activée, avec export des détections vers S3.
- Une durée de rétention supérieure à votre délai de détection.
Le Security Incident Response Guide d'AWS traite en profondeur le volet préparation. Pour l'investigation elle-même, partez de la vue d'ensemble de la réponse à incident.