Azureと、Azure ADと、ロールベースのアクセス制御と

はじめに

Azure初学者の方にとってとても分かりづらいのが、Azure ADとAzureで権限の考え方が分かれていることです。
多くのドキュメントでは、この事実が当たり前の大前提として書かれているせいで、初めて見ると分かったようで分からない状況になりがちです。
私自身、初めてAzureを触り出した時はまさにそんな感じでした。〇〇管理者と言われても、そのユーザーが何をできるのか…？ピンと来ないところから頭を整理するのに苦労しました。

公式ドキュメントで一番ちゃんと説明しているのはこのページだと思うんですが、ちょっと難しい…。
https://docs.microsoft.com/ja-jp/azure/role-based-access-control/rbac-and-directory-admin-roles

分かってから見ると、確かに！説明されてる！ってなるんですが、明らかに初心者向けじゃない。

最近、この辺りの概念を周りに説明する機会があり、ちょっと図とか整理したのですが、そのままでは勿体無いので記事にしてみます。

説明する概念

Azureの世界で、「ユーザー」が「リソース」を触るまでの間に、どういう構成要素があって、どのように権限管理されてるかを順番に紐解いていきます。

登場人物たち

登場人物は、以下の要素です。

• ユーザー（セキュリティプリンシパル）
• AzureAD
• （管理グループ）
• サブスクリプション
• リソースグループ
• リソース
  コレらの関係性を図示すると、以下のようになります。
  

個々の関係性

ユーザーとAzure AD

ユーザーは、必ずどこかのAzureADに所属しています。このAzureADで認証を受けて

ログインした時に、ポータル画面の右上にAzureAD名が表示されますね？それです！

ゲストユーザーと Azure AD

あるユーザーを、他のAzure ADテナントにゲストユーザーとして招待することができます。
同じID/Passwordでログインした後に、「ディレクトリの切り替え」により、別のAzure ADにアクセスすることができます。こんなイメージですね。

アクセスするAzureAD毎に、別のユーザーを使い分ける必要はありません。AWSでいうところのクロスアカウントでのスイッチロールとイメージは近いかと思います。※ロールは選べないですけどね。他のAWSアカウントへのアクセス権を取る、という意味では、AzureADの別テナントでの認証を受けるのと近い概念かと思います

ユーザーとAzure ADとロール

Azure AD上の設定で、所属しているユーザーに対して「Azure ADロール」を割り当てます。

※AWSだと帽子だけど、Azureだと特定のアイコンが無い…
代表的なものは「グローバル管理者」や「ユーザー管理者」「条件付きアクセス管理者」のようなロールです。
最強権限のAzure ADロールは、英語で"Global Administrator"／日本語で"グローバル管理者"なのですが、ドキュメント上、時々ですが"全体管理者"という言葉になって出てくることがあります。
同じものなのか、別のものなのか混乱することがあるので、迷ったらドキュメントは英語版も見てみましょう。

Azure AD RBAC

上記の設定をすることで、ユーザーはAzure ADの操作権限を得るのですが、この「ロールによりAzure ADのアクセス権を制御する仕組み」のことを、Azure AD RBACと呼びます。
（RBACは、Role Based Access Controlの頭文字で一般用語ですが、Azure AD RBACって…本当に呼ばれてますかね？私は、このドキュメント以外であんまり見たことがありません。）
（参考）
https://docs.microsoft.com/ja-jp/azure/active-directory/roles/concept-understand-roles

サブスクリプションとAzure AD

サブスクリプションとは、Azureにおける権限や課金の境界線です。通常は、「部署」で区切ったり、「システム」で区切るかと思います。
サブスクリプションは、どれか一つ、Azure ADを「信頼」しています。「信頼」は昔からActive Directory界隈では使われる用語ですが、緩く説明するなら「信頼する」＝「そっちで認証されてるならアクセスさせてあげるよ」でしょうか。

すなわち、「信頼しているAzure ADで認証されたユーザーアカウントに、自分（サブスクリプション）へのアクセスを許可するよ」ということです。

サブスクリプションとユーザーとロール

