変更要約: 各節に図（figure）を追加＝cert-figure-retrofit。SC-500 第3章を新規作成（ドメイン3「コンピュートの保護」: AI セキュリティ=SharePoint 過剰露出/Purview DSPM for AI/Copilot Studio リアルタイム保護/Entra Agent ID・条件付きアクセス/Defender XDR ブラスト半径/APIM AI Gateway・Foundry ガードレール/Defender for AI・データ&AI ダッシュボード、サーバー/VM=Bastion・JIT/ディスク暗号化・信頼された起動/Defender for Servers・エージェントレス/Azure Arc/Machine Configuration、アプリ基盤=Defender for Containers/ACR・AKS/App Service・Functions・Logic Apps/WAF・API Management）
3.3アプリケーション プラットフォーム サービスのセキュリティ
コンテナワークロードの保護（Defender for Containers）、AKS・Azure Container Registry・Container Instances/Apps のセキュリティ制御、Azure Functions・Logic Apps・App Service の保護、Web Application Firewall、そして API Management によるバックエンド API 保護を学びます。
PaaS とコンテナのアプリ基盤は、開発スピードを上げる一方で設定ミスや公開範囲の広さが脆弱性になりがちです。守る観点は「コンテナの構成と実行時を保護（Defender for Containers）→ レジストリ/オーケストレーターを制御（ACR/AKS）→ アプリ実行環境を保護（App Service/Functions/Logic Apps）→ 公開境界を守る（WAF/APIM）」です。
3.3.1コンテナの保護：Defender for Containers・AKS・ACR
Microsoft Defender for Containers は、コンテナワークロードの 構成ミス（設定の弱点）と 実行時リスク（不審なプロセス・既知の悪用など）を検知します。イメージは Azure Container Registry（ACR） に保管し、脆弱性スキャンと信頼されたイメージのみ許可で守ります。オーケストレーターの Azure Kubernetes Service（AKS） は、Entra 統合・RBAC・ネットワークポリシー・プライベートクラスターなどでアクセスと通信を制御します。軽量実行の Azure Container Instances（ACI）/Container Apps もネットワークと ID で保護します。
3.3.2アプリ実行環境：App Service・Functions・Logic Apps
App Service・Azure Functions・Logic Apps は、認証（App Service 認証/Easy Auth・Entra ID）でアクセスを制御し、ネットワーク制限（アクセス制限規則・プライベートエンドポイント・VNet 統合）で到達を絞ります。Functions はトリガーとバインディングの権限、Logic Apps はコネクタの資格情報（マネージド ID 推奨）に注意します。シークレットは Key Vault 参照で外出しします。
3.3.3公開境界の保護：WAF と API Management
公開する Web アプリ/API は Azure Web Application Firewall（WAF）（Application Gateway や Front Door に統合）で、SQL インジェクション・XSS など OWASP のよくある攻撃から保護します。API Management（APIM） はバックエンド API 保護の要で、サブスクリプションキー/OAuth 検証・レート制限・IP 制限・JWT 検証などのポリシーをゲートウェイで一元適用し、バックエンドを直接公開せずに守ります（第3章 s1 の AI Gateway も APIM の一機能）。
| 対象 | 主な制御 | 要点 |
|---|---|---|
| コンテナ全般 | Defender for Containers | 構成ミス＋実行時リスクを検知 |
| イメージ | ACR（脆弱性スキャン/信頼イメージ） | 信頼されたイメージのみ許可 |
| オーケストレーター | AKS（Entra/RBAC/ネットワークポリシー/プライベート） | アクセスと通信を制御 |
| アプリ実行環境 | App Service/Functions/Logic Apps（認証＋ネットワーク＋マネージド ID） | Key Vault 参照でシークレット外出し |
| 公開 Web/API | WAF＋API Management | OWASP 対策＋ゲートウェイで API 保護 |
混同に注意：
①WAF（L7 の Web 攻撃＝OWASP を防ぐ）とAPI Management（API のアクセス制御・レート制限・JWT 検証などをゲートウェイで適用）は役割が違い、併用しうる。
②Defender for Containers（コンテナの構成＋実行時の脅威検知）とACR の脆弱性スキャン（イメージの既知脆弱性）。
③アプリの認証（誰か）とネットワーク制限（どこから）は別レイヤー。
「要件 → 機能」：例「OWASP の Web 攻撃から公開アプリを守る」＝WAF、「バックエンド API を直接公開せずレート制限/JWT 検証」＝API Management、「コンテナの構成ミスと実行時リスクを検知」＝Defender for Containers、「イメージの脆弱性をスキャンし信頼イメージのみ許可」＝ACR、「Logic Apps からの接続でシークレットを使わない」＝マネージド ID。
3.3.4この節のまとめ
- コンテナ：Defender for Containers（構成＋実行時）＋ACR（イメージ脆弱性/信頼）＋AKS（Entra/RBAC/ネットワーク/プライベート）
- アプリ実行環境：認証（Easy Auth/Entra）＋ネットワーク制限＋マネージド ID＋Key Vault 参照
- 公開境界：WAF（OWASP）＋API Management（ゲートウェイで API 保護）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. コンテナワークロードの構成ミスと実行時リスク（不審なプロセスや既知の悪用）を検知する Defender for Cloud のプランはどれですか？
Q2. 公開する Web アプリケーションを SQL インジェクションや XSS など OWASP のよくある攻撃から保護するのはどれですか？
Q3. バックエンド API を直接公開せず、ゲートウェイでレート制限・JWT 検証・サブスクリプションキーなどのポリシーを一元適用するのはどれですか？
Q4. コンテナイメージの既知の脆弱性をスキャンし、信頼されたイメージのみを許可する保管場所はどれですか？
Q5. Logic Apps や Functions が他のサービスへ接続する際に、コードや構成にシークレットを置かずに認証する推奨方法はどれですか？
Q6. WAF と API Management の関係として正しいものはどれですか？