OWASP の上位 10 件の API の脅威

はじめに

OWASP は、信頼できるアプリケーションと API の開発、購入、メンテナンスを支援する組織専用のオープン コミュニティです。OWASP API セキュリティ プロジェクトを通じて、OWASP はウェブ アプリケーションと REST API にとって最も重要なセキュリティ リスクを公開し、それらのリスクに対処するための推奨事項を提供しています。

このドキュメントでは、OWASP の 2019 年トップ 10 の API セキュリティの脅威によって特定された、一般的な API ベースの攻撃から保護する方法について説明します。最新のリストで強調されている上位の脅威における共通のテーマは、クライアント アプリの使用に依存するアンチパターンを使用してアクセス制御を適用することによる、クライアント アプリ内の API リクエストによって返されるデータのフィルタリングなど、認証と承認の制御の不適切な配置です。

API エコシステムの急速な成長に伴い、API の不正行為や不正使用により、残念ながら攻撃者によるデータの引き出しが現在における最も一般的な攻撃要因となっています。セキュリティは引き続き、Apigee にとって優先度が高く、セキュリティ レポート機能や異常検出機能を含めて、高度な API オペレーションなどの多数の新機能が追加されています。ただし、API への攻撃が成功する可能性を減らすために、Apigee のセキュリティ機能を正しく設計して実装することが重要です。

アプリが実行されているプラットフォームを制御しないため、コンシューマ アプリケーションは信頼できない、「公開されている」とみなす必要があります。公開アプリは不正使用される可能性があるため、アクセス制御（API1、API5）の適用、レスポンス データ（API6）のフィルタリング、または API キーやアクセス トークンなどのクライアント シークレット（API2）の安全な保存は信頼できません。2019 年の OWASP トップ 10 を調べることで、いくつかの推奨事項が浮かび上がります。

  • API を使用するクライアント アプリの種類（SPA、モバイル、ブラウザベース）を決定し、適切な認証、承認、セキュリティ パターンを設計します。
  • 常に「公開クライアント」の OAuth または OpenID Connect フローを使用します（PKCE の使用を強くおすすめします）。
  • アプリのビジネス ロジックを検討し、最初に OpenAPI 仕様を定義してから API プロキシを設計し、Apigee 内のバックエンドからのすべてのレスポンス データをフィルタリングします。ダウンストリームのアプリ コード ロジックでこれを行おうとしないでください。
  • ユーザー固有の PII を含めてすべてのデータ リクエストをフィルタリングし、リクエストしているユーザーに属しているデータのみを許可します。

API1:2019 無効なオブジェクト レベルの承認

脅威の説明

オブジェクト アクセス リクエストの承認検証が不十分な場合、攻撃者がアクセス トークンを再利用して不正な操作を実行できてしまいます。この脅威は、承認検証の不適切な構成が原因です。Apigee は、VerifyApiKey、OAuth、JSON Web Token（JWT）ポリシーを提供しており、これらはこの脆弱性に対する保護に役立ちますが、この脅威を防ぐために、こうしたポリシーを正しく構成することが重要です。

この脅威を防ぐには、アプリケーション開発チームとセキュリティ チームが緊密に連携することが重要です。承認は本質的に複雑なトピックであり、効果的なきめ細かい承認には、アプリケーションのビジネス ロジックに対する深い理解が必要です。

Apigee の実装の観点から、主に次の 2 つの点を考慮する必要があります。

  • アクセス トークンの整合性
  • アクセス制御の適用

アクセス トークンの整合性

正しい OAuth または OpenID Connect フローと適切な認証情報検証または署名メカニズムを使用して、リクエスト元のクライアントによって提供されたトークンが改ざんされていないかどうかを検証することが重要です。Apigee では、よく使用されるすべての OAuth フローがサポートされます。

Apigee アクセス トークンの検証ポリシーは次のとおりです。

アクセス制御の適用

アクセス トークンの有効性が検証されたら、アクセス制御の適用ポリシーを実装して、承認トークンのアクセス エンタイトルメントに対して各 API リクエストを評価することが重要です。

Apigee には、承認ポリシーを検証して適用するための主なメカニズムが 2 つあります。

  • 内部: 条件付きフローを使用して、承認トークンからフロー変数として抽出されたクレームに基づいてアクセス リクエストを評価する
  • 委任: サードパーティのアクセス管理ソリューションへのサービス コールアウトの使用

内部アプローチ（上記の図を参照）は、アクセス制御モデルが比較的単純な場合に推奨されます。たとえば、アクセス トークンから抽出されたクレームを使用して、API オブジェクト リクエストを直接評価および承認できます。

OAuth ポリシーまたは JWT ポリシーに対して使用可能なフロー変数を使用して、条件付きフロー ステートメントを使用してアクセス リクエストを評価します。

委任アプローチ（上記の図を参照）は、アクセス トークンから抽出されたクレームをバックエンド オブジェクトへの承認に直接使用できない場合や、アクセス トークンを取得するために承認サーバーへの個別の呼び出しが必要となる複雑な OAuth フロータイプに推奨されます。

サービス コールアウト ポリシーを使用すると、サードパーティ サービスから承認ポリシーの決定をリクエストすることや、リクエスト元のエージェントに関する追加のクレーム情報を取得し、条件付きフローを使用してアクセス制御を決定することが可能です。

API2:2019 無効なユーザー認証

脅威の説明

