GSP909

概要

このラボでは、Apigee X 脅威対策ポリシーを使用して、コンテンツベースの脅威から API を保護します。また、グローバル外部 HTTPS ロードバランサに Cloud Armor を追加して、分散型サービス拒否攻撃（DDoS）からの保護、OWASP Top 10 リスクの軽減、IP ベースと位置情報ベースのアクセス制御などのウェブ アプリケーション ファイアウォール機能を提供します。

ランタイム インスタンスへのアクセスを提供するために、ロードバランサと、ブリッジ VM のマネージド インスタンス グループが作成されています。この構成のアーキテクチャは次のとおりです。

受信 API 呼び出しは、グローバル外部 HTTPS ロードバランサを介して顧客プロジェクトに入ります。外部 HTTPS ロードバランサは、テナント プロジェクトへの呼び出しを転送できません。代わりに、ロードバランサはリクエストを、お客様のプロジェクト内のブリッジ VM のマネージド インスタンス グループに転送します。これらのブリッジ VM は、Apigee ランタイム インスタンスに接続されたピアリングされたネットワーク内にあり、VM が API 呼び出しをランタイム インスタンスに転送できるようにします。

ロードバランサに送信された HTTP トラフィックは、ブリッジ VM に転送されてから、Apigee ランタイム インスタンスに転送されます。Cloud Armor セキュリティ ポリシーを追加して、特定のトラフィックがランタイムに送信されないようにします。

JSON 攻撃と XML 攻撃では、JSON パーサーと XML パーサーに過剰な負荷をかけてアプリケーション レベルのサービス拒否攻撃を引き起こすように構築されたペイロードが使用されます。Cloud Armor ではこのような攻撃は検出されませんが、Apigee では検出できます。JSONThreatProtection ポリシーと XMLThreatProtection ポリシーは、ペイロードをパーサーに読み込むことなく、これらの悪意のあるペイロードを検出できます。JSONThreatProtection ポリシーを使用して、不正な形式の JSON ペイロードから保護します。

このラボの手順は、有料組織と評価組織の両方に適用できます。

目標

このラボでは、次のタスクの実行方法について学びます。

• Apigee の脅威対策ポリシーを使用して、悪意のある JSON ペイロードと XML ペイロードをブロックする
• Cloud Armor ポリシーを作成する
• リクエストのブロックと許可を行う Cloud Armor ルールを作成する
• ロードバランサに Cloud Armor ポリシーを適用する
• HTTP トラフィックを使用して Cloud Armor ポリシーをテストする

設定

[ラボを開始] ボタンをクリックする前に

こちらの説明をお読みください。ラボには時間制限があり、一時停止することはできません。タイマーは、Google Cloud のリソースを利用できる時間を示しており、[ラボを開始] をクリックするとスタートします。

このハンズオンラボでは、シミュレーションやデモ環境ではなく実際のクラウド環境を使って、ラボのアクティビティを行います。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モード（推奨）またはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生しないようにすることができます。

• ラボを完了するための時間（開始後は一時停止できません）

注: このラボでは、受講者アカウントのみを使用してください。別の Google Cloud アカウントを使用すると、そのアカウントに料金が発生する可能性があります。 注: このラボを実施する際には、新しいシークレット ウィンドウを使用することをおすすめします。

ラボを開始して Google Cloud コンソールにログインする方法

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるダイアログでお支払い方法を選択してください。 右側の [ラボの設定とアクセス] パネルには、以下が表示されます。

   • [Google Cloud コンソールを開く] ボタン
   • このラボで使用する一時的な認証情報（ユーザー名とパスワード）
   • このラボを行うために必要なその他の情報（ある場合）

   ラボのタイマーはページの上部に表示され、残り時間が示されます。

2. [Google Cloud コンソールを開く] をクリックします（Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く] を選択します）。

   ラボでリソースがスピンアップし、別のタブで [ログイン] ページが表示されます。

   ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

   注: [アカウントの選択] ダイアログが表示された場合は、[別のアカウントを使用] をクリックします。

3. 必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。

   {{{user_0.username | "Username"}}}

   [ラボの設定とアクセス] パネルでもユーザー名を確認できます。

4. [次へ] をクリックします。

5. 以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。

   {{{user_0.password | "Password"}}}

   [ラボの設定とアクセス] パネルでもパスワードを確認できます。

