条件付きアクセスは“業務を止めないゼロトラスト”設計である

山崎行政書士事務所　クラウド法務担当


MFAを強制する機能ではなく、リスクに応じてアクセスを調整する業務継続アーキテクチャ

条件付きアクセスという言葉を聞くと、多くの現場ではまずこう考えます。

「MFAを必須にする機能」
「社外アクセスを止める機能」
「危険な国からのアクセスをブロックする機能」
「管理者だけ厳しくする設定」

もちろん間違いではありません。
しかし、それだけでは条件付きアクセスの本質を捉えきれていません。

Microsoft公式ドキュメントでは、Microsoft Entra 条件付きアクセスは、さまざまなシグナルをまとめ、意思決定を行い、組織のポリシーを適用する Microsoftのゼロトラスト・ポリシーエンジン と説明されています。さらに、条件付きアクセスの最も単純な形は「if-then」、つまり「ユーザーがリソースにアクセスする場合は、必要なアクションを完了する」という考え方です。

ここで重要なのは、条件付きアクセスの目的が「止めること」ではない点です。
Microsoft公式は、管理者の主な目標として「場所や時間を問わずユーザーの生産性を向上させること」と「組織の資産を保護すること」の2つを挙げています。

つまり条件付きアクセスは、
業務を止める壁ではなく、
業務を止めずにリスクを下げる制御面です。

本記事では、条件付きアクセスを「MFA設定」ではなく、業務継続・ゼロトラスト・監査説明まで含めた設計として整理します。

1. まず結論：条件付きアクセス設計で決めるべきこと

条件付きアクセスの設計で最初に決めるべきことは、
「全員MFAにするか」
ではありません。

決めるべきことは、次の10項目です。

No設計項目決めること1守る対象Microsoft 365、Azure管理、業務SaaS、社内アプリ、特権操作2対象者一般社員、管理者、ゲスト、委託先、サービスアカウント、ワークロードID3リスクサインインリスク、ユーザーリスク、場所、デバイス状態、クライアントアプリ4制御MFA、認証強度、準拠デバイス、アプリ保護、利用規約、ブロック5業務影響どの部門・端末・アプリ・時間帯で影響が出るか6例外緊急アクセス、移行期間、レガシアプリ、委託先、検証ユーザー7検証What If、レポート専用、サインインログ、Log Analytics8展開パイロット、本番、段階適用、ロールバック9監視失敗率、ブロック数、ポリシー競合、緊急アカウント使用10説明経営層、監査、取引先、委託先にどう説明するか

条件付きアクセスは、技術的にはMicrosoft Entra IDのアクセス制御です。
しかし実務上は、ID統制、端末統制、SaaS統制、委託先統制、監査証跡、業務継続をまとめて扱う設計です。

2. 図で見る：条件付きアクセスの全体像

【図1】条件付きアクセスの考え方

ユーザー / 管理者 / ゲスト / ワークロードID / エージェント
        │
        │  サインイン要求
        ▼
┌──────────────────────────────┐
│ Microsoft Entra ID             │
│ 条件付きアクセス ポリシーエンジン │
└───────────────┬──────────────┘
                │
                │ シグナル評価
                ▼
┌──────────────────────────────┐
│ 評価シグナル                   │
│ ・ユーザー / グループ / ロール   │
│ ・対象リソース / アプリ / 操作   │
│ ・サインインリスク              │
│ ・ユーザーリスク                │
│ ・ネットワーク / 名前付き場所    │
│ ・デバイス状態 / 準拠性          │
│ ・クライアントアプリ             │
│ ・認証コンテキスト              │
└───────────────┬──────────────┘
                │
                │ if 条件に該当
                ▼
┌──────────────────────────────┐
│ アクセス制御                   │
│ ・MFAを要求                    │
│ ・認証強度を要求                │
│ ・準拠デバイスを要求            │
│ ・アプリ保護ポリシーを要求      │
│ ・利用規約への同意を要求        │
│ ・セッション制御                │
│ ・アクセスをブロック            │
└───────────────┬──────────────┘
                │
                ▼
       許可 / 制限付き許可 / ブロック

Microsoft公式では、条件付きアクセスは、リソースにアクセスできるユーザー、アクセスできるリソース、どのような条件下でアクセスできるかを決定し、アクセス許可、セッション制御による制限、またはブロックを行うものと説明されています。

この図で最も重要なのは、
条件付きアクセスは認証の後ろにある“業務判断エンジン”である
という点です。

同じユーザーでも、次の条件で判断が変わります。

ユーザー状況判断例社員社内の準拠PCからTeamsへアクセス許可社員未管理PCからSharePointへアクセスWebのみ、ダウンロード制限管理者自宅PCからAzure Portalへアクセスフィッシング耐性MFA＋準拠デバイス要求ゲスト海外IPから機密サイトへアクセスMFA要求、場合によりブロック営業出張先からCRMへアクセスMFA要求、セッション短縮高リスクユーザー通常と異なるサインインパスワード変更またはブロック

このように、条件付きアクセスは「誰でも一律に止める」のではなく、
リスクに応じて要求を変える仕組みです。

3. “業務を止めない”ための基本思想

条件付きアクセス設計で失敗する会社は、よく次の順番で考えます。

悪い順番：
1. とにかく強いポリシーを作る
2. すべてのユーザーに適用する
3. 本番でオンにする
4. 業務停止してから例外を作る

正しい順番は逆です。

良い順番：
1. 守る業務とリソースを分類する
2. 業務影響を予測する
3. 緊急アクセスと例外を先に設計する
4. レポート専用で影響を観測する
5. パイロット展開する
6. 段階的にオンにする
7. サインインログで継続監視する
8. 例外を期限付きで管理する

Microsoft公式の展開計画でも、条件付きアクセスの変更ではユーザーへのコミュニケーションが重要であり、体験がどう変わるか、いつ変わるか、問題が起きた場合のサポート方法を知らせる必要があると説明されています。

条件付きアクセスは、セキュリティ部門だけで作るものではありません。

情シス、SOC、ヘルプデスク、業務部門、委託先、経営層が、
「どこまで止めてよいか」
「どこからは自己修復にするか」
「緊急時に誰が戻すか」
を合意しておく必要があります。

4. NISTゼロトラストの視点：場所ではなくリソースを守る