ユーザー認証ポリシーが正しく実装されていないと、攻撃者が認証の実装における誤りを利用して、正当なユーザーになりすますことができてしまいます。認証方法を実装する際に、次のような認証の原則を考慮する必要があります。

  • ユーザー エージェント（アプリ）とリクエスト元のユーザーの両方を常に認証する
  • 委任された認証と承認のパターンを使用して、API リクエスト内でパスワードを直接渡すことを回避する
  • アクセス認証情報の署名を常に検証し、使用するすべてのアクセス認証情報に有効期限が定義されていることを確認する
  • 割り当てを設定し、Apigee Sense を使用してボットドリブン ブルート フォース攻撃を検出して対応することで、ブルート フォース攻撃を阻止する

アウトサイドイン パラダイムでは、API 設計は、バックエンド システム内の既存のデータの構造ではなく、ユーザーのデータのユースケースに基づいて構築され、外部ユーザー向けの API の設計時にはセキュリティが重要な要素となります。従来のバックエンド システムは、パブリック ネットワークに公開するための十分に強力な認証実装で構築されていません。Apigee では、Identity and Access Management ソリューションを組み込むことで、このような脅威から保護するための強力なソリューションを提供します。

ここで考慮すべき主要な要素がいくつかありますが、いずれも次のセクションで説明します。

  • セキュリティ設計: 認証パターンの実装のために Apigee の機能をフル活用する
  • プライバシー: 公開されているすべての API プロダクトで、設計された認証パターンが正しく使用されていることを確認する
  • オペレーション セキュリティ: 不審な動作や異常な動作を検出し、認証済みの API プロキシを回避するか、またはブルート フォースを試みることが可能

セキュリティ設計

セキュリティ設計の目的は、認証フローとサードパーティの ID ツールとの統合を正しく実装することです。セキュリティ設計は重要なフェーズです。まず、API エンドポイントを使用するアプリのタイプに基づいて、使用する適切なタイプの委任認証フローを理解することから始めます。次に、ID チームと連携して、ID ソリューションで実装する統合パターンを定義します。

OpenID Connect RFC と OAuth RFC では、委任されたさまざまな認証と承認のフローと、これらのフローに含まれるアクターが提供されます。これは複雑なトピックであり、不完全な認証が OWASP API の主要な脅威の 1 つであることは驚くべきことではありません。ID 標準の正しい実装に関する包括的な入門についてはこのドキュメントの範囲外ですが、Apigee にはこの電子書籍とウェブキャスト、実装例など、OAuth フローを詳しく理解するための追加のリソースが多数あります。

認証ポリシー

ID と認証に関する問題に対処するのに役立つ Apigee ポリシーは次のとおりです。

  • OAuth 2.0 フレームワークを使用する場合は、アクセス トークン、更新トークン、レスポンス フロー トークンを確認または生成します。注: 技術的には、OAuth は委任された承認フレームワークですが、委任された認証パターンや連携された認証パターンで広く使用されています。
  • OpenID Connect 1.0 の JSON ウェブトークンと JSON ウェブ署名の検証、デコード、生成
  • SAML アサーションの生成と検証
  • API キーの確認
  • キー付きのハッシュ メッセージ認証コード（HMAC）の確認

トラフィック管理

次の Apigee トラフィック管理機能は、ブルート フォース攻撃からの保護に役立ちます。

  • API プロキシの全体的な移動平均レート制限を設定するための Spike Arrest ポリシー
  • Quota ポリシー: アプリキー、デベロッパー、API プロダクトの割り当てによって定義された割り当てに基づいて、API プロキシに対してきめ細かいレート制限を設定します。
  • キャッシュ ポリシー。定義された有効期限に基づいて、保存されたアクセス トークンをキャッシュし、キャッシュされた認証情報を無効にする機能（たとえば、有効なアクセス トークンが不正使用されている状況）

ガバナンス

セキュリティは継続的なプロセスであり、「設定して忘れる」プロジェクトではありません。セキュリティ侵害の最大の原因の 1 つは構成ミスです。認証フロー、ID 統合パターン、認証関連のトラフィック管理ポリシーを定義したら、これらを正しく一貫して実装することが非常に重要です。

Apigee には、実装の整合性を確保し、構成ミスエラーを防ぐためのさまざまな機能やツールが用意されています。

ロールベースのアクセス制御（RBAC）

大企業でも小規模な新興企業でも、構成ミスエラーを防ぐには、まず適切なユーザーとチームだけが API プロキシ構成にアクセスして変更できるようにします。API プログラムは、組織全体の専門分野が多岐にわたるチームがサポートしています。各チームには、API 導入の道のりの一部として業務を遂行するために必要な権限のみを付与する必要があります。

Apigee には、事前定義ロールにユーザーを割り当てる機能や、API チームに適したカスタムロールを作成する機能を提供することによって、ロールベースのアクセスを管理する機能があります。API プログラムを安全にスケーリングするには、ロールの割り当てを正しく定義して管理することが重要です。また、連携を使用して既存の企業ディレクトリと統合すると、Apigee 内の 2 番目の管理者認証情報セットを管理する必要がなくなります。

共有フロー

共有フローを使用すると、API プロキシ全体で実装できる再利用可能なオブジェクトに、ポリシーとリソースを定義できます。たとえば、チームがセキュリティ チームと連携して、API を使用するアプリのタイプに基づいて複数の認証設計パターンを設計したとします。API デベロッパーはこれを再利用するために ID の専門知識を持っている必要はなく、知る必要があるのは Flow callout ポリシーを使用して既存の API プロキシ構成に追加する適切な共有フローだけです。

図: 共有フローは再利用可能なポリシーと条件ロジックのバンドルであり、複合パターンを管理できます。

