条件付きアクセスの設計パターン｜ゼロトラスト実装の実務ガイド

「VPNさえ通ればあとは社内と同じ」——リモートワーク導入直後の現場で、こう言われたことはありませんか？

境界の外からのアクセスが当たり前になった今、「ネットワークの内側にいるから安全」という前提はすでに崩れています。必要なのは「誰が・どこから・何のデバイスで・どんな状況で」アクセスしているかを毎回判断する仕組みです。それが条件付きアクセスです。

この記事では、Microsoft Entra ID（旧Azure AD）の条件付きアクセスの仕組みと、現場で即使える設計パターンを整理します。

条件付きアクセスとは——「誰が・どこから・何で」アクセスするかで制御する仕組み

条件付きアクセス（Conditional Access） Microsoft Entra IDの機能。ユーザー・場所・デバイス・アプリケーションなどの条件を組み合わせて、アクセスの許可・ブロック・MFA要求を動的に制御するポリシーエンジン。

条件付きアクセスは「if-thenルール」の集まりです。「管理者が社外からアクセスしようとしたらMFAを要求する」「未登録のデバイスからはブロックする」——こうしたルールをポリシーとして定義し、アクセスのたびに自動で判断します。

ゼロトラストの考え方については「ゼロトラストとは？Azureでの実装パターン」で詳しく解説しています。

条件付きアクセスが必要になった背景——境界防御の限界

従来のセキュリティ設計は「社内ネットワーク＝安全」という前提に立っていました。ファイアウォールで外と内を分け、内側に入れたユーザーは信頼する——いわゆる境界防御モデルです。

しかしこの前提は、以下の変化によって崩れました。

条件付きアクセスはこの問題に対して「ネットワークの場所に関わらず、アクセスのたびにリスクを評価する」アプローチで応えます。

条件付きアクセスの構成要素を理解する

条件付きアクセスのポリシーは「シグナル」「条件」「アクセス制御」の3要素で構成されます。

シグナル——アクセスの「状況」を判断する材料

シグナルとは、ポリシーの判断に使われる情報のことです。主なシグナルは以下の通りです。

条件——どの状況に対してポリシーを適用するか

シグナルを組み合わせて「この条件に当てはまるアクセスに対してポリシーを適用する」と定義します。例えば「管理者グループのユーザーが、社外のIPアドレスからアクセスした場合」のように複数のシグナルを AND/OR で組み合わせられます。

アクセス制御——許可・ブロック・MFA要求を使い分ける

条件に一致したアクセスに対して、以下のいずれかの制御を適用します。

MFAの仕組みと種類については「MFAとは？」を参照してください。

現場で使える設計パターン4選

パターン1：管理者アカウントには必ずMFAを要求する

最優先で設定すべきポリシーです。管理者アカウントは攻撃者にとって最も価値の高いターゲットであり、パスワードだけでの保護は不十分です。

ポイント：管理者向けポリシーはBreak Glassアカウント（緊急用アカウント）を必ず除外対象にしてください。Break Glassアカウントをロックアウトしてしまうと、ポリシーの修正すらできなくなります。

PIMと組み合わせて特権アクセスを必要なときだけ有効化する設計については「PIMとは？」で解説しています。

パターン2：社外ネットワークからのアクセスにMFAを要求する

社内IPからのアクセスは許可し、それ以外にはMFAを要求するパターンです。リモートワーク環境でよく使われます。

ポイント：先に「信頼できる場所」として社内IPアドレスレンジをEntra IDに登録しておく必要があります。名前付きの場所（Named Locations）から設定してください。

パターン3：非準拠デバイスからのアクセスをブロックする

準拠デバイス（Compliant Device） Microsoft Intuneで管理され、組織のセキュリティポリシー（OSバージョン・暗号化・ウイルス対策など）を満たしていると判定されたデバイス。

管理されていない個人デバイスや、セキュリティ基準を満たさない端末からのアクセスをブロックするパターンです。

ポイント：Intuneの展開が完了していない環境でこのポリシーを有効にすると、全員がアクセスできなくなります。必ずレポート専用モードで影響範囲を確認してから有効化してください。

パターン4：リスクの高いサインインを自動でブロックする

サインインリスク（Sign-in Risk） Entra ID Protectionが機械学習でリアルタイムに評価するリスクスコア。普段と異なる国からのアクセス・匿名IPの使用・パスワードスプレー攻撃の検出などがトリガーになる。

