api-security-design

API セキュリティ設計

安全な API 設計により、バックエンドサービスとデータを不正利用や、OWASP API Security Top 10 のリスク（オブジェクトレベル認可の不備（BOLA）、認証の不備、機能レベル認可の不備（BFLA）、リソース消費の制限不足、サーバーサイドリクエストフォージェリなど）から保護します。Azure では、Azure API Management (APIM) が主要なポリシー適用ポイントであり、WAF、Entra ID、Key Vault、Defender for APIs と連携します。

使用するタイミング

API のセキュリティを設計またはレビューするときに使用します。特に、外部公開 API、パートナー向け API、機密データを扱う API の公開前、または定期的な設計レビューの一環として使用します。

このスキルを使用しないでください：

• 一般的なアプリケーションまたは Web アプリのセキュリティ（security-architecture、threat-modelling を使用）
• API の実行時検出とポスチャのみに関する場合（defender-for-apis を使用）
• フロントエンド／SPA の設計（Web アプリのセキュリティガイダンスを使用）

OWASP API リスクごとに適切なコントロールを選択する

OWASP API Top 10 のリスク	主なコントロール	適用箇所
API1 - BOLA（オブジェクトレベル認可）	オブジェクトごとの認可チェック	バックエンドコード（ゲートウェイでは完全に対応できません）
API2 - 認証の不備	Entra ID による OAuth 2.0／OIDC、validate-jwt	ゲートウェイ + Entra
API3 - オブジェクトプロパティ認可の不備	スキーマ検証 + レスポンスフィルタリング	バックエンド + ゲートウェイ
API4 - リソース消費の制限不足	レート制限、クォータ、ペイロードサイズ、タイムアウト	ゲートウェイ（APIM）
API5 - BFLA（機能レベル認可）	各操作でのロール／スコープチェック	バックエンドコード
API6 - 機密性の高いフローへの無制限のアクセス	ステップアップ認証、不正利用対策ルール	Entra + ゲートウェイ
API7 - SSRF	アウトバウンド URL の許可リスト + エグレス制御	バックエンド + ネットワーク
API8 - セキュリティ設定ミス	IaC + APIM ポリシーテンプレート	DevOps + ゲートウェイ
API9 - 不適切なインベントリ管理	API カタログ + APIM でのライフサイクル管理	APIM + ガバナンス
API10 - サードパーティ API の安全でない利用	上流レスポンスの検証、タイムアウト	バックエンド

経験則： BOLA と BFLA は API のリスクの中でも特に重要な 2 つであり、ゲートウェイだけでは完全に解決できません。バックエンドでオブジェクトごと、機能ごとの認可を適用する必要があります。ゲートウェイは必要ですが、それだけでは不十分です。

アプローチ

1. Entra ID によるゲートウェイでの認証 - Microsoft Entra ID を介した OAuth 2.0 / OpenID Connect を必須にし、APIM で validate-jwt ポリシーを使って JWT（発行者、対象者、署名キー、有効期限、必須クレーム）を検証します。唯一の制御手段として静的 API キーを使うことは避け、使用する場合は頻繁にローテーションしてください。 確認方法：無効または期限切れの JWT を使ったリクエストがゲートウェイで拒否され、ログに拒否理由が記録されること。
2. バックエンドでの認可 - JWT で最小権限のスコープ／ロールを適用し、バックエンドで呼び出しのたびにオブジェクトレベルおよび機能レベルの認可を確認します。ゲートウェイで分かるのは呼び出し元だけです。呼び出し元がオブジェクトの所有者かどうかを把握しているのはバックエンドだけです。 確認方法：ユーザー A のテスト用 JWT でユーザー B のデータをリクエストすると、ゲートウェイが呼び出しを許可しても 403 が返されること。
3. ゲートウェイの保護機能を適用（APIM） - サブスクリプション／IP／ID ごとのレート制限とクォータのポリシー、許可リスト用の IP フィルタリング、OpenAPI スキーマに対するリクエストとレスポンスの検証、ペイロードサイズの上限、タイムアウト、既知のオリジンに限定した CORS を設定します。 確認方法：レート制限を超えるリクエストには 429 が返されること。サイズ超過のペイロードが拒否されること。OpenAPI スキーマに一致しないリクエストが拒否されること。
4. 通信とシークレット - すべてのエンドポイントで TLS 1.2 以上を必須にし、脅威モデルで必要な場合はバックエンドに mTLS を使用します。また、すべてのシークレット（バックエンドの認証情報、署名キー）を Azure Key Vault に保存し、マネージド ID を使って APIM の名前付き値から参照します。ポリシー XML にシークレットを含めず、コードにもシークレットを含めないでください。 確認方法：APIM ポリシーやソースリポジトリにシークレットのリテラルがないこと。APIM がマネージド ID を使って、実行時に Key Vault の参照情報を取得すること。
5. 公開範囲とネットワーク制御 - パブリック API の前段に WAF（Application Gateway または Azure Front Door）を配置し、L7 保護（OWASP Core Rule Set）を適用します。また、Private Endpoints を使用してバックエンドをパブリックインターネットから隔離します。内部 API にパブリック経路を設けないでください。 確認方法：パブリック IP のポートスキャンで到達できるのが WAF／APIM のみで、バックエンドにはインターネットから直接到達できないこと。
6. 入力を厳格に検証 - ゲートウェイで OpenAPI スキーマに照らして検証し、予期しないフィールド、サイズ超過のペイロード、不正な型を拒否します。バックエンドのコードでもビジネス上の不変条件を再検証し、ゲートウェイだけを決して信頼しないでください。 確認方法：API のファジングテストで 5xx ではなく 4xx が返されること。どの入力クラスによってもクラッシュやスタックトレースの漏えいが発生しないこと。
7. 実行時の脅威検出を追加 - APIM を前段に配置した API で Microsoft Defender for APIs を有効にし、実行時の脅威（不審なアクセスパターン、機密データの露出、偵察、OWASP に準拠した攻撃）を検出します。 確認方法：意図的に不正な操作を行うテストクライアントが、Defender for APIs のアラートを発生させること。
8. API のカタログ化とライフサイクル管理 - APIM（または使用しているゲートウェイ）ですべての API を棚卸しし、機密性と所有者に基づいてタグ付けし、廃止予定のバージョンを計画に沿って終了します。シャドー API（文書化されず、監視もされていない API）は、最も一般的な侵害経路です。

