##Introduction
最近頻繁に聞かれる質問の１つに「サブスクリプションと Azure AD の関係」があります。ここに、リソースグループやら、リソースやら、ロールやら、挙句の果てには RBAC（Role-Based Access Control） なんていう言葉も絡んでくるのでわけがわからなくなります。公式ドキュメントを読んでもいまいちわかりずらい。
でも、これを理解しないとリソースを安全に保護することはできません。
まずは以下の記事を読むことをお勧めします。
Azure サブスクリプションと Azure AD の管理者
https://blogs.technet.microsoft.com/jpazureid/2017/11/04/azure-subscription-azuread-admin/
##「サブスクリプション」という言葉に惑わされてはいけないww
混乱する原因は「サブスクリプション」という言葉なのかもしれません。
確かに耳慣れないし、概念として頭に入ってきづらいです。「サブスクリプション」の説明を探すと、以下の記事がヒットします。
説明: Azure サブスクリプションとは
https://docs.microsoft.com/ja-jp/azure/architecture/cloud-adoption-guide/adoption-intro/subscription-explainer
うーん、なんか、わかったようなわからないようなwww これは、サブスクリプションが「営業的」な側面で語られることが多いからなんですよね。だから表現がなんだかアヤフヤになってしまう。なんせ、サブスクリプションってのは支払いの単位でもあるので。
そこで、話をすこし技術寄りにしましょう。
「Azure サブスクリプション」＝「アプリケーション＋データ」だと考えてください。
結局のところ、Azure AD が登場するってことは「アクセスコントロール」を行いたいわけです。アクセスコントロールの世界での登場人物は、大きく分ければ以下の 4 つです。
- 利用者（サブジェクトとも言ったりしますが、この場合はこれを読んでいる皆さんのこと）
- 認証基盤（Identity Provider とか Claims Providerとか、いろいろ言い方はありますが、面倒なので認証基盤にしときましょう）
- アプリケーション（リライングパーティとかサービスプロバイダーとか、いろいろ言い方はありますが、面倒なのでアプリケーションに統一しときます）
- データ（アプリケーションからアクセス可能なデータ）
関係を図にすると、以下のようになります。
Azure AD でユーザー認証をして、サブスクリプションというアプリを使う。。。ただこれだけの話です。実に単純なことなのです。
##サブスクリプションと Azure Portal
サブスクリプションとAzure ADの関係について深堀する前に Azure Portal について触れておきます。
サブスクリプションには、契約情報や課金情報、利用可能なAzureの機能とか、そんな情報がいっぱい詰まったデータ群が含まれています。そして、それらにアクセスして使うためのアプリケーション群が用意されています。
そのアプリケーション群を一元的にとりまとめてアクセスしやすくしているのが、「Azure Portal」です。サブスクリプションのフロントエンドに立っているイメージです。
Azure Portal も例外なく「アプリケーション」です。くどいですが、アプリケーションにアクセスするには認証が必要です。その認証を行うための基盤（認証基盤）が Azure Active Directory、略してAzure AD です。
言ってみれば、Azure Portal は「サブスクリプション」の「ログイン画面」であると言えます。
##マイクロソフトアカウントとAzure AD のアカウント
ここで、「マイクロソフトアカウント」の話をしておきましょう。マイクロソフトアカウントとは、古くは Live IDとかHotmail アカウントなどと言われていた、マイクロソフトが提供する SNS 用のアカウントです。
マイクロソフトには大きく分けて2つの認証基盤があります。
1つが マイクロソフトアカウント用認証基盤、もう一つが Azure AD です。
以下のような画面を見たことがありませんか？
「職場または学校のアカウント」とは、Azure AD に登録されたアカウントのことです。「組織アカウント」と呼ばれることもあるので、これがまた混乱を招く原因になっています（ほんと恐縮です。。。。orz）。
「個人のアカウント」とは「マイクロソフトアカウント」のことです。
わかりやすくしたつもりが、エンジニアにとっては逆にわかりずらくなった。。。。典型的な表現例ですね。。。
##サブスクリプションとマイクロソフトアカウント
前節で「Azure Portal を使用するには Azure AD にアカウントが無ければいけない」という話をしました。でも、中にはマイクロソフトアカウントで Azure Portal を使用している人もいるかもしれません。
「どういうこと?」と疑問に思いますよね。
試しに、新しいマイクロソフトアカウントを作成して https://portal.azure.com/ にログインしてみると、以下のように Azure Portal のトップ画面が表示されます。
でも、何もできません。ただ画面が表示されただけなのです。
試しに、Azure AD を確認してみましょう。
左側のメニューから「Azure Active Directory」を選択してください。以下のような画面が表示されるはずです。
「ユーザー」をクリックすると、驚くことに誰もいません。
でも、f8cdef31-a31e-4b4a-93e4-5f571e91255a という「テナントID」が発行されていることから、Azure AD のテナント（ディレクトリ）は自動的に作成されていることがわかります。本来は、テナントIDが表示されている部分には、microsoft.onmicrosoft.com といったドメイン名が表示されるはずです。しかし何の設定や契約行為も行っていないので、ドメイン名は割り当てられていません。
さらに、左側のメニューの「全てのサービス」をクリックし、中央から「サブスクリプション」を選択してみてください。
サブスクリプションが”紐づいていない”ことがわかります。
画面の上部にある「追加」をクリックすると、以下のような画面に遷移して、新規にAzureを契約（サブスクライブ）することができます。
ここまでで説明した”状態”を絵にすると、以下のような感じです。
なんとも中途半端な状態になっていることがわかります。
これを”正しい状態”にするには、上の画面で示した通り「サブスクリプションの追加」という操作をする必要があります。これにより、以下のことが行われます。
- Azure AD にテナント名（ドメイン名、ディレクトリ名）が割り当てられる
- サブスクリプションが作成される（アプリとデータが使用できるようになる）
- サブスクリプションが Azure AD と紐づく
- マイクロソフトアカウントが Azure AD に招待（同期）され、マイクロソフトアカウントと Azure AD との間で ID フェデレーションが構成される
- 招待されたマイクロソフトアカウントが Azure AD の「全体管理者」になる
- 招待されたマイクロソフトアカウントがサブスクリプションの「所有者」になる
これを絵にすると、こんな感じです。
この図の「認証」の矢印に注目してください。Azure AD に招待（同期）されたにもかかわらず、認証はマイクロソフトアカウント側で行っていることがわかります。これについては、「アイデンティティ フェデレーション」を理解している方であればご承知の通りです。「同期」されて「フェデレーション」されたID（この場合マイクロソフトアカウント）は、認証自体は従来通りマイクロソフトアカウント側行われます。
その後、認証された結果は Azure AD 側に提示され、Azure AD にフェデレーションされたIDがあることを確認後、Azure サブスクリプション用の新しい「チケット（トークン）」が発行されます。
このチケットをサブスクリプションに提示することで、サブスクリプションにアクセスすることができるようになります。
ちなみに、Azure AD に招待（同期）されたマイクロソフトアカウントは、マイクロソフトアカウントで使用しているIDのままでは管理されていません。Azure AD 上では以下のような ID で管理されています。
junichia_hotmail.com#EXT#@pharaojp.onmicrosoft.com
EXT は External の略で、外部ユーザーを意味しています。@ 以降は、Azure AD のテナント名（ドメイン名）です。
##次の投稿では。。。
前節で、サブスクリプションを作成したアカウントは、以下の2つの役割が与えられるという話をしました。
- Azure AD の「全体管理者」
- サブスクリプションの「所有者」
この部分も、多くの方が混乱しているところだと思います。
次回は、ユーザーに与えられる「ロール」について書きたいと思います。