Question

Difficulty: MediumStrengthening Identity, Access, and Network Security

An enterprise runs a public-facing web application behind an Application Load Balancer (ALB) in a production VPC in Account A. To strengthen network and application security, the enterprise deploys an Amazon CloudFront distribution in front of the ALB. An AWS WAF WebACL is associated with the CloudFront distribution to inspect and filter inbound traffic. During a security audit, the team discovers that the ALB's DNS name is publicly resolvable, allowing malicious traffic to bypass the CloudFront distribution and target the ALB directly. The solution must ensure that only requests routed through CloudFront are accepted by the ALB. The team wants to secure the custom header value used for validation by storing it as a secret in AWS Secrets Manager in a centralized Security Account (Account B) and allowing Account A's resources to retrieve it. Which of the following is the most secure and operationally efficient configuration to prevent direct public access to the ALB while ensuring CloudFront can successfully forward requests?

  1. Configure CloudFront to inject a custom HTTP header containing a secret value. Set the ALB listener rules to forward traffic only when this header is present and matches the secret value, and restrict the ALB's security group to allow inbound traffic only from CloudFront IP ranges using the AWS-managed prefix list. Store the secret in AWS Secrets Manager in Account B, encrypted with a Customer Managed Key (CMK), and configure its key policy to allow cross-account access from Account A.Answer
  2. B
    Configure CloudFront to inject a custom HTTP header containing a secret value. Set the ALB listener rules to forward traffic only when this header is present and matches the secret value, and restrict the ALB's security group to allow inbound traffic only from CloudFront IP ranges using the AWS-managed prefix list. Store the secret in AWS Secrets Manager in Account B, encrypted with the default AWS-managed KMS key for Secrets Manager, and configure a cross-account IAM policy to allow Account A's resources to retrieve and decrypt the secret.
  3. C
    Configure CloudFront to inject a custom HTTP header containing a secret value. Set the ALB listener rules to forward traffic only when this header is present and matches the secret value, and attach a Service Control Policy (SCP) to the Root OU in AWS Organizations that explicitly allows traffic to the ALB only if the request originates from CloudFront, assuming this SCP automatically overrides local security group restrictions.
  4. D
    Associate a second AWS WAF WebACL directly with the ALB instead of modifying the security group. In this WebACL, configure the default action to Allow, and place a rule that blocks all traffic not originating from CloudFront IPs at the end of the rule evaluation list, following other application-specific rules, to ensure CloudFront requests are not inadvertently blocked.

Answer

Configure CloudFront to inject a custom HTTP header containing a secret value. Set the ALB listener rules to forward traffic only when this header is present and matches the secret value, and restrict the ALB's security group to allow inbound traffic only from CloudFront IP ranges using the AWS-managed prefix list. Store the secret in AWS Secrets Manager in Account B, encrypted with a Customer Managed Key (CMK), and configure its key policy to allow cross-account access from Account A.
The correct solution combines network-level protection (restricting the ALB security group to the CloudFront AWS-managed prefix list) and application-level verification (verifying a custom header injected by CloudFront). For cross-account retrieval of the secret from Account B, a Customer Managed Key (CMK) is required because AWS-managed KMS keys cannot have their key policies modified and cannot be shared across different accounts.

Step-by-Step Solution

1
Enforce network-level restriction on the Application Load Balancer (ALB).
The ALB's security group is configured to only allow inbound HTTP/HTTPS traffic from CloudFront edge servers using the AWS-managed prefix list (com.amazonaws.global.cloudfront.origin-facing).
This prevents direct client connections to the ALB from outside CloudFront's network ranges.
2
Configure application-level request validation using custom headers.
CloudFront is configured to inject a custom HTTP header (e.g., X-Origin-Verify) with a secret value on origin requests, and the ALB listener rule is configured to return a 403 response if the header is missing or incorrect.
This prevents attackers from forging requests directly to the ALB DNS name if they bypass the IP restriction.
3
Configure secure cross-account secret management.
The secret containing the header value is stored in Account B, encrypted using a KMS Customer Managed Key (CMK) with a key policy allowing cross-account decryption by Account A's role.
AWS-managed KMS keys do not support policy modifications and cannot be used for cross-account access, making a CMK mandatory.

Key Concept

Strengthening origin security for ALBs behind CloudFront using security group prefix lists, custom origin headers, and cross-account Customer Managed Keys (CMKs).
Rate this question