＜目次＞
(１) Azure AD（Azure Active Directory）とは？簡単に概要をご紹介
(１-１) ひと昔の認証の仕組み（Active Directoryが無い時代）
(１-２) Azure ADの概要
(１) Azure AD（Azure Active Directory）とは？簡単に概要をご紹介
みなさまは社内のMS系のサービス（例：Teams、SharePoint、OneDrive、Azure）や各種SaaS（Salesforce、Confluenceなど）を利用する際に、下記のような認証を求められた事があると思います。
（図１０１）
（図１００）
（図１００）
これらはAzure ADの機能で実現されています。本記事ではAzure ADとは何か？について、イメージが湧くように概要をなるべく簡潔にご紹介する事を目的にしています。
(１-１) ひと昔の認証の仕組み（Active Directoryが無い時代）
Azure ADの話に入る前に、少しだけ一昔前の認証の仕組みについて簡単に触れておきます。１０年前頃は、システムごとに独自に認証機能を実装していた時代でした。各システムで、それぞれ自身のDBを持ち、システムごとにユーザーID管理や認証データをそれぞれのDBに保持していました。
（図１１１）昔のやり方の流れ
・①利用者（クライアント側）はログイン画面等からid/passを入力
↓
・②サーバ側でデータベースと通信して認証を行う
↓
・③サーバ側からクライアント側に、認証の結果を返却
これはセキュリティ機能を開発・追加・改修する際に非常に時間とコストが掛かる上に、セキュリティのリスクが高まる（認証情報が散らばる）リスクもあり、現代では推奨されないアプローチになっているという背景があります。加えて、ユーザー観点でも、複数のID・パスワードを記憶する必要があり、利用者の負担にもなります。
(１-２) Azure ADの概要
Azure ADは「クラウドベース」で「①IDプロバイダー（認証）」と「②アクセス制御」の中央集中管理をするサービスです。組織が提供する各種サービスへのログイン時に設定します。Azure ADの認証を経由して、各種サービスを利用している方も多いと思います（SSO機能）。
「①IDプロバイダー（認証）」機能
クラウドサービスにアクセスする「ユーザーの認証情報」を保存・管理するサービスです。ユーザーの場合は「ユーザーID・パスワード」、アプリの場合は「シークレットキー」や「証明書」などです。
・①クライアント⇒Azure ADへ「認証情報」を渡します
⇒サーバではなくAzure ADに送る
↓
・②Azure AD⇒クライアントへ「トークン」（※注２）を渡します
⇒暗号化されたクライアントと、その認証情報に関する情報
↓
・③クライアント⇒サーバ（SaaS等）へ「トークン」を渡します
⇒ID/パスワードの代わりにトークンを渡します。
↓
・④⑤サーバ（SaaS等）⇒Azure ADと通信し、トークン認証に必要な情報を取得します。
⇒サーバ（SaaS等）はAzure AD内で「信頼されたアプリ」として登録されています。
↓
・⑥サーバ（SaaS等）にてトークン認証を実施
↓
・⑦サーバ（SaaS等）⇒クライアントに結果を通知
（図１１２）
（ポイント）
・昔のやり方で問題であった「認証情報を各システムで独自に保持する」必要がなくなる
⇒各種サービスにおいては、Azure ADへ「信頼済サービス」として登録を行うだけで済みます。
⇒つまり、アカウント管理部分をAzureにアウトソーシング出来ることになります
⇒システム運用者としても、負担が減ります
・１度取得したトークンは各システムへのログインで使いまわす事ができる（SSO）
⇒クライアントはid/passを1セット覚えるだけで、全てのサービスが利用できる
・Azure ADのセキュリティ機能を利用できる。近年ではMFAなども利用できる
・外部に対してAPI等を公開する際にも、Azure ADを通じての認証を要求する事も可能です
⇒APIがよりセキュアになる
（図１１３）トークンは使いまわせる
「②アクセス制御」機能
アクセス制御は、認証されたユーザーやアプリに対して「アクセス権限」を制御・検証・追跡・管理するプロセスです。AzureではRole Base Access Control（RBAC）などと呼ばれます。
今回は例として、ある担当者Aさんが仮想マシンへのWrite権限を必要としている際に、管理者Bさんが権限を付与の設定をするまで流れをご紹介します。
・①担当者Aさんが「ストレージアカウント」への「Write権限」をリクエスト
（図１２１）①
↓
・②管理者Bさん側のロール割当て操作
・「ストレージアカウント」の「Access controll（IAM）」ブレードを選択
↓
・「ロールの割当の追加」を選択
↓
・割り当てる「ロール」と割り当て対象の「メンバー」を選択
（図１２１）②
↓
・③この時、選択した「ロール」と「メンバー」はいずれもAzure ADのオブジェクトとして存在しています。
（図１２１）③
※Azure ADではロールやメンバーやグループといった定義の１つ１つを「オブジェクト」と呼ぶ。
※Azure ADではロールやメンバーやグループといった定義の１つ１つを「オブジェクト」と呼ぶ。
↓
・④この「ロール」と「メンバー」の組み合わせも「ロールアサインメント」というオブジェクトとしてAzure ADに設定されます。これが対象のストレージアカウントに付与されます。
（図１２１）
(１-３) オマケ：用語補足
（表）
| ユーザー Users |
Azure AD管理下のユーザーを登録できます。組織内は「ユーザー」、組織外は「ゲストユーザー」として登録可能 |
| グループ Groups |
・グループは「ユーザーの集合体」です。 ⇒組織に応じた、必要なメンバーの集合 ・各「グループ」単位で「権限を付与」する事が出来ます。 |
| ロールと管理者 Roles and administrations |
・ロールは「権限の集合体」です。 ⇒役割に応じた、必要な権限の集合 ・各ユーザーに対して、ロール単位で付与が可能です。 |
| エンタープライズアプリケーション | ・エンタープライズアプリケーションのユーザー管理 |
| アプリの登録 App Registrations |
・外部アプリをAzure ADに対して接続する「クライアント」として登録し、Client IDやClient Secretを用いた接続を可能にする |
| Azure AD Connect | ・オンプレミスのActive Directoryとの同期機能 |
