Microsoft EntraでZero Trustを安全に段階導入する方法｜report-onlyと緊急アクセス設定

Microsoft EntraでZero Trustを導入する際は、最初から「全ユーザー・全リソース・ブロック」を有効化してはいけません。安全な進め方は、アクセス経路の棚卸し、緊急アクセスアカウントの準備、Conditional Accessのreport-only検証、限定グループへの適用、Global Secure Accessの段階展開という順番です。

特に重要なのは、user riskとsign-in riskを一つのポリシーにまとめず、目的と修復方法が異なる別ポリシーとして管理することです。Microsoftも、report-only、緊急アクセスアカウントの除外、段階的な展開によって、ロックアウトや業務停止のリスクを抑える方法を案内しています。(TECHCOMMUNITY.MICROSOFT.COM)

Entra Zero Trustを安全に導入する基本方針

Microsoft EntraにおけるZero Trustは、Conditional Accessだけを有効にすれば完成するものではありません。

Conditional Accessは、ユーザー、デバイス、場所、リスク、対象リソースなどの情報を基に、アクセスを許可するか、追加認証を求めるか、ブロックするかを判断するポリシーエンジンです。一方、Global Secure Accessは、Microsoft Entra Private AccessとMicrosoft Entra Internet Accessを通じて、オンプレミス、クラウド、SaaS、AIサービス、インターネットへの通信経路にもID中心の制御を広げます。(Microsoft Learn)

役割を整理すると、次のようになります。

機能	主な役割	主な対象
Conditional Access	アクセス可否と要求条件を判断する	ユーザー、管理者、クラウドアプリ、Private Accessアプリ
Microsoft Entra ID Protection	user risk、sign-in riskを検出する	侵害が疑われるIDやサインイン
Microsoft Entra Private Access	プライベート通信を取得して制御する	オンプレミス、IaaS、RDP、SSH、SMB、社内Webアプリ
Microsoft Entra Internet Access	インターネット通信を取得して制御する	SaaS、生成AI、一般Webサイト、インターネット接続
Global Secure Access Client	端末から対象通信を転送する	Windows端末など
Private Network Connector	Private Accessと内部リソースを接続する	オンプレミスやプライベートクラウド

安全な導入では、これらを一度に全社展開しません。まずConditional Accessで現在のアクセス状況を観測し、その後、Private Access、Internet Accessの順に対象を広げます。

最初にアクセス面を棚卸しする

ポリシーを作る前に、「誰が、どの端末から、どの経路で、何にアクセスしているか」を一覧化します。

Microsoft 365やAzureポータルだけを調べても不十分です。次のようなアクセスも対象に含めてください。

SaaSや生成AIサービス
オンプレミスの業務システム
RDP、SSH、SMBなどの非Web通信
Azureや他社クラウド上のプライベートリソース
PowerShell、Azure CLI、自動化スクリプト
POP、IMAP、SMTPなどを利用する古いシステム
ゲスト、委託先、外部パートナーによるアクセス
サービスアカウント、サービスプリンシパル、マネージドID
VPN、DirectAccess、プロキシ、拠点ルーターを通る通信

棚卸し表には、少なくとも次の項目を記録します。

項目	記録する内容
利用者	ユーザー、部署、管理者ロール、外部ユーザー
対象リソース	アプリ名、FQDN、IPアドレス、ポート、プロトコル
認証方式	パスワード、MFA、証明書、Kerberos、サービスプリンシパル
端末条件	Entra参加、ハイブリッド参加、Intune準拠、BYOD
現在の経路	直接接続、VPN、プロキシ、拠点ネットワーク
将来の経路	Conditional Access、Private Access、Internet Access
障害時の影響	全社停止、部署停止、個人のみ、影響軽微
代替経路	既存VPN、管理用端末、緊急アクセスアカウント
管理責任者	アプリ担当、ネットワーク担当、ID管理担当
例外期限	一時除外の終了日と見直し日

ここで重要なのは、アプリ名だけではなく、実際に呼び出されるリソースまで確認することです。たとえば、ユーザーはTeamsにサインインしているつもりでも、裏側ではExchange OnlineやSharePoint Onlineなど複数のリソースが利用されます。

