Dans une configuration multi-comptes, l'entreprise achemine tout le trafic sortant via une Transit Gateway vers un compte d'opérations réseau. Là, le trafic est inspecté par une appliance de pare-feu avant d'atteindre la passerelle Internet. Le pare-feu écrit des journaux dans CloudWatch Logs et classe les événements comme CRITICAL, HIGH, MEDIUM, LOW et INFO. L'équipe de sécurité doit être alertée chaque fois que des événements CRITICAL apparaissent. Que doit implémenter l'ingénieur DevOps pour satisfaire cette exigence ?

La bonne approche consiste à utiliser les fonctionnalités de CloudWatch Logs pour surveiller les journaux du pare-feu. En créant un filtre de métriques, vous pouvez analyser les flux de journaux pour des motifs spécifiques, tels que le mot-clé "CRITICAL". Chaque fois que ce motif est détecté, une métrique personnalisée est incrémentée. Une alarme CloudWatch peut ensuite être configurée pour surveiller cette métrique personnalisée et se déclencher lorsque le seuil est atteint (par exemple, un événement CRITICAL se produit). Cette alarme peut publier des notifications sur une rubrique SNS, à laquelle l'équipe de sécurité peut s'abonner par e-mail, garantissant ainsi des alertes immédiates. Les autres options sont incorrectes car: Les canaries CloudWatch Synthetics sont utilisées pour surveiller la disponibilité et les performances des applications, pas pour analyser les journaux d'événements. Amazon GuardDuty est un service de détection des menaces qui analyse les journaux de flux et les événements CloudTrail, mais il ne surveille pas directement les journaux d'applications ou de pare-feu personnalisés pour des mots-clés spécifiques. AWS Firewall Manager est utilisé pour gérer et déployer des règles de pare-feu de manière centralisée, mais il ne fournit pas de mécanisme direct pour déclencher des alertes basées sur le contenu des journaux d'événements du pare-feu.