ID インフラストラクチャをセキュリティ保護する 5 つのステップを読み解く

#はじめに
今から書く内容は、Microsoft の公開情報である「ID インフラストラクチャをセキュリティ保護する 5 つのステップ」の内容をかみ砕いて書いています。

-参考情報
ID インフラストラクチャをセキュリティ保護する 5 つのステップ
URL:https://docs.microsoft.com/ja-jp/azure/security/fundamentals/steps-secure-identity

以下の設定を施したからといって、セキュリティ保護が万全になるわけではありません。
逆に以下の設定を必ずしもすべて設定しないといけない、というわけでもありません。

この記事を書いた意図としては、ID を正しく保護するための方法が複数用意されているので、ご利用の環境に合わせて選択していただくための一助にして欲しいからです。

下記 Microsoft 公開情報にベストプラクティスとして書かれている記事がありますので、そちらも参考にしてみてください。

-参考情報
Azure の ID 管理とアクセス制御セキュリティのベスト プラクティス
URL:https://docs.microsoft.com/ja-jp/azure/security/fundamentals/identity-management-best-practices

#推奨アクションについて

設定を検討して欲しい項目は以下のとおりです。

| 項目     |      機能名 |  ライセンス     |備考|
|:-----------------|:------------------|:------------------|:------------------|
| 資格情報を強化する 1.          |             セキュリティ デフォルト| Azure AD Free             | 特定の管理者のみ、多要素認証の要求方法が限定的|
| 資格情報を強化する 2.       |           条件付きアクセス|    Azure AD Premium P1 以上   | Azure AD 上で ID 管理をするならほぼ必須な機能|
|   資格情報を強化する 3.    |             パスワード保護|  Azure AD Premium P1 以上      | クラウド ユーザーのグローバル禁止パスワード機能のみ Free で使える|
|資格情報を強化する 4.         |           スマート ロックアウト| Azure AD Free      |ロックアウトの規定値をカスタマイズする場合は Azure AD Premium P1 以上必要 |
| 攻撃の対象となる領域を減らす 1.         | 条件付きアクセスでレガシー認証をブロック |  Azure AD Premium P1 以上    |AD FS を利用している場合は AD FS 側の設定も必要 |
| 攻撃の対象となる領域を減らす 2.        | ユーザーの同意操作を制限する (Admin Consent) |   Azure AD Free   | |
| 攻撃の対象となる領域を減らす 3.        | Azure AD Privileged Identity Management |   Azure AD Premium P2  | |
|脅威への対応を自動化する           | Azure AD Identity Protection |   Azure AD Premium P2 推奨    |リスク ポリシーを設定するためには Azure AD Premium P2 ライセンスが必要|
|クラウド インテリジェンスを利用します  |  Azure AD サインイン ログ、監査ログ、Azure AD Identity Protection のイベント ログ|   ライセンスにより監視できる期間が異なる        | |
| エンドユーザー セルフサービスを有効にします        | セルフサービス パスワード リセット| Azure AD Premium P1 以上推奨     | クラウド ユーザー限定で Office 365 ライセンスでリセット可能だが機能が限定的|

#####  資格情報を強化する 1.   「セキュリティ デフォルト」

セキュリティ デフォルトは Azure AD Premium がなくても特定の管理者ユーザーに対して多要素認証を要求できる機能になります。
ただし、多要素認証の要求方法が Microsoft Authnticator アプリにより通知に限定されるため、スマート フォーンを持っていない場合多要素認証の要求に応えられないため、認証が完了することができません。

電話番号を利用した、通知、もしくは電話による認証を希望する場合は後述する条件付きアクセスを利用してください。

-関連する公開情報
セキュリティ デフォルトとは
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/fundamentals/concept-fundamentals-security-defaults

設定箇所は、「Azure ポータル」→「Azure Active Directory」→「プロパティ」→「セキュリティの期待値の管理のリンクをクリック」すると表示される下記「セキュリティの規定値の有効化」を「はい」に変更し「保存」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/69005a8d-e62b-00de-af0f-9d8eb69d3fe9.png)

上記設定をした後に、管理者ユーザーでサインインすると、下記画面ショットのように Microsoft Authenticator で応答する旨の画面に遷移し、応答した後にアプリケーションにサインインできます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/84fe015c-5f51-da6d-91c1-63891bfa7d21.png)

セキュリティ デフォルトで多要素認証が要求させる管理者ロールは下記のとおりです。

>
全体管理者
SharePoint 管理者
Exchange 管理者
条件付きアクセス管理者
セキュリティ管理者
ヘルプデスク管理者またはパスワード管理者
課金管理者
ユーザー管理者
認証管理者

