Microsoft Entra Identity Governance を 使って Microsoft Defender for Endpoint の運用アカウントを管理してみた

はじめましての投稿になります。私は普段、パートナーと協業する部門のセキュリティ担当なので、セキュリティの運用監視を外部に委託する（いわゆるSOC：Security Operation Center というやつです）際の相談をよく受けます。
その時「外部組織のSOC operator やSecurity Analystのアカウントをどう管理したらいいか？」という話になるのですが、
今回はその解の1つとしてMicrosoft Entra Identity Governance を使ったアカウント管理を紹介したいと思います。

## やってみたこと

Microsoft には デバイスの脅威を検知・対処するサービスとして Microsoft Defender for Endpoint (以下、MDE)を用意しています。
このMDEを対象としてセキュリティの運用監視を委託した会社(以下、委託元)と運用を委託された会社（SOC事業者、以下、委託先）の間のアカウント管理を実装していきましょう。
Microsoft Entra Identity Governance を使うことで、委託先からアクセスするSOCオペレーターのアカウントを細かく管理することができます。

![20221222_Image00.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/60423915-30ac-9668-d9c0-23c2179946e5.jpeg)


## 必要なライセンス

この機能を使うためには、Microsoft 365 ・ Azure Active Directory のライセンスを準備する必要があります。

#### 委託元で用意するライセンス

