【AWS】CloudFrontで特定のIPアドレスだけアクセス許可

By /

【AWS】CloudFrontで特定のIPアドレスだけアクセス許可：詳細な設定、運用、セキュリティ対策

はじめに

インターネット上でコンテンツを配信する際、セキュリティとアクセス制御は極めて重要です。特に、ウェブサイトやアプリケーションの特定領域（例えば管理画面）へのアクセスを制限したい場合や、特定のパートナーや社内ネットワークからのアクセスのみを許可したいといった要件は頻繁に発生します。

AWS CloudFrontは、世界中のエッジロケーションからコンテンツを高速に配信するCDN（Contents Delivery Network）サービスですが、単なる高速化ツールに留まらず、強力なセキュリティ機能も提供しています。その中でも、特定のIPアドレスからのアクセスのみを許可（または拒否）する機能は、ウェブサイトやアプリケーションのセキュリティ境界を強化する上で非常に有効な手段となります。

この記事では、AWS CloudFrontで特定のIPアドレスからのアクセスのみを許可するための詳細な設定方法、その背後にある仕組み、運用上の考慮事項、そして関連するセキュリティ対策について、約5000語のボリュームで徹底的に解説します。これからCloudFrontでIPアドレス制限を実装したいと考えている方、あるいは既存の設定を見直したいと考えている方にとって、網羅的な情報源となることを目指します。

なぜCloudFrontでIPアドレス制限が必要か？

CloudFrontでIPアドレス制限を設定する目的はいくつかあります。

  1. セキュリティ強化:

    • 不正アクセス防止: 特定のIPアドレス（例えば、管理者のIP、社内ネットワークのIP、特定のパートナー企業のIPなど）からのアクセスのみを許可することで、それ以外の不特定多数からの管理画面や機密情報へのアクセス試行をブロックします。
    • DDoS攻撃対策（限定的）: 特定のIPアドレス範囲からの大量アクセスに対する対策としては限定的ですが、既知の攻撃元IPやボットネットのIPアドレスリストをブロックする際にWAFと連携して活用できます。ただし、高度なDDoS攻撃に対してはAWS Shieldなどの専門サービスが必要です。
    • 脆弱性スキャン対策: 不要なスキャンツールからのアクセスを制限することで、攻撃者にシステムの脆弱性を発見されるリスクを低減します。

  2. コンテンツアクセスの制限:

    • 特定のユーザーグループへのコンテンツ配信: 許可されたIPアドレスリストに含まれるユーザーのみに、特定の動画コンテンツやドキュメントなどを配信したい場合に利用します。
    • ベータ版や限定公開版の提供: 特定のテスターや関係者のみに、開発中のサービスや限定版コンテンツを公開する場合に役立ちます。

  3. 運用上の理由:

    • テスト環境へのアクセス制限: 公開前のステージング環境やテスト環境へのアクセスを、開発者やテスターのIPアドレスのみに制限し、意図しない外部からのアクセスを防ぎます。
    • オリジンへの負荷軽減: CloudFrontのエッジで不要なリクエスト（許可されていないIPからのリクエスト）をブロックすることで、オリジンサーバーへの負荷を軽減し、コスト削減にもつながります。

CloudFrontでのIPアドレス制限の仕組み：AWS WAFとの連携

CloudFront単体には、特定のIPアドレスからのアクセスを「許可リスト」として設定する機能はありません。CloudFrontで詳細なアクセス制御（IPアドレス制限、地理的制限、特定のヘッダーやクエリパラメータに基づく制限など）を実現するためには、AWS WAF (Web Application Firewall) と連携して利用します。

AWS WAFとは？

AWS WAFは、ウェブアプリケーションを一般的なウェブ攻撃（SQLインジェクション、クロスサイトスクリプティング（XSS）など）から保護するウェブアプリケーションファイアウォールです。CloudFront、Application Load Balancer (ALB)、API Gateway、AppSyncなどのリソースと連携して動作します。

AWS WAFでは、Web Access Control List (Web ACL) と呼ばれるルールセットを作成し、そのWeb ACLを保護したいAWSリソース（この場合はCloudFrontディストリビューション）に関連付けます。Web ACLは1つ以上のルールで構成され、各ルールは特定のリクエストパターン（例えば、特定のIPアドレスからのリクエスト）に一致した場合に実行するアクション（許可、ブロック、カウント）を定義します。

CloudFrontとWAFの処理フロー

