Azure RBACのロール割り当てとカスタムロールを実務目線で解説【ポータル/CLI/棚卸し】

Azure RBACの仕組みが頭に入ったら、次はいよいよ実際にロールを割り当ててみる番です。「アクセス制御(IAM)ってどこを押せばいいの？」「CLIで一発でやりたいけどaz role assignment createの引数がよく分からない」「組み込みロールに欲しい権限がなかったらどうするの？」——このあたりでつまずく人はとても多いです。私も最初は、ポータルの画面とにらめっこしながら「この割り当て、あとで誰が付けたか分からなくなるな…」と不安になったものでした。

「RBACの理屈は分かった。で、実際にポータルとCLIでどう割り当てて、どう棚卸しするの？組み込みロールで足りないときは？」

この記事は、その手を動かすパートを一気に扱う実践編です。Azureポータルでのロール割り当てから始めて、同じことをAzure CLI（az role assignment create）でやる方法、割り当ての確認・削除（棚卸し）、そして最後に組み込みロールでは足りないときのカスタムロールの定義までを、公式Microsoft Learnの内容を噛み砕きながら通しでやっていきます。読み終わるころには、権限付与を画面でもコマンドでも自信を持って回せるようになります。

なお、そもそもRBACの3要素（誰に・何を・どこで）や組み込みロールの全体像があやふやな方は、先に Azure RBACとは？ロール割り当ての3要素と組み込みロールを実務目線で解説に目を通しておくと、この記事の一つひとつの操作が「何をしているのか」腹落ちします。本記事はそのハブ記事の中の「実際に割り当てる・作る」部分を深掘りする子記事です。

ポータルからロールを割り当てる（アクセス制御 IAM）
Azure CLI で割り当てる（az role assignment create）
割り当てを確認・削除する（棚卸し）
カスタムロールを定義する（Actions と AssignableScopes）
まとめ
あわせて読みたい

ポータルからロールを割り当てる（アクセス制御 IAM）

まずは一番オーソドックスな、Azureポータルからの割り当てです。ここで押さえるべき入り口はただ一つ、「アクセス制御(IAM)」というメニューです。RBACの操作は、原則としてこの画面から行います。

大事なのは、この「アクセス制御(IAM)」がほぼすべてのリソースに付いているという点です。サブスクリプションにも、リソースグループにも、個別の仮想マシンやストレージアカウントにも、それぞれ同じIAMメニューがあります。そして「どの階層のIAMを開いて割り当てたか」が、そのままスコープ（権限が効く範囲）になります。リソースグループのIAMで割り当てれば、その中のリソース全部に効く。個別リソースのIAMで割り当てれば、そのリソースだけに効く。ここが初心者の最初のつまずきポイントで、「なんか広すぎる／狭すぎる権限になった」というトラブルの大半は、開く階層を間違えていることが原因です。

今回は例として、あるリソースグループに対して「見るだけ」のReader（閲覧者）ロールを割り当ててみます。手順はこうです。

権限を付けたい対象（今回はリソースグループ）を開き、左メニューの「アクセス制御(IAM)」を選ぶ。
上部の「＋追加」→「ロールの割り当ての追加」をクリックする。
「ロール」タブで Reader を検索して選択し、「次へ」。
「メンバー」タブで「＋メンバーを選択する」を押し、権限を渡したいユーザーやグループを選ぶ。
「レビューと割り当て」で内容を確認し、割り当てを確定する。

これで完了です。前のハブ記事で説明した「誰に・何を・どこで」の3要素が、この画面のままメンバー＝誰に／ロール＝何を／開いている階層＝どこでに対応しているのが分かると思います。ポータル操作は、頭の中の3要素をそのまま画面に写しているだけなんですね。

なぜ最初に付けるなら Reader が安全なのか

練習で最初に触るロールとしてReaderを選んだのには理由があります。Readerは「見えるけれど、何も変更・削除できない」という、いわば一番害のないロールだからです。いきなりContributor（共同作成者）やOwner（所有者）を人に配ってしまうと、意図せずリソースを作られたり消されたりしかねません。まずは事故の起きないReaderで「割り当て→効いているか確認」の一連の流れを体で覚え、そこから必要に応じて強いロールに広げていく。この順番が安全です。

もう一つ、割り当てには反映まで少し時間がかかることがあります。割り当てた直後に対象ユーザーで確認しても権限が効いていないように見えることがありますが、多くは数十秒〜数分で反映されます。「効かない！」と慌てて二重に割り当てる前に、少し待ってみてください。

Azure CLI で割り当てる（az role assignment create）