6. [次へ] をクリックします。

   重要: ラボで指定された認証情報を使用する必要があります。ご自身の Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

7. その後のページはクリックして先に進みます。

   • 利用規約に同意します。
   • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
   • 無料トライアルには登録しないでください。

しばらくすると、このタブで Google Cloud コンソールが開きます。

注: Google Cloud のプロダクトやサービスにアクセスするには、ナビゲーション メニューをクリックするか、[検索] フィールドにサービス名またはプロダクト名を入力します。

Cloud Shell をアクティブにする

Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン をクリックします。

2. ウィンドウで次の操作を行います。

   • Cloud Shell 情報ウィンドウで操作を進めます。
   • Cloud Shell が認証情報を使用して Google Cloud API を呼び出すことを承認します。

接続した時点で認証が完了しており、プロジェクトに各自の Project_ID、 が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

3. （省略可）次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

4. [承認] をクリックします。

出力:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. （省略可）次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

タスク 1. JSON Threat Protection 共有フローを作成する

このタスクでは、JSONThreatProtection ポリシーを含む共有フローを作成し、フローフックを使用してすべての Apigee API で有効にします。

JSONThreatProtection ポリシーは、指定された上限を超える受信 JSON リクエストを拒否します。ポリシーを共有フローに配置し、フローフックで共有フローを接続することで、ポリシーは環境にデプロイされたすべてのプロキシに対するリクエストを保護できます。

Apigee コンソールを開く

Apigee コンソールを開くには、次の手順に沿って操作します。

• Google Cloud コンソールで、検索バーに「Apigee」と入力し、[プロダクトとページ] の結果から [Apigee] を選択します。

Apigee コンソールが開き、API、環境、プロキシ、デプロイを管理できます。

共有フローを作成する

1. ナビゲーション メニューで、[プロキシ開発] > [共有フロー] を選択します。

2. [作成] をクリックします。

   共有フローには、一連のポリシーと条件を含めることができ、FlowCallout ポリシーを使用して API プロキシや他の共有フローで実行できます。このラボでは、フローフックで共有フローを使用します。これにより、評価組織にデプロイされたすべてのプロキシに共有フローが接続されます。

3. 共有フローに protect-json という名前を付け、[作成] をクリックします。

4. [開発] タブをクリックします。

5. 共有フローの左側のメニューで、[共有フロー] セクションの [デフォルト] をクリックします。

6. [sharedflows/default.xml] ペインで、ポリシーステップを追加（）をクリックします。

7. [ポリシーを選択] で、[新しいポリシーを作成] を選択します。

8. [JSON Threat Protection] を選択し、[表示名] と [名前] を JTP-Protect に設定します。

9. [追加] をクリックします。

   JSONThreatProtection ポリシーには、受信する JSON リクエストに上限を設けるための要素がいくつか含まれています。通常、これらの上限は API の最大値に基づいて設定します。この場合、ポリシーのデフォルト構成を維持します。

   このポリシーは、リクエストの Content-Type ヘッダーが application/json に設定されている場合にのみ実行されます。これは、受信リクエストに JSON ペイロードが含まれていることを示します。

10. [保存] をクリックします。

11. [デプロイ] をクリックし、[環境] で [eval] を選択します。

12. [デプロイ]、[確認] の順にクリックします。

共有フローをフローフックに接続する

共有フローはプロキシ前フローフックに接続され、プロキシが実行される前に実行されます。

1. [管理] > [環境] に移動します。

2. [eval] > [フローフック] をクリックします。

3. [プロキシ前] 行のプルダウンから [protect-json] 共有フローを選択し、[保存] をクリックします。

   このフローフックは、後のタスクでテストします。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 共有フローとフローフックを作成する

タスク 2. Cloud Armor セキュリティ ポリシーを追加する

このタスクでは、ロードバランサを保護し、API へのアクセスを制御するために、Cloud Armor セキュリティ ポリシーを追加します。

Cloud Armor は、Google Cloud のウェブ アプリケーション ファイアウォールです。ロードバランサに対して指定できる Cloud Armor ポリシーは 1 つだけです。このラボでは、Cloud Armor セキュリティ ポリシーを使用して、特定のトラフィックが Apigee ランタイム インスタンスに到達する前に拒否し、API を保護します。

注: Apigee ランタイム インスタンスの IP アドレスが判明するまでロードバランサを完全に構成することはできません。そのため、ロードバランサの構成が完了するまで、ロードバランサに異常なインスタンスが表示されることがあります。

