API Management を使用して OWASP API のセキュリティ脅威上位 10 を軽減するための推奨事項

  • [アーティクル]

適用対象: すべての API Management レベル

Open Web Application Security Project (OWASP) Foundation は、コミュニティ主導のオープンソース ソフトウェア プロジェクト、世界中の数百の支部、数万人のメンバー、ローカルおよびグローバルなカンファレンスの開催により、ソフトウェア セキュリティの向上に取り組んでいます。

OWASP の API Security Project では、"API の固有の脆弱性とセキュリティ リスク" を理解して軽減するための戦略とソリューションに重点を置いています。 この記事では、OWASP によって明らかにされた上位 10 件の API 脅威を、Azure API Management を使用して軽減するための推奨事項について説明します。

Note

この記事の推奨事項に従うだけでなく、API セキュリティの分析情報、推奨事項、脅威検出のために、Microsoft Defender for Cloud の機能である Defender for API を有効にできます。 API Management での Defender for API の使用の詳細

壊れたオブジェクト レベルの認可

適切なレベルの認可で保護されていない API オブジェクトは、弱いオブジェクト アクセス識別子によるデータ リークや未承認のデータ操作に対して脆弱である可能性があります。 たとえば、攻撃者は整数オブジェクト識別子を悪用する可能性があり、これを繰り返すことができます。

この脅威について詳しくは、「API1:2019 壊れたオブジェクト レベルの認可」をご覧ください

推奨事項

  • オブジェクト レベルの認可を実装するのに最適な場所は、バックエンド API 自体の内部です。 バックエンドでは、該当する場合はドメインと API に適用できるロジックを使って、要求 (またはオブジェクト) のレベルで適切な認可の決定を行うことができます。 要求者のアクセス許可と認可に応じて、特定の要求に対して生成される応答の詳細レベルが異なる場合があるシナリオについて考えます。

  • 現在の脆弱な API をバックエンドで変更できない場合は、フォールバックとして API Management を使用できます。 次に例を示します。

    • バックエンドで実装されていない場合は、カスタム ポリシーを使ってオブジェクト レベルの認可を実装します。

    • 内部の識別子が公開されないように、要求からバックエンドおよびバックエンドからクライアントに識別子をマップするカスタム ポリシーを実装します。

      このような場合のカスタム ポリシーは、送信要求ポリシーによる別のサービスの検索 (辞書など) や統合を含むポリシー式でもかまいません。

  • GraphQL のシナリオでは、authorize 要素を使って、GraphQL 検証要求ポリシーによりオブジェクト レベルの認可を適用します。

壊れたユーザー認証

認証メカニズムが正しく、またはまったく実装されていないことが多く、攻撃者は実装の欠陥を悪用してデータにアクセスできます。

この脅威の詳細: API2:2019 壊れたユーザー認証

推奨事項

ユーザーの認証と認可に API Management を使います。

  • 認証 - API Management では、次の認証方法がサポートされています。

    • 基本認証ポリシー - ユーザー名とパスワードの資格情報。

    • サブスクリプション キー - サブスクリプション キーは、基本認証と似たレベルのセキュリティを提供し、単独では不十分な場合があります。 サブスクリプション キーが侵害された場合、攻撃者はシステムに無制限にアクセスできる可能性があります。

    • クライアント証明書ポリシー - クライアント証明書を使うと、基本的な資格情報やサブスクリプション キーより安全ですが、OAuth 2.0 などのトークン ベースの承認プロトコルによって提供される柔軟性は得られません。

  • 認可 - API Management は、OAuth ID プロバイダーのメタデータ エンドポイントから取得された情報に基づいて、受信した OAuth 2.0 JWT アクセス トークンの有効性を調べるための、JWT の検証ポリシーをサポートします。 関連するトークン クレーム、対象ユーザー、有効期限をチェックするようにポリシーを構成します。 OAuth 2.0 認可と Microsoft Entra ID を使用した API の保護の詳細について理解してください。

その他の推奨事項:

  • API Management でポリシーを使用し、セキュリティを強化します。 たとえば、呼び出しレート制限は、ブルート フォース攻撃を使って資格情報を侵害する悪意のあるアクターを遅くします。

  • API では、TLS/SSL (トランスポート セキュリティ) を使って資格情報またはトークンを保護する必要があります。 資格情報とトークンは、クエリ パラメーターとしてではなく、要求ヘッダーで送信する必要があります。

  • API Management 開発者ポータルで、アカウントのセキュリティを強化するために、ID プロバイダーとして Microsoft Entra ID または Azure Active Directory B2C を構成します。 開発者ポータルでは、CAPTCHA を使ってブルート フォース攻撃が軽減されます。

