[Azure AD] SC-300 合格のための必須キーワード「エンタイトルメント管理とは」1/2

この記事は @seafayさんが主宰する <a href=https://adventar.org/calendars/6173>Enterprise Mobility + Security（EMS） Advent Calendar 2021</a> に参加しています。

## Introduction

Azure AD の **Identity Governance** には 「**エンタイトルメント管理**」という機能がありますが、正直なところあまり認知されている気がしません。それもそのはず、Identity Protection や 特権ID管理（PIM）と同様、この機能は Azure AD P2 ライセンスが無いと使用することができないのです。

しかし、SC-300 を受験される方にとっては必須のスキルです。

ちなみに、エンタイトルメント管理機能は Azure AD の **Identity Governance** メニューから使用します。ぶっちゃけ、このリンククリックしたことがある方は非常に少ないのではないかと。。。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134539/332ce7bc-e180-76cc-8703-d8478af815c5.png)

この記事では、エンタイトルメント管理とはなんぞや? 何のために使うのか? について解説したいと思います。

## エンタイトルメント管理が想定するシナリオ

「エンタイトルメント」とは「**資格の付与**」のことです。つまり、「エンタイトルメント管理」とは、**アプリケーションへの資格の付与**を管理する機能のことです。ただし Azure 上の「資格」の管理機能はいろいろあって、このあたりが混乱を招く要因ではないかと思います。

そこでエンタイトルメント管理が想定するシナリオを、マイクロソフトの認定試験風に書いてみます（この問題が出るよということではありません。単に、シナリオを想定したほうが説明しやすいから。。。というだけのお話ですのでご注意を）。

> **想定シナリオ**
> あるプロジェクトを新たに開始するにあたり、プロジェクトメンバーにプロジェクトで使用するリソースへの権限を割り当てる必要があります。 
> プロジェクトには、社内からだけでなく**社外の協力会社**からも参加します。 
> プロジェクトで使用するリソースは以下の通りです。   
> - コラボレーション用に使用する Teams と SharePoint サイト
> - プロジェクト用に開発された WEB アプリケーション 1
> - プロジェクト専用に開発された WEB アプリケーション 2  
>
> WEB アプリケーション1 には **member** と **admin** という 2 つのアプリケーションロールが設定されています。
> WEB アプリケーション2 にはアプリケーションロールは設定されておらず、Azure AD のセキュリティグループのメンバーシップによってアクセス権が管理されています。
>
> 上記リソースには社内だけでなく社外から参加したメンバーもアクセスするため、権限管理は適切に行われなければなりません。
> また、メンバーはアドホックに変更されるため、社内や社外を問わず申請ベースの権限付与機能や、定期的なメンバーシップのレビュー機能が求められています。

上記のシナリオを満たすために使用するのが **エンタイトルメント管理** です。

## 基礎知識の整理

シナリオからすべてが理解できた方は、はやいところ <a href=https://docs.microsoft.com/ja-jp/learn/certifications/exams/sc-300>SC-300</a> 試験を受験してください。合格の確率が非常に高いと言えます。

シナリオの意図は、簡単に言ってしまえば **新しいプロジェクトのメンバーシップ管理とそれに伴うリソースへのアクセス管理を適切に、かつ簡単に行いたい** ということです。

上記シナリオの中で注目していただきたい点をいくつかここで確認しておきましょう。

### リソースへのアクセス権管理の考え方

まずはアクセス権管理の基礎的な概念の話から。

リソースに対するアクセス権を考える場合、「**認証と認可の分離**」の原則を常に意識してください。これを具体的に実装したものが **RBAC - Role-based Access Control** と呼ばれ、Azure 上のアクセス管理にも採用されています。

言うまでもありませんが、**認証** するのは Azure AD です。Azure AD はユーザーを認証し、**トークン**を発行します。そのトークンには、

