GSP844

概要

Apigee は API の開発と管理を行うためのプラットフォームで、API へのアクセスを保護し、アクセスのレートを制限することができます。また、API データへの内部アクセスを保護するための機能も備わっています。

このラボでは、アクセスに対して OAuth トークンを要求する API を作成します。SpikeArrest ポリシーを使用してアプリケーション別に API 呼び出しのレートを制限し、プライベート変数とデータ マスキングを使用して、API トラフィックをデバッグするユーザーに機密データが表示されないようにします。

目標

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

• OAuth トークンを要求して API へのアクセスを保護する
• SpikeArrest ポリシーを使用して、全体的なトラフィック レートとアプリケーション別のレートを制限する
• プライベート変数とデータ マスキングを使用して、API 呼び出しのデバッグ中に機密データを非表示にする
• 指定したリソースにバックエンドへの呼び出しを制限する
• データ漏洩を防ぐためにバックエンドのエラー メッセージを書き換える

設定と要件

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

こちらの説明をお読みください。ラボには時間制限があり、一時停止することはできません。タイマーは、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 の概要ガイドをご覧ください。

Apigee コンソールを開く

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

• Google Cloud コンソールの [検索] フィールドに「Apigee」と入力し、検索結果で [Apigee API Management] をクリックします。

Apigee コンソールが開き、よく使用される場所へのクイックリンクがランディング ページに表示されます。

• ナビゲーション メニュー（）で、[Apigee] の横にある [固定]（）をクリックします。

Apigee がナビゲーション メニューに固定されます。

タスク 1. Apigee API プロキシを使用して、バックエンド サービスをプロキシする

このタスクでは、バックエンド サービスのファサードとして機能する Apigee API プロキシを作成します。API プロキシはサービス アカウントを使用して、Cloud Run サービスに OpenID Connect ID トークンを提示できるようにします。

simplebank-rest という名前のバックエンド サービスがすでに作成され、Cloud Run にデプロイされています。サービス アカウントもすでに作成されています。

Apigee プロキシを作成する

1. Cloud Shell で次のコマンドを実行して、バックエンド サービスの URL を取得します。

   gcloud run services describe simplebank-rest --platform managed --region {{{project_0.default_region |REGION}}} --format 'value(status.url)'

   API プロキシの作成で使用するため、この URL を保存します。

2. Cloud コンソールで [Apigee] に移動します。

3. 左側のナビゲーション メニューで、[プロキシ開発] > [API プロキシ] を選択します。

4. [+ Create] をクリックし、プロキシ ウィザードを使用して新しいプロキシを作成します。

   バックエンド サービスのリバース プロキシを作成します。この API プロキシは、OpenAPI 仕様を使用して API のスケルトンを作成します。

5. [Proxy template] ボックスの [OpenAPI spec template] で、[Reverse proxy (Most common)] を選択します。

6. OpenAPI ファイルの場合は、ブラウザで URL を開くと、OpenAPI 仕様の YAML ファイルがパソコンにダウンロードされます。

   https://storage.googleapis.com/spls/shared/firestore-simplebank-data/simplebank-backend.yaml

7. [Browse] をクリックし、パソコンから OpenAPI ファイルを選択して [Next] をクリックします。

8. [Proxy details] で次のように指定します。

   プロパティ	値
   Proxy name	bank-v1
   Base path	/bank/v1
   Description	SimpleBank read-only API
   Target（Existing API）	backend URL

   注: Base path には、「/bank-v1」ではなく「/bank/v1」を使用してください。

   ターゲットには、このタスクですでに取得したバックエンド URL を指定する必要があります。ターゲットは、次のようになります。

   https://simplebank-rest-nu7rb74j5a-uw.a.run.app

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

10. その他の設定はデフォルトのままにして、[Create] をクリックします。

11. [Develop] タブをクリックします。

    注: フローがプロキシ エンドポイントに追加されています。それぞれのフローは、OpenAPI 仕様に記載されているいずれかのオペレーションの動詞とパスの条件を指定しています。

OpenID Connect の ID トークンを送信するようにターゲットを変更する

バックエンド サービスは認証アクセスを要求するようにデプロイされるため、有効な OpenID Connect の ID トークンがなければサービスを呼び出すことができません。

HTTPTargetConnection でサービスのバックエンド ターゲットを指定します。

1. プロキシの [Navigator] メニューで、[Target Endpoints] セクションの [PreFlow] をクリックします。

2. 次のコードを探します（URL は異なります）。

   <HTTPTargetConnection> <URL>https://simplebank-rest-zce6j3rjwq-uw.a.run.app</URL> </HTTPTargetConnection> 注: HTTPTargetConnection セクションが見つからない場合は、[Proxy Endpoints] セクションではなく [Target Endpoints] セクションの [PreFlow] をクリックしているか確認してください。

3. URL の下に、次のような Authentication セクションを追加します。

   <Authentication> <GoogleIDToken> <Audience>AUDIENCE</Audience> </GoogleIDToken> </Authentication>

4. AUDIENCE は、HTTPTargetConnection セクションにある URL 値に置き換えます。URL 要素と Audience 要素の独自の URL を除いて、コードは次のようになります。

   <TargetEndpoint name="default"> <PreFlow name="PreFlow"> <Request/> <Response/> </PreFlow> <Flows/> <PostFlow name="PostFlow"> <Request/> <Response/> </PostFlow> <HTTPTargetConnection> <URL>https://simplebank-rest-zce6j3rjwq-uw.a.run.app</URL> <Authentication> <GoogleIDToken> <Audience>https://simplebank-rest-zce6j3rjwq-uw.a.run.app</Audience> </GoogleIDToken> </Authentication> </HTTPTargetConnection> </TargetEndpoint>

5. [Save] をクリックします。

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