NIST SP 800-207では、ゼロトラストは静的なネットワーク境界から、ユーザー、資産、リソースに焦点を移す考え方として説明されています。また、物理的な場所やネットワーク上の場所、資産の所有関係だけで暗黙の信頼を与えず、リソースへのセッション確立前に認証と認可を行う考え方が示されています。

この考え方をMicrosoft Entra条件付きアクセスに置き換えると、次のようになります。

NISTゼロトラストの考え方条件付きアクセスでの実装例ネットワーク境界を盲信しない社内IPだけで許可しないリソース中心に保護するアプリ、操作、認証コンテキスト単位で制御認証と認可を都度評価するサインインリスク、ユーザーリスク、デバイス、場所を見る暗黙の信頼を置かない管理者にもMFA、準拠デバイス、認証強度を要求最小権限を適用する一般ユーザー、管理者、ゲスト、委託先を分ける状態変化に対応するリスクベース制御、継続的アクセス評価、セッション制御

MicrosoftのZero Trust IDガイダンスでも、Microsoft Entra条件付きアクセスは、明示的に検証されたユーザーID、環境、デバイスの正常性、リスクに基づいてリソースアクセスを決定するポリシーエンジンと説明されています。

つまり、条件付きアクセスは、
「社内なら安全」から「条件を満たすなら安全」へ移行するための中核です。

5. 条件付きアクセス設計の三層モデル

条件付きアクセスは、1枚の巨大ポリシーで設計しない方がよいです。

三層に分けると整理しやすくなります。

【図2】条件付きアクセス三層モデル

┌──────────────────────────────┐
│ 第3層：高リスク・特権制御       │
│ ・管理者                         │
│ ・Azure管理                     │
│ ・PIM                           │
│ ・機密アプリ                     │
│ ・フィッシング耐性MFA             │
│ ・準拠デバイス / PAW              │
└───────────────▲──────────────┘
                │
┌───────────────┴──────────────┐
│ 第2層：業務アプリ制御           │
│ ・Microsoft 365                 │
│ ・SaaS                          │
│ ・SharePoint / Teams             │
│ ・未管理端末の制限               │
│ ・セッション制御                 │
│ ・認証コンテキスト               │
└───────────────▲──────────────┘
                │
┌───────────────┴──────────────┐
│ 第1層：共通ベースライン         │
│ ・全ユーザーMFA                  │
│ ・レガシ認証ブロック             │
│ ・セキュリティ情報登録保護       │
│ ・リスクベース制御               │
│ ・緊急アクセス除外               │
└──────────────────────────────┘

第1層は、全社共通の土台です。
第2層は、業務影響を見ながら調整する層です。
第3層は、特権・機密・高リスクを強く守る層です。

重要なのは、最初から第3層を全社員に適用しないことです。
全社員にいきなり「準拠デバイス必須」「フィッシング耐性MFA必須」「社外ブロック」を適用すれば、セキュリティ以前に業務が止まります。

6. ポリシーは“個別設定”ではなく“設計台帳”で管理する

条件付きアクセスの画面でポリシーを作っていくと、すぐに次の状態になります。

CA001 MFA
CA002 MFA test
CA003 block legacy
test policy
admin policy new
admin policy final
old policy
社外アクセス制限
一時対応

これは危険です。

どのポリシーが本番なのか。
誰が管理しているのか。
どの業務を守っているのか。
なぜ例外が入っているのか。
誰も説明できなくなります。

Microsoft公式の展開計画では、条件付きアクセスの名前付け標準として、シーケンス番号、対象クラウドアプリ、応答、対象ユーザー、適用タイミングなどを含めることが示されています。また、条件付きアクセスには所有者属性が組み込まれていないため、ポリシー名や別台帳で所有者を管理する考え方も説明されています。

ポリシー命名例

CA010-BASE-AllUsers-AllResources-RequireMFA-AnyNetwork-ReportOnly
CA020-BASE-AllUsers-LegacyAuth-Block-AnyNetwork-On
CA030-ADMIN-PrivilegedRoles-AdminPortals-RequirePhishResistantMFA-On
CA040-AZURE-AllAdmins-AzureManagement-RequireMFA-On
CA050-M365-AllUsers-ExchangeSharePoint-RequireCompliantOrMFA-On
CA060-RISK-AllUsers-AllResources-SignInRiskMediumHigh-RequireMFA-On
CA070-RISK-AllUsers-AllResources-UserRiskHigh-RequirePasswordChange-On
CA080-GUEST-ExternalUsers-AllResources-RequireMFA-On
CA090-SESSION-UnmanagedDevices-SharePoint-AppEnforcedRestrictions-On
CA900-BREAKGLASS-EmergencyAccess-Excluded-MonitorOnly

条件付きアクセス台帳テンプレート

項目記載例Policy IDCA030ポリシー名CA030-ADMIN-PrivilegedRoles-AdminPortals-RequirePhishResistantMFA-On所有者情シスID基盤チーム業務責任者情報システム部長対象ユーザー特権ロール保持者除外緊急アクセスアカウント、検証用グループ対象リソースMicrosoft管理ポータル、Azure管理条件任意のネットワーク、全クライアント制御フィッシング耐性MFA、準拠デバイス状態On検証方法What If、レポート専用、テストユーザーロールバックReport-onlyへ戻す、対象グループを除外最終レビュー2026-07-02例外期限2026-09-30監査証跡AuditLogs、SigninLogs、変更チケット

この台帳がないと、条件付きアクセスは“見えない壁”になります。
台帳があると、条件付きアクセスは“説明できる制御”になります。

7. 緊急アクセスを先に作る

条件付きアクセスで最も危険なのは、セキュリティを強くしすぎて、管理者自身が締め出されることです。

Microsoft公式では、誤ってMicrosoft Entra組織からロックアウトされないよう、組織内に2つ以上の緊急アクセスアカウントを作成することで、不注意による管理アクセス喪失の影響を軽減できると説明されています。緊急アクセスアカウントは、通常の管理アカウントを使えない緊急時、いわゆるブレークグラスシナリオでのみ使うべきものです。

緊急アクセス設計表

