いちばんやさしい Azure 認証・認可編 後半

## はじめに
本記事は2部構成での「いちばんやさしい Azure 認証・認可編」の後半になります。
前半記事（1章～6章）は以下をご参照ください。

https://qiita.com/KoheiKushida/items/cbf06c17db79d697568f


以降は、前半記事の続きになるので、7章から入ります。

## 7.Microsoft Entra ID に関連する主要サービス
これまでの説明の中で Microsoft Entra ID の認証を重点的に説明しましたが、ここからは認可機能を重点的に説明します。

まずは、前半記事の最後に登場した詳細図の言葉の説明から入ります。

これまでの説明の中で登場していない言葉として、Microsoft Entra ID 内の Microsoft Entra テナント（ディレクトリ）、サブスクリプション、リソースグループがありますね。
※Microsoft Entra テナントとディレクトリは厳密には別物になりますが、説明記事の都合上、ひとまとめにしています。
※認可機能内の Entra ロール（グローバル管理者）や Azure RBAC（所有者、共同作成者、閲覧者）は後続で説明するので、ここでは無視してください。
※以降の説明図では Microsoft Entra ID での認証機能（ユーザー）を前提に説明しており、認証機能（マネージドID、サービスプリンシパル）は図から除外します。
　
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3815275/5b675723-6fd6-c201-50da-8edd02e98104.png)

|サービス名（または機能）|概要|
|:-----------------|:------------------|
|Microsoft Entra ID|Azure での認証・認可機能 や ID 管理機能などを提供するサービス|
|Microsoft Entra テナント（ディレクトリ）|Microsoft Entra ID サービス内の構成要素の一つ。様々な機能があるが、ユーザーやサブスクリプションの紐付けを行う機能|
|サブスクリプション|Azure での契約、課金の単位。サブスクリプション配下にリソースグループを構成することで、様々な Azure サービスを構成可能|
|リソースグループ|Azure サービスを管理する単位。リソースグループ構成後に、自由にその配下へその他 Azure サービスを構成可能|
|Azure サービス|リソースグループ配下の Azure サービス　例：Azure VM|

ここでは、記事の本筋から逸れてしまうため、簡単な説明に留めますが、数行の説明では非常に分かり難いですね。。
需要がある場合は、今後専用の記事を書ければと思います。

## 8.Microsoft Entra ID での認可機能
前半記事の復習になりますが、認可機能の種類としては大きく2種類存在します。

1.Entra ロール
2.Azure ロール（Azure RBAC または Azure ABAC）

接続先のサービスの種類によって、どちらのロールを使用するかが異なります。
詳しく見ていきましょう。

### 8.1.Entra ロール
Entra ロールとはユーザーへ Microsoft Entra テナントに対する役割（権限）を割り当てる認可機能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3815275/4e7df860-0909-5a83-a7a7-c28cc32f27ba.png)

前半記事では、特定サービスに接続する際、認可機能が必要という説明をしましたが、今回の接続先は Microsoft Entra ID サービス内の Microsoft Entra テナントになります。
なぜ、Microsoft Entra テナントに接続する必要があるかというと、Microsoft Entra ID の機能の一つに ID 管理（ユーザーの管理等）があり、その機能の利用には Microsoft Entra テナントへの接続が必要なためです。
※Microsoft Entra テナントは様々な機能の利用で接続するので、ここでの説明は一例としてご理解ください。
　
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3815275/2443b162-81aa-07c0-eea0-785db525fa3a.png)

ID 管理の例として、Microsoft Entra ID での新規ユーザーの作成や既存ユーザーの削除などを行う場合があり、その操作を行うための認可機能として Entra ロールが提供されています。

以下の図は、とあるユーザーの Azure 太郎さんが Microsoft Entra テナントを操作（Azure 花子さんというユーザーを作成）する流れ図になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3815275/88e5c547-0681-2c64-a16a-8bbf4ec70bec.png)