新しいセキュリティ ポリシーを作成する

1. Cloud コンソールのタブで、ナビゲーション メニュー（）から [すべてのプロダクトを表示] をクリックし、[ネットワーキング] セクションで [ネットワーク セキュリティ] を選択して、[Cloud Armor ポリシー] に移動します。

2. [ポリシーを作成] をクリックします。

3. [名前] に「protect-apis」を指定します。

   このセキュリティ ポリシーでは、ルールを使用して、Apigee API 宛ての特定のトラフィックをブロックします。

4. [デフォルトのルール アクション] で [拒否] を選択します。

   トラフィックを明示的に許可するルールに一致しない限り、ユーザーは API へのアクセスを拒否されます。

5. [拒否ステータス] プルダウンで [403（アクセス拒否）] を選択します。

   トラフィックを許可するルールにリクエストが一致しない場合は、ステータス コード 403 Forbidden がユーザーに返されます。

6. [次のステップ] をクリックします。

送信元国コードによるリクエストを許可するセキュリティ ポリシー ルールを追加する

このルールでは、指定した国からのリクエストのみが許可されます。

1. [ルールの追加] をクリックします。

2. [詳細モード] をクリックします。

   基本モードのルールでは、一致する IP アドレスまたは IP アドレス範囲のみを指定できます。この場合、許可する国コードを指定します。

3. [一致] に次の式を指定します。

   origin.region_code == 'US'

   Cloud Armor の場合、region_code は ISO 3166-2 リージョンとして指定されます。このルールは、米国からのリクエストに一致します。

4. [アクション] で [許可] を指定します。

5. [優先度] を 1000 に設定し、[ルールの変更を保存] をクリックします。

SQL インジェクション攻撃をブロックするルールを追加する

このルールは、SQL インジェクションにつながる可能性のある SQL 入力を含むリクエストをブロックします。

1. [ルールの追加] をクリックします。

2. [詳細モード] をクリックします。

3. [一致] に次の式を指定します。

   evaluatePreconfiguredExpr('sqli-stable', ['owasp-crs-v030001-id942251-sqli', 'owasp-crs-v030001-id942420-sqli', 'owasp-crs-v030001-id942431-sqli', 'owasp-crs-v030001-id942460-sqli', 'owasp-crs-v030001-id942421-sqli', 'owasp-crs-v030001-id942432-sqli'])

   この式は、事前構成済みの Cloud Armor ルールを指定します。事前構成されたルールでは、オープンソースの業界標準シグネチャを使用して悪意のあるリクエストを検出します。無効にするシグネチャの名前を指定することで、特定のシグネチャを無効にできます。

   この場合、感度レベル 3 と 4 のシグネチャはオフになります。シグネチャの感度レベル（パラノイア レベルとも呼ばれます）は、偽陽性の数が増える代わりにセキュリティ レベルが高くなるというトレードオフを指定します。

   レベル 1 はデフォルトのセキュリティ レベルで、誤検出はほとんど、あるいはまったく発生しません。レベル 2 では、高度で難読化された攻撃に対する保護が強化されます。レベル 3 と 4 のシグネチャはよりアグレッシブで、偽陽性を引き起こす可能性が大幅に高くなります。たとえば、単純な JSON ペイロードを含む POST リクエストは、レベル 3 または 4 のシグネチャによってフラグが立てられる可能性があります。

4. [アクション] は [拒否] のままにし、[拒否ステータス] は [403（アクセス拒否）] のままにします。

5. [優先度] を「500」に設定します。

   Cloud Armor ポリシーのルールが評価される際、リクエストに一致する最初のルールによって、実行されるアクションが指定されます。SQL インジェクションのチェックは、リージョンのチェックよりも前に行う必要があります。これは、許可されたリージョンからのリクエストであっても、SQL インジェクション パターンが含まれている場合は拒否するためです。優先順位の数値を小さくすると、リージョン チェックの前に SQL インジェクション チェックが行われます。

6. [ルールの変更を保存] をクリックします。

   右側の概要をご覧ください。ポリシーには 3 個のルールが含まれています。ルールは、優先度の数値が小さい順に評価され、最初に一致したルールが使用されます。

   最初のルールは、SQL インジェクション パターンが検出された場合にアクセスを拒否します。

   2 つ目のルールでは、送信元が米国の場合にアクセスが許可されます。

   最後のルールは、すべてのトラフィックのアクセスを拒否します。

