More than 5 years have passed since last update.

Azure サブスクリプション、リソース、ロール、Azure AD の関係その2

Last updated at 2018-07-09Posted at 2018-07-09

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番目にあります。

各ロールをクリックして、[説明]を参照すると、ロールに割り当てられた権限を参照することができます。