セキュリティ レポート

組織内の適切なユーザーのみが認証パターンを変更できることを確認し、共有認証フローを定義したら、API チームが開発した API プロキシで認証パターンを一貫して使用していることを確認する必要があります。

Apigee の新しい高度な API オペレーション機能には高度なセキュリティ レポートが含まれており、オペレーション チームとセキュリティ チームはすべての API プロキシに関するレポートを簡単に表示でき、共有フローの使用などのセキュリティ ポリシーの遵守に集中できます。レポート、ロギング、アラートは API セキュリティの重要な要素であり、API10: 不十分なロギングで詳しく説明しますが、不完全な認証のリスクを回避するという観点から、共有フローとして実装された定義済みの認証標準を遵守することが非常に有益です。

オペレーション セキュリティ

適切な認証パターンをベースライン トラフィック管理とともに使用して API を本番環境に移行したら、SecOps チームが、認証情報の不正使用から始まる不審なアクティビティを監視して対応できる必要もあります。

Apigee Sense

Apigee Sense は、悪意のあるクライアントによる攻撃など、望ましくないリクエスト トラフィックから API を保護します。Apigee Sense は、API リクエスト トラフィックを分析し、望ましくないリクエストを表す可能性があるパターンを識別します。この分析を使用すると、望ましくないリクエストを出すクライアントを特定し、そのリクエストに対して許可、ブロック、フラグ設定のアクションを取ることが可能です。Sense の将来の機能には、不審なトラフィックに対して ReCAPTCHA による確認を自動的に有効にする機能が含まれます。

Apigee Sense では、以下のようなリクエスト パターンから API を保護できます。

  • 人間の振る舞いの中に紛れた自動化された動作
  • 同じ IP から何度も続く試行
  • 異常なエラー率
  • 疑わしいクライアント リクエスト
  • データクロール
  • キー ハーベスティングと認証ブルート フォース攻撃
  • アクティビティ バースト
  • 地理的パターン

高度な API オペレーション

Sense はボットのような脅威を検出して対処するように設計されていますが、高度な API オペレーションには異常検出と高度なアラートの定義が含まれています。

異常検出は、人工知能（AI）モデルと機械学習（ML）モデルを履歴 API データに適用することによって機能します。次に、異常検出では、それまで思いつきもしなかった、生産性を向上させ、API の問題の平均修復時間（MTTR）を短縮するというシナリオのために、アラートをリアルタイムで生成できます。

高度な API オペレーションは、既存の API Monitoring アラート メカニズムに基づいており、次の高度なアラートタイプが追加されます。

  • トラフィック アラートの合計。特定の期間にトラフィックが指定した割合だけ変化した場合にアラートを生成します。たとえば、トラフィックが 1 時間で 5% 以上増加した場合や、1 週間で 10% 以上減少した場合に、アラートを生成できます。
  • 異常アラート。Edge ではトラフィックとパフォーマンスの問題を検出します。これらの異常に対してアラートを発生させることが可能です。
  • TLS 有効期限アラート。TLS 証明書の有効期限が近づいたときに通知を生成します。

API3:2019 過度のデータの漏洩

脅威の説明

公開された API では、必要なフィルタリングを行うためにクライアント アプリに依存している必要以上のデータが公開される可能性外あります。攻撃者が基盤となる API に直接クエリを送信すると、センシティブ データにアクセスできてしまいます。

Apigee の API 設計のためのアウトサイドイン設計原則の 1 つは、データの節約です。UX デザイナーやデベロッパーと連携して、アプリの UI 内で API 経由で必要なデータのみを公開します。バックエンド システムは公開使用パターン用に構築されていないため、Apigee での API ファースト設計の最初のタスクは、顧客とデベロッパーに対して最大限の API プロダクトを提供するために、公開するデータを必要最小限まで減らすことです。

Apigee のもう 1 つの設計原則は再利用性です。セキュリティ上の懸念はさておき、API によって提供されるデータをアプリでフィルタリングすると、アプリを開発するすべてのプラットフォームでフィルタリング ロジックを移植する必要が生じます。

セキュリティの観点から、この脅威は承認の適用をアプリに委任することに起因しますが、制御できないプラットフォームや OS が原因となることもあります。API1 と API2 で検証したように、不正なデータアクセスを防ぐためには、認証と承認を正しく実装することが重要です。

次のセクションでは、次の方法について説明します。

  • バックエンド サービスへのリクエストとレスポンスを書き換えて、データの露出を最小限に抑える
  • バックエンド サービスに関するセンシティブな環境情報が攻撃者に対して露出されることによる詳細なエラー メッセージを防ぐために、障害処理を実装する

レスポンスとリクエストの書き換え

バックエンド システムは一般に、公開アプリや信頼できないパブリック ネットワークで使用するようには設計されていません。Apigee Edge は、バックエンドを過度のデータ公開から保護することで、公開 API プロダクトをデプロイできるように設計されています。

これを行うために、Apigee では次の 3 つの主要なポリシーを使用します。

  • メッセージの割り当て
  • コードのコールアウト
  • 障害処理

Assign Message ポリシー

Assign Message ポリシーは、API プロキシフローの実行時に新しいリクエストとレスポンスのメッセージを変更または作成します。このポリシーを使用すると、こうしたメッセージに以下の操作を実行できます。

  • 新しいフォーム パラメータ、ヘッダー、クエリ パラメータをメッセージに追加する
  • 既存のプロパティをメッセージ間でコピーする
  • メッセージからヘッダー、クエリ パラメータ、フォーム パラメータ、あるいはメッセージのペイロードを削除する
  • メッセージに既存のプロパティの値を設定する