CloudFrontとWAFを連携させた場合の一般的なリクエスト処理フローは以下のようになります。

  1. ユーザーからのリクエスト: ユーザーがCloudFrontディストリビューションのエンドポイント（ドメイン名）にリクエストを送信します。
  2. CloudFrontエッジロケーションでの受信: 最も近いCloudFrontエッジロケーションがリクエストを受信します。
  3. WAFによる検査: CloudFrontエッジロケーションは、リクエストをオリジンに転送する前に、関連付けられているAWS WAF Web ACLにリクエストを渡します。
  4. Web ACLのルール評価: WAFはWeb ACLに定義されているルールを、優先順位の高い順に評価します。
  5. アクションの実行: いずれかのルールにリクエストが一致し、そのルールに定義されているアクション（Allow, Block, Count）が決定された場合、そのアクションが実行されます。
    • Allow: リクエストは許可され、CloudFrontはキャッシュの確認やオリジンへのリクエスト転送に進みます。
    • Block: リクエストはブロックされ、WAFはクライアントに対してHTTP 403 Forbiddenなどのブロックレスポンスを返します。リクエストはオリジンには到達しません。
    • Count: リクエストはログに記録され、カウントされますが、リクエスト自体はブロックされず、CloudFrontの通常の処理に進みます。これはルールのテストやモニタリングに利用されます。
  6. デフォルトアクション: どのルールにもリクエストが一致しなかった場合、Web ACLに設定されたデフォルトアクションが実行されます。IPアドレス制限で「許可リスト」方式を採用する場合、デフォルトアクションは通常「Block」に設定されます。
  7. CloudFrontのキャッシュ/オリジン処理: WAFによってAllowされたリクエストは、CloudFrontのキャッシュを確認します。キャッシュヒットの場合はキャッシュから応答を返します。キャッシュミスまたは設定によっては、オリジンサーバーへリクエストを転送します。
  8. オリジンからの応答: オリジンサーバーがリクエストを処理し、CloudFrontに応答を返します。
  9. CloudFrontからの応答: CloudFrontはオリジンからの応答をキャッシュし、ユーザーに返します。

このフローからわかるように、IPアドレスによるアクセス制御は、オリジンサーバーにリクエストが到達する前にCloudFrontのエッジロケーションで行われます。これは、オリジンへの不要なトラフィックを削減し、オリジンサーバーの負荷を軽減する上で非常に効果的です。

オリジンでの制限 vs CloudFront (WAF) での制限

IPアドレス制限は、オリジンサーバー側（例えば、Webサーバーのファイアウォール設定、セキュリティグループ、Nginx/Apacheの設定など）でも可能です。しかし、CloudFront (WAF) で制限を行うことには以下の利点があります。

  • エッジでのブロック: 悪意のあるトラフィックや不要なトラフィックをユーザーに最も近いエッジロケーションでブロックできるため、オリジンへの負荷がかかりません。
  • スケーラビリティ: WAFはAWSのマネージドサービスであり、トラフィックの増加に応じて自動的にスケールするため、オリジンサーバーのリソースを消費しません。
  • 一元管理: 複数のオリジンサーバーや異なるタイプのオリジン（S3、ELB、EC2など）を利用している場合でも、CloudFrontディストリビューションに関連付けられた一つのWAF Web ACLでアクセス制御を一元管理できます。
  • 他のWAFルールとの組み合わせ: IPアドレス制限だけでなく、SQLインジェクション対策、XSS対策、レートベース制限など、他のセキュリティルールと組み合わせて適用できます。

したがって、CloudFrontを利用している場合は、オリジン側での制限よりもCloudFront (WAF) での制限を優先することが推奨されます。

AWS WAFの設定手順：特定のIPアドレスからのアクセスを許可する

それでは、実際にAWS WAFを使用してCloudFrontディストリビューションで特定のIPアドレスからのアクセスを許可する設定手順を見ていきましょう。ここでは「特定のIPアドレスリストに含まれるIPからのアクセスのみを許可し、それ以外はすべて拒否する（許可リスト方式）」というシナリオを想定します。

ステップ1: AWS WAF コンソールを開く

AWSマネジメントコンソールにサインインし、「WAF & Shield」サービスを検索して開きます。

ステップ2: Web ACL の作成

WAFコンソールを開いたら、以下の手順でWeb ACLを作成します。

  1. 左側のナビゲーションペインで「Web ACLs」を選択します。
  2. 「Create web ACL」ボタンをクリックします。
  3. Describe web ACL and choose associated AWS resources:
    • Name: Web ACLの名前を入力します（例: CloudFront-IPAllowList-WebACL）。識別しやすい名前を付けましょう。
    • Description (Optional): 説明を入力します（例: Web ACL to allow access from specific IP addresses for CloudFront distribution.）。
    • CloudWatch metric name: CloudWatchに発行されるメトリクスの名前です。Nameに基づいて自動生成されますが、必要に応じて変更できます。
    • Resource type: ここでWeb ACLを関連付けるAWSリソースのタイプを選択します。CloudFrontディストリビューションに関連付ける場合は「CloudFront distributions」を選択します。この選択により、Web ACLはAWSグローバルサービスとして作成されます。
    • Region: 「CloudFront distributions」を選択した場合、Regionは自動的に「Global (CloudFront)」となります。
    • Associated AWS resources: 「Add AWS resources」をクリックし、このWeb ACLを関連付けたいCloudFrontディストリビューションを選択します。ドロップダウンリストから対象のディストリビューションを選択し、「Add」ボタンをクリックします。複数のディストリビューションに関連付けることも可能です。
    • 「Next」をクリックします。