タスク 2. API プロキシに OAuth を追加する

このタスクでは、OAuthV2 ポリシーを API プロキシに追加します。VerifyJWTAccessToken オペレーションを使用する OAuthV2 ポリシーは、実行時にアクセス トークンの検証を強制的に適用して、有効な OAuth アクセス トークンを持つアプリケーションのみが API にアクセスできるようにします。

OAuthV2 ポリシーでは、opaque トークンと JSON ウェブトークン（JWT）の両方を作成して検証できます。この API プロキシは、アクセス トークンに JWT を使用します。

プロパティ セットは、JWT の作成と検証で使用される署名シークレットの保存に使用されます。

プロパティ セットで署名シークレットを作成する

JWT の署名には、ハッシュベースのメッセージ認証コード（HMAC）が使用されます。この種の暗号署名にはシークレットが必要です。

1. プロキシの [Navigator] メニューで、[Resources] の横にある [+] をクリックします。

2. [Resource Type] のプルダウンで [Property Set] を選択します。

3. [Resource Name] に「oauth.properties」と指定し、[Add] をクリックします。

4. [oauth.properties] コードペインで、次のプロパティを追加します。

   secret=thisisnotagoodsecret,useabettersecretinproduction

   フロー変数 propertyset.oauth.secret を使用して、コード内でこの値にアクセスできます。

   注: プロパティ セット値は平文で保存されます。本番環境では暗号化された場所に HMAC シークレットを保存し、より安全な（ランダムな）シークレットを使用してください。

AssignMessage ポリシーを追加して、プロパティ セット値を取得する

署名シークレットはプライベート変数で OAuth ポリシーに提供する必要がありますが、propertyset.oauth.secret 変数はプライベートではありません。この AssignMessage ポリシーは、プロパティ セット変数からプライベート変数を作成します。

1. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [default] の下にある [PreFlow] をクリックします。

   デフォルトのプロキシ エンドポイントの request PreFlow は、API プロキシにリクエストが届いたときに実行される最初のフローです。

   OAuthV2 ポリシーはシークレットを必要とし、API プロキシで非常に早い段階で実行されます。

2. [Flow] ペインで、リクエスト フローの [PreFlow] のすぐ横にある [+] ボタンをクリックします。

3. [Create new Policy] を選択し、[Select policy] プルダウンで [Mediation] セクションの [Assign Message] を選択してから、[Display Name] と [Name] を「AM-GetSecret」に設定します。

4. [Add] をクリックします。ナビゲーション メニューの [Policies] で [AM-GetSecret] をクリックします。

   AssignMessage ポリシー構成が [Code] ペインに表示されます。

5. ポリシー構成を次のように変更します。

   <AssignMessage name="AM-GetSecret"> <AssignVariable> <Name>private.secretkey</Name> <Ref>propertyset.oauth.secret</Ref> </AssignVariable> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> </AssignMessage>

   AssignVariable の設定により、propertyset.oauth.secret 変数が private.secretkey 変数にコピーされます。

   propertyset.oauth.secret が解決できない場合は、IgnoreUnresolvedVariables の設定により AssignMessage ポリシーからエラーが生成されます。

OAuthV2 ポリシーを追加してトークンを検証する

1. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [default] の下にある [PreFlow] をクリックします。

   OAuthV2 ポリシーは AssignMessage ポリシーの後に実行する必要があります。

2. [Flow] ペインで、リクエスト フローの [PreFlow] のすぐ横にある [+] ボタンをクリックします。

3. [Create new policy] を選択し、[Select policy] プルダウンで [Security] セクションの [OAuth v2.0] を選択してから、[Display Name] と [Name] を「OA-VerifyToken」に設定します。

4. [Add] をクリックし、[Navigator] メニューの [Policies] で [OA-VerifyToken] をクリックします。

   OAuthV2 ポリシー構成が [Code] ペインに表示されます。

5. OAuthV2 ポリシー構成を次のように変更します。

   <OAuthV2 name="OA-VerifyToken"> <Operation>VerifyJWTAccessToken</Operation> <Algorithm>HS256</Algorithm> <SecretKey> <Value ref="private.secretkey"/> </SecretKey> </OAuthV2>

   この構成は、JWT アクセス トークンが HS256（HMAC-SHA256）アルゴリズムを使用し、AssignMessage ポリシーで作成されたプライベート変数をシークレット キーとして使用するよう指定しています。

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

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 ポリシーを追加してトークンを検証する

タスク 3. トークンを生成するためのポリシーを追加する

ここでは、JWT トークンの作成を許可するために、個別のプロキシ エンドポイントを API プロキシに追加します。

トークン オペレーション用に新しいプロキシ エンドポイントを追加する

通常、本番環境ではトークンを生成するために別個のプロキシが作成されます。このラボでは、同じ API プロキシ内の別のプロキシ エンドポイントにトークン生成フローを作成します。

1. プロキシの [Navigator] メニューで、[Proxy Endpoints] 行の [+] ボタンをクリックします。

   注: [default] の横にある [+] ボタンはクリックしないでください。

   新しい JWT の作成時に使用される新しいプロキシ エンドポイントが作成されます。

2. [Name] に「token」と指定し、[Add] をクリックします。

   [token] という名前の新しいプロキシ エンドポイントが [Code] ペインに表示されます。

3. token フローの構成全体を変更します。元の構成は次のようになっています。

   <ProxyEndpoint name="token"> . . . </ProxyEndpoint>

   これを、次のように変更します。

   <ProxyEndpoint name="token"> <PreFlow name="PreFlow"> <Request/> <Response/> </PreFlow> <PostFlow name="PostFlow"> <Request/> <Response/> </PostFlow> <Flows/> <HTTPProxyConnection> <BasePath>/token</BasePath> </HTTPProxyConnection> <RouteRule name="noTarget"/> </ProxyEndpoint>

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

   更新されたこの構成により、次の 2 つの変更が行われます。

   • BasePath が /token に設定されます。これが、トークンの作成時に使用されるベースパスです。
   • RouteRule がターゲット エンドポイントを参照しなくなります。API プロキシは、バックエンド サービスを呼び出さずにトークンを作成します。