Assign Message は、一般的にはリクエストやレスポンスのプロパティの追加、変更、削除に使用します。カスタム リクエスト メッセージの作成に記載されているように、Assign Message を使用してカスタムのリクエストやレスポンス メッセージを作成して、別のターゲットに渡すこともできます。

カスタムコードによる複雑な書き換え

Assign Message ポリシーの機能では対処できないデータを処理する場合は、JavaScript、Java、Python などのプロシージャル言語を使用できます。カスタムコードを API プロキシに追加し、プロキシフローに追加されたポリシーから呼び出すことが可能です。手続き型コードのサポートは、フロー変数、障害、リクエスト本文、レスポンス本文の複雑な処理を簡単に実装できるよう設計されています。

手続き型コードでできることを、以下に示します。

  • 複雑な本文の値（リクエストおよびレスポンスの値）を作成または操作する。
  • URL を書き換える（たとえばターゲット エンドポイント URL をマスクする）。

サポート対象の言語に対し、Apigee Edge にはそれぞれ JavaScript ポリシー、Java Callout ポリシー、Python Script ポリシーが含まれます。

障害処理

Apigee では、Raise Fault タイプのポリシーを使用してカスタム例外処理を実行できます。Raise Fault ポリシーは Assign Message ポリシーのバリエーションであり、エラー状態に応じてカスタム障害レスポンスを生成できます。

共有フロー

共有フローを使用して、障害メッセージを標準化できます。たとえば、バックエンドから特定の HTTP エラーコードを検出する同じ構成済みポリシーを使用して、エラー レスポンスを書き換えて一般的なエラー メッセージを返すことが可能です。

API4:2019 リソース不足とレート制限

脅威の説明

レート制限ポリシーを実装しないことで、攻撃者がサービス拒否攻撃でバックエンドに負荷をかける可能性があります。

これは、次の Apigee 機能を使用して簡単に対処できます。

  • 割り当てと Spike Arrest ポリシー: 受信 API リクエストにトラフィック制限を設定するための予防制御
  • Apigee Sense: ボットドリブン攻撃を動的に検出して対応する
  • 高度な API モニタリングとアラート: 進行中の DDoS 攻撃を通知する検出の制御

Quota ポリシーと Spike Arrest ポリシーによるレート制限

Apigee には、レート制限に関する 2 つのポリシーが用意されています。

  • Spike Arrest では、バックエンドへの受信リクエストの総数のレート制限のために、API プロキシ レベルで定義される一般的なポリシーが提供されます。
  • Quota では、API プロキシレベルまたは API プロダクト レベルで Quota ポリシーを適用するための詳細なポリシーツールが提供されます。

Spike Arrest

Spike Arrest ポリシーでは、トラフィックの急増から保護します。このポリシーは、API プロキシで処理され、バックエンドに送信されるリクエスト数を調整します。これにより、ポリシー内で定義できる移動平均値を使用して、パフォーマンスの低下やダウンタイムの発生を防ぎます。

Quota

Quota ポリシーを使用すると、1 分、1 時間、1 日、1 週間、1 か月など、一定期間に API プロキシで許可されるリクエスト メッセージの数を構成できます。API プロキシにアクセスするすべてのアプリに同じ割り当てを設定することも、次の条件に基づいて設定することもできます。

  • API プロキシを含むプロダクト
  • API をリクエストするアプリ
  • アプリのデベロッパー
  • その他の条件

このポリシーは Spike 停止よりもきめ細かく、通常は同時に使用する必要があります。

Apigee Sense によるボットの検出

Apigee Sense を使用すると、悪意のある行動または疑わしい行動を示すクライアントまたは場所に基づいて、特定のクライアント、IP 範囲、または自律システム組織からのリクエストを明示的に許可するか、ブロックするか、フラグを付けることが可能です。Apigee Edge は、こうしたアクションを API プロキシが処理する前にリクエストに適用します。たとえば、IP アドレスの範囲や特定のクライアントが「Brute Guessor」行動を示している場合にブロックしたり、フラグを付けたりできます。

Advanced API Ops Monitoring による脅威の検出

トラフィック アラートを使用すると、特定の期間に環境、プロキシ、リージョンのトラフィックが指定した割合だけ変化したときに通知が生成されます。この機能では、DDoS 攻撃の場合と同様に、トラフィックが予想スループットから大きく外れた場合にアラートが動的に生成されます。これらのアラートは、サードパーティのロギングおよびモニタリング ソリューションに簡単に送信できます。

API5:2019 無効な関数レベルの承認

脅威の説明

この脅威は API1 のバリエーションであり、承認の脆弱性でもあります。この脅威により、攻撃者はアクセスが許可されていない機能にリクエストを送信して、アクションを実行できてしまいます。たとえば、攻撃者は、API エンドポイントが HTTP リクエストの動詞を検証しない場合に、GET を PUT または DELETE に置き換えることによって、読み取りを許可するデータを変更または削除できてしまいます。または、API リソースの URI パスに対して、十分に制限されたアクセス制御を実装しないと、API エンドポイントで攻撃者がリクエスト内のパスを変更することによってユーザーのデータを見ることができてしまいます。

このタイプの脅威は、Apigee をメディエーションおよび抽象化レイヤとして使用する価値を強調しています。公開アクセス用に設計されていない多くのバックエンド システムでは、デフォルトでリスクの高い管理機能を含めて、複数のビジネス ロジックを実行するための単一のエンドポイントが提供されます。

