12 KiB
title, source_type, url, archive_url, related_branches, related_projects, tags, created
| title | source_type | url | archive_url | related_branches | related_projects | tags | created | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| official-doc / AWS CloudFront — Restrict access to Application Load Balancers (origin custom header + prefix list) | official-doc | https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html |
|
|
|
2026-07-16 |
AWS CloudFront — Restrict access to Application Load Balancers (origin custom header + prefix list)
Layer:
raw/— 외부 자료(공식 문서)의 원문 발췌·출처 기록. 검증된 요약은/ingest후wiki/concepts/에source-summary-template형식으로 별도 작성. 원본은 raw에 영구 보관.
Parent / 활용 branch (필수, 최소 1개+)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-keycloak-header-spoofing-defense | D5 — shared-secret internal header 패턴(엣지가 secret header 주입, origin 이 검증)은 AWS(CloudFront→ALB)가 공식 문서화한 mitigation 임을 뒷받침. 헤더 값을 secure credential 로 취급하고 make-before-break 로 회전해야 하며, secret 유출 시 전면 우회되므로 network-layer 제한(2차 방어)과 반드시 병행해야 한다는 결론의 vendor-doc 근거 |
출처 / Source
- 원본 URL: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html
- 아카이브 URL: (미제공)
- 저자 / 조직: Amazon Web Services — Amazon CloudFront Developer Guide
- 발행일: 페이지에 발행일 명시 없음 (AWS 공식 개발자 가이드, 버전 관리형 상시 갱신 문서)
- 마지막 확인일: 2026-07-16
왜 저장했는지 / Why archived
feature-keycloak-header-spoofing-defense D5(shared-secret 헤더는 defense-in-depth 2차, 1차는 network 격리)가 이전엔 UNSUPPORTED_DECISION(vendor 인용 부재, 자체 메모)였다. 이 문서는 CloudFront→ALB 맥락에서 동일 패턴(엣지가 custom header 주입, origin 이 그 header 존재로만 요청을 필터링)을 AWS 가 공식적으로 기술하며, 헤더를 credential 로 취급하라는 권고·헤더 유출 시 전면 우회된다는 명시적 경고·network-layer(prefix list) 병행 권고·make-before-break 회전 절차까지 모두 명시한다. D5 를 official-vendor-doc 등급 근거로 승격시키기 위해 보관.
핵심 인용 / Key quotes (verbatim, 5개)
[§Configure CloudFront to add a custom HTTP header to requests] "Configure CloudFront to add a custom HTTP header to requests that it sends to the Application Load Balancer."
[§Configure an Application Load Balancer to only forward requests that contain a specific header] "Configure the Application Load Balancer to only forward requests that contain the custom HTTP header."
[§Configure CloudFront to add a custom HTTP header to requests] "In production, use randomly generated header names and values. Treat header names and values as secure credentials, like usernames and passwords."
[§Configure CloudFront to add a custom HTTP header to requests, Important callout] "This use case relies on keeping the custom header name and value secret. If the header name and value are not secret, other HTTP clients could potentially include them in requests that they send directly to the Application Load Balancer. This can cause the Application Load Balancer to behave as though the requests came from CloudFront when they did not. To prevent this, keep the custom header name and value secret."
[§(Optional) Limit access to origin by using the AWS-managed prefix list for CloudFront] "To further restrict access to your Application Load Balancer, you can configure the security group associated with the Application Load Balancer so that it only accept traffic from CloudFront when the service is using an AWS-managed prefix list. This prevents traffic that doesn't originate from CloudFront from reaching your Application Load Balancer at the network layer (layer 3) or transport layer (layer 4)."
[§(Optional) Improve the security of this solution — Rotate the header name and value] "In addition to using HTTPS, we also recommend rotating the header name and value periodically. The high-level steps for doing this are as follows:" — 이어지는 4단계 절차 중 make-before-break 순서를 보여주는 첫 단계와 마지막 단계: "Configure CloudFront to add an additional custom HTTP header to requests that it sends to the Application Load Balancer." ... "Update the Application Load Balancer listener rule to stop forwarding requests that contain the original custom HTTP header."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| CF-ALB-SECRET-C1 | CloudFront 는 origin(ALB)으로 보내는 요청에 custom HTTP header 를 추가하도록 설정할 수 있고, ALB listener rule 은 그 custom header 가 포함된 요청만 forward 하도록 설정할 수 있다(그 외는 고정 403 응답) | "Configure CloudFront to add a custom HTTP header to requests that it sends to the Application Load Balancer." / "Configure the Application Load Balancer to only forward requests that contain the custom HTTP header." | official-vendor-doc |
CloudFront(엣지)→ALB(origin) 구조에서의 shared-secret header 검증 패턴 일반. Keycloak/oauth2-proxy→backend 같은 다른 엣지·오리진 조합에 그대로 이식된다는 뜻은 아님(구조적 유사성만 인용 가능) | 이 메커니즘이 K8s NetworkPolicy 나 EC2 Security Group 을 대체할 만큼 충분하다는 것은 증명 안 함 — 문서 자체가 이를 별도 "improve security" 권고로 분리 |
| CF-ALB-SECRET-C2 | production 에서는 무작위 생성된 header 이름·값을 쓰고, header 이름/값을 username·password 같은 secure credential 로 취급하라 | "In production, use randomly generated header names and values. Treat header names and values as secure credentials, like usernames and passwords." | official-vendor-doc |
shared-secret header 의 생성·보관·취급 원칙(값의 무작위성, credential 급 보안 취급) | 구체적인 저장소(예: AWS Secrets Manager vs 환경변수)나 rotation 주기 수치는 명시 안 함 |
| CF-ALB-SECRET-C3 | header 이름과 값이 secret 으로 유지되지 않으면 다른 HTTP client 가 그 header 를 담아 ALB 에 직접 요청을 보낼 수 있고, 이 경우 ALB 는 실제로는 CloudFront 를 거치지 않은 요청도 CloudFront 를 거친 것처럼 처리한다 — 즉 secret 유출 = 이 메커니즘의 전면 우회 | "This use case relies on keeping the custom header name and value secret. If the header name and value are not secret, other HTTP clients could potentially include them in requests that they send directly to the Application Load Balancer. This can cause the Application Load Balancer to behave as though the requests came from CloudFront when they did not." | official-vendor-doc |
shared-secret header 패턴의 명시적 실패 모드(단일 장애점: secret 유출) | 유출 경로(로그 노출, 네트워크 스니핑 등) 자체는 다루지 않음 — 유출됐을 때의 결과만 서술 |
| CF-ALB-SECRET-C4 | ALB 에 연결된 security group 을 AWS-managed prefix list(CloudFront) 로 제한하면, CloudFront 를 거치지 않은 트래픽은 network layer(L3)/transport layer(L4) 에서부터 ALB 에 도달하지 못하게 막을 수 있다 | "To further restrict access to your Application Load Balancer, you can configure the security group associated with the Application Load Balancer so that it only accept traffic from CloudFront when the service is using an AWS-managed prefix list. This prevents traffic that doesn't originate from CloudFront from reaching your Application Load Balancer at the network layer (layer 3) or transport layer (layer 4)." | official-vendor-doc |
shared-secret header 검증(응용 계층, L7)을 network-layer 제한(L3/L4)과 병행해야 하는 근거 — "(Optional)" 로 표기되었으나 header 단독 사용의 실패 모드(C3)를 상쇄하는 유일한 공식 권고 | prefix list 제한 자체가 header 검증을 "대체"해도 된다고는 말하지 않음 — 문서는 두 메커니즘을 병행 옵션으로만 제시 |
| CF-ALB-SECRET-C5 | header 이름/값은 주기적으로 회전(rotate)하도록 권고되며, 절차는 (1) 새 custom header 추가 및 새 header 를 forward 하는 ALB rule 추가 → (2) 기존 header 를 CloudFront 가 더 이상 보내지 않도록 중단 및 기존 header 를 forward 하던 ALB rule 제거 순서다(신규 추가 후 기존 제거 — make-before-break) | "In addition to using HTTPS, we also recommend rotating the header name and value periodically." / "Configure CloudFront to add an additional custom HTTP header to requests that it sends to the Application Load Balancer." / "Update the Application Load Balancer listener rule to stop forwarding requests that contain the original custom HTTP header." | official-vendor-doc |
header 회전이 필요한 이유(주기적 노출 위험 감소)와 순서(추가 먼저, 제거 나중 — 4단계 절차의 1번과 4번이 각각 add-new, remove-old) | 정확한 회전 "주기"(예: N일마다) 는 수치로 명시하지 않음 — "periodically" 로만 서술 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
CF-ALB-SECRET-C1: CloudFront→ALB 맥락에서 "엣지가 header 주입 + origin 이 header 존재로 필터링" 패턴이 AWS 공식 mitigation 이라는 것CF-ALB-SECRET-C2: header 값을 secure credential 급으로 취급하라는 공식 권고CF-ALB-SECRET-C3: 이 패턴의 실패 모드가 "secret 유출 = 전면 우회"라는 것 (AWS 문서가 명시적으로 경고)CF-ALB-SECRET-C4: network-layer(prefix list/security group) 제한을 header 검증과 병행하라는 공식 권고CF-ALB-SECRET-C5: 회전 절차의 순서(add-new-before-remove-old)
- 이 자료가 증명하지 않는 것:
- Keycloak/oauth2-proxy/nginx auth_request 같은 다른 엣지-오리진 조합에서도 동일 mitigation 이 "충분"하다는 것 — 이 문서는 CloudFront↔ALB 조합에 한정된 AWS 공식 가이드
- K8s NetworkPolicy, EC2 Security Group inbound, mTLS 각각의 구체적 설정법 — 이 문서는 "AWS-managed prefix list" 방식만 다룸 (D3/D4/D2 의 근거로는 사용 불가)
- shared-secret header 단독으로 충분한지 여부 — 오히려 이 문서 자체가 "단독 사용은 실패 모드(C3)를 가지므로 network-layer 제한과 병행하라(C4)"는 구조로 D5 의 "network 격리 1차, header 는 2차" 결론과 정합
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- 학습 프로젝트의 실제 엣지(oauth2-proxy/nginx)-백엔드 조합에서 동일 make-before-break 회전을 재현 가능한지 (
raw/branch-notes/feature-keycloak-header-spoofing-defense§Claims To Verify 참조) - AWS 환경이 아닌 셀프호스팅 nginx/oauth2-proxy 조합에서 "AWS-managed prefix list" 대응물(예: 자체 IP allowlist)을 어떻게 구성할지
- 학습 프로젝트의 실제 엣지(oauth2-proxy/nginx)-백엔드 조합에서 동일 make-before-break 회전을 재현 가능한지 (
메모 / Notes
- 이 문서는 CloudFront/ALB 전용이지만, "엣지가 secret header 주입 + origin 이 header 존재만으로 필터링"하는 구조 자체는 P1A ForwardAuth 패턴(oauth2-proxy/nginx → backend)과 동형이다. D5 의 vendor-doc 근거로 인용하되, 구조적 유사성 인용이라는 점을 명시해야 함(직접 Keycloak/nginx 문서는 아님).
- C3(실패 모드)와 C4(network-layer 병행 권고)를 나란히 읽으면, AWS 문서 스스로가 "header 검증 단독으로는 불충분 → network-layer 로 보강"하는 구조를 권고하고 있음을 알 수 있음. D5 의 "network 격리 1차, shared-secret 2차" 결론과 직접 정합.
- 추가로 봐야 할 동일 출처 페이지: AWS-managed prefix list 블로그 포스트(문서 본문에서 링크된
Limit access to your origins using the AWS-managed prefix list for Amazon CloudFront) — prefix list 설정의 구체적 CLI/console 절차가 필요하면 별도 raw 로 보존 검토.
Related / 관련
- raw/branch-notes/feature-keycloak-header-spoofing-defense — 이 자료가 D5 의 근거로 인용되는 branch
- (같은 주제 다른 official-doc) K8s NetworkPolicy 공식 문서 — 아직 raw 미보존 (해당 branch TODO 참조)