Microsoft Entraの「Microsoft-managed Conditional Access policies」は、管理者が一から条件付きアクセスを設計しなくても、MFA要求、レガシー認証のブロック、デバイスコードフローの制限、高リスクサインインへの対応などを導入しやすくするMicrosoft管理の条件付きアクセスポリシーです。結論から言うと、管理者が最初に確認すべきなのは「どのポリシーがテナントに作成されているか」「Report-onlyの影響結果」「除外すべき緊急アクセスアカウントやTeamsデバイス用アカウント」「既存ポリシーとの重複・競合」です。
2026年5月29日時点で特に注意したいのは、公式情報上で「Block device code flow」ポリシーにTeamsデバイス向けの例外設計ガイダンスが追加された点です。Teams Rooms、Teams Androidデバイス、共有Teamsデバイスなどを使っている組織では、デバイスコードフローを全面的にブロックする前に、TeamsデバイスのリソースアカウントとDevice Registration Serviceの扱いを確認しておく必要があります。GitHub上の更新履歴では、2026年5月28日のコミットで該当ガイダンスへのリンク追加と日付更新が行われています。(GitHub)
Microsoft EntraのMicrosoft管理条件付きアクセスポリシーとは
Microsoft-managed Conditional Access policiesは、Microsoftが作成・保守する事前構成済みの条件付きアクセスポリシーです。対象となるMicrosoft Entraテナントには、ライセンスや機能の条件に応じてポリシーが作成され、初期状態では通常「Report-only」として配置されます。ポリシーには、MFAの要求などMicrosoftが推奨する制御が含まれます。(Microsoft Learn)
通常の条件付きアクセスポリシーとの違いは、ポリシーのテンプレートや基本構成をMicrosoftが管理する点です。管理者はポリシー名の変更や削除はできませんが、ポリシー状態の変更、除外対象の設定、必要に応じた複製によるカスタムポリシー作成は可能です。(Microsoft Learn)
| 項目 | Microsoft-managed Conditional Access policiesの特徴 | 管理者が確認すべきこと |
|---|---|---|
| 作成者 | Microsoftが対象テナントに作成 | Conditional Access一覧の「Created by」列を確認 |
| 初期状態 | 基本的にReport-only | 影響を確認してOnまたはOffを判断 |
| 編集範囲 | 状態変更と除外設定などに限定 | 追加変更が必要なら複製して管理 |
| 自動有効化 | Report-onlyのまま残すと、導入後45日以上経過後に有効化される場合がある | Message centerとメール通知を確認 |
| 通知 | 有効化の28日前に通知される | Microsoft 365 Message centerを定期確認 |
| 対象範囲の変化 | 条件に合う新しいユーザー、グループ、ワークロードが既存ポリシーの対象に含まれる可能性がある | 除外設定と影響レポートを継続確認 |
重要なのは、「Microsoftが管理しているから何もしなくてよい」と考えないことです。ポリシー自体はMicrosoftが保守しますが、どのユーザー・デバイス・アプリに影響するか、どの例外を認めるかは各組織の責任で判断する必要があります。
2026年5月更新で管理者が特に見るべきポイント
今回の更新で実務上の影響が大きいのは、「Block device code flow」ポリシーとTeamsデバイスの関係です。デバイスコードフローは、ブラウザーや入力インターフェイスが限られた機器で使われる認証方式ですが、攻撃者がユーザーにコード入力を促すフィッシングにも悪用されやすい認証フローです。Microsoftは、可能な限りデバイスコードフローをブロックすることを推奨しています。(Microsoft Learn)
一方で、Teams Rooms、Teams Androidデバイス、共有Teamsデバイスなどでは、初回登録、再プロビジョニング、一部の再認証シナリオでデバイスコードフローが必要になる場合があります。そのため、単純に全ユーザーでブロックすると、会議室端末や共有端末のセットアップが失敗する可能性があります。(Microsoft Learn)
Teamsデバイスがある環境での確認事項
| 確認項目 | 見落とした場合の影響 | 推奨対応 |
|---|---|---|
| Teamsデバイス用リソースアカウントの棚卸し | 会議室端末や共有端末が登録・再認証できない | Teamsデバイスに割り当てたリソースアカウントを一覧化する |
| 例外グループの設計 | 広すぎる除外でデバイスコードフローのリスクが残る | Teamsデバイス用リソースアカウントだけを含める |
| Device Registration Serviceの除外 | デバイス登録がブロックされる | 対象リソースからDevice Registration Serviceを除外する |
| Report-onlyでの検証 | 本番端末で突然サインイン失敗が起きる | 有効化前にサインインログとポリシー影響を確認する |
| 非Teams用途のデバイスコードフロー | 開発ツールやCLIが使えなくなる | 必要性、所有者、代替手段、例外期間を明文化する |
ここで避けたいのは、「Teamsデバイスがあるから全社員を例外にする」という対応です。例外はアカウント単位で効くため、広いユーザーグループを除外すると、Teams以外の用途でもデバイスコードフローを使える状態が残ります。例外は、真に必要なTeamsデバイスのリソースアカウントに限定し、所有者と棚卸し周期を決めて管理するのが安全です。
対象となるMicrosoft管理ポリシーと影響範囲
公式ドキュメントで示されているMicrosoft管理ポリシーには、管理者向けMFA、全ユーザー向けMFA、レガシー認証ブロック、高リスクユーザーのアクセス制限などが含まれます。環境によって表示されるポリシーや対象範囲は異なるため、まず自社テナントで実際に作成されているポリシーを確認してください。(Microsoft Learn)
| ポリシー | 主な目的 | 影響を受けやすい対象 | 確認ポイント |
|---|---|---|---|
| Block all high risk agents from accessing all resources（Preview） | 高リスクと判定されたエージェントIDのアクセスをブロック | エージェントID、ワークロード関連の利用 | Preview扱いである点と対象条件 |
| Block legacy authentication | レガシー認証プロトコルをブロック | 古いOfficeクライアント、IMAP、SMTP、POP3など | 業務メール連携や古い複合機設定 |
| Block device code flow | デバイスコードフローをブロック | Teamsデバイス、IoT機器、CLI、開発ツール | Teamsデバイス例外とDevice Registration Service |
| Multifactor authentication for admins accessing Microsoft Admin portals | 管理ポータル利用時に管理者へMFAを要求 | 特権管理者 | 緊急アクセスアカウント、管理者教育 |
| Multifactor authentication for all users | 全ユーザーにMFAを要求 | 全従業員、ゲスト以外の対象ユーザー | MFA登録状況、サポート体制 |
| Multifactor authentication for per-user multifactor authentication users | per-user MFA利用者を条件付きアクセスへ寄せる | 旧来のper-user MFA設定ユーザー | 条件付きアクセスへの移行計画 |
| Multifactor authentication and reauthentication for risky sign-ins | 高リスクサインイン時にMFAと再認証を要求 | 高リスクと判定されたサインイン | Microsoft Entra ID P2、対象グループ |
| Block access for high-risk users | 高リスクユーザーのアクセスを制限 | 漏えい資格情報などでリスク判定されたユーザー | リスク修復プロセス、ヘルプデスク対応 |
| Require phishing resistant authentication for admins | 管理者にフィッシング耐性のある認証を要求 | 管理者ロール保有者 | Baseline security modeとの関係 |
特に「Block legacy authentication」は、古いメールクライアントや業務システム連携で問題になりやすいポリシーです。Microsoftの説明では、パスワードスプレー攻撃の大部分がレガシー認証プロトコルを使うとされており、基本認証を無効化またはブロックすることが重要な防御策になります。(Microsoft Learn)
Baseline security modeとの違いも確認する
条件付きアクセス一覧には、Microsoft管理ポリシーに近い見え方をする「Baseline security mode」由来のポリシーも表示される場合があります。公式情報では、Baseline security modeのうち「Require phishing resistant authentication for admins」と「Block legacy authentication」が条件付きアクセスポリシーとして表示されると説明されています。これらはMicrosoft管理ポリシーのフレームワークに基づきますが、「Created by」列にはBaseline security modeとして表示され、Microsoft 365 admin centerで管理されます。(Microsoft Learn)
混同しやすいポイントは、通常のMicrosoft-managed policiesはMicrosoftが作成するのに対し、Baseline security modeのポリシーは管理者が作成する点です。トラブル対応時に「Entra管理センター側で変更できない」と迷わないよう、どの管理画面で制御するポリシーなのかを運用手順書に明記しておくとよいでしょう。
管理者が最初に確認すべき設定
Microsoft管理ポリシーは、Microsoft Entra admin centerの条件付きアクセスポリシー一覧から確認できます。最小権限で確認する場合は、Conditional Access Administratorロールが必要です。(Microsoft Learn)
確認手順
- Microsoft Entra admin centerにサインインする
Entra ID>Conditional Access>Policiesを開く- 一覧で
Created by列を確認する Microsoftと表示されるポリシーを開く- ポリシーの状態が
Report-only、On、Offのどれかを確認する Excluded identitiesに緊急アクセスアカウントなどが適切に含まれているか確認するPolicy impactタブで影響範囲を確認する- サインインログで実際の成功・失敗・Report-only結果を確認する
Microsoft管理ポリシーでは、緊急アクセスアカウント、いわゆるbreak-glassアカウントを他の条件付きアクセスポリシーと同様に除外することが推奨されています。除外を忘れると、MFA構成ミスやポリシー競合が起きたときに、管理者がテナントへ入れなくなるリスクがあります。(Microsoft Learn)
サインインログで見るべきフィルター
Microsoft管理ポリシーの影響は、ポリシー画面のPolicy impactだけでなく、Microsoft Entraのサインインログでも確認します。公式手順では、Correlation ID、Conditional Access、Username、Dateなどのフィルターを使い、対象イベントのConditional Accessタブから適用ポリシーを確認する流れが示されています。(Microsoft Learn)
| 確認したいこと | 使うフィルター・観点 | 判断の目安 |
|---|---|---|
| 特定ユーザーがブロックされた理由 | Username、Conditional Access | どのポリシーで失敗したかを確認 |
| 問い合わせ対象のイベント | Correlation ID | ヘルプデスクや監査ログと突合 |
| 展開前の影響 | Conditional Access、Date | Report-onlyで失敗扱いになるサインインを抽出 |
| Teamsデバイスの影響 | Authentication protocol、Original transfer method | Device code flow由来のサインインを確認 |
| レガシー認証の依存 | Client app、Authentication protocol | POP、IMAP、SMTPなどの利用を洗い出す |
Teamsデバイス向けのデバイスコードフロー確認では、単に現在のAuthentication protocolだけを見ると見落としが出る場合があります。公式ガイダンスでは、現在の利用棚卸しには Authentication protocol = Device code flow、後続セッションやトラブルシュートには Original transfer method = Device code flow も確認する考え方が示されています。(Microsoft Learn)
開発者・運用担当に影響しやすいポイント
Microsoft-managed Conditional Access policiesは、ID管理者だけでなく、アプリケーション開発者、インフラ運用担当、情シスの端末管理担当にも影響します。特に注意したいのは、ユーザー名とパスワードに依存した認証、古いプロトコル、デバイスコードフロー、手動運用を前提にした管理者アカウントです。
| 影響を受けやすい実装・運用 | 起きやすい問題 | 推奨対応 |
|---|---|---|
| ROPCやユーザー名・パスワード認証 | MFA要求を満たせず認証エラーになる | MSALや認証方式の見直し、対話型認証や安全な代替へ移行 |
| Azure CLI、PowerShell、開発者向けCLI | デバイスコードフローがブロックされる | ブラウザー認証、管理者が承認した例外、代替認証を検討 |
| バッチやスクリプトで使うユーザーアカウント | MFA要求で自動処理が止まる | managed identity、service principal、workload identity federationへ移行 |
| 古いメール連携 | IMAP、SMTP、POP3などがブロックされる | Modern Authentication対応方式へ切り替える |
| Teams Roomsや共有Teamsデバイス | 初回登録や再認証に失敗する | リソースアカウント単位の例外とDevice Registration Service除外を設計 |
| 管理者アカウントの共有利用 | MFAや監査で運用が破綻する | 個人別管理者アカウント、PIM、緊急アクセス手順を整備 |
Microsoftの必須MFA関連ドキュメントでは、ROPCトークングラントフローがMFAと互換性を持たないこと、ユーザーIDをサービスアカウントのように使う自動化はワークロードIDへ移行することが推奨されています。(Microsoft Learn)
開発者向けに重要なのは、「条件付きアクセスで止まったら例外を追加する」ではなく、「その認証方式が今後も安全に使えるか」を判断することです。例外は一時的な回避策としては有効ですが、恒久的に広い例外を残すと、Microsoft管理ポリシーで得られる防御効果を弱めてしまいます。
展開前の実務チェックリスト
Microsoft管理ポリシーを有効化する前に、次の順番で確認すると失敗を減らせます。
| フェーズ | 作業内容 | 完了判断 |
|---|---|---|
| 棚卸し | Created byがMicrosoftまたはBaseline security modeのポリシーを一覧化 | 対象ポリシー名、状態、対象ユーザー、除外を把握している |
| 影響確認 | Policy impactとサインインログを確認 | Report-onlyでブロック予定のユーザー・アプリを説明できる |
| 例外設計 | break-glass、Teamsデバイスリソースアカウント、承認済み例外を整理 | 例外の所有者、理由、レビュー周期が決まっている |
| 既存ポリシー比較 | 既存の条件付きアクセスポリシーと重複・矛盾を確認 | 同じ制御が二重にかかる箇所を把握している |
| ユーザー通知 | MFA登録、端末登録、管理者サインイン影響を周知 | 問い合わせ先と対応手順が用意されている |
| 段階展開 | 重要部門や管理者から先に検証 | 業務影響が許容範囲である |
| 有効化 | Report-onlyからOn、またはOffを判断 | 監査ログと変更履歴に記録している |
| 継続監視 | サインインログ、例外グループ、Message centerを確認 | 例外が増えっぱなしになっていない |
このチェックリストで最も重要なのは、例外設計です。条件付きアクセスの事故は、ポリシー自体の不具合よりも「除外すべき管理アカウントを除外していない」「除外しすぎてポリシーの意味がなくなる」という運用ミスで起きやすいためです。
移行時に見落としやすい設定
per-user MFAを使っている環境
Microsoftは、per-user MFAを現在の推奨構成とはしておらず、条件付きアクセスへの統合を推奨しています。Microsoft管理ポリシーには、per-user MFAが有効または強制されているユーザーを対象にするポリシーも含まれます。対象条件には、Microsoft Entra ID P1またはP2のライセンス、セキュリティ既定値が無効であること、per-user MFAの有効または強制ユーザー数が500未満であることなどが示されています。(Microsoft Learn)
移行時は、単にper-user MFAを無効化するのではなく、条件付きアクセスポリシーで同等以上のMFA要件が有効になっていることを確認してから切り替えます。急に切り替えると、ユーザーによってMFAが要求されない、または逆に想定以上に要求される状態になりかねません。
外部MFAやフェデレーションを使っている環境
外部MFAを使っている場合でも、Microsoft EntraのMFA要件を満たせるケースがあります。公式情報では、external authentication methodsによるMFAはMicrosoft管理ポリシーのMFA要件を満たすとされています。一方、フェデレーションIDプロバイダー経由のMFAは、構成によってMicrosoft Entra IDのMFA要件を満たす場合があります。カスタムコントロールはMFA要求を満たさないため、external authentication methodsへの移行が必要です。(Microsoft Learn)
確認すべき観点は、次の3つです。
- Microsoft Entra側でMFA済みとして正しく評価されるか
- サインインログ上でMFA要求の結果を確認できるか
- 古いカスタムコントロールに依存していないか
「ユーザーはMFAを通っているはず」という感覚ではなく、Microsoft Entraのサインインログで要求と結果を確認することが重要です。
高リスクサインイン・高リスクユーザーの扱い
高リスクサインイン向けポリシーでは、通常と異なるサインイン、パスワードスプレー、トークンリプレイなどのリスク検出をもとに、MFAや再認証が要求されます。高リスクユーザーのアクセスブロックでは、漏えい資格情報などによってアカウント侵害の可能性が高いと判断されたユーザーのアクセスを制限します。これらはMicrosoft Entra ID Protectionのリスク情報に依存するため、運用側ではリスク検出後の修復手順を用意しておく必要があります。(Microsoft Learn)
ヘルプデスクには、少なくとも次の対応手順を共有しておきましょう。
| 状況 | ヘルプデスクの初動 |
|---|---|
| ユーザーが高リスクでブロックされた | 本人確認、リスク検出内容の確認、パスワードリセットやMFA再登録の要否判断 |
| 管理者がMFAを求められた | 正常なポリシー適用か、緊急アクセス手順が必要かを切り分け |
| サインインログにReport-only失敗が出た | 有効化前に業務影響の有無を担当部門へ確認 |
| 海外出張やVPNでリスク判定された | 場所、端末、本人確認、リスク修復をセットで確認 |
Microsoft管理ポリシーを安全に有効化する進め方
まずReport-onlyで「止まるもの」を見る
Microsoft管理ポリシーは初期状態でReport-onlyとして作成されます。ここで何も確認せずに有効化すると、管理者、古いクライアント、Teamsデバイス、業務スクリプトなどが急に影響を受ける可能性があります。
Report-only期間に見るべきなのは、成功件数ではなく「有効化されたら失敗するサインイン」です。失敗予定のサインインについて、ユーザー、アプリ、認証プロトコル、場所、端末、業務上の必要性を確認します。
例外は「人」ではなく「用途」で管理する
例外グループは、便利だからといって大きく作るべきではありません。たとえば、Teamsデバイスのために「会議室管理チーム全員」を例外にすると、Teamsデバイス以外の用途でもデバイスコードフローが通ってしまいます。
良い例外設計は、次のような形です。
| 良い例外 | 悪い例外 |
|---|---|
| Teamsデバイス用リソースアカウントのみ | 情シス全員 |
| 承認済みCLI用途の限定グループ | 開発部全員 |
| break-glassアカウント2件程度 | すべての管理者 |
| 所有者とレビュー日が記録された例外 | 誰が追加したか不明な例外 |
例外は「なぜ必要か」「いつ見直すか」「誰が責任を持つか」をセットで管理します。条件付きアクセスでは、例外の肥大化が長期的なセキュリティ低下につながります。
必要なら複製して自社用ポリシーにする
Microsoft管理ポリシーは、細かな条件変更に制限があります。より細かく対象アプリ、ユーザー、条件、セッション制御を調整したい場合は、Microsoft管理ポリシーを複製し、自社用の条件付きアクセスポリシーとして管理する選択肢があります。公式情報でも、許可された範囲を超える変更が必要な場合は複製を検討すると説明されています。(Microsoft Learn)
ただし、複製したポリシーで制御を弱めすぎると、本来のセキュリティ効果が落ちます。たとえば「全ユーザーMFA」を複製したあと、多数のユーザーを除外すると、侵害リスクの高いアカウントが保護されない可能性があります。複製は「業務要件に合わせるため」であり、「面倒なMFAを避けるため」ではありません。
監査と変更検知のポイント
Microsoft管理ポリシーは、Microsoftによって追加・更新される可能性があります。管理者は、Message centerやメール通知に加え、監査ログでも変更を追跡できます。公式情報では、AuditLog.Read.All と Directory.Read 権限を持つ管理者が、Microsoft Managed Policy ManagerによるPolicyカテゴリの監査ログをMicrosoft Graphで照会できると説明されています。(Microsoft Learn)
https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?$filter=initiatedBy/app/displayName eq 'Microsoft Managed Policy Manager' and category eq 'Policy'運用では、次のタイミングで確認すると効果的です。
| タイミング | 確認内容 |
|---|---|
| Microsoft 365 Message centerに通知が来たとき | 対象テナント、対象ポリシー、有効化予定日 |
| 新しい管理者や部門を追加したとき | MFA対象、除外、特権ロールの有無 |
| Teamsデバイスを追加・廃止したとき | リソースアカウントの例外追加・削除 |
| 新しい業務システムを導入したとき | レガシー認証やデバイスコードフロー依存 |
| 月次セキュリティレビュー | Report-only結果、ブロック件数、例外グループの棚卸し |
監査で見るべきなのは、「Microsoftが何を変更したか」だけではありません。自社側で例外を追加し続けた結果、ポリシーの効果が弱くなっていないかを確認することも重要です。
よくある失敗と回避策
Report-onlyのまま放置する
Microsoft管理ポリシーは、Report-onlyのまま放置しても安全とは限りません。公式情報では、Report-onlyのまま残した場合、ポリシー導入後45日以上経過してからMicrosoftが有効化することがあるとされています。また、ケースによっては45日より早く有効化される可能性もあり、その場合はメール、Message center、ポリシー詳細で通知されます。(Microsoft Learn)
回避策は、Report-onlyの結果を見たうえで、組織として「Onにする」「Offにする」「複製して自社ポリシーにする」を明示的に決めることです。
緊急アクセスアカウントを除外していない
break-glassアカウントを除外していないと、MFA障害やポリシー設定ミスの際に管理者が復旧できなくなる恐れがあります。緊急アクセスアカウントは、普段使いの管理者アカウントとは別に管理し、利用時の監査・通知も設定しておきます。
Teamsデバイスのリソースアカウントを誤解する
Teamsデバイスの例外対象は、端末に割り当てられた会議室、共用エリア、共有デバイス用のリソースアカウントです。セットアップ作業を行う技術者や管理者のアカウントではありません。公式ガイダンスでも、この点が明確に区別されています。(Microsoft Learn)
デバイスコードフロー例外を広げすぎる
デバイスコードフローは、正規のMicrosoftサインインページを使う攻撃にも悪用されるため、ユーザーが偽サイトに気づくタイプのフィッシング対策だけでは防ぎにくい面があります。例外は、Teamsデバイスのリソースアカウントや承認済みの限定用途に絞り、未知の利用はブロックする前提で設計します。
外部MFAなら何でも通ると思い込む
外部MFAやフェデレーションを使っている場合でも、Microsoft Entra側でMFA要求を満たしたと評価されなければ、条件付きアクセスの制御を通過できません。特に古いカスタムコントロールはMFA要求を満たさないため、external authentication methodsへの移行計画が必要です。(Microsoft Learn)
管理者が今日やるべきこと
Microsoft EntraのMicrosoft-managed Conditional Access policiesは、MFAや危険な認証フローの制限を標準化し、組織のIDセキュリティを底上げするための仕組みです。ただし、Microsoftがポリシーを管理してくれることと、自社環境で安全に展開できることは別問題です。
まずは、次の5点を確認してください。
- Conditional Access一覧で、Created byがMicrosoftまたはBaseline security modeのポリシーを洗い出す
- 各ポリシーの状態がReport-only、On、Offのどれかを確認する
- break-glassアカウント、Teamsデバイスリソースアカウント、承認済み例外の設計を見直す
- Policy impactとサインインログで、有効化時に失敗するサインインを確認する
- レガシー認証、デバイスコードフロー、ユーザーベースの自動化アカウントを移行対象として整理する
特にTeamsデバイスを運用している環境では、Block device code flowを有効化する前に、Teamsデバイス用リソースアカウントの例外グループとDevice Registration Serviceの除外を確認することが重要です。セキュリティを強化するポリシーほど、例外設計を誤ると業務影響が大きくなります。Report-onlyを使って影響を可視化し、小さく例外を作り、定期的に見直す。この運用をセットにすることで、Microsoft Entraの条件付きアクセスを安全に展開できます。
コメント