Événements de gestion, de données et d'analyse

CloudTrail capture trois catégories d’événements, et il est essentiel pour l’examen de connaître leurs différences : les événements de gestion, les événements de données et les événements Insights.

Ils se distinguent par ce qu’ils enregistrent, leur activation ou non par défaut et leur coût — des différences qui déterminent toute stratégie de journalisation.

Les événements de gestion enregistrent les opérations du plan de contrôle, c’est-à-dire les actions qui gèrent les ressources, comme créer une instance, associer une politique ou modifier un groupe de sécurité.

Ils sont enregistrés par défaut et le premier exemplaire est généralement gratuit. Ce sont les événements sur lesquels reposent la plupart des investigations de sécurité pour examiner les modifications de configuration et d’accès.

Les événements de données enregistrent les opérations du plan de données, c’est-à-dire les actions à volume élevé effectuées sur les données contenues dans les ressources, comme les appels S3 GetObject/PutObject ou les invocations de fonctions Lambda.

Ils sont désactivés par défaut et entraînent un coût supplémentaire en raison de leur volume. Activez-les de manière sélective là où la visibilité au niveau des objets est importante.

Une seule application peut effectuer des millions d’appels à des objets S3 par jour, ce qui dépasse largement le nombre d’actions de gestion.

Les journaliser tous est très utile pour l’analyse forensique — vous pouvez voir exactement quel objet a été lu — mais leur volume augmente les coûts. Limitez les événements de données aux compartiments sensibles plutôt que de les activer partout.

CloudTrail Insights détecte automatiquement les schémas inhabituels d’activité d’API, comme une hausse soudaine d’un appel habituellement rare.

Il établit une référence du comportement normal et génère un événement Insights lorsque l’activité s’en écarte, faisant ressortir des anomalies telles qu’une vague de suppressions de ressources pouvant signaler une attaque.

Un modèle mental simple : les événements de gestion correspondent au plan de contrôle (gérer la ressource), tandis que les événements de données correspondent au plan de données (utiliser la ressource).

Créer un compartiment S3 relève de la gestion ; lire un objet dans ce compartiment relève des données. Cette distinction vous indique de manière fiable le type d’événement concerné et son profil de coût.

Vous pouvez limiter la journalisation aux événements en lecture seule, en écriture seule ou à tous les événements.

Les événements d’écriture enregistrent les modifications (généralement prioritaires en sécurité), tandis que les événements de lecture enregistrent les accès. Le filtrage réduit le bruit et les coûts — par exemple en journalisant uniquement les événements de gestion en écriture ainsi que les événements de données de vos compartiments les plus sensibles.

Les sélecteurs d’événements avancés vous permettent de filtrer précisément les événements de données — par ARN de ressource, par nom d’événement ou selon d’autres champs — au lieu d’activer une journalisation globale ou de ne rien journaliser.

Vous pouvez journaliser GetObject uniquement pour un compartiment sensible, afin de maîtriser à la fois les coûts et le bruit. Cette précision rend la journalisation des événements de données pratique à grande échelle.

Quels que soient les types d’événements que vous activez, les enregistrements sont envoyés vers le compartiment S3 de votre piste et, éventuellement, vers CloudWatch Logs.

Les événements Insights sont également placés sous un préfixe S3 distinct. Il est important de connaître ces destinations pour effectuer des requêtes avec Athena, configurer des alarmes et protéger les journaux : c’est à cet endroit que se trouvent réellement vos éléments de preuve.

Un choix par défaut raisonnable consiste à activer une piste multi-région qui capture tous les événements de gestion en écriture, à ajouter des événements de données uniquement pour les compartiments et les fonctions qui traitent des données sensibles, et à activer Insights pour détecter les anomalies.

Cette stratégie équilibre une visibilité de sécurité complète et le coût élevé de la journalisation d’événements de données en grand volume.

Le SCS-C02 vérifie souvent que vous savez associer un besoin au bon type d’événement : le suivi des accès au niveau des objets correspond aux événements de données ; les modifications de configuration correspondent aux événements de gestion ; les hausses inhabituelles d’activité correspondent à Insights.

N’oubliez pas que les événements de données sont désactivés par défaut et qu’ils entraînent un coût supplémentaire — c’est un piège fréquent dans les réponses d’examen.

Associez le besoin au type d’événement.

CloudTrail enregistre trois types d’événements. Les événements de gestion journalisent les modifications du plan de contrôle et sont activés par défaut ; les événements de données journalisent les accès à haut volume du plan de données, comme S3 GetObject, et sont désactivés par défaut avec un coût supplémentaire ; les événements Insights détectent les schémas inhabituels d’activité d’API. Utilisez le modèle du plan de contrôle et du plan de données, filtrez les lectures et les écritures pour réduire le bruit, et activez les événements de données uniquement sur les ressources sensibles afin d’équilibrer visibilité et coût.