また、この機能は条件付きアクセスと組み合わせて利用することはできません。
この機能を有効にすると条件付きアクセスで多要素認証の設定ができなくなりますし、逆に条件付きアクセスで設定済みの場合は、セキュリティ デフォルトの機能は有効化できません。

あくまで Azure AD Free ライセンスのみ持っているテナント用の機能だと思ってください。


#####  資格情報を強化する 2.   「条件付きアクセス」

Azure AD を触ったことがある人は知らない人はいないというほど有名な機能です。
多要素認証の要求だけではなく、デバイス、場所、アプリケーション、ユーザー単位などに対して、多要素認証の要求、アクセス ブロック、追加の要件を要求させるなど、非常に柔軟な機能を持ち合わせているサービスです。

-関連する公開情報 (ドキュメントが多いので Index ページを紹介)
Azure AD 条件付きアクセスのドキュメント
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/conditional-access/index

Azure Active Directory 条件付きアクセスによるアクセス制御の概要
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/conditional-access/controls

例えば、Azure AD 上の特定のアプリケーションにアクセスする際に、多要素認証を要求させたい場合には、下記画面ショットのように「アクセス制御の項目」で「多要素認証を要求する」のチェックボックスを有効にすることで、実現可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/a2057640-c884-28dc-2345-d119f9a750a2.png)

#####  資格情報を強化する 3.   「パスワード保護」
パスワード保護の機能は、ユーザーが簡単に推測できるようなパスワードを設定させないように、Microsoft が非公開として予め設定されている「グローバル禁止パスワード」と管理者がテナント単位に個別に禁止パスワードを設定できる「カスタム禁止パスワード」を組み合わせることで、悪意のあるアクターからのアカウントの侵害を防ぐための対策の 1 つとして用意されている機能です。

Azure AD Free ライセンスでは、クラウド ユーザー限定でかつ「グローバル禁止パスワード」のみしか利用できないので、オンプレミス AD から ID を同期している環境および「カスタム禁止パスワード」を利用する場合には、Azure AD Premium P1 以上が必要になります。

-関連する公開情報 
組織内の不適切なパスワードを排除する
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/authentication/concept-password-ban-bad

カスタム禁止パスワードの設定は「Azure ポータル」→「Azure AD パスワード保護」で表示される以下画面ショットの「カスタムの禁止パスワードの一覧」の項目で行います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/efdd25bc-c83b-e62d-e2df-683be209a305.png)

グローバル禁止パスワードに引っかかると以下の画面が表示されて入力したパスワードの設定ができません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/68eb09e8-af81-42c0-656b-60447b82dff1.png)

カスタム禁止パスワードに引っかかると、下記画面ショットのように組織で禁止されているパスワードを入力していることが指摘されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/1b10b5b7-6f89-86cf-8783-87e13b50dfc1.png)

#####  資格情報を強化する 4.   「スマート ロックアウト」
スマート ロックアウトはブルート フォース対策として、悪意のあるアクターがパスワードをリスト型アタックを利用して侵入を試みる行為を自動的にロックアウトさせることで、攻撃を遮断させる機能になります。

この機能の良いところは、管理者側が何も設定しなくても内部的に機能してくれる点があります。
細かい動作は公開情報を見て欲しいのですが、デフォルトの設定では、ユーザーもしくは悪意のあるアクターがパスワード入力を 10 回失敗した段階で、 1 分間ロックアウトされます。

スマートロックアウトはデータセンター側に「既知の場所」と「未知の場所」のロックアウト カウンターが用意されていて、それぞれのカウンターが 10 に達した時点でロックアウトされます。

従って、通常悪意のあるアクターは「未知の場所」からアタックを仕掛けてくるので、「未知の場所」のカウンターが 10 に達しても、「既知の場所」のカウンターが 10 に達していなければ、正しいユーザーは正しくパスワードを入力すれば問題なくアプリケーションにアクセスできます。
上述のロックアウトされる閾値「10」を変更したい場合、もしくはロックアウトの時間「60秒」を変更したい場合には、Azure AD Premium P1 以上のライセンスが必要になります。

-関連する公開情報 
Azure Active Directory のスマート ロックアウト
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/authentication/howto-password-smart-lockout

スマート ロックアウトの設定は、「Azure ポータル」→「Azure AD パスワード保護」で表示される、下記画面ショットの「カスタムのスマート ロックアウト」の項目で設定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/28d90eb2-e32d-6934-b11f-ec7dd9a4a949.png)