ポータルは分かりやすい反面、同じ割り当てを何度もやったり、手順を記録・再現したりするには向きません。そこで実務で重宝するのがAzure CLIです。ロール割り当てを1行で作れるので、「あとで見返して何をやったか分かる」「スクリプトに残せる」という強みがあります。

コマンドは az role assignment create です。先ほどのReader割り当てをCLIで書くと、こうなります。

az role assignment create \
  --assignee "tanaka@yourcompany.onmicrosoft.com" \
  --role "Reader" \
  --scope "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-demo"

3つの引数が、そのままRBACの3要素になっているのがポイントです。順番に噛み砕きます。

–assignee（誰に）：権限を渡す相手。ユーザーのUPN（メール形式の名前）や、オブジェクトID、グループ、サービスプリンシパルのIDを指定します。名前が曖昧で解決に失敗するときは、確実なオブジェクトIDを --assignee-object-id で渡すと安定します。
–role（何を）：割り当てるロール。"Reader" のように組み込みロールの表示名でも、ロール定義のIDでも指定できます。
–scope（どこで）：効かせる範囲。ポータルで「どの階層のIAMを開くか」に相当する部分を、ここではリソースIDの文字列で明示します。

CLIで一番とっつきにくいのが、この --scope の長い文字列でしょう。これはそのリソースを指す住所のようなもので、階層が深くなるほど後ろにパスが伸びていきます。サブスクリプション全体なら /subscriptions/<サブスクID>、リソースグループなら /subscriptions/<サブスクID>/resourceGroups/<RG名>、個別リソースならさらにその後ろに /providers/... と続きます。手打ちする必要はなく、対象リソースをCLIで参照したときに返る id をそのままコピーすればOKです。

ちなみに、いま操作しているサブスクリプションのIDが分からなくなったら、az account show --query id -o tsv で取り出せます。スコープ文字列を組み立てるときの部品として覚えておくと便利です。

「ポータル＝メンバー/ロール/開いた階層」「CLI＝–assignee/–role/–scope」。同じ3要素を別の入り口で指定しているだけ、と分かると一気にラクになります。

割り当てを確認・削除する（棚卸し）

権限は「付けて終わり」ではありません。運用していくと、「誰に、どのスコープで、どんなロールが付いているか」が時間とともに分からなくなっていきます。異動した人の権限が残っていたり、テスト用に付けた強い権限を外し忘れていたり。だからこそ、定期的に一覧して見直す「棚卸し」が実務では欠かせません。ここでは確認と削除のやり方を押さえます。

ポータルで確認する

ポータルなら、対象リソースの「アクセス制御(IAM)」→「ロールの割り当て」タブを開くと、そのスコープに効いている割り当てが一覧で見えます。ここで注意したいのが、表示される割り当てにはそのリソース自身に直接付けたものだけでなく、上位（親のリソースグループやサブスクリプション）から継承されたものも含まれるという点です。一覧の「スコープ」列を見ると、その割り当てが「このリソース」なのか上位から降ってきた継承なのかが分かります。「なぜかこのリソースにOwnerが付いている」と思ったら、実はサブスクリプション全体に付いていた、というのはよくある話です。

CLIで一覧・削除する

棚卸しをちゃんとやるなら、CLIのほうが圧倒的にラクです。特定スコープの割り当てを一覧するにはこうします。

az role assignment list \
  --scope "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-demo" \
  --output table

誰が何を持っているかがテーブルで並びます。特定の人に絞りたければ --assignee を足せば、その人の割り当てだけを抜き出せます。棚卸しでは、この「人で絞る」使い方がとても効きます。

不要な割り当てを見つけたら、az role assignment delete で外します。削除は「割り当てそのもの」を消す操作なので、誰の・どのロールを・どのスコープで外すのかを過不足なく指定するのがコツです。

az role assignment delete \
  --assignee "tanaka@yourcompany.onmicrosoft.com" \
  --role "Reader" \
  --scope "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-demo"

ここでの最大の注意点は、スコープを指定せずに --assignee だけで削除すると、その人に付いている割り当てを広く消してしまうことです。「1つ外したかっただけなのに、他のスコープの権限まで消えた」という事故につながります。削除では、消したい割り当てをできるだけロールとスコープまで具体的に指定して、対象を1本に絞る癖をつけてください。作成のとき以上に、削除は慎重に。

カスタムロールを定義する（Actions と AssignableScopes）