漏えいした認証情報を使ったアクセスや、不審なサインインを自動で検出・ブロックするパターンです。Entra ID P2ライセンスが必要です。

設計前に決めておくべき3つのこと

ポリシーを作り始める前に、以下の3点を必ず整理してください。設計後に気づくと手戻りが大きくなります。

① Break Glassアカウントの用意

すべてのポリシーから除外する緊急用アカウントを事前に作成してください。条件付きアクセスの設定ミスで管理者全員がロックアウトされた場合の復旧手段になります。Break Glassアカウントはハードウェアトークンでのみ認証し、使用時に必ずアラートが発報される設計にしてください。

② レポート専用モードで事前検証

新しいポリシーは必ず「レポート専用モード」で作成し、実際に適用される前に影響範囲を確認します。本番適用前に「このポリシーを有効にしたら何人がブロックされるか」を把握できます。

③ ポリシーの適用順序と除外ユーザーの整理

複数のポリシーが重なる場合、より制限の強い制御が優先されます。「誰がどのポリシーの対象か・除外か」を一覧で管理する台帳を作っておくと、後から変更が入ったときに追跡しやすくなります。

よくある失敗パターン——設定ミスが招くリスクとロックアウト

① Break Glassアカウントを除外し忘れた

管理者全員にMFAを要求するポリシーを作ったはいいが、Break Glassアカウントを除外するのを忘れてロックアウト——というのは実際に起きる事故です。ポリシーを作成するたびにBreak Glassアカウントが除外リストに入っているか確認してください。

② レポート専用モードを使わずいきなり有効化した

「全員に準拠デバイスを要求する」ポリシーをいきなり有効にして、Intune未登録の端末ユーザー全員がアクセスできなくなったケースは珍しくありません。必ずレポート専用モードで数日間観察してから本番適用してください。

③ 「すべてのユーザー」に適用してゲストも巻き込んだ

「すべてのユーザー」を対象にしたポリシーは、ゲストユーザーや外部コラボレーターにも適用されます。取引先との共有フォルダへのアクセスが突然できなくなるといったトラブルの原因になります。ゲストユーザーは別ポリシーで管理するか、明示的に除外してください。

④ ポリシーが増えすぎて管理できなくなった

「とりあえず作ってきた」ポリシーが乱立し、どのポリシーが誰に当たっているか把握できなくなるケースです。ポリシーには命名規則を設け（例：CA001_管理者_MFA要求_全場所）、台帳で一元管理する運用を最初から設計してください。

実務チェックリスト——条件付きアクセス設計の確認ポイント

設計前の準備

• [ ] Break Glassアカウントを作成し、全ポリシーの除外リストに追加したか
• [ ] 信頼できる場所（社内IP）をNamed Locationsに登録したか
• [ ] ポリシーの命名規則と管理台帳を決めたか

ポリシー設計

• [ ] 管理者アカウントへのMFA要求ポリシーを設定したか
• [ ] 社外からのアクセスにMFAを要求するポリシーを設定したか
• [ ] 新規ポリシーをレポート専用モードで検証したか
• [ ] ゲストユーザーへの影響を確認したか

運用・監視

• [ ] サインインログで条件付きアクセスの適用状況を定期確認しているか
• [ ] Break Glassアカウントの使用アラートが設定されているか
• [ ] ポリシーの定期レビュー（半期に1回程度）の運用があるか

IAM設計全体のチェックリストは「クラウドIAM設計チェックリスト」にまとめています。

まとめ——今日確認すべきことは1つです

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

まだ設定されていなければ、まずこの1本だけをレポート専用モードで作成してください。影響範囲を確認してから有効化するだけで、管理者アカウントへの不正アクセスリスクを大幅に下げられます。

クラウドIAM設計でよくある失敗全般については「クラウドIAM設計でよくある失敗」で、Azure RBAC設計の落とし穴は「Azure RBAC設計でよくある失敗6選」でそれぞれ解説しています。

あわせてご覧ください

• ゼロトラストとは？Azureでの実装パターン
• MFAとは？多要素認証の仕組みと実務での導入・運用ガイド
• PIMとは？Azure特権アクセス管理の実務ガイド
• IAMとは？認証と認可の違いから学ぶアクセス管理の基本
• クラウドIAM設計でよくある失敗5選と対策【認証のミスが招くセキュリティ事故】
• Azure RBAC設計でよくある失敗6選と対策【初心者でもわかる権限設計】