Apigee を使用したアプリケーションと API の保護のベスト プラクティス

Last reviewed 2022-09-27 UTC

このドキュメントでは、Apigee API 管理と次の Google Cloud プロダクトを使用してアプリケーションと API を保護するベスト プラクティスについて説明します。

このドキュメントは、アプリケーションのインフラストラクチャの管理や、安全性、スケーラビリティ、パフォーマンスに優れた API の公開をサポートするため、API アーキテクト、セキュリティ アーキテクト、エンジニアリング リードを対象として作成されました。

このドキュメントでは、一連のサンプル アーキテクチャを使用して、Apigee API 管理の使用に関するベスト プラクティスを提示します。さらに、ウェブアプリと API の保護（WAAP）を使用するためのベスト プラクティスについても説明します。WAAP は、アプリケーションや API の保護に役立つ包括的なセキュリティ ソリューションです。

このドキュメントは、ネットワーキング、API、Google Cloud に精通していることを前提としています。

Apigee API 管理

Apigee は API の開発と管理を行うためのプラットフォームです。サービスにプロキシレイヤを追加することで、Apigee は、バックエンド サービス API の保護に役立つ抽象化またはファサードを提供します。

ユーザーは OAuth 2.0 と許可リスト登録済みの IP アドレス範囲を使用してアプリケーションを操作できます。次の図に示すように、ユーザーはアプリケーションを操作でき、データとサービスは双方向のフローで公開されます。

ユーザーによるアプリケーション操作とバックエンド間のセキュリティ ポイント。

セキュリティ ポイントは次のとおりです。

  • ユーザー:
    • OAuth 2.0
    • IP アドレス アクセス制御
  • アプリケーション
    • API キー
    • OAuth 2.0
    • TLS
  • デベロッパーとパートナー
    • SSO
    • RBAC
  • API
    • OAuth 2.0
    • OpenID Connect
    • 割り当て
    • Spike Arrest
    • 脅威からの保護
  • API チーム
    • IAM RBAC
    • 連携ロジック
    • データ マスキング
    • 監査ログ
  • バックエンド
    • プライベート ネットワーク
    • 相互 TLS
    • IP アドレス アクセス制御

上の図に示すように、Transport Layer Security（TLS）を備えた API キーや OAuth 2.0 などのさまざまなセキュリティ メカニズムをアプリケーションで使用できます。API レイヤのバックエンドに対して、レート制限や脅威保護ポリシーの追加、相互 TLS の構成もできます。

Apigee プラットフォーム内で API チームのアクセス管理を容易にするため、Apigee はロールベースのアクセス制御（RBAC）と連携ログインを備えています。

API を保護するために、Apigee のデフォルト ポリシーを使用することをおすすめします。ポリシーは次のとおりです。

  • トラフィック管理。キャッシュの構成、割り当ての制御、トラフィック急増の影響の軽減、API トラフィックの制御ができます。
  • メッセージ レベルの保護。リクエスト ペイロードの検査と妥当性確認を行い、悪意のある攻撃者からバックエンドを保護できます。
  • セキュリティ。API へのアクセスを制御できます。

そのポリシーのうち 1 つ以上をプロキシレイヤに接続できます。次の表は、ポリシータイプ別に分類された、各ポリシーのセキュリティ ユースケースを示しています。

