条件付きアクセスとは？設計パターンと実務ガイド｜Entra IDでゼロトラストを実装する

「MFAを設定したから大丈夫」——現場でこう言われると、少し立ち止まって考えてほしくなります。

MFAは確かに強力な認証手段です。ただ、MFAを設定しているだけでは「誰でもMFAを通過さえすればアクセスできる」状態になります。海外から不審なIPでアクセスしてきた場合でも、私物の未管理デバイスからのアクセスでも、MFAを通過すれば許可されてしまいます。

その「条件をつけてアクセスを制御する」仕組みが条件付きアクセスです。本記事では条件付きアクセスの仕組みから現場でよく使う設計パターンまで解説します。

Entra IDとオンプレADの連携構成については「Entra IDとオンプレAD連携｜ハイブリッド構成の設計と注意点」を参照してください。

条件付きアクセスとは

条件付きアクセスとは——誰が・どこから・何にアクセスするかで判断する仕組み

条件付きアクセスとは、ユーザーのサインイン時に「誰が・どこから・どのデバイスで・何にアクセスしようとしているか」を評価し、アクセスの許可・拒否・追加認証要求を動的に判断するMicrosoft Entra IDの機能です。

条件付きアクセス（Conditional Access） Microsoft Entra IDが提供するアクセス制御機能。ユーザー・場所・デバイス・アプリケーションなどの条件を組み合わせて、アクセスを許可するか・MFAを要求するか・ブロックするかをポリシーとして定義できる。ゼロトラストの「常に検証する」原則を実装する中心的な仕組み。

ゼロトラスト（Zero Trust） 「信頼しない、常に検証する」を原則とするセキュリティモデル。社内ネットワークにいるからといって安全とは見なさず、すべてのアクセスを継続的に検証する考え方。条件付きアクセスはその実装手段の一つ。

条件付きアクセスはIF-THENの構造で動作します。「もし○○の条件に当てはまるなら、△△の制御を適用する」というポリシーを定義します。

MFAとの違い——MFAは手段、条件付きアクセスは判断の仕組み

MFAと条件付きアクセスはよく混同されますが、役割が異なります。

MFAを条件付きアクセスの制御の一つとして組み込むことで、「管理者アカウントには常時MFAを要求する」「海外IPからのアクセスはブロックする」など、状況に応じた柔軟な制御が実現できます。

MFAの仕組みと実務導入については「MFAとは？多要素認証の仕組みと実務での導入・運用ガイド」を参照してください。

設定できる条件と制御の組み合わせ

条件（IF）——ユーザー・場所・デバイス・アプリ

条件付きアクセスポリシーで設定できる主な条件は以下です。

制御（THEN）——許可・MFA要求・ブロック・準拠デバイスのみ

条件に合致したときの制御には以下の種類があります。

MDM（Mobile Device Management：モバイルデバイス管理） スマートフォンやPCなどのデバイスをリモートで一元管理する仕組み。MicrosoftのIntuneを使うと、デバイスが会社のセキュリティポリシーに準拠しているかどうかを評価できる。条件付きアクセスと組み合わせることで「準拠デバイスのみアクセス許可」を実現できる。

現場でよく使う設計パターン

パターン①——海外IPからのアクセスをブロックする

国内ビジネスのみの組織では、海外IPからのアクセスをブロックするポリシーが有効です。

設定内容：

IF：
　ユーザー：全ユーザー
　場所：許可された国（日本）以外
　アプリ：すべてのクラウドアプリ

THEN：
　アクセスをブロック

まず「ネームド ロケーション」で日本のIPレンジや国を「信頼できる場所」として登録し、それ以外をブロックします。出張・海外リモートワークがある場合は対象ユーザーをポリシーから除外するか、別途例外ポリシーを作成してください。

パターン②——管理者アカウントに常時MFAを要求する

ASD「Detecting and Mitigating Active Directory Compromises」でもEntra IDの特権ユーザー全員へのMFA有効化が強く推奨されています。管理者アカウントが侵害されると被害が甚大になるため、条件に関わらず常時MFAを要求するのが基本です。

設定内容：

IF：
　ユーザー：グローバル管理者・特権ロール管理者などの管理者ロール
　アプリ：すべてのクラウドアプリ
　場所：すべての場所（信頼済みIPも含む）

THEN：
　多要素認証を要求

「信頼済みIPからは除外」という設定を入れてしまうと、社内ネットワークから侵害された場合にMFAが機能しません。管理者アカウントは場所に関わらず常時MFAを要求してください。

特権アカウントの設計原則については「AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務」も参照してください。

パターン③——非準拠デバイスからのアクセスを制限する

会社管理外のデバイス（私物PC・スマートフォン）からのアクセスを制限するパターンです。Intuneと組み合わせて使います。

設定内容：

IF：
　ユーザー：全ユーザー
　アプリ：Microsoft 365（Exchange・SharePoint等）
　デバイス：準拠していないデバイス

THEN：
　アクセスをブロック（またはMFAを要求）

完全なブロックを適用する前に、まずMFA要求から始めると移行がスムーズです。Intuneが未導入の場合は「ハイブリッド参加済みデバイスのみ許可」という形でドメイン参加済みデバイスに限定する方法もあります。

現場でよくある設定ミス

① レポート専用モードを外さずに本番適用してしまう

条件付きアクセスには「レポート専用モード」があり、ポリシーを実際には適用せずに影響をシミュレーションできます。このモードのまま「設定完了」と思い込んでしまうケースがあります。ポリシーを有効にする前に必ず「有効」に切り替えたか確認してください。

レポート専用モード（Report-only Mode） 条件付きアクセスポリシーの影響を実際には適用せずにテストできるモード。サインインログに「レポート専用：許可」などの結果が記録されるが、実際のアクセス制御は行われない。本番適用前の動作確認に使う。

② 全ユーザーにブロックをかけて自分もロックアウトする

「全ユーザーを対象にしたブロックポリシー」を設定した際に、設定した管理者自身もロックアウトされるケースがあります。ポリシーを適用する前に必ず緊急アクセスアカウント（Break Glass アカウント） をポリシーの除外リストに追加してください。

緊急アクセスアカウント（Break Glass Account） 通常の管理者アカウントが使えなくなった緊急時のために用意するグローバル管理者アカウント。条件付きアクセスポリシーから除外しておき、MFAも別の方法（物理キーなど）で管理する。このアカウントのサインインは厳重に監視する。

③ 緊急アクセスアカウントをポリシーから除外していない

すべての条件付きアクセスポリシーに緊急アクセスアカウントの除外設定が漏れているケースがあります。1つでも除外が漏れると、そのポリシーによって緊急時にアクセスできなくなります。ポリシーを作成・変更するたびに緊急アクセスアカウントの除外設定を確認してください。

④ 条件が複雑になりすぎて管理できなくなる

ポリシーが増えすぎて「どのポリシーが誰に適用されているか分からない」状態になるケースがあります。ポリシーは目的別にシンプルに分割し、命名規則を統一して管理してください。例えばCA001-管理者-常時MFA要求のように番号・対象・目的を含めると管理しやすくなります。

チェックリスト

初期設定の確認

• 緊急アクセスアカウント（Break Glass）が作成されており、全ポリシーから除外されている
• レポート専用モードで動作確認を行ってからポリシーを有効化している
• ポリシーの命名規則を統一して管理している

ポリシー内容の確認

• 管理者ロールに常時MFAを要求するポリシーが有効になっている
• 信頼済みIPからも管理者へのMFAを除外していない
• 海外IPブロックポリシーがある場合、出張者等の例外設定が考慮されている
• 非準拠デバイスへの制御ポリシーが設定されている

運用の確認

• サインインログで条件付きアクセスの適用結果を定期的に確認している
• 緊急アクセスアカウントのサインインログを監視している
• ポリシー変更時には必ずレポート専用モードでテストしてから本番適用している

まとめ

今日確認すべきことは1つです。管理者アカウントに常時MFAを要求する条件付きアクセスポリシーが有効になっているか確認してください。

Entra IDの管理センター（entra.microsoft.com）→「保護」→「条件付きアクセス」から現在のポリシー一覧を確認し、管理者ロールを対象にしたMFA要求ポリシーが「有効」になっていることを確認してください。

条件付きアクセスはゼロトラストの入口です。まず管理者アカウントへのMFA要求から始め、海外IPブロック・非準拠デバイス制限と段階的に拡張していくアプローチが現場では無理なく定着します。

Entra IDのサインインログで不審なアクセスを検知する方法については「Entra IDのサインインログ分析入門｜不審なサインインを見つける実務ガイド」で詳しく解説しています。

あわせてご覧ください

• Entra IDとオンプレAD連携｜ハイブリッド構成の設計と注意点
• Entra IDのサインインログ分析入門｜不審なサインインを見つける実務ガイド
• MFAとは？多要素認証の仕組みと実務での導入・運用ガイド
• AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務

参考文献

• 参考：条件付きアクセスとは（Microsoft Learn）
• 参考：緊急アクセス用管理者アカウントを管理する（Microsoft Learn）
• 参考：Detecting and Mitigating Active Directory Compromises（ASD・ACSC）