Conditional AccessのWhat Ifツールは特定条件をシミュレーションできますが、サービス間の依存関係までは判定しません。Microsoftも、TeamsのシミュレーションではExchange Onlineなどの依存リソースが考慮されない例を示しています。最終判断には、実際のサインインログが必要です。(Microsoft Learn)

緊急アクセスアカウントを先に準備する

Conditional Accessを作成する前に、緊急アクセスアカウントを用意します。通常の管理者アカウントがポリシー設定ミスや認証基盤障害で利用できなくなった場合に、テナントへ復旧アクセスするためのアカウントです。

Microsoftの現行ガイダンスでは、次の構成が推奨されています。(Microsoft Learn)

緊急アクセスアカウントを少なくとも2つ作成する
オンプレミスADや外部IdPに依存しないクラウド専用アカウントにする
.onmicrosoft.comドメインを使用する
通常の管理者とは異なる認証方法を登録する
FIDO2セキュリティキーや証明書ベース認証など、フィッシング耐性のある方式を使用する
Global Administratorを永続的に有効な状態で割り当てる
専用の安全な管理端末からのみ使用する
すべての利用を監視し、サインイン時に通知する
少なくとも90日ごとにサインインと管理操作をテストする

緊急アクセス用グループを作る

個別のアカウントを各ポリシーから除外するのではなく、たとえば次のような専用セキュリティグループを作成します。

SG-EmergencyAccess

作成するConditional Accessポリシーでは、原則としてこのグループを除外します。将来、緊急アカウントを変更した場合も、グループメンバーを更新するだけで済みます。

report-onlyでも最初から除外を設定する

Microsoft Learnでは、report-onlyポリシーはアクセスをブロックしないため、この段階では緊急アクセスアカウントの除外は必須ではないと説明されています。一方、ブロックや制限を実際に強制するポリシーからは除外が必要です。(Microsoft Learn)

実務では、report-onlyで作成する段階から緊急アクセスグループを除外しておくことを推奨します。検証後にポリシーをOnへ変更した際、除外設定を追加し忘れる事故を防げるためです。

ただし、除外するのはアクセス制御だけです。緊急アクセスアカウントのサインインログや監査ログは必ず監視し、使用された時点で管理者へ通知してください。

Conditional Accessはreport-onlyから始める

report-onlyは、Conditional Accessポリシーの条件を実際のサインインに対して評価しながら、MFA要求、ブロック、セッション制御などを強制しないモードです。

判定結果は、サインインログのConditional AccessおよびReport-onlyの項目に記録されます。(Microsoft Learn)

report-onlyの結果を正しく読む

結果	意味	確認すべきこと
Report-only: Success	必要な条件をすでに満たしている	既存のMFAクレームや準拠状態で満たしていないか
Report-only: Failure	条件に該当し、非対話型要件を満たせない	ブロック対象、非準拠端末、未対応クライアントを確認
Report-only: User action required	MFAなどの利用者操作が必要になる	MFA登録状況、認証方法、利用者への周知を確認
Report-only: Not applied	ポリシーの条件に該当しない	除外、対象アプリ、場所、端末条件が正しいか確認

「User action required」は、ポリシー設定に失敗したという意味ではありません。report-onlyではMFA画面を表示しないため、実際に強制した場合にユーザー操作が必要になるサインインを示します。

反対に、Successが多いから安全とも限りません。既存トークンにMFA情報が含まれていたため、追加操作なしで成功している可能性があります。新しい端末、セッション切れ、異なるネットワークなどでも検証する必要があります。

report-onlyポリシーの作成手順

基本的な手順は次のとおりです。

Microsoft Entra管理センターへサインインする
Entra IDからConditional Accessを開く
Policiesから新しいポリシーを作成する
目的が分かるポリシー名を付ける
対象ユーザーまたはパイロットグループを指定する
緊急アクセスグループを除外する
対象リソースを選択する
リスク、端末、場所、クライアントなどの条件を指定する
MFA、認証強度、準拠端末、ブロックなどの制御を指定する
Enable policyをReport-onlyにする
設定内容を再確認して作成する

ポリシー名には、対象、目的、状態が分かる規則を設けると管理しやすくなります。

