Microsoft Entra ID for Customers (顧客向け Entra ID) の顧客ユーザーの管理 - 作成、パスワードリセット、プロパティ、検索、ログ分析

:::note info
本記事は、[Microsoft Security Advent Calendar 2023](https://qiita.com/advent-calendar/2023/microsoft-security) に参加しています。
:::

# 本記事について

Microsoft Security Advent Calendar 2023 の下記記事にて詳細がまとめられておりますが、Microsoft Entra ID for Customers (顧客向け Entra ID) がプレビューリリースされ、今後マイクロソフトの CIAM ソリューションの中心を占めることになります。

https://qiita.com/daimat/items/bc58bc986e9b52c3fa79

まだプレビューリリースということもあり、ウェブ上にある日本語の情報も多くないため、本記事では Advent Calendar の一記事として、この Microsoft Entra ID for Customers について、特に顧客ユーザー (ローカルユーザー (メールアドレス・パスワード)) の管理について、 作成、パスワードリセット、プロパティ、検索、ログ分析という観点でまとめてみたいと思います。(Facebook や Google でログインするユーザーアカウントについては本稿では扱いません。)

公式ドキュメントにも様々な情報が載っていますが、ページごとに分かれていて必要な情報を見つけるのがやや難しくなっているかと思いますので、なるべく一つの記事で道標になるような内容になるようにしていきたいと思います。

https://learn.microsoft.com/ja-jp/entra/external-id/customers/overview-customers-ciam

まず顧客ユーザーアカウントの作成手順について見ていきます。

# 1. 顧客ユーザー (ローカルユーザー (メールアドレス・パスワード)) の作成

ローカルユーザー (Google や Facebook のユーザーではなく、Microsoft Entra ID for Customers で認証するユーザー) を作成する方法は主に２つあります。１つは、サインアップとサインインのユーザーフローで顧客が自身でサインアップする方法 (方法①)、もう一つは Entra ID の管理画面や Graph API などで管理者側で作成する方法 (方法②) になります。

一般的に、消費者向けアプリケーションの大半では、①の手法がとられるかと思います。ただ、対企業の顧客向けのアプリケーションで、別途利用登録があったユーザーにのみアプリケーションを使用させるようなケースでは、②の方法が利用可能かと思います。

以下では、その２つの方法についてそれぞれ簡単にまとめてみます。

## ① サインアップとサインインのユーザーフローによる作成

アプリケーションに Entra ID のユーザーフローを追加することで、顧客向けの簡単なサインアップとサインインのエクスペリエンスを作成することができます。

https://learn.microsoft.com/ja-jp/entra/external-id/customers/how-to-user-flow-sign-up-sign-in-customers

このユーザーフローで顧客がアプリにアクセスしたときに、顧客自身にアカウントのサインアップをさせることによって、ユーザーアカウントを作らせることができます。ユーザーフロー経由の場合は、サインアップ時にパスワードを設定させ、またユーザーフローの設定に従って属性情報を収集することができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/604cc978-c941-cc55-b297-61cf57f4c62a.png)

顧客は以下のような画面（[管理者側でカスタマイズ可能](https://learn.microsoft.com/ja-jp/entra/external-id/customers/how-to-customize-branding-customers)）でサインアップを行います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/af3d4084-4a2f-2eee-6bfa-8e51ef846196.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/66395afe-63a6-5a97-ba10-559f76ae73f8.png)

また、このユーザーフローでサインアップを禁止し、サインインのみ有効にすることもできます。Graph API を使って、ユーザーフローの `isSignUpAllowed` というプロパティを `false` に設定します。

https://learn.microsoft.com/ja-jp/entra/external-id/customers/how-to-user-flow-sign-up-sign-in-customers#disable-sign-up-in-a-sign-up-and-sign-in-user-flow

## ② 管理者による作成

管理者側でアカウントを作成し、一時パスワードを別途利用ユーザーに配布して、サインイン時にしパスワードを別途入力させる、という運用も可能です。Entra ID の管理画面で作成する場合、下記のような形で作成します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/30d5057a-5ce5-3de9-0e67-a688f7c1c836.png)