トークンの生成フローを作成する

1. プロキシのフローで、[Proxy Endpoints: token] セクションの [/token] のすぐ横にある [+] をクリックします。

2. 新しい条件フローに次の値を指定します。

   プロパティ	値
   Flow Name	generateToken
   Condition Type	Custom を選択

3. [Condition] で次の値を指定します。

   (proxy.pathsuffix MatchesPath "/") and (request.verb = "POST") and (request.formparam.grant_type = "client_credentials")

   有効なクライアント認証情報トークン リクエストのみが許可されます。

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

AssignMessage ポリシーをアタッチして、プロパティ セット値を取得する

トークンを生成する OAuthV2 ポリシーは、private.secretkey 変数へのアクセスも必要とします。

1. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [token] の下にある [generateToken] をクリックします。

2. [Flow] ペインで、リクエスト フローの [generateToken] のすぐ横にある [+] ボタンをクリックします。

3. [Select Policy] で [Select Existing policy] を選択し、[AM-GetSecret] をクリックします。

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

   同じ AssignMessage ポリシーがトークン プロキシ エンドポイント PreFlow にアタッチされます。

トークンを生成するための OAuthV2 ポリシーを追加する

1. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [token] の下にある [generateToken] をクリックします。

2. [Flow] ペインで、リクエスト フローの [generateToken] のすぐ横にある [+] ボタンをクリックします。

3. [Select Policy] で [Create new policy] を選択し、[Security] セクションで [OAuth v2.0] を選択してから、[Display Name] と [Name] を「OA-GenerateToken」に設定します。

4. [Add] をクリックし、[Policies] で [OA-GenerateToken] をクリックします。

   OAuthV2 ポリシー構成が [Code] ペインに表示されます。

5. OAuthV2 ポリシー構成を次のように変更します。

   <OAuthV2 name="OA-GenerateToken"> <Operation>GenerateJWTAccessToken</Operation> <Algorithm>HS256</Algorithm> <SecretKey> <Value ref="private.secretkey"/> </SecretKey> <SupportedGrantTypes> <!-- pass client_id and client_secret via basic auth header --> <GrantType>client_credentials</GrantType> </SupportedGrantTypes> <!-- 1800000 ms = 1800 s = 30 min --> <ExpiresIn>1800000</ExpiresIn> <GenerateResponse enabled="true"/> <RFCCompliantRequestResponse>true</RFCCompliantRequestResponse> </OAuthV2>

   この構成によって、30 分間で有効期限が切れる JWT OAuth トークンを作成できるようになります。

無効なトークン リクエストに対してエラーを生成する

1. プロキシのフローで、[Proxy Endpoints: token] セクションの [/token] のすぐ横にある [+] をクリックします。

2. 新しい条件フローに次の値を指定します。

   プロパティ	値
   Flow Name	invalidRequest
   Condition Type	Custom を選択
   Condition	DELETETHIS

   無効な generateToken リクエストはすべてこのフローを通過する必要があるため、フローが追加されると条件が削除されます。

3. [Add] をクリックします。

4. invalidRequest フローで、次の行を削除します。

   <Condition>DELETETHIS</Condition>

5. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [token] の下にある [invalidRequest] をクリックします。

6. [Flow] ペインで、リクエスト フローの [invalidRequest] のすぐ横にある [+] ボタンをクリックします。

7. [Create new policy] を選択し、[Mediation] セクションで [Raise Fault] を選択してから、[Display Name] と [Name] を「RF-InvalidTokenRequest」に設定します。

8. [Add] をクリックし、[Policies] で [RF-InvalidTokenRequest] をクリックします。

   RaiseFault ポリシー構成が [Code] ペインに表示されます。

9. RaiseFault ポリシー構成を次のように変更します。

   <RaiseFault name="RF-InvalidTokenRequest"> <FaultResponse> <Set> <StatusCode>400</StatusCode> <ReasonPhrase>Bad Request</ReasonPhrase> <Payload contentType="application/json">{ "error":"Bad request: use POST /token" }</Payload> </Set> </FaultResponse> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </RaiseFault>

   この変更により、リクエストが無効だった場合に 400 Bad Request レスポンスが返されるようになります。

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

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 トークンを生成するためのポリシーを追加する

タスク 4. OAuth プロキシをデプロイする

このタスクでは、API プロキシをデプロイして、アクセスの際に OAuth トークンが要求されるようにします。

ランタイム インスタンスが使用できることを確認する

1. 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 "***ORG IS READY TO USE***";

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

2. インスタンスの準備が完了するまで待ちます。

   ***ORG IS READY TO USE*** というテキストが表示されたら、インスタンスの準備は完了です。ラボを開始する前に、すでに Apigee 組織が作成されていることがあります。その場合はインスタンスが作成されるまで待つ必要はありません。

   組織の準備が整うまで待つ場合は、その間に OAuth の概要、SpikeArrest ポリシー、データのマスキングと非表示、opaque トークンと JWT についてご確認ください。

API プロキシをデプロイする

1. Cloud コンソールで [Apigee] に移動します。

2. 左側のナビゲーション メニューで、[プロキシ開発] > [API プロキシ] を選択し、[bank-v1] をクリックします。

3. [Develop] タブをクリックします。

4. [Deploy] をクリックし、[Environment] で [eval] を選択します。

   デプロイの確認を求めるダイアログが表示されます。