項目設計アカウント数少なくとも2つ種別.onmicrosoft.com ドメインのクラウド専用認証FIDO2パスキー、証明書ベース認証などロールグローバル管理者を永続的にアクティブ条件付きアクセスブロック・制限ポリシーから除外保管防火性のある安全な場所、複数人承認監視サインイン時に即時アラート訓練少なくとも90日ごとに検証使用後事後レビュー、承認確認、操作確認

Microsoft公式は、緊急アクセスアカウントをサインインをブロックまたは制限する条件付きアクセス ポリシーから除外すること、ただしサインインと監査ログを監視し、少なくとも90日ごとにアカウント機能を検証することを求めています。

KQL例：緊急アクセスアカウントのサインイン監視

let EmergencyAccounts = dynamic([
  "breakglass01@contoso.onmicrosoft.com",
  "breakglass02@contoso.onmicrosoft.com"
]);
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName in~ (EmergencyAccounts)
| project
    TimeGenerated,
    UserPrincipalName,
    IPAddress,
    Location,
    AppDisplayName,
    ResultType,
    ResultDescription,
    ConditionalAccessStatus,
    CorrelationId
| order by TimeGenerated desc

緊急アクセスアカウントは「例外」ではありません。
業務を止めないための安全弁です。

8. “ブロック”は最後の手段にする

条件付きアクセスには「アクセスをブロック」があります。
しかし、これは非常に強い制御です。

Microsoft公式も、ブロックアクセスは強力な制御であり、影響を理解している場合にのみ適用すべきで、大規模な制御を有効化する前にテストと検証を行い、レポート専用モードで潜在的な影響を把握するよう説明しています。

ブロックより先に検討すべき制御

リスクいきなりブロック業務を止めにくい制御社外アクセス全ブロックMFA要求、準拠デバイス要求未管理端末全ブロックWebのみ、ダウンロード制限高リスクサインイン全ブロックMFAで自己修復高リスクユーザー全ブロックセキュリティで保護されたパスワード変更ゲストアクセス全ブロックMFA、特定アプリのみ許可管理者操作全ブロックフィッシング耐性MFA、PIM、PAW特定国アクセス全ブロック重要アプリのみ制限、例外台帳

ブロックが必要な場面はあります。
レガシ認証、明らかに業務不要な地域、退職者、侵害確定ユーザーなどは、強く止めるべきです。

しかし、日常業務の制御では、まず
追加認証、デバイス条件、セッション制御、アプリ制限
を使って、業務継続と保護を両立させるべきです。

9. レポート専用モードで“影響を見てから止める”

条件付きアクセスを業務停止事故にしないための最大の武器が、レポート専用モードです。

Microsoft公式では、レポート専用モードでポリシーを保存すると、サインインログでリアルタイムサインインへの影響を確認でき、サインインイベントの「レポートのみ」タブから各レポート専用ポリシーの結果を表示できると説明されています。

また、条件付きアクセステンプレートで作成されるポリシーは既定でレポート専用モードで作成され、有効化前にテストと監視を行って意図した結果を確認するよう案内されています。

レポート専用の実務フロー

【図3】レポート専用から本番化まで

ポリシー設計
    │
    ▼
Report-onlyで作成
    │
    ▼
サインインログで影響確認
    │
    ├─ 想定外の部門が影響
    │      → 対象・除外・条件を修正
    │
    ├─ レガシアプリが失敗
    │      → アプリ移行・例外期限設定
    │
    ├─ 管理者ロックアウト懸念
    │      → 緊急アクセス確認
    │
    ▼
パイロットグループでOn
    │
    ▼
部門単位で段階展開
    │
    ▼
全社展開
    │
    ▼
月次レビュー

KQL例：レポート専用ポリシーの影響を見る

SigninLogs
| where TimeGenerated > ago(14d)
| where isnotempty(ConditionalAccessPolicies)
| mv-expand CAPolicy = ConditionalAccessPolicies
| extend
    PolicyName = tostring(CAPolicy.displayName),
    PolicyResult = tostring(CAPolicy.result)
| where PolicyResult startswith "reportOnly"
| summarize
    SignIns = count(),
    Users = dcount(UserPrincipalName),
    Apps = dcount(AppDisplayName),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by PolicyName, PolicyResult
| order by SignIns desc

このクエリで見るべきことは、単なる件数ではありません。

観点見ることreportOnlyFailure本番化すると失敗する可能性対象ユーザー数影響範囲対象アプリ数業務影響の広がり期間一時的な失敗か、継続的な失敗か部門業務プロセスの偏り端末未管理端末・旧OS・レガシクライアント

10. What Ifで“想定条件”を検証する

本番ログを見る前に、条件付きアクセスの適用結果をシミュレーションするには、What Ifツールを使います。

Microsoft公式では、What Ifツールは条件付きアクセス ポリシーの結果をシミュレートし、環境のトラブルシューティングと最適化に使うものと説明されています。評価結果では、適用されるポリシー、適用されないポリシー、満たす必要がある許可制御やセッション制御、適用されない理由を確認できます。

What Ifで検証すべきシナリオ

シナリオ例一般社員社外からSharePointへアクセス営業モバイル回線からTeamsへアクセス管理者自宅からAzure Portalへアクセスゲスト海外IPからTeamsへアクセス委託先未管理PCから業務SaaSへアクセス高リスクサインインリスク中以上緊急時緊急アクセスアカウントでサインイン例外ユーザー一時除外グループに入ったユーザーレガシアプリ旧クライアントからのアクセスモバイルiOS/Androidからのアクセス

What Ifは万能ではありません。
Microsoft公式も、シミュレーションはポリシー影響の把握に役立つが、適切に構成された開発環境での実テストを置き換えるものではないと説明しています。

したがって、What Ifは
設計レビュー用、
レポート専用は
実トラフィックでの影響確認用、
パイロットは
本番運用検証用
として使い分けます。

11. リスクベース制御で“止めずに自己修復”する

業務を止めないゼロトラストで重要なのが、リスクベース制御です。

Microsoft Entra ID Protectionのリスクベースアクセス制御では、サインインリスクとユーザーリスクという2つのユーザー固有のリスク条件を使い、各サインイン時にID Protectionが検出したリスクレベルを条件付きアクセスへ送り、条件が満たされるとリスクベースポリシーが適用されます。

サインインリスクとユーザーリスク

