ファイアウォールによるアクセスの制御

ファイアウォールにより、通過を許可するネットワーク トラフィックと拒否するネットワーク トラフィックが判別されます。App Engine では、優先順位が付けられた最大 1,000 個の個別ルールを持つファイアウォールを作成できます。個別ルールは、IP アドレスとサブネットの範囲で許可または制限を設定します。アプリはファイアウォールから許可されたリクエストだけに応答します。

準備

アプリに App Engine ファイアウォール ルールを作成するには、次のいずれかの App Engine IAM ロールが必要です。これらのロールには、ファイアウォール ルールの作成または変更に必要な権限が含まれています。

  • App Engine 管理者
  • 編集者
  • オーナー

ファイアウォール ルールの作成

ファイアウォール ルールは、次のいずれかの方法で作成します。追加するルールごとに次の手順を繰り返します。

Console

Cloud Console の [ファイアウォール ルール] ページを使用してファイアウォール ルールを作成します。

  1. Cloud Console で [ファイアウォール ルールの作成] ページに移動します。

    [ファイアウォール ルールの作成] ページに移動

  2. ファイアウォール ルールの詳細を指定します。

    1. [優先度] に、ルールの相対的な重要度を表す整数を入力し、ルールの評価順序を定義します。

      有効な値は 12147483646 です。 優先度 1 のルールが最初に評価されます。優先度 2147483647 のルールは最後に評価されますが、この値は default ルール用に予約されています。

    2. [一致したときのアクション] で、ルールに一致したリクエストのアクセスを許可するか拒否するかを指定します。ルールに allow を設定すると、リクエストがアプリケーションに転送されます。ルールに deny を設定すると、リクエストには 403 Forbidden エラーが返されます。
    3. [IP 範囲] で、ルールを適用する IP アドレスの範囲を定義します。IP アドレスの範囲は CIDR 表記で定義する必要があります。ここにはサブネット マスクを使用することもでき、IPv4 と IPv6 の両方に対応しています。
    4. (省略可)[説明] に、ルールの説明を 100 文字以内で入力します。
  3. [保存] をクリックすると、ルールが作成されます。
  4. ルールをテストし、優先度とアクションが期待どおり動作することを確認します。
    1. [IP アドレスをテスト] をクリックします。
    2. 検証する IP アドレスを入力し、[テスト] をクリックします。対応するルールが正しく評価されていることを確認します。
gcloud

次の gcloud app firewall-rules コマンドを実行して、ファイアウォール ルールを作成します。

  1. 次のコマンドを実行して、ファイアウォール ルールを作成します。

    gcloud app firewall-rules create PRIORITY --action ALLOW_OR_DENY --source-range IP_RANGE --description DESCRIPTION
    ここで
    • PRIORITY には、1 から 2147483646 までの整数を指定します。この値によりルールの重要度と評価順序が定義されます。優先度 1 のルールが最初に評価されます。優先度 2147483647 のルールは最後に評価されます。この値は default ルール用に予約されています。
    • ALLOW_OR_DENY は、ルールに一致したリクエストのアクセスを許可するか拒否するかを指定します。有効な値は allow または deny です。ルールに allow を設定すると、リクエストがアプリケーションに転送されます。ルールにdeny を設定すると、リクエストには 403 Forbidden エラーが返されます。
    • IP_RANGE には、ルールを適用する IP アドレスの範囲を指定します。IP 範囲は CIDR 表記で定義する必要があります。ここにはサブネット マスクを使用することもでき、IPv4 と IPv6 の両方に対応しています。
    • DESCRIPTION には、ルールの説明を 100 文字以内で指定します。これは省略可能です。
  2. 次のコマンドを実行してルールをテストし、優先度とアクションが期待どおり動作することを確認します。
    gcloud app firewall-rules test-ip IP_ADDRESS
    IP_ADDRESS はファイアウォールでテストする IP アドレスです。
  3. 既存のルールを一覧表示するには、次のコマンドを実行します。
    gcloud app firewall-rules list
  4. 既存のルールを削除するには、次のコマンドを実行します。
    gcloud app firewall-rules delete PRIORITY
    PRIORITY は、削除するルールの優先度値です。
例:
以下のサンプルを参考にして、ファイアウォールを作成してください。
  • IPv6 アドレスとサブネット マスクを許可するルールを追加し、そのルールをテストして、他のルールより前に評価されることを確認します。

    gcloud app firewall-rules create 123 --source-range fe80::3636:3bff:fecc:8778/128 --action allow
    gcloud app firewall-rules test-ip fe80::3636:3bff:fecc:8778
  • IPv4 アドレスとサブネット マスクを拒否するルールを追加し、そのルールをテストして、適切に評価されることを確認します。

    gcloud app firewall-rules create 123456 --source-range "74.125.0.0/16" --action deny
    gcloud app firewall-rules test-ip 74.125.0.8
  • default ルールを更新してテストし、他のルールと一致しないすべての IP アドレスが制限されることを確認します。

    gcloud app firewall-rules update default --action deny
    gcloud app firewall-rules test-ip 123.456.7.89