7. [ポリシーを作成] をクリックします。

   [ポリシー] タブには、新しい protect-apis ポリシーのターゲットが 0 と表示されます。これは、まだロードバランサに接続していないためです。

ポリシーをロードバランサに接続する

1. [protect-apis] の横にあるポリシー メニューボタン（）をクリックし、[ターゲットにポリシーを適用] をクリックします。

2. [Backend Service 1] プルダウンで [apigee-proxy-backend] を選択し、[追加] をクリックします。

   [protect-apis] ポリシーの詳細ページに、ポリシーが 1 つのターゲットに適用されていることがすぐに表示されます。

   注: Cloud Armor の変更がターゲットに反映されるまで数分かかることがあります。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Cloud Armor セキュリティ ポリシーを追加する

タスク 3. Apigee インスタンスのプロビジョニングが完了するまで待機する

このタスクでは、Apigee 評価組織のプロビジョニングが完了するまで待ちます。

Apigee 組織のプロビジョニングが完了するまでには、かなりの時間がかかる場合があります。組織のプロビジョニングの進行状況は、Apigee API を使用してモニタリングできます。

モニタリング スクリプトを開始する

1. Cloud Shell で、次のコマンドを使用して、GOOGLE_CLOUD_PROJECT 変数にプロジェクト名が含まれていることを確認します。

   echo ${GOOGLE_CLOUD_PROJECT}

   変数 GOOGLE_CLOUD_PROJECT には、プロジェクトの名前（Apigee 組織名と同じ）が含まれている必要があります。

2. GOOGLE_CLOUD_PROJECT 変数が設定されていない場合、{project} をプロジェクト名に置き換えて、次のようなコマンドを使用して変数を手動で設定します。

   export GOOGLE_CLOUD_PROJECT={project} 注: この手順では、中かっこを削除する必要があります。

3. 以下のコマンドを Cloud Shell に貼り付けます。

   export INSTANCE_NAME=eval-instance; export ENV_NAME=eval; export PREV_INSTANCE_STATE=; echo "waiting for runtime instance ${INSTANCE_NAME} to be active"; while : ; do export INSTANCE_STATE=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${GOOGLE_CLOUD_PROJECT}/instances/${INSTANCE_NAME}" | jq "select(.state != null) | .state" --raw-output); [[ "${INSTANCE_STATE}" == "${PREV_INSTANCE_STATE}" ]] || (echo; echo "INSTANCE_STATE=${INSTANCE_STATE}"); export PREV_INSTANCE_STATE=${INSTANCE_STATE}; [[ "${INSTANCE_STATE}" != "ACTIVE" ]] || break; echo -n "."; sleep 5; done; echo; echo "instance created, waiting for environment ${ENV_NAME} to be attached to instance"; while : ; do export ATTACHMENT_DONE=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${GOOGLE_CLOUD_PROJECT}/instances/${INSTANCE_NAME}/attachments" | jq "select(.attachments != null) | .attachments[] | select(.environment == \"${ENV_NAME}\") | .environment" --join-output); [[ "${ATTACHMENT_DONE}" != "${ENV_NAME}" ]] || break; echo -n "."; sleep 5; done; echo; echo "${ENV_NAME} environment attached, waiting for hello-world to be deployed"; while : ; do export ATTACHMENT_DONE=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${GOOGLE_CLOUD_PROJECT}/instances/${INSTANCE_NAME}/attachments" | jq "select(.attachments != null) | .attachments[] | select(.environment == \"${ENV_NAME}\") | .environment" --join-output); [[ "${ATTACHMENT_DONE}" != "${ENV_NAME}" ]] || break; echo -n "."; sleep 5; done; echo "***ORG IS READY TO USE***";

   この一連のコマンドでは、Apigee API を使用して、Apigee ランタイム インスタンスが作成されて eval 環境が接続されたことを確認します。

4. インスタンスが使用可能になるまで待ちます。

   ***ORG IS READY TO USE*** というテキストが表示されたら、インスタンスは使用可能です。

   注: コマンドで組織がすぐに使用可能であることが示された場合は、ラボに入る前にラボが事前ウォーミングされている可能性があります。

   組織の準備ができるまで待つ場合は、その間に Cloud Armor の概要、カスタムルール、事前構成済みルールの詳細をご覧ください。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 インスタンスの準備が整うまで待つ

