L'entreprise exécute des applications dans des comptes AWS qui sont membres d'une organisation AWS Organizations. Ces applications utilisent Amazon EC2 et Amazon S3. L'entreprise souhaite détecter les instances EC2 compromises, les comportements réseau suspects et les appels d'API inhabituels sur les comptes actuels et futurs. Lorsque de tels événements sont détectés, l'entreprise souhaite publier une notification sur une rubrique Amazon SNS existante utilisée par son équipe d'exploitation. Quelle approche répond à ces exigences et suit les meilleures pratiques AWS ?

L'option correcte centralise la gestion de GuardDuty et la notification des événements. Désigner un compte administrateur GuardDuty permet de gérer la détection des menaces sur tous les comptes membres de l'organisation. L'invitation des comptes existants garantit que GuardDuty surveille l'ensemble de l'environnement. La création d'une règle EventBridge dans le compte administrateur GuardDuty, qui correspond aux résultats GuardDuty et les envoie à une rubrique SNS, est une pratique courante pour l'automatisation des alertes de sécurité, garantissant que l'équipe d'exploitation est informée des événements détectés. Les options incorrectes proposent des solutions moins efficaces ou ne répondent pas pleinement aux exigences. La deuxième option est complexe et ne garantit pas une gestion centralisée des alertes. Les troisième et quatrième options se concentrent sur CloudTrail et Security Hub, qui sont des services importants, mais GuardDuty est spécifiquement conçu pour la détection des menaces mentionnées (instances compromises, comportements réseau suspects, appels d'API inhabituels) et est le service le plus direct pour répondre à ces exigences.