- ユーザーの属性
- グループのメンバーシップ
- ユーザーに割り当てられた Azure リソースロール(所有者や共同作成者 など）
- ユーザーに割り当てられた Azure AD ロール（全体管理者やセキュリティ管理者 など）
- アプリケーションロール（アプリケーションに独自に実装されたロール。詳細は後述。）

などが含まれています。

認証基盤としての Azure AD は、ユーザーがどのような**権限**を持っているかは知りませんし、知ったことではありません。その代わりユーザーに割り当てられている「アプリケーションロール」や「グループのメンバーシップ」は知っています。それがトークンに組み込まれてアプリケーションに渡されます。

アプリケーションはトークンを受け取り、その中からアプリで使用する情報を取り出します。例えば、**admin** というアプリケーションロールがトークンに入っていたとして、それをどう解釈するかはアプリケーションの勝手です。言葉通り「アプリケーションの管理者」として判断するのであれば、それに紐づく**権限** をユーザーに割り当てれば、ユーザーは管理者としてアプリ上でふるまうことができます。

<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134539/ba1017ad-bcb0-f147-c2e3-166a9c51cd9d.png width=500 />

もしアプリケーションが**グループのメンバーシップ**でアクセス権を管理しているのであれば、ユーザーは事前にグループの一員になっておく必要があります。

Azure AD は認証基盤という役割以外にも、アクセス権を決定するための情報（ロールやグループのメンバーシップ）を集中管理するという役割があり、**エンタイトルメント管理** は、その集中管理された情報を適切にユーザーに割り当てる役割を担っています。

<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134539/908d6403-8a8a-ef67-f78c-e0c4e36c19f0.png width=500 />

### Teams と SharePoint へのアクセス管理

シナリオの中で Teams と SharePoint サイトを使用することが明言されており、それらのアクセス権を管理したいという意図が見えます。

Teams や SharePoint のアクセス権のチェックは以下の2段階に分かれていると考えると理解しやすくなります。

Step1 : TeamsチャネルやSharePointサイトにアクセスできるかどうか
Step2 : どんな管理権限を持っているのか

このシナリオでは管理権限までは言及していませんので、誰がTeamsチャネルやSharePointサイトにアクセスできるのかを管理したいのであろうことがわかります。

よって Step1 がこのシナリオのターゲットであり、最も簡単に Teams や SharePoint サイトへのアクセスを許可する方法は、言うまでもなく **Microsoft 365 グループ** を使うことです。Microsoft 365 グループのメンバーになることで、簡単に、そこに紐づけられた Teams サイトや SharePoint サイトへのアクセス権を取得することができますし、逆にメンバーから削除することでアクセス権を削除することができます。

- <a href=https://docs.microsoft.com/ja-jp/MicrosoftTeams/office-365-groups>Microsoft 365グループとMicrosoft Teams</a>
- <a href=https://support.microsoft.com/ja-jp/office/sharepoint-%E3%81%A7%E3%83%81%E3%83%BC%E3%83%A0-%E3%82%B5%E3%82%A4%E3%83%88%E3%82%92%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B-ef10c1e7-15f3-42a3-98aa-b5972711777d>SharePoint でチーム サイトを作成する</a>

### アプリケーションロール（アプリロール）によるアクセス管理

**アプリケーションロール（アプリロール）**とは、Azure AD に登録されたアプリケーションに対して設定されたロールです。アプリケーションロールは、Azure AD 管理画面の **アプリ登録** でアプリケーションを作成後、以下の画面から設定することができます。

<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134539/02d9c338-c361-e32a-a8f8-8ddefc736a60.png width=600 />

ここで設定したロールをユーザーに割り当てることで、ユーザーに対して発行されたトークン内にこのロールが書き込まれます。
アプリケーションはトークンを受け取り、そこに書き込まれたロールを参照することで、ユーザーがどのようなロールを持っているかを判断し、そのロールに割り当てられている権限をユーザーに与えることができます。

よって、アプリケーションは事前に「ロールの判定方法」や「ロールと権限のマッピングを参照」するロジックをコードの中に実装しておく必要があります。Azure AD はあくまでもロールの割り当てだけを知っており、その権限までは管理していません。

このように、RBAC に対応したアプリケーションは、アプリケーション側でユーザーと権限をマッピングする必要がありません。間に**ロール**を介することで、Azure AD 側で「ユーザーとロール」、アプリケーション側で「ロールと権限」を個別に管理することができます。

### セキュリティグループのメンバーシップによる権限管理

アプリケーションロールと同様、グループのメンバーシップもトークンに含めることができます。

これは、Azure AD に登録されたアプリケーションの「トークン構成」画面で設定することができます。

<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134539/57df5a38-4546-c952-d82b-4226ccf5ae05.png width=600 />

言うまでもありませんが、アプリケーションには、やはりトークンを介して伝達することができます。アプリロール同様、アプリケーション側には、このロールをどのように権限に結び付けるかを実装しておく必要があります。

## Azure IAM との関係

Azure には、**エンタイトルメント管理**がリリースされる以前から RBAC によるアクセスコントロール機能が実装されていました。誤解しないでいただきたいのは、エンタイトルメント管理は IAM を**置き換えるものではない** ということです。

IAM は、Azure リソースロールと Azure AD ロールを使用して、サブスクリプションや Azure AD に対するアクセス権を管理する機能です。

この記事で話題にしているのは「Azure AD で管理されているアプリケーションに対するアクセスコントロール」であり、IAM とは別の機能であることに注意してください。

<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134539/e5102d11-1d01-5468-4fe6-38efaa3eda4a.png width=600/>

いかがでしょうか？
次々と新しい機能が追加される Azure AD なので、そのキャッチアップには苦労しますよね。
でも、SC-300 受験者には必須の知識ですので、かならず押さえておきましょう。

次の記事（作成中）で、エンタイトルメント管理のより具体的な説明と操作方法について解説します。