タスク 4. 許可されたリージョンからテストする

このタスクでは、Cloud Armor セキュリティ ポリシーが API を保護していること、許可されたリージョンからの許容可能なトラフィックを許可していること、フローフックが JSON 脅威から保護していることを確認します。

apigeex-test-vm という名前の仮想マシンが自動的に作成されています。このマシンを使用して、米国から API を呼び出すことができます。

1. Cloud Shell で、米国にあるテスト VM への SSH 接続を開きます。

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

2. [Do you want to continue (Y/n)?] というメッセージが表示されたら、Y キーを押して続行します。

3. Cloud Shell で確認されるすべての項目について、Enter キーまたは Return キーを押して、デフォルトの入力を指定します。

   プロジェクトのオーナーとしてログインしているため、このマシンへの SSH は許可されます。

   これで、Cloud Shell セッションが VM 内で実行できるようになります。

4. hello-world API プロキシにアクセスできることを確認します。

   export PREV_STATUS_CODE=; echo "waiting for hello-world to be accessible"; while : ; do export STATUS_CODE=$(curl -k -s -o /dev/null -w "%{http_code}" --max-time 5 -X GET "https://eval.example.com/hello-world"); [[ "${STATUS_CODE}" == "${PREV_STATUS_CODE}" ]] || (echo; echo "STATUS_CODE=${STATUS_CODE}"); export PREV_STATUS_CODE=${STATUS_CODE}; [[ "${STATUS_CODE}" != "200" ]] || break; echo -n "."; sleep 5; done; echo; echo "***HELLO-WORLD IS ACCESSIBLE***";

   hello-world プロキシがデプロイされ、外部ロードバランサを介してプロキシが利用可能になるまでには、しばらく時間がかかる場合があります。これらのコマンドが ***HELLO-WORLD IS ACCESSIBLE*** を返したら、hello-world プロキシが利用可能になります。

5. eval 環境にデプロイした hello-world API プロキシを呼び出します。

   curl -i -k "https://eval.example.com/hello-world"

   ホスト名 eval.example.com の DNS エントリは、ロードバランサの受信 IP アドレスを使用して作成されています。

   -i オプションは、レスポンスのステータス コードとヘッダーを表示します。

   -k オプションは、ロードバランサの TLS 証明書の検証をスキップします。これは、ロードバランサに使用される TLS 証明書が、既知の認証局によって検証された証明書ではなく、自己署名証明書であるためです。

   注: -k オプションを使用して証明書の検証を省略することは、本番環境では避けてください。

   VM は米国に配置されているため、curl コマンドは hello-world プロキシによって生成された Hello, Guest! レスポンスを正常に返します。

   HTTP/2 200 x-powered-by: Apigee access-control-allow-origin: * x-frame-options: ALLOW-FROM RESOURCE-URL x-xss-protection: 1 x-content-type-options: nosniff content-type: text/plain; charset=utf-8 content-length: 13 etag: W/"d-GHB1ZrJKk/wdVTdB/jgBsw" date: Mon, 30 Aug 2021 19:14:45 GMT alt-svc: clear alt-svc: clear x-request-id: b5532b95-c051-4f21-a131-07da1574edc3 server: apigee via: 1.1 google, 1.1 google Hello, Guest!

6. 次のコマンドを使用して hello-world プロキシを呼び出します。

   curl -i -k -X POST "https://eval.example.com/hello-world" -H "Content-Type: application/json" -d '{ "ThisIsAReallyLongElementNameIMeanReallyReallyReallyLong": 42 }'

   このリクエストは、共有フローに含まれる JSONThreatProtection ポリシーで指定された ObjectEntryNameLength の上限を超えています。共有フローは、プロキシ前のフローフックを使用してすべての API プロキシに接続されます。

   レスポンスは次のようになります。

   HTTP/2 500 content-type: application/json x-request-id: 5360a9fb-b0b9-4fce-968c-22c2d3fd57dd content-length: 235 date: Mon, 30 Aug 2021 19:16:17 GMT server: apigee via: 1.1 google alt-svc: clear {"fault":{"faultstring":"JSONThreatProtection[JTP-Protect]: Execution failed. reason: JSONThreatProtection[JTP-Protect]: Exceeded object entry name length at line 1","detail":{"errorcode":"steps.jsonthreatprotection.ExecutionFailed"}}} 注: デフォルトで返されるステータス コードは 500 で、サーバーエラーを示します。このポリシーを本番環境で使用する場合は、サーバーエラーではなく、リクエストの問題を示すエラー（400 Bad Request など）を書き換える方が理にかなっています。