ステップ3: Add rules and rule groups

次に、Web ACLにルールを追加します。ここでIPアドレス制限のルールを作成します。

  1. 「Add rules」ドロップダウンから「Add my own rules and rule groups」を選択します。
  2. Rule:
    • Type: 「Regular rule」を選択します。
    • Name: ルールに名前を付けます（例: Allow-Specific-IPs）。
    • If a request: ここでリクエストを検査する条件を設定します。
      • Inspect: ここで検査するリクエストのどの部分を見るかを指定します。IPアドレスに基づく制限なので「an IP address is in the specified IP set」を選択します。
      • IP set: ここで、許可したいIPアドレスを定義した「IP set」を選択します。まだIP setを作成していない場合は、この画面で作成できます。
        • Create new IP set: もし新しいIP setを作成する場合、これをクリックします。新しいウィンドウまたはタブが開きます。
          • Name: IP setの名前を入力します（例: Allowed-User-IPSet）。
          • Description (Optional): 説明を入力します。
          • IP address type: 「IPv4」または「IPv6」を選択します。両方のタイプのIPアドレスを許可したい場合は、それぞれ別々のIP setを作成するか、または複数のIP setを組み合わせる必要があります（後述）。ここではまず「IPv4」を選択します。
          • IP addresses: 許可したいIPアドレスをCIDR形式で入力します。改行区切りで複数入力できます。
            • 例:
              203.0.113.1/32 # 単一のIPアドレス
              192.168.1.0/24 # サブネット全体
            • /32は単一のIPv4アドレス、/128は単一のIPv6アドレスを表します。
            • 注意: CIDR形式の入力間違いがないように注意してください。無効な形式やプライベートIPアドレス範囲（ただし、オリジンがVPC内にあるなどの特定のユースケースを除く）は使用できない場合があります。CloudFrontからのリクエストは通常パブリックIPアドレスを持つクライアントから送信されます。
          • 「Create IP set」をクリックします。
        • IP setの作成後、元のルール作成画面に戻り、「IP set」のドロップダウンリストから作成したIP set（例: Allowed-User-IPSet）を選択します。
      • IP address source: 検査対象のIPアドレスがリクエストのどこから取得されるかを指定します。通常はクライアントのSourceIPアドレスに基づく制限を行いますが、CloudFrontの場合、クライアントのSourceIPアドレスは標準でHTTPヘッダーのX-Forwarded-Forに含まれて転送されます。しかし、WAFはCloudFrontと連携している場合、標準でクライアントのSourceIPアドレス（X-Forwarded-Forの最初のIP）を自動的に取得するため、通常はSource IP addressを選択します。特定のヘッダー（例えばプロキシやロードバランサーを経由している場合のカスタムヘッダー）から取得したい場合は「IP address in header」を選択することも可能ですが、一般的なクライアントIP制限ではSource IP addressが適切です。
    • Action: ルールに一致したリクエストに対して実行するアクションを指定します。特定のIPからのアクセスを「許可」したいので、「Allow」を選択します。
    • Custom request handling (Optional): Allowアクションの場合は、通常設定不要です。Blockアクションの場合は、カスタム応答（ステータスコード、応答ヘッダーなど）を設定できます。
  3. Set rule priority: ルールの優先順位を設定します。数値が小さいほど優先度が高くなります。通常、IP許可リストのルールは優先度を高く設定します。複数のルールを追加する場合、この順番が重要になります。このルールが最初のルールであれば、優先順位は0で問題ありません。
  4. 「Add rule」をクリックしてルールをWeb ACLに追加します。

これで、特定のIPアドレスからのアクセスを許可するルールが作成されました。

ステップ4: Set default web ACL action for requests that don’t match any rules

ルールを追加したら、どのルールにも一致しなかったリクエストに対するデフォルトアクションを設定します。

  • Default web ACL action: 特定のIPリストからのアクセスのみを許可し、それ以外をすべて拒否したい場合は、「Block」を選択します。これにより、作成した「Allow-Specific-IPs」ルールに一致しない（つまり、許可リストに含まれないIPアドレスからの）すべてのリクエストがブロックされます。

ステップ5: Review and create Web ACL

最後に、設定内容を確認します。

  1. Summary: Web ACLの名前、リソースタイプ、関連付けられたリソース、ルール、デフォルトアクションなどが一覧表示されます。
  2. 設定内容に間違いがないか確認します。特に、関連付けられたCloudFrontディストリビューション、作成したIPセットが正しく選択されているか、ルールの条件とアクション（Allow）が意図通りになっているか、そしてデフォルトアクションがBlockになっているかを再度確認します。
  3. 「Create web ACL」ボタンをクリックします。