ポリシー名の例	用途
`CA-OBS-RISK-SIGNIN-MEDHIGH`	sign-in riskの全体観測
`CA-OBS-RISK-USER-HIGH`	user riskの全体観測
`CA-ENF-PILOT-MFA-ALLRESOURCES`	パイロットユーザーへのMFA強制
`CA-ENF-GSA-PRIVATE-FINANCE`	財務部門のPrivate Access制御
`CA-BLOCK-LEGACYAUTH`	レガシ認証のブロック

既存のOnポリシーをreport-onlyへ戻さない

既存ポリシーの変更を検証する場合、現在Onになっているポリシーをreport-onlyへ変更してはいけません。変更した時点で、既存の強制が停止するためです。

安全な方法は、現在のポリシーを複製し、変更案を反映したコピーをreport-onlyで作成することです。現在のOnポリシーとreport-onlyのコピーを比較し、結果を確認した後で本番ポリシーを変更します。(Microsoft Learn)

複数ポリシーは上書きではなく合算される

Conditional Accessには、ファイアウォールルールのような上から順番に評価する優先順位はありません。1回のサインインに複数ポリシーが適用される場合、適用対象となったすべてのポリシーを満たす必要があります。

たとえば、あるポリシーがMFAを要求し、別のポリシーが準拠端末を要求している場合、MFAと準拠端末の両方が必要です。別のポリシーでアクセスが許可されていても、どれか一つがブロックすればアクセスできません。(Microsoft Learn)

パイロットポリシーだけを見るのではなく、既存ポリシーとの組み合わせを確認してください。

user riskとsign-in riskは別ポリシーにする

user riskとsign-in riskは似ていますが、検出対象と必要な対応が異なります。

user riskは、ユーザーID自体が侵害されている可能性を表します
sign-in riskは、特定の認証要求が本人によるものではない可能性を表します

Microsoft Entra ID Protectionでは、この二つのリスクを別々にConditional Accessへ渡します。(Microsoft Learn)

項目	user risk	sign-in risk
判定対象	ユーザーIDやアカウント	個別のサインイン要求
代表的な意味	資格情報漏えいや継続的な侵害の疑い	今回のアクセスが本人ではない疑い
Microsoftの基本例	High	Medium、High
主な制御	Require risk remediation	MFAの認証強度を要求
主な結果	認証方式に応じたアカウント修復	強い認証で今回のサインインを確認
必要ライセンス	Microsoft Entra ID P2	Microsoft Entra ID P2

現行のMicrosoftガイダンスでは、user riskはHigh、sign-in riskはMediumとHighを対象とする構成例が示されています。ただし、実際のリスクレベルは組織の許容度やサポート体制に合わせて決定します。(Microsoft Learn)

sign-in riskポリシーの構成例

設定項目	設定例
Users	All users
Exclude	`SG-EmergencyAccess`
Target resources	All resources
Sign-in risk	Medium、High
Grant	Grant access
Authentication strength	Multifactor authentication
Sign-in frequency	Every time
Enable policy	Report-only

sign-in riskポリシーを本番化する前に、対象ユーザーがMFAを登録済みか確認してください。リスクがあるセッションではMFA登録が許可されないため、未登録ユーザーはサインインを完了できず、AADSTS53004が表示される場合があります。(Microsoft Learn)

したがって、先に認証方法登録キャンペーンや通常のMFAポリシーを展開し、MFA登録率を確認してからsign-in riskを強制する必要があります。

user riskポリシーの構成例

設定項目	設定例
Users	All users
Exclude	`SG-EmergencyAccess`
Target resources	All resources
User risk	High
Grant	Grant access
Control	Require risk remediation
Sign-in frequency	Every time
Enable policy	Report-only

Require risk remediationでは、ユーザーの認証方式や検出された脅威に応じた修復が行われます。パスワードを利用するユーザーでは、MFAによる本人確認後に安全なパスワード変更を行う流れが中心です。

ハイブリッドID環境では、オンプレミス側のパスワード変更をuser riskの修復として扱うために、パスワードハッシュ同期などの構成確認が必要です。MFA未登録ユーザーも自己修復できないため、先に認証方法の準備状況を確認してください。(Microsoft Learn)