スマート ロックアウトでロックアウトされると下記画面ショットのように正しいパスワードを入力しても一時的にサインインできなくなります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/8504eba9-c3ae-9891-9ef5-d9b71cadd7cc.png)

#####攻撃の対象となる領域を減らす 1.   「条件付きアクセスでレガシー認証をブロック」

レガシー認証を利用しているアプリケーションは、POP 3 クライアント、IMAP4 クライアント、SMTP クライアントなどのプロトコルを利用して認証をするため、上述で触れている多要素認証を強制することがプロトコルとしてできません。

このあたりの話については、私の過去の記事にて言及しているので参考にしてみてください。

-参考情報
[日本語訳][個人的解釈]Azure AD Mailbag: Discovering and blocking legacy authentication
URL:https://qiita.com/Shinya-Yamaguchi/items/fc1add86a8985e8cbe8f

-関連する公開情報 
方法:条件付きアクセスを使用して Azure AD へのレガシ認証をブロックする
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/conditional-access/block-legacy-authentication

設定箇所は、「Azure ポータル」→「条件付きアクセス」より、条件の項目内の「クライアント アプリ」にて、「他のクライアント」を有効にします。これで、レガシー認証を利用してアクセスしてきたクライアントに対して制御ができるようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/5112ce56-562f-e900-9407-5cb2fe383e38.png)

同一の条件付きアクセス ポリシー内で下記画面ショットのように「アクセスのブロック」を指定することで、レガシー認証を利用したアクセスをブロックできるようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/873dae26-3525-0168-2546-bce6af263b4e.png)

この設定をすると本当にレガシー認証を利用したクライアントはブロックされるので、レガシー認証を利用し続けている社員がいる場合には、事前に先進認証でもアクセスできる環境を用意しておくなどの対処をきちんと行う必要があります。

現行の機能では下記画面ショットのように条件付きアクセスの「レポート専用」機能があります。
この機能は当該のポリシーを有効化はしない代わりに、設定したポリシーに該当したアクセスが発生した際にはサインイン ログに記録されます。
つまり、移行前の動作確認として活用できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/bf1ebbd2-2855-c366-fc77-7d5a5b7a9c41.png)

#####攻撃の対象となる領域を減らす 2.   ユーザーの同意操作を制限する (Admin Consent)

既定では、Azure AD 上のユーザーが Microsoft ID プラットフォームを利用したアプリケーション上のデータにアクセスすることが許可されています。

ユーザーが勝手にアプリケーション上のデータにアクセスさせなくする、もしくはユーザーが勝手に Azure AD 上にアプリケーションを登録できないように、管理者の承認を得ることで初めてアクセスできるような仕組みを用意することができます。

以下はほんの一例ですが、「Admin Consent」という管理者の承認を得ることを前提とした設定ができます。

-関連する公開情報 
すべてのアプリケーションに対して今後のユーザーの同意操作をすべて無効にする必要がある
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/manage-apps/methods-for-removing-user-access#i-want-to-disable-all-future-user-consent-operations-to-any-application

Azure AD アプリケーションの同意エクスペリエンスについて
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/develop/application-consent-experience

設定箇所は、「Azure ポータル」→「エンタープライズ アプリケーション」→「ユーザー設定」→「ユーザーは、アプリが自身の代わりに会社のデータにアクセスすることを許可できます」を「いいえ」に変更します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/1e073a7c-ee05-c249-8c40-e9eb1cad9bff.png)

こうすることで、例えば「Graph Explorer」にアクセスした場合に、下記画面ショットのように「管理者の承認が必要」と表示されて文字通り「管理者の承認」を得られるまでアクセスができなくなります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/d0b2dc36-12c5-1c89-be02-8138df6214e4.png)

管理者側は、Graph Explorer の「アクセス許可」の項目内、「xxx に管理者の同意を与えます」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/7e2810d6-e5d2-a4eb-438e-4db335cd12e6.png)

クリック後に、管理者の資格情報で認証を行うことで、下記画面ショットが表示されるので、「承諾」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/7804b31f-b0f4-6f9b-e12f-dd54ab717dd2.png)

上記はあくまで一例ですが、管理者の同意ワークフローを利用することで、ユーザー側から管理者の同意を「要求」する仕組みも利用することができます。(プレビュー機能です)

-参考情報
管理者の同意ワークフローの構成 (プレビュー)
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/manage-apps/configure-admin-consent-workflow

#####攻撃の対象となる領域を減らす 3.   「Azure AD Privileged Identity Management 」