https://learn.microsoft.com/ja-jp/entra/external-id/customers/how-to-manage-customer-accounts#create-a-customer-account

また、Graph API を利用して作成することも可能です。実際に管理者側でアカウント発行を行うシナリオでは、Graph API (各言語の SDK) を利用して一括処理・自動化を行うことになるかと思います。

下記は簡単な実行例です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/e9fd4666-1767-b519-8869-e688ffd83f86.png)

実行結果として、下記のようなユーザーが作られます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/4e3ff807-5118-c96c-9ac8-223ac5fbb8fa.png)

公式のリファレンスは下記になります。POST する JSON の中身などについては、こちらでご確認ください。

https://learn.microsoft.com/ja-jp/graph/api/user-post-users?view=graph-rest-1.0&tabs=http#example-2-create-a-user-with-social-and-local-account-identities

次にユーザーがパスワードリセットをする方法について考えます。

# 2. 顧客ユーザー (ローカルユーザー) のパスワードリセット

パスワードリセットの手法に関して、顧客がログイン時にパスワードをリセットする方法（セルフサービスパスワードリセット）と、管理者側でパスワードをリセットする方法が挙げられます。前者はユーザーがアクセスする際にパスワードを忘れた時、後者はログインしたユーザーがなんらかの理由でパスワードを変更したいときなどに利用できるかと思います。

## ① サインイン画面でのパスワードのリセット（セルフサービスパスワードリセット）

ユーザーがサインインする画面で、パスワードをリセットすることができるようになっています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/f294aefc-2ffa-a655-1bbd-7f6e0847093f.png)

リセット用のコードが送信され、新パスワードをセットできます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/28a256f9-26ec-5ba5-2d53-99b97ba1afc2.png)

セルフサービスパスワードリセットは、会社のブランド化の既定のサインインエクスペリエンスの編集画面にて、ON/OFFの設定や表示テキストのカスタマイズが可能です。

https://learn.microsoft.com/ja-jp/entra/external-id/customers/how-to-customize-branding-customers#to-customize-self-service-password-reset

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/aa353ee4-194e-e1ba-c693-b1dc80254b0e.png)

## ② 管理者側でのパスワードの変更

もしくは、Entra ID 管理センターで個々のユーザーのパスワードを変更することもできます。こちらは一時的に利用できる新パスワードが発行され、次回ログイン時にユーザーが新規パスワードを発行する形になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/c3a852aa-9419-1308-2c7e-e2809aef6b97.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/b60c7cb1-3b6f-090e-8f6f-38bfd195743d.png)

こちらも Graph API を介して変更させることもでき、実際にはこちらを使ってアプリ側で受け取ったパスワード変更リクエストを処理する形になることが想定されます。`Update user` のリクエストにより実行できます。

https://learn.microsoft.com/en-us/graph/api/user-update?view=graph-rest-beta&tabs=http

公式ドキュメントの参考例をそのまま抜粋してみます。

```
PATCH https://graph.microsoft.com/beta/users/{id}
Content-type: application/json

{
  "passwordProfile": {
    "forceChangePasswordNextSignIn": true,
    "password": "xWwvJ]6NMw+bWH-d"
  }
}
```

また、以下、想定されるアプリケーションの簡易的な構成例になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/a080504f-7abc-5182-d51c-f3f3720d36d7.png)

# 3. 顧客ユーザーのプロパティと検索

次に、作成されたユーザーのプロパティがどのように値が入っているかと、それらの情報をアプリケーションからどう検索してどう扱えるかを見ていきます。

## ① 顧客ユーザーのアカウントのプロパティ

顧客向けの Entra ID のテナントもベースは従業員向けの Entra ID になっているため、CIAM としてみた時に少し癖がある情報登録になっています。

まず、ユーザーが作成されると、一意のオブジェクト ID を持つユーザーアカウントとして Entra ID ディレクトリに登録されるのですが、そのユーザープリンシパル名 (UPN) が `<オブジェクト ID>@<テナントのサブドメイン>.onmicrosoft.com` という形で設定されます。

