変更要約: AZ-104 第1章を Associate 級に深掘り（比較表・シナリオ・FAQ・ひっかけ＋深掘り段落、図を日本語化）
1.2ロールベースアクセス制御（RBAC）
Azure RBAC のロール割り当て（セキュリティプリンシパル＋ロール定義＋スコープ）、組み込みロール、スコープ階層による継承、最小権限の原則を理解します。
認証（誰か）の次は 認可（何をしてよいか） です。Azure では RBAC（ロールベースアクセス制御）で、リソースへの操作権限を細かく付与します。
1.2.1ロール割り当ての3要素
- セキュリティプリンシパル：権限を与える相手（ユーザー/グループ/アプリ）。
- ロール定義：許可される操作の集合。例：閲覧者（読み取り）、共同作成者（作成/変更）、所有者（全権＋アクセス管理）。
- スコープ：適用範囲。管理グループ→サブスクリプション→リソースグループ→リソースの階層で、上位の割り当ては下位へ継承される。
「閲覧者＝読み取り／共同作成者＝作成・変更（アクセス管理は不可）／所有者＝全権＋アクセス管理」の違いは AZ-104 で頻出です。スコープは上位ほど広く継承されます。
Azure RBAC は「誰（プリンシパル）に・何（ロール定義）を・どこで（スコープ）」許すかの3要素で構成します。代表的な組み込みロールは 閲覧者（読み取りのみ）、共同作成者（作成/変更できるがアクセス管理＝ロール付与は不可）、所有者（全権＋アクセス管理）、ユーザーアクセス管理者（権限の管理のみ）。スコープは 管理グループ→サブスクリプション→リソースグループ→リソース の階層で、上位の割り当ては下位へ継承されます。ロール定義は許可（Actions）と拒否（NotActions）で表現され、明示的な 拒否割り当て は許可に優先します（通常 Blueprints/managed app が使用）。組み込みで足りなければ カスタムロール を作成し、最小権限を保ちます。RBAC は Azure リソースの操作権限で、Entra ID の ディレクトリロール（全体管理者など、テナント/IDの管理）とは別物です。PIM で所有者などの強い権限を時間限定・承認付きで付与すると、常設特権を減らせます。判断軸は「読み取りだけ＝閲覧者」「作る/変える＝共同作成者」「権限まで管理＝所有者/ユーザーアクセス管理者」。
| ロール | できること |
|---|---|
| 閲覧者（Reader） | 読み取りのみ |
| 共同作成者（Contributor） | 作成/変更（ロール付与は不可） |
| 所有者（Owner） | 全権＋アクセス管理 |
| ユーザーアクセス管理者 | アクセス権限の管理のみ |
シナリオ：開発者にはリソースを作らせたいが、他人への権限付与はさせたくない。 共同作成者をリソースグループスコープで割り当て（作成/変更は可、ロール付与は不可）。権限管理が必要な担当者には ユーザーアクセス管理者を別途。所有者は最小限にし、必要時だけ PIM で時間限定昇格。全社共通の制限は 管理グループスコープで割り当てて配下に継承させます。
Q. 読み取りだけ？ 閲覧者。Q. 作る/変えるが権限付与は不可？ 共同作成者。Q. 全権＋アクセス管理？ 所有者。Q. 権限の管理だけ？ ユーザーアクセス管理者。Q. 上位スコープの割り当ては？ 下位へ継承。Q. 常設特権を減らす？ PIM で時間限定昇格。
混同に注意：
①共同作成者はロール付与（アクセス管理）ができない——それは所有者かユーザーアクセス管理者。
②Azure RBAC（リソース権限）と Entra ディレクトリロール（テナント/ID管理）は別物——全体管理者≠所有者。
③スコープは継承するので、広すぎる上位割り当ては過剰権限になる（最小スコープで付与）。
④拒否割り当ては許可に優先する。
まずは組み込みロールで要件を満たせないか検討し、足りない場合のみカスタムロールを作成します。最小権限を心がけましょう。
1.2.2この節のまとめ
- ロール割り当て＝プリンシパル＋ロール定義＋スコープ
- 閲覧者/共同作成者/所有者を使い分け、スコープは下位へ継承
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. Azure RBAC のロール割り当てを構成する3要素はどれですか？
Q2. リソースの読み取りのみを許可し、変更はさせたくない場合に適した組み込みロールはどれですか？
Q3. サブスクリプションのスコープで割り当てたロールは、配下のリソースグループにどう作用しますか？