5. [Service Account] でサービス アカウントのメールアドレスを指定します。

   apigee-internal-access@{{{ project_0.project_id | PROJECT }}}.iam.gserviceaccount.com

6. [Deploy]、[Confirm] の順にクリックします。

7. [Overview] タブをクリックし、プロキシがデプロイされたことが [eval] のデプロイ ステータスに示されるまで待ちます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 API プロキシをデプロイする

API プロキシをテストする

Apigee 組織の eval 環境は、eval.example.com というホスト名を使用して呼び出すことができます。このホスト名の DNS エントリはプロジェクト内に作成されており、Apigee ランタイム インスタンスの IP アドレスに解決します。この DNS エントリは限定公開ゾーンに作成されているため、内部ネットワークのみで表示されます。

Cloud Shell は内部ネットワークに存在しないため、Cloud Shell コマンドではこの DNS エントリを解決できません。組織内の仮想マシン（VM）は限定公開ゾーンの DNS にアクセス可能で、apigeex-test-vm という名前の 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. Cloud Shell で確認されるすべての項目について、Enter キー（リターンキー）を押してデフォルトの入力を指定します。

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

   これで、Cloud Shell セッションが VM 内で実行されます。

3. eval 環境で、デプロイした bank-v1 API プロキシを呼び出します。

   curl -i -k -X GET "https://eval.example.com/bank/v1/customers"

   -k オプションを指定すると、curl は TLS 証明書の検証をスキップします。このラボの Apigee ランタイムでは、信頼できる認証局（CA）によって作成された証明書ではなく、自己署名証明書を使用します。

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

   この API は、顧客リストの取得を試みます。次のような 401 Unauthorized レスポンスが表示されます。

   HTTP/2 401 content-type: application/json www-authenticate: Bearer realm="null",error="invalid_token",error_description="oauth.v2.InvalidAccessToken: Invalid access token" x-request-id: 99263881-d0f7-4495-b886-0253f28a2e05 content-length: 101 date: Tue, 11 Jan 2022 18:59:01 GMT via: 1.1 google {"fault":{"faultstring":"Invalid access token","detail":{"errorcode":"oauth.v2.InvalidAccessToken"}}}

   このレスポンスは、アクセス トークンが提供されなかったために、バックエンド サービスへのアクセスが API プロキシによってブロックされたことを示しています。

4. コマンド exit を入力して SSH セッションを終了し、Cloud Shell に戻ります。

タスク 5. API プロダクト、デベロッパー、アプリケーションを追加する

このタスクでは、API へのアクセスを提供する API プロダクトを追加します。また、デベロッパーを作成してから、API プロダクトに関連付けるアプリケーションも作成します。

API プロダクトを作成する

1. Cloud コンソールで [Apigee] に移動します。

2. ナビゲーション メニューで、[配布] > [API プロダクト] を選択します。

3. [+Create] をクリックして、新しい API プロダクトを作成します。

4. [Product details] ペインで、以下を指定します。

   プロパティ	値
   Name	bank-readonly
   Display Name	bank (read access)
   Environment	eval を選択
   Access	Public を選択

   [Automatically approve access requests] は選択したままにします。

5. [Operations] セクションで、[+Add an Operation] をクリックします。

   オペレーションは、API プロダクトに関連付けられているアプリケーションに対してどの API プロキシのどのリクエストを許可するかを指定するために使用されます。

   注: ボタンが [GraphQL Operations] セクションではなく [Operations] セクションにあることを確認します。