上記の図において、Microsoft Entra ID に接続してくる人のユーザー（Azure 太郎さん）は、Microsoft Entra ID 内で Azure 太郎さんを予め登録してあるので、Microsoft Entra ID での認証は成功します。
さて、図内の①～②全ての処理が進むと Azure 太郎さんは目的の Microsoft Entra テナント に接続できると思いますか？
　
前半記事で同じ問いかけがありましたが、答えはノーです。
なぜなら、Azure 太郎さんは Microsoft Entra ID により、Azure 太郎さんであることは判断（識別）されましたが、目的の Microsoft Entra テナントに接続するための役割（権限）を持っておらず、接続が拒否されてしまうためです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3815275/1922baa7-9ea2-76a1-4300-4b72ec0b2935.png)

このままの状態では Microsoft Entra テナント に接続できませんね。困りました。どうしたら良いでしょうか。。
　

　
前半記事と同じ考え方ですが、必要な機能は「認可」です。
Microsoft Entra テナントに対する認可機能である Entra ロールを利用します。

以下の図では、ユーザーの Azure 太郎さんに対して、認可機能の Entra ロールである"グローバル管理者"の役割（権限）を割り当ててあげました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3815275/349e8f6a-af89-d032-1a4f-256ddfc6d58a.png)

グローバル管理者とは、Microsoft Entra テナント上の全ての操作が可能な Entra ロールになり、最も強い役割（権限）になります。例えば、Microsoft Entra ID でのユーザーの作成や削除などを行うことが可能です。

上記の役割（権限）を持つ Azure 太郎さんは自由にユーザを作成することができ、今回は Azure 花子さんを作成することが可能になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3815275/d95e1f79-8630-2e35-bc31-c72fbd84dbfa.png)

Entra ロールを割り当て後のユーザーの作成イメージが湧かない方は、Azure ドキュメントをご参照ください。
　
タイトル名：新しいユーザーを作成する
https://learn.microsoft.com/ja-jp/entra/fundamentals/how-to-create-delete-users#%E6%96%B0%E3%81%97%E3%81%84%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%92%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B
　
また、今回の例では、代表的な Entra ロールである"グローバル管理者"を説明しましたが、上記の他にも数多くの Entra ロールが提供されているので、必要に応じて使い分けることになります。

Entra ロールの一覧は、Azure ドキュメントをご参照ください。
https://learn.microsoft.com/ja-jp/entra/identity/role-based-access-control/permissions-reference

### 8-2.Azure ロール
Azure ロールとはユーザーへ Azure サービスに対する役割（権限）を割り当てる認可機能です。

また、Azure ロールは Azure RBAC（Role Based Access Control）、
Azure ABAC（Attribute Based Access Control）の2種類に分類することが可能です。

#### 8-2-1.Azure RBAC
特定サービスに接続する際、認可機能が必要でしたが、Azure ロール（Azure RBAC）が必要になる接続先はどこになると思いますか？

Entra ロールでは、接続先が Microsoft Entra ID サービス内の Microsoft Entra テナントでしたね。
　
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3815275/594e79b7-5de3-106f-04ee-9523fed63454.png)

今回、新たに登場する Azure ロール（Azure RBAC）は接続先が Azure サービス になります。
図にする場合、以下の通りです。
　
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3815275/87eaae8b-8f77-effa-ac35-468aeebf3843.png)

ここでもイメージしやすいように具体例を用います。
以下の図は、とあるユーザーの Azure 太郎さんが Azure サービス の Azure VM を操作（インスタンスの変更等）する流れ図になります。
　
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3815275/d19e7b80-5abc-1c68-a328-4533cded8e30.png)
　
これまでの説明と同じ考え方ですが、Azure 太郎さんは Microsoft Entra ID により、Azure 太郎さんであることは判断（識別）されましたが、目的の Azure VM に接続するための役割（権限）を持っておらず、接続が拒否されてしまいます。

もうお分かりと思いますが、ここで必要な機能は「認可」です。
ここでは、Azure VM（Azure サービス）に対する認可機能である Azure ロール（Azure RBAC）を利用します。