過剰なデータの露出

API インターフェイスを適切に設計することは、思うほど簡単ではありません。 多くの場合、特に時間をかけて進化してきたレガシ API では、要求と応答のインターフェイスには、それを使用するアプリケーションで必要なものより多くのデータ フィールドが含まれています。

悪意のあるアクターは、(おそらく有効な要求を再現することによって) API に直接アクセスしようとするか、サーバーと API の間のトラフィックを傍受しようとする可能性があります。 API アクションと使用可能なデータを分析すると、フロントエンド アプリケーションに公開されたり使用されたりしない機密データが、攻撃者の手に渡る可能性があります。

この脅威に関する詳細情報: API3:2019 過剰なデータの露出

推奨事項

  • この脆弱性を軽減するための最善の方法は、バックエンド API で定義されている外部インターフェイスを慎重に、そして理想的にはデータの永続化とは独立して、設計することです。 それらには、API のコンシューマーで必要なフィールドのみを含める必要があります。 API を頻繁にレビューし、レガシ フィールドを非推奨にして、削除する必要があります。

    API Management では、以下を使います。

    • インターフェイスへのフィールドの追加など、非破壊的変更を適切に制御するためのリビジョン。 リビジョンと共にバックエンドでのバージョン管理の実装を使用できます。

    • インターフェイスからのフィールドの削除など、破壊的変更のためのバージョン。

  • バックエンド インターフェイスの設計を変更できず、過剰なデータが問題になる場合は、API Management の変換ポリシーを使って、応答ペイロードを書き換え、データをマスクまたはフィルター処理します。 たとえば、応答本文から不要な JSON プロパティを削除します。

  • API Management の応答の内容の検証を、XML または JSON スキーマと共に使って、ドキュメントにないプロパティや不適切な値が含まれる応答をブロックできます。 このポリシーでは、指定されたサイズを超える応答のブロックもサポートされています。

  • 状態コードの検証ポリシーを使って、API スキーマで定義されていないエラーを含む応答をブロックします。

  • ヘッダーの検証ポリシーを使って、スキーマで定義されていないヘッダーまたはスキーマでの定義に準拠していないヘッダーが含まれる応答をブロックします。 ヘッダーの設定ポリシーを使って、望ましくないヘッダーを削除します。

  • GraphQL のシナリオでは、GraphQL 要求の検証ポリシーを使って、GraphQL 要求を検証し、特定のクエリ パスへのアクセスを承認し、応答のサイズを制限します。

リソースとレート制限の欠如

レート制限がないと、データが流出したり、バックエンド サービスに対する DDoS 攻撃が成功したりして、すべてのコンシューマーが停止する可能性があります。

この脅威に関する詳細情報: API4:2019 リソースとレート制限の欠如

推奨事項

  • レート制限 (短期) とクォータ制限 (長期) のポリシーを使って、コンシューマーごとに許可される API 呼び出し数または帯域幅を制御します。

  • OpenAPI の定義で、厳密な要求オブジェクト定義とそのプロパティを定義します。 たとえば、ページング整数の最大値、文字列の maxLength および正規表現 (regex) を定義します。 API Management の内容の検証およびパラメーターの検証ポリシーを使って、それらのスキーマを適用します。

  • 内容の検証ポリシーを使って、要求の最大サイズを適用します。

  • 組み込みキャッシュを使ってパフォーマンスを最適化し、特定の操作の CPU、メモリ、ネットワーク リソースの消費を減らします。

  • API 呼び出しに対して認証を適用します (「壊れたユーザー認証」を参照)。 不正なユーザーのアクセス権を取り消します。 たとえば、サブスクリプション キーを非アクティブにしたり、呼び出し元 IP の制限ポリシーを使って IP アドレスをブロックしたり、JWT トークンから特定のユーザー クレームの要求を拒否したりします。

  • CORS ポリシーを適用し、API を通して提供されるリソースの読み込みが許可される Web サイトを制御します。 構成でアクセスが過度に許可されないように、CORS ポリシーではワイルドカード値 (*) を使わないでください。

  • バックエンド サービスの応答にかかる時間を最小限に抑えます。 バックエンド サービスで応答にかかる時間が長いほど、API Management が接続を占有する時間が長くなるため、特定の期間内に処理できる要求の数が減ります。

  • API Management は DDoS 攻撃からバックエンド サービスを保護できますが、それらの攻撃自体に対しては脆弱である可能性があります。 DDoS 攻撃からの保護を強化するには、API Management の前面にボット保護サービス (Azure Application Gateway、Azure Front Door、Azure DDoS Protection など) をデプロイします。 Azure Application Gateway または Azure Front Door で WAF を使用する場合は、Microsoft_BotManagerRuleSet_1.0 の使用を検討してください。