リスクポリシーを分ける理由

二つのリスクを別ポリシーにすると、次の利点があります。

サインイン単位の異常とアカウント単位の侵害を区別できる
MFA要求とアカウント修復の影響を別々に測定できる
誤検知時に片方だけを調整できる
サインインログで適用理由を追いやすい
パイロット展開やロールバックを個別に行える
ヘルプデスクへの問い合わせ原因を特定しやすい

一つの巨大なポリシーへ条件を詰め込むより、小数の目的別ポリシーとして管理した方が、障害時の原因切り分けが容易です。

旧ID Protectionリスクポリシーは移行する

2026年9月3日時点のMicrosoft Learnでは、Microsoft Entra ID Protectionで設定する旧形式のuser risk、sign-in riskポリシーは、2026年10月1日に廃止予定と案内されています。

旧ポリシーを利用しているテナントでは、次の順序で移行します。

同等のConditional Accessポリシーをreport-onlyで作成する
サインインログで影響を確認する
パイロットグループでConditional Access側をOnにする
問題がないことを確認する
対象を段階的に拡大する
旧ID Protectionポリシーを無効化する

新旧ポリシーを同時に強制すると、想定外の重複制御が起きる可能性があります。切り替え順序と変更記録を明確にしてください。(Microsoft Learn)

report-onlyの評価方法

report-onlyを作成した後は、単に数日放置するのではなく、複数の方法で結果を確認します。

サインインログ

個別のサインインについて、次の項目を確認します。

適用されたポリシー
適用されなかったポリシーと理由
対象リソース
クライアントアプリ
端末情報
ネットワークや場所
user risk、sign-in risk
MFAの実行状況
Report-onlyの判定結果
相関IDとエラーコード

管理者、一般ユーザー、モバイル利用者、社外利用者、サービスアカウントなど、利用形態の異なるユーザーを抽出して確認します。

Conditional Access Insights and Reporting

Conditional Access Insights and Reportingワークブックを利用すると、report-onlyとOnのポリシーを期間、ユーザー、アプリ、端末、場所、sign-in riskなどで比較できます。

利用には、Conditional Access用のMicrosoft Entra ID P1以上に加え、サインインログを送信するLog Analyticsワークスペースが必要です。(Microsoft Learn)

特に確認したいのは、次の数値です。

想定外のFailure
User action requiredとなるユーザー数
MFA未登録ユーザー
非準拠端末からのアクセス
レガシクライアントの利用
管理者アカウントへの影響
部署やアプリごとの偏り

What Ifツール

What Ifツールでは、ユーザー、対象アプリ、端末プラットフォーム、クライアント、場所、リスクなどを指定して、適用されるポリシーをシミュレーションできます。

ただし、What Ifだけで本番化を判断してはいけません。サービス依存関係や実際の通信経路が再現されないためです。What Ifは例外的な条件を確認する補助ツール、サインインログは実際の利用状況を確認する主な証拠として使い分けます。(Microsoft Learn)

次の段階へ進む判断基準

少なくとも次の条件を満たしてから、パイロットでOnにします。

確認項目	判断基準
緊急アクセス	2アカウントともサインインと管理操作を確認済み
MFA	パイロット対象者が利用可能な認証方法を登録済み
管理者	管理ポータル、PowerShell、CLIへの影響を確認済み
アプリ	主要なクラウドアプリと依存リソースを確認済み
端末	Windows、macOS、iOS、Androidなど利用端末を確認済み
自動処理	バッチ、スクリプト、サービスアカウントへの影響を確認済み
サポート	問い合わせ窓口と復旧手順を準備済み
ロールバック	ポリシー無効化とグループ除外の担当者を決定済み

検証期間は一律の日数ではなく、通常業務のサイクルを一巡できる長さにします。月末処理や給与処理など、特定時期にしか使われないシステムがある場合は、その業務まで確認してから全社展開します。

report-only特有の注意点

report-onlyでは制御が強制されませんが、完全にユーザーへ影響しないとは限りません。

Microsoftは、準拠端末を要求するreport-onlyポリシーにより、macOS、iOS、Androidで端末証明書の選択を求められる場合があると案内しています。端末準拠の強制は行われなくても、証明書選択画面が繰り返し表示される可能性があります。(Microsoft Learn)