Azure ロール（Azure RBAC）とは、サブスクリプション以下（厳密には管理グループ以下）の Azure サービスに対する認可機能です。
　
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3815275/7f9a52ef-5dd8-e1df-4fc7-06a651c54c35.png)
　
以下の図では、ユーザーの Azure 太郎さんに対して、認可機能の Azure ロール（Azure RBAC）である"所有者"の役割（権限）を割り当ててあげました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3815275/8b0343e5-dcbb-a33a-248e-2fd86b3ad199.png)

所有者とは、割り当て先の Azure サービス上の全ての操作が可能な Azure ロール（Azure RBAC）になり、最も強い役割（権限）になります。例えば、他のユーザーに対して、Azure ロール（Azure RBAC）の割り当てなどが可能です。

今回の場合、上記の役割（権限）を持つ Azure 太郎さんは、自由に Azure サービスの Azure VM を操作することができるようになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3815275/0d676068-d170-2958-49ca-f3885f30cafa.png)


Azure ロール（Azure RBAC）は、Entra ロールと同じく数多くのロールが提供されていますが、主要なロールとしては3種類存在します。

|ロール名|概要|
|:-----------------|:------------------|
|所有者|対象の Azure サービスを管理するためのフル接続が可能なロール。また、Azure RBAC の割り当てが可能|
|共同作成者　|対象の Azure サービスを管理するためのフル接続が可能なロール|
|閲覧者|対象の Azure サービスの閲覧が可能だが、追加・変更・削除の操作ができないロール|

Azure ロール（Azure RBAC）の一覧は、Azure ドキュメントをご参照ください。
https://learn.microsoft.com/ja-jp/azure/role-based-access-control/built-in-roles
　

　
また、Azure ロール（Azure RBAC）を利用する上での重要な機能に"スコープ"があります。
スコープとは、認可機能である Azure ロール（Azure RBAC）を割り当てる範囲のことを指します。

スコープは、4つの階層から構成されており、上位階層にスコープを割り当てた場合、下位階層に継承されます。
（管理グループ > サブスクリプション > リソースグループ > Azure サービス）

例えば、サブスクリプションに対して Azure RBAC（権限：所有者）を割り当てた場合は、
下位階層のリソースグループ、Azure サービスの全てに所有者が継承されるということです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3815275/96605586-80f6-5342-1bd4-ab682624990b.png)


#### 8-2-2.Azure ABAC
Azure ABAC とは属性に基づいて役割（権限）を割り当てる認可機能です。
Azure RBAC より更にきめ細かな制御をする場合に利用します。
例：Azure Storage（BLOB）サービスで BLOB ファイル単位にアクセス制御を行いたい場合

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3815275/3c2cc9a7-6f60-e988-0c90-96de1029613f.png)

2022年10月に一般提供されたものの、対象サービスが少ないなど、まだまだ発展途上の機能だと考えています。
筆者自身も利用経験がなく、ここでは紹介程度に留めます。

Azure ABAC の利用シナリオは、Azure ドキュメントをご参照ください。

タイトル名：条件のシナリオ例
https://learn.microsoft.com/ja-jp/azure/role-based-access-control/conditions-overview#example-scenarios-for-conditions

# 9.おわりに（後半の部）
以上がいちばんやさしい Azure 認証・認可編（後半）の説明になります。
後半の部では、Microsoft Entra ID での認可機能の説明を重点的に行いました。

筆者自身、実業務の中で Azure での認証・認可の説明を求められる場合がありますが、口頭や Web 情報の内容では相手に伝わりにくく、説明に困ることが多々ありました。
例えば、認証・認可を混同されていたり、認可機能の Entra ロールや Azure ロールを同じ位置付けで理解されていたりする場合などです。

きっと、世の中でも同じような境遇の方がいらっしゃるのではと思うので、本記事を参考にしていただければと思います。
※記事の内容に誤りがある場合は、優しくコメントいただけますと幸いです。

皆さん、快適な Azure ライフを！

## We Are Hiring!

https://www.biprogy.com/recruit/recruiting/