種別意味典型的な制御サインインリスクその認証要求が本人ではない可能性MFA要求、場合によりブロックユーザーリスクアカウント自体が侵害されている可能性セキュリティで保護されたパスワード変更、リスク修復、ブロック

Microsoft公式では、サインインリスクが中または高の場合にMFAを要求することができ、ユーザーはそのリスクレベルでのみプロンプトを受けると説明されています。また、ユーザーが必要なアクセス制御、たとえばセキュリティで保護されたパスワード変更を完了すると、リスクが修復され、管理者の調査・修復負担を軽減できるとされています。

さらに、ID Protectionと条件付きアクセスを組み合わせることで、危険なサインインや侵害されたユーザーを自動的に修復し、MFAやセキュリティで保護されたパスワード変更、SSPRなどを使ってユーザー影響を軽減できると説明されています。

リスクベース設計例

リスク条件制御業務継続の考え方サインインリスク低通常と異なるが低リスク許可または通常MFA過剰反応しないサインインリスク中疑わしいサインインMFA要求本人なら継続可能サインインリスク高攻撃疑いMFAまたはブロック高機密アプリではブロックユーザーリスク中侵害可能性ありMFA・監視強化自己修復ルートを用意ユーザーリスク高資格情報漏えい等パスワード変更要求ユーザー自身で復旧可能にするリスク修復不可MFA未登録等ブロックヘルプデスク導線を用意

なお、条件付きアクセスの利用にはMicrosoft Entra ID P1が必要であり、リスクベースのアクセス ポリシーにはMicrosoft Entra ID P2が必要とされています。

12. 認証強度で“どのMFAでもよい”を卒業する

MFAは重要です。
しかし、すべてのMFAが同じ強度ではありません。

SMS、音声通話、Authenticator通知、FIDO2、証明書ベース認証、Windows Hello for Businessは、攻撃耐性が異なります。

Microsoft公式では、認証強度は、ユーザーがリソースにアクセスするために使用できる認証方法の組み合わせを指定する条件付きアクセス制御であり、機密性の高いリソースに対してフィッシングに強い認証方法のみを要求するようなシナリオに対応できると説明されています。組み込み認証強度には、多要素認証強度、パスワードレスMFA強度、フィッシング耐性MFA強度があります。

認証強度の使い分け

対象推奨制御一般的なMicrosoft 365利用MFA社外からの業務SaaSMFAまたはパスワードレスMFA管理者フィッシング耐性MFAAzure管理フィッシング耐性MFA＋準拠デバイスPIMロール有効化認証コンテキスト＋強い認証経理・人事・法務データフィッシング耐性MFAまたは準拠端末ゲストの機密アクセス特定認証強度を要求

組み込みのフィッシング耐性MFA強度では、Windows Hello for Businessまたはプラットフォーム資格情報、FIDO2セキュリティキー、Microsoft Entra証明書ベース認証などが含まれます。

実務では、次のように考えます。

一般業務：
  MFAで業務継続を優先

管理者・特権操作：
  フィッシング耐性MFAを要求

機密データ：
  認証強度 + 準拠デバイス + セッション制御

緊急アクセス：
  通常管理者とは異なるフィッシング耐性認証を準備

13. デバイス条件は“ブロック”より“使い方を制限”する

未管理端末をすべてブロックできるなら簡単です。
しかし、現実には次のようなケースがあります。

  • BYODを一部認めている

  • 委託先が自社端末を使う

  • 出張中に一時端末が必要

  • スマートフォンからTeamsだけ使いたい

  • 退職前後の引き継ぎでWebアクセスだけ必要

  • 災害時に通常端末が使えない

ここで必要なのは、
「未管理端末は全部禁止」
ではなく、
「未管理端末では、できることを制限する」
という設計です。

条件付きアクセスのセッション制御では、アプリによって適用される制限、Microsoft Defender for Cloud Appsによるアプリ制御、サインイン頻度、永続的ブラウザーセッション、継続的アクセス評価のカスタマイズなどが利用できます。Defender for Cloud Appsのセッション制御では、機密ドキュメントのダウンロード、切り取り、コピー、印刷のブロックや危険なセッション動作の監視などが示されています。

端末状態別の制御例

端末状態制御例Intune準拠PC通常利用を許可Microsoft Entra Hybrid Join端末管理端末として許可未管理PCWebのみ、ダウンロード制限モバイル端末アプリ保護ポリシー要求不明OSブロックまたはレポート専用で確認管理者端末PAWまたは準拠デバイス必須緊急時端末期限付き例外、操作ログ強化

注意点として、Microsoft公式は、デバイスプラットフォームの特定には変更可能なユーザーエージェント文字列など未確認のソースが使われると説明しています。つまり、OS判定だけに過度な信頼を置くのではなく、準拠デバイス、アプリ保護、認証強度、セッション制御と組み合わせるべきです。

14. ネットワーク条件は“社内IPなら安全”にしない

条件付きアクセスでは、ネットワークや名前付き場所を使えます。
ただし、ここにも落とし穴があります。

Microsoft公式では、ユーザーの場所はパブリックIPアドレスまたはMicrosoft AuthenticatorアプリのGPS座標で決定されると説明されています。また、条件付きアクセスの場所条件はネットワークに移動・名称変更され、既存ポリシーは変更なしで引き続き機能すると案内されています。

ネットワーク条件の設計観点

設計対象注意点社内IPNAT、プロキシ、VPN、拠点追加で変わるVPN全ユーザーが同じ出口IPに見えるクラウドプロキシX-Forwarded-Forは信頼されない国/地域IPジオロケーションの精度に限界GPSユーザー体験への影響が大きいGlobal Secure Access準拠ネットワーク条件として活用可能不明な国/地域ブロック対象にするか慎重に判断

クラウドプロキシやVPNを利用する場合、条件付きアクセスの評価でMicrosoft Entra IDが使用するIPアドレスはプロキシのIPアドレスであり、X-Forwarded-Forヘッダーは信頼できるソースからの検証がないため使われないと説明されています。

悪い設計

社内IP = 信頼済み
信頼済みならMFA不要
MFA不要なら管理者操作も許可

良い設計

社内IP = リスク低減シグナルの一つ
ただし管理者・機密アプリではMFAや認証強度を要求
未管理端末は社内でも制限
信頼済み場所は定期棚卸し