この脅威の可能性を減らすための概念的な要素は通常、次のように分けられます。

  • 保護対象API プロダクト戦略を検討し、RESTful ベスト プラクティスを使用して Apigee API プロキシ、プロダクト、アプリ機能によって露出されるパスとリソースを設計する場合に機能の論理セグメンテーションを実装します。
  • API リソースにアクセスしているユーザーAPI1 と API2 で説明されているように、Apigee の認証機能と承認機能を使用して、高レベルのペルソナを定義し、デフォルトの「最小限の権限」のアクセス権を実装します。
  • アクセス ポリシーの適用方法条件付きフローと障害を使用して、すべての API リクエストの URL パスと動詞を検証します。

図: この図は、アクセス トークン内でエンタイトルメントとして提供されるスコープを使用して、Apigee で関数レベルの承認を適用する方法を示しています。

API プロキシ、プロダクト、アプリによる論理セグメンテーション

Apigee では、API リソースの論理セグメンテーションを有効にする柔軟性の高いツールキットが提供され、API プロキシを任意の数の API プロダクトにバンドルできます。アプリ デベロッパーはこの API プロダクトを使用して、アプリを登録できます。アクセス ポリシーは、これらのどのレベルでも定義できます。

効果的な機能の承認とセグメンテーションを実装するには、API プロダクト戦略を定義することが重要です。この重要で継続的なプロセスの一部として、ユーザーの視点とデベロッパーの視点から API リソースを見ることによって API プロダクトの「ユーザー」と「対象」を定義し、パスリソースと HTTP の動詞レベル、許可されるリクエストのタイプを定義します。

図: API プロダクトにバンドルする API リソースを 1 つ以上の API から集めることができるので、リソースを組み合わせて使用層と承認の境界を作成できます。

OAuth スコープと JWT クレームによる関数レベルのアクセス制御

API1: 2019 無効なオブジェクトの承認のために上記で検討した承認アプローチでは、オブジェクト レベルでのきめ細かいアクセス制御に対応します。これは、関数レベルでの大まかなアクセス制御に対応することと同様に重要です。リクエスト元のユーザーは、この URL パスをリクエストすることもできますか？このタイプのポリシーは多くの場合、ユーザー ペルソナ（顧客、従業員、管理者、社内またはサードパーティのデベロッパー）ごとに定義されます。

構成ミスのリスクを減らすには、セキュリティ チームと連携し、OAuth スコープまたは JWT クレームを使用して、アクセス トークンにリクエスト元のユーザーに関するアサーションを含めることをおすすめします。

条件フローによるリクエストの検証

基礎レベルでは、REST API 呼び出しが次の要素で構成されます。

  • エンドポイント
  • リソース
  • アクションの動詞
  • 任意の数の追加のリクエスト属性（クエリ パラメータなど）

この脅威で説明する攻撃のタイプは通常、API リクエストのフィルタリングが不十分であるために発生し、攻撃者が承認されていないアクションを実行したり、保護されているリソースにアクセスしたりできてしまいます。Apigee では、アクセス トークンまたはクレームに基づいてリクエストをフィルタリングできる条件ロジックに加えて、リクエスト自体に基づいてフィルタリン グロジックを実装できます。

API プロダクトのビジネス ロジック、API で許可される機能を明確に理解して定義したら、次のステップとして、Apigee プロダクトの機能以外によるリクエストを制限します。

  • プロキシフロー構成の任意のステップで、リソースパスまたは動詞を制限する条件ロジックと Raise Fault ポリシー
  • JSON と XML 不正な形式の JSON または XML リクエスト ペイロードを使用したコンテンツ ベースの攻撃から保護するための脅威保護ポリシー

API6:2019 一括割り当て

脅威の説明

API を介してクライアント アプリに提供されるフィルタリングされていないデータにより、バックエンドに保存されているデータ オブジェクトのプロパティを未承認で修正したり、アクセスしたりできてしまいます。

この脅威は、フィルタリングされていないデータ（通常は JSON または XML）がクライアントに送信されることによって発生し、攻撃者がバックエンド システムの基盤となる実装の詳細や、機密データ要素のプロパティ名を推測できてしまいます。このタイプの攻撃の結果、攻撃者が不適切なデータを読み取ったり操作したりする可能性が生じ、最悪のシナリオでは、リモートコード実行の脆弱性が生じる可能性があります。

このタイプの脅威の発生には通常、次の 2 つの側面があります。

  • API 設計の観点。アプリが攻撃者によって悪用され、信頼できると見なされる可能性があるため、クライアント側でのデータのフィルタリングを行うためにアプリケーション ロジックに依存しないでください。API サービスを有効にするために必要な最小限のデータのみを露出するように API データスキーマを設計します
  • API 実装の観点。データ フィルタリングとスキーマ検証を実装して、機密データが誤ってクライアント アプリケーションに露出されるのを防ぐ

Apigee プロダクトの観点から、API の堅牢なデータ フィルタリングを実装するのに役立つ機能がいくつか用意されています。

OpenAPI 仕様のフィルタリング ポリシー

OASValidation（OpenAPI 仕様検証）ポリシーを使用すると、OpenAPI 3.0 仕様（JSON または YAML）に対して受信リクエストまたはレスポンス メッセージを検証できます。このポリシーでは、次のことが実現します。

  1. OpenAPI 仕様（OAS）を作成して API を設計する
  2. Apigee を使用してバックエンドから API プロダクトを安全に露出するために必要なメディエーション、セキュリティ、キャッシュ ロジックを実装する
  3. OAS 仕様で定義されているデータスキーマ（ベースパス、動詞、リクエスト メッセージ ポリシー、パラメータ）に対する受信リクエストを検証する