ポリシータイプ ポリシー名 セキュリティ ユースケース
トラフィック管理 <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="wwJSt9qVSU86+j+K5hdeMDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48/BPCjCPyqbJ4QIYkewUegZAhpcwIAZaV84OTWeC1qmI=" track-metadata-position="body" track-name="internalLink">SpikeArrest ポリシー</atrack-type="bestpractices"> バックエンドに送信されるリクエスト数にレート制限を適用します。
トラフィック管理 <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="yfev46B745dkygzs/X3PYjuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48drLKNEpUjCcWt0NEMR35Aw==" track-metadata-position="body" track-name="internalLink">Quota ポリシー</atrack-type="bestpractices"> 組織が一般ユーザーごとに割り当て（API 呼び出しの数）を適用できるようになります。
トラフィック管理 <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="sNIOJtAt5FZdwfenZs4WsDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48vgnRxI3oKuq9whtN9wbwxN4Jvbbifor6FLtE46wrhrk=" track-metadata-position="body" track-name="internalLink">ResponseCache ポリシー</atrack-type="bestpractices"> レスポンスをキャッシュに保存して、バックエンドへのリクエスト数を減らします。
メッセージ レベルの保護 <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="sNIOJtAt5FZdwfenZs4WsDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48agkPHIw5NGRuiTaPVjcpJ94Jvbbifor6FLtE46wrhrk=" track-metadata-position="body" track-name="internalLink">OASValidation ポリシー</atrack-type="bestpractices"> OpenAPI 3.0 仕様（JSON または YAML）に対する受信リクエストまたはレスポンス メッセージの妥当性確認を行います。
メッセージ レベルの保護 <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadataposition" l10n-encrypted-href="rQxnC8xh5zt2v5zuykhd8TuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48n708TfUwM7jK4ICdhKxXZ/gECJOcw35DRsjAaj5xHIk=" track-metadataposition="body" track-name="internalLink">SOAPMessageValidation ポリシー</atrack-type="bestpractices"> 選択したスキーマに対する XML メッセージの妥当性確認を行います。WSDL に対する SOAP メッセージの妥当性確認を行い、JSON メッセージと XML メッセージの形式が正しいかどうかを判断します。
メッセージ レベルの保護 <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="gJQUlh/pVJ3nw/DE2jI8yjuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48PH2WHMyhNs2aCSuqrjke2kkmB2frJlapcQXWoVC+6R4=" track-metadata-position="body" track-name="internalLink">JSONThreatProtection ポリシー</atrack-type="bestpractices"> 配列や文字列などの JSON 構造を制限することで、コンテンツ レベルの攻撃のリスクを軽減します。
メッセージ レベルの保護 <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="Ev6aAOEX4vzZEHynKB7CyzuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48G5NfGFILzHG1aUVaCe5pKIMNSUpFOiLN5W6ZMdSmR88=" track-metadata-position="body" track-name="internalLink">XMLThreatProtection ポリシー</atrack-type="bestpractices"> メッセージの内容を評価し、メッセージに破損や不適切な形式が含まれていないかを解析前に検出することで、XML の脆弱性への対処と攻撃リスクの低減をサポートします。
メッセージ レベルの保護 <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadataposition" l10n-encrypted-href="gJQUlh/pVJ3nw/DE2jI8yjuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48hnl+zSlYfRHrAeiDsqUTpvpqJhesabZJgL3V8ccue2E=" track-metadataposition="body" track-name="internalLink">RegularExpressionProtection ポリシー</atrack-type="bestpractices"> 事前定義済みの正規表現に照らしてコンテンツを評価し、式が true の場合は拒否します。
セキュリティ <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="r3pD7LpDHbEckDP2z0dAEDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48juAt8VDhRW36xJUC4mFdu43Qj5Gje9MJOejmpvMk7uk=" track-metadata-position="body" track-name="internalLink">BasicAuthentication ポリシー</atrack-type="bestpractices"> Base64 で、ユーザー認証情報のエンコードとデコードが行われます。
セキュリティ <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="sNIOJtAt5FZdwfenZs4WsDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48D+PigKa3fMWEhWo+2kF/jN4Jvbbifor6FLtE46wrhrk=" track-metadata-position="body" track-name="internalLink">VerifyAPIKey ポリシー</atrack-type="bestpractices"> 実行時に API キーの検証と妥当性確認を行います。<atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="408dbk6WV0fWZ26OogAdmO6/+F4vggx0AzbnRBncDef5ATRnWKKNFnIyGajdRoduwWqfpzJjBKtDKUJN+Plw7g==" track-metadata-position="body" track-name="internalLink">API プロダクトに関連付けられた承認済みの API キーを持つアプリケーションのみが API に対するアクセスを許可されます。</atrack-type="bestpractices">
セキュリティ <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="1Tp726mCvkMuEnFlF5rt4zuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48yTsdQQAvZw5EhOjj9jakUw==" track-metadata-position="body" track-name="internalLink">OAuthV2 ポリシー</atrack-type="bestpractices"> OAuth 2.0 権限付与タイプ オペレーションを実行して、アクセス トークンの生成と妥当性確認を行います。
セキュリティ <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="sNIOJtAt5FZdwfenZs4WsDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48xNqw8rr/3fZpAtK46UMv1Yw8J3aQGcGbGAQBhAwrScg=" track-metadata-position="body" track-name="internalLink">JWS ポリシーと JWT ポリシー</atrack-type="bestpractices"> JSON Web Token（JWT）と JSON Web Signature（JWS）を生成、検証、デコードします。
セキュリティ <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="uT7Wlj+BBoD8kfn3kHjQDDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48VwHhKrlRQdC046sjz4nbjA==" track-metadata-position="body" track-name="internalLink">HMAC ポリシー</atrack-type="bestpractices"> 認証とアプリケーション レベルの整合性チェックのために、ハッシュベースのメッセージ認証コード（HMAC）の計算と検証を行います。
セキュリティ <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="sNIOJtAt5FZdwfenZs4WsDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48l/hI3hS5tq+mD5Tm6KH3CN4Jvbbifor6FLtE46wrhrk=" track-metadata-position="body" track-name="internalLink">SAMLAssertion ポリシー</atrack-type="bestpractices">
  • デジタル署名された SAML アサーションを含んだ受信メッセージの妥当性確認を行います。
  • 送信 XML リクエストに対する SAML アサーションを生成します。