7. 次のコマンドを使用して、hello-world API プロキシを呼び出してみます。

   curl -i -k "https://eval.example.com/hello-world?item=name'%20OR%20'a'='a"

   item クエリ パラメータは、文字列を連結して SQL クエリを構築する場合に意図しない結果をもたらす可能性がある SQL インジェクション パターンを使用します。

   SQL インジェクション パターンが Cloud Armor によって正常に検出され、リクエストがブロックされて 403 Forbidden レスポンスが返されます。

   HTTP/2 403 content-length: 134 content-type: text/html; charset=UTF-8 date: Thu, 22 Jul 2021 18:50:03 GMT alt-svc: clear <!doctype html><meta charset="utf-8"><meta name=viewport content="width=device-width, initial-scale=1"><title>403</title>403 Forbidden 注: Cloud Armor ルールが伝播するまでには数分かかることがあります。リクエストがブロックされない場合は、リクエストがブロックされるまで呼び出しを再試行してください。

8. 「exit」と入力して、米国仮想マシンへの SSH 接続を閉じます。

タスク 5. 許可されていないリージョンからセキュリティ ポリシーをテストする

このタスクでは、Cloud Armor セキュリティ ポリシーで、許可リストに登録されていないリージョンのトラフィックが許可されないことを確認します。

apigeex-outside-us という名前の VM がゾーン に自動的に作成されています。このマシンを使用して、米国以外から API を呼び出すことができます。

1. Cloud Shell で、米国以外のテスト VM への SSH 接続を開きます。

export SECOND_VM_NAME=apigeex-outside-us export SECOND_VM_ZONE={{{project_0.default_zone_2| Secondary Zone}}} gcloud compute ssh ${SECOND_VM_NAME} --zone=${SECOND_VM_ZONE} --force-key-file-overwrite

2. 承認するよう求められた場合は、[承認] をクリックします。

3. Cloud Shell で確認されるすべての項目について、Enter キーまたは Return キーを押して、デフォルトの入力を指定します。

   プロジェクトのオーナーとしてログインしているため、このマシンへの SSH は許可されます。

   これで、Cloud Shell セッションが VM 内で実行できるようになります。

4. eval 環境にデプロイした hello-world API プロキシを呼び出します。

   curl -i -k "https://eval.example.com/hello-world"

   VM は米国にないため、Cloud Armor はリクエストをブロックし、403 を返します。

   HTTP/2 403 content-length: 134 content-type: text/html; charset=UTF-8 date: Thu, 22 Jul 2021 22:47:06 GMT alt-svc: clear <!doctype html><meta charset="utf-8"><meta name=viewport content="width=device-width, initial-scale=1"><title>403</title>403 Forbidden

タスク 6. Cloud Armor のポリシー モニタリングについて確認する

このタスクでは、Cloud Monitoring で Cloud Armor ポリシー ダッシュボードを確認します。

1. Cloud コンソールのタブで、[Monitoring] > [ダッシュボード] に移動します。

2. [Cloud Armor Policies Overview] をクリックします。

   このダッシュボードには、すべての Cloud Armor ポリシーで許可されたリクエストとブロックされたリクエストの割合が表示されます。現在、ポリシーは 1 つのみです。

3. [ポリシー] ペインで、[protect-apis] をクリックします。

   このダッシュボードには、protect-apis ポリシーで許可されたリクエストとブロックされたリクエストの割合が表示されます。

   個々のリクエストの詳細をログに記録するには、ロードバランサのリクエスト ロギングを有効にする必要があります。

お疲れさまでした

このラボでは、Cloud Armor ポリシーを作成し、そのポリシーを使用して、Cloud Armor ルールに基づいて受信トラフィックを拒否または許可しました。

次のステップと詳細情報

• Cloud Armor の概要
• Cloud Armor と Apigee のブログ投稿

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2025 年 9 月 17 日

ラボの最終テスト日: 2025 年 9 月 17 日

Copyright 2026 Google LLC. All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。