+ Microsoft Defender for Endpoint を利用できるライセンス
+ Azure Active Directory Premium Plan 2
    Microsoft Entra Identity Governance を利用するために必要となります。
    どういう役割の方にライセンスを割り当てるか、詳細は[こちら](https://learn.microsoft.com/ja-jp/azure/active-directory/governance/entitlement-management-overview#license-requirements)に記載されているので試してみたい方はぜひご一読ください。

#### 委託先で用意するライセンス

ライセンスの種類は問いません。**Azure Active Directory** を作成してそこにSOC Operetor のアカウントを作成しましょう。
（ライセンスの種類は問いません、と記載しましたが実際はいくつか考慮する点があります。そちらは最後にまとめます。）
お察しの方もいらっしゃるかと思いますが、委託先のSOC Operatorは委託元のゲストユーザーとして稼働します。ゲストユーザーに関するライセンスの考え方は[こちら](https://learn.microsoft.com/ja-jp/azure/active-directory/external-identities/external-identities-pricing)に記載されておりますのでご確認ください。
基本的には委託先のゲストユーザーのコストは委託元が負担する、と思っていただければよいかと思います。(2022年12月時点での情報)

## 受け入れ準備を整えましょう

### (委託元での作業) Azure AD で グループを作成する
さて、いよいよ作業に取り掛かります。ここで2つのグループを作成しましょう。
まず委託先のSOC Opererator が参加するセキュリティグループを作成します。
![20221222_Image01.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/e24ccec9-3b01-a20c-3d58-385beb9962a7.jpeg)
作成時にAzure AD ロールとメンバーの割り当ては不要です。 

もう１つグループを作りましょう。このグループは委託先のSOC Opererator の参加を承認するグループです。アクセスを要求してきたSOC Operetatorに対し、管理権限を承認するユーザーのグループです。
![20221222_Image07.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/56cd6277-f203-faef-599a-b13218d4416b.jpeg)

こちらのグループにはあらかじめ承認するメンバーを割り当てておきます。ここでは「Hiroko Sato」さんをメンバーに追加しました。


### (委託元での作業) Microsoft Defender for Endpoint での作業
#### Roleをグループに割り当てる
では続いて、MDE側でRoleをグループに割り当てていきます。この作業はMicrosoft 365 Defender で行います。
権限のあるアカウントで作業してください。
 ![20221222_Image02.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/5578e714-7193-74de-91a1-bc2ddd7a9f3f.jpeg)
[設定] - [エンドポイント] の順に進みます。

![20221222_Image03.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/e78d0947-43cc-e0a1-0eb0-a0b36c30ccaf.jpeg)
[ロール] - [アイテムを追加] の順に進みます。

![20221222_Image04.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/fc02b4b4-5487-c581-9a4f-8cdd093b891e.jpeg)
この画面でアクセスしてくるSOC operator に渡す権限を設定します。

![20221222_Image05.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/ac0dae46-dace-61f1-c299-62726e227e42.jpeg)

一つ前の作業で作成したSOC Opererator が参加するグループとの紐づけを行い、[保存]を選択します。
#### デバイスグループをグループに割り当てる
MDEの監視対象となるデバイスをグループに割り当てます。
![20221222_Image38.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/79196906-6cdc-be8e-599f-5c73a010832d.jpeg)
[デバイスグループ]から[グループ解除されたデバイス（固定）]を選択します。このデバイスグループは固有のグループが指定されていないデバイスが所属しています。
![20221222_Image37.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/08aef10c-819e-404f-69f4-27493cc69bc7.jpeg)
[ユーザーアクセス]の［Azure ADユーザー グループ］のタブから一つ前の作業で作成したSOC Opererator が参加するグループとの紐づけを行います。

これでこのグループに所属するメンバーは委託元のテナントのMDEを運用監視することができるようになります。


### (委託元での作業) Microsoft Entra Identity Governance で アクセス パッケージを作成する
さて、入れ物になるグループと管理権限の付与までは完了しましたが、このグループに所属するメンバーは現時点では誰もいません。
ここからは、Microsoft Entra Identity Governance を使った権限の割り当てを行っていきましょう。

#### 委託先の組織を接続する

まず最初に委託先が委託元にアクセスできるようにするために、組織の接続を行います。

![20221222_Image06.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/51306e8e-d0ce-a157-9a20-145342fdec25.jpeg)

[Identity Governance]の管理画面を開いて、[接続されている組織の追加] を選択します。

![20221222_Image08.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/4cf090fc-9a34-959d-88bf-3263a0b4abbb.jpeg)

名前と説明を記載します。

![20221222_Image09.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/171200bc-596e-63c0-0c11-751c4bb48dca.jpeg)

委託先のAzure AD ディレクトリを検索し、登録します。

![20221222_Image11.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/a3248413-1774-d165-7a82-20302661503d.jpeg)

構成を確認し、委託先の組織を接続します。

#### アクセス パッケージを作成する

アクセス パッケージとはアクセス権を持つユーザーの有効期限や承認者の指定、アクセス レビューを行うためのルールセットです。ここでは委託先のSOC operatorのアカウント ルールを作成していきましょう。

![20221222_Image12.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/1d2bad3e-fd39-aa9e-2645-5843b0ab2bb7.jpeg)

まず、新しいカタログを作成します。

![20221222_Image13.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/c620cef1-1a4b-7038-e44b-c6c57f700a9e.jpeg)

ここで[外部ユーザーに有効]を選択します。

![20221222_Image14.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/80b41814-2bc4-ef39-98c4-12728b0bdbc9.jpeg)

作成したカタログを選択し、アクセスパッケージを作成します。
![20221222_Image16.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/c024ebb1-89df-5da1-12c9-60f85a427d55.jpeg)

![20221222_Image17.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/5ce2092f-1b3d-cc9d-7d6e-ed99ea5d5254.jpeg)

アクセス パッケージの名前を説明を入力します。

![20221222_Image18.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/283962a8-9f7d-be64-4dec-8f1c9589f875.jpeg)
[リソース]タブで委託先のSOC Opererator が参加するセキュリティグループを選択します。ここでアクセス パッケージと対象になるグループの関連付けを行います。

![20221222_Image19.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/a67c510b-5aa2-3c53-c6bd-e888a3329fb5.jpeg)
アクセス パッケージの具体的なルールを指定します。まず外部ユーザーと対象となる外部組織を選択します。ここでは先に設定していた委託先の組織を選択しています。

![20221222_Image20.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/32648d23-d051-922e-c2de-fd7f8c03b6f6.jpeg)
次にアクセスを許可する承認者をここで設定します。

![20221222_Image21.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/9ec93fd6-ef1f-2ca3-5cdb-cab0d00faad9.jpeg)
ここではアクセスの有効期限とアクセスレビューを設定します。

![20221222_Image22.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/ba70ee2e-9a13-1671-114b-943651151f94.jpeg)
ここまででアクセス パッケージの作成は完了です。[作成]をクリックし、アクセス パッケージを作成してください。

![20221222_Image23.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/68c26b3e-fb36-d01f-53a4-d5e35e58ccad.jpeg)

アクセスパッケージには、アクセスを要求するアカウントの接続先が記載されています。委託元はこのURLを委託先に伝えてください。

## アクセス権の要求から承認まで

### （委託先での作業）アクセス権を申請する

ここからは、委託先（SOC Operator）側の作業となります。
![20221222_Image24.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/d8cf9019-692d-be6e-aea1-ea1ea1431033.jpeg)
SOC OperatorになったTaro Yamada さんは仕事として委託元のテナントにアクセスを試みます。アクセス先のURLは委託元から伝えられたURLになります。

![20221222_Image25.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/5075d22e-db18-dab1-0528-70b2decbe023.jpeg)
Taro Yamada さんは委託先のドメインに作られたアカウントを使ってサインインを試みます。ここで本人確認を行うのは**委託先のドメイン**になります。

![20221222_Image26.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/81377d04-9adb-c98e-edca-47765fe63199.jpeg)
Taro Yamadaさんは委託元のドメインに入ってアクセスを要求します。

### （委託元での作業）アクセスを承認する

ここからは、委託元側の作業となります。
![20221222_Image30.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/f420b9a8-0dfc-7f84-e470-a147815434ba.jpeg)
承認者として指定されたグループのメンバーにメールが届きます。メールの内容からTaro Yamadaがアクセスを要求していることがわかるので、ボタンをクリックして承認画面を表示させます。

![20221222_Image31.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/ee611dd2-4648-b34f-4aa6-41200a6b1e77.jpeg)
![20221222_Image32.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/1cfb153c-56c6-2f8a-e0cb-96926ac148ec.jpeg)

承認者は内容を確認し、承認を行います。

### （委託先での作業）申請結果の確認

![20221222_Image34.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/c1ab9f16-e2b5-cee9-afbe-bcb1aeb6a9b5.jpeg)
SOC operator の Taro Yamadaさんが再びアクセス画面に行こうとすると上の画面が表示されました。これは委託元ドメインでどういったアクセスが行われるかという確認と承諾になります。
![20221222_Image35.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/8832f716-4472-1b6a-d96e-de0e1a2d739f.jpeg)
要求の履歴を確認します。ここでTaro Yamada さんは自分の要求が承諾されたことがわかります。

## （委託先での作業）委託元のMicrosoft Defender for Endpoint へのアクセス

ここまでくればあと一息です。委託先のSOC operatorであるTaro Yamada さんは委託先のMicrosoft 365 Denfer にアクセスを試みます。
委託先のMicrosoft 365 Defender にアクセスするためには、URLでhttps://security.microsoft.com?tid=customer_tenant_id を指定します。テナントIDは委託元のテナントIDになります。

![20221222_Image36.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1259410/aa6a68ef-717a-0fe1-a3f3-0be27bbd6ebb.jpeg)
Taro Yamada さんは委託先のAzure ADに作成されたアカウントで委託元のMDEの運用管理作業を行うことができるようになりました。

## まとめ

### Microsoft Entra Identity Governance を使う理由

ここまで内容を追いかけてみて「直接Azure AD上で委託先のアカウントをゲストユーザーとして登録すればいいのでは？」と思われた方もいらっしゃるかと思います。確かにそちらの方法でも委託先のアカウントでMDEを運用することは可能です。
しかし運用者が数人のうちはそれでもよいのですが、SOC operatorや運用担当者が増えると毎回ゲストユーザーを登録する作業は煩雑になるかと思います。また委託先の人事異動やSOC オペレーターの退職に伴い、ゲストユーザーの削除・登録が発生することを考えると委託元のアカウント管理者にかかる負荷がかかることが容易に想像されます。
委託元が静的にゲストユーザーを登録することをやめて、委託先の運用担当者自身がアクセスを申請することで、アカウント管理者側での作業負荷を軽減することが可能になります。
この話の詳しい内容が[こちら](https://jpazureid.github.io/blog/azure-active-directory/access-management-with-access-package/) に紹介されていました。とてもわかりやすく紹介されておりますので気になった方はぜひご覧ください。

### SOC事業者 (委託先) で気を付けたほうがよさそうなこと

+ 委託先のSOC operatorを認証するのは**委託先のAzure AD**
流れからもわかる通り、SOC Operatorは委託先のAzure AD側で認証を行います。したがって、委託先の本人確認に問題があると不正アクセスのリスクが高まります。このリスクを軽減するためには委託先側で多要素認証を使って認証強度を高める、特定の場所以外からのアクセスを禁止する等を実施することが求められます。