arrow_back

Apigee X による API の保護

ログイン 参加
Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

Apigee X による API の保護

Lab 1時間 30分 universal_currency_alt クレジット: 5 show_chart 中級
Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

GSP844

Google Cloud セルフペース ラボ

概要

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

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

目標

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

  • OAuth トークンを要求して API へのアクセスを保護する

  • SpikeArrest ポリシーを使用して、全体的なトラフィック レートとアプリケーション別のレートを制限する

  • プライベート変数とデータ マスキングを使用して、API 呼び出しのデバッグ中に機密データを非表示にする

  • バックエンドへの呼び出しを指定したリソースに制限する

  • データ漏洩を防ぐためにバックエンドのエラー メッセージを書き換える

設定と要件

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

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

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

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

  • 標準的なインターネット ブラウザ（Chrome を推奨）
注: このラボの実行には、シークレット モードまたはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生することを防ぎます。
  • ラボを完了するために十分な時間を確保してください。ラボをいったん開始すると一時停止することはできません。
注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、このラボでは使用しないでください。アカウントへの追加料金が発生する可能性があります。 注: このラボを実施する際には、新しいシークレット ウィンドウを使用することをおすすめします。

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

  1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。

    • [Google コンソールを開く] ボタン
    • 残り時間
    • このラボで使用する必要がある一時的な認証情報
    • このラボを行うために必要なその他の情報（ある場合）

  2. [Google コンソールを開く] をクリックします。 ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

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

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

  3. 必要に応じて、[ラボの詳細] パネルから [ユーザー名] をコピーして [ログイン] ダイアログに貼り付けます。[次へ] をクリックします。

  4. [ラボの詳細] パネルから [パスワード] をコピーして [ようこそ] ダイアログに貼り付けます。[次へ] をクリックします。

    重要: 認証情報は左側のパネルに表示されたものを使用してください。Google Cloud Skills Boost の認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

  5. その後次のように進みます。

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

その後このタブで Cloud Console が開きます。

注: 左上にある [ナビゲーション メニュー] をクリックすると、Google Cloud のプロダクトやサービスのリストが含まれるメニューが表示されます。 ナビゲーション メニュー アイコン

Cloud Shell をアクティブにする

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

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

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

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

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

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

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

  2. 出力は次のようになります。