セキュリティ <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="uT7Wlj+BBoD8kfn3kHjQDDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48gQT0uDbIMRYnV2IytSwUdg==" track-metadata-position="body" track-name="internalLink">CORS ポリシー</atrack-type="bestpractices"> <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="h61XYN2JabzN6Gs65pqwthXSVh+mabqTVA5/45yLR2rpnRTZBLB1hFjkdAWzsfw5" track-metadata-position="body" track-name="internalLink">ウェブ アプリケーションによって使用される API のクロスオリジン リソース シェアリング（CORS）ヘッダーを設定できます。</atrack-type="bestpractices">

IP アドレスと位置情報ベースのアクセス制御には、Google Cloud Armor を使用することをおすすめします。ただし、使用できない場合は AccessControl ポリシーを使用できます。Apigee からバックエンドへの接続を保護するために、Apigee には TLS handshake 用のキーストアとトラストストアを構成できるキーストアの管理も用意されています。

Apigee で API プロダクトを作成すれば、API オペレーションをバンドル化し、アプリケーション デベロッパーに利用可能な状態にすることができます。API プロダクトは、1 つ以上のオペレーションをバンドル化したものです。オペレーションは、API プロキシとそのプロキシからアクセスできるリソースパスを指定します。オペレーションでは HTTP メソッドと割り当てによってアクセスを制限することもできます。

API へのアクセスを制御するには、API プロダクトを使用します。デベロッパー アプリケーションで 1 つ以上の API プロダクトを定義することにより、API キーを使用してプロキシへのアクセスを制限できます。たとえば、顧客が使用するモバイルアプリは、/v1/payments エンドポイント（この場合は https://$DOMAIN/v1/payments）では POST オペレーションだけを実行できます。別の例として、コールセンターのスタッフが使用するコールセンター アプリケーションでは、https://$DOMAIN/v1/payments/1234 などの /payments エンドポイントで PUT や DELETE などのオペレーションを実行することで、支払いの取り消しや逆支払いができます。

初期のアーキテクチャ

このセクションでは、データセンターとクラウド プロバイダにデプロイされたサービスを使用したマイクロサービス アーキテクチャの例を提示します。以下のアーキテクチャのベスト プラクティスは、初期のアーキテクチャのイテレーションや改善の方法を示しています。

データセンターとクラウド プロバイダにデプロイされたサービスを使用したマイクロサービス アーキテクチャの例。

この初期アーキテクチャには次のような要素があります。

  • 支払いとアカウント サービスはデータセンターでホストされ、送金サービスは Google Cloud でホストされている。
  • 外部アプリケーション ロードバランサは、サービスへの上り（内向き）の制御と構成を行います。
  • 外部アプリケーション ロードバランサが、適切なバックエンドまたはサードパーティ サービスにリクエストを転送し、TLS handshake を処理します。