API

App Engine アプリケーションのファイアウォール ルールをプログラムで作成するには、Admin API の apps.firewall.ingressRules メソッドを使用します。

ファイアウォール ルールをテストして、優先度とアクションが期待どおりに動作することを確認するには、apps.firewall.ingressRules.list メソッドを使用し、テストする IP アドレスを matchingAddress パラメータ内で指定します。

App Engine ファイアウォール ルールについて

App Engine ファイアウォールは、指定した IP アドレスまたはアドレスの範囲からのアプリへのアクセスを許可または拒否するルールに優先度を設定してリストしたもので構成されます。このルールは、App Engine アプリケーションのすべてのリソースに適用されます。

ファイアウォール ルールは重要度順に並べられます。この重要度は、各ルールの優先度で数値として定義します。ルールの優先度によって、ファイアウォール内の他のルールとの相対的な重要度が定義されます。したがって、各ルールに指定する値は一意でなければなりません。ルールの優先度は 1 から 2147483647 であり、値が小さいほど重要度が高くなります。

各ファイアウォールには default ルールが自動的に作成されます。このルールの優先度は 2147483647 に設定され、アプリケーションの IP 範囲全体に適用されます。default ルールは、常にファイアウォール内で最後に評価され、すべての IP アドレスからのリクエストに適用されます。

ファイアウォールでは、最も優先度が高いルールが最初に評価されます。 ファイアウォール内の残りのルールは、そのリクエストの IP 範囲と一致するルールが見つかるまで順番に評価されます。一致するルールが見つかると、接続が許可または拒否され、ファイアウォール内の残りのルールはすべてスキップされます。リクエストに一致する手動定義のルールがファイアウォール内にない場合、default ルールが評価されます。

たとえば、優先度 1 のルールを作成すると、このルールが常に最初に評価されます。受信したリクエストが優先度 1 のルールと一致すると、このルールのみが評価され、ファイアウォール内の残りのルールはすべてスキップされます。default ルールも評価されません。

下のファイアウォールの例は、ルールの優先度がファイアウォールの動作にどのように影響するかを示しています。

App Engine ファイアウォールと Cloud Load Balancing

Cloud Load Balancing とサーバーレス NEGS を使用する場合は、次の点に注意してください。

  • ロードバランサにより、App Engine ファイアウォール ルールが妨げられることや、ロードバランサが App Engine ファイアウォール ルールに関わることはありません。App Engine ルールは、サーバーレス NEG が App Engine にトラフィックを転送するまで評価されません。
  • Google Cloud によって App Engine サービスに自動的に割り当てられる URL を無効にすることはできません。App Engine サービスのデフォルト URL がすでに割り当てられているユーザーは、ロードバランサをバイパスしてサービス URL に直接アクセスできます。つまり、Google Cloud Armor セキュリティ ポリシー、SSL 証明書、秘密鍵をロードバランサから構成できますが、デフォルト URL を割り当てられたユーザーはこれらのポリシーを回避できます。

ファイアウォールの例

この例では、エンジニアリング チームと社内ネットワークに、開発中のアプリへのアクセスを許可するようにファイアウォールを設定しています。後で変更に対応できるように、ファイアウォール ルールの優先度は余裕をもって設定されています。

優先度 アクション IP 範囲 説明
1000 拒否 192.0.2.1 DoS 攻撃者のアクセスを拒否します。
2000 許可 198.51.100.2 サテライト オフィスのエンジニアにアクセスを許可します。
3000 拒否 198.51.100.0/24 エンジニアが勤務していない建物に対するアクセスをすべて拒否します。
5000 許可 203.0.113.0/24 本館のネットワークに対するアクセスを許可します。
2147483647 拒否 * デフォルトのアクション

ファイアウォールの作成後に、次のリクエストがサンプルアプリに発行されたと仮定して、アプリのレスポンスに注目してください。

  • 198.51.100.2 からのリクエスト: 優先度 2000 のルールと一致するため許可されます。
  • 198.51.100.100 からのリクエスト: 優先度 3000 のルールと一致するため拒否されます。
  • 203.0.113.54 からのリクエスト: 優先度 5000 のルールと一致するため許可されます。
  • 45.123.35.242 からのリクエスト: default ルールと一致するため拒否されます。

競合するルールの解決

たとえば、この会社のファイアウォール内の 2 つの優先度を入れ替えるとします。優先度 2000 と 3000 のルールを入れ替えると、意図しない動作が発生します。