ここまでは組み込みロール（AzureがあらかじめReaderやContributorなどを用意してくれているもの）を使ってきました。実務の多くはこれで足ります。でも時々、「Readerだと弱いけどContributorだと強すぎる」「仮想マシンの再起動だけを許可したい」といった、ちょうどいい組み込みロールが存在しない場面に出くわします。そのときの最後の手段がカスタムロールです。自分で「できること」を定義した、オリジナルの役割を作れます。

カスタムロールはJSONで定義します。まずは短いサンプルを見てもらうのが早いです。「仮想マシンの起動・再起動・状態確認はできるが、削除や作成はできない」ロールを作るイメージです。

{
  "Name": "VM Operator (custom)",
  "Description": "VMの起動・再起動と状態確認のみ許可",
  "Actions": [
    "Microsoft.Compute/virtualMachines/read",
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action"
  ],
  "NotActions": [],
  "AssignableScopes": [
    "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  ]
}

初見だと呪文のようですが、カスタムロールを理解するカギは2つのブロックだけです。Actions（何を許可するか）とAssignableScopes（どこで割り当てられるか）。ここさえ分かれば、あとは応用です。

Actions と NotActions ＝「できること」の定義

Actionsには、このロールで許可する操作を並べます。1つひとつは Microsoft.Compute/virtualMachines/start/action のような文字列で、「リソースプロバイダー名／リソース種別／操作」という構造になっています。最初の Microsoft.Compute が「仮想マシンを司る担当部署」、次が「仮想マシンというリソース」、最後の start/action が「起動という操作」だと読むと分かりやすいです。末尾の read は参照、write は作成・変更、delete は削除にあたります。

ここでよく使うのがワイルドカード（*）です。たとえば Microsoft.Compute/virtualMachines/* と書けば、「仮想マシンに関する操作を全部許可」になります。広く許可しておいて、そこから一部だけ引き算したいときに使うのがNotActionsです。NotActionsは「Actionsで許可した中から、これだけは除外する」という差し引きの指定です。「仮想マシン全操作を許可するが、削除だけは禁止」なら、Actionsに .../virtualMachines/* を入れ、NotActionsに .../virtualMachines/delete を入れる、といった具合です。足し算がActions、引き算がNotActions、と覚えてください。

どんなActionの文字列があるのかは暗記する必要はありません。az provider operation show --namespace Microsoft.Compute のようなコマンドで、そのプロバイダーで指定できる操作の一覧を引けます。まずは組み込みロールのJSON定義（az role definition list で見られます）を眺めて、「この権限はこう書くのか」と真似るのが一番の近道です。

AssignableScopes ＝「どこで使えるロールか」

もう一つの柱がAssignableScopesです。これは「このカスタムロールを、どの範囲で割り当てられるようにするか」という指定です。組み込みロールはAzure全体でどこでも使えますが、カスタムロールは自分で使える範囲を明示しないといけません。ここに書いたサブスクリプションやリソースグループの中でだけ、そのロールを割り当てられるようになります。

混同しやすいので整理すると、AssignableScopesは「ロールを配置していい売り場」、実際のロール割り当てのスコープは「その中で実際に効かせる棚」です。AssignableScopesにサブスクリプションを指定しておけば、その配下のどのリソースグループにでもこのロールを割り当てられる。逆に特定リソースグループだけに絞れば、そのロールはそこでしか使えなくなります。うっかり全社に配りたくないカスタムロールは、AssignableScopesを狭めておくのが安全です。

このJSONができたら、az role definition create --role-definition ./vm-operator.json で登録できます。登録後は、これまでと全く同じ手順で——ポータルのIAMでもCLIの az role assignment create でも——組み込みロールと同じように人に割り当てられます。カスタムロールは「新しいロールを増やす」だけで、割り当ての作法自体は何も変わらないわけです。

まとめ

この記事では、RBACを「実際に手で回す」ための一連の操作を通しでやってきました。最後に流れを振り返っておきます。

ポータル：対象の「アクセス制御(IAM)」→「ロールの割り当ての追加」で、ロール・メンバーを選ぶだけ。開いた階層がスコープになる。
CLI：az role assignment create --assignee/--role/--scope の3引数が、そのままRBACの3要素。
棚卸し：az role assignment list で確認、az role assignment delete で削除。削除はスコープまで具体的に指定して対象を1本に絞る。
カスタムロール：組み込みで足りないときの最終手段。Actions/NotActionsで「できること」を足し引きし、AssignableScopesで「使える範囲」を明示する。

ここまでできれば、権限付与を画面でもコマンドでも自信を持って回せるはずです。あとは「では実際、どこまで権限を絞るべきか」「付けた権限をどう継続的に見直すか」という設計と運用の話が残ります。そこは姉妹記事に譲りますので、あわせて読み進めてください。