Microsoft Entra ID P2を全社員に配布し、Entra ID Protection側のリスクポリシーで高リスクのサインインに多要素認証やパスワード変更を要求している。そんな数千人規模の企業でID基盤を預かる情報システム部門に、期限のある宿題が届いている。Microsoftは、Entra ID Protectionで設定するレガシーのリスクポリシーを2026年10月1日に廃止すると公式ドキュメントに明記した[1]。対象はID Protection側で設定するユーザーリスクポリシーとサインインリスクポリシーの2つで、移行先は条件付きアクセス（Conditional Access。サインインの条件に応じてアクセス可否や追加認証を制御するEntraの機能）側に作る同等のリスクベースポリシーになる[1]。
問題は移行の手当てにある。公式ドキュメントが示す移行手順は、管理者が条件付きアクセス側に同等のポリシーを作り、旧ポリシーを自分で無効化するという手動作業である[1]。設定が自動で引き継がれるという記述はない。本記事の公開時点で残りは約5週間。放置した場合に何が起きるのか、公式の3段階をどう変更管理に乗せるのか、しきい値のトレードオフを決裁側にどう説明するのか、の順で整理する。
予備知識
- Entra ID Protection: サインインの挙動や漏えいした資格情報からアカウントの危険度を判定するEntraの機能
- ユーザーリスク／サインインリスク: 前者はアカウントが侵害された可能性、後者はそのサインイン試行自体の不審さを示す指標
- 条件付きアクセス: 利用者・端末・場所・リスクなどの条件に応じて、許可・ブロック・追加認証の要求を決めるEntraのポリシー機能
- report-onlyモード: 条件付きアクセスのポリシーを実際には適用せず、適用したらどうなるかだけをログに残す検証用の状態
条件付きアクセスと多要素認証の設定画面を実機ベースで追えるため、移行先ポリシーを作る前の手順確認に使える
Entra ID Protectionのレガシーリスクポリシーは何がいつ廃止されるのか
廃止されるのは、Entra ID Protectionの画面から設定するユーザーリスクポリシーとサインインリスクポリシーの2つで、期限は2026年10月1日である[1]。
公式ドキュメントは、レガシーのリスクポリシーが2026年10月1日に廃止されると記している[1]。ここで言うレガシーとは、ID Protectionのダッシュボードから直接オン・オフする形式のポリシーを指す。同じリスク判定を使っていても、条件付きアクセス側で作るリスクベースのポリシーは廃止対象ではない。
| 設定場所 | ポリシー | 2026年10月1日以降 |
|---|---|---|
| ID Protection ダッシュボード | ユーザーリスクポリシー | 廃止 |
| ID Protection ダッシュボード | サインインリスクポリシー | 廃止 |
| 条件付きアクセス | リスクベースのポリシー | 継続。ここが移行先 |
公式ドキュメントは、Entra ID Protectionの機能をフルに使うにはMicrosoft Entra ID P2またはMicrosoft Entra Suiteのライセンスが必要だとしている[1]。すでにP2を全社配布しているなら、条件付きアクセス側へ移すこと自体でライセンス費用が増えることはない。P1のみの環境でレガシーポリシーが使えるかは公式ドキュメントに明記がなく、自社の適用状況は管理センターで確認するほかない。
ポリシー廃止で生じる統制の欠落を監査側の言葉で説明する必要がある担当者向けに、ID管理と内部統制の接続点を整理できる
手動移行を済ませないまま10月1日を迎えるとサインインはどうなるのか
公式の手順は手動移行であり、設定の自動引き継ぎには触れていない[1]。条件付きアクセス側に同等のポリシーを用意しない限り、10月1日以降は高リスクと判定されたサインインに追加の検証を課す仕組みが残らない、というのが手順から導かれる帰結になる。
廃止といっても、既存の設定が別の場所へ引き継がれるわけではない。旧ポリシーが止まり、代わりが用意されていなければ、リスク判定そのものは動き続けるのに制御だけが抜け落ちる。
厄介なのは、この状態が障害として見えないことである。サインインは成功し、利用者は何も気づかず、失敗ログも積み上がらない。監視のしきい値を見張っていても検知の起点が現れない。
内部統制の観点では、これは期末に指摘を受けやすい形の欠落にあたる。高リスクサインインには多要素認証を要求している、という統制記述が実態と合わなくなるためである。しかも欠落した時点を示す証跡が残りにくいので、いつから統制が効いていなかったのかを後から立証する作業が発生する。
数千人規模でEntra ID（旧Azure AD）とオンプレADを併用し、年次の内部監査があるような日本企業のID基盤担当者は、SMSや音声通話によるMFA（多要素認証）を、まだ主要な認証手段として使い続けている場合が多い。Microso[…]
公式が示す移行の3段階とreport-onlyでの検証の進め方
公式ドキュメントが示す移行手順は3段階である。条件付きアクセスで同等のポリシーを作る、旧ポリシーを無効化する、必要に応じて追加のリスクポリシーを整備する、という順になる[1]。
第1段階は、条件付きアクセスでのポリシー作成である。手動で設定してもよいし、Microsoftが用意する推奨テンプレートを使ってもよい[1]。公式が重ねて示しているのは、本適用の前にreport-onlyモードで検証するという点である[1]。なお、セキュリティ既定値群（Security Defaults）を有効にしているテナントでは、条件付きアクセスのポリシーを有効化する前にセキュリティ既定値群を無効化する必要がある[2]。中小規模から拡大してきた組織では、ここで最初に詰まることがある。
第2段階は旧ポリシーの無効化である。ID Protectionのダッシュボードからユーザーリスクまたはサインインリスクのポリシーを開き、enforcementをdisabledに設定する[1]。順序を逆にすると空白期間が生まれるため、新ポリシーの本適用を先に済ませてから無効化するのが安全である。
第3段階は、必要に応じた追加のリスクポリシー整備になる[1]。判断に迷う場合は、Entra管理センターからサービスの種類「Microsoft Entra Sign-in and Multifactor Authentication」、問題の種類「Identity Protection」、サブタイプ「Configure risk policies」で技術サポートリクエストを出せる[1]。
数千人規模の従業員を抱え、基幹業務システムにRDS for MySQL（Amazonが管理するリレーショナルデータベースサービス）を使い、四半期ごとに内部監査を受けている企業のDB運用担当者は、2026年8月以降、毎月の請求書に見慣れない[…]
ユーザーリスクHighとサインインリスクMedium、しきい値はどう決めるか
Microsoftの推奨は、ユーザーリスクがHighのときに修復を要求し、サインインリスクがMediumまたはHighのときに多要素認証を要求する構成である[1]。
しきい値の設計はセキュリティ強度だけの問題ではない。公式ドキュメントは、Highのリスクレベルでアクセス制御を適用するとポリシーが発動する回数が減ると説明している[1]。逆に低いしきい値を選ぶと、正規の利用者が追加認証を求められる中断が増えるとしている[1]。
| 項目 | ユーザーリスクポリシー | サインインリスクポリシー |
|---|---|---|
| Microsoft推奨のしきい値 | High | Medium または High |
| 要求する動作 | 修復（パスワード変更等） | 多要素認証 |
| しきい値を上げた場合 | 発動回数が減る | 発動回数が減る |
| しきい値を下げた場合 | 利用者の中断が増える | 利用者の中断が増える |
中断の増加は、そのままヘルプデスクの負荷になる。パスワード変更を突然求められた利用者の多くは、手順書を探す前に情報システム部門へ電話をかける。セルフサービスのパスワードリセットが全社で使える状態かどうかで、同じしきい値でも問い合わせ件数の伸び方は変わる。
しきい値より先に確認すべき前提が2つある。公式ドキュメントは、修復が必要な場面を迎える前に利用者が多要素認証の登録を済ませている必要があり、未登録の利用者はブロックされ管理者の介入が必要になると警告している[1]。さらに、オンプレADから同期しているハイブリッド利用者については、パスワードライトバックが有効になっていることが必須とされている[1]。全社員にP2を配っていても、登録率とライトバックの設定状況次第で、本適用の当日にサインインできない社員が出る。
report-onlyでの検証期間は、この負荷を見積もる材料を取る時間でもある。実データを持たないまましきい値を決めると、本適用の当日に想定外の問い合わせを受けることになる。
稟議と監査が絡む日本企業でリスクポリシー移行をどう通すか
廃止日は世界共通で、日本企業だけ猶予されない。違いは技術ではなく、変更を決めてから実行するまでの経路の長さに出る。
全社員の認証挙動が変わる変更は、情報システム部門の単独判断で実施できない企業が多い。変更管理委員会や情報セキュリティ委員会の審議が挟まり、開催が月次であれば実質のリードタイムは数週間になる。Entraの運用をSIerに委託している場合は、ポリシー新設が委託範囲に含まれるかの確認と追加見積もりがさらに前段に入る。
監査面の扱いも軽くない。J-SOXのIT全般統制でアクセス管理の証跡を求められる企業では、統制記述と実際のポリシー構成が一致している必要がある。旧ポリシーを無効化した以上、運用手順書と統制文書の改訂まで含めて初めて移行が完了する。
| 論点 | 技術作業そのもの | 日本企業で追加になる工程 |
|---|---|---|
| ポリシー作成 | 管理センターで数十分 | 変更管理の申請と承認 |
| 本適用への切替 | 設定1カ所 | 利用部門への事前周知とヘルプデスク体制の合意 |
| 旧ポリシー無効化 | 設定1カ所 | 統制文書・運用手順書の改訂 |
| 運用委託 | 対象外 | SIerとの作業範囲と費用の確認 |
IT部門の判断はひとつ。承認に要する日数を先に逆算し、report-onlyの結果が出るのを待たずに申請の枠だけ確保しておく。決裁側の判断もひとつ。P2配布済みなら追加のライセンス費用は原則発生せず、判断軸はコストではなく動かせない期限のほうにある。
よくある質問（FAQ）
Q. 10月1日を過ぎたら、旧ポリシーの設定内容は見られなくなりますか。
A. 公式ドキュメントは廃止日を示すのみで、廃止後に画面上でどう扱われるかまでは明記していない[未確認]。しきい値・対象ユーザー・除外設定は、廃止前に控えておくのが安全である。
Q. 条件付きアクセスへ移すと追加費用はかかりますか。
A. Entra ID Protectionの機能をフルに使うにはEntra ID P2またはEntra Suiteが必要とされている[1]。すでにP2を配布済みなら、移行そのものでライセンス費用が増えることはない。
Q. report-onlyのまま10月1日を迎えたらどうなりますか。
A. report-onlyは実際の制御を行わず影響をログに残すだけの状態である。本適用に切り替えていなければ、リスク判定に応じた多要素認証や修復の要求は働かない。
まとめ
この変更で一番厄介なのは、期限を過ぎても何も壊れないことである。エラーは出ず、失敗ログも増えず、利用者からの申告も来ない。消えるのはアクセス制御の統制だけで、その欠落は次の監査まで表面化しない可能性がある。
IT部門の次の一手は決まっている。現行のユーザーリスクポリシーとサインインリスクポリシーについて、しきい値・対象ユーザー・除外設定を棚卸しし、同じ内容の条件付きアクセスポリシーをreport-onlyで作る。1〜2週間回せば、どの部門の誰が何回引っかかるかが実データで出る。
決裁側の材料は3つある。追加のライセンス費用は原則発生しないこと、多要素認証の要求が増えれば一時的にヘルプデスクの負荷が上がること、そして2026年10月1日という期限が動かないことである[1]。しきい値をHighに寄せれば中断は減るが、拾える範囲も狭くなる[1]。
残りは約5週間。手を動かす時間より、承認を取る時間のほうが先に足りなくなる。