サブスクリプションへのアクセスを許可するには、上記の「信頼」だけでは不足しています。もう一つ、ユーザーに対するロールの設定を行う必要があります。ロールとは、「どういう役割か」すなわち「どういう権限セットでアクセスできるのか」ということを示す概念です。

Azureポータル上、サブスクリプションの「IAM」にて、この組み合わせを登録します。

Azure RBAC

この仕組みが、Azure RBACです。Azure AD RBACと違い、各ドキュメントにも頻繁に出てくる概念ですので、しっかり覚えましょう。
Azure RBACでは、先ほど「IAM」で設定する3つの要素がポイントとなります。すなわち、
誰が：セキュリティプリンシパル
何処に：スコープ
どういう権限で：ロール
の3つです。
なお、冒頭で話した通り、AzureADのロールとAzureのロールは無関係です。そのため、Azure ADに対しては何も権限を持っていないけど、Azureのリソースは何でもいじれることもあり得ますし、逆にAzure ADでユーザー管理をすることはできてもAzure側のリソースは参照すら出来ない、なんていう設定も可能です。

セキュリティプリンシパル

セキュリティプリンシパルとして設定できるものは、「ユーザー」の他に、「グループ」「サービスプリンシパル」「マネージドID」などがあります。「誰が」ですので、人またはアプリケーションが主語になると考えれば違和感は無いと思います。

スコープ

「サブスクリプション」の他に、「管理グループ」「リソースグループ」「リソース」が指定できます。これらの説明は後段で。

ロール

メジャーなロールを3つ紹介すると、

• 一番上位の権限が「所有者」です。権限回りの設定が変更できるロールです。
• 次に「共同作成者」です。リソースの作成や削除が行えます。
• 最後に「閲覧者」です。文字通り参照権限のみを持っており、リソースの作成削除、停止起動などは行えません。
  CLIなどでロールの情報を取得すると英語で出てくるので、英語での呼び名も知っておいた方が良いと思います。上記の3つはそれぞれ、Owner/Contributor/Readerです。

サブスクリプションとリソースグループ

リソースグループは、サブスクリプションの中に作成する、リソースを束ねる概念です
先ほど説明した通りAzure RBACの「スコープ」に設定できますので、例えば「本番用RG」「開発中RG」のように分けて、『開発中RGでは何でもできるけど、本番様RGは閲覧だけにしましょう』といった権限設定を行います。

なお、ロールによる権限は上位から下位に継承されるので、例えば「サブスクリプションの所有者は、その配下のリソースグループ全ての所有者」となります。Azureでは、権限を「Deny」することは出来ないので、一部分拒否って言うのが出来ないんですよね。なので、「全体に閲覧者をつけて、このリソースグループだけ参照禁止！」という事はできません。
「最上位には一番低い権限をつけて、小さい単位で強い権限をつける」という考え方で管理しましょう。コレばっかりはAWSを見習って欲しいな…。
※Blueprintsというサービスでできるようですが勉強不足！

リソースグループとリソース

リソースとは、Azureにおける管理の最小単位で、「VirtualMachine」や「SQLDatabase」、「NSG」などが該当します。
なお、リソースごとに、Azure RBACの「スコープ」にできるのですが、管理があまりにも細かくなってしまうので、推奨されません。

管理グループ

説明を飛ばしましたが、サブスクリプションを束ねる「管理グループ」という概念があります。管理グループの利用は必須ではないのですが、これもRBACのスコープにできますので、環境によってはメリットが出てきます。

下記の公式ドキュメントによれば、サブスクリプションを階層的に管理することで、権限が整理しやすくなるとあります。

https://docs.microsoft.com/ja-jp/azure/governance/management-groups/overview

例えば、ルート管理グループをスコープに所有者ロールを付ければ、全体に対してなんでもできますし、ITグループに閲覧者権限を付ければその配下のサブスクリプション5つに対する参照権限となります。このサブスクリプション1つ1つにロールの設定を行うのはとても労力の無駄になるので、大規模な環境になればなるほど、使った方が良いです。

おわりに

ということで、1人のユーザーがリソースにアクセスできるまでの権限の仕組みを図解してみました。Azure分かってる人にとっては当たり前ですが、躓きやすいポイントだと思いますので、この記事が誰かの役に立てれば幸いです。