これで、AWS WAF Web ACLが作成され、CloudFrontディストリビューションに関連付けられました。設定が反映されるまでには数分かかる場合があります。

IPアドレスリストの更新

作成したIPセットに含まれるIPアドレスリストを変更したい場合は、WAFコンソールの「IP sets」メニューから対象のIPセットを選択し、「Edit」をクリックしてIPアドレスを追加または削除します。IPセットの変更は、そのIPセットを使用しているすべてのルール、ひいてはそれらのルールを含むすべてのWeb ACLに即座に反映されます。

IPv4とIPv6の両方を許可したい場合

許可したいIPアドレスリストにIPv4とIPv6の両方が含まれている場合は、以下のいずれかの方法で対応します。

  1. 別々のIPセットを作成し、同じルールで参照する:

    • IPv4用とIPv6用で別々のIPセット（例: Allowed-User-IPv4Set, Allowed-User-IPv6Set）を作成します。
    • ルール作成時に、条件を「Requests must match all of the statements (AND)」とし、2つのステートメントを追加します。
      • ステートメント1: an IP address is in the specified IP set -> IPセットとしてAllowed-User-IPv4Setを選択 -> IP address sourceはSource IP address
      • ステートメント2: an IP address is in the specified IP set -> IPセットとしてAllowed-User-IPv6Setを選択 -> IP address sourceはSource IP address
    • この「AND」条件では、IPv4とIPv6のIPセットの両方に同時に含まれているリクエストのみを許可することになり、これは意図しない動作です。

  2. 別々のIPセットを作成し、別のルールで参照する:

    • IPv4用IPセット（例: Allowed-User-IPv4Set）とIPv6用IPセット（例: Allowed-User-IPv6Set）をそれぞれ作成します。
    • IPv4許可用ルール（例: Allow-IPv4s）を作成します。条件でIPv4用IPセットを参照し、アクションをAllowとします。
    • IPv6許可用ルール（例: Allow-IPv6s）を作成します。条件でIPv6用IPセットを参照し、アクションをAllowとします。
    • これらのルールの優先順位を高く設定します（例: 0と1）。
    • デフォルトアクションをBlockとします。
    • この方法が最も一般的で推奨されます。 リクエストは優先度の高い順にルールに評価され、Allow-IPv4sルールに一致すれば許可、一致しなければAllow-IPv6sルールを評価、それに一致すれば許可、いずれにも一致しなければデフォルトアクションのBlockが適用されます。

  3. 一つのIPセットに両方のタイプを含める（現在は非推奨/不可能）: WAFv2では、一つのIPセットにIPv4とIPv6を混在させることはできません。タイプごとにIPセットを分ける必要があります。

したがって、IPv4とIPv6の両方に対応する場合は、方法2のようにIPv4用とIPv6用のIPセットとルールを別々に作成し、Web ACLに含めるのが標準的なアプローチとなります。

設定のテストと確認

設定が完了したら、意図通りに動作するかテストと確認を行うことが重要です。

  1. 許可したIPアドレスからのアクセス:

    • 設定で許可したIPアドレス（またはそのネットワーク内のIPアドレス）を持つクライアント（例: 自分のPC、社内ネットワーク内のPCなど）から、CloudFrontディストリビューションのドメイン名にアクセスします。
    • ウェブサイトやコンテンツが正常に表示されることを確認します。HTTPステータスコードが200 OKなど、正常な応答であることを開発者ツールなどで確認できます。

  2. 許可していないIPアドレスからのアクセス:

    • 設定で許可していないIPアドレスを持つクライアント（例: スマートフォンのキャリアネットワーク、別のインターネット回線、VPNをオフにした状態など）から、CloudFrontディストリビューションのドメイン名にアクセスします。
    • アクセスが拒否されることを確認します。通常、HTTPステータスコード403 Forbiddenが返されます。カスタム応答を設定している場合は、設定した応答が表示されます。

  3. AWS WAF コンソールでの確認:

    • WAFコンソールに戻り、作成したWeb ACLを選択します。
    • 「Sampled requests」タブを選択します。ここに、Web ACLによって検査されたリクエストのサンプルが表示されます。
    • テストで送信したリクエストがリストアップされているか確認します。
    • 各リクエストの詳細を開き、どのルールに一致したか（またはどのルールにも一致しなかったか）、最終的なアクション（Allowed, Blocked, Counted）がどうなったかを確認できます。特にブロックされたリクエストについては、意図した通りデフォルトアクションでブロックされているかを確認します。
    • このログはリアルタイムではない（サンプリングされる）ため、すべてのリクエストが表示されるわけではありませんが、設定の基本的な動作確認には非常に役立ちます。

  4. Amazon CloudWatch Metricsでの確認:

    • CloudWatchコンソールを開き、「Metrics」->「All metrics」を選択します。
    • 「WAFV2」の名前空間を選択し、「WebACL, WAFVisualSearch」または「WebACL」などのディメンションで、作成したWeb ACLに関連するメトリクスを確認します。
    • 主なメトリクス:
      • AllowedRequests: Web ACLによって許可されたリクエスト数。
      • BlockedRequests: Web ACLによってブロックされたリクエスト数。
      • <RuleName>_BlockedRequests: 特定のルールによってブロックされたリクエスト数。
      • <RuleName>_CountedRequests: 特定のルールによってカウントされたリクエスト数。
    • これらのメトリクスを見ることで、設定したIP制限ルールが有効に機能しているか、許可されたトラフィックとブロックされたトラフィックの割合などを把握できます。

  5. CloudFront アクセスログでの確認:

    • CloudFrontディストリビューションでアクセスログを有効にしている場合、S3バケットに配信されるログファイルを確認します。
    • CloudFrontアクセスログには、WAFによってリクエストがブロックされたかどうかの情報が直接記録されるわけではありません（WAFでブロックされたリクエストはオリジンに到達しないため）。しかし、WAFで許可されたリクエストについては、オリジンへの転送やキャッシュヒット/ミスなどの情報が通常通り記録されます。
    • WAFでブロックされたリクエストの詳細な情報は、前述のWAFコンソールのSampled requestsやCloudWatch Metricsで確認するのが主な方法です。より詳細なログ分析が必要な場合は、WAFのFull loggingを有効にして、Kinesis Data Firehose経由でS3やCloudWatch Logsにログを配信することも可能です（別途設定と費用が発生します）。

