Entra ID 条件付きアクセス設計の基本｜最初に押さえる4つのポリシー

Microsoft 365やAzureを使い始めた企業で、必ずと言っていいほど相談を受けるのが「条件付きアクセスをどう設計すればいいか」です。
機能としては知っている、ポリシーも作れる。しかし「何をどこまで作れば適切なのか」の判断基準がなく、場当たり的にポリシーが増えていく——実際の支援現場でも、こうした状態になっているテナントをよく見かけます。

この記事では、条件付きアクセスを「最初に」設計するときの考え方と、まず作るべき基本ポリシーのセットを整理します。

この記事でわかること

• 条件付きアクセスを設計するときの基本的な考え方

• 最初に作るべき基本ポリシーのセット

• 事故を起こさずに展開するための手順と、よくある失敗

※本記事は、Microsoft Entra ID P1以上を利用できる環境（Microsoft 365 Business Premium、E3/E5等を含む）を前提としています。ユーザーリスク・サインインリスクを利用した条件付きアクセスには、Entra ID P2が必要です。

条件付きアクセスは「ゼロトラストの入口」

条件付きアクセスは、サインインのたびに「誰が・どのデバイスから・どこから・何にアクセスしようとしているか」を評価し、許可・拒否・追加認証を判断する仕組みです。
社内ネットワークにいるかどうかで信頼を判断する境界型の考え方から、「すべてのアクセスを検証する」ゼロトラストへ移行する際の、最初の実装ポイントになります。

ここで大切なのは、条件付きアクセスは「制限の仕組み」ではなく「信頼の条件を明確に判断する仕組み」という捉え方です。
「MFAを強制する」ではなく「MFAを通った人を信頼する」。この視点で設計すると、ポリシーの目的が明確になり、後から見た人にも意図が伝わる構成になります。

逆に、最初にやってはいけないのが「思いつくままの全部盛り」です。
場所条件、デバイス条件、アプリ条件、リスク条件—条件付きアクセスは条件の組み合わせが自由なだけに、初期から複雑なポリシーを大量に作ると、どのポリシーが適用されているのか誰にも分からなくなります。
ポリシー同士の相互作用は本数が増えるほど読みにくくなり、「なぜサインインできないのか」「なぜこのユーザーには適用されないのか」という調査に時間を要するようになります。

最初に作るべき基本ポリシーセット

Microsoftが提供している推奨テンプレートには、セキュリティ情報登録の保護やデバイス準拠の要求など、さらに多くのポリシーが用意されています。本記事では、その中でも私たちが新規テナントや整理し直しの案件で、初期設計として特に優先して確認する4つに絞って紹介します。

1. 全ユーザーにMFAを要求する

もっとも基本のポリシーです。対象は「すべてのユーザー」、条件は付けず、許可の制御で「多要素認証を要求」。対話型で利用する一般ユーザーは、原則としてすべて対象とします。緊急用アカウントと、Entra Connectの同期アカウントのようにシステム連携で利用する非対話型のアカウントについては、用途を確認したうえで個別に設計します。スクリプト等で使っているアカウントは、可能であればマネージドIDへの移行を検討するのがおすすめです。

「営業所のPCは社内からしか使わないからMFA不要では」といった声が必ず出ますが、初期セットの段階で場所による免除を作るのはおすすめしません。一度定着した例外は、後から廃止することが難しくなるためです。まずは全員MFA、不都合が出た箇所は個別に検討する順番が、結果的に設計をシンプルに保ちます。

2. 管理者ロールには、より強い認証を要求する

グローバル管理者をはじめとする特権ロールは、一般ユーザーと同じMFAでは不十分です。フィッシング耐性のある認証方式（FIDO2セキュリティキーやパスキー等）を要求するポリシーを分けて作ります。管理者アカウントは攻撃者から見れば「テナントの鍵」であり、ここだけは初期段階から一段強い基準を適用する価値があります。

3. レガシー認証をブロックする