このアーキテクチャ例の初期状態には次のような制約があります。

  • スケーリングが見込めない。
  • 悪意のある攻撃からシステムを保護できない可能性が高い。
  • 組織内のさまざまなチームによってサービスが開発、管理されているため、セキュリティとロギングに関する一貫性のあるベスト プラクティスが適用されない。

アーキテクチャに関するベスト プラクティス

すべての API に標準のセキュリティ ポリシー セットを実装することで、サービスの価値が高まり、顧客への公開も容易になります。このセクションでは、Apigee を使用して API を保護するためのベスト プラクティスについて説明します。

Apigee をプロキシレイヤとして使用する

次の図は、プロキシ（ファサード）レイヤとして Apigee を追加した初期のアーキテクチャを示しています。

プロキシレイヤとしての Apigee。

Apigee は Google Cloud プロジェクトでプロビジョニングされ、ランタイムは VPC ネットワーク ピアリングを使用してテナント プロジェクトにプロビジョニングおよびピアリングされます。システムを保護するため、インターネット経由でデータを送信するのではなく、Apigee をプロキシレイヤとして使用して、Cloud Interconnect でデータセンターへの直接（プライベート）接続を確立できます。

リクエスト フローは次のとおりです。

  1. クライアントは、キー、トークン、証明書などのアプリケーションの認証情報を使用して外部アプリケーション ロードバランサにリクエストを送信します。
  2. ロードバランサは、リクエストを Apigee に転送します。
  3. Apigee はリクエストを処理し、Apigee API 管理の説明に従ってセキュリティ ポリシーを実行してリクエストを許可または拒否します。Apigee は、クライアント、リクエスト、またはその両方に基づいて異なるバックエンドにリクエストをルーティングするためにも使用できます。
  4. Apigee は、内部 IP アドレスを介してリクエストを GKE バックエンドに直接転送します。Apigee と送金サービス間の通信は、両者ともピアリングされたネットワーク内にあるため、RFC 1918 アドレス（内部 IP アドレス）を通じて行われます。
  5. Apigee は Cloud Interconnect 経由でプライベート データセンター バックエンドにリクエストを送信します。
  6. Apigee は、Apigee NAT IP アドレスのプロビジョニングを介してサードパーティ サービスにリクエストを送信します。

Apigee で WAF レイヤとして Google Cloud Armor を使用する

Google Cloud Armor をアーキテクチャに追加して、セキュリティ境界を拡大できます。Google Cloud Armor は、Google Cloud のグローバルな負荷分散インフラストラクチャの一部です。ウェブ アプリケーション ファイアウォール（WAF）機能を備え、分散型サービス拒否（DDoS）攻撃の防止に有用です。また、OWASP トップ Ten にリストされているリスクからアプリケーションへの脅威を軽減します。

外部アプリケーション ロードバランサに到達したクライアントからのすべての呼び出しを評価するには、Google Cloud Armor のルールとポリシーを構成します。Google Cloud Armor ポリシーの構成を自動化することもできます。Google Cloud Armor でルールを構成する方法の詳細については、Google Cloud Armor の入門ガイドをご覧ください。

次の図は、Apigee と Google Cloud Armor の両方を含むアーキテクチャの例を示しています。

Google Cloud Armor を含むアーキテクチャ。