優先度 アクション IP 範囲 説明
1000 拒否 192.0.2.1 DoS 攻撃者のアクセスを拒否します。
2000 拒否 198.51.100.0/24 エンジニアが勤務していない建物に対するアクセスをすべて拒否します。
3000 許可 198.51.100.2 サテライト オフィスのエンジニアにアクセスを許可します。
5000 許可 203.0.113.0/24 本館のネットワークに対するアクセスを許可します。
2147483647 拒否 * デフォルトのアクション

新しい優先度では、サテライト オフィスのエンジニアにアクセスを許可するルールが評価されないため、サテライト オフィスのエンジニアは会社のアプリにアクセスできなくなります。エンジニアの IP アドレス 198.51.100.2 は、この IP アドレスに対しアクセスを許可するルールの前に、198.51.100.0/24 の範囲内のエンジニア以外のユーザーをすべて拒否するルールと一致します。

これを修正するには、198.51.100.2 に対してアクセスを許可するルールに、IP 範囲 198.51.100.0/24 に対するアクセスを拒否するルールよりも高い優先度を設定する必要があります。

サービスからのリクエストの許可

ルールを作成する場合は、次の点を考慮する必要があります。

  • デフォルトで、ルールに一致しないリクエストには、アプリへのアクセスが許可されます。特定のルールに一致しないリクエストをすべてブロックするには、default ルールを deny に設定する必要があります。
  • default ルールが deny に設定されていても、タスクキュー トラフィックはファイアウォールによって許可されます。
  • cron トラフィックは、スタンダード環境で許可されます。App Engine アプリからの受信 cron リクエストを検証するには、cron リクエストの検証をご覧ください。

    フレキシブル環境では、cron トラフィックを明示的に許可する必要があります。App Engine フレキシブル環境でのファイアウォール ルールの作成について、詳しくはファイアウォールの作成をご覧ください。

  • 他の App Engine アプリやサービスからのリクエストに対するアクセスを制御するために、サービス間通信で使われる IP アドレスを受け入れるルールを作成しなければならないことがあります。アプリが App Engine の他のアプリやサービスと通信する場合は、次の IP アドレスからのリクエストをどう処理するか検討してください。

    • URL 取得サービスからのリクエスト: 0.1.0.40
      • スタンダード環境で受信するリクエスト: 0.1.0.40
      • フレキシブル環境で受信するリクエスト: 0.1.0.4010.0.0.1
      • 0.1.0.40 または 10.0.0.1 からのリクエスト。任意の App Engine アプリから受信する可能性があります。
      • 送信元のアプリ ID を特定するには、X-Appengine-Inbound-AppId ヘッダーを使用できます。
    • Blobstore または Cloud Storage からのリクエスト: 0.1.0.30
    • スタンダード環境でのみ受信するリクエスト:
      • アプリのデプロイ リクエスト: 10.1.0.41
    • 限定公開の Google アクセスが有効な Compute Engine インスタンスからのリクエスト: 0.0.0.0
      • 0.0.0.0 からのリクエスト。限定公開の Google アクセスが有効な任意の Compute Engine インスタンスから受信されます。

    スタンダード環境で動作するバックエンド サービス(backend_std)をアプリケーションが利用しているとします。このサービスは、URL 取得サービスを使用して backend_flex と通信します。

    リクエストを許可するルール、および backend_flex 内の X-Appengine-Inbound-AppId ヘッダーを読み取って backend_std のアプリ ID に対応していることを確認するルールの 2 種類のファイアウォール ルールを作成する必要があります。

    • 0.1.0.40 - backend_flexbackend_std からの URL 取得リクエストの受信を許可するルール。
    • 10.0.0.1 - backend_flex の URL 取得リクエストに対してサービス間通信を許可するルール。
    • リクエストが許可されるのは、backend_flex 内で X-Appengine-Inbound-AppId ヘッダーが backend_std の ID と一致する場合のみ。

キャッシュに保存されたコンテンツへのアクセスの防止

App Engine ファイアウォールは、コンテンツ キャッシュ メカニズム(ウェブプロキシやブラウザなど)の背後に設置されます。コンテンツがキャッシュに保存されると、期限切れになるまでコンテンツは特定の URL から提供され、新しいファイアウォール ルールを作成してもそのコンテンツにはアクセスできます。

静的コンテンツのデフォルトの有効期限の変更または、静的コンテンツがキャッシュに保存されないようにする方法については、キャッシュの有効期限をご覧ください。

アプリのコードからの動的コンテンツの出力がキャッシュに保存されないようにするには、Cache-ControlExpires の HTTP レスポンス ヘッダーを使用します。キャッシュの制御方法など、HTTP ヘッダーの詳細については、キャッシュの回避をご覧ください。

次のステップ

アプリを安全に構成して適切なアクセスレベルを設定するには、アプリケーション セキュリティアクセス制御をご覧ください。