出力:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`
  1. （省略可）次のコマンドを使用すると、プロジェクト ID を一覧表示できます。
gcloud config list project

出力:

[core] project = <project_ID>

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

Apigee UI を開く

Apigee UI には、Google Cloud コンソールとは別のページからアクセスします。このラボでは、Google Cloud プロジェクトと同じ名前の Apigee 組織が自動的に作成されています。

  • クリックして、Apigee UI を開きます。

    Google Cloud コンソールから Apigee UI を開くこともできます。開くには、ナビゲーション メニュー（ナビゲーション メニュー）を開き、[Apigee API Management] > [Apigee] を選択します。

プロジェクトに組織がプロビジョニングされていないことを示すエラーが表示される場合は、過去のラボの組織をタブが読み込もうとしている可能性があります。

このエラーが表示される場合:

  • 組織プルダウンをクリックします。

    「プロビジョニングされていません」エラー メッセージ

    組織プルダウンには、Google Cloud プロジェクトと同じ名前の組織が表示されているはずです。

    Apigee UI 組織プルダウン

    リストアップされている組織は、ログイン ユーザーがアクセスできる組織です。このラボでは、ラボの開始時に [ラボの詳細] パネルで指定されたラボ認証情報を使用してログインする必要があります。

    Apigee UI を操作するには、左側のナビゲーション メニューを使用します。ランディング ページには、よく使用される場所に移動できるクイックリンクも表示されます。

タスク 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 us-west1 --format 'value(status.url)'

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

  2. ブラウザ ウィンドウで Apigee UI タブを選択します。

  3. 左側のナビゲーション メニューで [Develop] > [API Proxies] を選択します。

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

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

  5. [Reverse proxy] ボックスで、[Use OpenAPI Spec] をクリックします。

  6. [OpenAPI Spec URL] で次のように指定します。

    https://storage.googleapis.com/cloud-training-cors/api-dev-quest/simplebank-backend.yaml 注: OpenAPI 仕様を確認するには、ブラウザで同じ URL を開きます。OpenAPI 仕様 YAML ファイルがご使用のパソコンにダウンロードされます。

  7. [Select] をクリックします。

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

    プロパティ 値
    Name bank-v1
    Base path /bank/v1
    Description SimpleBank read-only API
    Target (Existing API) バックエンド URL
    注: [Base path] には /bank-v1 ではなく /bank/v1 を使用していることを確認してください。

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

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

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

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

    [OpenAPI operations] ページに、バックエンド OpenAPI 仕様に記載されているオペレーションのリストが表示されます。今回は、バックエンド サービスの読み取り専用オペレーションへのアクセスのみを許可する API を作成します。

  11. [OpenAPI operations] ページで、4 つの POST オペレーションと 2 つの PUT オペレーションを選択解除し、[Next] をクリックします。

    GET オペレーションのみを選択したままにします。

  12. [Summary] ページで、設定をデフォルトのままにして [Create] をクリックします。

  13. [Edit proxy] をクリックします。

  14. 右上隅に [Switch to Classic] リンクがある場合は、そのリンクをクリックします。

  15. [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. [File Type] のプルダウンで [Property Set] を選択します。

  3. [File 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] をクリックします。

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

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

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

  3. [Mediation] セクションで、[Assign Message] を選択し、[Display Name] と [Name] を AM-GetSecret に設定します。

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

    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] ペインで、リクエスト フローの右上にある [+Step] ボタンをクリックします。

  3. [Security] セクションで [OAuth v2.0] を選択し、[Display Name] と [Name] を OA-VerifyToken に設定します。

  4. [Add] をクリックして、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. [Proxy Endpoint 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. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [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] ペインで、リクエスト フローの右上にある [+Step] ボタンをクリックします。

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

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

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

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

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

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

  3. [Security] セクションで [OAuth v2.0] を選択し、[Display Name] と [Name] を OA-GenerateToken に設定します。

  4. [Add] をクリックして、OA-GenerateToken アイコンをクリックします。

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

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

    <OAuthV2 name="OA-GenerateToken"> <Operation>GenerateJWTAccessToken</Operation> <Algorithm>HS256</Algorithm> <SecretKey> <Value ref="private.secretkey"/> </SecretKey> <SupportedGrantTypes> <!-- 基本認証ヘッダーを使用して client_id と client_secret を渡す --> <GrantType>client_credentials</GrantType> </SupportedGrantTypes> <!-- 1,800,000 ミリ秒 = 1,800 秒 = 30 分 --> <ExpiresIn>1800000</ExpiresIn> <GenerateResponse enabled="true"/> <RFCCompliantRequestResponse>true</RFCCompliantRequestResponse> </OAuthV2>

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

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

  1. プロキシの [Navigator] メニューで、[Proxy Endpoints] セクションの [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] ペインで、リクエスト フローの右上にある [+Step] ボタンをクリックします。

  7. [Mediation] セクションで、[Raise Fault] を選択し、[Display Name] と [Name] を RF-InvalidTokenRequest に設定します。

  8. [Add] をクリックして、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. ブラウザ ウィンドウで Apigee UI タブを選択します。

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

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

  4. [Deploy to eval] をクリックします。

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

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

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

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

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

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

API プロキシをテストする

Apigee 組織の eval 環境は、eval.example.com というホスト名を使用して呼び出すことができます。このホスト名を Apigee ランタイム インスタンスの IP アドレスに解決する DNS エントリは、すでにプロジェクト内に作成されています。この 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 キーまたは Return キーを押して、デフォルトの入力を指定します。

    プロジェクトのオーナーとしてログインしているため、このマシンへの 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. ブラウザ ウィンドウで Apigee UI タブを選択します。

  2. 左側のナビゲーション メニューで [Publish] > [API Products] を選択します。

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

  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. 以下を指定します。

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

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

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

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

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

  9. [Publish] > [API Products] ページに戻ります。

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

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

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

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

  2. 新しいアプリ デベロッパーを作成するには、[+Developer] をクリックします。

  3. 以下を指定します。

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

  4. [Create] をクリックして、アプリ デベロッパーを作成します。

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

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

  2. 新しいアプリを作成するには、[+App] をクリックします。

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

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

  4. [Credentials] ペインで、[Add product] をクリックし、[bank (read access)] をクリックしてから [Add(1)] をクリックして追加します。

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

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

  6. [Key] と [Secret] の隣にある [Show] リンクをクリックします。

    この 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. ブラウザ ウィンドウで Apigee UI タブを選択します。

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

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

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

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

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

  6. [Traffic Management] セクションで、[Spike Arrest] を選択し、[Display Name] と [Name] を SA-LimitTokenRate に設定します。

  7. [Add] をクリックして SA-LimitTokenRate アイコンをクリックします。

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

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

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

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

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

    UseEffectiveCount が false に設定されているため、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] ペインで、リクエスト フローの右上にある [+Step] ボタンをクリックします。

  3. [Traffic Management] セクションで、[Spike Arrest] を選択し、[Display Name] と [Name] を SA-LimitRateByApp に設定します。

  4. [Add] をクリックして 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 分です。レートの計算は、スライディング ウィンドウに基づきます。

    レートが 48 と 5 のスライディング ウィンドウの例。

    上記の例で、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] をクリックします。プロキシが新しいリビジョンとして保存されたことを知らせるメッセージが表示された場合は、[OK] をクリックします。

  7. [Deploy to eval] をクリックしてから [Deploy] をクリックします。

  8. [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 プロキシのトラブルシューティングとモニタリングを行うためのツールです。Debug ツールを使用すると、API 呼び出しの各ステップの詳細を調べることができます。

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

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

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

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

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

    注: 画面の上部に赤い枠線で囲まれた「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 UI ページに戻ります。

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

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

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

  6. [View Options] で、[Automatically Compare Selected Phase] チェックボックスをオフにします。

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

    AssignMessage アイコンと [Variables Read] の説明がハイライト表示されている Apigee UI ページ。

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

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

    Transaction Map カテゴリ内のハイライト表示されたバックエンドのトグルと、Response Content のハイライト表示された本文テキスト。

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

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

  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 UI の左側のナビゲーション メニューで [Develop] > [API Proxies] を選択し、[bank-v1] をクリックします。

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

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

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

  5. SSH 接続が閉じている場合は、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

  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 UI の [Debug] ページに戻り、GET リクエストをクリックします。

  8. AssignMessage ポリシーをクリックします。

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

    非表示モードの propertyset.oauth.secret 変数。

  9. バックエンド レスポンスの円をクリックします。

    balance 項目がすべてマスクされています。

    本文テキストの非表示の balance 項目。

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

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

API をテストする

  1. SSH 接続が閉じている場合は、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. 「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. ブラウザ ウィンドウで Apigee UI タブを選択します。

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

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

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

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

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

  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] をクリックします。プロキシが新しいリビジョンとして保存されたことを知らせるメッセージが表示された場合は、[OK] をクリックします。

  4. [Deploy to eval] をクリックしてから [Deploy] をクリックします。

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

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

  1. SSH 接続が閉じている場合は、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. トークンを取得して、/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 Endpoints] セクションの [default] の隣にある [+] をクリックします。

  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] ペインで、リクエスト フローの右上にある [+Step] ボタンをクリックします。

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

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

  9. [Save] をクリックします。プロキシが新しいリビジョンとして保存されたことを知らせるメッセージが表示された場合は、[OK] をクリックします。

  10. [Deploy to eval] をクリックしてから [Deploy] をクリックします。

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

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

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

  1. SSH 接続が閉じている場合は、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. トークンを取得して、/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 条件フローを使用して、バックエンドへの呼び出しを特定のリソースに限定しました。

クエストを完了する

このセルフペース ラボは、「Develop and Secure APIs with Apigee X」クエストの一部です。クエストとは学習パスを構成する一連のラボのことで、完了すると成果が認められて上のようなバッジが贈られます。バッジは公開して、オンライン レジュメやソーシャル メディア アカウントにリンクできます。このラボの修了後、こちらのクエストまたはこのラボが含まれるクエストに登録すれば、すぐにクレジットを受け取ることができます。受講可能なすべてのクエストについては、Google Cloud Skills Boost カタログをご覧ください。

次のラボを受講する

シリーズの次のラボ「Apigee X での Google Cloud サービスの使用」に進んでクエストを続けてください。

次のステップと詳細情報

マニュアルの最終更新日: 2023 年 2 月 4 日

ラボの最終テスト日: 2022 年 5 月 26 日

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