このアーキテクチャのイベントフローは、このドキュメントの前半で説明した Apigee をプロキシレイヤとして使用するで説明されているフローと似ています。リクエスト フローは次のとおりです。

  1. クライアントは、キー、トークン、証明書などのアプリケーションの認証情報を使用して外部アプリケーション ロードバランサにリクエストを送信します。
  2. 外部アプリケーション ロードバランサによって有効になっているため、Google Cloud Armor はそのリクエストをフィルタリングします。構成済みのすべてのルールとポリシーを適用し、評価します。いずれかのルールに違反している場合、Google Cloud Armor はリクエストを拒否し、エラー メッセージとステータス コードを返します。
  3. Google Cloud Armor ルールの違反がない場合、外部アプリケーション ロードバランサはリクエストを Apigee にルーティングします。
  4. Apigee はリクエストを処理し、セキュリティ ポリシーを実行して、リクエストを許可または拒否します。クライアント、リクエスト、またはその両方に基づいて異なるバックエンドにリクエストをルーティングするためにも使用できます。
  5. Apigee は、内部 IP アドレスを介してリクエストを GKE バックエンドに直接転送します。Apigee と送金サービス間の通信は、両者ともピアリングされたネットワーク内にあるため、RFC 1918 アドレス（内部 IP アドレス）を通じて行われます。
  6. Apigee は Cloud Interconnect 経由でプライベート データセンター バックエンドにリクエストを送信します。
  7. Apigee は、Apigee NAT IP アドレスのプロビジョニングを介してサードパーティ サービスにリクエストを送信します。

WAAP を使用する

セキュリティ プロファイルをさらに強化するために、WAAP を使用することもできます。WAAP は、Google Cloud Armor、reCAPTCHA Enterprise、Apigee を統合して、DDoS 攻撃と bot からシステムを保護します。また、WAF と API 保護も実装します。

ウェブサイトとモバイルアプリから API 呼び出しが行われる企業のユースケースでは、WAAP をおすすめします。reCAPTCHA Enterprise ライブラリを読み込み、reCAPTCHA Enterprise トークンを生成してリクエスト作成時に一緒に送信するよう、アプリケーションを設定できます。

次の図はそのワークフローを示しています。

WAAP のリクエスト フロー。

上の図のリクエスト フローは次のとおりです。

  • （1）顧客と API 利用者によるすべての HTTP(S) リクエストが外部アプリケーション ロードバランサに送信されます。
  • （2）WAAP ソリューションの最初の窓口は Google Cloud Armor です。
  • （2a）Google Cloud Armor ポリシーによってこれらのルールがトリガーされない場合、リクエストは reCAPTCHA Enterprise API に送信され、受信トラフィックが正規リクエストかどうかが評価されます。
  • （3a）正規リクエストの場合、リクエストはバックエンドに転送されます。
  • （2b）正規リクエストでない場合、Google Cloud Armor はリクエストを拒否し、ユーザーに 403 レスポンス コードを送信します。
  • （3b）API リクエストの場合、Google Cloud Armor OWASP ルールと DDoS 対策が評価された後、リクエストは Apigee に転送され、API リクエストの有効性が確認されます。
  • （4）Apigee は、リクエストで使用されている API キーまたはアクセス トークンが有効かどうかを判断します。Apigee が正規リクエストでないと判断した場合、Apigee から 403 レスポンス コードが送信されます。
  • （5）正規リクエストの場合、Apigee はリクエストをバックエンドに転送します。

次の図は、API リクエスト用の Google Cloud Armor、reCAPTCHA Enterprise、Apigee を使用した WAAP のアーキテクチャを示しています。

Google Cloud Armor、reCAPTCHA Enterprise、Apigee を使用した WAAP のリクエスト フロー。

上の図のリクエスト フローは次のとおりです。

  1. クライアントは、キー、トークン、証明書などのアプリケーションの認証情報を使用して外部アプリケーション ロードバランサにリクエストを送信します。
  2. 外部アプリケーション ロードバランサで Google Cloud Armor が有効になっているため、Google Cloud Armor がリクエストを選択します。構成済みのすべてのルールとポリシーを適用し、評価します。いずれかのルールに違反している場合、Google Cloud Armor はリクエストを拒否し、エラー メッセージとステータス コードを返します。
  3. ログインページのフォーム送信のようなウェブサイト呼び出しに関しては、Google Cloud Armor は reCAPTCHA Enterprise と統合されています。reCAPTCHA Enterprise は受信トラフィックを評価し、正規のトラフィックにリスクスコアを追加します。正規のトラフィックでない場合は、Google Cloud Armor がリクエストを拒否します。
  4. Google Cloud Armor ルールの違反がない場合、外部アプリケーション ロードバランサは API リクエストを Apigee にルーティングします。
  5. Apigee はリクエストを処理し、セキュリティ ポリシーを実行して、リクエストを許可または拒否します。Apigee は、クライアント、リクエスト、またはその両方に基づいて異なるバックエンドにリクエストをルーティングするためにも使用できます。
  6. Apigee は、内部 IP アドレスを介してリクエストを GKE バックエンドに直接転送します。Apigee と送金サービス間の通信は、両者ともピアリングされたネットワーク内にあるため、RFC 1918 アドレス（内部 IP アドレス）を通じて行われます。
  7. Apigee は Cloud Interconnect 経由でプライベート データセンター バックエンドにリクエストを送信します。
  8. Apigee は、Apigee NAT IP アドレスのプロビジョニングを介してサードパーティ サービスにリクエストを送信します。

