はじめに
CloudflareのDNS画面にある「Proxied（オレンジ色の雲）」は、単なるDNSレコードの隠し設定ではありません。DNSの応答をCloudflareのAnycast IPに置き換え、HTTP/HTTPS通信をCloudflareのエッジへ誘導するリバースプロキシ機能です。[1]
この仕組みにより、オリジンIPを通常のDNS応答から隠し、CDNキャッシュ、DDoS緩和、WAF、TLS終端などを通信経路へ組み込めます。一方で、Proxiedにするだけではオリジンへの直接アクセスを防げません。IPが漏えいした後もCloudflareを迂回できないようにするには、オリジン側のファイアウォール、mTLS、Tunnelなどを併用する必要があります。
本稿では、Cloudflare Reverse Proxyの通信フローを分解し、メリット・デメリット、IP遮蔽の限界、導入時の確認方法、AWS CloudFront・Fastly・Akamaiとの違いまで整理します。
TL;DR
| 結論 | 内容 |
|---|---|
| Proxiedの本質 | DNSでCloudflare Anycast IPを返し、Web通信をCloudflare経由にすること |
| IP遮蔽の効果 | 通常のDNS問い合わせからオリジンIPを見えにくくする。ただし秘匿であって到達制御ではない |
| 必須の追加対策 | オリジンの80/443をCloudflareのIPv4/IPv6 CIDRだけに制限する |
| より強い対策 | Full (strict) + Authenticated Origin Pulls、またはCloudflare Tunnel |
| 注意点 | DNS-only、メール、過去DNS、IPv6、別ポート、同居サービスからIPが漏れる |
| 選定の要点 | CDNのキャッシュ階層と、オリジンへの直接到達制御は別々に評価する |
1. DNSとリバースプロキシは別の機能
DNSは、ホスト名をIPアドレスや別名へ変換する仕組みです。Cloudflareを権威DNSとして利用していても、すべての通信がCloudflareを経由するわけではありません。
DNS-only（灰色の雲）では、CloudflareはDNSの回答を返すだけです。A/AAAAレコードの値がオリジンIPなら、クライアントはそのIPへ直接接続します。
Proxied（オレンジ色の雲）では、Cloudflareは外部のDNS回答としてオリジンIPではなくCloudflareのAnycast IPを返します。クライアントはCloudflareエッジへ接続し、エッジが必要に応じてオリジンへリクエストを転送します。[1] [2]
したがって、次の2つは分けて考える必要があります。
- 秘匿性: DNS回答などからオリジンIPを見つけにくくする。
- 到達制御: オリジンIPを知られても、Cloudflareを経由しない接続を拒否する。
Proxiedは主に1を実現します。2はオリジン側のネットワーク制御で実現します。
2. 通信フロー
ProxiedレコードのTTLは通常 Auto で、既定値は300秒です。CloudflareのAnycast IPはオリジンそのものではなく、Cloudflareネットワークへの入口です。[1]
3. Proxiedにできるレコードとできない通信
通常のDNSプロキシで対象になるのは、HTTP/HTTPSを提供するA、AAAA、CNAMEレコードです。MX、TXT、SRV、CAAなどはDNS情報そのものを提供するレコードなので、HTTPプロキシにはなりません。[3]
| 対象 | Proxied | 実務上の注意 |
|---|---|---|
| A | 可能 | IPv4 Webオリジン向け |
| AAAA | 可能 | IPv6側の公開面も必ず確認する |
| CNAME | 条件付きで可能 | Web用途以外の検証・メール連携はDNS-onlyが必要な場合がある |
| MX/TXT/SRV/CAA | 不可 | DNSとして公開される |
| SSH/FTPなど | 通常のHTTPプロキシでは不可 | VPN、bastion、Tunnel、Spectrumなどを検討 |
標準のWebプロキシで対応するポートにも制限があります。代表的にはHTTPの80/8080、HTTPSの443/8443などです。22番ポートのSSHや任意のTCP/UDPアプリケーションを、そのままオレンジ色の雲で隠せるわけではありません。[3]
4. IP遮蔽が成立する条件
4.1 Web用の名前を漏れなくProxiedにする
www.example.comだけをProxiedにしても、admin.example.comやorigin.example.comが同じIPをDNS-onlyで指していれば、オリジンIPは容易に判明します。DNSはホスト名単位ではなく、IP単位で公開面を棚卸しするのが重要です。
# A/AAAA/CNAMEを確認
dig A www.example.com +short
dig AAAA www.example.com +short
dig CNAME www.example.com +short
# 関連するメール・委任情報を確認
dig MX example.com +short
dig TXT example.com +short
dig NS example.com +short
4.2 オリジンファイアウォールで直接アクセスを拒否する
Cloudflare経由のリクエストがオリジンへ到着すると、ネットワーク層の送信元は通常、訪問者ではなくCloudflareのIPレンジになります。そのため、オリジンのSecurity Group、ロードバランサー、ホストファイアウォールで、80/443をCloudflareのIPv4・IPv6 CIDRに限定します。[4]
概念的には次の順序です。
allow Cloudflare IPv4 CIDR -> TCP/80,443
allow Cloudflare IPv6 CIDR -> TCP/80,443
allow 運用VPN / 監視 / ヘルスチェック -> 必要なポートだけ
deny その他 -> TCP/80,443
CloudflareのIPレンジは変更されるため、手作業で固定値を貼り付けたままにせず、公式のIP一覧を取得して差分検知・承認・適用・ロールバックまで自動化します。[4]
CF-Connecting-IPなどのヘッダーは、Cloudflareから来た通信だけを受け入れるネットワーク境界を作った後に信頼してください。インターネットから直接到達できるWebサーバーで、このヘッダーだけを信頼してはいけません。
4.3 IPv4だけで完了としない
IPv4のAレコードをProxiedにしても、DNS-onlyのAAAAレコードや、IPv6側のファイアウォールの穴が残っていれば直接到達されます。確認時は必ず両方を試します。
curl -4 -I https://www.example.com/
curl -6 -I https://www.example.com/
# 承認済みの診断環境からのみ実施する
curl -vk --resolve www.example.com:443:ORIGIN_IP https://www.example.com/
直接接続テストは、許可された診断環境で、業務影響を避けて実施してください。
5. IPが漏れる代表的な経路
| 経路 | 起きること | 対策 |
|---|---|---|
| DNS-onlyのA/AAAA | 実IPがDNS回答に含まれる | Web用レコードをProxiedにする |
| メールサーバーとの同居 | MX、SMTPバナー、バウンスなどからIPが推測される | メールとWebを別IP・別ネットワークに分離する |
| Cloudflare導入前のDNS | 過去のDNS情報が残る | 有効化後にオリジンIPをローテーションする |
originやadminサブドメイン |
補助ホスト名が実IPを公開する | 全DNSゾーン、委任サブゾーン、CNAMEを棚卸しする |
| 非HTTPサービス | SSH、FTP、監視ポートなどが同じIPに存在する | VPN、bastion、Tunnel、専用ネットワークへ移す |
| IPv6 | Aだけ閉じてAAAAやIPv6 listenerを放置する | IPv4/IPv6を同じdeny-by-defaultで管理する |
| アプリケーション | エラーメッセージ、メール、レスポンスヘッダーなどにIPが出る | 出力、ログ、メール経路を監査する |
「推測しにくいサブドメイン名」は探索コストを上げるだけです。IPが判明しても接続できないことを、本来の防御目標にしてください。
6. TLSは2区間に分けて考える
Cloudflareのプロキシでは、TLS接続は次の2区間です。
- クライアントからCloudflareエッジ。
- Cloudflareエッジからオリジン。
Flexibleでは、クライアントからCloudflareまではHTTPSでも、CloudflareからオリジンまではHTTPになります。ログイン情報や個人情報を扱うサービスでは避けるべき構成です。Cloudflareは可能な限り Full または Full (strict) を推奨しています。[5]
| モード | クライアント→Cloudflare | Cloudflare→オリジン | 評価 |
|---|---|---|---|
| Flexible | HTTPS可能 | HTTP | 後段が平文。機密用途には不適 |
| Full | HTTPS可能 | HTTPS | オリジン証明書を厳密には検証しない |
| Full (strict) | HTTPS可能 | HTTPS | オリジン証明書を検証。基本推奨 |
Cloudflare Origin CA証明書は、主にCloudflareとオリジン間で使う証明書です。ブラウザが直接オリジンへ接続するための公開信頼証明書とは役割が異なります。IP遮蔽や直接到達制御の代替にはなりません。
さらに厳密にする場合は、Authenticated Origin Pulls（AOP）を使います。これはCloudflareがオリジンへ接続する際のクライアント証明書をオリジン側で検証するmTLSです。[6] IP allowlistとAOPを併用すると、IPが漏れた場合でもCloudflareを経由しない接続を拒否しやすくなります。
7. Cloudflare Tunnelという別解
オリジンに公開IPを持たせる必要自体を減らしたい場合は、Cloudflare Tunnelを検討できます。cloudflaredがオリジンからCloudflareへアウトバウンド接続を張るため、インターネットからオリジンへ新規接続を受ける構成を避けられます。
これは「IPを隠す」より強い考え方です。到達経路を公開ネットワーク上に置かず、Cloudflare側の認証・ポリシーとconnectorの管理へ責任を移します。ただし、connectorの冗長化、更新、資格情報、障害時の運用経路を設計する必要があります。
8. メリット
8.1 オリジンの公開面を減らせる
通常のDNS回答ではCloudflareのIPを返すため、オリジンIPの直接的な露出を減らせます。これにより、攻撃者がオリジンへ直接到達するまでの探索コストを上げられます。
8.2 CDNによる負荷軽減
静的コンテンツをエッジキャッシュから返せれば、オリジンへのリクエスト数、帯域、TLS処理を減らせます。ただし、Proxiedにしただけでログイン済みHTMLやAPIが自動的に安全にキャッシュされるわけではありません。Cookie、認証、Cache-Control、クエリ文字列を含めてキャッシュポリシーを設計します。
8.3 DDoS緩和・WAFを入口に集約できる
WebリクエストをCloudflareへ集約することで、CloudflareのDDoS緩和、WAF、レート制限、Bot対策などをエッジで適用できます。ただし、DDoS対策とWAFは同一機能ではありません。ネットワーク攻撃、HTTP攻撃、認証・認可の不備を別の統制として設計してください。
8.4 証明書・DNS・ルーティングを一体管理できる
DNS、TLS証明書、キャッシュ、WAFを一つの制御面で管理できます。小規模サービスでは導入部品を減らしやすく、大規模環境ではAPIやTerraformで変更管理へ移行できます。[7]
9. デメリットと落とし穴
9.1 Cloudflare障害時に影響範囲が広い
DNSとHTTP入口をCloudflareへ集約するほど、Cloudflare側の障害や設定ミスの影響は大きくなります。緊急時のDNS、オリジン、管理アクセス、証明書更新の手順を事前に用意します。
9.2 クライアントIPの扱いが変わる
オリジンのTCP接続元はCloudflareになります。アプリケーションで元のクライアントIPを使う場合は、信頼できる経路から来た場合だけ CF-Connecting-IPなどを採用し、Webサーバーやフレームワークのtrusted proxy設定を正しく行います。
9.3 非HTTPサービスにはそのまま使えない
SSH、メール、任意のTCP/UDP通信を通常のDNSプロキシで処理することはできません。すべてをCloudflareのオレンジクラウドで隠せると考えると、設計を誤ります。
9.4 キャッシュミス、設定ミス、個人情報混入
動的レスポンスを誤ってキャッシュすると、利用者間でデータが混ざる可能性があります。ログイン後ページ、Cookie、Authorizationヘッダー、APIレスポンスは、キャッシュキーと保存可否を明示的にレビューします。
9.5 送信元IP allowlistの更新が必要
CloudflareのIPレンジを古いままにすると、正規のCloudflare通信まで遮断します。逆に不要なレンジを残すと、許可範囲が広がります。取得元、差分、適用結果、ロールバックをログに残します。
10. 他サービスとの比較
ここでは「CDNとしてのオリジン負荷軽減」と「オリジンへの直接到達制御」を分けて比較します。前者ができても、後者が自動的に実現するわけではありません。
| 観点 | Cloudflare | AWS CloudFront | Fastly | Akamai |
|---|---|---|---|---|
| 基本的な入口 | DNSのProxiedでCloudflareエッジへ誘導 | DistributionとDNSを構成 | CDNサービスとドメインを構成 | PropertyとEdge hostnameを構成 |
| オリジン負荷軽減 | CDN、Tiered Cache、Cache Rules | Regional Edge Cache、Origin Shield | Shielding、VCL、キャッシュ制御 | Tiered Distribution、Cloud Wrapper |
| 直接アクセス抑止 | IP allowlist、AOP、Tunnel | VPC origins、CloudFront専用ヘッダー、AWS managed prefix list | Fastly IPレンジのallowlist、TLS、アプリ認証 | Site Shield CIDR、追加の認証 |
| WAF/DDoS | Cloudflare WAF/DDoSを同一エッジで提供 | AWS WAF、AWS Shieldと組み合わせる | DDoS Protection、Next-Gen WAF | App & API Protector、Prolexicなど |
| 設定管理 | Dashboard、API、Terraform | Console、CloudFormation、API | API/CLI、バージョンactivate、VCL | Property Manager、PAPI、Terraform、staging activate |
| 向く組織 | DNSから短時間でWeb保護を始めたい | AWS資産・IAM・IaCへ統合したい | 細粒度なCDN制御と明示的な版管理を重視 | 大規模配信とエンタープライズ統制を重視 |
| 注意点 | IP遮蔽だけでは十分でない | Origin Shieldは到達制御ではない | Shieldingは認証ではない | Site Shieldは認証の代替ではない |
CloudFrontとの違い
CloudFrontはAWSのVPC、ALB、S3、WAF、CloudFormationと統合しやすい点が強みです。CloudFrontのVPC originsを使えば、公開サブネットにオリジンを置かない設計を取りやすくなります。[8]
一方、Origin Shieldはキャッシュ階層であり、オリジンへの直アクセスを禁止する機能ではありません。公開ALBを使う場合は、CloudFrontの秘密ヘッダー、ALB側のルール、Security Groupなどを組み合わせます。
Fastlyとの違い
Fastlyは設定をバージョンとして管理し、明示的に本番activateする運用や、VCLによる細かなキャッシュ・ルーティング制御に強みがあります。Shieldingは複数POPからの要求を指定POPへ集約しますが、オリジン認証そのものではありません。[9]
Akamaiとの違い
AkamaiはProperty Managerのルールツリー、stagingからproductionへのactivate、Site Shieldなど、エンタープライズ向けの変更統制と大規模配信機能が中心です。Site Shieldでオリジン側の許可CIDRを絞れますが、Akamaiの公式説明でも認証の代替ではないとされています。[10]
11. どれを選ぶべきか
| 要件 | 第一候補の考え方 |
|---|---|
| 小規模なWebサイトを早く保護したい | Cloudflare。DNS切り替えとProxiedで開始し、後からWAF・AOP・IaCを追加する |
| AWS内のALBやVPCを中心に運用している | CloudFront。VPC origins、AWS WAF、Security Groupを一体で設計する |
| VCLと版管理でエッジロジックを細かく制御したい | Fastly。Shieldingとオリジン認証を分けて設計する |
| 大規模配信、複雑な契約・統制、グローバル運用 | Akamai。Site Shield、Property Manager、セキュリティ製品を要件単位で評価する |
| オリジンに公開IPを持たせたくない | Cloudflare Tunnel、CloudFront VPC originsなど、private originを優先する |
価格はプラン、トラフィック、WAF、ログ保持、リクエスト数、リージョン、追加機能で変わります。比較時は「CDN単価」だけでなく、WAF、DDoS、ログ、オリジン転送、キャッシュミス、運用工数まで同じトラフィックモデルで試算してください。[11]
12. 導入後のチェックリスト
- Web用のA/AAAA/CNAMEが意図どおりProxiedになっている
- DNS-onlyの名前がWebオリジンと同じIPを指していない
- MX、メール、SPF、外部委任サブゾーンを棚卸ししている
- CloudflareのIPv4/IPv6 CIDRだけがオリジンの80/443へ到達できる
- IPv4とIPv6の両方で直接アクセス試験を行っている
- TLSモードがFull (strict)で、オリジン証明書の更新手順がある
-
CF-Connecting-IPを信頼する境界を明確にしている - キャッシュキー、Cookie、Authorization、個人情報の扱いをレビューしている
- Cloudflare IPレンジの更新を自動化または運用手順化している
- Cloudflare障害時の管理アクセスと復旧手順がある
まとめ
CloudflareのDNSプロキシは、DNS回答をCloudflareのAnycast IPへ置き換え、Web通信をCloudflareエッジへ集約するリバースプロキシです。これにより、通常のDNS参照からオリジンIPを隠し、CDN、DDoS緩和、WAF、TLSなどを通信経路へ配置できます。
しかし、IP遮蔽は到達制御ではありません。DNS-onlyレコード、メール、過去DNS、IPv6、同居サービスからIPが漏れれば、攻撃者はオリジンを直接狙えます。実運用では、Proxied化、オリジンのCloudflare CIDR allowlist、Full (strict)、AOPまたはTunnel、IPv4/IPv6の監査を一つの設計として扱ってください。
また、CloudFrontのOrigin Shield、FastlyのShielding、AkamaiのSite Shieldも、キャッシュによる負荷軽減と到達制御を分けて考える必要があります。サービス選定では、CDNの機能一覧ではなく、オリジンを誰が、どの経路から、どの認証で到達できるのかまで比較することが重要です。
References
1: https://developers.cloudflare.com/dns/proxy-status/ "Proxy status · Cloudflare DNS docs"
2: https://www.cloudflare.com/learning/cdn/glossary/reverse-proxy/ "What Is a Reverse Proxy? · Cloudflare"
3: https://developers.cloudflare.com/dns/proxy-status/limitations/ "Proxying limitations · Cloudflare DNS docs"
4: https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/ "Cloudflare IP addresses · Cloudflare Docs"
5: https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/ "Encryption modes · Cloudflare SSL/TLS docs"
6: https://developers.cloudflare.com/ssl/client-certificates/ "Authenticated Origin Pulls · Cloudflare Docs"
7: https://developers.cloudflare.com/terraform/ "Terraform on Cloudflare · Cloudflare Docs"
8: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html "Use VPC origins with CloudFront · AWS Documentation"
9: https://www.fastly.com/documentation/guides/concepts/shielding/ "Shielding · Fastly Documentation"
[10]: https://techdocs.akamai.com/origin-ip-acl/docs/welcome "Origin IP Access Control List · Akamai TechDocs"
[11]: https://www.cloudflare.com/plans/ "Cloudflare Plans and Pricing"