変更要約: AZ-305 第1章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
1.1ID とアクセスの設計
Azure の認証・認可の設計——Microsoft Entra ID、RBAC、条件付きアクセス、マネージド ID、PIM、B2B/B2C——を理解します。最小権限で安全な ID 基盤を設計します。
アーキテクチャの土台は ID です。Microsoft Entra ID を中心に、誰が何にアクセスできるかを最小権限で設計します。
1.1.1ID とアクセスの構成要素
- Microsoft Entra ID：クラウドのディレクトリ/ID プロバイダー。SSO とアプリ統合の中心。
- RBAC：ロールで最小権限を付与（スコープ: 管理グループ/サブスクリプション/RG/リソース）。
- 条件付きアクセス：場所/デバイス/リスクに応じ MFA 要求などのポリシーを適用。
- マネージド ID：アプリが資格情報なしで Azure リソースへアクセス。PIM は特権のジャストインタイム昇格。
「最小権限のロール付与＝RBAC」「条件に応じた MFA など＝条件付きアクセス」「資格情報なしのサービス間アクセス＝マネージド ID」「特権の期限付き昇格＝PIM」「外部ユーザー＝B2B、顧客向け＝B2C」 は AZ-305 で頻出です。サービスからのアクセスは可能な限りマネージド ID を使います。
マネージド ID には「システム割り当て」（リソースと同じライフサイクル）と「ユーザー割り当て」（複数リソースで共有）があります。
AZ-305 は「要件から適切な ID ソリューションを設計する」力を問います。Microsoft Entra ID はクラウドのディレクトリで、オンプレ AD とは Entra Connect（同期）や フェデレーションで接続し、ハイブリッド ID を実現します。RBAC は管理グループ→サブスクリプション→RG→リソースのスコープに継承でロールを割り当て、職務分離には組み込みロール（Owner/Contributor/Reader や各サービス固有ロール）やカスタムロールを使います。条件付きアクセスはサインインのシグナル（ユーザー/場所/デバイスの準拠状態/サインインリスク）を評価し、MFA 要求・ブロック・準拠デバイス必須などの制御をポリシーとして適用します（リスクベースは Entra ID Protection と連携）。サービス間認証はマネージド IDが原則で、システム割り当て（リソース 1:1・自動削除）とユーザー割り当て（複数リソースで共有・独立ライフサイクル）を要件で使い分けます。特権は PIM でジャストインタイム昇格（承認・期限・アクティブ化時 MFA・アクセスレビュー）にし、常時付与を避けます。外部 ID は、取引先の既存 ID を招く B2B（External ID）、消費者向けにカスタマイズ可能な B2C を用途で選びます。設計では「人もサービスも最小権限」「資格情報を持たない」「特権は期限付き」を徹底します。
| 要件 | 設計の選択 | 要点 |
|---|---|---|
| サービスが他リソースへ安全アクセス | マネージド ID | 資格情報なし・System/User 割り当て |
| 条件に応じた認証強化 | 条件付きアクセス | 場所/デバイス/リスクで MFA・ブロック |
| 特権の最小化 | PIM | JIT 昇格・承認・期限・レビュー |
| 外部ユーザー/顧客の ID | B2B / B2C | B2B=取引先招待・B2C=消費者向け |
シナリオ：App Service 上のアプリが Key Vault のシークレットと Storage のデータへアクセスする。コードに資格情報を一切持たせたくない。→ App Service にシステム割り当てマネージド IDを有効化し、Key Vault と Storage 側でそのマネージド ID に RBAC（最小権限ロール）を付与。アプリは資格情報なしでトークンを取得してアクセスします。管理者の特権作業は PIM で必要時のみ昇格させます。
FAQ：システム割り当てとユーザー割り当てのマネージド ID、どちらを設計する？ リソースと 1 対 1 で済み、リソース削除時に ID も消えてよいならシステム割り当て（管理が単純）。複数のリソースで同じ ID を共有したい、または ID をリソースより長く保持したいならユーザー割り当て（独立したライフサイクル）を選びます。
ひっかけ：サービス間アクセスに「アプリ登録＋クライアントシークレット」を設計するのは、マネージド ID が使える場面では不適切です（シークレットの管理・ローテーション負担と漏洩リスク）。Azure リソース上で動くワークロードはマネージド IDが第一選択。条件付きアクセスは「認可（RBAC）」ではなく「認証時の条件制御」である点も混同しないこと。
1.1.2この節のまとめ
- ID＝Entra ID＋RBAC（最小権限）＋条件付きアクセス
- サービス認可＝マネージド ID／特権＝PIM
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. アプリが Key Vault や Storage へ、資格情報をコードに持たずに安全にアクセスできるようにしたい。何を使いますか？
Q2. 特定の場所やリスクの高いサインインに対してのみ MFA を要求したい。何を設計しますか？
Q3. 管理者の特権ロールを常時付与せず、必要時のみ承認・期限付きで昇格させたい。何を使いますか？