変更要約: SC-100 第5章を新規作成（ドメイン4「アプリとデータのセキュリティ設計」: M365 保護(Microsoft Secure Score/Defender for Office 365/Defender for Cloud Apps(CASB)/Intune/Purview ラベル/DLP)、Copilot for Microsoft 365(権限/ラベル継承/過剰共有/DSPM for AI/Purview Audit)、アプリ保護(脅威モデリング/セキュア開発ライフサイクル/workload identity/API Management/Azure WAF)、データ保護(discovery/分類/保存時・転送時暗号化/CMK/Key Vault/Defender for Storage/Defender for Databases/Azure SQL/Synapse/Cosmos DB/Storage)）。
5.3アプリケーションの保護
アプリポートフォリオの posture 評価、脅威モデリングによる business-critical アプリの評価、アプリセキュリティのフルライフサイクル戦略とセキュア開発の標準、workload identity による認証、API 管理とセキュリティ、Azure Web Application Firewall（WAF）を理解します。
アプリケーションは攻撃者の主要な入口です。アーキテクトは個々のバグ修正でなく、「設計→開発→運用」を通したアプリセキュリティのライフサイクル戦略と、実行時の防御（WAF・API 保護・workload identity）を設計します。
5.3.1脅威モデリングとセキュア開発
まず既存アプリポートフォリオの posture を評価し、business-critical アプリを 脅威モデリング（どこが・どう攻撃されうるか）で分析します。設計から運用までのフルライフサイクル戦略＝セキュア開発の標準（コード/依存関係/シークレットのスキャン・IaC 検査・SBOM）を DevSecOps（第1章）として組み込みます。技術選定は要件（認証・データ保護・監査）にマッピングし、属人的でなく標準化します。アーキテクトは「アプリのセキュリティを開発プロセスに織り込む」設計を導きます。
5.3.2workload identity・API・WAF
実行時のアプリは、Azure リソースへ workload identity（マネージド ID／フェデレーション資格情報）で鍵を持たずに認証します。公開 API は Azure API Management で認証/認可・レート制限・ゲートウェイ集約を行い、Web アプリは Azure Web Application Firewall（WAF）で OWASP Top 10（SQLi/XSS 等）や Bot を L7 で防御 します（Application Gateway や Azure Front Door に統合）。アーキテクトは「アプリのアイデンティティ・API 入口・Web 攻撃」の 3 点を、それぞれ適切な製品で固めます。
決め手：「アプリに鍵を配らず Azure リソースへ認証」＝workload identity（マネージド ID）。「API の認証/レート制限/ゲートウェイ」＝API Management。「SQLi/XSS/Bot を L7 で防御」＝Azure WAF（App Gateway/Front Door）。「どこが攻撃されるかを設計時に分析」＝脅威モデリング。
混同に注意：
①WAF（L7 の Web アプリ防御）と NSG/ファイアウォール（L3/L4 のネットワーク制御）を取り違えない。
②workload identity はアプリ用＝ユーザー認証（Conditional Access）とは別レイヤ。
③アプリセキュリティは実行時防御だけでなく開発ライフサイクル（DevSecOps）まで設計する。
5.3.3この節のまとめ
- 脅威モデリングで business-critical アプリを評価し、セキュア開発をフルライフサイクル戦略（DevSecOps）に組み込む
- 実行時＝workload identity（鍵レス認証）・API Management（API 保護）・Azure WAF（L7 の Web 防御）
- WAF（L7）とネットワーク制御（L3/L4）、workload identity（アプリ）とユーザー認証は別レイヤ
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. Web アプリへの SQL インジェクションやクロスサイトスクリプティング（XSS）を L7 で防御したい。最適なのはどれですか？
Q2. アプリが鍵やシークレットを保持せずに Azure リソースへ認証する設計はどれですか？
Q3. 公開 API の認証/認可・レート制限・ゲートウェイ集約を一元的に行いたい。最適なのはどれですか？
Q4. business-critical なアプリについて、設計段階で「どこがどう攻撃されうるか」を体系的に分析したい。最適なのはどれですか？
Q5. アプリセキュリティの設計範囲として最も適切なのはどれですか？