Introduction
Azure サブスクリプションと Azure AD の関係に関する解説の続きです。前回は以下をご覧ください。
Azure サブスクリプション、リソース、ロール、Azure AD の関係 その1
https://qiita.com/junichia/items/e8cf118314a173efcb68
前回書いたとおり、Azure を契約するとサブスクリプションが作成され、そのアクセスコントロールをするために Azure AD が紐づきます。
最初のユーザーに与えられる権限
Azure サブスクリプションを契約するプロセスの途中に、認証基盤である Azure AD の「テナント名」を設定する画面があります。テナント名を「hogehoge」と指定すると、以下のような DNSドメインが作成されます。そして、サブスクリプションにアクセスするユーザーの認証基盤として設定されます。
hogehoge.onmicrosoft.com
後半の onmicrosoft.com は規定値であり変更することはできません。ただし、hogehoge.com のようなカスタムドメイン名を後から指定することが可能です。
Azure を契約する際に使用したユーザーID（メールアドレス）は、新しく作成したテナント（ドメイン）の記念すべき”第1号ユーザー”として自動的に登録されます。
その際、以下の”ロール”が自動的に割り当てられます。
- Azure AD テナントの”全体管理者”
- サブスクリプションの”所有者”
なんとなくイメージできると思いますが、最初のユーザーに強い権限が割り当てられるのだなぁ。。。ということが何となくわかるでしょう。
前回も使用したものですが、絵にすると以下のようになります。
気を付けなければならないのは、ユーザーに”権限”が直接割り当てられるのではなく、”ロール”が割り当てられるという点です。この方式を RBAC（アールバック）と言いますが、これについて以降で少しずつ解説していきます。
”認証”と”認可”の分離
RBAC（Role-Based Access Control）について話す前に、思想的な話を少しだけ。
ユーザーがITを使用する場合、なんらかの「権限」を持つ必要があります。俗にいうアクセス権ってやつです。
アクセス権にはレベルがあります。「管理者」「一般ユーザー」だけでなく「社長」「部長」といった役職も権限に影響します。さらには、参加している「グループ」も権限を判断する材料になるでしょう。
権限はアプリケーションごとに異なります。メールサーバーであれば、「自分のメールを読む権限」が無ければ電子メールを読むことはできません。ファイルサーバーであれば「フォルダに書き込む権限」が無ければファイルを保存することができません。
こうした権限は、基本的にシステム（サービス、アプリケーション）ごとに管理されており、認証されたユーザーに権限を与えることを「認可（Authorization）」と呼びます。
では、「認証（Authentication）」は誰が行うのでしょう？
従来は、以下に示す通り「認可」を与えるサービス自身が「認証」を行ってきました。
しかし、システムが増えるにしたがって以下のような問題が発生し、悩まされてきたことはご存知の通りです。
- ユーザーIDとパスワードが統一されていない
- 認証の強度がシステムによって異なる
- システムごとのユーザー管理やアクセスコントロールが煩雑
- 組織変更や異動が速やかに反映されない
そのため、多くの組織では認証基盤を統一する方向に進んでいます。
このことは必然的に、ユーザーを識別する「認証基盤」と、ユーザーを認可する「サービス側」が分離されることを意味します。
これが「”認証”と”認可”の分離」です。
認証を、専用の認証基盤に任せることで、システム間で一定品質の認証が行えるようになります。パスワードポリシーをはじめとする認証ポリシーが統一されるからです。
また、認証基盤が統一されるので、認証の品質を高めるための投資を集中できるというメリットもあります。ワンタイムパスワードや多要素認証などの機能追加には高額な投資が必要ですが、統合された認証基盤であれば1回だけで済みます。
もちろん、Azure サブスクリプションでも認証と認可は分離されています。
RBAC（ロールベースのアクセス制御）
RBAC とは、ユーザーの”ロール”によってアクセス権を決定する方法です。
以下の図で上に書かれているのは DAC（discretionary access control）と呼ばれ、アクセスする主体に直接アクセス権を付与する方式です。この方式のデメリットは「誰が、どこにアクセスできるのか」をシステム側で個別に管理しなければならないことです。この方式はユーザーが増えたり、システムが増えてくると、運用コストが一気に増加します。設定ミスも発生しやすく、一度与えた権限をはく奪しわすれたために情報漏洩が発生。。。といった問題も起こりやすくなります。
一方、RBAC ではユーザーには直接アクセス権を与えません。上の図にも書かれている通り、ユーザーには「ロール」を割り当て、「ロール」に「権限」を割り当てます。
ユーザーとロールのマップは認証基盤側が管理します。何をもってロールとするかは設計に依存しますが、以下のような属性をロールとして採用する場合が多いです。
- ユーザーの Role（役割）属性
- ユーザーの Title（肩書）属性
- ユーザーが参加しているグループ
- など
一方サービス側（上の図ではサブスクリプション）ではロールと権限のマップを持ちます。これによって、ユーザー認証後に発行された「トークン」内にロールが格納され、それをサービスが受けとることでユーザーの権限を決定することができます。
ユーザーと権限が直接紐づいていないため、RBAC には「アクセスポリシー」として表現しやすいというメリットがあります。どういう役割を持っていれば何ができるのか? というポリシーを作成し、それをそのままシステム上に反映しやすくなります。
また、ユーザーのロールを変えれば権限も変わるというメリットもあります。
DAC の場合、アクセス権を変更するには大量のシステムを個々に修正しなければなりませんでしたが、RBAC であれば認証基盤側でロールの割り当てを変更するだけで済みます。
Azure AD とサブスクリプションの関係においても同様のことが言えます。
”Azure AD の全体管理者”と”サブスクリプションの所有者”
Azure AD の全体管理者とサブスクリプションの所有者とは、言い換えれば、
- Azure AD の全体管理者 → 認証基盤の管理者
- サブスクリプションの所有者 → サービス全体のオーナー
ということになります。
全体管理者は Azure AD というリソースに対して、ユーザーなどの編集や削除、他人への権限付与も含め、全ての権限を持っています。
また、所有者はサブスクリプションに対して、同様に全ての管理権限を持っています。
Azure AD の管理権限
Azure AD は認証基盤ですが、それを管理しようとすればなんらかの「管理アプリ」や「管理API」が必要になります。
つまり、Azure ADの中でも、認証と認可の分離の原則が成り立っています。
Azure AD にどのような管理ロールが用意されているのか確認してみましょう。
Azure ポータルの左側のメニューから[Azure Active Directory] ー[ロールと管理者] を選択します。
画面中央に表示されているのが、Azure AD で使用可能なロールの一覧です。Exchange 管理者や Intune 管理者など、それらのサービスを契約していなければ使用できないロールに加えて、アプリケーション管理者やパスワード管理者なども用意されています。つまり、一般ユーザーにこれらのロールを割り当てることによって、権限を分散させることができるわけです。
全体管理者は下から2番目にあります。
各ロールをクリックして、[説明]を参照すると、ロールに割り当てられた権限を参照することができます。
赤線を引いたところには、以下のような文字列が書かれています。
microsoft.aad.directory/AdministrativeUnit/AllActions/AllProperties
microsoft.aad.directory は、リソースの提供元を意味しており、ここでは Azure AD 自身のことです。これをリソースプロバイダーと言います。
AdministrativeUnit は、Azure AD 配下のリソースの1つです。
AllActions は”全てのアクション”を意味し、”AllProperties”は全ての属性を意味します。
つまり、
Azure AD の AdministrativeUnit に対して、すべての操作を全ての属性に対して実行可能
という意味になります。
そのほかの例として、以下は”アカウント管理者ロール”に割り当てられている権限の1つです。
microsoft.aad.directory/Group/Update/Members
言うまでもありませんが、これは、Azure AD 内のグループに対して、メンバーを更新する権限 を意味しています。
このように、各ロールは細かな権限の集合体です。こうした細かい権限を個別にユーザーに割り当てるのは非常に効率が悪いですし、ミスも発生しやすくなるであろうことをご理解いただけると思います。
サブスクリプションの所有者
サブスクリプションの最も偉い権限が「所有者」です。
実際にどのような権限が与えられているのか確認してみましょう。
Azure Portal で[サブスクリプション]-[<サブスクリプション名>]-[アクセス制御（IAM）]を選択します。
右側に表示されているのは、現在割り当てられているロールとユーザーです。
割り当て可能なロールの一覧を参照するには、上の「役割」を選択します。
以下の画面の左側に「アクセス許可（プレビュー）」が表示されていますが、全てのリソースプロバイダーに対して全ての権限が付与されていることがわかります。
それぞれのリソースプロバイダーを選択すると、以下のように、どのような権限が用意されているかを細かく参照することができます。
既定で用意されている組み込みロールの一覧は以下のリンク先を参照してください。
組み込みロールの一覧
https://docs.microsoft.com/ja-jp/azure/role-based-access-control/built-in-roles
ロールは個別に定義することも可能です。カスタムロールの作り方については、以下を参照してください。
Azure のカスタムロール
https://docs.microsoft.com/ja-jp/azure/role-based-access-control/custom-roles
TIPS: サブスクリプションは階層構造
サブスクリプションには階層構造があり、かならず以下の構造になります。
そして、上位の階層で設定したロールは、既定では下位の階層にも継承されます。
各階層でのアクセス権の設定は、サブスクリプション同様に「アクセス制御（IAM）」で設定することができます。
TIPS: 招待したユーザーがサブスクリプションを参照できない
よく、「ユーザーはAzure AD に存在するのにサブスクリプションにアクセスできない」と困っている方がいます。多くの場合、これはサブスクリプションに対する権限を持っていないことが原因です。サブスクリプションの IAM でロールを割り当ててあげましょう。