モバイルやmacOSの利用者が多い場合は、次のいずれかで検証します。

最初はWindowsのみを対象にする
端末プラットフォームごとにreport-onlyポリシーを分ける
小規模な端末検証グループを作る
証明書プロンプトが発生しないか実機で確認する

「report-onlyだから利用者影響はゼロ」と決めつけないことが重要です。

パイロット展開では観測用と強制用を分ける

全ユーザーを対象としたreport-onlyポリシーを、そのままOnへ変更するのは避けます。

次の二層構成にすると安全です。

全ユーザーを対象にした観測用ポリシーをreport-onlyで維持する
パイロットグループだけを対象にした強制用ポリシーを別に作成する

たとえば、次のように分けます。

ポリシー	対象	状態
`CA-OBS-RISK-SIGNIN-MEDHIGH`	全ユーザー	Report-only
`CA-ENF-RISK-SIGNIN-PILOT`	パイロットグループ	On
`CA-OBS-RISK-USER-HIGH`	全ユーザー	Report-only
`CA-ENF-RISK-USER-PILOT`	パイロットグループ	On

パイロットには、IT部門だけでなく、次のような利用者を含めます。

一般的な事務ユーザー
管理者
モバイル利用者
在宅勤務者
拠点勤務者
macOS利用者
社内業務アプリの利用者
PowerShellやCLIを利用する担当者

IT担当者だけで検証すると、一般ユーザー固有の端末、認証、アプリ依存関係を見逃しやすくなります。

Microsoft Entra Private Accessを段階展開する

Conditional Accessの基礎が安定したら、Microsoft Entra Private AccessでオンプレミスやプライベートクラウドへのZero Trustを進めます。

Private Accessは、VPNのようにネットワーク全体へ接続させるのではなく、FQDN、IPアドレス、ポートなどで定義したプライベートリソースへのアクセスを制御できます。(Microsoft Learn)

Private Network Connectorを冗長化する

Private Accessでは、内部リソースへ到達できるネットワーク上にPrivate Network Connectorを配置します。

本番環境では、一つのコネクタグループに少なくとも2台のコネクタを配置します。同一グループ内のコネクタは、高可用性と負荷分散の単位として動作します。(Microsoft Learn)

可能であれば、次の点も分散します。

別々のWindows Server
異なる仮想化ホスト
異なる障害ドメイン
異なるインターネット出口
アプリに近いネットワーク配置

コネクタが正常でも、DNS解決や内部ルーティング、ファイアウォールポートが不足していると接続できません。対象アプリごとに、FQDN、IP、TCPまたはUDPポート、名前解決経路を確認します。

Private Accessの推奨展開順序

Microsoftは、Quick Accessからアプリ単位のセグメント化へ進む段階的な考え方を示しています。(Microsoft Learn)

段階	実施内容
接続準備	コネクタ、DNS、対象リソースを構成する
小規模検証	影響の小さいアプリをパイロット公開する
VPN移行	必要に応じてQuick Accessで既存VPN相当の範囲を提供する
利用状況の発見	Application Discoveryで実際の通信を分析する
アプリ単位の分割	重要アプリを個別のエンタープライズアプリとして登録する
最小権限化	必要なユーザーとグループだけを割り当てる
Conditional Access適用	MFA、認証強度、準拠端末などを要求する
VPN縮小	検証済みの対象からVPN経路を廃止する

Quick AccessはVPNから移行しやすい反面、広いIP範囲やワイルドカードFQDNを設定すると、従来のVPNに近い広範な接続になります。

そのため、Quick Accessを最終形とせず、一時的な移行手段として扱います。利用状況を確認した後、重要システムからper-app accessへ分割し、ユーザーごとの最小権限へ移行します。

クライアントを先に配布し、通信転送は後から割り当てる

Global Secure Access Clientを配布した直後から、全ユーザーのPrivate Access通信を転送する構成は避けます。

安全な順序は次のとおりです。