ネットワーク条件は便利です。
しかし、ゼロトラストでは、場所は“信頼そのもの”ではなく“判断材料の一つ”です。

15. 継続的アクセス評価とセッション設計

条件付きアクセスは、サインイン時だけの制御ではありません。

継続的アクセス評価、CAEを使うと、ユーザー状態の変化により近いタイミングでアクセスを再評価できます。Microsoft公式では、CAE対応クライアントがMicrosoft Entraへ資格情報または更新トークンを提示し、すべての条件付きアクセス ポリシーが評価され、ユーザーが許可IP範囲外になると、リソースプロバイダーがアクセスを拒否し、クライアントへ要求チャレンジを返す流れが説明されています。

また、セッション制御にはサインイン頻度、永続的ブラウザーセッション、継続的アクセス評価のカスタマイズなどが含まれます。

セッション設計の考え方

業務サインイン頻度永続セッションCAE一般業務長め許可可標準経理・人事短め原則抑制有効管理者操作短め抑制厳格に検討未管理端末短め抑制有効共有端末短め抑制有効緊急運用状況に応じる証跡重視事後確認

サインイン頻度を短くしすぎると、ユーザーは頻繁に再認証を求められます。
長くしすぎると、侵害時の影響時間が伸びます。

ここは、セキュリティ部門だけでなく、ヘルプデスク、業務部門、経営層も含めて、業務影響を見ながら決めるべきです。

16. 認証コンテキストで“アプリ全体”ではなく“操作”を守る

条件付きアクセスは、アプリ単位だけでは粗い場合があります。

たとえば、同じSharePointでも、

  • 公開済み社内規程を見る

  • 人事評価ファイルを見る

  • 契約書をダウンロードする

  • PIMで特権ロールを有効化する

  • 管理ポータルでポリシーを変更する

ではリスクが違います。

ここで使えるのが認証コンテキストです。

Microsoft公式では、認証コンテキストはアプリケーションのデータとアクションを保護するもので、カスタムアプリ、LOBアプリ、SharePoint、Defender for Cloud Appsで保護されたアプリケーション、PIMでのロール有効化時の条件付きアクセス適用などに使えると説明されています。

認証コンテキストの利用例

対象通常アクセス機密操作SharePointMFA準拠デバイス＋利用規約業務アプリMFAフィッシング耐性MFAPIMMFA認証強度＋理由＋承認契約管理MFA管理端末＋セッション制御経理承認MFA強い認証＋端末制御

認証コンテキストは、条件付きアクセスを“アプリ単位の粗い壁”から、
操作単位の細かい統制へ進化させます。

17. レガシ認証は早めに潰す

レガシ認証は、条件付きアクセス設計で最初に確認すべき領域です。

Microsoftの条件付きアクセス テンプレートでは、セキュリティで保護された基盤の一つとして「レガシ認証をブロックする」が挙げられています。また、Azure ID管理とアクセス制御のベストプラクティスでも、攻撃者がパスワードスプレー攻撃で古いプロトコルの弱点を悪用しているため、レガシプロトコルをブロックするよう条件付きアクセスを構成することが推奨されています。

レガシ認証対策の流れ

1. サインインログでレガシクライアント利用を確認
2. 利用アプリ・ユーザー・部門を特定
3. 代替手段を用意
4. 例外期限を設定
5. レポート専用で影響確認
6. パイロットでブロック
7. 全社ブロック
8. 例外台帳を月次レビュー

KQL例：レガシ認証クライアントの確認

SigninLogs
| where TimeGenerated > ago(30d)
| where ClientAppUsed has_any (
    "Other clients",
    "IMAP",
    "POP",
    "SMTP",
    "MAPI",
    "Exchange ActiveSync"
)
| summarize
    SignIns = count(),
    Users = dcount(UserPrincipalName),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by ClientAppUsed, AppDisplayName, UserPrincipalName
| order by SignIns desc

列名や値はテナントやログ形式で差異があるため、実環境では SigninLogs | getschema やサインインログのフィルターで確認してください。

18. 管理者は別扱いにする

管理者アカウントは、一般ユーザーと同じ扱いにしてはいけません。

Microsoft公式の条件付きアクセス テンプレートでは、管理者保護カテゴリに、管理者へのMFA要求、レガシ認証ブロック、Azure管理へのMFA要求、準拠デバイスまたはハイブリッド参加デバイスの使用要求、フィッシング耐性MFA要求などが挙げられています。

管理者向け条件付きアクセス例

対象条件制御グローバル管理者全リソースフィッシング耐性MFA条件付きアクセス管理者ポリシー変更保護されたアクションAzure管理者Azure管理MFA＋準拠デバイスExchange管理者管理ポータルMFA＋セッション短縮PIM利用者ロール有効化MFA＋理由＋承認外部管理委託先管理対象アプリのみMFA＋時間制限＋監査

Microsoft公式の特権アクセス保護ガイダンスでは、PIMを使って特権ロールをジャストインタイムで有効化し、MFA、正当な理由、最大アクティブ化期間、承認を設定する例も示されています。

管理者には、次の考え方が必要です。

一般社員：
  業務継続と使いやすさを重視

管理者：
  攻撃影響が大きいため、強い認証と端末制御を重視

緊急アクセス：
  通常管理経路とは別に、厳重保管と監視を重視

19. 保護されたアクションで“ポリシー変更そのもの”を守る

条件付きアクセスは強力です。
だからこそ、条件付きアクセスを変更できる人を守る必要があります。

Microsoft公式の展開計画では、保護されたアクションを有効にすると、条件付きアクセス ポリシーを作成、変更、削除する前に追加の検証を要求できると説明されています。

保護されたアクションは、条件付きアクセス認証コンテキストを使って、条件付きアクセス ポリシーを1つ以上のアクセス許可に割り当てる仕組みです。

守るべき管理操作

操作追加制御条件付きアクセス ポリシー作成フィッシング耐性MFA条件付きアクセス ポリシー変更フィッシング耐性MFA＋準拠デバイス条件付きアクセス ポリシー削除PIM＋承認＋監査テナント間アクセス設定変更強い認証認証方法ポリシー変更強い認証管理者ロール変更PIM＋保護されたアクション緊急アクセス除外変更二者承認＋監査

