Firma uruchamia aplikacje na kontach AWS, które są członkami organizacji AWS Organizations. Te aplikacje korzystają z Amazon EC2 i Amazon S3. Firma chce wykrywać naruszone instancje EC2, podejrzane zachowania sieciowe i nietypowe wywołania API na obecnych i przyszłych kontach. Po wykryciu takich zdarzeń firma chce publikować powiadomienia w istniejącym temacie Amazon SNS używanym przez zespół operacyjny. Które podejście spełnia te wymagania i jest zgodne z najlepszymi praktykami AWS?

Prawidłowa odpowiedź opisuje najlepsze praktyki AWS dla scentralizowanego zarządzania GuardDuty w organizacji. Wyznaczenie konta administratora GuardDuty pozwala na agregację wyników ze wszystkich kont członkowskich, w tym przyszłych kont, co zapewnia kompleksowe wykrywanie zagrożeń. Reguła EventBridge na koncie administratora GuardDuty centralizuje powiadomienia o wynikach, wysyłając je do istniejącego tematu SNS zespołu operacyjnego. Pozostałe opcje są nieprawidłowe, ponieważ: Opcja druga proponuje StackSet do akceptowania zaproszeń i tworzenia reguł EventBridge, co jest niepotrzebne i bardziej złożone niż bezpośrednie zarządzanie GuardDuty przez konto administratora. Opcja trzecia i czwarta skupiają się na CloudTrail, VPC Flow Logs i Security Hub, które są cennymi narzędziami, ale nie są głównym mechanizmem wykrywania naruszonych instancji EC2, podejrzanych zachowań sieciowych i nietypowych wywołań API, które są domeną GuardDuty. Ponadto, nie opisują prawidłowego scentralizowanego wdrożenia GuardDuty.