導入予定の条件付きアクセス ポリシーが利用者に適用されるかを、実際にアクセス拒否させず確認したい場合は、Microsoft Entra IDの「What If」を使います。利用者、対象リソース、デバイス、接続方法などを指定すると、その条件で適用されるポリシーと、適用されないポリシーの理由を確認できます。
ただし、What Ifはサインイン条件を模擬評価する機能です。実際の接続に成功することや、関連サービスを含めて問題なく利用できることを保証するテストではありません。What Ifで事前確認した後、レポート専用モードの実サインインログと照合するのが安全な進め方です。([Microsoft Learn][1])
What Ifと実サインインログの違い
What Ifとレポート専用モードは、どちらもポリシーを有効化する前の確認に使えますが、確認している対象が異なります。
| 確認方法 | 評価するもの | 実際のサインイン | ポリシーの強制 | 主な用途 |
|---|---|---|---|---|
| What If | 入力した仮想的なサインイン条件 | 発生しない | しない | 特定条件で適用されるポリシーをすぐ確認する |
| レポート専用モード | 利用者が実際に行ったサインイン | 発生する | 原則としてしない | 実際の端末、場所、アプリでの影響を確認する |
| 有効なポリシーによるテスト | 実際のサインイン | 発生する | する | 本番動作を最終確認する |
What Ifは、まだ発生していない条件も自由に設定できます。たとえば、「特定の利用者が国外から特定アプリへアクセスした場合」といった状況を、実際に国外から接続せず評価できます。
一方、レポート専用モードでは、実際のサインイン時にポリシーが評価され、その結果がサインインログに記録されます。Grant controlsやSession controlsは強制されないため、ポリシーによって利用者をブロックせずに影響を調査できます。([Microsoft Learn][2])
What Ifで評価されるポリシー
What Ifの評価対象になるのは、次の状態にある条件付きアクセス ポリシーです。
- 有効
- レポート専用
無効になっているポリシーは評価対象に含まれません。そのため、新しく作成したポリシーをWhat Ifで確認したい場合は、少なくとも「レポート専用」に設定しておく必要があります。([Microsoft Learn][1])
「ポリシーを作成したのに結果へ表示されない」という場合は、入力条件だけでなく、ポリシーの有効状態も確認してください。
What Ifを実行する手順
Microsoft Entra管理センターで、次の順に開きます。
Entra ID → Conditional Access → Policies → What If
日本語表示では、環境によって「条件付きアクセス」「ポリシー」などの名称で表示されます。([Microsoft Learn][1])
対象となる利用者を指定する
最初に、評価したい利用者を選択します。
「全利用者を対象にしたポリシーだから、誰を選んでも同じ」とは限りません。利用者ごとにポリシーの除外設定や対象範囲が異なる可能性があるため、実際に影響を確認したい利用者を指定します。
管理者、一般職員、外部利用者など、役割の異なる利用者がいる場合は、それぞれ個別に評価すると見落としを減らせます。
対象リソースを指定する
続いて、利用者がアクセスしようとしている対象リソースを指定します。
たとえば、Microsoft Teamsの利用を確認したい場合は、単に「Microsoft 365全体」を想定するのではなく、評価対象となる個別アプリを明確にします。
新しいWhat If評価APIでは、アプリケーションを指定するときに個別のApp IDを使用します。「Office 365」や「Microsoft Admin Portals」のようなアプリグループ名は、評価するサインインのアプリ指定として一致しません。([Microsoft Learn][1])
ここで混同しやすいのが、ポリシー側の設定とWhat If側の入力です。
- ポリシー側では「Office 365」のようなアプリグループを対象にできる
- What Ifで模擬するサインイン側では、個別アプリのApp IDを指定する
Microsoft GraphのWhat If評価APIを直接利用する場合は、表示名だけではなく、評価したいアプリの正しいApp IDを確認してください。
デバイスプラットフォームを指定する
実際の利用環境に合わせて、デバイスプラットフォームを指定します。
たとえば、Windows端末向けのポリシーを確認したいのに、別のプラットフォームを指定すると、そのポリシーは適用されない結果になる可能性があります。
利用者が複数の端末を使う場合は、Windows、モバイル端末など、利用パターンごとに評価を分けます。
クライアントアプリを指定する
ブラウザやモバイルアプリなど、想定するクライアントアプリの条件も指定します。
条件付きアクセス ポリシーでクライアントアプリを限定している場合、ここが実際の利用方法と異なると、対象ポリシーが「適用されない」と判定されます。
Microsoftの資料では、次の4項目がWhat Ifの必須条件とされています。
| 必須項目 | 確認する内容 |
|---|---|
| Identity | 評価する利用者などのID |
| Target resource | アクセス先となるリソース |
| Device platform | 利用するデバイスのプラットフォーム |
| Client app | ブラウザなどのクライアント種別 |
これら以外の条件は任意項目ですが、入力しなかった項目は既定で「なし」として扱われます。([Microsoft Learn][1])
ポリシーが参照する条件は任意項目でも入力する
What Ifで「適用されない」と表示される代表的な原因が、場所やサインインリスクなどの入力不足です。
画面上で任意となっている項目でも、評価対象のポリシーがその条件を参照している場合は入力が必要です。
たとえば、ポリシーが次の条件で構成されているとします。
- 対象は全利用者
- 対象リソースはOffice 365
- 場所は特定の国または地域
- サインインリスクは「高」
このポリシーに対して利用者だけを指定しても、アプリ、場所、サインインリスクの条件を評価できません。
Microsoftの説明例でも、利用者、個別アプリのApp ID、場所、サインインリスクを順に補い、すべての条件がそろった段階でポリシーが適用対象になります。これは説明用の評価例であり、個別テナントでの実測結果ではありません。([Microsoft Learn][1])
実務では、ポリシー編集画面を別タブで開き、次の条件が設定されていないか確認しながら入力すると確実です。
| ポリシー側の条件 | What Ifで確認する項目 |
|---|---|
| 対象リソース | 個別の対象アプリ |
| デバイスプラットフォーム | 実際に利用するOSや端末種別 |
| クライアントアプリ | ブラウザ、モバイルアプリなど |
| 場所 | 対象となる国、地域、名前付き場所 |
| サインインリスク | ポリシーで指定したリスクレベル |
What Ifで正確な結果を得るには、「入力必須と表示された項目だけを埋める」のではなく、そのポリシーが判定に使う条件をすべて埋めることが重要です。
What Ifの結果を正しく読む方法
What Ifを実行すると、主に次の2種類に分けて結果が表示されます。
- 適用されるポリシー
- 適用されないポリシー
適用されるポリシーでは制御内容まで確認する
ポリシーが「適用される」と表示されただけでは、サインインが成功するとは判断できません。
適用されるポリシーには、利用者が満たす必要のある次の制御も表示されます。
- Grant controls
- Session controls
つまり、「適用される」という結果は、利用者とサインイン条件がポリシーの対象範囲に入ったことを示しています。その後に要求される制御を満たせるかどうかは、別に確認する必要があります。([Microsoft Learn][1])
また、条件付きアクセスでは複数のポリシーが同時に評価されます。一つのポリシーだけを見て「アクセス可能」と判断せず、適用されるポリシー全体を確認してください。
適用されないポリシーでは理由を確認する
適用されなかったポリシーには、その理由が表示されます。
ただし、表示されるのは、ポリシー条件のうち最初に一致しなかった条件です。すべての不一致条件が一度に列挙されるわけではありません。([Microsoft Learn][1])
たとえば、場所とサインインリスクの両方が不足している場合、最初は場所だけが理由として表示される可能性があります。場所を修正して再実行すると、次にサインインリスクの不一致が表示されることがあります。
したがって、非適用理由を一つ修正した後は、必ずWhat Ifを再実行してください。
「適用されない」と出たときの確認順序
What Ifで想定したポリシーが適用されない場合は、次の順で確認すると原因を切り分けやすくなります。
ポリシーの状態を確認する
対象ポリシーが「有効」または「レポート専用」になっているか確認します。
無効なポリシーはWhat Ifの評価対象になりません。
対象利用者と除外設定を確認する
評価した利用者がポリシーの対象に含まれているか確認します。
対象グループに含まれていても、別の設定で除外されていれば適用されません。
個別の対象アプリを確認する
アプリグループ名ではなく、評価したい個別アプリが指定されているか確認します。
特にAPIから評価する場合は、App IDの取り違えに注意してください。
デバイスとクライアントアプリを確認する
ポリシーが対象としているプラットフォームやクライアントアプリと、What Ifの入力が一致しているか確認します。
場所やリスクを確認する
ポリシーで場所やサインインリスクを使用している場合は、その条件も明示的に入力します。
非適用理由を修正して再実行する
非適用理由は最初の不一致条件のみ表示されるため、一つ修正するたびに再評価します。
この確認順序にすると、「必須項目は入力したのに適用されない」という状況でも、ポリシー状態、対象範囲、追加条件を段階的に調査できます。
サービス依存関係は自動評価されない
What Ifを使うときに特に注意したいのが、Microsoft 365サービス間の依存関係です。
What Ifは、指定した対象リソースについて条件付きアクセス ポリシーを評価しますが、関連する下流サービスのポリシーまでは自動的に評価しません。
Microsoftの資料では、Microsoft Teamsを指定してWhat Ifを実行しても、Teamsが依存するExchange Onlineに適用されるポリシーの影響は結果に含まれないと説明されています。([Microsoft Learn][1])
Teamsは、Exchange Onlineだけでなく、SharePoint OnlineやPlannerなどのサービスにも依存しています。サービスによって、サインイン時に先に評価されるものと、機能利用時に後から評価されるものがあります。([Microsoft Learn][3])
そのため、次のような判断は避けてください。
Teamsを対象にWhat Ifを実行して問題がなかったため、Teamsのすべての機能が利用できる。
What Ifで確認できたのは、指定した条件と対象リソースに対する評価です。Teams上でファイルを開く、予定表を表示する、関連サービスのデータへアクセスするといった動作まで確認したことにはなりません。
複数サービスを利用するアプリでは、次の方法で確認します。
- 主となるアプリを個別App IDで評価する
- 依存するサービスも、それぞれ個別に評価する
- レポート専用モードの実サインインログを確認する
- 利用者が実際に使う操作ごとにログを追跡する
サービス依存関係の調査では、What Ifだけで結論を出さず、サインインログに記録されたアプリ、リソース、ポリシーの情報を確認することが重要です。([Microsoft Learn][3])
What Ifとレポート専用モードを組み合わせる
新しい条件付きアクセス ポリシーを導入するときは、次の順序で確認すると安全です。
What Ifで代表的な条件を事前評価する
まず、影響を確認したい利用者とアプリを指定します。
通常の社内アクセスだけでなく、ポリシーの目的に応じて、場所、デバイス、クライアントアプリ、リスクなどの条件を変えて複数回評価します。
ポリシーをレポート専用にする
What Ifで想定どおりの結果になったら、ポリシーをレポート専用に設定します。
レポート専用ポリシーは実際のサインイン時に評価されますが、Grant controlsやSession controlsは強制されません。評価結果はサインインログのConditional AccessまたはReport-onlyに関する項目で確認できます。([Microsoft Learn][2])
実サインインログと照合する
対象利用者が通常の業務操作を行った後、個別のサインインイベントを確認します。
ログでは、次の点を確認します。
- 対象ポリシーが評価されているか
- 適用または非適用のどちらになったか
- 想定したアプリとリソースが記録されているか
- 他の条件付きアクセス ポリシーも同時に適用されていないか
複数の利用者やアプリについて一定期間の影響を確認したい場合は、Conditional Access Insights and Reporting workbookも利用できます。ワークブックでは、対象ポリシー、期間、利用者、アプリなどを指定して、成功、失敗、利用者操作が必要、非適用といった結果を集計できます。([Microsoft Learn][4])
結果を確認してから有効化する
What Ifとレポート専用の結果が一致し、想定外の利用者やアプリに影響しないことを確認してから、ポリシーを有効にします。
What Ifは設計段階の確認に向き、レポート専用モードは実際の利用状況に基づく確認に向いています。どちらか一方で済ませるのではなく、役割を分けて使うことが重要です。
What Ifを使うときの判断基準
導入前の確認では、次のように使い分けます。
| 確認したい内容 | 適した方法 |
|---|---|
| 特定条件でポリシーが対象になるか | What If |
| なぜポリシーが適用されないか | What Ifの非適用理由 |
| どのGrant controlsが要求されるか | What Ifの適用ポリシー詳細 |
| 実際の端末やネットワークでどう評価されたか | レポート専用のサインインログ |
| 一定期間の利用者やアプリへの影響 | Insights and Reporting workbook |
| 依存サービスを含む実際の動作 | 個別サービスの評価とサインインログ |
| 本当に認証操作を完了できるか | 管理された範囲での実サインインテスト |
What Ifで「適用される」と表示されても、実際の接続成功が保証されたわけではありません。反対に「適用されない」と表示された場合も、ポリシー設計が誤っているとは限らず、What Ifへの入力が不足している可能性があります。
まず、対象ポリシーをレポート専用にしたうえで、代表的な利用者と個別アプリを選び、ポリシーが参照する条件をすべて入力してWhat Ifを実行してください。その後、実際のサインインログと照合し、対象範囲、制御内容、依存サービスへの影響を確認してから有効化するのが安全です。
[1]: https://learn.microsoft.com/en-us/entra/identity/conditional-access/what-if-tool “The Conditional Access What If tool – Microsoft Entra ID | Microsoft Learn”
[2]: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-report-only “Conditional Access Policy Insights: Monitoring and Evaluation – Microsoft Entra ID | Microsoft Learn”
[3]: https://learn.microsoft.com/en-us/entra/identity/conditional-access/service-dependencies “Conditional Access service dependencies – Microsoft Entra ID | Microsoft Learn”
[4]: https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-insights-reporting “Conditional Access insights and reporting workbook – Microsoft Entra ID | Microsoft Learn”
コメント