壊れた機能レベルの認可

異なる階層、グループ、ロールが含まれる複雑なアクセス制御ポリシーや、管理機能と通常機能の間の明確ではない分離は、認可の欠陥につながります。 これらの問題を悪用することで、攻撃者は他のユーザーのリソースや管理機能にアクセスできるようになります。

この脅威について詳しくは、「API5:2019 壊れた機能レベルの認可」をご覧ください

推奨事項

  • 既定で、API Management 内のすべての API エンドポイントをサブスクリプション キーで保護します。

  • JWT の検証ポリシーを定義し、必要なトークン クレームを適用します。 特定の操作でさらに厳密なクレームの適用が必要な場合は、それらの操作に対してのみ追加の validate-jwt ポリシーを定義します。

  • Azure 仮想ネットワークまたは Private Link を使って、インターネットから API エンドポイントを隠します。 API Management での仮想ネットワークのオプションの詳細を理解してください。

  • ワイルドカードの API 操作 (つまり、パスとして * を使用する "キャッチオール" API) は定義しないでください。 API Management では明示的に定義されたエンドポイントに対する要求のみを処理するようにし、未定義のエンドポイントへの要求は拒否します。

  • サブスクリプションを必要としないオープン製品を含む API は発行しないでください。

一括割り当て

特定のアクションについてクライアントで必要なものより多くのフィールドを API で提供した場合、攻撃者は必要以上のプロパティを挿入して、データで承認されていない操作を実行する可能性があります。 攻撃者は、要求と応答の形式または他の API を調べたり、それらを推測したりすることで、ドキュメントに書かれていないプロパティを検出する場合があります。 このような脆弱性は、厳密な型指定のプログラミング言語を使っていない場合に特に当てはまります。

この脅威に関する詳細情報: API6:2019 一括割り当て

推奨事項

  • 外部の API インターフェイスを、内部のデータ実装から切り離す必要があります。 API コントラクトをバックエンド サービスのデータ コントラクトに直接バインドしないようにします。 API の設計を頻繁にレビューし、API Management のバージョン管理を使って、レガシ プロパティを非推奨にして削除します。

  • API スキーマで XML と JSON のコントラクトを正確に定義し、内容の検証およびパラメーターの検証ポリシーを使って、ドキュメントに書かれていないプロパティを含む要求と応答をブロックします。 ドキュメントに書かれていないプロパティを含む要求をブロックすると攻撃が軽減されますが、ドキュメントに書かれていないプロパティを含む応答をブロックすると、潜在的な攻撃ベクトルをリバース エンジニアリングするのが困難になります。

  • バックエンド インターフェイスを変更できない場合は、変換ポリシーを使って要求と応答のペイロードを書き換え、バックエンド コントラクトから API コントラクトを切り離します。 たとえば、データをマスクまたはフィルター処理したり、不要な JSON プロパティを削除したりします。

セキュリティの誤構成

攻撃者は、次のようなセキュリティの誤構成の脆弱性を悪用しようとする可能性があります。

  • セキュリティの強化がない
  • 必要ないのに有効にされている機能
  • 必要ないのにインターネットに開かれているネットワーク接続
  • 脆弱なプロトコルまたは暗号の使用
  • システムに不正アクセスできる可能性があるその他の設定またはエンドポイント

この脅威に関する詳細情報: API7:2019 セキュリティの誤構成

推奨事項

  • ゲートウェイ TLS を正しく構成します。 脆弱なプロトコル (TLS 1.0、1.1 など) や暗号を使わないでください。

  • HTTPS や WSS プロトコルなど、暗号化されたトラフィックのみを受け入れるように API を構成します。

  • API Management をプライベート エンドポイントの内側にデプロイするか、内部モードでデプロイされた仮想ネットワークにアタッチすることを検討します。 内部ネットワークでは、プライベート ネットワーク内 (ファイアウォールまたはネットワーク セキュリティ グループ経由) およびインターネット (リバース プロキシ経由) からアクセスを制御できます。

  • Azure API Management のポリシーを使います。

    • 常に <base> タグを使って親ポリシーを継承します。

    • OAuth 2.0 を使うときは、JWT の検証ポリシーを構成してテストし、バックエンドに到達する前に JWT トークンの存在と有効性をチェックします。 トークンの有効期限、トークンの署名、発行者を自動的にチェックします。 ポリシーの設定を通して、クレーム、対象ユーザー、トークンの有効期限、トークンの署名を適用します。

    • CORS ポリシーを構成します。構成オプションにワイルドカード * を使わないでください。 代わりに、許可する値を明示的に列挙します。

    • 運用環境では検証ポリシーを prevent に設定して、JSON と XML のスキーマ、ヘッダー、クエリ パラメーター、状態コードを検証し、要求または応答の最大サイズを適用します。

    • API Management がネットワーク境界の外側にある場合でも、呼び出し元 IP の制限ポリシーを使ってクライアント IP を検証できます。 ブロックリストではなく、許可リストを使うようにします。

    • 呼び出し元と API Management の間でクライアント証明書を使う場合は、クライアント証明書の検証ポリシーを使います。 属性 validate-revocation、validate-trust、validate-not-before、validate-not-after がすべて true に設定されていることを確認します。

      • クライアント証明書 (相互 TLS) は、API Management とバックエンドの間に適用することもできます。 バックエンドでは、次のようにする必要があります。

        • 認可資格情報を構成します

        • 該当する場合は、証明書チェーンを検証します

        • 該当する場合は、証明書名を検証します

  • GraphQL のシナリオでは、GraphQL 要求の検証ポリシーを使います。 authorization 要素と max-size および max-depth 属性が設定されていることを確認します。

  • ポリシー ファイルまたはソース管理にシークレットを格納しないでください。 常に、API Management の名前付きの値を使うか、実行時にカスタム ポリシー式を使ってシークレットをフェッチします。

    • 名前付きの値は、Key Vault と統合するか、"secret" とマークすることによって API Management 内で暗号化する必要があります。 プレーンテキストの名前付きの値にシークレットを格納しないでください。

  • サブスクリプションが必要な製品を介して API を発行します。 サブスクリプションを必要としないオープン製品は使わないでください。

  • Key Vault の統合を使って、すべての証明書を管理します。これにより、証明書の管理が一元化され、証明書の更新や失効などの運用管理タスクが容易になります。

  • セルフホステッド ゲートウェイを使う場合は、イメージを最新バージョンに定期的に更新するプロセスがあることを確認します。

  • バックエンド サービスをバックエンド エンティティとして表します。 必要に応じて、認可資格情報、証明書チェーンの検証、証明書名の検証を構成します。

  • 開発者ポータルを使うとき:

    • 開発者ポータルをセルフホストする場合は、セルフホステッド ポータルを最新バージョンに定期的に更新するプロセスがあることを確認します。 既定のマネージド バージョンの更新は自動的に行われます。

    • ユーザーのサインアップとサインインには、Microsoft Entra ID または Azure Active Directory B2C を使います。 セキュリティが弱い既定のユーザー名とパスワードによる認証を無効にします。

    • ユーザー グループを製品に割り当てて、ポータルでの API の可視性を制御します。

  • Azure Policy を使って、API Management のリソース レベルの構成とロールベースのアクセス制御 (RBAC) のアクセス許可を適用し、リソースへのアクセスを制御します。 すべてのユーザーに必要最低限の特権を付与します。

  • 開発環境の外側では DevOps プロセスとコードとしてのインフラストラクチャのアプローチを使って、API Management の内容と構成の変更の整合性を確保し、人的エラーを最小限に抑えます。

  • 非推奨の機能は使わないでください。

インジェクション

