Azure リソースへのアクセス管理（RBAC）

Azure RBAC は、セキュリティプリンシパル（誰が）、ロール定義（何をしてよいか）、スコープ（どこまで効くか）の 3 つを結び付けたものだ。この結び付き 1 件を「ロールの割り当て」と呼ぶ。

セキュリティプリンシパルは 4 種類ある。ユーザー、グループ、サービスプリンシパル（アプリ）、そしてマネージド ID だ。実務でも試験でも、個人ではなくグループに割り当てるのが推奨で、「担当者が増えるたびに権限を付け直したくない」と書かれていたらグループが答えになる。

スコープは 4 階層ある。管理グループ → サブスクリプション → リソースグループ → リソースだ。上位スコープで割り当てたロールは、下位すべてに継承される。

逆方向は無い。リソース 1 つに割り当てた権限が、そのリソースグループ全体に広がることはない。「必要最小限の範囲に絞る」という原則からすると、要件を満たす一番下のスコープを選ぶのが正解になることが多い。

複数の割り当てが重なった場合、許可は足し算される。リソースグループで閲覧者、個別の VM で共同作成者を持っていれば、その VM は変更できる。ただし例外が 1 つある。

組み込みロールは何百もあるが、AZ-104 で問われるのは実質 4 つだ。違いは「読み取り」「作成・変更・削除」「ロールの割り当て」の 3 つができるかどうかで決まる。

カスタムロール

組み込みロールで過不足があるときに自作する。JSON で定義し、Actions（許可する操作）、NotActions（そこから除く操作）、DataActions / NotDataActions（データ面の操作）、そして AssignableScopes（このロールを割り当ててよい範囲）を書く。

# 組み込みロールの定義を見る。 カスタムロールの雛形にする
az role definition list --name "Contributor"
# カスタムロールを作る （PowerShell: New-AzRoleDefinition）
az role definition create \
  --role-definition ./myrole.json
# ロールを割り当てる （PowerShell: New-AzRoleAssignment）
az role assignment create --assignee <ID> \
  --role "Contributor" --scope <スコープ>

ここが混乱の最大の原因になる。Azure には権限の体系が 2 つあり、交わらない。

アプリから Azure のサービスへ接続するとき、接続文字列やシークレットをコードに書くのは避けたい。マネージド ID は、Azure のリソース自身に ID を持たせ、その ID に RBAC でロールを割り当てることで、資格情報なしで認証させる仕組みだ。