これらのテストと確認手順を実行することで、設定が正しく機能していることを検証し、必要に応じて調整を行うことができます。

高度な設定と考慮事項

特定のIPアドレスからのアクセス許可という基本的な設定に加えて、さらに高度な設定や、運用・セキュリティ上の考慮事項がいくつかあります。

1. 動的なIPアドレスへの対応

許可リストに含めたいユーザーが固定IPアドレスを持っていない場合（例えば、リモートワークで自宅の動的IPアドレスからアクセスする場合）は、IPアドレス制限だけでは対応が困難です。このような場合の代替策や組み合わせ可能な手法を検討する必要があります。

  • VPNの利用: 許可したいユーザーにVPN接続を強制し、VPNゲートウェイの固定IPアドレスのみを許可リストに含める方法です。セキュリティレベルが最も高く、推奨されるアプローチです。AWS Client VPNや、サードパーティのVPNソリューションを利用できます。
  • AWS Global Accelerator: アプリケーションエンドポイントの前にGlobal Acceleratorを配置し、固定IPアドレスを提供します。ただし、これはCloudFrontとは異なるサービスであり、構成が複雑になる可能性があります。
  • 他の認証・認可メカニズムとの組み合わせ: IPアドレス制限は第一段階のフィルタリングとして利用し、さらにアプリケーション側でユーザー認証（ID/パスワード、多要素認証など）や認可（どのユーザーがどのリソースにアクセスできるか）を実装することで、より柔軟かつセキュアなアクセス制御を実現します。Cognito、IAM Identity Center、またはカスタム認証システムなどが考えられます。
  • IPアドレスの動的な更新: 一部のサービス（例: オフィスネットワークなど）では、IPアドレスが動的に変わるものの、特定のドメイン名や範囲に限定される場合があります。このような場合は、定期的にIPアドレスを確認し、WAFのIPセットを自動的に更新するスクリプトや仕組み（Lambda関数など）を構築することも理論的には可能ですが、運用負荷が高くなります。

2. 複数のIPリストの管理とルール設計