SOAP Message Validation ポリシー

SOAP Message Validation ポリシーを使用すると、XSD スキーマに対して XML メッセージを検証するか、WSDL 定義に対して SOAP メッセージを検証することによって、XML ベースのリクエストを検証できます。さらに、Message Validation ポリシーを使用して、JSON 形式または XML 形式のメッセージ ペイロードが正しいことを確認できます。これには、XML 形式または JSON 形式のメッセージでの次の検証が含まれます。

  • 単一のルート要素があること
  • コンテンツに不正な文字がないこと
  • オブジェクトとタグが正しくネストされていること
  • 開始タグと終了タグが一致していること

API7:2019 セキュリティ構成の誤り

脅威の説明

セキュリティの構成ミスは一般的に、安全性が低いデフォルト構成、不完全またはアドホックの構成、オープン クラウド ストレージ、構成が誤っている HTTP ヘッダー、不要な HTTP メソッド、制約なしのクロスオリジン リソース シェアリング（CORS）、機密情報が含まれる詳細なエラー メッセージが原因です。攻撃者は、パッチが適用されていない欠陥、共通のエンドポイント、保護されていないファイルやディレクトリを見つけて、攻撃しようとしているシステムの未承認のアクセスや知識を得ようとします。 セキュリティの構成ミスにより、プライベート ユーザー データだけではなくシステムの詳細が露出される可能性があり、サーバーの完全なセキュリティ侵害につながる可能性があります。また、セキュリティの構成ミスの脆弱性には他にも次のようなものがあります。

  • 構成が誤っている TLS
  • スタック トレースが含まれるエラー メッセージ
  • パッチが適用されていないシステム
  • 露出されているストレージまたはサーバーの管理パネル

組織でセキュリティの構成ミスに関する課題に対処し、緩和するために、以下のさまざまな手順があります。

  1. 強化とパッチ適用のプロセスの確立と標準化
  2. API エコシステムに関するガバナンスの開発
  3. 管理者権限の制限と、監査とアラートの有効化

共有フローとフローフック

Apigee では、API デベロッパーがポリシーとリソースを再利用可能なグループにまとめることを可能にする、共有フローのコンセプトがサポートされています。再利用可能な機能を 1 か所に集約することにより、共有フローは整合性を保証し、開発時間を短縮して、コードをより簡単に管理するのに役立ちます。個々の API プロキシ内に共有フローを含めることも、さらに進んでフローフックに共有フローを配置して、共有フローと同じ環境にデプロイされたすべての API プロキシの共有フローロジックを自動的に実行することもできます。

API セキュリティ レポート

組織がガバナンス フレームワークを開発しようとしているため、Apigee は、以下のために API のセキュリティ属性を必要とする公開設定でオペレーション チームを支援する API セキュリティ レポートに関する機能を提供します。

  • セキュリティ ポリシーと構成要件の遵守
  • 社内外の不正行為からセンシティブ データを保護する
  • セキュリティ インシデントを先回りして特定し、診断して解決する

Apigee セキュリティ レポートは、ポリシーと構成要件を遵守し、社内外の不正行為から API を保護し、セキュリティ インシデントを迅速に特定して解決するために、オペレーション チームに高度な分析を提供します。

セキュリティ レポートによって、セキュリティ管理者は API プロキシがセキュリティについてどのように構成されているかに加え、プロキシのセキュリティに影響を及ぼす可能性があるランタイム条件を迅速に把握できます。この情報を使用して、それぞれのプロキシについて適切なレベルのセキュリティを確保できるように構成を調整します。

API Monitoring

Apigee では、セキュリティ レポート機能を補完する包括的な API Monitoring プラットフォームが提供されます。API Monitoring を使用すると、API トラフィックとパフォーマンスの問題を先回りして検出できます。Apigee API Monitoring は、Apigee Edge for Public Cloud と連携して、API のパフォーマンスをコンテキストに応じてリアルタイムで分析し、問題を迅速に診断できるよう支援し、ビジネス継続性のための修復アクションを簡単に行えるようにします。

図: Apigee API Monitoring には、問題をモニタリングし、調査して対処するための幅広いツールが用意されています。こうしたツールでは、Google Cloud Platform のクラス最高のインテリジェンス機能を活用しています。

Apigee Sense

Apigee Sense は、悪意のあるクライアントによる攻撃など、望ましくないリクエスト トラフィックから API を保護します。Apigee Sense は、API リクエスト トラフィックを分析し、望ましくないリクエストを表す可能性があるパターンを識別します。

この分析を使用すると、望ましくないリクエストを出すクライアントを特定し、そのリクエストに対して許可、ブロック、フラグ設定のアクションを取ることが可能です。Apigee Sense では、以下のようなリクエスト パターンから API を保護できます。

  • 人間の振る舞いの中に紛れた自動化された動作
  • 同じ IP から何度も続く試行
  • 異常なエラー率
  • 疑わしいクライアント リクエスト
  • データクロール
  • キー ハーベスティング
  • アクティビティ バースト
  • 地理的パターン

API8:2019 インジェクション

脅威の説明