条件付きアクセスは、攻撃者にとっても魅力的な標的です。
攻撃者が条件付きアクセスを緩められれば、他のセキュリティ制御も無力化されます。

20. ゲスト・委託先・外部ユーザーを分ける

B2Bゲストや委託先を、社員と同じ条件で扱うと失敗します。

  • 委託先は自社Intune準拠端末ではない

  • ゲストは自社MFAを持っている場合がある

  • 外部ユーザーに端末準拠を要求できないことがある

  • 監査上、委託先のアクセス範囲を説明する必要がある

  • 契約終了時にアクセスが残るリスクがある

Microsoft公式の展開計画では、既知で関係のある外部組織については、ゲストが提示するMFA、デバイスコンプライアンス、ハイブリッドデバイス要求を信頼できる場合があると説明されています。

外部ユーザー設計表

区分制御例一時ゲストMFA必須、対象アプリ限定、期限付き継続委託先専用グループ、アクセスレビュー、MFASOC委託先監視対象リソース限定、PIM、操作ログSIer管理ポータルはPIM＋MFA＋時間制限取引先SharePointサイト単位、ダウンロード制限外部管理者社員管理者より厳格に制御

条件付きアクセス単体では、外部委託先管理は完結しません。
契約、責任分界、アクセスレビュー、操作ログ、退職・契約終了時の削除手順までセットで設計すべきです。

21. サービスアカウントとワークロードIDは人間用ポリシーで守れない

条件付きアクセス設計で見落とされがちなのが、サービスアカウント、サービスプリンシパル、ワークロードIDです。

Microsoft公式では、サービスプリンシパルによる呼び出しは、ユーザーを対象とする条件付きアクセス ポリシーではブロックされず、サービスプリンシパルを対象とするポリシーにはワークロードIDの条件付きアクセスを使うと説明されています。さらに、スクリプトやコードで使っているアカウントはマネージドIDに置き換えることが推奨されています。

人間IDとワークロードIDの分離

区分例設計人間ユーザー社員、管理者、ゲスト条件付きアクセス特権ユーザー管理者、PIM利用者条件付きアクセス＋PIMサービスアカウントバッチ、旧スクリプト原則廃止・置換サービスプリンシパルアプリ認証ワークロードID制御マネージドIDAzureリソース間認証推奨構成AIエージェントIDエージェント実行主体専用ポリシー・台帳管理

人間のIDにMFAを強制しても、古いサービスアカウントに高権限シークレットが残っていれば、ゼロトラストとは言えません。

22. AIエージェント時代の条件付きアクセス

2026年時点のMicrosoft公式ドキュメントでは、条件付きアクセスの対象リソースとして「すべてのエージェント リソース（プレビュー）」が記載されており、エージェントIDブループリントプリンシパルとエージェントIDに対するトークン要求にポリシーが適用されると説明されています。

また、条件のページでは、エージェントリスクやエージェント実行環境がプレビューとして説明されており、エージェントが侵害される可能性や、エンドポイントから開始されたエージェントのユーザーアカウントセッションにポリシーをスコープする考え方が示されています。

AIエージェント時代の確認ポイント

項目確認エージェントID人間ユーザーと分けているかエージェントリソース条件付きアクセス対象に入るか実行環境端末起点か、クラウド実行かツール権限API、SharePoint、DB、チケット起票リスクエージェント侵害、過剰権限、ツール誤実行監査誰の代理で何をしたか例外AIエージェント用の例外が放置されていないか

今後の条件付きアクセス設計は、人間だけでなく、ワークロードID、AIエージェント、外部連携まで含める必要があります。

23. Microsoft推奨テンプレートを“そのままオン”にしない

Microsoft Entraには条件付きアクセス テンプレートがあります。

Microsoft公式では、条件付きアクセス テンプレートは、Microsoftの推奨事項と整合性がある新しいポリシーをデプロイする便利な方法であり、セキュリティで保護された基盤、ゼロトラスト、リモート作業、管理者の保護、新たな脅威、AIエージェントなどのカテゴリに分類されています。

テンプレートは有益です。
しかし、そのまま本番オンにするのは危険です。

テンプレート利用時の注意

注意点理由作成者だけが除外される場合がある他の緊急アクセスアカウントを除外する必要がある既定はレポート専用本番化前に影響確認が必要自社アプリ依存を確認レガシアプリや委託先アクセスが影響を受ける命名規則へ変更台帳管理・監査説明に必要例外期限を設定一時例外が恒久化しやすいグループ単位で展開いきなり全社適用しないJSONエクスポートPolicy as Codeに使う

Microsoft公式も、ユーザーを対象とする条件付きアクセス テンプレート ポリシーでは、作成しているユーザーのみがテンプレートから除外されるため、他のアカウントを除外する必要がある場合は作成後にポリシーを変更するよう注意しています。

24. Policy as Codeで変更管理する

条件付きアクセスは、ポータルで手作業だけで管理すると、変更履歴・レビュー・ロールバックが弱くなります。

Microsoft公式の展開計画では、Microsoft Graph conditionalAccessPolicy APIやMicrosoft Graph PowerShellを使って条件付きアクセス ポリシーをプログラムで管理し、ポリシーの一括作成、バージョン管理、監査を行うこと、ソース管理とCIを備えたPolicy as Codeワークフローを採用することが説明されています。

Microsoft Graphでは、条件付きアクセス ポリシーは conditionalAccessPolicy リソースとして表され、ポリシー一覧取得や更新APIが提供されています。

Graph PowerShell例：条件付きアクセスのバックアップ

# Microsoft Graph PowerShell を利用
# 実行には適切な権限と管理者同意が必要です

Connect-MgGraph -Scopes "Policy.Read.All"

$timestamp = Get-Date -Format "yyyyMMdd-HHmmss"
$outDir = ".\ca-backup-$timestamp"
New-Item -ItemType Directory -Path $outDir | Out-Null

Get-MgIdentityConditionalAccessPolicy -All |
  ForEach-Object {
    $fileName = ($_.DisplayName -replace '[\\/:*?"<>|]', '_') + ".json"
    $_ | ConvertTo-Json -Depth 30 | Out-File -FilePath (Join-Path $outDir $fileName) -Encoding utf8
  }

Policy as Code運用例

