1.はじめに
皆さんは、Azure で提供される認証・認可についてご存知ですか？
ピンとくる方は、Azure での認証・認可 = Microsoft Entra ID を思い浮かべると思いますが、複雑で完全に理解できていない方もいらっしゃるのではと思います。
もちろん、私もその一人です！
実業務の中で Azure の認証・認可を調査する機会があったので、本記事にて筆者自身の頭の整理を行いつつ、読者の方と一緒に理解を深めていきたいと思います。
また、今回は「いちばんやさしい Azure 〇〇」というタイトルにしており、説明量が多くなることを想定し、前半/後半の2部構成とします。
もし、途中まで読んでみて、理解できない。。内容が難しい。。となってしまった方は、以下の記事をご参照ください。
タイトル名：IT 知識ゼロから始める Azure 学習の進め方
https://qiita.com/KoheiKushida/items/8600540939bf11a32966
※投稿目的の一つとして、筆者自身の認証・認可の理解を深めたい点があるので、内容に誤りがあればコメントをいただければと思います。
2.そもそも認証・認可ってなに？
まずは、言葉の定義を知るところから始めてみます。
Google 先生に聞いてみると、ニュアンスは Web 情報により異なりますが、このような定義です。
認証：通信相手が誰なのか判断（識別）する機能
認可：通信相手に対して役割（権限）を割り当てる機能
うーん。何となく言ってることは分かるけど、理解しにくいので、
それぞれの機能について具体例を交えながら整理してみます。
まずは、「認証」についてです。
認証というのは、何らかのサービスへ接続する前に誰からの接続かを判断（識別）する機能になります。
以下は、とあるサービス A に接続したい Azure 太郎さんを認証サービスで判断（識別）する際の流れ図になります。
補足ですが、認証サービスは接続する人を判断（識別）する機器（サーバなど）とここでは理解してください。
認証サービスに予め接続してくる人の情報（Azure 太郎さん等）を登録しておくことで、認証サービスが知ってる人かを判断（識別）する仕組みになります。
その為、認証サービスに登録のない人は接続してきた人のことを認証サービスは知らないので、「認証」は失敗します。今回の図では、認証サービス内に登録のある "Azure 太郎"さんと "Azure 花子"さんのみが「認証」に成功するということです。
さて、話を戻しますが、図内の①～②全ての処理が進むと Azure 太郎さんは目的のサービス A に接続できると思いますか？
答えはノーで、以下の図の通りサービス A への接続は失敗します。
なぜなら、Azure 太郎さんは認証サービスにより、Azure 太郎さんであることは判断（識別）されましたが、目的のサービス A に接続するための役割（権限）を持っておらず、接続が拒否されてしまうためです。
このままの状態ではサービス A に接続できませんね。困りました。どうしたら良いでしょうか。。
そこで、必要な機能が「認可」です。
認可というのは、「認証」で誰なのかを判断（識別）した後に、その人に対して必要な役割（権限）を割り当てる機能です。
先程の図を一部更新し、Azure 太郎さんに認可サービスを利用して、サービス A に対する役割（権限：読み取り）を割り当ててあげました。こうすることで、サービス A に Azure 太郎さんは接続できるようになります。認可サービスは認証サービスと同じく機器（サーバなど）を指しますが、同一機器で認証・認可の両方の機能を提供する場合もあります。
ここまで、広義的な認証・認可の説明を行いましたが、このような認証・認可という考え方はクラウド（Azure）でも同じ仕組みが提供されています。
認証・認可の理解をより深めたい方は、Microsoft 社の公式 URL に認証・認可の違いの説明があるので、こちらも合わせてご参照ください。
https://www.microsoft.com/ja-jp/security/business/security-101/what-is-authentication#authorization
3.Azure での認証・認可基盤の全体像
さて、ここからは Azure での認証・認可の全体像について整理します。
まずは、Azure で利用する認証・認可機能は主要なもの（具体的な機能・サービス）として、以下の2種類があります。
①Active Directory
②Microsoft Entra ID
オンプレ環境（サーバ）や Azure サービスを利用する方は名称として聞いたことがあると思いますが、①・②はそれぞれ重要な認証・認可機能を提供する機能・サービスになります。
この2種類は何が異なるの？というのが気になる所ですが、異なる点としては認証・認可機能の提供範囲になります。
| 機能・サービス名 | 認証・認可の提供範囲 | 利用例 |
|---|---|---|
| Active Directory | 社内ネットワーク | ドメイン内のリソースでの認証・認可 |
| Microsoft Entra ID | クラウドサービス | Azure サービスでの認証・認可 |
まとめると上記の通り、Active Directory は社内ネットワーク上にあるリソースに対して、Microsoft Entra ID はクラウドサービス（Azure サービス）に対して、適切なユーザ（認証機能で誰かを識別）に特定のリソースやサービスの利用を許可（認可機能で識別した人に権限を割り当て）するために必要な認証・認可基盤です。
※Microsoft Entra ID は厳密には Azure サービスを問わず、複数のクラウドサービス（M365等）で認証・認可機能を提供するサービスになりますが、本記事では説明をシンプルにするため、Azure サービスに対する認証・認可サービスとしております。
※Microsoft Entra ID は旧名 Azure Active Directory（Azure AD）になります。
3-1.実例ベースの提供範囲の説明
Active Directory は社内ネットワーク、Microsoft Entra ID は Azure サービスで認証・認可機能を提供すると説明しましたが、ここでは Azure 上の Azure Virtual Machines（以降、Azure VM）を例に説明します。
読者の皆さんが、Azure 上で Azure VM を構成する場合は、Azure Portal の GUI や IaC などの方法で構成し、構成後も同様の方法で何らかの作業（Azure VM に対するインスタンスの変更やマネージドディスクの追加等）を実施するかと思います。このような作業は Azure サービスに関する操作になりますので、利用する認証・認可機能は Microsoft Entra ID にて提供されます。
一方で、Azure VM 上で実際に稼働するワークロード（ゲスト OS の Windows Server 等）はオンプレ環境上のサーバと何ら変わりませんので、ワークロードに関する操作（Windows Server への RDP 等）で利用する認証・認可機能は Active Directory にて提供されます。
イメージとしては以下の図の通りですが、ご自身で構築および検証してみると、理解が深まるかと思います。
4.Microsoft Entra ID での認証
ここからは Microsoft Entra ID での認証機能の説明ですが、イメージしやすいように認証・認可の言葉の定義の説明で利用した流れ図を交えつつ、説明します。
認証サービス、サービス A という言葉がありましたね。
上記の図を Azure 上の言葉に置き換えた図へ更新します。
※シナリオとしては、とあるユーザーの Azure 太郎さんが Azure サービスの Azure VM 操作を行う場合の流れ図になります。
更新後の名称、図は以下の通りです。
| Azure でのサービス名 | |
|---|---|
| 認証サービス | Microsoft Entra ID |
| サービスA | Azure VM |
上記の図でイメージしやすくなったと思いますが、認証サービスが Microsoft Entra ID 、サービス A が Azure サービス（Azure VM）になるだけです。
Microsoft Entra ID に接続してくる人のユーザー（Azure 太郎さん）を予め作成しておくことで、Microsoft Entra ID での認証が成功します。その後、認可機能を用いて、Azure 太郎さんに適切な役割（権限）を割り当てることで、Azure VM に接続できるという流れになります。
尚、実際の設定（ユーザーの作成）は Web サービス画面（GUI）での操作の場合、Microsoft Entra 管理センター > ID > ユーザーの画面にて行います。
※前文の Microsoft Entra ID で接続してくるユーザーを作成する際の設定箇所
Azure ドキュメントで具体的な手順が整理されているので、合わせてご参照ください。
4.1.認証相手の分類
一般的な定義の中では、通信相手が”誰”なのか判断（識別）する機能という定義で説明したため、読者の方は通信相手が”人”が前提なんだと解釈されたのではないでしょうか。
厳密には、Microsoft Entra ID では”人”の判断（識別）はもちろんのこと、その他コンピュータの判断（識別）も行うので、認証相手としては大きく3種類存在します。
| 認証機能名 | 利用者 | 作成方法 |
|---|---|---|
| ユーザー | 人 | Microsoft Entra ID 上で作成 |
| マネージド ID | Azure サービス | Azure サービス上の設定画面より有効化 |
| サービスプリンシパル | Azure サービス外のサービスや機器 | Microsoft Entra ID（アプリ登録）で有効化 |
上記の通り、Azure が誰（人や各サービス）からアクセスがあったのかを判断（識別）するための Microsoft Entra ID 内の認証機能として、ユーザー、マネージドID、サービスプリンシパルが提供されています。
マネージド ID、サービスプリンシパルの説明がやけにあっさりしているな？と思った方がいらっしゃると思いますが、既に分かりやすい説明記事がありましたので、詳細はやまぱん！（@aktsmm）さんの記事をご参照ください。
タイトル名：Azure のワークロードID (マネージド ID とサービスプリンシパル) を整理する
https://qiita.com/aktsmm/items/a50a9a75a99c49c87ed7
5.Microsoft Entra ID での認可
それでは最後の Microsoft Entra ID での認可機能の説明ですが、Microsoft Entra ID での認証では以下の図になりましたね。
上記の図のままでは、Azure 太郎さんは Microsoft Entra ID により、Azure 太郎さんであることは判断（識別）されましたが、目的の Azure VM に接続するための役割（権限）を持っておらず、接続が拒否されてしまいます。
そこで、認可機能を利用します。
認証機能と同様に Microsoft Entra ID により、認可機能は提供されているため、Azure 太郎さんに対し Azure VM の接続に必要な適切な役割（権限）を割り当てることで、目的の Azure サービスの Azure VM へ接続が可能です。
こちらで Microsoft Entra ID での認証・認可の説明は以上です！
と締めたいところですが、認証機能と同じく、Microsoft Entra ID での認可機能には複数の種類があり、それぞれの用途を理解する必要があるため、筆者自身、ここからの理解が非常に重要だと考えています。
まずは、認可機能の種類ですが、大きく2種類存在します。
1.Microsoft Entra ロール（以降、Entra ロール）
2.Azure ロール（Azure RBAC または Azure ABAC）
これまでの流れ図に取り入れる場合、図内（赤枠）にある Microsoft Entra ID での認可機能の扱いになります。
Azure ドキュメントでも概要説明があるので、合わせてご参照ください。
タイトル名：Microsoft Entra ID でのロールベースのアクセス制御の概要
https://learn.microsoft.com/ja-jp/entra/identity/role-based-access-control/custom-overview
これまで説明した Microsoft Entra ID での認証・認可機能を詳細な図にしてみました。
馴染みのない言葉が多いなと感じる場合があると思いますが、ここまでの説明に登場していない Azure サービス（Microsoft Entra テナント、サブスクリプション等）があります。これらの Azure サービスは認証・認可を理解するのにどれも重要なサービスになるため、後半の部で認可機能に合わせて簡単に説明ができればと考えています。
6.おわりに（前半の部）
以上がいちばんやさしい Azure 認証・認可編（前半）の説明になります。
前半の部では、広義的な認証・認可や Azure 上で提供される認証・認可の具体的な機能やサービス、Microsoft Entra ID での認証機能の説明を行いました。後半の部では、Microsoft Entra ID での認可機能について、重点的に説明したいと思います。
後半記事（7章～9章）は以下をご参照ください。
タイトル名：いちばんやさしい Azure 認証・認可編 後半
https://qiita.com/KoheiKushida/items/1ca534588cfc1b32d828
皆さん、快適な Azure ライフを！
We Are Hiring!