CDNとWAFを付けても原本サーバーが露出する理由と防ぎ方

原本の迂回は三条件が同時にそろって成立します

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、アプリケーションへ到達します。インターネットから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へ直接露出する場合も同じ問題です。監査は「Webサービスは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]} 各行の最後の列は、緩和を適用した後にも残る注意点です。

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と自動の回転、鍵の保護、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を照合します。

原本が保護されたと判定できる基準

単にOriginのアドレスを見つけられなかったという結果は通過の証拠になりません。アドレスがたまたま知られていないことと、直接の要求を拒否するよう設計されていることは別です。下の八項目はそれぞれNegative Testで確認します。

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が実際に迂回しにくい統制になります。