EntraID条件付きアクセスゼロトラストセキュリティ

条件付きアクセスポリシーの設計パターン

14 分で読めます

Microsoft Entra IDの条件付きアクセスを使って、デバイスコンプライアンス・場所・リスクレベルに基づいたアクセス制御を設計する方法を解説。ライセンスごとに何ができるかや、よく使う5つのパターンも紹介します。

はじめに

Entra ID（旧Azure AD）を使っていると、ほぼ確実に触ることになるのが「条件付きアクセス」です。 ゼロトラストの入り口として語られることが多い機能ですが、実際に設計しようとすると「Entra ID P1とP2で何が違う？」「ユーザーリスクとサインインリスクの違いって？」「継続的アクセス評価って何？」という疑問が一気に噴き出してきます。このあたりの用語を整理していきます。

この記事では、ライセンスによる機能差と、リスクの種類の違い、そしてよく使う5つの設計パターンをまとめます。「条件付きアクセス、入口は分かるけどどこから手を付ければ？」という人の、ちょうど良い取っ掛かりになることを目指します。

ライセンス：P1とP2で何が変わるか

Entra IDのライセンスは、大きく分けて Free / P1 / P2 の3段階です。条件付きアクセスは P1以上 で使えます。P2になるとここに「Identity Protection」によるリスクベースの制御が加わるのが大きな違いです。

ざっくり整理すると、こんな感じです。

機能 P1 P2
条件付きアクセス（場所、デバイス、アプリ、認証強度など） ○ ○
Identity Protectionによるリスク検出・リスクベースの条件 × ○
Privileged Identity Management（PIM） × ○
アクセスレビュー・アクセスパッケージ（Identity Governance） × ○

参考：Microsoft Entra ID ライセンス概要

P1でも条件付きアクセスは十分実用になりますが、「ユーザーリスク」「サインインリスク」といったリスクベースの条件を使うにはP2が必要です。中小企業ではP1だけで完結するケースも多いですが、教育機関などではM365 A5を導入し、リスクベース認証を行う自治体も少なくありません。文部科学省としても「教育情報セキュリティポリシーに関するガイドライン」などで、リスクベース認証を推奨しています。

なお、M365 E5 / A5 には Entra ID P2 が含まれています。「すでにE5を買っている＝P2が使える状態」なので、この場合は積極的に Identity Protection を活かしたほうが良いです。

ユーザーリスクとサインインリスクの違い

この機能の名前にはどちらも「リスク」と付くのですが、検知対象が違います。

  • ユーザーリスク：ユーザーアカウントそのものが侵害されている可能性を表す。ダークウェブで漏洩した資格情報と一致した、通常と異なる活動が継続している、などのシグナルで判定。
  • サインインリスク：そのサインインイベント1回分が怪しいかどうかを表す。見知らぬIPからの不審なログイン、不可能な移動（インポッシブルトラベル）、匿名化IPの利用など。

ユーザーリスクは「その人のアカウントが危ない状態か？」、サインインリスクは「今のログイン行為が怪しいか？」を問うているイメージです。 したがって、対応の設計も変わります。

  • ユーザーリスクが「高」→ パスワード変更を強制する
  • サインインリスクが「高」→ MFAを要求する、あるいはブロックする

というのが定番の組み合わせです。どちらもIdentity Protectionで検知される情報なので、使うにはP2が必要です。

継続的アクセス評価（CAE）とは

もう一つ用語を整理しておきます。「継続的アクセス評価（Continuous Access Evaluation, CAE）」は、条件付きアクセスの判定を「トークンの有効期限が切れるまで待つ」のではなく、イベントに応じてほぼリアルタイムに再評価する ための仕組みです。

通常、OAuth/OpenID Connectのアクセストークンは1時間程度の寿命を持っていて、その間は再認証なしに使えます。ただしCAEが有効だと、例えば次のようなイベントが起きた瞬間にトークンが無効化され、再認証を求められます。

  • ユーザーのパスワードが変更された
  • ユーザーアカウントが無効化・削除された
  • 条件付きアクセスで新しいポリシーが有効になった
  • サインインリスクが大幅に上がった

「退職時にアカウントを無効化したのに、1時間以内は引き続きOutlookが開けてしまった」という古典的な問題を、CAEはかなり緩和してくれます。CAE対応アプリはまだ限定的ですが、Exchange Online、SharePoint Online、TeamsなどのMicrosoftネイティブサービスは対応済みなので、条件付きアクセスを設計する時は「CAEあり」を前提にしておくのが今のベストプラクティスだと思っています。

よく使う条件付きアクセスのパターン

ここから具体例です。自分が実案件でよく提案・展開している5つのパターンを紹介します。基本2つ、応用3つの構成にしています。

パターン1：管理者にMFAを要求する（基本）

これは条件付きアクセスの入門中の入門です。段階導入の最初の一歩や、ITベンダーが構築用に使うアカウントなどに適用します。

  • ユーザーまたはエージェント：IT管理者、ITベンダー用アカウント
  • ターゲットリソース：全クラウドアプリ
  • 条件：なし
  • アクセス制御（許可）：アクセス権の付与 → 認証強度が必要（Multifactor authentication）

最近は「認証強度（Authentication Strengths）」でMFAを指定するのが主流です。旧来の「多要素認証を要求する」チェックボックスよりも細かい制御ができます。例えば「SMSは受け入れない、Authenticatorアプリかパスキーのみ」といった縛り方ができるので、パスキー移行を進めている環境なら積極的に使ったほうが良いです。

パターン2：特定の場所のみログインを許可する（基本）

主に社内からしか業務アプリにアクセスしないという現場でよく使います。 ポイントは、アクセス制御で「許可」を選ぶとMFAなどの追加要素を必ず選ばなければいけないので、アクセスさせたい場所を「対象外」に指定して、それ以外をブロック する設計にすることです。

事前に「Named Location」という仕組みで許可したい場所を定義しておく必要があります。Named Locationの作り方は別記事「Named Locationを登録する方法」にまとめているので、そちらを参照してください。

  • ユーザーまたはエージェント：全ユーザー
  • ターゲットリソース：全クラウドアプリ
  • 条件：場所 → 対象：任意のネットワークまたは場所／対象外：選択したネットワークと場所
  • アクセス制御：アクセスのブロック

「許可したい方を例外として指定する」という発想がピンとこない最初は「逆じゃないの？」と感じますが、「対象：全部／対象外：許可する場所／操作：ブロック」と読むと、慣れてくるとシンプルに見えてきます。

パターン3：ChromeBookからのアクセスをブロックする（応用）

現場でよくある要望の一つに「ChromeBookからのアクセスはブロックしたい」というものがあります。ここが少しだけ罠で、条件付きアクセスの「デバイスプラットフォーム」という条件には、なぜか ChromeOSが選択肢に存在しない のです。

なのでChromeBookを直接指定することができません。これを逆手に取って、「対象として許可したいOS以外の全て＝ChromeOSを含むその他」をブロックする設計にします。

  • ユーザーまたはエージェント：全ユーザー
  • ターゲットリソース：全クラウドアプリ
  • 条件：デバイスプラットフォーム → 対象：任意のデバイス／対象外：Android, iOS, Windows Phone, Windows, macOS, Linux
  • アクセス制御：アクセスのブロック

参考：デバイスプラットフォームの条件

ちょっとクセがありますが、これが現状のベストアンサーです。なお、この設計はプラットフォームがAndroid以外のChromeOS端末を想定しており、ユーザーエージェントの偽装などで回避される可能性はゼロではない、という点だけは認識しておいたほうが良いです。

パターン4：Windows Hello for Businessでログインした端末のみログインできるようにする（応用）

Windows Hello for Business（WHfB）は展開そのものは難易度が高いのですが、条件付きアクセス側の設定はシンプルです。認証強度のテンプレートに「Windows Hello for Business」があるので、それを要求するだけで実現できます。

  • ユーザーまたはエージェント：全ユーザー
  • ターゲットリソース：全クラウドアプリ
  • 条件：なし
  • アクセス制御（許可）：アクセス権の付与 → 認証強度が必要（Windows Hello for Business）

WHfB環境まで作り込んでいる現場であれば、これを入れるとフィッシング耐性の強い認証だけに絞れます。ただし段階的に展開する前提で設計しないと、WHfB未展開の端末から突然ログインできなくなるので、最初はレポートオンリーモードで影響範囲を確認するのがおすすめです。

パターン5：専用のFIDO2キーを使っているユーザーのみログインできるようにする（応用）

情シス・運用管理者・特権アカウントなどに対して、「会社支給の専用FIDO2キーを使うユーザーだけを許可する」ような設計です。 事前に、使用する専用FIDO2キーをAAGUIDで指定して登録する必要があります。登録の具体手順は別記事「専用FIDO2キーを登録する方法」に書いていますので合わせて参照してください。

  • ユーザーまたはエージェント：全ユーザー（もしくは特権ユーザーのグループ）
  • ターゲットリソース：全クラウドアプリ
  • 条件：なし
  • アクセス制御（許可）：アクセス権の付与 → 認証強度が必要（事前作成した認証方法の名前）

認証強度をカスタムで作り、「その方法のみ」を要求するのがポイントです。特権アカウントにこれを適用するだけで、パスワードフィッシングを実質的に無効化できます。予備キーの管理は別途必要になりますが、運用さえ回れば非常に強力なパターンです。

展開のコツ：レポートオンリーから始める

ここまでパターンを紹介しましたが、条件付きアクセスは 効果が強すぎて事故になりやすい 機能でもあります。 実際に本番に展開する時は、いきなり「オン」にしないで、まず レポートオンリーモード で数日〜1週間動かし、サインインログで「このポリシーが適用されたら誰が影響を受けるか」を確認するのが安全です。その後、小さいユーザー群から段階的に展開していく流れをお勧めします。

あと、どのポリシーでも必ず 緊急用の例外アカウント（いわゆるBreak Glassアカウント） を除外しておくことも忘れないでください。自分でもヒヤッとしたことがありますが、条件付きアクセスでロックアウトされると、管理者自身がポータルに入れなくなる、という事故が起きます。Break Glassアカウントは条件付きアクセスのすべてのポリシーから除外し、使用を監視する、というのがMicrosoftの公式推奨です。

まとめ

条件付きアクセスは一見シンプルに見えますが、ライセンスによる機能差、リスクの種類、継続的アクセス評価、認証強度など、周辺の概念を整理しないと設計がブレがちです。今回紹介した5つのパターンは、現場でそのまま使えるか、ちょっと調整すれば使えるくらいの粒度でまとめてあります。

個人的には、最初はパターン1（管理者MFA）とパターン2（場所ベース）の2つから入って、運用が安定してから応用パターンに手を出すのが一番安全だと思っています。ゼロトラストは一気に完成させるものではなく、段階的に強化していくものなので、焦らず一歩ずつ積み上げていくのが結局近道でした。