Microsoft Entra IDの条件付きアクセスを運用しているすべての管理者にとって、見逃せない変更が2026年5月13日に施行される。「すべてのリソース（All resources）」を対象としたポリシーにおいて、リソース除外設定の扱いが変わり、これまで除外設定によって事実上回避されていたサインインもポリシー評価の対象になる。既存構成によっては予期せぬアクセスブロックが発生しうるため、施行前の早急な棚卸しが求められる。

条件付きアクセスの「リソース除外」とは

条件付きアクセスポリシーは、「誰が・どのアプリに・どの条件でアクセスするか」を制御する仕組みだ。ポリシーのスコープとして「すべてのクラウドアプリ」を指定しつつ、特定アプリだけを除外リストに入れることで、例外的なアクセスパスを設けることができる。

たとえば「すべてのリソースに多要素認証（MFA）を要求する」というポリシーを定義しながら、特定のレガシーアプリやサービスアカウント向けアプリを除外リストに追加するケースが多い。これは現実的な運用上の妥協点として広く使われてきた手法だ。

何が変わるのか

今回の変更の核心は「ポリシー強制適用の一貫性向上」にある。

これまでの動作では、「すべてのリソース」を対象とするポリシーに除外リソースが設定されている場合、該当リソースへのサインインがポリシー評価から実質的に外れるケースが存在した。ポリシー設計者の意図と異なる動作を引き起こす可能性があり、セキュリティギャップになり得た。

5月13日以降は、このギャップが解消される。「すべてのリソース」を対象とするポリシーは、リソース除外の有無にかかわらず、より一貫した形で評価・強制適用される。

事前に確認すべきポイント

1. 「すべてのリソース」対象ポリシーの棚卸し Entraポータルの「条件付きアクセス」→「ポリシー」で、スコープが「すべてのリソース」になっているポリシーを全件確認する。リソース除外が設定されているものは特に注意が必要だ。

2. 除外の意図を再確認する 除外設定が「技術的に仕方なく入れた回避策」なのか、「意図的な例外ルール」なのかを明確にしておく。前者の場合、変更後に予期せぬブロックが発生する可能性がある。

3. 「What If」ツールで影響をシミュレーション Entraの「What If」ツールやサインインログを活用して、変更後にどのサインインが影響を受けるかを事前に確認する。本番環境で突然ブロックが発生する前に、テストテナントや評価環境での検証も推奨する。

4. 5月13日以前に修正を完了させる ポリシーを意図した動作に修正するか、個別アプリへの専用ポリシーを作成して対応する。施行当日の対応では間に合わないケースもある。

日本のIT環境への影響

日本の大規模企業では、条件付きアクセスを「とりあえず設定した」状態のまま、除外リストを膨らませて運用しているケースが少なくない。特に、オンプレミスからEntraへ移行した時期に「既存システムが動かなくなると困る」という理由で除外を積み上げてきた環境は要注意だ。

今回の変更は、そうした「なんとなく動いていた」構成が明示的に問題として浮き上がるきっかけになる。影響を受けるポリシーを早期に特定し、ゼロトラストの観点でポリシー全体を見直す好機と捉えたい。

筆者の見解

ゼロトラストの本質は「すべてのアクセスを継続的に検証する」ことにある。その観点からすれば、今回の変更はMicrosoftが当然の挙動を当然に動くようにした、正しい方向性の修正だ。

ただ、「当たり前のことが今まで当たり前でなかった」という事実は率直に受け止めるべきだろう。リソース除外によるポリシー回避という設計上のあいまいさが長年存在していた点は、Entraの実力を考えればもったいなかったと感じる。Microsoft Entra IDはゼロトラストの中心的な基盤として十分な実力を持っている。その実力を全開にするには、こういった細部の一貫性こそが重要だ。

企業に対しては、「変更で壊れたから直す」という対応に留まらず、これを機にポリシー設計全体を見直してほしい。「常時アクセス権の付与」や「積み上がった除外設定」は、ゼロトラストの皮をかぶった旧来の境界防御に過ぎない。ポリシーを「管理画面上のスイッチ」ではなく「アクセス制御の設計図」として捉え直す——今回の変更は、その再設計への良い入り口になる。

出典: この記事は Conditional Access: Policy Enforcement Change for Resource Exclusions (May 13) の内容をもとに、筆者の見解を加えて独自に執筆したものです。