MFAを強制しても、レガシー認証（基本認証を使う古いプロトコル）が有効なままでは、そこが迂回路になります。現在では既定で無効化が進んでいますが、テナントの歴史が長いほど古い設定や機器（複合機のSMTP送信など）が残っているものです。まずレポートでレガシー認証のサインインが残っていないかを確認し、影響がないことを確かめたうえでブロックポリシーを適用します。

4. 緊急用アカウント（ブレークグラス）を設計してから除外する

すべてのポリシーに共通する重要事項が、緊急用アカウントの設計です。条件付きアクセスの設定ミスで全管理者がロックアウトされると、テナントの復旧は非常に困難になります。そのための「最後の入口」として、条件付きアクセスの対象から除外した緊急用アカウントを2つ以上用意します。オンプレミスに依存しないクラウド専用のアカウントとし（`.onmicrosoft.com` ドメインでの作成が推奨されています）、認証にはフィッシング耐性のある方式を使います。

実際の支援現場では、緊急用アカウントが存在せず、日常運用の管理者アカウントがすべてを兼ねている——そんな危険な状態のテナントを少なからず見てきました。緊急用アカウントは「作っていて当たり前」のものではなく、意識して設計しないと存在しないものだと考えてください。

ただし「除外されたアカウント」はそれ自体がリスクです。次の4点をセットで運用します。

• 認証情報は通常の管理者と分離し、物理的に安全な場所に保管する

• 使用されたら即座に検知できるよう、サインインのアラートを構成する

• 90日ごとを目安に、実際にサインインできることを確認する（いざという時に使えない緊急用アカウントは意味がありません）

• 定期的に棚卸しし、「なんとなく除外されているアカウント」を増やさない

事故を起こさない展開手順

ポリシーの中身と同じくらい重要なのが、展開の順番です。

1. レポート専用モードで作る。 条件付きアクセスには、ポリシーを適用せずに「適用されたらどうなっていたか」だけを記録するレポート専用モードがあります。新しいポリシーは必ずここから始めます。

2. サインインログで影響を確認する。 1〜2週間ほど運用し、サインインログで「このポリシーが有効だったら誰がブロックされていたか」を確認します。想定外のブロック対象（サービスアカウント、複合機、古いアプリ）は、この段階であぶり出します。

3. 小さなグループから段階適用する。 いきなり全社適用せず、情報システム部門→協力的な部門→全社の順で対象を広げます。問い合わせ対応の準備（MFA登録の案内、ヘルプデスクへの周知）も、この段階展開に合わせて行います。

4. 適用後も「除外」を定期的に見直す。 展開時にやむを得ず作った除外は、恒久化させないことが大切です。除外一覧の棚卸しを運用カレンダーに組み込みます。

よくある失敗

最後に、実際の現場で繰り返し見てきた失敗パターンを挙げます。

• 自分をロックアウトする。 ポリシー適用の対象に自分自身と緊急用アカウントを含めてしまう、最も古典的な事故です。緊急用アカウントの除外を必ず先に構成してください。

• レポート専用モードを飛ばす。 「検証環境で確認したから大丈夫」は通用しません。本番テナントには検証環境に存在しないアカウントと機器が必ずあります。

• 例外が既得権になる。 「一時的に」の除外が数年残り続けるパターンです。除外には理由と期限をメモとして残し、棚卸しの仕組みで担保します。

• ポリシー名から意図が読めない。 「ポリシー1」「テスト」のような名前は、数年後の担当者（未来の自分を含む）への負債です。「対象-条件-制御」が読み取れる命名規則を最初に決めておきます。

まとめ

条件付きアクセスの設計は、高度な条件を組み合わせることよりも、シンプルな基本セットを確実に適用し、例外を管理し続けることに価値があります。まずは「全員MFA・管理者強化・レガシー認証ブロック・緊急用アカウント」の4点を、レポート専用モードからの段階展開で確実に入れる。応用的なポリシー（デバイス準拠、場所、リスクベース）は、この土台が安定してからで十分です。