CDN＋LB＋nginx構成でIP制御を安全に行う方法【X-Forwarded-For設計の正解】

URLをコピーしました！

CDN＋ロードバランサ＋nginx構成でIP制限を実装する場合、

正しく設計しないとIP制限は簡単に突破されます。

よくある誤解：

X-Forwarded-Forを見ればクライアントIPが分かる
real_ip_recursiveをonにすれば安全
CDN配下ならIP偽装はできない

すべて不十分です。

本記事では、

安全な信頼境界の考え方
正しいnginx設定例
よくある事故パターン
安全であることの確認方法

を実務レベルで解説します。

まず理解すべき：IP制御の本質は「信頼境界」

典型構成

Client
  ↓
CDN
  ↓
Load Balancer
  ↓
nginx

この構成で重要なのは：

どのレイヤーまでを“信頼するか”

です。

なぜ事故が起きるのか

事故例① set_real_ip_fromが広すぎる

set_real_ip_from 0.0.0.0/0;
real_ip_recursive on;

→ すべてのIPを信頼してしまう → XFFの最左IPを無条件採用 → クライアントがIPを偽装可能

事故例② LBを経由しない直アクセスが可能

FWやセキュリティグループで制御していない場合：

nginxへ直接アクセス
任意のXFFを付与

→ IP制限が無意味になります。

事故例③ CDNのIPレンジ管理が不十分

CDNはIPレンジが変わります。

固定で書いて更新していない場合、

正規アクセスが拒否される
誤って広範囲を信頼してしまう

という事故が発生します。

安全な設計原則（結論）

① nginxはLBからのみ通信許可

最重要ポイントです。

セキュリティグループやFWで：

LBのIPのみ許可
CDNやClientからの直アクセス禁止

これができていない時点で設計は不完全です。

② set_real_ip_fromは「直前の信頼ノードのみ」

nginxが直接受けるのがLBなら：

set_real_ip_from 10.0.0.10;  # LBのみ
real_ip_header X-Forwarded-For;
real_ip_recursive on;

CDNはここでは指定しません。

理由：

nginxが直接見ているのはLBだから

③ CDN → LBでXFFを正しく引き継ぐ

LBがXFFを上書きしてしまうと、

クライアントIPが失われます。

LB設定で：

既存XFFを保持
自身のIPを追記

する必要があります。

安全なnginx設定例（多段構成）

set_real_ip_from 10.0.0.10;      # LBのみ
real_ip_header X-Forwarded-For;
real_ip_recursive on;

allow 203.0.113.0/24;
deny all;

この場合：

LB以外からのXFFは無効
recursiveで正しいクライアントIPを採用
IP制限が正しく機能

どうなれば「安全」と言えるのか

以下がすべて満たされていること

nginxへ直アクセス不可
set_real_ip_fromが最小範囲
recursiveの動作を理解している
偽装テストで突破できない

安全性の検証方法（必須）

① 偽装テスト

curl -H "X-Forwarded-For: 1.2.3.4" https://example.com

remote_addrが1.2.3.4になるなら失敗です。

② ログ確認

log_format test '$remote_addr | $http_x_forwarded_for';

以下を確認：

LB経由アクセス
想定外IPアクセス

常に正しいクライアントIPになっているか確認します。

よくある誤解

CDNがあるから安全 → ❌
recursiveをonにすれば安全 → ❌
XFFは信頼できる → ❌

安全なのは

通信経路を物理的に制御している構成だけ

まとめ

CDN＋LB＋nginx構成でIP制御を安全に行うために必要なのは：

信頼境界の明確化
直アクセス遮断
最小限のset_real_ip_from
recursiveの正しい理解
偽装テストによる検証

IP制御は設定の問題ではなく、設計の問題です。

設計が正しければ安全に動作し、設計が曖昧なら必ず突破されます。