パイロット端末へクライアントを配布する
まだPrivate Accessプロファイルを割り当てない
クライアントの正常性とサインイン状態を確認する
Private Accessをパイロットグループだけに割り当てる
対象アプリ、DNS、Kerberos、RDP、SSHなどを確認する
問題があればプロファイル割り当てを解除する
部署単位で対象を拡大する

Traffic forwarding profileは、ユーザーやグループ単位で割り当てられます。Microsoft Learnでは、プロファイルが過去に有効化されている場合と、新しく有効化する場合で初期の割当状態が異なることが示されています。切り替える前に、必ずUser and group assignmentsの実際の表示を確認してください。(Microsoft Learn)

既存VPNはすぐに廃止しない

Private Accessのパイロット中は、復旧経路として既存VPNを維持します。

次の項目を確認してから、対象システムごとにVPNを縮小します。

通常時の接続
多要素認証
パスワード変更後の接続
端末再起動後の接続
社外ネットワークからの接続
DNSサフィックスと名前解決
Kerberos SSO
RDP、SSH、SMBなどの非Web通信
コネクタ1台停止時のフェイルオーバー
Conditional Accessで拒否された場合の表示
障害時のロールバック

DirectAccessを利用している端末では、Private AccessとのトンネルやNRPTルールの競合が文書化されています。同一端末での共存を前提とせず、パイロット端末からDirectAccessを削除した後にPrivate Accessを有効化します。(Microsoft Learn)

Microsoft Entra Internet Accessを段階展開する

Private Accessが社内リソースへのアクセスを対象とするのに対し、Microsoft Entra Internet Accessは、SaaS、生成AI、一般Webサイトなどのインターネット通信を対象にします。

Internet Accessプロファイルを割り当てると、対象端末のインターネット通信がGlobal Secure Access ClientからMicrosoftのSecurity Service Edgeへ転送され、設定したセキュリティポリシーが適用されます。(Microsoft Learn)

Internet Accessの展開手順

利用するライセンスと管理ロールを確認する
パイロットグループを作成する
Global Secure Access Clientをパイロット端末へ配布する
Internet Accessプロファイルの割当対象を確認する
Webコンテンツフィルタリングポリシーを作成する
セキュリティプロファイルを作成する
セキュリティプロファイルをConditional Accessへ関連付ける
Internet Accessプロファイルをパイロットグループへ割り当てる
ブラウザー、Office、業務アプリ、更新処理などを検証する
部署単位で対象を拡大する

Webコンテンツフィルタリングでは、通信転送、フィルターポリシー、セキュリティプロファイル、Conditional Access、ユーザー割り当てを組み合わせて構成します。(Microsoft Learn)

AIサービスは利用目的ごとに分ける

生成AIを一律に許可または禁止するだけでは、業務利用の実態に合わないことがあります。

棚卸しでは、少なくとも次の分類を行います。

分類	例	主な判断
承認済みAI	会社契約済みの生成AI	認証、データ保護、利用部署を確認
未承認AI	個人契約や未審査サービス	アップロード制限やブロックを検討
AI搭載SaaS	Officeアドイン、開発ツール	通常のWeb以外の通信経路も確認
API利用	アプリやスクリプトからのAI API	ユーザー通信とワークロード通信を分離
外部MCPなど	外部ツールや連携サーバー	接続先、権限、データ送信範囲を確認

ブラウザーからのアクセスだけを検証しても、Officeアドイン、デスクトップアプリ、API、バックグラウンド通信を見落とす可能性があります。端末やアプリごとの通信ログを確認し、許可経路を明確にします。

TLS検査で動かなくなるアプリを確認する

Internet AccessでTLS検査を利用する場合、証明書ピンニングを使用するアプリや、独自の証明書検証を行うクライアントが正常に通信できなくなることがあります。

パイロットでは、次の処理を確認してください。

OSやアプリの更新
銀行、決済、電子申請などの業務サイト
開発ツールのパッケージ取得
バックアップソフト
セキュリティ製品の更新
VPNやリモートサポートツール
モバイルアプリ
APIクライアント
証明書ピンニングを使用するSaaS

障害が発生した場合は、単にInternet Access全体を無効化するのではなく、対象通信の仕様を確認し、必要なバイパスを限定的に設定します。Microsoftの運用ガイダンスでも、TLS検査の失敗増加時には証明書ピンニングの変更やバイパス一覧を確認するよう案内されています。(Microsoft Learn)

