はじめに
私たちネクストリードは、Microsoft 365 セキュリティ運用のプロフェッショナルとして、これまで多くのお客様のセキュリティ アセスメントを行ってきました。その中でも特に改善点として指摘することが多い機能の筆頭が Microsoft Entra ID の条件付きアクセス ポリシー です。
本ブログでは、条件付きアクセス ポリシーを運用する上で気を付けた方が良いポイントを 3 点ご紹介します。
Microsoft Entra ID 条件付きアクセス ポリシーとは
Microsoft Entra ID の条件付きアクセス ポリシーは、 「誰が・どこから・どのデバイスで・どのアプリへアクセスするか」 などの条件に基づき、アクセスを許可・ブロック・追加認証させるためのセキュリティ機能です。ゼロトラスト セキュリティを実現するうえで中心的な役割を担っており、多くの企業に導入されています。
一方で、条件付きアクセス ポリシーは柔軟性が高い反面、設計や運用が難しく、また多数の例外を積み重ねてしまうことで、ポリシー全体の整合性を失ってしまうことがよくあります。
私たちが支援してきたお客様の環境でも、ポリシー設計方針が明確になっていないまま増改築を繰り返したことで、結果として「全体として何を守りたいのか」が見えにくくなっているケースが少なくありません。
ポリシーの最適な運用のために考慮すべきこと
条件付きアクセス ポリシーの設計と運用は奥深く、組織の文化や状況に合わせて考慮するポイントも変わってきますが、私たちが重要と考えている 3 つのポイントをご紹介します。
- レイヤーでの設計
- 例外対応の自動化
- 継続的な見直し
1. レイヤーでの設計
条件付きアクセス ポリシーの運用を難しくしてしまう例としてユーザー単位で（縦割りで）設計してしまうことが挙げられます。
例えば、営業部にはこのポリシー、経理部にはこのポリシー、のようにユーザーごとにポリシーを設計すると、一見きめ細やかなポリシー設計が出来ていて良さそうに思います。
しかし、ほとんど同じような内容で微妙に内容が異なるポリシーが複数作成され、時間が経つにつれてそれぞれのポリシーが微修正され、誰にどのような制御が適用されているのか、抜け漏れがないのかを把握することが次第に困難になっていきます。
そこで、ポリシーを レイヤーで設計する ことを考えてみましょう。
例えば、①組織のすべてのユーザーが例外なく満たす必要があるポリシー（例えば、レガシー認証をブロックするなど）、②メンバー ユーザーが例外なく満たすべきポリシー（例えば、多要素認証を要求するなど）、③特権アカウントが例外なく満たす必要があるポリシー（フィッシング耐性 MFA を要求するなど）の 3 つのレイヤーでポリシーを作成してみることにします。
この状態であれば、仮に監査などで下記のような質問をされても、すぐに回答することが出来ますよね。
- 組織全体でレガシー認証はブロックされているか
- 多要素認証が適用されていないユーザーは誰か
- 特権アカウントがフィッシングによりパスワードが漏えいする可能性はどの程度か
① や ② のようなポリシーはベースラインとして機能し、少数のポリシーで組織全体に適用するため、ポリシーの適用漏れが発生する可能性を大きく下げることが出来ます。このようなベースラインとして機能するポリシーの適用対象は特定のグループではなく「すべてのユーザー」を使用し、対象外のユーザー（緊急アクセス用アカウント、ゲストなど）を除外するようにします。
特定のグループ向けにポリシーを作成する場合は、ベースラインに追加する位置づけで作成します。（下記の図の XXX のイメージ）
2. 例外対応の自動化
実際のポリシー設計では、ポリシー A から除外する代わりにポリシー B でリスクヘッジしたい、といったケースが出てきます。また、運用の中で「一時的に除外したい」などのニーズも当然想定されます。（MFA デバイスを忘れた場合など）
このような場合は、例外ユーザーをメンバーとして管理するセキュリティ グループを作成して利用することになると思いますが、このグループのメンバーを手動で管理すると下記のような抜け漏れが発生しがちです。
- MFA デバイスを忘れたユーザーを一時的に除外グループに追加したまま数カ月経っていた
- 部署移動で除外する必要がなくなっていたユーザーが除外されたままになっていた
- このユーザーが除外されている理由が不明で除外してもいいのか判断できない
そこで、例外ユーザーを管理するセキュリティ グループのメンバー管理を自動的することをお勧めします。
動的グループやアクセス レビューのような Microsoft Entra ID 標準機能を利用することもできますが、ロジックアプリと Graph API を組み合わせてカスタム実装することも有効です。
例えば、私たちはこれまで下記のようなグループのメンバー自動更新ロジックを作成したことがあります。（これらの条件は Microsoft 365 標準機能で実装が出来ませんが、カスタム実装が可能です）
- 特定のライセンスを持っているユーザーのグループ
- 作成されてから 30 日経過しておらずかつ MFA が登録されていないユーザーのグループ
- 準拠デバイスをもっているユーザーのグループ
上記のようなグループを作成しておくことで、「M365 Business Premium が割り当てられた社員にのみ準拠デバイスを要求する」「新入社員に説明会まで MFA 登録を猶予し、登録が終わったユーザーから即座に MFA を強制する」「会社支給デバイスをもつユーザーのみ準拠デバイスを強制する」のような運用を、手動でのメンバー管理なしで実現できます。
また、除外グループにメンバー追加後 24 時間で自動的にメンバーから削除する、のような自動化も抜け漏れを防ぐうえで有効です。
3. 継続的な見直し
条件付きアクセス ポリシーは一度構築して終わりではなく、組織の変化に合わせて継続的に見直すことが求められます。新しいクラウド サービスの導入、組織再編、セキュリティ戦略の更新など、組織は常に変化し続けており、ポリシーもそれに追随する必要があります。
また、組織の変化以上にポリシーの見直しが重要である理由は、攻撃手法の進化という外圧によるものが大きいと思います。
「MFA によって不正サインインの 99% をブロックできる」と聞いたことがある方も多いと思いますが、この数字は今後間違いなく低下すると考えられます。
実はこの数字、2019 年頃までは 99.9% と言われていましたが、2025 年現在は 99.2% と言われており、既に若干下がってきています。今後 Microsoft が MFA 必須化の取り組みを進めるとともに、攻撃者は MFA をバイパスする攻撃手法に注力していくだろうと考える方が自然です。今後 AiTM はさらに一般的な攻撃になると思いますし、サービス プリンシパルや AI エージェントを狙った攻撃も 5 年後くらいにはもっと一般的な脅威となるはずで、これらの脅威に対応できるようにセキュリティ戦略の見直しは必ず必要になります。
このように、組織内部の変化や攻撃手法の進化に追随していくために、ポリシーの継続的な見直しは非常に重要であり、組織レベルでも個人レベルでも下記のような対応が必要になると考えています。
- 組織で定期的なポリシー見直しのスケジュールを設定しておく
- ブログやイベント等で機能や攻撃手法をキャッチアップする
- アラートの対応をしっかりやる
最後の「アラート対応」については一見ポリシーの見直しとは関係ないように思われるかもしれませんが、認証関連のアラートの一部は想定外のアクセス許可によって発生していることがあり、ポリシーが適切に機能していないことの現れである場合があります。普段のアラート対応をしっかりすることでポリシーの不備や不足に気づきやすくなることを覚えておいてください。
情報収集やアラート対応は自社だけで行うことが難しいこともあると思いますので、お付き合いのある IT ベンダーの協力も得ながら対応を進めましょう。
さいごに
条件付きアクセス ポリシーは、Microsoft 365 を安全に活用するための最重要のセキュリティ機能であり、ゼロトラスト セキュリティを実現する基盤でもあります。しかし、その柔軟性ゆえに、設計や運用を誤ると 想定外の抜け漏れ や 形骸化した例外 が積み重なり、気づかないうちに組織を危険にさらすこともあります。
本記事で紹介した 3 つのポイントはどれもシンプルですが、実際に取り組むと意外と難しいことが分かると思います。
もし自社だけでの設計や運用に不安があったり、ポリシーが複雑化して整理が追いつかない場合は、ぜひ私たちネクストリードにお気軽にご相談ください。（2026 年 1 月より「認証強化短期プログラム」支援を始めますので、ご興味がありましたらお問い合わせください）
条件付きアクセス ポリシーを適切に設計・運用し、攻撃者にとってコスパが悪い組織を目指しましょう。
本記事が、みなさまのポリシー運用の見直しや改善のきっかけになれば幸いです！