6. 以下を指定します。

   プロパティ	値
   API Proxy	bank-v1 API プロキシを選択
   Path	/**
   Methods	GET を選択

   パス式 /\*\* は、ベースパスに一致するすべてのリクエストが許可されることを示します。

   本番環境では、このワイルドカード パス式を使用せずに、許可する各オペレーションを個別に追加することもできます。

7. [Save] をクリックして、オペレーションを保存します。

8. [Products Detail] ページの上部で [Save] をクリックし、API プロダクトを保存します。

9. [配布] > [API プロダクト] ページに戻ります。

   API プロダクトがリストに表示されます。

アプリ デベロッパーを作成する

アプリを作成する前に、アプリ デベロッパーを作成する必要があります。

1. 左側のナビゲーション メニューで [配布] > [デベロッパー] をクリックします。

2. [+Create] をクリックして新しいアプリ デベロッパーを作成します。

3. 以下を指定します。

   プロパティ	値
   First Name	Joe
   Last Name	Developer
   Username	joe
   Email	joe@example.com

4. [Add] をクリックするとアプリ デベロッパーが作成されます。

bank-v1 アクセス権を持つアプリを作成する

1. 左側のナビゲーション メニューで [配布] > [アプリ] をクリックします。

2. [+Create] をクリックして新しいアプリを作成します。

3. [App details] ペインで、以下を指定します。

   プロパティ	値
   Name	readonly-app
   Developer	joe@example.com を選択

4. [Credentials] ペインで、[Add credentials > Add products] をクリックし、プルダウンで [bank (read access)] を選択してから、[Add] をクリックして追加します。

5. 右上の [Create] をクリックしてアプリを作成します。

   これで、アプリのキーとシークレットが構成されました。

6. [Key] と [Secret] の横にある 表示 アイコンをクリックします。

   この API には OAuth アクセス トークンが必要です。キーとシークレットは、アプリに OAuth アクセス トークンの作成を許可する、アプリの認証情報として使用されます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 API プロダクトを追加してアプリを作成する

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

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

   これで、Cloud Shell セッションが VM 内で実行されます。

2. 次のコマンドを実行して、アプリケーションのコンシューマ キーとシークレットを取得します。

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null); echo "PROJECT_ID=${PROJECT_ID}" export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output); echo "CONSUMER_KEY=${CONSUMER_KEY}" export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output); echo "CONSUMER_SECRET=${CONSUMER_SECRET}"

   最初のコマンドは、gcloud 構成を読み取って現在のプロジェクトを取得します。2 番目と 3 番目のコマンドは、Apigee API を使用してコンシューマ キーとシークレットを取得します。ログインしているユーザーのアクセス許可を持つアクセス トークンを送信するため、リクエストは承認されます。

   OAuth クライアント認証情報の権限付与タイプの場合は、アクセス トークンが生成されるように、クライアント アプリケーションが Authorization ヘッダーでコンシューマ キーとシークレットを送信する必要があります。

3. 次のコマンドを実行して JWT アクセス トークンを生成します。

   export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials"); echo ${TOKEN_RESPONSE} export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output); echo "JWT_TOKEN=${JWT_TOKEN}"

   最初のコマンドは、トークン エンドポイントを呼び出してレスポンスを保存します。トークンは、JSON レスポンスから抽出されて JWT_TOKEN に保存されます。

4. 次のコマンドを実行し、JWT トークンを使用してリクエストをテストします。

   curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/customers"

   API 呼び出しから顧客のリストが返されます。

   注: 「Your client does not have permission to the requested URL」というレスポンスを受け取った場合は、タスク 1 で Audience を正しく設定しているか確認してください。

5. コマンド exit を入力して SSH セッションを終了し、Cloud Shell に戻ります。

タスク 6. レート制限を追加する

このタスクでは、API プロダクトの割り当て構成を使用する SpikeArrest ポリシーを追加して、API への呼び出しのレートを制限します。

SpikeArrest ポリシーでは、許可される最大トラフィック レートを指定して、API とバックエンドをトラフィックの急増から保護できます。処理しきれないほど大量のトラフィックがバックエンドに到達するのを防ぐことができます。

トークン生成のために SpikeArrest ポリシーを追加する

この SpikeArrest ポリシーでは、/token API への呼び出しのトラフィックに対する全般的なレート制限を指定します。

1. Cloud コンソールで [Apigee] に移動します。

2. 左側のナビゲーション メニューで、[プロキシ開発] > [API プロキシ] を選択し、[bank-v1] をクリックします。

3. [Develop] タブをクリックします。

4. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [token] の下にある [PreFlow] をクリックします。

   SpikeArrest ポリシーは、条件フローポリシーの前に実行される必要があります。

5. [Flow] ペインで、リクエスト フローの [PreFlow] のすぐ横にある [+] ボタンをクリックします。

6. [Create new policy] を選択し、[Traffic Management] セクションで [Spike Arrest] を選択してから、[Display Name] と [Name] を「SA-LimitTokenRate」に設定します。

7. [Add] をクリックし、[Policies] セクションの [SA-LimitTokenRate] をクリックします。

   SpikeArrest ポリシー構成が [Code] ペインに表示されます。

8. SpikeArrest ポリシー構成を次のように変更します。

   <SpikeArrest name="SA-LimitTokenRate"> <Rate>5pm</Rate> <UseEffectiveCount>false</UseEffectiveCount> </SpikeArrest>

   この構成では、許可されるリクエストの最大レートが 1 分あたり 5 件に指定されています。SpikeArrest ポリシーのこの制限は、すべてのトラフィックに適用されます。

   注: 1 分あたり 5 件のリクエストという制限は、テストを円滑に進めるためのものです。このラボで使用している SpikeArrest の制限は、一般的に現実のシナリオでは低すぎます。

   false に設定された UseEffectiveCount は、SpikeArrest ポリシーでトークン バケット アルゴリズムを使用するように指定します。トラフィックは、レートをより短い間隔に分割することで平滑化されます。1 分あたり 5 件のリクエストとは、1/5 分あたり 1 件のリクエスト、つまり 12 秒ごとに 1 件のリクエストになります。2 番目のリクエストが前のリクエストから 12 秒経過しないうちに Message Processor に到達した場合は、そのリクエストが拒否されることがあります。

API リクエストのために SpikeArrest ポリシーを追加する

この SpikeArrest ポリシーは、/bank/v1 API への呼び出しのトラフィックに対するレート制限を指定します。このレートはアプリケーションごとに適用されます。

1. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [default] の下にある [PreFlow] をクリックします。

   SpikeArrest ポリシーは呼び出しの早い段階で実行されますが、アプリケーションに応じてレートを制限するために、OAuthV2 VerifyJWTAccessToken ポリシーより後に実行される必要があります。

2. [Flow] ペインで、リクエスト フローの [PreFlow] のすぐ横にある [+] ボタンをクリックします。

3. [Create new policy] を選択し、[Traffic Management] セクションで [Spike Arrest] を選択してから、[Display Name] と [Name] を「SA-LimitRateByApp」に設定します。

4. [Add] をクリックし、[Policies] セクションの [SA-LimitRateByApp] をクリックします。

   SpikeArrest ポリシー構成が [Code] ペインに表示されます。

5. SpikeArrest ポリシー構成を次のように変更します。

   <SpikeArrest name="SA-LimitRateByApp"> <Rate>5pm</Rate> <Identifier ref="client_id" /> <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>

   この構成では前のポリシーと同様に、リクエストで許可される最大レートが 1 分あたり 5 件に指定されています。ただし、このポリシーでは Identifier が指定されているため、SpikeArrest のレートは client_id ごとに個別に維持されます。クライアント ID は OA-VerifyToken ポリシーによって設定されますが、これはデベロッパー アプリケーションごとに一意です。

   UseEffectiveCount が true に設定されているため、リージョン内のすべてのトラフィックでレート数が維持されます。このポリシーは、期間ごとに受け取ったリクエストのカウンタを維持します。1 分あたりのリクエスト数というレートを使用している場合、期間は 1 分です。レートの計算は、スライディング ウィンドウに基づきます。

   

   上記の例で、1 分あたり 50 件のリクエストというレートを使用しているとします。カウンタは 1 分の期間を使用します。ただし、レートが 1 秒あたりで指定されている場合は、カウンタ期間が 1 秒になります。矢印で示されているように、現時点でこの 1 分の期間のうち 10 秒が経過しているとします。前の 1 分間では 48 件のリクエストがあり、現在の期間ではこれまでに 5 件のリクエストがありました。

   新しいリクエストを許可するには、1 分あたり 50 件未満のリクエストである必要があります。計算されたレートは次のようになります。

   request_rate = (48 × (60-10)/60) + 6 = 46

   現在の期間では 60 秒のうち 10 秒しか経過していないため、残りの 50 秒については前の期間のレートを使用して計算されます。48 の 5/6 は 40 です。リクエストが許可されたとすると、現在の期間のカウントは 5 + 1、つまり 6 になります。リクエスト レートの計算結果は 46 となり、1 分あたり 50 件未満のため、リクエストが許可されることがわかります。

6. [Save] > [Save as new revision] を選択します。

7. [Deploy] をクリックし、[Environment] で [eval] を選択します。

8. [Service Account] でサービス アカウントのメールアドレスを指定します。

apigee-internal-access@{{{ project_0.project_id | PROJECT }}}.iam.gserviceaccount.com

9. [Deploy]、[Confirm] の順にクリックします。
10. [Overview] タブをクリックし、プロキシがデプロイされたことが [eval] のデプロイ ステータスに示されるまで待ちます。

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

レート制限をテストする

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

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

   これで、Cloud Shell セッションが VM 内で実行されます。

2. 次のコマンドを実行して、アプリケーションのコンシューマ キーとシークレットを取得します。

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null); echo "PROJECT_ID=${PROJECT_ID}" export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output); echo "CONSUMER_KEY=${CONSUMER_KEY}" export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output); echo "CONSUMER_SECRET=${CONSUMER_SECRET}"

3. 次のコマンドを繰り返し実行して、複数のアクセス トークンを生成します。

   curl -i -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials"

   すぐに、レートを超過したことを示す 429 Too Many Requests レスポンスが表示されます。このポリシーでは UseEffectiveCount が false なので、トークン バケット アルゴリズムを使用してトラフィックが平滑化されます。ここでは、5 番目のリクエストの前に Spike Arrest の違反が発生すると考えられます。

4. 次のコマンドを実行して、JWT アクセス トークンを保存します。

   export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials"); echo ${TOKEN_RESPONSE} export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output); echo "JWT_TOKEN=${JWT_TOKEN}"

5. 次のコマンドを繰り返し送信して、API 呼び出しに対して SpikeArrest ポリシーをテストします。

   curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/customers"

   UseEffectiveCount が true なので、このポリシーではスライディング ウィンドウ アルゴリズムが使用されます。リクエストがブロックされるまでに、5 件のリクエストを行えるはずです。

6. コマンド exit を入力して SSH セッションを終了し、Cloud Shell に戻ります。

タスク 7. データ マスクを作成する

このタスクでは、データマスクを作成して、デバッグ セッションで特定の項目を非表示にします。

デバッグ セッションを開始する

Debug は、Apigee で動作する API プロキシのトラブルシューティングとモニタリングを行うためのツールです。このツールを使用すると、API 呼び出しの各ステップの詳細を調べることができます。

1. 左側のナビゲーション メニューで、[プロキシ開発] > [API プロキシ] を選択し、[bank-v1] をクリックします。

2. [Debug] タブをクリックします。

3. [Start debug session] ペインで [Start debug session] をクリックし、環境のプルダウンで [eval] を選択します。

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

   デバッグ セッションでリクエストのキャプチャが開始されるまでに、少し時間がかかる場合があります。

   注: 画面の上部に赤い枠線で囲まれた「Error fetching debug transactions」や「List debug session transaction error」といったエラー メッセージが表示された場合でも、デバッグ セッションは正しく動作していることがあります。

   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

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

   これで、Cloud Shell セッションが VM 内で実行されます。

2. 次のコマンドを実行し、アプリケーションのトークンを取得します。

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null); echo "PROJECT_ID=${PROJECT_ID}" export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output); echo "CONSUMER_KEY=${CONSUMER_KEY}" export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output); echo "CONSUMER_SECRET=${CONSUMER_SECRET}" export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials"); echo ${TOKEN_RESPONSE} export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output); echo "JWT_TOKEN=${JWT_TOKEN}"

3. API に次のリクエストを送信します。

   curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/customers/abe@example.org/accounts"

4. [Apigee] ページに戻ります。

   [Debug] ページに POST（トークンの生成）と GET（ユーザーのアカウントの取得）の 2 つのリクエストが表示されているはずです。

5. GET リクエストをクリックします。

   GET リクエストの詳細が表示されます。

6. 最初のポリシーをクリックします。これは、propertyset.oauth.secret 変数を private.secretkey 変数にコピーする AM-GetSecret ポリシーです。

   

   デバッグ セッションでは「private」の接頭辞が付いた変数が非表示になるため、[Phase Details] にはプライベート変数が表示されません。ただし、プロパティ セット変数にも同じ機密データが格納されるため、トラフィックをデバッグするユーザーに対してプロパティ セット変数を非表示にすることをおすすめします。

7. バックエンドからのレスポンスをクリックします。これは、工場アイコンの左側にある円で示されています。

   

   レスポンスには、アカウント残高を含むユーザーのアカウント情報が含まれています。

デバッグマスクを作成する

1. 同じブラウザ ウィンドウで新しいタブを開き、Apigee API リファレンスにアクセスします。

   Apigee API リファレンスには、Apigee の管理や Apigee API の呼び出しに使用できるさまざまな API 呼び出しの詳細が記載されています。このページには、organization.environments API 呼び出しが示されています。

2. ページの下部までスクロールして、[updateDebugmask] をクリックします。

   この API 呼び出しは、環境のデバッグマスクを更新します。

3. [Try this API] ペインの name リクエスト パラメータに次の値を使用します。

   organizations/{{{ project_0.project_id | PROJECT }}}/environments/eval/debugmask

4. リクエスト本文に次の値を入力します。

   { "responseJSONPaths": [ "$[*].balance" ], "variables": [ "propertyset.oauth.secret" ] }

   このペイロードによって propertyset.oauth.secret 変数がマスクされ、さらにレスポンス ペイロードの一連のオブジェクトの各 balance フィールドもマスクされます。

5. [Execute] をクリックします。

   アカウントの選択を求めるポップアップ ボックスが表示されたら、受講者アカウントを選択します。

6. [Allow] をクリックして、ページでの受講者認証情報の使用を許可します。

デバッグマスクをテストする

1. [Apigee] の左側のナビゲーション メニューで [プロキシ開発] > [API プロキシ] を選択し、[bank-v1] をクリックします。

2. [Debug] タブをクリックします。

3. [Start debug session] ペインで、環境のプルダウンから [eval] を選択します。

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

5. Cloud Shell で SSH 接続が閉じている場合は、テスト 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

6. トークンを取得して、再度 API リクエストを送信します。

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null) export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output) export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output) export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials") export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output) curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/customers/abe@example.org/accounts"

7. [Apigee] の [Debug] ページに戻り、GET リクエストをクリックします。

8. AM-GetSecret ポリシーをクリックします。

   propertyset.oauth.secret 変数がマスクされます。

   

9. バックエンド レスポンスの [Proxy Response Flow Started] をクリックします。

   balance フィールドがすべてマスクされています。

   

タスク 8. エラー処理を追加する

このタスクでは、特定のバックエンド リソースに対する呼び出しを制限するためのデフォルトの条件フローを作成し、バックエンド エラー メッセージを書き換えます。

API をテストする

1. Cloud Shell で SSH 接続が閉じている場合は、テスト 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. 「Y」と入力して続行し、Enter キーを 2 回押してパスフレーズを空白のままにします。

3. トークンを取得して、/users に GET リクエストを送信します。

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null) export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output) export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output) export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials") export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output) curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/users"

   バックエンド サービスは GET /users リクエストを認識しないため、次のような 404 レスポンスが返されます。

   HTTP/2 404 x-powered-by: Express content-security-policy: default-src 'none' x-content-type-options: nosniff content-type: text/html; charset=utf-8 x-cloud-trace-context: 7e96528757cc5053ba4fc8853037b02d;o=1 date: Wed, 19 Jan 2022 01:49:53 GMT server: Google Frontend content-length: 144 x-request-id: 2d8c8002-3152-4fc2-a60b-1729dd5483d8 via: 1.1 google <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>Error</title> </head> <body> <pre>Cannot GET /users</pre> </body> </html>

   レスポンスから HTML ペイロードが返されますが、これは RF-InvalidTokenRequest ペイロードの形式と一致していません。また、バックエンド レスポンスには機密データが含まれている可能性があります。そのため、バックエンド サービスからのエラー レスポンスを書き換えることがベスト プラクティスとなります。

404 Not Found エラーを書き換える

障害ルールを使用してエラーを検出し、エラー メッセージを書き換えることができます。

RaiseFault ポリシーを使用して、新しいレスポンスを設定します。

1. Cloud コンソールで [Apigee] に移動します。

2. 左側のナビゲーション メニューで、[プロキシ開発] > [API プロキシ] を選択し、[bank-v1] をクリックします。

3. [Develop] タブをクリックします。

4. プロキシの [Navigator] メニューで、[Policies] の横にある [+] をクリックします。

5. [Mediation] セクションで [Raise Fault] を選択してから、[Display Name] と [Name] を「RF-404NotFound」に設定します。

6. [Create] をクリックします。[Policies] セクションで [RF-404NotFound] をクリックします。

7. RaiseFault ポリシー構成を次のように変更します。

   <RaiseFault name="RF-404NotFound"> <FaultResponse> <Remove> <Headers/> </Remove> <Set> <StatusCode>404</StatusCode> <ReasonPhrase>Not Found</ReasonPhrase> <Headers> <Header name="FaultName">{fault.name}</Header> </Headers> <Payload contentType="application/json">{ "error": "{request.verb} {proxy.pathsuffix} not found" }</Payload> </Set> </FaultResponse> <AssignTo createNew="true" type="response"/> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </RaiseFault>

   まず、Remove セクションによって、バックエンド サービスから取得された可能性のあるヘッダーがすべて削除され、次に Set セクションによってレスポンスが作成されます。エラーが発生した際に fault.name 変数の値が表示されるよう、FaultName ヘッダーが追加されています。fault.name 変数はエラーの名前を指定します。

FaultRule を作成する

1. プロキシの [Navigator] メニューで、[Target Endpoints] セクションの [default] をクリックします。

   デフォルトのターゲット エンドポイントには、404 レスポンスを返すバックエンド ターゲット呼び出しが含まれています。404 はエラーコードとして扱われます。エンドポイントからエラーが返されると、ターゲット エンドポイントに指定された FaultRule を使用して API レスポンスを書き換えることができます。

2. TargetEndpoint 構成の TargetEndpoint タグの直下に、次の FaultRules セクションを追加します。

   <FaultRules> <FaultRule name="404"> <Step> <Name>RF-404NotFound</Name> </Step> <Condition>response.status.code == 404</Condition> </FaultRule> </FaultRules>

   TargetEndpoint の先頭は次のようになります。

   <TargetEndpoint name="default"> <FaultRules> <FaultRule name="404"> <Step> <Name>RF-404NotFound</Name> </Step> <Condition>response.status.code == 404</Condition> </FaultRule> </FaultRules>

3. [Save] > [Save as new revision] を選択します。

4. [Deploy] をクリックし、[Environment] で [eval] を選択します。

5. [Service Account] でサービス アカウントのメールアドレスを指定します。

   apigee-internal-access@{{{ project_0.project_id | PROJECT }}}.iam.gserviceaccount.com

6. [Deploy]、[Confirm] の順にクリックします。

7. [Overview] タブをクリックし、プロキシがデプロイされたことが [eval] のデプロイ ステータスに示されるまで待ちます。

エンドポイント レスポンスのエラーをテストする

1. Cloud Shell で SSH 接続が閉じている場合は、テスト 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. トークンを取得して、/users に GET リクエストを送信します。

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null) export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output) export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output) export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials") export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output) curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/users"

   レスポンスが書き換えられて次のようになります。

   HTTP/2 404 faultname: ErrorResponseCode content-type: application/json x-request-id: 8d9db301-b3c7-4957-816d-93e796306dfb content-length: 39 date: Tue, 18 Jan 2022 06:42:23 GMT via: 1.1 google { "error": "GET /users not found" }

   レスポンスで JSON が使用されるようになっています。faultname ヘッダーの値が ErrorResponseCode であることに注目してください。これは、ターゲットからエラーコードが返されたときに指定される fault.name 変数の値です。バックエンド サービスから 404 レスポンスが返されるとすぐにエラーが生成されます。ターゲット エンドポイントの障害ルールが評価され、404 障害ルールによってレスポンスが書き換えられています。

404 条件フローを追加する

予期しないリクエストが送信された際に、バックエンドからレスポンスが返されるのを待つ代わりに、プロキシ エンドポイントの条件フローの最後に新しい条件フローを追加して、他の条件フローの条件がいずれも満たされなかった場合にエラーが生成されるようにすることができます。こうすることで、条件フローにリストされているオペレーションのみがバックエンドに渡されるようになります。このパターンを利用して、特定のバックエンド サービス リソースのみにアクセスを許可できます。

1. プロキシの [Navigator] メニューで [Proxy Endpoint: default] に移動し、[Flow] セクションで [/bank/v1] の横にある [+] をクリックします。

2. 新しい条件フローに次の値を指定します。

   プロパティ	値
   Flow name	404NotFound
   Condition type	Custom を選択
   Condition	DELETETHIS

3. [Add] をクリックします。

4. 404NotFound フローで、次の行を削除します。

   <Condition>DELETETHIS</Condition>

   前の条件フローの条件がいずれも満たされない場合、404NotFound フローが実行されます。

5. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [default] の下にある [404NotFound] をクリックします。

6. [Flow] ペインで、[404NotFound] リクエスト フローのすぐ横にある [+] ボタンをクリックします。

7. [Select Policy] で [Select existing policy] を選択し、[RF-404NotFound] をクリックします。

8. [Add] をクリックします。

9. [Save] > [Save as new revision] を選択します。

10. [Deploy] をクリックし、[Environment] で [eval] を選択します。

11. [Service Account] でサービス アカウントのメールアドレスを指定します。

    apigee-internal-access@{{{ project_0.project_id | PROJECT }}}.iam.gserviceaccount.com

12. [Deploy]、[Confirm] の順にクリックします。

13. [Overview] タブをクリックし、プロキシがデプロイされたことが [eval] のデプロイ ステータスに示されるまで待ちます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 エラー処理を追加する

404 条件フローをテストする

1. Cloud Shell で SSH 接続が閉じている場合は、テスト 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. トークンを取得して、/users に GET リクエストを送信します。

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)' 2>/dev/null) export CONSUMER_KEY=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerKey" --raw-output) export CONSUMER_SECRET=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/developers/joe@example.com/apps/readonly-app" | jq ".credentials[0].consumerSecret" --raw-output) export TOKEN_RESPONSE=$(curl -k -u "${CONSUMER_KEY}:${CONSUMER_SECRET}" -X POST "https://eval.example.com/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=client_credentials") export JWT_TOKEN=$(echo ${TOKEN_RESPONSE} | jq ".access_token" --raw-output) curl -i -k -H "Authorization: Bearer ${JWT_TOKEN}" -X GET "https://eval.example.com/bank/v1/users"

   レスポンスが書き換えられて次のようになります。

   HTTP/2 404 faultname: RaiseFault content-type: application/json x-request-id: d6bbd48f-65bd-4551-9236-636fad03a609 content-length: 39 date: Tue, 18 Jan 2022 07:07:58 GMT via: 1.1 google alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 { "error": "GET /users not found" }

   faultname ヘッダーの値が RaiseFault になっています。これは、RaiseFault ポリシーによってエラーが生成されたときに使用される fault.name の値です。これで、404NotFound 条件フローの RaiseFault ポリシーによってレスポンスが生成されました。

お疲れさまでした

このラボでは、JWT OAuth トークンを要求することで API を保護し、SpikeArrest ポリシーを追加してトラフィックを制限しました。また、プライベート変数とデータ マスキングを使用して、デバッグ セッションで機密データを非表示にしました。さらに、バックエンド エラー メッセージを書き換え、404 条件フローを使用してバックエンドへの呼び出しを特定のリソースに限定しました。

次のステップと詳細情報

• OAuth の概要
• SpikeArrest ポリシー
• データのマスキングと非表示
• Opaque トークンと JWT
• 障害の処理

マニュアルの最終更新日: 2025 年 8 月 6 日

ラボの最終テスト日: 2025 年 8 月 6 日

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