A financial services enterprise is designing a new centralized security administration por… — AWS Certified Solutions Architect - Professional

A financial services enterprise is designing a new centralized security administration portal inside a Shared Services account ( $111122223333$ ). Administrators managed in an external corporate identity provider (IdP) must federate into AWS using SAML 2.0 to assume an IAM role named `PortalAdminRole` in the Shared Services account.

The design must satisfy the following security and compliance requirements:
- Only federated users who belong to the "SecurityOps" group in the corporate IdP should be allowed to assume the `PortalAdminRole`.
- The federation request must originate from the company's corporate network public IP CIDR block of $198.51.100.0/24$ .
- The administration portal must write session logs to an Amazon S3 bucket located in a separate Security Account ( $444455556666$ ). These logs must be encrypted at rest using a key that ensures only the Shared Services account can use it to encrypt the logs.

Which configuration strategy should the security architect implement to meet these requirements?

A
Configure the trust policy of the `PortalAdminRole` in the Shared Services account with the SAML provider as the principal, the `sts:AssumeRoleWithSAML` action, and a condition evaluating `saml:memberOf` equals "SecurityOps" and `aws:SourceIp` in $198.51.100.0/24$ . Encrypt the S3 bucket in the Security Account using the default AWS-managed key `aws/s3`, and configure the S3 bucket policy to allow write access from the Shared Services account.
B
Configure the trust policy of the `PortalAdminRole` in the Shared Services account with the SAML provider as the principal, the `sts:AssumeRole` action, and a condition evaluating `saml:memberOf` equals "SecurityOps" and `aws:SourceIp` in $198.51.100.0/24$ . Encrypt the S3 bucket in the Security Account using a Customer Managed Key (CMK), and configure the KMS key policy to grant the `PortalAdminRole` permissions for `kms:GenerateDataKey` and `kms:Decrypt`.
Configure the trust policy of the `PortalAdminRole` in the Shared Services account with the SAML provider as the principal, the `sts:AssumeRoleWithSAML` action, and a condition evaluating `saml:memberOf` equals "SecurityOps" and `aws:SourceIp` in $198.51.100.0/24$ . Encrypt the S3 bucket in the Security Account using a Customer Managed Key (CMK), and configure the KMS key policy to grant the `PortalAdminRole` permissions for `kms:GenerateDataKey` and `kms:Decrypt`.Answer
D
Create a Service Control Policy (SCP) at the root organizational unit (OU) that permits users in the "SecurityOps" group from $198.51.100.0/24$ to assume the `PortalAdminRole` in the Shared Services account. Encrypt the S3 bucket in the Security Account using a Customer Managed Key (CMK), and configure the KMS key policy to grant the Shared Services account access to the key.

Answer

The configuration that sets up the trust policy of the `PortalAdminRole` with `sts:AssumeRoleWithSAML`, restricts access based on SAML attributes and source IP, and encrypts the S3 bucket using a Customer Managed Key (CMK) with cross-account KMS permissions.

The correct strategy uses `sts:AssumeRoleWithSAML` for the SAML federation trust relationship. It restricts access under the `Condition` block to only allow requests originating from the corporate IP range and where the SAML assertion contains the 'SecurityOps' group attribute. Furthermore, encrypting the cross-account S3 bucket with a Customer Managed Key (CMK) allows the security architect to modify the key policy in the Security Account to grant `kms:GenerateDataKey` and `kms:Decrypt` access to the `PortalAdminRole` in the Shared Services account.

Step-by-Step Solution

Determine the required STS action and principal for SAML federation.

The principal must be the SAML provider ARN and the action must be `sts:AssumeRoleWithSAML`.

SAML federation requests cannot use standard `sts:AssumeRole` and must use the specific SAML assume-role action.

Configure role trust policy conditions.

Evaluate `saml:memberOf` for group validation and `aws:SourceIp` for network perimeter control.

This enforces identity attribute validation and IP restriction directly on the STS assume-role call.

Determine key type for cross-account S3 encryption.

Select a Customer Managed Key (CMK) instead of the default AWS-managed `aws/s3` key.

AWS-managed keys cannot have their key policies edited and thus cannot be shared with principals in external accounts.

Key Concept

Designing secure federated access using SAML trust policies combined with cross-account resource encryption using Customer Managed Keys.

Estimated Time:2m 30s

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic