次の方法で共有

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

  • [アーティクル]

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

Note

この記事は、2023 年の最新の OWASP API セキュリティ脅威上位 10 のリストを反映するように更新されました。

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

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

API Management には API セキュリティに関する包括的な制御が用意されていますが、その他の Microsoft サービスが、OWASP API の脅威を検出または保護するための補完的な機能を提供します。

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

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

この脅威に関する詳細情報: API1:2023 壊れたオブジェクト レベルの認可

推奨事項

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

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

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

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

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

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

壊れた認証

サイトまたは API の認証メカニズムは、匿名ユーザーに対して開かれているため、特に脆弱です。 パスワードの忘れやパスワードのリセットのフローなど、認証に必要な資産とエンドポイントは、悪用を防ぐために保護する必要があります。

この脅威に関する詳細情報: API2:2023 壊れた認証

推奨事項

  • Microsoft Entra を使って API 認証を実装します。 Microsoft Entra は、保護され、回復力があり、地理的に分散されたログイン エンドポイントを自動的に提供します。 validate-azure-ad-token ポリシーを使用して、受信 API 要求で Microsoft Entra トークンを検証します。
  • 認証が必要な場合、API Management では、OAuth 2 トークンの検証、基本認証、クライアント証明書、および API キー がサポートされます。
    • 認証方法の適切な構成を確認します。 たとえば、validate-jwt ポリシーを使用して OAuth2 トークンを検証する場合、require-expiration-time と require-signed-tokens を true に設定します。
  • レート制限を使用して、ブルート フォース攻撃の有効性を低下させることができます。
  • クライアント IP フィルタリングを使用して、攻撃の対象となる領域を減らすことができます。 ネットワーク セキュリティ グループは、API Management と統合された仮想ネットワークに適用できます。
  • 可能であれば、セキュリティで保護されたプロトコルやマネージド ID または資格情報マネージャーを使用して API Management からバックエンドに対して認証しします。
  • API Management への受信要求やバックエンドへの送信要求の URL ではなく、トークンまたはキーがヘッダーで渡されていることを確認します。
  • Microsoft Entra を使用して API Management 開発者ポータルへのアクセスをセキュリティで保護します。

壊れたオブジェクト プロパティ レベルの認可

API インターフェイスを適切に設計することは、思うほど簡単ではありません。 多くの場合、特に時間をかけて進化してきたレガシ API では、要求と応答のインターフェイスには、それを使用するアプリケーションで必要なものより多くのデータ フィールドが含まれ、データ インジェクション攻撃が可能になります。 また、攻撃者が、ドキュメントに記載されていないインターフェイスを検出する可能性もあります。 これらの脆弱性により、機密データが攻撃者の手に渡る可能性があります。

この脅威に関する詳細情報: API3:2023 壊れたオブジェクト プロパティ レベルの認可

推奨事項

  • この脆弱性を軽減するための最善の方法は、バックエンド API で定義されている外部インターフェイスを慎重に、そして理想的にはデータの永続化とは独立して、設計することです。 それらには、API のコンシューマーで必要なフィールドのみを含める必要があります。 API を頻繁にレビューし、レガシ フィールドを非推奨にして、削除する必要があります。
  • API Management で、リビジョンを使用して、インターフェイスへのフィールドの追加など非破壊的変更を適切に制御し、バージョンを使用して破壊的変更を実装します。 また、バックエンド インターフェイスのバージョン管理も行う必要があります。これは通常、コンシューマー向け API とは異なるライフサイクルがあります。
  • 外部の API インターフェイスを、内部のデータ実装から切り離します。 API コントラクトをバックエンド サービスのデータ コントラクトに直接バインドしないようにします。
  • バックエンド インターフェイスの設計を変更できず、過剰なデータが問題になる場合は、API Management の変換ポリシーを使って、応答ペイロードを書き換え、データをマスクまたはフィルター処理します。 API Management の内容の検証を、XML または JSON スキーマと共に使って、ドキュメントにないプロパティや不適切な値が含まれる応答をブロックできます。 たとえば、応答本文から不要な JSON プロパティを削除します。 ドキュメントに書かれていないプロパティを含む要求をブロックすると攻撃が軽減されますが、ドキュメントに書かれていないプロパティを含む応答をブロックすると、潜在的な攻撃ベクトルをリバース エンジニアリングするのが困難になります。 validate-content ポリシーでは、指定されたサイズを超える応答のブロックもサポートされています。
  • validate-status-code ポリシーを使って、API スキーマで定義されていないエラーを含む応答をブロックします。
  • validate-headers ポリシーを使って、スキーマで定義されていないヘッダーまたはスキーマでの定義に準拠していないヘッダーが含まれる応答をブロックします。 set-header ポリシーを使って、望ましくないヘッダーを削除します。
  • GraphQL のシナリオでは、validate-graphql-request ポリシーを使って、GraphQL 要求を検証し、特定のクエリ パスへのアクセスを承認し、応答のサイズを制限します。

無制限のリソース使用量

API では、メモリや CPU などのリソースを実行する必要があり、運用コストを表すダウンストリーム統合 (pay-per-request サービスなど) が含まれる場合があります。 制限を適用すると、リソースの過剰な消費から API を保護するのに役立ちます。

この脅威に関する詳細情報: API4:2023 無制限のリソース使用量

推奨事項

  • rate-limit-by-key または rate-limit ポリシーを使用して、短い時間枠でスロットリングを適用します。 パスワードのリセット、サインイン、サインアップ操作、または重要なリソースを消費するエンドポイントなど、機密性の高いエンドポイントにより厳密なレート制限ポリシーを適用します。
  • quota-by-key または quota-limit ポリシーを使用して、長い期間に許可される API 呼び出しまたは帯域幅の数を制御します。
  • 組み込みキャッシュを使ってパフォーマンスを最適化し、特定の操作の CPU、メモリ、ネットワーク リソースの消費を減らします。
  • 検証ポリシーを適用します。
    • validate-content ポリシーの max-size 属性を使用して、要求と応答の最大サイズを適用します
    • API 仕様で、スキーマとプロパティ (文字列の長さや配列の最大サイズなど) を定義します。 validate-content、validate-parameters、および validate-headers ポリシーを使用して、要求と応答にこれらのスキーマを適用します。
    • GraphQL API に対して validate-graphql-request ポリシーを使用し、max-depth および max-size パラメーターを構成します。
    • ユーザーによるデータの過剰な消費に対するアラートを Azure Monitor で構成します。
  • 生成 AI API の場合:
  • バックエンド サービスの応答にかかる時間を最小限に抑えます。 バックエンド サービスで応答にかかる時間が長いほど、API Management が接続を占有する時間が長くなるため、特定の期間内に処理できる要求の数が減ります。
    • forward-request ポリシーで timeout を定義し、許容できる最も短い値を目指します。
    • limit-concurrency ポリシーを使って、並列バックエンド接続の数を制限 します。
  • CORS ポリシーを適用し、API を通して提供されるリソースの読み込みが許可される Web サイトを制御します。 構成でアクセスが過度に許可されないように、CORS ポリシーではワイルドカード値 (*) を使わないでください。
  • Azure には、分散型サービス拒否 (DDoS) 攻撃に対するプラットフォーム レベルの保護と強化された保護の両方がありますが、API のアプリケーション (レイヤー 7) 保護は、API Management の前にボット保護サービスをデプロイすることで強化できます。たとえば、Azure Application Gateway、Azure Front Door、Azure DDoS Protection などです。 Azure Application Gateway または Azure Front Door で Web アプリケーション ファイアウォール (WAF) を使用する場合は、Microsoft_BotManagerRuleSet_1.0 の使用を検討してください。

壊れた機能レベルの認可

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

この脅威に関する詳細情報: API5:2023 壊れた機能レベルの認可

推奨事項

  • 既定で、API Management 内のすべての API エンドポイントをサブスクリプション キーまたは all-APIs-level 承認ポリシーで保護します。 該当する場合は、特定の API または API 操作に対して他の承認ポリシーを定義します。
  • ポリシーを使用して OAuth トークンを検証します。
    • validate-azure-ad-token ポリシーを使用して、Microsoft Entra トークンを検証します。 必要なすべての要求を指定し、該当する場合は、承認済みのアプリケーションを指定します。
    • Microsoft Entra によって発行されていないトークンを検証するには、validate-jwt ポリシーを定義し、必要なトークン要求を適用します。 可能であれば、有効期限を要求します。
    • 可能であれば、暗号化されたトークンを使用するか、アクセスのための特定のアプリケーションを一覧表示します。
    • 権限がないために拒否された要求を監視および確認します。
  • Azure 仮想ネットワークまたは Private Link を使って、インターネットから API エンドポイントを隠します。 API Management での仮想ネットワークのオプションの詳細を理解してください。
  • ワイルドカードの API 操作 (つまり、パスとして *  を使用する "キャッチオール" API) は定義しないでください。 API Management では明示的に定義されたエンドポイントに対する要求のみを処理するようにし、未定義のエンドポイントへの要求は拒否します。
  • サブスクリプションを必要としないオープン製品を含む API は発行しないでください。
  • クライアント IP がわかっている場合は、ip-filter ポリシーを使用して、承認された IP アドレスからのトラフィックのみを許可します。
  • validate-client-certificate ポリシーを使用して、クライアントから API Management インスタンスに提示された証明書が、指定された検証規則と要求に一致することを強制します。

機密性の高いビジネス フローへの無制限のアクセス

API は、それを使用するアプリケーションに幅広い機能を公開できます。 API 作成者は、API が提供するビジネス フローと、関連付けられている機密度を理解することが重要です。 機密性の高いフローを公開する API が適切な保護を実装していない場合、ビジネスに対するリスクが高くなります。

この脅威に関する詳細情報: API6:2023 機密性の高いビジネス フローへの無制限のアクセス

推奨事項

  • クライアントの指紋に基づいてアクセスを減らすか、ブロックします。 たとえば、return-response ポリシーを choose ポリシーと一緒に使用して、User-Agent ヘッダーまたは他のヘッダーの整合性に基づいてヘッドレス ブラウザーからのトラフィックをブロックします。
  • validate-parameters ポリシーを使用して、要求ヘッダーが API 仕様と一致することを強制します。
  • ip-filter ポリシーを使用して、既知の IP アドレスからの要求のみを許可するか、特定の IP からのアクセスを拒否します。
  • プライベート ネットワーク機能を使用して、内部 API への外部接続を制限します。
  • rate-limit-by-key ポリシーを使用して、ユーザー ID、IP アドレス、または別の値に基づいて API 使用の急増を制限します。
  • API Management を Azure Application Gateway または Azure DDoS Protection サービスと共に使って、ボット トラフィックを検出し、ブロックします。

サーバー側のリクエスト フォージェリ

サーバー側のリクエスト フォージェリの脆弱性が生じる可能性があるのは、API が適切な検証チェックなしに API 呼び出し元によって渡された URL の値に基づいてダウンストリーム リソースをフェッチする場合です。

この脅威に関する詳細情報: API7:2023 サーバー側のリクエスト フォージェリ

推奨事項

  • 可能であれば、たとえば、バックエンド URL、send-request ポリシー、または rewrite-url ポリシーのパラメーターとして、クライアント ペイロードで提供される URL を使用しないでください。
  • API Management またはバックエンド サービスで、ビジネス ロジックの要求ペイロードで提供される URL を使用する場合は、API Management のポリシー (choose ポリシーやポリシー式など) を使用して、ホスト名、ポート、メディアの種類、またはその他の属性の限定的な一覧を定義して適用します。
  • forward-request および send-request ポリシーで timeout 属性を定義します。
  • 検証ポリシーを使用して、要求および応答のデータを検証してサニタイズします。 必要に応じて、set-body ポリシーを使用して応答を処理し、生データが返されないようにします。
  • プライベート ネットワークを使用して接続を制限します。 たとえば、API をパブリックにする必要がない場合は、インターネットからの接続を制限して攻撃の対象となる領域を減らします。

セキュリティの誤構成

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

  • セキュリティの強化がない
  • 必要ないのに有効にされている機能
  • 必要ないのにインターネットに開かれているネットワーク接続
  • 脆弱なプロトコルまたは暗号の使用

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

推奨事項

  • ゲートウェイ TLS を正しく構成します。 脆弱なプロトコル (TLS 1.0、1.1 など) や暗号を使わないでください。
  • HTTPS や WSS プロトコルなど、暗号化されたトラフィックのみを受け入れるように API を構成します。 Azure Policy を使用して、この設定を監査して適用できます。
  • API Management をプライベート エンドポイントの内側にデプロイするか、内部モードでデプロイされた仮想ネットワークにアタッチすることを検討します。 内部ネットワークでは、プライベート ネットワーク内 (ファイアウォールまたはネットワーク セキュリティ グループ経由) およびインターネット (リバース プロキシ経由) からアクセスを制御できます。
  • Azure API Management のポリシーを使います。
    • 常に <base> タグを使って親ポリシーを継承します。
    • OAuth 2.0 を使うときは、validate-jwt ポリシーを構成してテストし、バックエンドに到達する前にトークンの存在と有効性をチェックします。 トークンの有効期限、トークンの署名、発行者を自動的にチェックします。 ポリシーの設定を通して、クレーム、対象ユーザー、トークンの有効期限、トークンの署名を適用します。 Microsoft Entra を使用する場合、validate-azure-ad-token ポリシーを使用すると、セキュリティ トークンをより包括的かつ簡単に検証できます。
    • CORS ポリシーを構成します。構成オプションにワイルドカード * を使わないでください。 代わりに、許可する値を明示的に列挙します。
    • 運用環境で検証ポリシーを設定して、JSON と XML のスキーマ、ヘッダー、クエリ パラメーター、状態コードを検証し、要求または応答の最大サイズを適用します。
    • API Management がネットワーク境界の外側にある場合でも、呼び出し元 IP の制限ポリシーを使ってクライアント IP を検証できます。 ブロックリストではなく、許可リストを使うようにします。
    • 呼び出し元と API Management の間でクライアント証明書を使う場合は、validate-client-certificate ポリシーを使います。 属性 validate-revocation、validate-trust、validate-not-before、validate-not-after がすべて true に設定されていることを確認します。
  • クライアント証明書 (相互 TLS) は、API Management とバックエンドの間に適用することもできます。 バックエンドでは、次のようにする必要があります。
    • 認可資格情報を構成します
    • 該当する場合は、証明書チェーンを検証します
    • 該当する場合は、証明書名を検証します
    • GraphQL のシナリオでは、validate-graphQL-request ポリシーを使います。 authorization 要素と max-size および max-depth 属性が設定されていることを確認します。
  • ポリシー ファイルまたはソース管理にシークレットを格納しないでください。 常に、API Management の名前付きの値を使うか、実行時にカスタム ポリシー式を使ってシークレットをフェッチします。 名前付きの値は、Azure Key Vault と統合するか、"secret" とマークすることによって API Management 内で暗号化する必要があります。 プレーンテキストの名前付きの値にシークレットを格納しないでください。
  • サブスクリプションが必要な製品を介して API を発行します。 サブスクリプションを必要としないオープン製品は使わないでください。
  • すべての製品がサブスクリプション キーを必要とするように構成されている場合でも、API にサブスクリプション キーが必要であることを確認します。 詳細情報
  • すべての製品に対してサブスクリプションの承認を要求し、すべてのサブスクリプション要求を慎重に確認します。
  • Key Vault の統合を使用して、すべての証明書を管理します。 これにより、証明書の管理が一元化され、証明書の更新や失効などの運用管理タスクが容易になります。 マネージド ID を使用して、キー コンテナーに対して認証します。
  • セルフホステッド ゲートウェイを使う場合は、イメージを最新バージョンに定期的に更新するプロセスがあることを確認します。
  • バックエンド サービスをバックエンド エンティティとして表します。 必要に応じて、認可資格情報、証明書チェーンの検証、証明書名の検証を構成します。
  • 可能であれば、資格情報マネージャーまたはマネージド ID を使用して、バックエンド サービスに対して認証します。
  • 開発者ポータルを使うとき:
    • 開発者ポータルをセルフホストする場合は、セルフホステッド ポータルを最新バージョンに定期的に更新するプロセスがあることを確認します。 既定のマネージド バージョンの更新は自動的に行われます。
    • ユーザーのサインアップとサインインには、Microsoft Entra ID または Azure Active Directory B2C を使います。 セキュリティが弱い既定のユーザー名とパスワードによる認証を無効にします。
    • ユーザー グループを製品に割り当てて、ポータルでの API の可視性を制御します。
  • Azure Policy を使って、API Management のリソース レベルの構成とロールベースのアクセス制御 (RBAC) のアクセス許可を適用し、リソースへのアクセスを制御します。 すべてのユーザーに必要最低限の特権を付与します。
  • 開発環境の外側では DevOps プロセスとコードとしてのインフラストラクチャのアプローチを使って、API Management の内容と構成の変更の整合性を確保し、人的エラーを最小限に抑えます。
  • 非推奨の機能は使わないでください。

