La contrainte est souvent la visibilité, pas la sophistication de l’attaquant
Lorsqu’un incident AWS est investigué tardivement, la discussion porte souvent sur le degré d’avancée de l’intrusion. Dans de nombreux environnements, la contrainte réelle est plus simple: il n’y a pas assez de télémétrie pour reconstruire ce qui s’est passé.
CloudTrail, VPC Flow Logs et data events sont imparfaits. Ils ne révèlent pas l’intention ni ne capturent les payloads. Leur valeur est de préserver des pièces de preuve indépendantes qui, ensemble, répondent à des questions de base: quelle identité a agi, quand, depuis où, sur quelle ressource, et avec quel résultat.
Comment la piste disparaît
Dans les environnements multi-comptes, le volume d’événements croît vite. Quelqu’un revoit le coût de stockage, d’indexation ou de SIEM et pose la question inévitable: avons-nous besoin de tant de logging?
Les optimisations arrivent par morceaux:
- les événements de lecture sont écartés comme « bruit »
- les Flow Logs sont limités à la production, ou au trafic rejeté seulement
- les data events S3 sont désactivés à cause du volume
- la rétention est coupée à 30 ou 90 jours
Chaque décision peut sembler raisonnable. Ensemble, elles peuvent supprimer le contexte nécessaire pour comprendre un compromis.
La reconnaissance reste une activité
Après avoir obtenu des credentials valides, un attaquant ne commence pas nécessairement par supprimer des données. Il pose des questions. Il énumère. Il cartographie.
En termes d’API AWS, cela ressemble à des opérations légitimes Get*, List* et Describe*. Pour une équipe produit, cela peut sembler du bruit. Pour un attaquant, c’est une carte.
Si la télémétrie de lecture disparaît du pipeline de sécurité, une action ultérieure comme un changement de politique peut encore être visible. Ce qui est perdu, c’est le début de l’histoire: les minutes d’énumération préalable.
Le schéma inverse existe aussi: garder les lectures et filtrer les écritures. L’exploration reste visible… et le moment où rôles, trust policies ou security groups changent devient incomplet.
Les événements de lecture et d’écriture décrivent des phases différentes. N’en choisir qu’une n’est pas une « visibilité optimisée »; c’est une cécité asymétrique.
Ce qu’une architecture de logging utile devrait préserver
Une posture saine n’est pas « tout journaliser sans jugement ». C’est définir des signaux minimums abordables et utiles pour la forensique et la détection:
- événements de management CloudTrail avec rétention alignée au risque
- couverture des comptes et régions pertinents, pas seulement de l’environnement « principal »
- Flow Logs là où le contexte réseau compte
- data events sélectifs sur les ressources à haute valeur
- un chemin clair du stockage des logs jusqu’aux personnes qui investiguent
L’objectif n’est pas un musée d’événements. C’est la capacité de répondre aux questions de sécurité et de métier avec des preuves quand cela compte.
Lien avec le travail TechRebel
Dans les engagements de sécurité AWS et d’observabilité, nous partons d’une prémisse simple: la visibilité est une décision d’architecture, pas un add-on optionnel. Nous évaluons ce qui est enregistré, ce qui est retenu et ce qui peut encore être reconstruit avant de parler de contrôles supplémentaires.
Pour revoir la posture de logging et de détection dans votre organisation AWS, planifiez une réunion ou consultez AWS & Cloud Security.