report-onlyと通信転送のパイロットは別物

Zero Trust導入で見落としやすいのが、Conditional Accessのreport-onlyと、Global Secure Accessのtraffic forwarding profileは別の制御だという点です。

report-onlyにすれば、Conditional AccessによるMFA要求やブロックは強制されません。しかし、Private AccessやInternet Accessのプロファイルをユーザーへ割り当てると、通信経路そのものは変更されます。(Microsoft Learn)

つまり、次のような障害はreport-onlyでは防げません。

DNSを解決できない
コネクタから内部アプリへ到達できない
通信ポートが不足している
他のVPNやSSEクライアントと競合する
TLS検査でアプリが失敗する
誤ったFQDNやIP範囲が取得される
インターネット通信の遅延が増える

そのため、安全対策は二重に行います。

Conditional Accessはreport-onlyで検証する
Traffic forwarding profileはパイロットグループだけに割り当てる

どちらか一方だけでは、ロックアウトや通信障害を十分に防げません。

サービスアカウントを安易に除外しない

Conditional Accessの計画では、サービスアカウントや自動処理を必ず確認します。

ユーザーとしてサインインする古いサービスアカウントは、MFAを実行できないため、Conditional Accessの強制で停止する可能性があります。一方、サービスプリンシパルの呼び出しは、通常のユーザー対象Conditional Accessでは制御されません。

Microsoftは、スクリプトやコードでユーザー型サービスアカウントを使用している場合、可能なものはマネージドIDへ置き換え、サービスプリンシパルにはworkload identities向けConditional Accessを利用するよう案内しています。(Microsoft Learn)

一時的に除外する場合は、次の情報を残します。

除外理由
システム所有者
利用している認証方式
移行先の認証方式
移行期限
除外の再確認日
障害時の連絡先

「止まると困るから永久除外」ではなく、例外を技術的負債として管理することが重要です。

必要なライセンスを確認する

主なライセンス要件は次のとおりです。契約形態や機能提供条件は変更される可能性があるため、導入時点のMicrosoft製品条項と管理センターの表示も確認してください。(Microsoft Learn)

機能	主なライセンス要件
基本的なConditional Access	Microsoft Entra ID P1またはP2
user risk、sign-in risk	Microsoft Entra ID P2
Conditional Access Insightsワークブック	Entra ID P1以上、Log Analyticsワークスペース
Microsoft Entra Private Access	Entra Suiteまたは単体ライセンスに加え、Entra ID P1またはP2
Microsoft Entra Internet Access	Entra Suiteまたは単体ライセンスに加え、Entra ID P1またはP2
Internet Access for Microsoft services	Entra ID P1またはP2に含まれる範囲あり
端末準拠条件	対象ユーザーのIntuneライセンスなど
Workload identities向けConditional Access	Microsoft Entra Workload ID Premium

ライセンスの保有数だけでなく、ポリシー対象となるユーザー全員に必要なライセンスが割り当てられているか確認します。

アプリごとに確認すべき制約

Zero Trustポリシーを全社展開する前に、アプリごとの制約を確認します。

確認対象	主な注意点
MFA未登録ユーザー	リスクのあるセッションではMFA登録できない場合がある
ハイブリッドユーザー	user risk修復にパスワードハッシュ同期などが必要
レガシ認証	MFAや最新のConditional Access制御に対応しない
Teamsなど複合サービス	ExchangeやSharePointなど依存リソースがある
RDP、SSH、SMB	FQDN、IP、ポート、DNS、認証方式を確認する
Kerberosアプリ	ドメインコントローラー、SPN、チケット取得経路を確認する
サービスプリンシパル	ユーザー向けポリシーではなくWorkload IDを検討する
ゲスト、委託先	認証方法、端末管理、テナント切り替えを確認する
証明書ピンニング	TLS検査で通信に失敗する可能性がある
VPN、DirectAccess	ルート、DNS、NRPT、トンネルの競合を確認する
BYOD	準拠端末を要求できるか、代替制御が必要か確認する
モバイル端末	report-onlyでも証明書プロンプトが出る場合がある

