変更要約: SC-300 第4章を新規作成（ドメイン3: ワークロード ID 選択/マネージド ID(システム/ユーザー割当)/サービスプリンシパル/gMSA、エンタープライズアプリ(SSO/Application Proxy/app role 割当/同意ポリシー/管理者同意ワークフロー)、アプリ登録(リダイレクト URI/シークレット・証明書・フェデレーション資格情報/委任・アプリケーション権限/app roles)、Defender for Cloud Apps(cloud discovery/Cloud app catalog/OAuth アプリポリシー/CA アプリ制御/アクセス・セッションポリシー)）。
4.1ワークロード ID の選択とマネージド ID
アプリや Azure ワークロードに適した ID（マネージド ID・サービスプリンシパル・ユーザーアカウント・マネージドサービスアカウント）の選択、マネージド ID の作成・割当・他リソースへのアクセスを理解します。
人だけでなく、アプリやサービス（ワークロード）にも ID が必要です。アクセス管理者は、鍵を持たせずに最小特権で動かせる ID を選び、漏えいリスクを下げます。
4.1.1ワークロード ID の選択
Azure リソース上で動くワークロードには マネージド ID を第一に選びます＝資格情報を Azure が管理し、鍵を配布しません。アプリを Entra に表す実体は サービスプリンシパル（アプリ登録のインスタンス）です。人が使う ユーザーアカウント をサービスに流用するのはアンチパターンで避けます。オンプレ AD のサービスには グループ管理サービスアカウント（gMSA） 等を使います。「Azure リソースから他リソースへ鍵なしでアクセス」＝マネージド ID が原則です。
4.1.2システム割当とユーザー割当のマネージド ID
マネージド ID には 2 種類あります。システム割当 はリソース（例：VM）に 1:1 で紐づき、リソース削除で自動消滅します（単一リソース向け）。ユーザー割当 は独立したリソースとして作成し、複数のリソースで共有できます（複数 VM/関数で同じ ID を使う運用向け）。作成後、対象リソースに割り当て、アクセス先リソースで RBAC ロール（例：Key Vault の Secrets User）を付与すれば、コードに鍵を書かずにアクセスできます。
決め手：「Azure リソースから鍵なしで他リソースへ」＝マネージド ID。「複数リソースで同じ ID を共有」＝ユーザー割当マネージド ID。「単一リソースに紐づけ自動ライフサイクル」＝システム割当。「アプリを Entra に表す実体」＝サービスプリンシパル。人のアカウントをサービスに使わない。
混同に注意：
①マネージド ID（Azure が資格情報管理・鍵レス）とサービスプリンシパル（一般のアプリ ID・シークレット/証明書を持ちうる）を取り違えない。
②システム割当（1:1・自動消滅）とユーザー割当（共有可・独立ライフサイクル）の使い分け。
③ユーザーアカウントをサービスに流用しない。
4.1.3この節のまとめ
- Azure ワークロードはマネージド ID 第一（鍵レス）。アプリの実体はサービスプリンシパル。ユーザーアカウントをサービスに使わない
- システム割当＝1:1/自動消滅、ユーザー割当＝複数リソースで共有。RBAC で最小権限を付与
- オンプレのサービスには gMSA 等
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. Azure VM 上のアプリが Key Vault のシークレットへアクセスする必要がある。コードに資格情報を埋め込まずに実現したい。最適なのはどれですか？
Q2. 複数の VM と関数アプリで「同じ ID」を共有してリソースにアクセスさせたい。最適なのはどれですか？
Q3. 単一の VM に紐づき、その VM を削除したら ID も自動的に消えるようにしたい。最適なのはどれですか？
Q4. サービスプリンシパルとマネージド ID の関係として正しいのはどれですか？
Q5. サービスに人間用のユーザーアカウントを流用するのを避けるべき理由として最も適切なのはどれですか？