API リクエストへのデータ（SQL、NoSQL、XML パーサー、ORM、LDAP、OS コマンド、JavaScript など）の信頼できないインジェクションによって、意図しないコマンドの実行や未承認のデータアクセスが発生する可能性があります。攻撃者は、利用可能なインジェクション ベクター（直接入力、パラメータ、統合サービスなど）を介して悪意のあるデータで API をフィードし、インタープリタに送信しようとします。攻撃者が脆弱性スキャナとファザーを使用してソースコードを簡単に確認し、こうした欠陥を見つけることができてしまいます。インジェクションが成功すると、機密性保持に影響する情報開示やデータ損失が生じる可能性があり、場合によっては DoS につながる可能性もあります。

インジェクションのエラーや攻撃を軽減するためのベスト プラクティスには、入力データ（スキーマ、タイプ、文字列パターンなど）の厳密な定義、入力検証、制限チェックの実行、ランタイムでの適用などがあります。Apigee プラットフォームでは、フィルタを使用して受信データを検証し、各入力パラメータに対して有効な値のみを許可できます。

受信 API リクエスト用のサーバーとして機能する Apigee Edge は、ペイロード構造が許容範囲内に収まっていることを確認して保証します。これは制限チェックとも呼ばれます。入力検証ルーチンで入力を変換して危険な文字シーケンスを削除し、安全な値に置き換えるように、API プロキシを構成できます。

Regular Expression Protection ポリシー

RegularExpressionProtection ポリシーでは、メッセージ（URI パス、クエリ パラメータ、ヘッダー、フォーム パラメータ、変数、XML ペイロード、JSON ペイロードなど）から情報を抽出し、その内容を事前定義済みの正規表現に対して評価します。特定の正規表現が true と評価された場合、メッセージは脅威とみなされ、拒否されます。正規表現は、文字列内のパターンを指定する一連の文字列です。正規表現を使用すると、コンテンツがプログラムでパターンについて評価されるようになります。たとえば、適切に構造化したメールアドレスを評価するために使用できます。

RegularExpressionProtection の最も一般的な使用方法は、悪意のあるコンテンツに関する JSON や XML ペイロードの評価です。

コンテンツ ベースの攻撃をすべて排除できる正規表現はなく、複数のメカニズムを組み合わせて多層防御を実現する必要があります。このセクションでは、コンテンツをブラックリストに登録するための推奨パターンをいくつか示します。

Apigee プラットフォームで利用可能な入力を検証するためのアプローチがいくつか用意されています。

コンテンツ タイプを検証する

コンテンツ タイプとは、HTTP 経由で転送され、2 つの部分からなる構造に基づいて分類されるファイルのコンテンツです。以下で説明するように、条件ロジックを使用してリクエストとレスポンスのコンテンツ タイプを検証することをおすすめします。

API セキュリティ レポート

組織がガバナンス フレームワークを開発しようとしているため、Apigee は、オペレーション チームを支援する API セキュリティ レポートに関する機能を提供し、以下のために API のセキュリティ属性を必要とする公開設定を提供することで、API を保護するために必要な公開設定を提供します。

  • セキュリティ ポリシーと構成要件の遵守を確認します。
  • 社内外の不正行為からセンシティブ データを保護します。
  • セキュリティ インシデントを積極的に特定、診断、解決します。

API9:2019 不適切なアセット管理

脅威の説明

不十分な環境管理と環境の分離により、攻撃者が安全性の低い API エンドポイントにアクセスできてしまいます。また、管理上の安全保護対策がないと、サポートが終了したリソースが不必要に露出されます。

この脅威に対処するには、Apigee の成熟した機能を活用して API ライフサイクル全体を管理して、チーム間の共同作業を可能にする包括的なガバナンス モデルを作成すると同時に、セキュリティ担当者と API デベロッパーの間での職務分掌を適用できるようにします。境界とコントロールは、次の方法で構成して管理できます。

組織、環境、リビジョン: ランタイムのコンテキストを通じて分離と安全なプロモーション プロセスを保証する仮想ガードレールと物理的なガードレール。

ロールベースのアクセス制御: API チームの必要なユーザーのみが、構成の変更とプロモーション プロセスを管理する権限を持ちます。

API ドキュメントのユーザー管理: デベロッパー ポータルで API が公開されると、ターゲット ユーザーを管理することによって、ドキュメントの公開設定を制限できます。

フローフック: API デベロッパーが変更できない特権ガードレールとして管理できるグローバルなポリシーとパターンを適用できます。

セキュリティ レポート: セキュリティ担当者は、公開された API とそのサポート構成をエンドツーエンドで可視化できます。グローバル セキュリティ ポリシーの遵守は、公開された各 API エンドポイントのリスク プロファイルに基づいて監査および評価できます。

組織と環境

Apigee の構成アーティファクト、ユーザー、機能は、特定の組織や環境にスコープを指定できます。つまり、プラットフォームには、API とそのサポート構成の周囲に配置できる事前に構築されたガードレールがあります。

組織: 組織は Apigee の最上位テナントです。トラフィック、構成、ユーザーを完全に分離できます。ガバナンスのベスト プラクティスとして、本番環境の組織と非本番環境の組織を分離することを検討してください。これにより、本番環境のデータ、ユーザー、トラフィックが下位環境と混在することを効果的に回避できます。

環境: Apigee の API は複数のデプロイ状態でプロモーションできます。各状態は実行コンテキストにリンクされます。プロモーション プロセス中は環境コンテキストが引き継がれないため、プライベート構成が権限のないユーザーに露出することはありません。

リビジョン: リビジョンを使用すると、API や個々の機能を環境を介してシームレスにプロモージョンできます。

ロールベースのアクセス制御