不適切なインベントリ管理

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

  • 適切な API ドキュメントまたは所有権情報がない
  • 古い API バージョンの数が多すぎるため、セキュリティ修正プログラムが見つからない可能性がある

この脅威に関する詳細情報: API9:2023 不適切なインベントリ管理

推奨事項

  • REST API をインポートするソースとして、明確に定義された OpenAPI 仕様を使います。 この仕様では、自己文書化メタデータを含む API 定義のカプセル化が許可されています。
  • 正確なパス、データ スキーマ、ヘッダー、クエリ パラメーター、状態コードで API インターフェイスを使います。 ワイルドカード操作は避けます。 各 API と操作の説明を提供し、連絡先とライセンスの情報を含めます。
  • ビジネス目標に直接関係のないエンドポイントは避けます。 攻撃対象領域が不必要に増え、API の発展が困難になります。
  • API Management でリビジョンとバージョンを使用して、API の変更を管理します。 強力なバックエンド バージョン管理戦略を使用し、サポートされる API バージョンの最大数までコミットします (たとえば、2 つまたは 3 つ前のバージョン)。 古く、多くの場合安全性が低い API バージョンは、速やかに非推奨にして、最終的に削除することを計画します。 使用可能なすべての API バージョンにわたってセキュリティ制御が実装されていることを確認します。
  • 異なる API Management サービスを使用して、環境 (開発、テスト、運用など) を区別します。 各 API Management サービスが同じ環境内の依存関係に接続されていることを確認します。 たとえば、テスト環境では、テスト API Management リソースは、テスト Azure Key Vault リソースとバックエンド サービスのテスト バージョンに接続する必要があります。 DevOps の自動化とコードとしてのインフラストラクチャのプラクティスを使うと、環境間の一貫性と精度を維持し、人的エラーを減らすのに役立ちます。
  • ワークスペースを使用して、API と関連リソースに対する管理アクセス許可を分離します。
  • タグを使って API と製品を整理し、発行用にそれらをグループ化します。
  • 開発者ポータルを使って使用するための API を公開します。 API のドキュメントが最新であることを確認します。
  • ドキュメントに書かれていない API またはアンマネージド API を検出し、より適切な制御のために API Management を通じて公開します。
  • Azure API Center を使用して、API が Azure API Management で管理されていない場合でも、API、バージョン、デプロイの包括的で一元的なインベントリを維持します。

API の安全でない使用

ダウンストリーム統合により取得されるリソースは、呼び出し元またはエンド ユーザーからの API 入力よりも信頼性が高い傾向があります。 適切なサニタイズとセキュリティ標準が適用されていない場合、統合が信頼できるサービスから提供される場合でも、API は脆弱になる可能性があります。

この脅威に関する詳細情報: API10:2023 API の安全でない使用

推奨事項

  • バックエンド API が統合するダウンストリームの依存関係のファサードとして機能するように API Management を使用することを検討してください。
  • ダウンストリームの依存関係が API Management で導入される場合、または API Management で send-request ポリシーを使用してダウンストリームの依存関係が使用される場合は、このドキュメントの他のセクションの推奨事項を使用して、次のような安全で制御された使用を確保します。
    • セキュリティで保護されたトランスポートが有効になっていることを確認し、TLS/SSL 構成を適用します
    • 可能であれば、資格情報マネージャーまたはマネージド ID を使用して認証します
    • rate-limit-by-key および quota-limit-by-key ポリシーを使用して使用を制御します
    • validate-content および validate-header ポリシーを使用して、API 仕様に準拠していない応答をログに記録、またはブロックします
    • たとえば、不要な情報や機密情報を削除するために、set-body ポリシーを使用して応答を変換します
    • タイムアウトを構成し、コンカレンシーを制限します

関連するコンテンツ

各項目の詳細情報