キャッシュ保存に Cloud CDN を使用する

Cloud CDN は、Google のグローバル ネットワークを使用してユーザーの近くからコンテンツを配信します。これにより、ウェブサイトやアプリケーションのレスポンス時間を短縮できます。Cloud CDN には、キャッシュからレスポンスを返すバックエンドのキャッシュ保存機能もあります。アクセス頻度が高いデータを Google ネットワークのエッジにある Google Front End（GFE）にキャッシュ保存することにより、データは可能な限りユーザーに近い場所に保存され、高速アクセスが可能になっています。

また、Cloud CDN により、休日や新学期の時期などのトラフィックの季節的な急増を組織はシームレスに処理できます。こうしたキャッシュ保存の手法により、エコシステムでの信頼性とユーザー エクスペリエンスが向上します。また、ウェブサーバーの負荷、コンピューティング、ネットワーク使用量を最小限に抑えるのにも役立ちます。このアーキテクチャを実装するには、Apigee のトラフィックを処理するロードバランサで Cloud CDN を有効にする必要があります。

Cloud CDN は、このドキュメントで説明するどのオプションでも使用できます。次の図は、Cloud CDN を追加した WAAP の初期のアーキテクチャの例を示しています。

Cloud CDN を使うリクエスト フロー。

上の図に示されているリクエスト フローは次のとおりです。

  1. クライアントが reCAPTCHA Enterprise ライブラリを使用してトークンを取得し、アプリケーションの認証情報（キー、トークン、証明書など）を使用してリクエストを外部アプリケーション ロードバランサに送信します。
  2. Cloud CDN は、キャッシュキーを使用してキャッシュをチェックし、キャッシュ ヒットが true の場合はレスポンスを返します。
  3. キャッシュ ヒットが false の場合、外部アプリケーション ロードバランサにより有効になっている Google Cloud Armor がリクエストをフィルタします。Google Cloud Armor は、構成されたすべてのルールとポリシーを適用し、評価します。いずれかのルールに違反している場合、Google Cloud Armor はリクエストを拒否し、エラー メッセージとステータス コードを返します。
  4. Google Cloud Armor は reCAPTCHA Enterprise と統合されています。reCAPTCHA Enterprise は、リスクスコアで正規の受信トラフィックを評価します。正規のトラフィックでない場合は、Google Cloud Armor がリクエストを拒否します。
  5. Google Cloud Armor ルールの違反がない場合、外部アプリケーション ロードバランサはリクエストを Apigee にルーティングします。
  6. Apigee はリクエストを処理し、Apigee API 管理の説明に従ってセキュリティ ポリシーを実行してリクエストを許可または拒否します。クライアント、リクエスト、またはその両方に基づいて異なるバックエンドにリクエストをルーティングするためにも使用できます。
  7. Apigee は、内部 IP アドレスを介してリクエストを GKE バックエンドに直接転送します。Apigee と送金サービス間の通信は、両者ともピアリングされたネットワーク内にあるため、RFC 1918 アドレス（内部 IP アドレス）を通じて行われます。
  8. Apigee は Cloud Interconnect 経由でプライベート データセンター バックエンドにリクエストを送信します。
  9. Apigee は、Apigee NAT IP アドレスのプロビジョニングを介してサードパーティ サービスにリクエストを送信します。
  10. レスポンスがクライアントに返送されると、Cloud CDN はそれをキャッシュに保存し、以降の呼び出しではキャッシュからレスポンスを返せるようにします。

次のステップ