Skip to content

Vous découvrez que CloudTrail (journalisation d'audit du plan de contrôle) est désactivé dans un compte de production. Pourquoi est-ce important et que faites-vous ?

Réponse courte

Sans journaux d'audit du plan de contrôle, vous êtes aveugle à qui a fait quoi au niveau cloud, et détection, forensique et conformité dépendent toutes de cet enregistrement. Activez CloudTrail immédiatement, à l'échelle de l'org, en livrant vers un bucket séparé, à accès contrôlé et résistant à la falsification (immuable). Dire que ça n'a pas d'importance tant que rien ne va mal ignore que vous n'auriez aucun historique le jour où ça ira mal. Attendre un incident signifie que les premières actions décisives sont déjà non journalisées et irrécupérables. Les journaux applicatifs ne capturent pas l'activité API, IAM ou console du plan de contrôle.

La journalisation d'audit est le socle sur lequel tout le reste repose. L'examinateur veut vous entendre traiter des journaux de plan de contrôle manquants comme un risque actif — car le coût de leur absence ne se paie jamais qu'au milieu d'un incident, quand il est trop tard pour y remédier.

Pourquoi c'est important

CloudTrail enregistre l'activité API du plan de contrôle : qui a appelé quoi, depuis où, quand — modifications IAM, connexions console, création et suppression de ressources, modifications de politique. Sans lui, vous n'avez aucun enregistrement de l'activité du compte. Les règles de détection n'ont rien sur quoi se déclencher, un intervenant en incident n'a aucune chronologie à reconstruire, et les cadres de conformité qui exigent une piste d'audit ne sont pas satisfaits. Les journaux applicatifs opèrent un niveau au-dessus ; ils ne disent rien des appels API, de l'IAM ou des actions console au niveau du plan de contrôle cloud.

Ce que vous faites

Activez CloudTrail maintenant, à l'échelle de l'org (pour que chaque compte actuel et futur soit couvert par défaut), en livrant vers une destination séparée, à accès contrôlé et immuable — idéalement un compte de journalisation dédié avec S3 Object Lock / validation des fichiers journaux afin que même un administrateur (ou un attaquant) du compte de production ne puisse pas supprimer ou falsifier discrètement l'historique.

Pourquoi les distracteurs sont mauvais

  • « Pas d'importance tant que rien ne va mal. » Tout l'intérêt des journaux d'audit est d'avoir l'historique avant que quelque chose tourne mal. Au moment où vous en avez besoin, vous ne pouvez pas les créer rétroactivement.
  • L'activer seulement après un incident. Les premières actions, les plus diagnostiques, d'un incident — l'accès initial, l'élévation de privilège — surviennent avant que vous ne l'activiez. Vous enquêteriez avec une bande vierge pour la partie qui compte le plus.
  • Se fier aux journaux applicatifs. Utiles, mais à un autre niveau. Ils ne capturent pas l'activité API, IAM ou du plan de contrôle, donc ne peuvent pas dire qui a créé un utilisateur malveillant ou désactivé un contrôle de sécurité.

Ce que recherchent les examinateurs

Le traiter comme urgent, activer une couverture à l'échelle de l'org, et protéger l'intégrité de la piste (compte séparé, stockage immuable, validation des journaux). Les bons candidats notent que les attaquants tentent couramment de désactiver la journalisation, donc une alarme sur StopLogging/DeleteTrail est elle-même une détection clé.

Questions de suivi probables

  • Pourquoi la piste doit-elle aller vers un compte séparé ou un bucket immuable plutôt que le même compte ?
  • Quelles catégories d'activité CloudTrail capture-t-il que les journaux applicatifs ne captureront jamais ?
  • Si un attaquant a désactivé la piste, comment le sauriez-vous, et comment l'empêchez-vous ?

Sources

Certifications

Recevez 100 questions d'entretien en cybersécurité + réponses

Laissez votre e-mail et nous vous enverrons le pack PDF gratuit et le jeu de flashcards.

Pas de spam. Désabonnez-vous à tout moment.