ガードレール

• BOLA/BFLA は API の最重要リスクです — オブジェクトごと、関数ごとの認可をサーバー側で適用する必要があります。ゲートウェイから呼び出し元は確認できますが、アクセス可能なオブジェクトまでは把握できません。
• ゲートウェイだけに頼らないでください — ゲートウェイとバックエンドの両方で多層防御を実施します。単一の層では障害が発生しますが、多層の制御を設ければ、ある箇所の設定ミスがそのまま侵害につながることはありません。
• スキーマに照らして入力を検証し、想定外のフィールドや過大なペイロードは拒否します。最も一般的な API の CVE は「想定していなかったものを受け入れてしまった」ことが原因です。
• 静的 API キーだけを認証手段にしないでください。 OAuth 2.0 + Entra ID に移行します。パートナーとの互換性のためにキーを残す場合は、頻繁にローテーションし、厳格にレート制限を設定します。
• API インベントリを資産として扱ってください — シャドー API は管理されていないリスクです。検出とカタログ化は API セキュリティの一部であり、単なる運用ではありません。
• バックエンドでの再検証は重複ではありません — オブジェクトごとの認可を安全に適用できるのは、バックエンドだけです。

よくあるアンチパターン

• 「ゲートウェイで JWT を検証しているので、安全です。」 バックエンドでの BOLA/BFLA チェックが欠けています。これは最もよくある API 侵害のパターンです。
• レート制限もローテーションもない静的 API キー。 認証情報が 1 つ漏えいするだけで、検知されることなくすべてが露出します。
• ゲートウェイでのスキーマ検証がない。 不正な入力によってバックエンドがクラッシュし、スタックトレースが漏えいします。ファジングで見つかるバグは、テスト環境ではなく本番環境のものになります。
• APIM ポリシー XML やリポジトリ内のシークレット。 最初の認証情報ローテーション時のインシデントで、履歴に残ったシークレットが恒久的に露出します。
• APIM を前段に置いているのに、バックエンドがパブリック。 バックエンドの URL を見つけた人は誰でもゲートウェイを迂回できます。Private Endpoints / VNet 統合を使用してください。
• API カタログがない。 シャドー API は、外部 API 侵害の最も一般的なパターンです。一覧化できなければ、安全を確保することもできません。

プロンプトの例

• OWASP API Security Top 10 に準拠した Azure API Management のセキュアな API を設計してください。
• 静的 API キーに頼るのではなく、ゲートウェイで JWT を検証するにはどうすればよいですか？
• バックエンド API を保護するため、レート制限とペイロード検証を設定してください。
• 最小権限の原則に照らして、API の認証および認可の設計をレビューしてください。
• Azure API Management で BOLA と BFLA に対応する制御は何ですか？

Microsoft Learn

• API Management のセキュリティ ベースライン：https://learn.microsoft.com/azure/api-management/security-baseline
• Entra ID でバックエンドを保護する：https://learn.microsoft.com/azure/api-management/api-management-howto-protect-backend-with-aad
• validate-jwt ポリシー：https://learn.microsoft.com/azure/api-management/validate-jwt-policy
• OWASP API の脅威を軽減する：https://learn.microsoft.com/azure/api-management/mitigate-owasp-api-threats
• Defender for APIs：https://learn.microsoft.com/azure/defender-for-cloud/defender-for-apis-introduction
• APIM ランディング ゾーン アクセラレータ：https://learn.microsoft.com/azure/cloud-adoption-framework/scenarios/app-platform/api-management/landing-zone-accelerator