What should the solutions architect do to meet these requirements with the LEAST operational overhead?
Write an AWS Lambda script that monitors security groups for SSH being open to 0.0.0.0/0 addresses and creates a notification every time it finds one.
Enable the restricted-ssh AWS Config managed rule and generate an Amazon Simple Notification Service (Amazon SNS) notification when a noncompliant rule is created.
Create an IAM role with permissions to globally open security groups and network ACLs. Create an Amazon Simple Notification Service (Amazon SNS) topic to generate a notification every time the role is assumed by a user.
Configure a service control policy (SCP) that prevents non-administrative users from creating or editing security groups. Create a notification in the ticketing system when a user requests a rule that needs administrator permissions.
Explanations:
While a Lambda script could monitor security groups and notify when SSH is open to 0.0.0.0/0, it requires custom development and ongoing maintenance, which adds operational overhead.
Enabling the restricted-ssh AWS Config managed rule automates compliance checks for security groups. It generates an SNS notification when a rule allows SSH from 0.0.0.0/0, providing immediate alerts with minimal operational effort.
Creating an IAM role with permissions for security groups and ACLs does not directly address the compliance policy. It may increase security risks and operational overhead by allowing non-compliant changes without proper monitoring.
While a service control policy (SCP) could limit changes to security groups, it does not directly monitor or notify about non-compliance. The approach requires users to request changes, which could delay compliance enforcement and increase operational complexity.
From my perspective, the answer is:
Enable the restricted-ssh AWS Config managed rule and generate an Amazon Simple Notification Service (Amazon SNS) notification when a noncompliant rule is created.