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

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

• Google Cloud Armor
• reCAPTCHA
• Cloud CDN

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

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

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

Apigee API Management

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 つ以上をプロキシレイヤに接続できます。次の表は、ポリシータイプ別に分類された、各ポリシーのセキュリティ ユースケースを示しています。

ポリシータイプ	ポリシー名	セキュリティ ユースケース
トラフィック管理	SpikeArrest ポリシー	バックエンドに送信されるリクエスト数にレート制限を適用します。
トラフィック管理	割り当てポリシー	組織が一般ユーザーごとに割り当て（実行された API 呼び出しの数）を適用できるようになります。
トラフィック管理	ResponseCache ポリシー	レスポンスをキャッシュに保存して、バックエンドへのリクエスト数を減らします。
メッセージ レベルの保護	OASValidation ポリシー	OpenAPI 3.0 仕様（JSON または YAML）に対する受信リクエストまたはレスポンス メッセージの妥当性確認を行います。
メッセージ レベルの保護	SOAPMessageValidation ポリシー	選択したスキーマに対する XML メッセージの妥当性確認を行います。WSDL に対する SOAP メッセージの妥当性確認を行い、JSON メッセージと XML メッセージの形式が正しいかどうかを判断します。
メッセージ レベルの保護	JSONThreatProtection ポリシー	配列や文字列などの JSON 構造を制限することで、コンテンツ レベルの攻撃のリスクを低減するのに役立ちます。
メッセージ レベルの保護	XMLThreatProtection ポリシー	メッセージの内容を評価し、メッセージに破損や不適切な形式が含まれていないかを解析前に検出することで、XML の脆弱性への対処と攻撃リスクの低減をサポートします。
メッセージ レベルの保護	RegularExpressionProtection ポリシー	事前定義済みの正規表現に照らしてコンテンツを評価し、式が true の場合は拒否します。
セキュリティ	BasicAuthentication ポリシー	Base64 でユーザー認証情報をエンコードおよびデコードします。
セキュリティ	VerifyAPIKey ポリシー	実行時に API キーの検証と妥当性確認を行います。API プロダクトに関連付けられた承認済みの API キーを持つアプリケーションのみに API へのアクセスを許可します。
セキュリティ	OAuthV2 ポリシー	OAuth 2.0 権限付与タイプ オペレーションを実行して、アクセス トークンの生成と妥当性確認を行います。
セキュリティ	JWS ポリシーと JWT ポリシー	JSON Web Token（JWT）と JSON Web Signature（JWS）を生成、検証、デコードします。
セキュリティ	HMAC ポリシー	認証とアプリケーション レベルの整合性チェックのために、ハッシュベースのメッセージ認証コード（HMAC）を計算および検証します。
セキュリティ	SAMLAssertion ポリシー	デジタル署名された SAML アサーションを含んだ受信メッセージの妥当性確認を行います。 送信 XML リクエストに対する SAML アサーションを生成します。
セキュリティ	CORS ポリシー	ウェブ アプリケーションで使用される API に対してクロスオリジン リソース シェアリング（CORS）ヘッダーを設定できます。

IP アドレスと位置情報ベースのアクセス制御には、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 を処理します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. クライアントは、キー、トークン、証明書などのアプリケーションの認証情報を使用して外部アプリケーション ロードバランサにリクエストを送信します。
2. 外部アプリケーション ロードバランサで有効になっているため、Cloud Armor はそのリクエストをフィルタリングします。構成済みのすべてのルールとポリシーを適用し、評価します。いずれかのルールに違反している場合、Cloud Armor はリクエストを拒否し、エラー メッセージとステータス コードを返します。
3. 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 は、Cloud Armor、reCAPTCHA、Apigee を統合して、DDoS 攻撃と bot からシステムを保護します。また、WAF と API 保護も実装します。

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

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

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

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

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

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

1. クライアントは、キー、トークン、証明書などのアプリケーションの認証情報を使用して外部アプリケーション ロードバランサにリクエストを送信します。
2. 外部アプリケーション ロードバランサで Cloud Armor が有効になっているため、Cloud Armor がリクエストを選択します。構成済みのすべてのルールとポリシーを適用し、評価します。いずれかのルールに違反している場合、Cloud Armor はリクエストを拒否し、エラー メッセージとステータス コードを返します。
3. ログインページのフォーム送信のようなウェブサイト呼び出しに関しては、Cloud Armor は reCAPTCHA と統合されています。reCAPTCHA は受信トラフィックを評価し、正規のトラフィックにリスクスコアを追加します。正規のトラフィックでない場合は、Cloud Armor がリクエストを拒否します。
4. 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 の初期のアーキテクチャの例を示しています。

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

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

次のステップ

• Apigee プロビジョニング オプションの詳細を確認する。
• Apigee と Cloud Armor による多層 API セキュリティの概要を読む。
• Apigee X と Cloud CDN を使用した高パフォーマンスのグローバル API を提供する方法を学ぶ。
• Apigee コミュニティで閲覧や質問を行う。
• GitHub の Apigee リポジトリを確認する。
• Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。