異なる目的で複数のIPアドレスリストを管理したい場合があります。例えば、管理者用のIPリスト、パートナー企業用のIPリスト、特定の開発チーム用のIPリストなどです。

  • 複数のIPセットの作成: 目的に応じて複数のIPセットを作成します（例: Admin-IPSet, PartnerA-IPSet）。
  • 複数のAllowルールの作成: 各IPセットに対応するAllowルールを作成します（例: Allow-Admins-Rule, Allow-PartnerA-Rule）。各ルールの条件でそれぞれのIPセットを参照し、アクションをAllowとします。
  • ルールの優先順位: これらのAllowルールの優先順位を、デフォルトのBlockアクションよりも高く設定します。複数のAllowルール間の優先順位は、先に一致したルールのアクションが適用されるため、どの順番で評価されても最終的にAllowになれば良い場合はあまり気にする必要はありません。ただし、特定のIPグループには別のカスタム応答を返したい場合などは優先順位が重要になります。
  • 特定のパスへの制限: 特定のIPアドレスからのアクセスを、ウェブサイト全体ではなく、特定のURLパス（例: /admin/*）にのみ許可したい場合があります。これは、WAFのルール内で「スコープダウンステートメント (Scope-down statements)」を使用することで実現できます。
    • ルール作成時に、条件を「Requests must match all of the statements (AND)」とします。
    • ステートメント1: an IP address is in the specified IP set -> 許可したいIPセットを選択 -> IP address sourceはSource IP address
    • ステートメント2: A request matches the statement -> InspectでURI pathを選択 -> Match typeでStarts withやExactly matches, Contains, Regex matchなどを選択 -> 制限したいパスを入力（例: /admin/）。必要に応じてText transformationを設定します。
    • アクションをAllowとします。
    • このルールの優先順位を高く設定します。
    • デフォルトアクションをBlockとします。
    • 注意: この設定の場合、/admin/*以外のパスへのアクセスは、このAllowルールには一致しません。他のルール（例えば、すべてのIPからの通常のアクセスを許可するルールなど）がない場合、デフォルトアクションのBlockによってブロックされてしまう可能性があります。したがって、このようなパスベースの制限を行う場合は、通常、許可されたIPからの/admin/*へのアクセスをAllowするルールと、すべてのIPからの/admin/*以外のパスへのアクセスをAllowするルール、そしてその他のリクエストをBlockするデフォルトアクション、という構成になります。複雑になるため、ルールの論理構成には十分な注意が必要です。WAFv2のビジュアルエディタや、論理演算子（AND, OR, NOT）を組み合わせることで、複雑な条件を定義できます。

3. 地理的制限との組み合わせ

特定の国や地域からのアクセスを許可または拒否する地理的制限（Geo Restriction）も、CloudFrontまたはWAFで設定可能です。IPアドレス制限と地理的制限を組み合わせて利用することで、よりきめ細かいアクセス制御が可能になります。

  • CloudFront Geo Restriction: CloudFrontディストリビューションの設定で、特定の国からのアクセスを許可または拒否できます。これはIPアドレスレベルではなく国レベルの制限です。
  • WAF Geo match rule: WAFルールとして地理的制限を設定することも可能です。これにより、特定の国のIPアドレスを他の条件（IPセット、URIパスなど）と組み合わせて評価できます。例えば、「特定のIPセットに含まれるかつ日本からのアクセスのみ許可」といった複雑な条件を設定できます。IPアドレス制限と地理的制限を組み合わせる場合は、WAFルールとしてまとめて管理する方が、論理的な整合性を保ちやすく、運用が容易になる場合があります。

4. IPアドレスの更新管理

許可リストに含めるIPアドレスが頻繁に変更される場合、WAFのIPセットを手動で更新するのは手間がかかります。このような場合は、自動化を検討します。

  • Lambda関数: IPアドレスリストを管理する外部ソース（例: S3バケット上のファイル、データベース、外部APIなど）を用意し、その変更をトリガーにLambda関数を実行してWAFのIPセットを更新する仕組みを構築できます。
  • IaC (Infrastructure as Code): Terraform, AWS CloudFormationなどのIaCツールを使用してWAFリソースを管理している場合、IPアドレスリストをIaCのコードとして管理し、コードの変更をデプロイすることでIPセットを更新します。これにより、変更履歴の管理やロールバックが容易になります。

5. PrivateLink/VPN接続経由のアクセス

オリジンサーバーがVPC内にあり、AWS PrivateLinkやVPN接続経由でのみアクセス可能になっている場合、CloudFrontからのアクセスは通常パブリックインターネットを経由しません。しかし、CloudFront自体はグローバルなサービスであり、ユーザーからのリクエストはCloudFrontのエッジロケーションで受信されます。

  • PublicなCloudFrontエンドポイントに対するIP制限: クライアントがパブリックインターネット経由でCloudFrontにアクセスする場合、WAFによるIP制限はクライアントのグローバルIPアドレスに対して機能します。オリジンがPrivateLink経由でCloudFrontに接続されていても、このWAFによる制限はユーザーとCloudFrontの間で動作します。
  • VPC内からのアクセス: VPC内からCloudFront（あるいはオリジン）にアクセスする場合、通常はPrivate IPアドレスが使用されます。このようなPrivate IPに対するWAFでの制限は、CloudFrontと連携するWAFでは直接行うことはできません（WAF for CloudFrontはグローバルIPを検査するため）。VPC内からのアクセスに対する制限は、セキュリティグループやネットワークACL、またはオリジン側の設定（例えば、ALBに対するWAF、EC2に対するOSファイアウォールなど）で行う必要があります。

6. 料金体系の理解

CloudFrontおよびAWS WAFは従量課金サービスです。IPアドレス制限を設定する前に、料金体系を理解しておくことが重要です。

  • CloudFront料金: データ転送量、リクエスト数、エッジロケーションなどに基づきます。WAFの使用自体がCloudFrontのリクエスト料金に直接影響を与えるわけではありませんが、WAFでブロックされたリクエストはオリジンへの転送が発生しないため、データ転送量やオリジンリクエスト数の削減につながる可能性があります。
  • AWS WAF料金:
    • Web ACL数: 作成したWeb ACLの数に対して月額料金がかかります。
    • ルール数: Web ACL内のルールの数に対して月額料金がかかります。
    • 処理されたリクエスト数: Web ACLに関連付けられたリソース（CloudFrontディストリビューション）で処理されたリクエスト数に対して料金がかかります。これは、WAFで許可されたリクエスト、ブロックされたリクエスト、カウントされたリクエストのすべてを含みます。
  • IPアドレス制限のためにIPセットとルールを作成し、Web ACLに関連付けることで、上記の料金が発生します。大量のリクエストがある場合は、WAFの処理リクエスト数に基づく料金が主なコスト要因となる可能性があります。最新の料金情報はAWS公式ウェブサイトで確認してください。

7. CIDR表記の正確性

IPアドレスリストを指定する際は、CIDR (Classless Inter-Domain Routing) 形式を使用します。CIDRは、IPアドレスとネットワークプレフィックス長（スラッシュの後に続く数値）で構成されます。

  • 単一のIPv4アドレス: 192.0.2.1/32
  • ネットワークアドレス: 192.0.2.0/24 (192.0.2.0 から 192.0.2.255 の範囲)
  • 単一のIPv6アドレス: 2001:db8::1/128
  • IPv6ネットワークアドレス: 2001:db8::/32

IPセットに間違ったCIDR形式を入力すると、意図した通りにIPアドレスが許可または拒否されない原因となります。特に、単一のIPアドレスを指定する場合のプレフィックス長（IPv4は/32、IPv6は/128）を間違えないように注意が必要です。

8. 最小特権の原則

セキュリティのベストプラクティスとして、常に最小特権の原則（Least Privilege Principle）を適用することが推奨されます。IPアドレス制限においても、必要最小限のIPアドレスのみを許可リストに含めるようにします。広すぎる範囲（例えば、不要な大きなサブネット）を許可リストに含めると、セキュリティリスクを高める可能性があります。定期的に許可リストを見直し、不要になったIPアドレスを削除することも重要です。

9. モニタリングとアラート

IPアドレス制限が正しく機能しているか、そして不審なアクセス試行が発生していないかを継続的に監視することは重要です。

  • CloudWatch Metrics: 前述のように、BlockedRequestsなどのWAFメトリクスを監視します。通常時よりもブロックされたリクエスト数が異常に増加した場合、DDoS攻撃やブルートフォース攻撃の兆候である可能性があります。
  • CloudWatch Alarms: 特定のメトリクス（例: BlockedRequests）が閾値を超えた場合に通知（SNS、Lambda、OpsGenieなど）を受け取るようにアラームを設定します。これにより、問題発生時に迅速に検知・対応できます。
  • WAF Full logging: 詳細なログが必要な場合は、WAFのFull loggingを有効にし、S3やCloudWatch Logsにログを保存・分析します。これにより、どのIPアドレスからのリクエストがブロックされたのか、どのルールに一致したのかなどを詳細に調査できます。Amazon AthenaやElasticsearch Service (OpenSearch Service) などと連携してログを検索・分析することで、攻撃パターンの特定や不正アクセスの詳細な追跡が可能になります。

これらのモニタリングとアラートの仕組みを構築しておくことで、セキュリティインシデントの早期発見と対応、および日々の運用の健全性確認に役立ちます。

トラブルシューティング

設定したはずのIPアドレス制限が意図通りに動作しない場合の一般的な原因と、確認すべき項目をいくつか挙げます。

1. アクセスできない（許可したIPから）

許可リストに含めたIPアドレスからアクセスできない場合、以下の点を確認します。

  • WAF Web ACLの関連付け: CloudFrontディストリビューションに正しいWeb ACLが関連付けられているか確認します。関連付けが間違っているか、または関連付けがまだ反映されていない可能性があります。
  • WAF Web ACLのステータス: Web ACLが「Active」ステータスになっているか確認します。
  • WAFルール:
    • 許可したいIPアドレスが、IP許可リストを参照するAllowルールに正しく含まれているか確認します。
    • ルールの条件（Inspect, IP set, IP address source）が正しく設定されているか確認します。特にSource IP addressが選択されているか確認します。
    • ルールのアクションが「Allow」になっているか確認します。
    • ルールの優先順位が、そのリクエストをブロックする可能性のある他のルール（例えば、レートベースルールやデフォルトのBlockアクション）よりも高くなっているか確認します。
  • IPセット:
    • 許可したいIPアドレスが、Allowルールで参照しているIPセットに正しく、かつ正しいCIDR形式で含まれているか確認します。単一IPの場合は/32 (IPv4) または/128 (IPv6) であることを確認します。
    • 使用しているクライアントのパブリックIPアドレスが許可リストに含まれているか確認します。必要であれば、クライアントの現在のパブリックIPアドレスを外部サイト（例: 確認くんなど）で確認し、IPセットの内容と照合します。
  • デフォルトアクション: デフォルトアクションがBlockになっている場合、許可リストにないIPからのリクエストはブロックされます。許可したはずのIPからのリクエストがどのAllowルールにも一致しなかった場合に、このデフォルトアクションでブロックされている可能性があります。
  • WAF Sampled requests: WAFコンソールのSampled requestsを確認し、該当するリクエストがどのように処理されたか（どのルールに一致し、最終的にAllowed/Blockedどちらになったか）を確認します。リクエストがブロックされている場合、どのルールによってブロックされたのか、あるいはデフォルトアクションでブロックされたのかが分かります。
  • CloudFront キャッシュ: CloudFrontのキャッシュが古い応答を返している可能性があります。キャッシュをクリアするか、クエリパラメータを変更してキャッシュをバイパスして試行します。
  • オリジン側のファイアウォール: CloudFrontからのリクエストをオリジン側でブロックしている可能性もゼロではありません。ただし、WAFでAllowされたリクエストは通常オリジンに到達するため、WAF設定が原因でなければオリジン側も確認します。
  • クライアント側の問題: クライアント側のファイアウォール設定やネットワーク設定が、接続を妨げている可能性も考慮します。

2. アクセスできてしまう（許可していないIPから）

許可リストに含まれていないIPアドレスからアクセスできてしまう場合、以下の点を確認します。

  • WAF Web ACLの関連付け: CloudFrontディストリビューションに正しいWeb ACLが関連付けられているか確認します。
  • WAFルール:
    • 意図しない他のAllowルールに、そのリクエストが一致してしまっている可能性を検討します。ルールの優先順位が関係していることもあります。
    • IPセットを参照するルール以外のルール（例えば、特定のヘッダーやクエリ文字列に基づくルール、レートベースルールなど）がないか確認し、それらのルールが誤ってリクエストを許可していないか確認します。
  • IPセット: 許可リストに入れるべきではないIPアドレスが、誤ってIPセットに含まれていないか確認します。また、ネットワーク範囲（CIDRプレフィックス長）が広すぎないか確認します。
  • デフォルトアクション: デフォルトアクションが「Block」になっているか再確認します。「Allow」になっていると、どのルールにも一致しないすべてリクエストが許可されてしまいます。許可リスト方式ではデフォルトアクションは「Block」が必須です。
  • ルールの優先順位: 意図しないAllowルールが、デフォルトのBlockアクションよりも優先度が高く設定されていないか確認します。
  • WAF Sampled requests: 許可されてしまったリクエストがどのように処理されたか（どのルールに一致し、最終的にAllowedになったか）を確認します。これにより、問題の原因となっているルールを特定できます。
  • プロキシ/VPNの利用: アクセス元のIPアドレスが、ユーザーが想定しているものと異なっている可能性があります。ユーザーが知らず知らずのうちにVPNやウェブプロキシを経由してアクセスしており、そのプロキシ/VPNサーバーのIPアドレスが許可リストに含まれている、というケースが考えられます。

まとめ

AWS CloudFrontで特定のIPアドレスからのアクセスのみを許可する設定は、AWS WAFとの連携によって実現されます。WAFでWeb ACLを作成し、その中に許可したいIPアドレスを定義したIPセットを参照するAllowルールを作成し、最後にデフォルトアクションをBlockに設定することで、特定のIPアドレスリストに含まれるIPからのアクセスのみを許可し、それ以外は拒否するという強力なアクセス制御をCloudFrontのエッジロケーションで実現できます。

この設定は、ウェブサイトの管理画面へのアクセス制限、特定のユーザーグループへのコンテンツ配信、テスト環境へのアクセス制御など、様々なセキュリティおよび運用上の要件を満たす上で非常に有効です。エッジでのブロックにより、オリジンサーバーへの負荷を軽減し、セキュリティを強化できるというメリットがあります。

設定手順自体はシンプルですが、IPv4とIPv6の両方への対応、動的なIPアドレスへの対応、複数のIPリストの管理、特定のパスへの制限、地理的制限との組み合わせ、そしてIPアドレスリストの更新管理など、運用フェーズに入ると考慮すべき点がいくつかあります。また、CloudFrontおよびWAFの料金体系を理解し、モニタリングとアラートの仕組みを構築しておくことも、安定した安全な運用には不可欠です。

最後に、セキュリティ設定は常に最新の状態に保ち、定期的に見直すことが重要です。許可リストに含まれるIPアドレスが適切か、不要なIPアドレスが含まれていないかなどを定期的に棚卸しし、必要に応じてIPセットを更新してください。この記事で解説した詳細な手順と考慮事項が、CloudFrontとWAFを活用したセキュアなコンテンツ配信環境の構築と運用の一助となれば幸いです。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール