회사는 AWS Organizations 조직의 멤버인 AWS 계정에서 애플리케이션을 실행합니다. 해당 애플리케이션은 Amazon EC2 및 Amazon S3를 사용합니다. 회사는 현재 및 향후 계정에서 손상된 EC2 인스턴스, 의심스러운 네트워크 동작 및 비정상적인 API 호출을 감지하고자 합니다. 이러한 이벤트가 감지되면 회사는 운영 팀에서 사용하는 기존 Amazon SNS topic으로 알림을 게시하고자 합니다. 어떤 접근 방식이 이러한 요구 사항을 충족하고 AWS 모범 사례를 따릅니까?

이 접근 방식은 AWS Organizations의 다중 계정 환경에서 GuardDuty를 중앙에서 관리하고 탐지된 위협에 대한 알림을 자동화하는 AWS 모범 사례를 따릅니다. 관리 계정에서 GuardDuty 관리자를 지정하고 멤버 계정을 초대함으로써 모든 계정의 위협 탐지를 중앙에서 통합할 수 있습니다. EventBridge 규칙은 GuardDuty findings를 필터링하고 운영 팀의 SNS topic으로 알림을 보내 신속한 대응을 가능하게 합니다. 다른 옵션들은 다음과 같은 이유로 올바르지 않습니다. GuardDuty를 구성하여 초대를 통해 새 계정을 추가하고 기존 계정에 초대를 보내는 것은 관리자 계정에서 GuardDuty를 활성화하는 것과 동일한 효과가 없으며, StackSet은 GuardDuty 관리자 계정에서 중앙 집중식으로 관리하는 것보다 복잡합니다. CloudTrail 조직 트레일과 VPC Flow Logs는 유용하지만, GuardDuty는 EC2 인스턴스 손상, 의심스러운 네트워크 동작 및 비정상적인 API 호출과 같은 특정 위협 탐지에 더 적합합니다. Security Hub는 GuardDuty findings를 집계하지만, GuardDuty 자체가 직접적인 탐지 서비스입니다. CloudTrail 관리자 지정은 CloudTrail 관리에 중점을 두며, GuardDuty가 제공하는 위협 탐지 기능을 직접적으로 다루지 않습니다. VPC Flow Logs와 Security Hub는 보완적이지만, GuardDuty의 핵심 기능을 대체하지 않습니다.