PIM は Azure AD 管理者ロールや RBAC を永久的にユーザーに付与するのではなく、例えばコラボレーションしている別組織のユーザーに対して、一時的に作業に必要なロールを割り当てて利用したいとなった場合に、申請、承認の上、初めてロールが付与できるという機能になります。

ある管理者ロールを割り当てたユーザーが退職してしまったが、アカウントを無効化しないまま運用してしまい、悪意のあるアクターにそのアカウントを侵害され、管理者ロールを利用して不正に操作されるというケースが考えられます。

この場合は、Just-In-Time の機能を利用することで、指定した期間の間だけ指定したロールを利用させることで、期限が切れのあとは、割り当てたロールが自動的に利用できなくなる仕組みを構成することが可能となります。

-関連する公開情報 
Azure AD Privileged Identity Management とは
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/privileged-identity-management/pim-configure

Azure AD Privileged Identity Management (PIM) をデプロイする
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/privileged-identity-management/pim-deployment-plan

#####脅威への対応を自動化する 「Azure AD Identity Protection 」

Azure AD Identity Protection は様々な理由でセキュリティ侵害の可能性を検知した際に、「リスク」として評価を行い、低、中、高、という「リスク レベル」に応じて対象のユーザー アクセスをブロックさせたり、多要素認証を要求させることでそのユーザーが悪意のあるアクターでないことを証明させたりする機能を有しています。

この機能自体は Azure AD Free ライセンスでも動作はしていますが、後述する「ユーザー リスク ポリシー」ならびに「サインイン リスク ポリシー」というリスク検出時の対策を自動化するためには Azure AD Premium P2 ライセンスが必要になります。

-関連する公開情報 
Azure Active Directory Identity Protection とは
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/identity-protection/overview-identity-protection

Identity Protection ポリシー
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/identity-protection/concept-identity-protection-policies

方法:リスク ポリシーを構成して有効にする
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/identity-protection/howto-identity-protection-configure-risk-policies

設定箇所は、「Azure ポータル」→「Azure Active Directory」→「セキュリティ」→「Identity Protection」になります。
以下は一例ですが、「ユーザー リスク ポリシー」で定義したポリシーに引っかかってアカウント ブロックされた場合には、以下画面ショットのようにブロックされた画面に遷移します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/b035c59d-8c27-e626-696c-cf35a2d269b2.png)

また、「サインイン リスク ポリシー」に引っかかってアクセスがブロックされた場合には、以下画面ショットに遷移します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/4f69e836-3856-519c-d3ba-463524f70a43.png)

ブロックだけではなく、多要素認証を要求させる設定もありますので、いずれかを選択します。
この「ユーザー リスク ポリシー」と「サインイン リスク ポリシー」はそれぞれ 1 つずつしか定義できません。
つまり、リスク レベルごとに、「ユーザー リスク ポリシー」を設定するようなことはできません。

Microsoft では、「ユーザー リスク ポリシー」を「高」、「サインイン リスク ポリシー」を「中以上」に設定することを推奨しています。

-参考情報
許容されるリスク レベルの選択
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/identity-protection/howto-identity-protection-configure-risk-policies#choosing-acceptable-risk-levels

#####クラウド インテリジェンスを利用します  「Azure AD サインイン ログ、監査ログ、Azure AD Identity Protection のイベント ログ」
Azure AD サインイン ログ、監査ログは Azure AD を監視する上では欠かせない機能になります。
サインイン ログは主に認証時のログ、監査ログは、ユーザー、アプリ、グループ、ロール、ポリシーの追加や削除など、Azure AD 内のあらゆるリソースに加えられた変更が発生した際に記録されます。

また、Azure AD Identity Protection は「危険なユーザー」と「危険なサインイン」という項目でログを記録しているので、リスク発生時の履歴を追うことができます。

さらに、Azure Sentinel というクラウドネイティブの SIEM と組み合わせることで、リスクの可視化とトリアージの簡易化が実現できます。

-参考情報
Azure Sentinel に Azure AD と Identity Protection のログを取り込んで可視化してみる
URL:https://qiita.com/Shinya-Yamaguchi/items/7b4e30065857be797c82

-関連する公開情報 
Azure セキュリティのログと監査
URL:https://docs.microsoft.com/ja-jp/azure/security/fundamentals/log-audit

Azure Active Directory ポータルの監査アクティビティ レポート
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/concept-audit-logs

また、サインイン ログと監査ログは、以下のとおり、Azure AD テナントに保持しているライセンスにより保存期間が異なります。

-参考情報
Azure AD にデータが保存される期間

URL:https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/reference-reports-data-retention#how-long-does-azure-ad-store-the-dataa
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/897894c2-f37d-e586-ec35-e4ef541edf12.png)