そして、そのようなユーザーのプロパティが以下のような感じで管理センターから見えます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/d5d59caa-644f-824f-f40e-439d16e176da.png)

ひとつ問題として挙げられるのが、サインアップしたメールアドレスがこのプロパティ画面から見ることができないことです。ユーザーフローから作成したユーザーについては、下記の認証方法の画面からメールアドレスを確認することができます。（が、管理センターや Graph API から作成した場合は見えないようです。）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/ad624a32-6a55-77d7-05a9-8ce500f0eb7b.png)

メールアドレスの情報は、下記でご紹介する Graph API であればいずれの作成方法を取ったユーザーの場合でも確認可能です。

## ② プロパティ情報の検索と利用 - Graph API 

プロパティ情報をアプリケーションから検索し取得するには、Graph API を利用します。また、単に情報を参照する際も、管理センターよりも多くの情報を Graph API 経由で参照できます。

Graph API の利用の仕方については、公式情報の他、下記 Qiita 記事などを参照することができます。

https://learn.microsoft.com/ja-jp/graph/overview?view=graph-rest-1.0

https://qiita.com/massie_g/items/fe7540161aa4a5f86bf5

また、C#, Java, JavaScript/TypeScript, Python, PHP, Go など様々な言語用の SDK も公開されていますので、アプリケーション開発においても大いに利用できます。

https://learn.microsoft.com/ja-jp/graph/sdks/sdks-overview

