どうも、フリーランスエンジニアのMakotoです。
今回は、ロールベースのアクセス制御（RBAC）について解説します。
Azure ADで管理されるユーザーに適切な権限を付与するための重要な仕組みです。ぜひ、最後までお読みください。
という方はこちらの記事を先にチェックされることをオススメします！
それではいってみましょう！
ロールベースのアクセス制御（RBAC）とは？
ロールベースのアクセス制御（Role Based Access Control）は、Azureリソースに対するアクセス権を管理するための仕組みです。略してRBAC（アールバック）を呼びます。
Azure ADにユーザーを登録したところで仮想マシンなどのリソースに対して作成・変更・削除の操作ができるわけではないので、RBACの仕組みによりアクセス権を割り当てます。
RBACという用語だけ聞くと難しそうに聞こえますが、仕組みはWindowsやLinuxのファイルの権限管理と似ています。
簡単な例を挙げます。
以下の画面は、サブスクリプション > リソースグループ > リソースの階層構造をエクスプローラーで表したものです。ファイル=リソースと捉えてください。
この例では「リソースグループA」というフォルダに対して、Everyoneがフルコントロールできるようにプロパティから設定しようとしています。
これは少し極端な例ですが、RBACでAzureのリソースに対してアクセス権を割り当てる場合も、どのスコープに対して、誰に、どんな権限（ロール）を割り当てるのかを設定します。
まず、スコープを選択します。
親スコープに対して付与するアクセス権は子スコープに継承されます。
Azureリソースの階層構造についてはこちらの記事で解説しています。
「誰に」の部分は単一のユーザーを選択することもできますが、一般的には先にグループで整理しておいて、グループに対してアクセス権を付与します。
そして、どんな操作を許可するのか、アクセス権を付与します。このアクセス権のことをAzureでは「ロール（役割）」と呼びます。
Azureでは、一般的なアクセス規則が記述された「組み込みロール」が初めから用意されていますが、利用者が独自のロール（カスタムロール）を作成することも可能です。
組み込みロールの一例として次のようなロールがあります。
- 所有者：すべての操作を許可
- 共同作成者：権限管理以外の操作を許可
- 閲覧者：読み取り（閲覧）のみ許可
RBACの設定手順
実際にロールを割り当てる場合、最初にサブスクリプション、リソースグループ、リソースいずれかの画面にある「アクセス制御（IAM）」を開きます。
IAMは「Identity and Access Management」の略で直訳すると「IDとアクセス管理」という意味です。AWSやGCPでも登場する一般的な用語です。
少しわかりにくいかもしれないのでもう一度書きます。最初はまずスコープのリソースに遷移します（どのスコープにも共通してアクセス制御のメニューがあります）
追加ボタン → ロールの割り当ての追加 から操作を開始できます。ここではリソースグループに対して設定します。
まず、ロールを選択します。組み込みロールがずらっと表示されるので、ここではその中の「共同作成者」を選択します。
次のメンバータブでは、「誰に」を選択します。ここでは「インフラグループ」を選択しました。マネージドIDについては後述します。
最後に内容を確認して割り当てを実行します。
割り当てた結果は「ロールの割り当て」タブから確認できます。
リソースグループ内のリソース（ここでは仮想ネットワーク）のアクセス制御（IAM）から確認してみると「共同作成者」のロールが継承されていることがわかります。
マネージドIDとは？
これまで、「誰に」の部分を人間前提で解説していますが、Azure ADにおける身元を表すIDにはユーザー = 人を含めて次のような種類があります。
| IDの種類 | 説明 |
|---|---|
| ユーザー | Azureポータルなどからアクセスする組織の従業員や招待されたゲスト |
| サービスプリンシパル | アプリケーションに割り当てるID |
| マネージドID | 仮想マシンなどAzureリソースに割り当てるID |
| デバイス | モバイル端末やラップトップなどのハードウェア |
例えば、仮想マシンで動作するアプリケーションからBlobストレージにログを出力する場合、仮想マシンがストレージにアクセスするための権限が必要です。
ここでは、そんな時に利用するマネージドIDについて取り上げます。
こういった場合、仮想マシンのマネージドIDを有効化することで、Azure AD上に仮想マシンのIDが登録され、ロールを割り当てることができるようになります。（AWSでいうところのIAMロールの機能です）
Azureのロールは2種類ある
AZ-900試験では恐らく知らなくてもいい内容ですが、みなさんが将来混乱しないように少しだけ補足しておきます。
なにがややこしいって、実はロール = RBACの仕組みはAzure RBAC / Azure AD RBACの2種類あるんですよね。
こちらの記事で解説しているとおり、サブスクリプションとAzure ADがそれぞれが独立しているということは、それぞれに対して行える操作が異なるということです。
まず、Azure RBACではすでに述べたとおり、Azureリソースを作成、読み取り、変更、削除などを行うロールをスコープに対して割り当てることができます。
続いて、Azure AD RBACのロール一覧画面です。
ユーザーやグループの作成、パスワードリセットなどIDに関わる操作のロールを設定でき、こちらもいくつかの組み込みロールが用意されています。割り当て対象のスコープに階層構造はありません。Azure ADに対するロールです。
管理者アカウントには次の権限が割り当てられます。いずれも何でもできる最強の権限です。
- サブスクリプション：所有者
- Azure AD：グローバル管理者
サブスクリプションとAzure ADそれぞれにロールを割り当てることができる（権限が分離されている）点は頭の片隅に入れておきましょう。
- サブスクリプションのロールはAzureリソースの操作に対する権限
- Azure ADのロールはユーザー管理に関わる権限
まとめ
今回はロールベースのアクセス制御（RBAC）について解説しました。AZ-900試験の対策としてRBACのポイントをまとめると次のとおりです。
- 何に対して（スコープ）、誰に、どんな操作（ロール）を許可するか設定する
- 親スコープのロールは子スコープに継承される
- 初めから用意された「組み込みロール」と独自に作成する「カスタムロール」がある
- Azureリソースにロールを割り当てるためのマネージドIDがある
Azure ADで管理されるユーザーなどのIDと、そのIDに権限を割り当てるロールの仕組み（RBAC）は密接に関係しています。
ユーザーはグループでひとまとめに整理しておいて、必要最小限のロールをグループに対して割り当てるのがベストプラクティスとされています。
権限管理を考える際には、Azure ADとRBACをセットで考えるようにしましょう。
それでは、また。
