원본 우회는 세 조건이 동시에 맞을 때 성립합니다
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 인증 중 하나 이상을 원본 쪽에서 실제로 강제해야 한다고 설명합니다.[2][7]
원본 노출을 한 단어로 표현하면 조치의 우선순위가 흐려집니다. 이 글에서는 세 조건으로 나눕니다. Endpoint를 식별할 수 있고, 인터넷 또는 다른 비승인 경로에서 직접 연결할 수 있으며, 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가 매 요청을 통제하도록 요구합니다.[1]
목표 상태는 한 문장으로 적힙니다. 사용자는 CDN과 WAF, Edge를 거쳐 Private Route 또는 제한된 Network와 인증된 Origin Connection으로만 Origin과 Load Balancer, Application에 도달합니다. 인터넷에서 Origin의 Public Route로 가는 길과 비승인 Edge에서 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를 교체하도록 안내합니다.[2] 다만 IP 교체는 과거 주소를 무효화하고 새 주소의 노출 가능성을 낮추는 조치일 뿐입니다. 새 IP가 다시 인터넷에 열려 있고 직접 요청을 수락한다면 구조적인 문제는 남아 있습니다.
이전 DNS와 인증서 정보는 방어 감사 단서입니다. 삭제한 A·AAAA·CNAME Record도 과거 기록이나 운영 문서에 남습니다. 공개 TLS 인증서가 Certificate Transparency Log에 기록되는 환경에서는 인증서에 포함된 이름도 자산 감사의 단서가 됩니다. RFC 9162는 공개 TLS 인증서를 누구나 감사할 수 있는 Log에 기록하는 구조를 정의합니다.[3] 여기서 잘못된 결론은 "이름을 모두 숨겨야 한다"는 것입니다. 공개 인증서와 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이 이를 정상 요청으로 받아들이는 경우입니다.
콘텐츠에 맞춰 전송 경로를 설계 — 파일의 갱신 방식에 맞춰 캐시를 나누고 엣지 전송 결과와 원본 부하를 함께 관측합니다.
경로별로 무엇을 확인하고 무엇으로 막는가
아래 표는 특정 공급자의 공식 등급표가 아닙니다. Cloudflare, AWS, Azure, Akamai, Google Cloud, NIST, IETF와 OWASP의 현재 문서를 Origin Security 질문에 맞게 통합한 편집 판단입니다.[1][2][5][6][7] 각 행의 마지막 열은 완화를 적용한 뒤에도 남는 주의점입니다.
노출 경로 | 감사에서 확인할 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 이름은 정상일 수 있다. 노출 여부와 접근 허용 여부를 분리한다 |
HTTPS 연결과 Origin 접근통제는 다릅니다
일반적인 HTTPS 연결에서 Client가 인증서를 정상 검증하면 Origin Server의 신원과 전송 구간의 기밀성·무결성을 보호합니다. 그러나 HTTPS를 사용한다는 사실만으로 누가 Origin에 연결할지가 제한되지는 않습니다.
TLS는 도청·변조·메시지 위조를 방지하기 위한 Protocol입니다. Client가 접속하려는 서비스 이름과 Server Certificate의 Identity를 검증하는 절차는 RFC 9525가 정의합니다.[4] 이들은 Origin으로 가는 연결을 안전하게 만들지만, 일반 Server-authenticated TLS만으로는 Client가 CDN Edge인지 일반 Client인지 구분되지 않습니다.
Origin이 Client Certificate까지 요구하는 mTLS를 쓰면 Edge가 허용된 Certificate의 Private Key를 보유했는지 확인합니다. 다만 인증서가 공급자 전체에 공유되는지, 특정 계정·Zone·Hostname에 전용인지에 따라 증명하는 Identity의 범위가 다릅니다. Cloudflare의 Global AOP와 계정 전용 AOP 구분이 그 예입니다.[5]
어떤 방어 모델을 선택해야 할까
공개 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 연결을 인증합니다.[5]
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을 함께 검토해야 합니다.[6]
mTLS는 Identity가 필요한 곳에서 씁니다. 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로 보호하며 주기적으로 회전해야 한다고 명시합니다.[7] 따라서 Secret Header를 쓸 때는 일곱 가지를 지킵니다. 일반 Client가 보내는 Header와 이름을 분리합니다. Secret Manager 등에서 관리합니다. Log·Trace·Error Page에 값을 남기지 않습니다. 무중단 이중 값 방식으로 회전합니다. 누락·오류 요청은 Application에 전달하지 않습니다. 가능하면 Edge IP Allowlist와 함께 씁니다. 장기적으로 Private Path나 강한 Origin Authentication으로 전환할지 검토합니다.
- Private Origin
- Private Origin은 원본을 Private Subnet이나 Private Link, VPC Origin, 내부 Load Balancer에 두고 Edge가 관리하는 경로로만 연결하는 구성입니다. Public IP와 과거 DNS, 직접 Port 문제를 구조적으로 줄입니다.
- Outbound Tunnel
- Outbound Tunnel은 원본에서 Edge Network로 나가는 연결만 만들어 인터넷에서 원본으로 들어오는 Public Listener를 없애는 방식입니다. Connector Credential이 원본 연결을 인증합니다.
- Origin Authentication
- Origin Authentication은 특정 계정이나 배포에서 온 요청임을 mTLS, 배포 식별자, 서명, Origin Credential로 원본이 직접 검증하는 통제입니다.
서비스 앞단에서 요청을 분류하고 방어 — 요청과 차단 기록을 살펴 방어 규칙을 조정하고 인증서와 접근 통제를 함께 관리합니다.
노출 감사는 여섯 영역으로 나눕니다
아래 체크리스트는 조직이 소유하거나 명시적으로 감사 권한이 있는 자산에만 사용합니다. 여섯 영역은 범위와 자산 목록, 네트워크와 Listener, Origin Identity와 요청 수락, Host·TLS·기본 응답, Management Plane과 공개 자산, Negative Test와 운영 증거입니다. API와 Endpoint의 범위가 불명확하다면 먼저 API Inventory 운영 문서에서 DNS·LB·Serverless·Runtime Route를 대조해야 합니다.
영역 | 점검 항목 |
|---|---|
| 범위와 자산 목록 | 감사 대상 서비스·환경·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에 포함된 이름을 확인했는가. 서비스별 업무 책임자와 기술 책임자가 지정돼 있는가 |
| 네트워크와 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와 요청 수락 | 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 또는 정기 재감사 주기가 정해져 있는가 |
원본이 보호됐다고 판정할 수 있는 기준
단순히 Origin 주소를 찾지 못했다는 결과는 통과 증거가 아닙니다. 주소가 우연히 알려지지 않은 것과 직접 요청을 거부하도록 설계된 것은 다릅니다. 아래 여덟 항목은 각각 Negative Test로 확인합니다.
검증 항목 | 통과 기준 |
|---|---|
| 정식 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가 갱신된다 |
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가 실제로 우회하기 어려운 통제가 됩니다.
