解決した課題

  • AWSのALB配下でWebを公開しているが、特定ページ（管理系／限定公開ページ等）だけは接続元IP制限をかけたい。
  • ALB経由だとWebサーバから見える接続元IPがALBになりやすく、従来の「接続元IP＝クライアントIP」前提の制限が効かない。

対応内容

  • 方針：ALBが付与する X-Forwarded-For（XFF）を信頼できる前提を作り、Webサーバ側で「見かけの接続元IP」をクライアントIPとして扱えるようにした上で、URI単位のIP制限を実装する。
  • 前提条件の整備（重要）：
    • XFFはクライアントが偽装できるヘッダであるため、Webサーバがインターネットから直叩きされ得る状態では危険となる。
    • そこで「WebサーバはALBからしか到達できない」構成（SG/ルーティングで直アクセス遮断）を作り、XFFを信頼できる条件を成立させた。
  • XFFからクライアントIPを復元：
    • ALBのXFFは「クライアントIP, プロキシIP…」のようにチェーンになるため、先頭要素（左端）をクライアントIPとして扱う方針とした。
    • Apacheの場合は mod_remoteip 等で、ALBからの通信に限り X-Forwarded-For を元に REMOTE_ADDR を復元する設定に寄せた（ログ・アクセス制御の両方が素直になる）。
    • Nginxの場合も同様に、信頼するプロキシ（ALB）を限定した上で real_ip 系の設定で復元した。
  • 特定ページのIP制限：
    • 復元後のクライアントIP（=見かけの接続元IP）に対して、対象URI配下だけ許可IP/拒否IPを定義し、該当しない場合は403にするルールを実装した。
    • 業務要件に合わせて許可リストを運用し、例外追加が発生しても追える形（設定ファイル分割、管理手順化）にした。
  • 確認と運用：
    • ALB経由アクセス時に、対象URIだけ期待通りに許可／拒否が動くことを確認した。
    • ログ上もクライアントIPが正しく記録されることを確認し、監査・調査の実用性を確保した。

結果

  • ALB配下でも、特定ページに対して接続元IP制限を適用できるようになった。
  • Webサーバ直叩きを遮断した上でXFFを扱う構成とし、ヘッダ偽装リスクを抑えた運用にできた。