ユーザー データを受け入れるすべてのエンドポイントは、インジェクションの悪用に対して脆弱である可能性があります。 次はその例ですが、これらだけではありません。

  • コマンド インジェクションでは、悪意のあるアクターが API 要求を変更し、API をホストしているオペレーティング システムでコマンドを実行しようとします

  • SQL インジェクションでは、悪意のあるアクターが API 要求を変更し、API が依存するデータベースに対してコマンドやクエリを実行しようとします

この脅威に関する詳細情報: API8:2019 インジェクション

推奨事項

  • 最新の Web アプリケーション ファイアウォール (WAF) ポリシーでは、多くの一般的なインジェクション脆弱性がカバーされています。 API Management には組み込みの WAF コンポーネントはありませんが、API Management インスタンスの上流 (前) に WAF をデプロイすることを強くお勧めします。 たとえば、Azure Application Gateway や Azure Front Door を使います。

    重要

    悪意のあるアクターが WAF をホストしているゲートウェイをバイパスして、API Management ゲートウェイまたはバックエンド API 自体に直接接続できないようにします。 可能な軽減策としては、ネットワーク ACL、API Management ポリシーを用いたクライアント IP によるインバウンド トラフィックの制限、必要のないパブリック アクセスの削除、クライアント証明書認証 (相互 TLS または mTLS とも呼ばれます) などがあります。

  • 必要に応じて、スキーマとパラメーターの検証ポリシーを使って、バックエンド API サービスに到達する前の要求をさらに制約し、検証します。

    API の定義で提供されるスキーマでは、脆弱なフィールドに正規表現パターン制約を適用する必要があります。 各正規表現をテストし、フィールドの制約が一般的なインジェクションの試みを軽減するのに十分であることを確認する必要があります。

不適切な資産管理

不適切な資産管理に関連する脆弱性には、次のようなものがあります。

  • 適切な API ドキュメントまたは所有権情報がない

  • 古い API バージョンの数が多すぎるため、セキュリティ修正プログラムが見つからない可能性がある

この脅威に関する詳細情報: API9:2019 不適切な資産管理

推奨事項

  • REST API をインポートするソースとして、明確に定義された OpenAPI 仕様を使います。 この仕様では、自己文書化メタデータを含む API 定義のカプセル化が許可されています。

    • 正確なパス、データ スキーマ、ヘッダー、クエリ パラメーター、状態コードで API インターフェイスを使います。 ワイルドカード操作は避けます。 各 API と操作の説明を提供し、連絡先とライセンスの情報を含めます。

    • ビジネス目標に直接関係のないエンドポイントは避けます。 攻撃対象領域が不必要に増え、API の発展が困難になります。

  • API Management のリビジョンとバージョンを使って、API エンドポイントを管理および制御します。 強力なバックエンド バージョン管理戦略を使用し、サポートされる API バージョンの最大数までコミットします (たとえば、2 つまたは 3 つ前のバージョン)。 古く、多くの場合安全性が低い API バージョンは、速やかに非推奨にして、最終的に削除することを計画します。

  • 環境 (開発、テスト、運用など) ごとに API Management のインスタンスを使います。 各 API Management インスタンスが同じ環境内の依存関係に接続されていることを確認します。 たとえば、テスト環境では、テスト API Management リソースは、テスト Azure Key Vault リソースとバックエンド サービスのテスト バージョンに接続する必要があります。 DevOps の自動化とコードとしてのインフラストラクチャのプラクティスを使うと、環境間の一貫性と精度を維持し、人的エラーを減らすのに役立ちます。

  • タグを使って API と製品を整理し、発行用にそれらをグループ化します。

  • 組み込みの開発者ポータルを使って使用するための API を公開します。 API のドキュメントが最新であることを確認します。

  • ドキュメントに書かれていない API またはアンマネージド API を検出し、より適切な制御のために API Management を通じて公開します。

不十分なログと監視

不十分なログと監視が、インシデント対応との統合の欠如または不良と組み合わさると、攻撃者はシステムをさらに攻撃し、永続化を維持し、より多くのシステムにピボットしてデータを改ざんし、データを抽出または破壊することができます。 ほとんどの侵害調査では、侵害を検出するまでの時間は 200 日を超え、通常は内部のプロセスや監視ではなく外部の関係者によって検出されることが示されています。

この脅威に関する詳細情報: API10:2019 不十分なログと監視

推奨事項

次のステップ

各項目の詳細情報