API9 を軽減するには、セキュリティ担当者と API デベロッパーの間で明確な職掌の定義と分散が必要です。このドキュメントで前述したように、Apigee にはロールベースのアクセス制御機能があり、カスタムロールに権限を割り当てることが可能です。この特定の脅威については、ロールのスコープを、組織、環境、またはより詳細な構成の権限ごとに制限できます。環境を通じて API のデプロイ状態を変更して、デベロッパーがグローバル セキュリティ ライブラリ（フローフック）にアクセスしたり変更したりできないように、権限を制限することをおすすめします。こうした限定的なロールにより、従来のエンドポイントと現在公開されているエンドポイントの両方を幅広く対象とするグローバル セキュリティ ポリシーへの未承諾の変更を防ぎます。

API ドキュメントのオーディエンス管理

デベロッパー ポータルは、API 戦略を成功させるための非常に重要なコンポーネントです。ホスト / エンドポイント、リソース、オペレーション、ペイロード スキーマなど、API に関連するすべてのドキュメントの包括的なインベントリを保持できます。Apigee では、API プロダクト構造を使用して API をグループ化できます。API プロダクトは、同じビジネスとセキュリティのコンテキスト（サービスプラン、ビジネス ドメイン、カテゴリ、会社階層など）に属しているリソースとオペレーションのバンドルによって定義されます。

Apigee の統合デベロッパー ポータルでは、ターゲット ユーザーを管理して、API プロダクトを公開し、公開コンテンツの公開設定を制限できます。この機能は、ビジネスとセキュリティの要件に沿ったコンテンツ セグメンテーション戦略に準拠しています。

フローフック

API のプロモーションとリリースのプロセスには、常にセキュリティ コンプライアンスと証明書プロセスを含める必要があります。適切なツールを使用する API チームは、効率性を高めるために、アジャイルなリリース サイクルを維持しながら、職務分掌を保証するガードレールを作成できる必要があります。

Apigee では、フローフックを使用してグローバル ポリシーを適用することで、セキュリティ ガバナンスの職掌を強化できます。こうしたグローバル ポリシーは、API デベロッパーが変更できない特権ガードレールとして管理できるため、デフォルトのセキュリティを適用し、特定の実行環境でデプロイされたすべての API にセキュリティ コンプライアンスを提供することによって、職務分掌を保証し、アジリティを促進します。

図: フローフックと共有フローを使用して、Apigee で特権ガードレールを構成できます。セキュリティ担当者は、セキュリティ関連のグローバル ポリシーを管理する責任を負います。こうした機能により、職務分掌が保証され、アジャイルな開発ライフサイクルが促進されます。

セキュリティ レポート

セキュリティ監査は、組織のデータやビジネスの目標を保護するためのセキュリティ ポリシーを評価、テストすることを目的としています。API は標準化された公開または非公開のインターフェースであり、包括的に保護すると同時に、セキュリティ ガバナンス モデルで監査可能である必要があります。

Apigee では、定義されたポリシーを遵守するために役立つ特別なセキュリティ レポートにアクセスでき、セキュリティ チームが包括的な分析情報に基づいてアクションを実行できるようにします。

ランタイム トラフィック: ターゲット サーバー、仮想ホスト、TLS 構成、環境ごとのトラフィックの変化などに関する API トラフィック統計情報を 1 か所に表示できます。

構成: API プロキシレベルで適用されるすべてのポリシーにおけるエンドツーエンドの可視性と、組織レベルまたはプロキシレベルでアタッチされている共有フローの適用範囲を提供する API プロキシ構成の監査機能。

ユーザー アクティビティ: プラットフォーム ユーザーが行っている機密性の高いオペレーションをトラッキングします。疑わしいアクティビティをドリルダウンすることによって分析します。

API10:2019 不十分なロギングとモニタリング

脅威の説明

ロギング、モニタリング、アラートが不十分なために進行中の攻撃が検出されないため、戦略でビジネスに影響する重大なイベントに関する分析情報を取得する必要があります。

API のイベントとロギングの管理戦略では、以下のベスト プラクティスを検討してください。

  • ログ管理ポリシー: ログの詳細度、ログレベル、ログの整合性、一元化されたリポジトリなどを標準化して管理するルールをドキュメント化して適用します。
  • イベント管理ポリシー: すべてのイベントがソースまで追跡可能であることを保証します。また、重大度とビジネスへの影響に基づいてイベントを分類できる必要があります。
  • レポートと監査: セキュリティ担当者とオペレーション関係者は、ログとイベントにリアルタイムでアクセスして対応できる必要があります。また、担当者が強化サイクルを実施して、過去のデータに基づいて検出パターンを調整できます。

Apigee には、包括的なイベントとロギングの管理戦略を作成するために必要なツールが用意されています。たとえば、次のようなものがあります。

メッセージ ロギング ポリシー: API トラフィックのトラフィック データまたはメタデータに基づいて、ログストリームを作成します。条件ロジックとメッセージ テンプレートを利用して、ストリームの詳細度を柔軟に決定できます。

Google のクラウド オペレーション スイート: Google の拡張可能なモニタリング ツールやロギングツールのすぐに使用できる統合を利用できます。

Service Callout ポリシー: イベントの送信に HTTP エンドポイントを必要とするログストリームのサポートを追加します。

アナリティクス: すぐに使用できるレポートやカスタマイズしたレポートから、過去のトラフィック メタデータにアクセスして分析します。傾向に基づいてアラートを作成して管理し、トラフィックの異常を把握します。

API Monitoring: 前述のように、このツールでは重要なイベントに基づいてトリガーできるアラート機能が提供されます。トラフィック ログをさらに分析して対処できます。