CDN이나 WAF를 적용했다고 해서 원본 서버가 자동으로 비공개가 되는 것은 아니다. CDN과 WAF는 자신을 통과한 요청만 검사한다. 원본의 Public IP, 이전 DNS Record, 다른 Hostname, 직접 연결할 수 있는 Port, IPv6 주소나 Load Balancer Endpoint가 남아 있고 원본이 그 요청을 받아들인다면, 앞단의 WAF·Rate Limit·Bot·DDoS 통제를 건너뛸 수 있다.
원본 보호의 목표는 주소를 아무도 모르게 만드는 것이 아니다. 원본 주소가 알려지더라도 승인된 Edge 경로가 아니면 애플리케이션에 도달하지 못하게 만드는 것이다. Cloudflare, AWS, Azure의 현재 공식 문서도 직접 Origin 접근을 막으려면 공개 경로 제거, 네트워크 제한, Origin 인증 중 하나 이상을 원본 쪽에서 실제로 강제해야 한다고 설명한다.
앞단 통제들이 각각 무엇을 막고 어디에 공백을 남기는지는 WAF·API Gateway·Rate Limit·Schema Validation·JWT·mTLS 비교 글 에서 다뤘다. 이번 글은 그중 Direct-Origin 우회 경로를 찾고 닫는 문제에 집중한다.
원본 우회는 세 가지 조건이 동시에 맞을 때 성립한다
원본 노출을 한 단어로 표현하면 조치의 우선순위가 흐려진다. 이 글에서는 다음 세 조건으로 나눈다.
원본 우회 경로 성립
= Endpoint를 식별할 수 있음
AND 인터넷 또는 다른 비승인 경로에서 직접 연결할 수 있음 AND Origin이 그 연결과 요청을 정상 요청으로 수락함
예를 들어 원본 Hostname이 공개돼 있어도 Private Network 안에만 있어 외부 Route가 없다면 직접 연결할 수 없다. 반대로 Public IP가 있어도 Origin이 특정 Client Certificate를 제시한 Edge 연결만 수락한다면 일반 요청은 애플리케이션에 도달하지 못한다.
주소 교체나 DNS 정리는 첫 번째 조건인 발견 가능성을 낮춘다. Firewall과 Private Network는 두 번째 조건인 직접 연결 가능성을 줄인다. mTLS, Origin Authentication, 배포별 식별자와 Secret Header는 세 번째 조건인 요청 수락을 제한한다.
한 계층만으로도 특정 경로를 끊을 수는 있다. 그러나 설정 변경과 운영 실수를 감안하면, 이 글의 권장 감사 기준은 네트워크 경로와 Origin Identity 중 두 계층을 독립적으로 확인하는 것이다. NIST의 Zero Trust 원칙도 네트워크 위치 자체를 신뢰 근거로 삼지 않고 Resource 앞의 Policy Enforcement Point가 매 요청을 통제하도록 요구한다.
사용자 │ ▼ CDN / WAF / Edge │ │ Private Route 또는 │ 제한된 Network + 인증된 Origin Connection ▼ Origin / Load Balancer / Application
인터넷 ──────── X ────────> Origin Public Route
비승인 Edge ─── X ────────> Origin Authentication 관리자 ───── 별도 경로 ───> Management Plane 원본 서버가 노출되는 주요 경로 Public IP는 DNS를 가렸다고 없어지지 않는다
정식 서비스 도메인이 CDN의 IP만 반환하더라도 VM, Load Balancer, Kubernetes Ingress나 방화벽 장비에 Public IP가 남아 있을 수 있다. DNS Proxy는 이름을 조회했을 때 Origin IP를 바로 보여주지 않게 할 뿐, 그 주소가 인터넷에서 연결 가능한 상태 자체를 제거하지는 않는다.
Cloudflare도 DNS-only Record와 이전 DNS 기록에 Origin IP가 남을 수 있으므로, 기존 Record를 감사하고 Edge 전환 후 Origin IP를 교체하도록 안내한다. 다만 IP 교체는 과거 주소를 무효화하고 새 주소의 노출 가능성을 낮추는 조치일 뿐이다. 새 IP가 다시 인터넷에 열려 있고 직접 요청을 수락한다면 구조적인 문제는 남아 있다.
이전 DNS와 인증서 정보는 방어 감사 단서다
삭제한 A·AAAA·CNAME Record도 과거 기록이나 운영 문서에 남아 있을 수 있다. 공개 TLS 인증서가 Certificate Transparency Log에 기록되는 환경에서는 인증서에 포함된 이름도 자산 감사의 단서가 된다. RFC 9162는 공개 TLS 인증서를 누구나 감사할 수 있는 Log에 기록하는 구조를 정의한다.
여기서 잘못된 결론은 “이름을 모두 숨겨야 한다”는 것이다. 공개 인증서와 DNS는 본질적으로 공개될 수 있는 정보다. 운영자는 자신이 관리하는 Domain과 Certificate Inventory에서 과거 이름을 확인하되, 최종 방어는 해당 이름으로 직접 연결해도 요청이 거부되는 상태로 만들어야 한다.
Alternate Hostname과 기본 Endpoint가 정식 도메인을 우회한다
정식 도메인만 CDN을 통과하고 다음과 같은 주소는 원본으로 직접 연결되는 경우가 있다.
Origin 전용 Hostname
과거 서비스 도메인
Staging·Preview·Beta Hostname
클라우드 공급자가 자동으로 만든 Load Balancer DNS Name
Serverless·PaaS의 기본 Domain
Kubernetes Ingress나 Gateway의 별도 주소
외부 연동을 위해 남겨 둔 Backend Endpoint
이 경로들이 업무상 필요하다면 정식 Edge와 동일한 Network·Identity 통제를 적용해야 한다. 필요하지 않다면 Public Access를 끄거나 폐기해야 한다.
Host Header나 SNI를 예상 값으로 제한하는 것은 Default Virtual Host가 애플리케이션을 노출하는 실수를 줄여 준다. 그러나 Hostname은 비밀정보가 아니므로, Host 검증만으로 Edge Identity를 대신할 수는 없다.
80·443만 막고 다른 Port를 열어 두기도 한다
Origin 보호 정책이 80·443에만 적용되고 별도 Web Port, Debug Port, Health Port, 관리 Panel이나 임시 Listener가 전체 인터넷에 열려 있을 수 있다. Container Port나 Backend Service가 Public Load Balancer를 거치지 않고 Node·VM에 직접 노출되는 경우도 같은 문제다.
감사는 “웹 서비스는 443을 쓴다”는 설계 문서가 아니라 다음을 기준으로 해야 한다.
Cloud Firewall과 Security Group
Network ACL
Load Balancer Listener
Host OS Listener
Container·Kubernetes Service
Ingress·Gateway
방화벽 Port Forwarding
현재 Runtime에서 실제로 Listen하는 Port
필요한 Health Check가 있다면 전체 인터넷이 아니라 공급자가 명시한 Health Check Source나 내부 Monitoring 경로만 허용한다.
IPv6는 IPv4 Firewall의 연장이 아니다
Dual-stack 환경에서는 IPv4와 IPv6가 별도의 연결 경로다. IPv4 Public IP를 닫았더라도 AAAA Record, VM의 Global IPv6, Dual-stack Load Balancer나 ::/0 Inbound Rule이 남아 있으면 IPv6를 통해 직접 연결될 수 있다.
AWS의 공식 문서도 0.0.0.0/0과 ::/0을 서로 별도의 Anywhere 규칙으로 다루며 IPv6 운영 시 별도 Inbound Rule과 Flow Log 검토가 필요하다고 설명한다. CISA도 IPv6가 활성화됐다면 IPv4와 동등한 관리 Plane 통제를 적용하도록 권고한다.
“우리는 IPv6를 사용하지 않는다”는 설명만으로는 충분하지 않다. DNS, Load Balancer, VM Interface, Container Network와 Firewall에서 실제 활성 상태를 확인해야 한다.
Management Port가 Application Origin과 섞여 있다
SSH, RDP, 서버 관리 Panel, Database Admin, Kubernetes Dashboard 같은 관리 Interface가 애플리케이션 Origin과 같은 Public IP에 열려 있으면 CDN과 WAF는 이 경로를 보호하지 못한다. 일반적인 HTTP 요청을 검사하는 Edge와 시스템 관리 접근은 보호 대상, 사용자, Protocol, 가용성 요구가 다르다.
이번 글에서는 VPN·Bastion·Identity-aware Access 중 무엇을 선택할지는 비교하지 않는다. 적용할 원칙은 하나다.
Application Data Plane과 Management Plane은 서로 다른 접근 경로와 정책으로 분리한다.
Cloud Resource Metadata와 공개 자산이 Endpoint를 드러낸다
클라우드 Console이나 IaC에는 Public IP, LB DNS Name, Serverless 기본 URL, Ingress Address와 Service Endpoint가 기록된다. CI Output, 운영 문서, Public Repository, Status Page에 같은 정보가 복사될 수도 있다.
브라우저에 전달되는 HTML·JavaScript·Configuration, Source Map, Redirect Body도 내부 IP나 민감 Route를 포함할 수 있다. OWASP WSTG는 Client-side JavaScript와 Source Map이 내부 주소, API 정보와 Debug 정보를 노출할 수 있으므로 Production Asset을 검토하도록 안내한다.
공개 Client가 호출해야 하는 API Endpoint는 당연히 공개될 수 있다. Endpoint가 보인다는 사실 자체가 취약점은 아니다. 문제는 그 Endpoint가 WAF나 Gateway를 우회하는 별도 경로이고 Origin이 이를 정상 요청으로 받아들이는 경우다.
Exposure Path × Mitigation Matrix
| 노출 경로 | 방어 감사에서 확인할 Evidence | 1차 완화 | 보조 통제 | 남는 주의점 |
|---|---|---|---|---|
| Origin Public IPv4 | VM·LB·Ingress의 Public IP Inventory, Route, Firewall, Security Group, Edge Origin 설정 | Public IP·Internet Route 제거 또는 Private Origin 전환. 공개가 필요하면 Default-deny 후 승인된 Edge Source만 허용 | 계정·배포별 Origin Authentication, mTLS, Default Listener Deny | IP를 숨기거나 바꾸는 것만으로는 접근통제가 되지 않는다 |
| Old DNS Record | 현재 Zone뿐 아니라 Migration Record, 폐기 대상 Record, 과거 운영 문서와 인증서 Inventory | Stale Record 제거, Edge 전환 후 Origin 주소 교체, 이전 IP·Host의 연결 경로 폐기 | DNS 변경 Review, 소유자와 폐기일 기록 | 공개된 과거 기록을 완전히 없앤다고 가정하지 않는다 |
| Alternate Hostname | Origin Alias, Preview·Staging·Legacy Domain, PaaS·Serverless 기본 Domain | 불필요한 Public Domain 비활성화. 필요한 Host에는 정식 경로와 같은 제한 적용 | 예상 Host·SNI만 수락, Default Virtual Host에서 고정 거부 | Hostname 검증은 Edge Identity가 아니다 |
| Direct Port | 모든 LB·VM·Container·Ingress Listener, Port Forward, Health·Debug Port | 사용하지 않는 Listener 폐쇄. 필요한 Port는 승인된 Source와 Private Network로 제한 | Listener별 mTLS·Token·Fixed Deny, Port Owner 지정 | 443이 안전해도 다른 Listener가 애플리케이션을 노출할 수 있다 |
| IPv6 | AAAA Record, Global IPv6, Dual-stack LB, IPv6 Route, ::/0 Rule, IPv6 Flow Log | IPv4와 동일한 Default-deny·Allowlist 또는 Private Route 적용 | IPv4·IPv6를 분리한 Negative Test와 Drift Check | IPv4 Rule이 IPv6에 자동 적용된다고 가정하지 않는다 |
| Management Port | SSH·RDP·Control Panel·DB Admin·Cluster Admin Endpoint와 Public Route | Application Origin과 Management Plane 분리. 인터넷 Public Listener 제거 | 사용자·기기 Identity, MFA, 승인·감사, 별도 Break-glass 정책 | 관리 접근의 가용성과 비상 절차는 별도로 설계해야 한다 |
| Load Balancer·Backend Endpoint | Public LB DNS, Backend Service, Target 직접 주소, Serverless 기본 URL | Private LB·Private Endpoint·VPC Origin 또는 Public Access Disable | 공급자 IP Range와 배포별 Identity를 함께 검증 | Health Check, Protocol, 상품별 Private Origin 지원 제한 확인 필요 |
| Certificate·Historical DNS Clue | Certificate Inventory와 SAN, 조직 소유 Domain의 CT Monitoring, 이전 DNS 변경 기록 | 이름을 비밀로 보지 않고 해당 Endpoint의 Route·Origin Auth를 폐쇄 | 불필요한 Origin 전용 공개 이름 축소, 환경별 Certificate 분리 | 공개 TLS 이름과 DNS 기록은 감사 가능한 정보로 남을 수 있다 |
| Cloud Metadata·Public Asset | Cloud Resource Inventory, IaC·CI Output, Public Repository, JS·Source Map·Config·Redirect Body | 불필요한 내부 Endpoint와 Credential 제거, Debug Asset 배포 제한 | Origin 직접 접근 거부, Secret Scanning, Release Review | 공개 API 이름은 정상일 수 있다. 노출 여부와 접근 허용 여부를 분리해야 한다 |
이 표는 특정 공급자의 공식 등급표가 아니다. Cloudflare, AWS, Azure, Akamai, Google Cloud, NIST, IETF와 OWASP의 현재 문서를 Origin Security 질문에 맞게 통합한 편집 판단이다.
HTTPS 연결과 Origin 접근통제는 다르다
일반적인 HTTPS 연결에서 Client가 인증서를 정상 검증하면 Origin Server의 신원과 전송 구간의 기밀성·무결성을 보호할 수 있다. 그러나 HTTPS를 사용한다는 사실만으로 누가 Origin에 연결할 수 있는지가 제한되지는 않는다.
TLS 1.3의 현행 규격인 RFC 9846은 TLS가 도청·변조·메시지 위조를 방지하기 위한 Protocol임을 설명하고 RFC 9525는 Client가 접속하려는 서비스 이름과 Server Certificate의 Identity를 검증하는 절차를 정의한다. 이들은 Origin으로 가는 연결을 안전하게 만들지만 일반 Server-authenticated TLS만으로는 Client가 CDN Edge인지 일반 Client인지 구분하지 않는다.
Origin이 Client Certificate까지 요구하는 mTLS를 사용하면 Edge가 허용된 Certificate의 Private Key를 보유했는지 확인할 수 있다. 다만 인증서가 공급자 전체에 공유되는지, 특정 계정·Zone·Hostname에 전용인지에 따라 증명하는 Identity의 범위가 다르다. Cloudflare의 Global AOP와 계정 전용 AOP 구분이 그 예다.
어떤 방어 모델을 선택해야 할까
공개 Route를 제거할 수 있다면 Private Origin을 우선한다
Origin을 Private Subnet, Private Link, VPC Origin, 내부 Load Balancer 등에 배치하고 Edge가 관리하는 Private Path로만 연결하면 Public IP·과거 DNS·직접 Port 문제를 구조적으로 줄일 수 있다.
AWS CloudFront VPC Origin은 Private Subnet의 ALB·NLB·EC2를 Origin으로 사용할 수 있고 Azure Front Door는 지원되는 Origin에 Private Link를 사용할 수 있다. Google Cloud도 인터넷에서 VM의 외부 IP로 직접 연결하는 구조를 권장하지 않는다.
Private Origin이 항상 가능한 것은 아니다. Protocol, Load Balancer 유형, Region, Health Check, 기존 네트워크, 공급자 상품 등에서 제한이 있을 수 있다. 예를 들어 현재 AWS VPC Origin은 지원 Resource와 NLB TLS Listener 등에 제한이 있다. 설계 전에 현재 공식 지원 범위를 다시 확인해야 한다.
Outbound Tunnel·Connector는 Inbound Listener를 없앨 수 있다
Origin에서 Edge Network로 outbound-only 연결을 만들면 인터넷에서 Origin으로 들어오는 Public Listener를 제거할 수 있다. Cloudflare Tunnel이 이 유형이며 Cloudflare 문서는 Publicly Routable IP 없이 Origin을 연결한다고 설명한다.
이 모델에서는 다음 운영 요소가 새로 중요해진다.
Connector Credential 보호와 회전
Connector Instance의 고가용성
Tunnel 단절 시 Failover
Health Check와 배포 순서
공급자 장애·종속성
Tunnel을 거치지 않는 잔여 Public Route의 폐쇄
Cloudflare의 경우 Tunnel Origin에는 Inbound Listener가 없으므로 AOP를 중복 적용하는 방식이 아니며 Connector Credential이 Origin 연결을 인증한다.
Origin이 공개돼야 한다면 Network와 Identity를 함께 제한한다
Legacy 시스템, 공급자 지원 범위, 외부 연동 때문에 Origin의 Public Endpoint를 유지해야 할 수 있다. 이때는 최소한 다음 세 조건을 함께 구성한다.
Default-deny: 승인되지 않은 요청은 Application Handler에 전달하지 않는다.Network Source Restriction: 공급자가 관리하는 Prefix List, Service Tag, Stable CIDR 또는 Edge IP Range만 허용한다.
Origin Identity: 특정 계정·배포에서 온 요청임을 mTLS, 배포 식별자, 서명 또는 Origin Credential로 검증한다.
Azure Front Door는 Public Origin에서 Backend IP Filtering과 X-Azure-FDID Profile Identifier 검증을 함께 사용하도록 안내한다. IP 주소가 다른 Azure 고객과 공유되기 때문에 Network Source만으로는 특정 Front Door Profile을 증명하지 못하기 때문이다.
Akamai의 Origin IP ACL과 같은 Stable IP Allowlist도 Origin Firewall 운영을 단순화할 수 있다. 그러나 가능한 경우 연결 주체를 인증하는 mTLS·Origin Authentication을 함께 검토해야 한다. Akamai TechDocs
mTLS는 Identity가 필요한 곳에서 사용한다
mTLS는 Origin이 Client Certificate를 검증해 Edge 또는 호출 서비스의 Identity를 확인해야 할 때 적합하다.
특히 다음 조건에서 가치가 크다.
Origin이 Public Network에 남아 있어야 한다.
특정 CDN 계정·배포나 B2B Client만 허용해야 한다.
Shared Provider IP Range만으로는 Identity 범위가 너무 넓다.
인증서 발급·배포·회전·폐기 체계를 운영할 수 있다.
TLS가 종료되는 모든 Hop에서 Identity가 유지되는지 검증할 수 있다.
반대로 인증서 Inventory와 자동 회전, Key 보호, Revocation, 만료 경보가 없는 조직에서는 mTLS가 새로운 장애 원인이 될 수 있다. 한 인증서를 여러 Origin이 공유하거나 Proxy에서 검증한 결과를 위조 가능한 Header로 넘기면 기대한 Identity 경계도 약해진다.
Secret Header는 보조 통제로 다룬다
CDN이 Origin Request에 비밀 Header를 추가하고 Origin이 일치하는 요청만 전달하는 방식은 Legacy 환경에서도 적용하기 쉽다. AWS도 공개 ALB를 CloudFront 뒤에 둘 때 이 패턴과 Default 403 Rule을 공식적으로 안내한다.
다만 이 방법은 Header 이름과 값이 유출되지 않는다는 전제에 의존한다. AWS 문서도 이를 Credential처럼 취급하고 HTTPS로 보호하며 주기적으로 회전해야 한다고 명시한다.
따라서 Secret Header를 사용할 때는 다음을 지킨다.
일반 Client가 보내는 Header와 이름을 분리한다.
Secret Manager 등에서 관리한다.
Log·Trace·Error Page에 값을 남기지 않는다.
무중단 이중 값 방식으로 회전한다.
누락·오류 요청은 Application에 전달하지 않는다.
가능한 경우 Edge IP Allowlist와 함께 사용한다.
장기적으로 Private Path나 강한 Origin Authentication으로 전환할지 검토한다.
Origin Exposure Audit Checklist
아래 Checklist는 조직이 소유하거나 명시적으로 감사 권한을 가진 자산에만 사용한다.
범위와 자산 목록
감사 대상 서비스·환경·Domain·Cloud Account·Network 범위를 확정했는가
Production뿐 아니라 Staging·Preview·Test·Legacy 환경도 포함했는가
현재 A·AAAA·CNAME Record를 수집했는가
이전·폐기 예정 DNS Record와 Migration 기록을 확인했는가
VM·Load Balancer·Ingress·Gateway·Firewall의 모든 Public IPv4를 확인했는가
Global IPv6와 Dual-stack 설정을 별도 확인했는가
Public LB DNS Name과 Backend Service Endpoint를 확인했는가
PaaS·Serverless·Object Storage의 기본 Domain을 확인했는가
Origin Alias, Preview, Beta, Legacy Hostname을 확인했는가
Certificate Inventory와 SAN에 포함된 이름을 확인했는가
서비스별 업무 책임자와 기술 책임자가 지정돼 있는가
API와 Endpoint의 범위가 불명확하다면 먼저 API Inventory 운영 가이드
에서 DNS·LB·Serverless·Runtime Route를 대조해야 한다.
네트워크와 Listener
Origin에 Public IP가 정말 필요한지 검토했는가
Private Subnet·Private Link·VPC Origin·Tunnel로 전환 가능한지 확인했는가
Public Origin이라면 Inbound 기본값이 Default-deny인가
공급자가 관리하는 최신 Edge Source Range·Prefix List·Service Tag만 허용하는가
공급자 IP 변경을 수동 복사본이 아니라 관리 가능한 방식으로 반영하는가
Load Balancer Listener 전체를 확인했는가
Host OS에서 실제 Listen 중인 Port를 확인했는가
Container·Kubernetes Service·Ingress가 Node나 VM을 직접 노출하지 않는가
Health Check Source가 필요한 범위보다 넓지 않은가
사용하지 않는 HTTP·HTTPS·Debug·관리 Listener를 폐쇄했는가
0.0.0.0/0과 ::/0을 서로 별도로 검토했는가
IPv6 Flow Log 또는 동등한 Network Evidence를 수집하는가
Origin Identity와 Request Acceptance
Origin이 단순히 “공급자 네트워크”만 확인하는지, “우리 계정·배포”까지 확인하는지 구분했는가
Shared Edge IP Allowlist만으로 충분하다고 가정하지 않았는가
mTLS, 배포별 인증서, 서명 요청, Provider Identifier 또는 Origin Token 중 적절한 방식을 선택했는가
Origin Authentication이 모든 Hostname과 Listener에 일관되게 적용되는가
인증 정보가 없는 요청을 Application에 전달하지 않는가
잘못된 인증 정보가 있을 때 고정 거부 응답 또는 연결 거부가 발생하는가
Secret Header를 사용하는 경우 Credential처럼 보관·회전하는가
Header·Certificate 정보가 Access Log, Trace, Error Report에 과도하게 남지 않는가
인증서 만료·회전·폐기 책임자와 자동화가 있는가
Edge 설정 변경과 Origin 설정 변경의 배포 순서가 정의돼 있는가
Host·TLS·기본 응답
Origin TLS Certificate와 기대하는 Service Identity가 일치하는가
Edge가 Origin Certificate를 실제로 검증하는가
예상하지 않은 Host Header와 SNI를 Default Virtual Host에서 거부하는가
직접 IP 요청이 인증서 오류만 일으키는 상태를 접근통제로 간주하지 않는가
Alternate Hostname에도 동일한 Origin Authentication이 적용되는가
Default Listener가 Application Content나 상세 Error를 반환하지 않는가
Redirect Response가 내부 Hostname이나 관리 경로를 노출하지 않는가
HTTP에서 HTTPS로 전환하는 Listener도 승인된 Edge Source만 처리하는가
Management Plane과 공개 자산
SSH·RDP·Control Panel·Database Admin을 Application Origin과 분리했는가
관리 Interface가 Public Internet에 직접 노출되지 않는가
관리 접근에는 사용자·기기 Identity와 감사 기록이 남는가
비상 접근 경로가 평상시 우회 경로로 사용되지 않는가
Frontend JavaScript와 Configuration에 불필요한 Origin 주소가 없는가
Production Source Map·Debug Asset의 공개 필요성을 검토했는가
Public Repository, IaC Output, CI Artifact에 Endpoint·Credential이 노출되지 않는가
Status Page와 운영 문서가 내부 Origin·관리 주소를 공개하지 않는가
Endpoint 정보와 Secret을 구분해, 공개 Endpoint를 억지로 비밀정보처럼 관리하지 않는가
Negative Test와 운영 증거
정식 CDN·WAF 경로에서는 서비스가 정상 동작하는가
Origin Public IPv4로 직접 연결했을 때 Application Content가 반환되지 않는가
Origin IPv6로 직접 연결했을 때도 같은 결과인가
이전 IP·Old Hostname·Alternate Hostname이 요청을 수락하지 않는가
Public LB·Backend 기본 Endpoint가 Application을 노출하지 않는가
비승인 Port와 Management Port가 외부에서 연결되지 않는가
Origin Authentication이 누락되거나 잘못됐을 때 요청이 거부되는가
다른 계정·배포의 Edge Traffic이 허용되지 않는가
거부된 직접 요청이 Origin·Firewall·LB Log에 남는가
Edge를 통과한 요청과 거부된 직접 요청을 Log에서 구분할 수 있는가
거부 응답이 Framework·Version·Internal Hostname을 과도하게 노출하지 않는가
DNS·CDN·LB·Firewall·Certificate 변경 후 같은 검증을 반복하는가
임시 허용 Rule에 만료 시각·Owner·변경 사유가 있는가
Drift Detection 또는 정기 재감사 주기가 정해져 있는가
원본이 보호됐다고 판정할 수 있는 기준
| 검증 항목 | 통과 기준 |
|---|---|
| 정식 Edge 경로 | 정상적인 사용자 요청이 기대한 기능과 응답을 반환한다 |
| Public IPv4·IPv6 직접 경로 | TCP·TLS 계층에서 거부되거나, Application 앞에서 고정 거부된다. 실제 Application Content가 반환되지 않는다 |
| Old·Alternate Hostname | 폐기됐거나 정식 Edge와 같은 Network·Origin Identity 정책을 강제한다 |
| Public LB·Backend Endpoint | Private이거나 직접 요청을 전달하지 않는다 |
| Origin Authentication | Credential·Certificate·Identifier 누락 및 오류 요청이 모두 거부된다 |
| Management Plane | 일반 인터넷과 Application Origin 경로에서 접근할 수 없다 |
| 로그와 관측 | 승인된 Edge Traffic과 직접 접근 시도를 구분하고 추적할 수 있다 |
| 변경 후 재검증 | DNS·IP·CDN·LB·Certificate·Firewall 변경 때마다 Negative Test Evidence가 갱신된다 |
단순히 Origin 주소를 찾지 못했다는 결과는 통과 증거가 아니다. 주소가 우연히 알려지지 않은 것과 직접 요청을 거부하도록 설계된 것은 다르다.
CDN과 WAF는 앞문이다
CDN과 WAF는 중요한 Edge Control이지만 건물의 모든 출입구를 자동으로 잠그지는 않는다. Origin Public IP, 이전 DNS, 다른 Hostname, IPv6, Direct Port, Management Interface와 Backend Endpoint를 별도로 확인해야 한다.
가장 직접적인 방어는 Public Route를 없애는 것이다. 공개 Origin을 유지해야 한다면 Network Source와 Origin Identity를 함께 제한한다. 주소 교체, Host 검증, Secret Header는 그 위에 더하는 보조 통제로 다루는 편이 안전하다.
최종 판정은 설정 화면이 아니라 Negative Test로 내려야 한다.
승인된 Edge 경로는 동작하고 그 밖의 직접 경로는 애플리케이션에 도달하지 않는다.
이 상태를 증명할 수 있어야 CDN과 WAF가 실제로 우회하기 어려운 통제가 된다.
공식 참고자료
- https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/
- https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/
- https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html
- https://techdocs.akamai.com/site-shield/reference/api