#####エンドユーザー セルフサービスを有効にします 「セルフサービス パスワード リセット」
セルフサービス パスワード リセットは、文字通り、ユーザーが自分自身でパスワードをリセットできる機能になります。
ID を保護するというよりかは、運用を簡易化し、運用コストを下げるという意味で大きな効力を発揮します。

この機能を有効化していない場合は、パスワードを忘れてしまった場合、パスワードをリセットし、新しいパスワードを設定するオペレーションをヘルプデスクや IT 管理部門の管理者が行う必要があります。

１回のパスワード リセットのオペレーションコストはそれほど高くないかもしれませんが、当然社員が多ければ多いほどこの作業が発生する可能性が上がってしまいます。

「セルフサービス パスワード リセット」を有効化すればユーザーが自分でパスワードをリセットできますので、管理部門が作業する必要がなくなります。
また、ユーザー側から見ると、パスワードを忘れてリセットしたいとなったときに、管理部門に依頼をする必要がなくなります。
この機能を有効化していないと、今すぐアプリケーションにアクセスする必要があるのに、パスワードがリセットされるまで、アクセスできない、という時間的なロスが発生してしまいます。

このように、管理部門、ユーザーサイド双方にとってメリットのある機能になります。

-関連する公開情報 
チュートリアル:Azure Active Directory のセルフサービス パスワード リセットを使用して、ユーザーが自分のアカウントのロック解除またはパスワードのリセットを実行できるようにする
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/authentication/tutorial-enable-sspr

設定は、「Azure ポータル」→「Azure Active Directory」→「パスワード リセット」で表示される項目で行います。
一例として、「認証方法」の項目にて下記画面ショットのようにリセットするために必要な数、方法を設定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/5226cef8-b918-f1a3-3cc8-07fa8664d343.png)

管理者側が上記設定後に、ユーザーがサインインすると、下記画面ショットのように詳細情報が必要の画面が表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/61b4c6d6-9715-4125-a14b-062256b4da2f.png)

次へ、をクリックすることで、このようにリセットに必要な項目を設定するように要求されるので、順番にセットアップしていきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/463b3c36-39ec-54ce-8b8f-6ec9afcf7f61.png)

必要なセットアップが完了すると、「完了」ボタンが押せるようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/2b8ca9d5-86af-0536-985e-b31ac20cdfd9.png)

同じユーザーで画面下の「パスワードを忘れた場合」のリンクをクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/7eeafd77-ea36-7cde-aff0-c1d4c41ec555.png)

Bot ではないことを証明するために、画面に表示されている文字列を入力し、「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/a469550a-f5e7-e0b2-c8f8-016e0aca5b05.png)

セットアップしたいずれかの連絡方法を選択します。今回は電子メールの通知を選択しています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/9b777e18-fd36-7569-c00a-f9503c63b03d.png)

指定したメールアドレスに通知されたワンタイム コードを入力して、「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/c7b141de-53e0-b050-8335-87e8426a56a3.png)

今回は、リセットに必要な方法を「2」にしているのでもう 1 つ連絡方法を選択します。今回は、携帯電話に SMS 送信を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/56651078-ddd8-b7c1-a4a8-0583e6e79bb2.png)

通知されるワンタイム コードを入力して「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/3f36f421-56c7-aa2f-fd41-56a9c52e4ab8.png)

この画面で新しいパスワードを入力して、「完了」をクリックすることで、新しいパスワードの設定が完了します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/fee9cce0-1db3-1b9d-504f-fd7301e67fa3.png)

これで完了です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/5cf3ad09-3372-84c6-5e0a-eece3b18b0ce.png)

#おわりに
今回は Microsoft の公開情報に書かれている「ID インフラストラクチャをセキュリティ保護する 5 つのステップ」を読み解いて、それぞれどのような機能なのかご紹介しました。

読んでいただいた方はお気づきかと思いますが、この公開情報に書かれている機能すべてをご紹介したわけではありません。
さらに、Azure AD で実現できる ID 保護機能はこれだけにとどまりません、結構なボリュームで 10 個の機能をご紹介しましたが、それでもほんの一部にすぎません。

あまりに機能が多すぎて、どこから手を付けたらいいのか分からない、という方向けに、最低限押さえて欲しい機能をご紹介したつもりです。
また、繰り返しになりますが、書いてある機能を全部必ず有効化しないといけない、という訳でもありません。

実際に利用されている環境に適しているかどうかを判断いただき、必要な機能を取り入れていただくための気づきになればと思って書きました。
今回の記事が少しでも参考になれば幸いです。