はじめに
本記事では、AWSのApplication Load Balancer(ALB)を使用して、EC2上の特定のパスに対してアクセス制限をかける方法を解説します。
セキュリティ強化のために「特定のディレクトリには管理者IPからのみアクセス許可したい」といった場面もあるかと思います。
今回は、「送信元IPによる制限」と、プロキシやCDNを経由する場合の「X-Forwarded-For(XFF)ヘッダーを利用した制限」の2つの設定手順を紹介します。
前提
・ALB(リスナールール)と振り分け先のサーバー(EC2)は既に作られている想定とします
・アクセス制限を掛けるパスは今回の記事では以下とします
/adminer.php
・アクセス許可したいユーザーのグローバルIP(GIP)が分かっているとします
設定(送信元IPで制限を掛ける方法)
ALBの前段にプロキシサーバーやCDN(CloudFrontなど)が存在せず、ALBがクライアント(ユーザー)のGIPを直接認識できる構成の場合に利用可能です。
設定をしていきます。
リスナーの画面でルールを追加をクリックします
一致パターンマッチングで「値マッチング」を選択し、パス条件値に指定のパスを入力します。
ここでは「*」を付けることで「adminer.php」で始まるすべてを対象としています。

ルールを追加する→条件で「送信元IP」を選択して対象のIPを入力します。
「/32」などサブネットマスクも入力します。

また対象のIPが複数あれば「+OR条件値を追加」を押して、追加することができます。
次にアクションの項目を設定します。
ここでは「事前ルーティングアクションなし」「ターゲットグループへ転送」を選択し、
リクエストを送りたいターゲットグループを選択し、次へをクリックします。

ルールの優先度を付けます。
優先度の高い(数値が小さい)方から処理されていくので、許可したいルールは優先度を高くする必要があります。

次へをクリックすると変更の確認画面になります。
内容を確認し問題がなければ「変更の保存」をクリックするとルールが追加されます。

これで指定の送信元IPの許可ルール設定は完了です。
次に、上記以外の合致しないIPからのアクセスに対するルールを作成します。
403エラーページの設定
アクセス制限のルールを追加した後は、条件に合致しない(許可されていない)ユーザーに対して「403 Forbidden」を返すように設定しました。
ALBのリスナールールで「固定レスポンスを返す」アクションを選択することで、専用のエラーメッセージやステータスコードを表示させることが可能です。
先ほどと同じように、対象のリスナーを選択し、リスナーの画面でルールを追加をクリックします。
条件には同じパスを指定します。

アクションには「事前ルーティングなし」「固定レスポンスを返す」を選択し
レスポンスコードには「403」コンテンツタイプを「text/plain」とし
レスポンス本文内の文字列を返すようにします。今回はAccess Deniedを返す設定をしています。

次に優先度の設定ですが、先程作った許可ルールよりも低い優先度(数値が大きい)にします。
変更の確認画面で「変更の保存」をクリックすると、403を返すルールが作成されます。
この状態で指定のパス/adminer.phpに対し、許可ルールに記載した送信元IPと、それ以外のIPからアクセスを行い
期待通りの挙動
・許可したIPは/adminer.phpへアクセス可能
・それ以外のIPは403 Access Deniedの表示
になっていれば設定は完了です。
次にプロキシやCDNを経由する場合の設定について記載します。
設定(XFFで制限を掛ける方法)
プロキシサーバーやCloudFrontを介してアクセスする環境の場合、ALBには「ユーザーのGIP」ではなく「前段にあるサービスのIP」が届いてしまいます。
このように、ALBがクライアントのグローバルIPを直接認識できない構成では、リクエストヘッダーに含まれる「X-Forwarded-For (XFF)」の値を参照してアクセス制限を行います。
ルールの設定方法は上記とほぼ同様ですが、使用する条件が異なります。
ルール作成時の条件には「HTTPヘッダー」を選択し、HTTPヘッダー名に「X-Forwarded-For」と入力します。
またHTTPヘッダー値には許可したい送信元IPを入力します。
※ここでは「/32」などのサブネットマスクは入力しないでください。

他の設定は「送信元IPで制限を掛ける方法」と同じです。
403の設定も同様に実施してください。
まとめ
本記事では、ALBのリスナールールを用いて、EC2上の特定パスへIP制限をかける2つの手法を解説しました。直接アクセスを制御する「送信元IP制限」と、CloudFrontなどのCDNを経由する場合に必須となる「X-Forwarded-Forヘッダー制限」について記事にしました。
ALBのリスナールールでのアクセス制限は簡単で、運用負荷も低いと感じました。
また色々な条件を使うことで、割と柔軟なアクセス制御ができると感じました。