ユーザーの情報の検索は、[`GET users/<オブジェクトID>または<UPN>`](https://learn.microsoft.com/ja-jp/graph/api/user-get?view=graph-rest-beta&tabs=http) で行えるのですが、取得できる情報は、Beta 版の Graph API のほうが情報が豊富です。

```
GET https://graph.microsoft.com/beta/users/<オブジェクトID>
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/7b71dd94-7664-dd8d-ec49-4e70a77c811b.png)

特に顧客ユーザーのサインインで利用される情報は、`Identities` の欄に書かれています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/8e0c6bb4-30ff-cd40-7fd3-6698c57626b3.png)

## (補足) ID トークンに含まれる情報

なお、アプリケーションに受け渡される ID トークンには以下のような情報が含まれています。メールアドレスは `preferred_username` に入っていることがわかります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/f3790d3a-2faa-13df-65ff-c25d510b4d85.png)

# 4. 顧客ユーザーのアクティビティのログの収集と分析

顧客ユーザーのアクティビティをトラックする方法は２つ挙げられます。ひとつは Entra 管理センターの組み込みのダッシュボードを利用する方法、もうひとつは診断設定でログをエクスポートして Azure Monitor / Sentinel や Microsoft Fabric で分析する方法です。

## ① Entra 管理センター - 使用状況と分析情報 - アプリケーションユーザーアクティビティ

まずは、組み込みのダッシュボードが Entra 管理センターに用意されています。使用状況と分析情報のアプリケーションユーザーアクティビティの画面で、ユーザー数の変遷や認証の内訳を簡単に確認できます。最初に利用開始するときには、諸々の情報の把握に便利です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/f022130f-3f44-5bda-1cd9-90de07efcc90.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/20b3a4d1-5960-286d-c75e-4d91b63236c3.png)

一方、より詳細なユーザーアクティビティの分析やセキュリティ利用には診断設定でのエクスポートが利用できます。

## ② 診断設定 (Log Analytics, Blob Storage, Event Hubs) によるログのエクスポート

従業員向けの Entra ID テナントと同じく、診断ログの設定から、Log Analytics ワークスペース、Event Hubs, ストレージアカウント (Blob Storage) へのログ送信が可能です。

ただし、顧客向け環境の注意点として、通常 Azure サブスクリプションは従業員向けテナント側で管理されることが挙げられます。そのため、一般的には顧客向けテナントに対して、従業員向けテナント側にあるサブスクリプションの権限移譲を Lighthouse を介して行う必要があります。これにより診断ログを別テナントにあるサブスクリプション上のリソースへ送ることができるようになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/6965695c-fee8-247d-d9a0-72c7885c9740.png)

簡単に下記の絵にアーキテクチャをまとめています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/19b5d198-36dc-4945-e750-4b4f5b0ea0ef.png)

大半のユースケースでは、サインインログや監査ログの第一の出力先オプションは ログ管理の容易さや Azure サービスとの連携に優れた Log Analytics ワークスペースになるでしょう。

### Log Analytics ワークスペース - Azure Monitor & Microsoft Sentinel

従業員向けの Entra ID と同じく、`SinginLogs` テーブルや `AuditLogs` テーブルにそれぞれサインインログや監査ログが出力されます。

Log Analytics ワークスペースに格納することで、Azure Monitor でアラートを発行したり、Microsoft Sentinel で脅威検知、インシデント調査、Workbook によるダッシュボード化したりすることができるようになります。また、すぐに検索可能な状態で長期間保存するという用途にも最適です。

以下、特に重要になるサインインログと監査ログについて、簡単に情報をまとめてみます。

#### サインインログ (SigninLogs)

`SigninLogs` テーブルで顧客ユーザーのデータを扱うときの注意点としては、さきほどプロパティのセクションでまとめたように、ユーザーアカウントの UPN が `<オブジェクトID>@<サブドメイン>.onmicrosoft.com` になるため、ユーザー ID として使われるメールアドレスを取得するには、`SignInIdentifier` か `AlternateSignInName` を参照する必要があることが挙げられます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/01151d22-607d-3f40-4423-3e21e094cad9.png)

`SigninLogs` のプロパティには、アクセス元ブラウザやOS、IP アドレスと地理情報など、豊富なデータが含まれています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/43353586-fef1-18c1-f547-0ec643e88e1c.png)

また、`SigninLogs` テーブルのログリファレンスは下記に公開されており、顧客向け Entra ID のログのケースでも同様に参照可能です。

https://learn.microsoft.com/ja-jp/azure/azure-monitor/reference/tables/signinlogs

#### 監査ログ (AuditLogs)

ユーザーの追加やパスワードリセットといったアクティビティを追跡するには、監査ログ (`AuditLogs`) を利用します。下記にユーザー追加とパスワードリセットのログ例を掲載します。

**<ユーザー追加の例>**
* ユーザーフロー経由

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/2d83da9b-f8c6-4bdd-2284-8518456ddfbd.png)

* Graph API 経由

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/c4b55e9a-2507-d478-f80a-4b476ccf7c3b.png)

**<パスワードリセットの例>**
* 管理者による変更

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/196b3d57-cad7-7ed3-929e-ad7b008111a6.png)

* ユーザーによる変更

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/a9013574-4fe5-2781-cf5c-f3e5bf5f05f2.png)

注意点として、ID 情報が UPN やオブジェクト ID で入ることが挙げられます。このあたりは、たとえば Sentinel で Watchlist を用いて別テーブルを作って `join` 句で参照するようにするなどの工夫が必要です。

AuditLogs のスキーマ情報の公式リファレンスは下記になります。

https://learn.microsoft.com/ja-jp/azure/azure-monitor/reference/tables/auditlogs

### ストレージアカウント - Microsoft Fabric

ストレージアカウントに JSON ファイルとしてログを出力することもできます。この方式では、ストレージアカウントを Data Lake v2 にしておくことで、Microsoft Fabric の Lakehouse からショートカットとしてデータを扱うことができます。

Microsoft Fabric にデータを集約することで、顧客向けアプリの網羅的なデータ分析環境を構築することが可能になります。たとえば下記のようなアーキテクチャを考えることも可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/d03f77de-8eb1-905d-40da-c30171747021.png)

Microsoft Fabric のショートカットで Data Lake v2 を接続した場合、ログファイルは下記のように参照できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/515ccf14-8c29-afdc-eea2-368f96d52449.png)

これを例えば、データパイプラインやデータフロー (v2) を用いてテーブルに移し、Power BI でレポート化することができます。

# 最後に

本記事では、Microsoft Entra ID for Customers (顧客向け Entra ID) について、特に顧客アカウントの管理について、ポイントとなる事項を見ていきました。本稿がこれから Microsoft Entra ID for Customers を利用する方々の一助となれば幸いです。

＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。