【図4】条件付きアクセス変更管理

要件
  │
  ▼
設計書・台帳更新
  │
  ▼
JSON / PowerShell / Graph定義
  │
  ▼
Pull Request
  │
  ├─ セキュリティレビュー
  ├─ 業務影響レビュー
  ├─ 緊急アクセス除外確認
  └─ ロールバック確認
  │
  ▼
検証テナント適用
  │
  ▼
Report-only
  │
  ▼
パイロットOn
  │
  ▼
本番On
  │
  ▼
監視・月次レビュー

条件付きアクセスは「画面で設定したから終わり」ではありません。
経営や監査に説明するなら、変更理由、承認者、実施者、影響評価、戻し方を残す必要があります。

25. 監視：サインインログと監査ログを見る

条件付きアクセスは、設定後の監視が本番です。

Microsoft公式では、Microsoft Entraサインインログを使って、サインインの問題のトラブルシューティング、機能パフォーマンス確認、テナントのセキュリティ評価ができ、サインインイベントの「条件付きアクセス」タブで適用されたポリシーを確認できると説明されています。

また、Microsoft Entraの診断設定で AuditLogs と SigninLogs をLog Analyticsへ送信し、KQLで分析できると説明されています。

KQL例：条件付きアクセス失敗の多いポリシー

SigninLogs
| where TimeGenerated > ago(7d)
| where isnotempty(ConditionalAccessPolicies)
| mv-expand CAPolicy = ConditionalAccessPolicies
| extend
    PolicyName = tostring(CAPolicy.displayName),
    PolicyResult = tostring(CAPolicy.result)
| where PolicyResult in ("failure", "reportOnlyFailure")
| summarize
    Failures = count(),
    Users = dcount(UserPrincipalName),
    Apps = dcount(AppDisplayName),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by PolicyName, PolicyResult
| order by Failures desc

KQL例：アプリ別の条件付きアクセス失敗

SigninLogs
| where TimeGenerated > ago(7d)
| where ConditionalAccessStatus in ("failure", "notApplied")
| summarize
    SignIns = count(),
    Users = dcount(UserPrincipalName),
    IPs = dcount(IPAddress)
    by AppDisplayName, ConditionalAccessStatus
| order by SignIns desc

KQL例：条件付きアクセス変更の監査

AuditLogs
| where TimeGenerated > ago(30d)
| where ActivityDisplayName has_any (
    "conditional access",
    "Conditional Access",
    "policy"
)
| project
    TimeGenerated,
    ActivityDisplayName,
    InitiatedBy,
    TargetResources,
    Result,
    CorrelationId
| order by TimeGenerated desc

監視すべきKPI

KPI意味CA失敗数業務影響・攻撃兆候reportOnlyFailure数本番化前の想定ブロックMFA要求数ユーザー負荷ブロック数強制制御の影響レガシ認証試行攻撃または旧アプリ管理者サインイン特権操作の監視緊急アクセス使用重大イベントポリシー変更統制変更例外グループ増加形骸化リスク国・IP異常攻撃兆候

条件付きアクセスは、作って終わりではありません。
ログで見続ける設計にして初めて、ゼロトラスト運用になります。

26. ロールバックを設計してから本番化する

条件付きアクセスの本番化で必ず必要なのが、ロールバック設計です。

Microsoft公式では、新しく実装したポリシーをロールバックする方法として、ポリシーを無効にする、ユーザーまたはグループを除外する、不要なら削除する、削除された条件付きアクセスや名前付き場所は30日間の論理削除期間内に復元できることが説明されています。

ロールバック設計表

事象戻し方注意特定ユーザーが業務不可一時除外グループへ追加期限付き、理由記録部門全体が影響対象グループを除外影響調査後に再適用管理者が締め出し緊急アクセスで復旧使用後レビューレガシアプリ停止例外ポリシー作成廃止期限を設定誤ってポリシー削除30日以内に復元変更監査を確認MFA障害コンティンジェンシーポリシー緊急時のみ有効化ネットワーク障害場所条件を一時緩和変更承認と監視

ロールバック用Runbook例

【条件付きアクセス障害時Runbook】

1. 受付
   ・ユーザー
   ・アプリ
   ・時刻
   ・エラー画面
   ・相関ID
   ・端末
   ・場所/IP

2. 確認
   ・SigninLogs
   ・条件付きアクセス タブ
   ・What If
   ・対象ポリシー
   ・直近のAuditLogs

3. 影響判定
   ・単一ユーザー
   ・部門
   ・全社
   ・管理者
   ・外部ユーザー
   ・重要業務

4. 暫定対応
   ・ポリシーをReport-onlyへ戻す
   ・対象グループを除外
   ・緊急アクセスで復旧
   ・コンティンジェンシーポリシーを有効化

5. 事後対応
   ・原因分析
   ・ポリシー修正
   ・例外期限設定
   ・利用者周知
   ・監査記録更新

条件付きアクセスの運用では、
「強いポリシーを作れること」よりも、
安全に戻せることが重要です。

27. セキュリティの既定値から条件付きアクセスへ移る時の注意

小規模テナントでは、セキュリティの既定値を使っている場合があります。

Microsoft公式では、セキュリティの既定値はセキュリティ態勢を開始するための適切なベースラインである一方、多くの組織が必要とするカスタマイズには対応しておらず、条件付きアクセスはより複雑な組織要件に対応するカスタマイズを提供すると説明されています。また、セキュリティの既定値を置き換える条件付きアクセス ポリシーを実装する組織では、セキュリティの既定値を無効にする必要があります。

移行時の注意

観点注意セキュリティの既定値簡単だがカスタマイズ不可条件付きアクセス柔軟だが設計責任が増える無効化タイミング代替ポリシーを先に準備緊急アクセス必ず先に検証MFA登録ユーザー登録状況を確認レガシ認証ブロック前に利用確認管理者保護先に強化レポート専用本番化前に影響確認

「セキュリティの既定値を無効にしたが、条件付きアクセスが未整備」
という状態は非常に危険です。

28. 条件付きアクセス設計パターン集

パターン1：全社MFAベースライン

項目内容対象全ユーザー除外緊急アクセス、移行中例外リソース全リソース条件任意のネットワーク制御MFA要求展開Report-only → パイロット → 全社注意MFA未登録者の導線を用意

