L'azienda esegue applicazioni in account AWS che sono membri di un'organizzazione AWS Organizations. Tali applicazioni utilizzano Amazon EC2 e Amazon S3. L'azienda desidera rilevare istanze EC2 compromesse, comportamenti di rete sospetti e chiamate API insolite negli account attuali e futuri. Quando tali eventi vengono rilevati, l'azienda desidera pubblicare una notifica su un argomento Amazon SNS esistente utilizzato dal suo team operativo. Quale approccio soddisfa questi requisiti e segue le best practice AWS?

L'opzione corretta è la migliore pratica per centralizzare il rilevamento delle minacce e la notifica in un ambiente AWS Organizations. Designare un account amministratore GuardDuty consente di gestire GuardDuty a livello centrale per tutti gli account membri, inclusi quelli futuri, garantendo una copertura uniforme. GuardDuty è specificamente progettato per rilevare istanze EC2 compromesse, comportamenti di rete sospetti e chiamate API insolite. La creazione di una regola EventBridge nell'account amministratore di GuardDuty per inoltrare i risultati a un argomento SNS centralizza ulteriormente la gestione degli avvisi, fornendo al team operativo un unico punto di notifica. L'opzione 2 è meno efficiente perché richiede la distribuzione di uno StackSet CloudFormation per accettare gli inviti e configurare EventBridge in ogni account, il che è più complesso della gestione centralizzata tramite l'account amministratore di GuardDuty. Le opzioni 3 e 4 si concentrano su CloudTrail e VPC Flow Logs per Security Hub. Sebbene utili per la sicurezza generale, non sono il servizio principale per il rilevamento delle minacce in tempo reale come richiesto, e Security Hub aggrega i risultati ma non è il motore di rilevamento primario per questi tipi di minacce. GuardDuty è la soluzione più diretta ed efficace per i requisiti specifici.