「Microsoft 365が使えたから問題ない」ではなく、対象アプリ、利用端末、認証方式、通信経路の組み合わせごとに検証します。

失敗しやすい設定と回避策

失敗例	起きる問題	回避策
全ユーザー・全リソース・BlockをすぐOnにする	管理者を含めてロックアウトする	report-only、緊急アカウント除外、パイロット展開を行う
report-onlyの全体観測ポリシーをそのままOnにする	一度に全社へ強制される	パイロット用の強制ポリシーを別作成する
既存のOnポリシーをreport-onlyへ変更する	現在の保護が停止する	コピーをreport-onlyで作成する
User action requiredを障害と判断する	MFA対象者を誤って除外する	実際に必要となるユーザー操作として評価する
What Ifだけで本番化する	サービス依存関係を見逃す	実際のサインインログとアプリテストを併用する
緊急アカウントを1つだけ作る	資格情報や端末の故障時に復旧できない	独立したアカウントを少なくとも2つ用意する
サービスアカウントを一括除外する	恒久的な認証の弱点が残る	マネージドIDやWorkload IDへ移行する
GSAプロファイルを全ユーザーへ割り当てる	DNSや通信経路の不具合が全社へ波及する	パイロットグループから割り当てる
Quick Accessを最終構成にする	広すぎるネットワークアクセスが残る	Application Discovery後にper-appへ分割する
Private Access導入直後にVPNを廃止する	障害時の代替経路がなくなる	アプリ単位で検証後に縮小する
TLS検査を一括適用する	証明書ピンニング対応アプリが停止する	実機検証し、必要な通信だけを限定的に除外する

特に「All users」と「All resources」を組み合わせたブロックポリシーは慎重に扱います。Microsoftも、管理者のロックアウトにつながる可能性があるとして注意を促しています。(Microsoft Learn)

実務で使える段階導入ランブック

フェーズ	実施内容	次へ進む条件	ロールバック
準備	アクセス棚卸し、ライセンス確認、担当者決定	対象と影響範囲が明確	ポリシーを作成しない
復旧経路	緊急アクセスアカウントを2つ作成	サインインと管理操作に成功	通常管理者設定を見直す
全体観測	riskポリシーをreport-onlyで作成	想定外のFailureを把握	ポリシーをOffにする
パイロット強制	限定グループにriskポリシーをOn	問い合わせと失敗を解消	パイロットポリシーをOffまたは割当解除
Private Access検証	コネクタ、クライアント、限定アプリを展開	DNS、認証、フェイルオーバー成功	プロファイル割当解除、VPNへ戻す
Private Access拡大	部署単位で対象を追加	主要アプリをper-app化	対象グループを前段階へ戻す
Internet Access検証	Web、SaaS、AI通信をパイロット転送	業務アプリとTLS検査を確認	Internet Access割当解除
全社展開	グループ単位で段階的に拡大	監視とサポート体制が安定	直前の展開グループを解除
旧経路縮小	VPNや旧ポリシーを段階廃止	代替経路が検証済み	一時的に旧経路を再有効化

各変更では、実施者、承認者、開始時刻、対象グループ、変更前設定、ロールバック手順を記録します。障害が起きてから復旧方法を考えるのではなく、変更作業の一部として復旧手順を用意してください。

まとめ

Microsoft EntraでZero Trustをロックアウトせず導入するには、Conditional Accessの設定だけでなく、ID、端末、アプリ、ネットワーク経路を一つの変更計画として扱う必要があります。

最初に実施すべきことは、次の4点です。

AI、SaaS、オンプレミス、インターネットを含むアクセス面を棚卸しする
独立した緊急アクセスアカウントを少なくとも2つ用意する
user riskとsign-in riskを別ポリシーとしてreport-onlyで作成する
全体観測用とパイロット強制用のポリシーを分ける

Conditional Accessが安定した後は、Private Accessを限定アプリから展開し、続いてInternet AccessでSaaSやAI、Web通信へ制御を広げます。

ただし、report-onlyで防げるのはConditional Accessによる強制だけです。Global Secure Accessによる通信経路の変更は別途パイロットグループで検証し、VPNや既存経路を復旧手段として残したまま進めることが、安全な段階導入の要点です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。