パターン2：管理者強化

項目内容対象特権ロール保持者リソース管理ポータル、Azure管理条件任意制御フィッシング耐性MFA、準拠デバイス連携PIM、保護されたアクション注意緊急アクセス除外と監視

パターン3：未管理端末の制限付きアクセス

項目内容対象全ユーザーリソースSharePoint、Exchange、Teams条件未準拠端末制御アプリ制限、ダウンロード制御連携Defender for Cloud Apps、Intune注意いきなりブロックしない

パターン4：リスクベース自己修復

項目内容対象全ユーザー条件サインインリスク中以上制御MFA条件ユーザーリスク高制御セキュリティで保護されたパスワード変更注意Entra ID P2、SSPR、MFA登録が重要

パターン5：ゲストアクセス制御

項目内容対象ゲスト・外部ユーザーリソースTeams、SharePoint、業務SaaS制御MFA、対象アプリ限定補完アクセスレビュー、期限管理注意委託先契約・責任分界と連動

パターン6：Azure管理保護

項目内容対象管理者、Azure運用担当リソースAzure Resource Manager、Azure Portal制御MFA、認証強度、準拠デバイス注意Azure API依存のクライアントにも影響

Microsoft公式では、Windows Azure Service Management APIを対象にすると、Azure Resource Manager、Azure Portal、Application Insights API、Log Analytics APIなどに発行されたトークンにポリシーが適用され、Azure APIに依存するサービスやクライアントが間接的に影響を受ける可能性があると説明されています。

29. 条件付きアクセス設計チェックリスト

A. 基本設計

チェック内容□守る対象リソースを分類した□一般ユーザー、管理者、ゲスト、委託先を分けた□緊急アクセスアカウントを2つ以上用意した□緊急アクセスアカウントのサインイン監視を作った□条件付きアクセス台帳を作った□命名規則を決めた□例外管理台帳を作った

B. 技術設計

チェック内容□MFAベースラインを設計した□レガシ認証を確認した□管理者向けの強い認証を設計した□認証強度を使う対象を決めた□リスクベースポリシーを検討した□デバイス準拠・アプリ保護を整理した□名前付き場所を棚卸しした□セッション制御を設計した□認証コンテキストの利用可否を確認した

C. 展開設計

チェック内容□What Ifで代表シナリオを検証した□レポート専用モードで影響を見た□パイロットグループを作った□部門単位の展開計画を作った□ヘルプデスク向けFAQを作った□ユーザー周知を行った□ロールバック手順を作った

D. 監視・監査

チェック内容□SigninLogsをLog Analyticsへ送っている□AuditLogsをLog Analyticsへ送っている□条件付きアクセス失敗KQLを用意した□緊急アクセスサインインのアラートを作った□ポリシー変更監査を確認している□月次レビューを設定した□取引先・監査向け説明資料を作った

30. 監査・取引先説明で出せる成果物

条件付きアクセスは、監査で非常に説明しやすい領域です。
ただし、資料があれば、です。

提出・説明資料の例

成果物内容条件付きアクセス方針書基本思想、対象、例外、展開方針ポリシー一覧表Policy ID、対象、制御、状態、所有者アクセス権限マトリクス一般ユーザー、管理者、ゲスト、委託先緊急アクセス手順書ブレークグラス、保管、利用、監視例外管理台帳例外理由、期限、承認者、再評価日レポート専用評価結果本番化前の影響分析サインインログ分析失敗率、MFA要求、ブロック、リスク変更履歴AuditLogs、承認チケット、Graph差分ロールバック手順障害時の戻し方利用者周知資料何が変わるか、困った時の連絡先委託先責任分界表誰が設定し、誰が監視し、誰が対応するか経営層向け報告リスク低減、業務影響、残課題

山崎行政書士事務所では、Azure・Microsoft 365・Entra IDを利用する企業向けに、契約・責任分界・証跡・監査対応の整理を掲げ、アクセス権限マトリクス、ログ保存・提出設計表、例外管理台帳、監査回答シートなどを支援成果物として示しています。

条件付きアクセスは、まさにこの領域です。
技術設定でありながら、説明責任そのものです。

31. まとめ：条件付きアクセスは“止める設定”ではなく“続けるための設計”である

条件付きアクセスを、単なるMFA強制機能と考えると、業務を止めます。

しかし、条件付きアクセスを、
リスクに応じてアクセスを調整する業務継続アーキテクチャ
として設計すれば、ゼロトラストは現実的になります。

最後に、この記事の要点をまとめます。

要点意味条件付きアクセスはゼロトラストのポリシーエンジンif-thenでアクセス判断する目的は業務停止ではない生産性と資産保護の両立ブロックは最後の手段MFA、認証強度、端末、セッション制御を使う緊急アクセスが先ロックアウトを防ぐ安全弁レポート専用が必須本番前に業務影響を観測するWhat Ifで設計検証想定シナリオを事前確認リスクベース制御が重要本人なら自己修復、攻撃なら止める管理者は別扱いフィッシング耐性MFA、PIM、PAWログを見て初めて運用SigninLogs、AuditLogs、KQL台帳化して初めて説明可能監査、取引先、委託先に説明できる

条件付きアクセスは、業務を止めるための壁ではありません。

業務を止めずに、危険なアクセスだけを段階的に強くする設計です。

「社内だから安全」ではなく、
「条件を満たすから許可する」。

「危ないから全部止める」ではなく、
「危険度に応じて追加確認・制限・自己修復・ブロックを使い分ける」。

これが、Microsoft Entra 条件付きアクセスによる“業務を止めないゼロトラスト”です。

山崎行政書士事務所は、Azure・Microsoft 365・Entra IDの現場理解と、クラウド法務・責任分界・証跡整理の視点をつなぎ、情シス、SOC、法務、経営層が取引先・監査・委託先に説明できる条件付きアクセス設計を支援します。

※本記事は一般的な情報提供を目的としたものであり、個別案件の法的判断、紛争対応、訴訟対応等を行うものではありません。条件付きアクセス、個人情報、委託先管理、監査対応、契約上の責任分界等は、貴社の業種、契約、データ種別、Microsoft 365 / Azure / Entra ID構成、運用体制に応じて個別に整理する必要があります。

いいなと思ったら応援しよう！