Which solution will meet these requirements?
Designate an account to be the delegated Amazon GuardDuty administrator account. Turn on GuardDuty for all accounts across the organization. In the GuardDuty administrator account, create an SNS topic. Subscribe the SecOps team’s email address to the SNS topic. In the same account, create an Amazon EventBridge rule that uses an event pattern for GuardDuty findings and a target of the SNS topic.
Create an AWS CloudFormation template that creates an SNS topic and subscribes the SecOps team’s email address to the SNS topic. In the template, include an Amazon EventBridge rule that uses an event pattern of CloudTrail activity for s3:PutBucketPublicAccessBlock and a target of the SNS topic. Deploy the stack to every account in the organization by using CloudFormation StackSets.
Turn on AWS Config across the organization. In the delegated administrator account, create an SNS topic. Subscribe the SecOps team’s email address to the SNS topic. Deploy a conformance pack that uses the s3-bucket-level-public-access-prohibited AWS Config managed rule in each account and uses an AWS Systems Manager document to publish an event to the SNS topic to notify the SecOps team.
Turn on Amazon Inspector across the organization. In the Amazon Inspector delegated administrator account, create an SNS topic. Subscribe the SecOps team’s email address to the SNS topic. In the same account, create an Amazon EventBridge rule that uses an event pattern for public network exposure of the S3 bucket and publishes an event to the SNS topic to notify the SecOps team.
Explanations:
While GuardDuty can monitor account activities, it is primarily focused on detecting threats and suspicious activities rather than configuration changes to S3 bucket policies. It does not natively support notifications for changes in Block Public Access settings on S3 buckets. Therefore, using GuardDuty for this requirement does not provide the necessary monitoring capabilities.
Although this option involves creating an SNS topic and subscribing to notifications, it requires deploying a CloudFormation stack to each account. This could lead to inconsistencies if not managed correctly, and it still relies on the accounts’ ability to create resources. The requirement specifies that individual accounts should not be able to turn off the notification, which this method does not guarantee.
AWS Config can monitor S3 bucket configurations and enforce compliance with the Block Public Access settings. By using a conformance pack with thes3-bucket-level-public-access-prohibitedmanaged rule, any changes to these settings can trigger notifications through an SNS topic. Since this is set up in the delegated administrator account, individual accounts cannot disable this notification.
Amazon Inspector is primarily used for assessing security vulnerabilities and does not specifically monitor S3 bucket configuration changes. Similar to GuardDuty, it is not suitable for tracking changes to the Block Public Access feature on S3 buckets, making it an ineffective choice for this requirement.
I sort that the answer is:
Turn on AWS Config across the organization. In the delegated administrator account, create an SNS topic. Subscribe the SecOps team’s email address to the SNS topic. Deploy a conformance pack that uses the s3-bucket-level-public-access-prohibited AWS Config managed rule in each account and uses an AWS Systems Manager document to publish an event to the SNS topic to notify the SecOps team.
I conclude that the answer is:
Turn on AWS Config across the organization. In the delegated administrator account, create an SNS topic. Subscribe the SecOps team’s email address to the SNS topic. Deploy a conformance pack that uses the s3-bucket-level-public-access-prohibited AWS Config managed rule in each account and uses an AWS Systems Manager document to publish an event to the SNS topic to notify the SecOps team.