An enterprise has a multi-account AWS environment managed under AWS Organizations. Develop… — AWS Certified Solutions Architect - Professional

An enterprise has a multi-account AWS environment managed under AWS Organizations. Developers access resources in the member accounts by federating through AWS IAM Identity Center. A security audit of the existing setup reveals that developers can log in from any internet-facing location and perform actions. Additionally, some developers have accidentally disabled Amazon GuardDuty and Amazon Security Hub in their respective sandbox accounts.

The security team wants to implement a solution that:
1. Restricts all developer API operations to only be allowed when originating from the corporate office public IP range $203.0.113.0/24$ .
2. Ensures that AWS services can still perform actions on behalf of the developers (such as AWS CloudFormation deploying resources or Auto Scaling launching instances).
3. Prevents any IAM user or role in the member accounts from disabling GuardDuty or Security Hub.

Which solution meets these requirements with the least operational overhead?

Attach a Service Control Policy (SCP) to the organization's root. In the SCP, implement a Deny rule for all actions with a condition that denies access if the source IP is not in $203.0.113.0/24$ and the request is not made by an AWS service on behalf of the user. In the same SCP, include a Deny rule for actions matching guardduty:Delete*, guardduty:Disassociate*, guardduty:Update*, securityhub:Delete*, and securityhub:Disable*.Answer
B
Attach a Service Control Policy (SCP) to the organization's root that denies all actions if the source IP is not in $203.0.113.0/24$ . In the same SCP, deny all actions matching guardduty:Delete*, guardduty:Disassociate*, guardduty:Update*, securityhub:Delete*, and securityhub:Disable*.
C
Define an IAM permission boundary in each member account that denies all actions if the source IP is not in $203.0.113.0/24$ , and associate it with all IAM roles. Configure a local IAM policy in each account to deny access to GuardDuty and Security Hub modification APIs. Use AWS CloudFormation StackSets to deploy these policies to all accounts.
D
Update the trust policies of the IAM roles provisioned by IAM Identity Center in each member account to include a condition that restricts the sts:AssumeRole action to requests originating from $203.0.113.0/24$ . Deploy an SCP that denies GuardDuty and Security Hub modification actions across the organization.

Answer

The correct solution is to attach a Service Control Policy (SCP) to the organization's root that implements a Deny rule for all actions with a condition denying access if the source IP is not in the corporate range and the request is not made via an AWS service (using the aws:ViaAWSService context key), and also includes a Deny rule for GuardDuty and Security Hub modification actions.

The correct solution attaches an SCP to the root of the organization to centrally manage security boundaries. By using a Deny statement with a NotIpAddress condition for the corporate CIDR range alongside a condition checking if aws:ViaAWSService is false, it ensures that direct user requests must originate from the corporate network, while legitimate AWS service-to-service operations triggered by users are permitted. Explicitly denying GuardDuty and Security Hub deletion/disabling actions in the same SCP ensures that no principal in the member accounts can turn off these monitoring services.

Step-by-Step Solution

Select the correct policy mechanism for global enforcement.

Identify that Service Control Policies (SCPs) are required to enforce boundaries across all member accounts in the organization, overriding local administrator actions.

SCPs apply to all IAM users and roles in member accounts, including the root user, ensuring consistent governance.

Configure the IP restriction logic while avoiding disruption to AWS services.

Use a Deny policy with a condition block that checks if the source IP is not in the corporate range, combined with a condition that checks if the request is NOT made via an AWS service.

AWS services frequently call other services on behalf of users (e.g., CloudFormation creating an EC2 instance). These calls originate from AWS IP space, not the corporate network, so they must be exempted using the aws:ViaAWSService context key.

Enforce protection for GuardDuty and Security Hub.

Add explicit Deny statements for deletion and disabling actions of GuardDuty and Security Hub in the SCP.

A Deny statement in an SCP cannot be overridden by any Allow policy within the member accounts, preventing accidental or malicious configuration changes.

Key Concept

Enforcing network boundaries globally across an AWS Organization using SCPs while preserving AWS service integrations with the aws:ViaAWSService context key.

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics