A empresa executa aplicações em contas AWS que são membros de uma organização AWS Organizations. Essas aplicações usam Amazon EC2 e Amazon S3. A empresa deseja detectar instâncias EC2 comprometidas, comportamento de rede suspeito e chamadas de API incomuns em contas atuais e futuras. Quando tais eventos são detectados, a empresa deseja publicar uma notificação em um tópico Amazon SNS existente usado por sua equipe de operações. Qual abordagem atende a esses requisitos e segue as melhores práticas da AWS?

A opção correta centraliza o gerenciamento do GuardDuty e das notificações. Designar uma conta administradora do GuardDuty na conta de gerenciamento permite monitorar todas as contas membros (atuais e futuras automaticamente, se configurado) de forma centralizada. A criação de uma regra do Amazon EventBridge na conta administradora para capturar descobertas do GuardDuty e publicá-las em um tópico SNS é a forma recomendada de automação. As opções incorretas apresentam falhas: A segunda opção sugere convites manuais para contas existentes e um StackSet para aceitar convites e criar regras do EventBridge, o que é complexo e menos eficiente do que a integração nativa do GuardDuty com o Organizations. A terceira e quarta opções focam no CloudTrail, VPC Flow Logs e Security Hub. Embora sejam serviços de segurança importantes, eles não substituem a detecção de ameaças do GuardDuty para instâncias EC2 comprometidas, comportamento de rede suspeito e chamadas de API incomuns, que são requisitos específicos da pergunta. Além disso, a configuração do Security Hub para consolidar descobertas é uma boa prática, mas o GuardDuty é o serviço principal para a detecção de ameaças mencionada.