Microsoft Entra Private Access のドメインコントローラー対応が重要なのは、オンプレミス Active Directory に残る Kerberos 認証ベースの業務システムにも、条件付きアクセスや MFA を適用しやすくなるためです。従来の VPN や社内ネットワーク前提の設計では、「社内にいる＝信頼できる」という暗黙の前提が残りがちでした。今回の更新は、その前提を崩し、ハイブリッド環境の中核であるドメインコントローラーをゼロトラスト設計に組み込むための大きな一歩です。
2026年4月16日時点で確認できる Microsoft Entra の更新情報では、Global Secure Access の新リリースとして「Entra Private Access for Domain Controllers」が掲載されています。Microsoft 公式ドキュメントでは、Active Directory ドメインコントローラーに対して Microsoft Entra Private Access を構成し、Kerberos 認証を使うオンプレミスアプリケーションに条件付きアクセスや MFA を適用する流れが説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Entra Private Access のドメインコントローラー対応で何が変わるのか
Microsoft Entra Private Access は、社内アプリケーションやプライベートリソースへのアクセスを、VPN 中心ではなく ID 中心で制御するための ZTNA、つまり Zero Trust Network Access の仕組みです。FQDN や IP アドレスで社内リソースを定義し、Global Secure Access クライアントとプライベートネットワークコネクタを通じて、ユーザーやデバイスの状態に応じたアクセス制御を行います。(Microsoft Learn)
今回注目すべき点は、制御対象が単なる社内 Web アプリやサーバー接続にとどまらず、Active Directory ドメインコントローラーを経由する Kerberos 認証にまで広がったことです。Microsoft の発表では、ドメインコントローラー上に軽量な Private Access Sensor を導入し、Kerberos 認証をインターセプトして条件付きアクセスを適用できると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
これにより、たとえば次のようなオンプレミス資産にも、従来より細かいアクセス制御を設計しやすくなります。
- ファイルサーバーの共有フォルダー
- SQL Server などの業務データベース
- RDP で接続する管理用サーバー
- Kerberos 認証を前提とするレガシー業務アプリ
- 拠点内から利用される社内システム
従来は「VPN に接続できたユーザー」や「社内ネットワークにいる端末」に広めのアクセス権を与え、その後はファイアウォール、VLAN、ACL、AD 権限で守る設計が一般的でした。しかし、攻撃者が一度社内ネットワークや端末を侵害すると、横展開の余地が残ります。ドメインコントローラー対応の価値は、ネットワーク到達性だけでなく、認証要求そのものにポリシー評価を差し込める点にあります。
なぜドメインコントローラーの保護がゼロトラスト設計で重要なのか
ゼロトラストの基本は「明示的に検証する」「最小権限を使う」「侵害を前提にする」です。Microsoft は Global Secure Access を、Microsoft Entra Internet Access と Microsoft Entra Private Access を含む SSE、Security Service Edge の統合的な管理領域として説明しており、ゼロトラストの原則に基づくアクセス制御を提供するとしています。(Microsoft Learn)
その中でもドメインコントローラーは、ハイブリッド企業にとって特別な位置づけです。Active Directory は今も多くの企業でユーザー認証、グループ管理、ファイル共有、業務アプリ認証の土台です。クラウド移行が進んでも、オンプレミス AD をすぐに廃止できない企業は少なくありません。
問題は、オンプレミス AD が残る限り、ゼロトラストが「クラウドアプリだけの話」になりやすいことです。Microsoft 365 や SaaS には条件付きアクセスを適用できても、社内 LAN 上のファイル共有や Kerberos ベースの古いアプリには、同じ粒度の制御を適用しづらい場面があります。
ドメインコントローラー対応により、次のような設計変更が現実的になります。
| 従来の設計で残りやすい課題 | ドメインコントローラー対応で狙える改善 |
|---|---|
| VPN 接続後に広い社内ネットワークへ到達できる | アプリや SPN 単位でアクセス制御を細分化しやすい |
| 社内 LAN からのアクセスを信頼しすぎる | 社内・社外を問わず認証要求を検証する設計に近づける |
| レガシーアプリに MFA を適用しづらい | Kerberos 認証を使うオンプレミスアプリにも条件付きアクセスを適用しやすい |
| 横展開対策がネットワーク分離に偏る | ID、デバイス、リスク、認証の文脈を組み合わせて制御できる |
| 拠点・リモート・クラウドでポリシーが分断される | Microsoft Entra 管理センターを中心に統一的な運用へ寄せられる |
ゼロトラストアーキテクトにとって重要なのは、「VPN を置き換えるかどうか」だけではありません。オンプレミス AD を含む認証経路全体を、どこまで ID 中心に再設計できるかです。
仕組みを簡単に理解する：Kerberos 認証に条件付きアクセスを挟む
Microsoft Entra Private Access for Domain Controllers の考え方は、アプリ通信そのものをすべてクラウドに迂回させるというより、Kerberos 認証のタイミングで Entra のポリシー評価を活用する点にあります。Microsoft の説明では、オンプレミスユーザーのアプリケーショントラフィックはローカルに保ちつつ、認証トラフィックを Entra に送ってポリシー評価を行う構成が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
大まかな流れは次のとおりです。
| 構成要素 | 役割 |
|---|---|
| Global Secure Access クライアント | Windows 端末側で Private Access の通信を扱うクライアント |
| Private Network Connector | Entra クラウドサービスと社内リソースの間を仲介するコネクタ |
| Private Access Sensor | ドメインコントローラー上で Kerberos 認証要求を扱う軽量センサー |
| SPN | cifs/*、MSSQL/* など、保護対象サービスを識別する名前 |
| 条件付きアクセス | MFA、準拠デバイス、フィッシング耐性のある認証などを要求するポリシー |
たとえば、ファイル共有を保護したい場合は cifs/*、SQL Server を対象にしたい場合は MSSQL/* のように、SPN レベルで制御対象を考えます。Microsoft の発表でも、ファイル共有への MFA、SQL Server への準拠デバイス要件、機密 RDP サーバーへのステップアップ認証といった例が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
ネットワーク管理者にとっては、ここが設計上の分岐点です。サブネット単位で大きく通すのではなく、「どのサービスに、誰が、どの端末状態で、どの認証強度ならアクセスできるか」を SPN 単位で考える必要があります。
VPN 置き換えではなく「認証境界の再設計」として考える
Microsoft Entra Private Access は VPN 置き換えの文脈で語られることが多く、Microsoft Learn でも VPN を使わずにプライベートアプリへアクセスできる点や、Quick Access と per-app access による制御が説明されています。(Microsoft Learn)
ただし、ドメインコントローラー対応を単純な VPN 代替として見ると、価値を見誤ります。重要なのは、ネットワーク境界から認証境界へ軸足を移すことです。
従来型 VPN では、接続が成功すると「社内ネットワークに入った」状態になります。その後の制御は、ファイアウォールルール、ルーティング、AD グループ、サーバー側権限に依存します。もちろんこれらは今後も必要ですが、侵害済み端末や盗まれた資格情報を前提にすると、VPN 接続の成功だけでは十分とは言えません。
一方、ドメインコントローラー対応の Private Access では、Kerberos 認証を使うリソースへのアクセス時に、ユーザー、端末、認証強度、条件付きアクセスを組み合わせて評価できます。つまり、「社内に入れたか」ではなく、「このリソースに今アクセスさせてよいか」を都度判断する設計に近づきます。
導入効果が大きい企業の特徴
すべての環境で一斉導入すべきという話ではありません。効果が大きいのは、次のような企業です。
| 企業・環境の特徴 | 期待できる効果 |
|---|---|
| Active Directory と Microsoft Entra ID を併用している | クラウドとオンプレミスのアクセス制御を統一しやすい |
| ファイル共有、RDP、SQL Server など Kerberos 依存の資産が多い | レガシー資産にも MFA やデバイス条件を適用しやすい |
| VPN 利用者が多く、接続後の到達範囲が広い | VPN 後の横展開リスクを下げる設計に移行しやすい |
| 拠点、リモート、データセンター、クラウドが混在している | 場所に依存しないポリシー設計を進めやすい |
| ゼロトラストを Microsoft Entra 中心で進めている | 条件付きアクセス、ID 保護、端末準拠性と連携しやすい |
特にグローバル企業では、国や拠点ごとに VPN、AD サイト、ファイアウォール、運用ルールが分かれがちです。ドメインコントローラーを保護対象に含めることで、各拠点のネットワーク事情に左右されすぎない共通ポリシーを作りやすくなります。
設計時に最初に決めるべきこと
ドメインコントローラー対応を検討する際は、いきなりセンサーを展開するのではなく、保護対象と例外を先に決めるべきです。特に SPN 設計は、セキュリティ効果と業務影響を左右します。
どのリソースを最初に保護するか
最初からすべての Kerberos 認証を厳しく制御しようとすると、業務影響の切り分けが難しくなります。初期フェーズでは、次のような対象から始めると現実的です。
| 優先度 | 対象例 | 理由 |
|---|---|---|
| 高 | 管理者向け RDP、踏み台サーバー、重要ファイル共有 | 侵害時の影響が大きく、追加認証の合理性を説明しやすい |
| 中 | 部門別ファイルサーバー、業務データベース | 利用者を限定しやすく、段階展開に向く |
| 低 | 全社共通の古い業務アプリ、認証方式が不明なシステム | 影響範囲が読みづらく、事前調査が必要 |
最初の PoC では、「全社ファイル共有すべて」ではなく「特定部門の機密共有」や「管理者向け RDP」など、効果と影響を説明しやすい対象を選ぶのが安全です。
SPN の粒度をどうするか
SPN はワイルドカードで広く指定できますが、広すぎる指定は想定外の業務影響につながります。Microsoft の構成ガイドでも、SPN は完全一致または <serviceclass>/* のようなワイルドカード形式で扱えると説明されています。(Microsoft Learn)
たとえば cifs/* はファイル共有保護として分かりやすい一方、対象が広くなりやすい指定です。PoC では、重要サーバーや特定用途に絞った設計から始め、監査ログを見ながら広げる方が失敗しにくくなります。
社内ユーザーにも適用するか
ゼロトラスト設計では、社内 LAN からのアクセスも無条件に信頼しません。Microsoft の発表でも、オンサイトユーザーを含めた制御が強調されています。(TECHCOMMUNITY.MICROSOFT.COM)
ただし、社内ユーザーに MFA を頻繁に要求すると、ヘルプデスク問い合わせや業務停止につながる可能性があります。最初は「管理者」「高リスクアプリ」「機密データ」などに限定し、通常業務のファイルアクセスには準拠デバイス要件を中心にするなど、認証強度と業務負荷のバランスを取る必要があります。
構成の全体像と導入手順
Microsoft Learn の構成ガイドでは、Private Network Connector の導入、Quick Access または Enterprise Application によるドメインコントローラー公開、ユーザー割り当て、条件付きアクセス、Private Access Profile、有効化、Global Secure Access クライアント、Private Access Sensor の導入などが手順として示されています。(Microsoft Learn)
実務では、次の順序で進めると整理しやすくなります。
| フェーズ | 作業 | 判断ポイント |
|---|---|---|
| 現状把握 | DC、AD サイト、Kerberos 依存アプリ、SPN、VPN 経路を棚卸し | どの DC がどの拠点・アプリの認証を処理しているか確認する |
| PoC 設計 | 対象ユーザー、対象 SPN、対象 DC、条件付きアクセスを限定 | 影響範囲を説明できる小さな単位で始める |
| 基盤準備 | Private Network Connector、Global Secure Access クライアント、Private Access Profile を準備 | 既存 VPN やプロキシとの共存を確認する |
| センサー導入 | 対象 DC に Private Access Sensor を導入 | 監査モードから始め、ログで影響を確認する |
| ポリシー設計 | MFA、準拠デバイス、フィッシング耐性認証などを設定 | 管理者と一般ユーザーで要件を分ける |
| 検証 | klist、SMB アクセス、RDP、イベントログで確認 | 期待通りにブロック・許可・MFA 要求されるか確認する |
| 段階展開 | 拠点、DC、SPN、ユーザー範囲を拡大 | 例外とブレークグラス手順を維持する |
構成ガイドでは、ドメインコントローラー側で TCP 1337 の受信許可、*.msappproxy.net:443 への送信許可、最新の Private Network Connector、Private Access Sensor の導入などが前提条件として示されています。実際の本番設計では、これらの通信要件をファイアウォール、プロキシ、EDR、サーバー運用ルールと照合してから進めるべきです。(Microsoft Learn)
条件付きアクセス設計の実例
Microsoft Learn では、Private Access アプリに対して条件付きアクセスを適用し、MFA、準拠デバイス、Microsoft Entra ハイブリッド参加済みデバイスなどを要求する例が示されています。また、緊急アクセス用の break-glass アカウントを除外する重要性も説明されています。(Microsoft Learn)
実務では、次のようにリスク別にポリシーを分けると運用しやすくなります。
| 対象 | 推奨される制御例 | 注意点 |
|---|---|---|
| 管理者向け RDP | フィッシング耐性 MFA、準拠デバイス、管理者グループ限定 | 誤設定時のロックアウト対策を必ず用意する |
| 重要ファイル共有 | MFA または準拠デバイス、社外アクセス時の追加制御 | ファイルサーバー利用者の業務時間帯に検証する |
| SQL Server | 利用部門グループ、準拠デバイス、特定拠点条件 | サービスアカウントやバッチ処理の影響を確認する |
| 一般的な社内アプリ | まずは監査モード、段階的に要件追加 | 古いクライアントや NTLM 依存を洗い出す |
ポイントは、全員に常時 MFA を求めることではありません。ゼロトラストでは、リスクが高い操作やリソースに対して追加検証を行い、通常業務は可能な限り自然に通す設計が重要です。
失敗しやすいポイントと回避策
NTLM 依存を見落とす
構成ガイドでは、環境内で NTLM v1/v2 を使っている場合、NTLM の制限や Kerberos 利用を検討する必要がある一方、影響評価なしに NTLM 認証を制限するとサービス停止につながる可能性があると注意されています。(Microsoft Learn)
古い複合機、業務アプリ、バッチ、NAS、スクリプトは NTLM に依存していることがあります。Kerberos 前提で設計したつもりでも、一部のアクセスだけ NTLM に落ちているケースは珍しくありません。導入前に認証ログを確認し、NTLM 利用状況を棚卸ししてください。
DC の一部だけにセンサーを入れて安心する
PoC では一部の DC だけに Private Access Sensor を入れる構成も考えられます。ただし、実際の端末がどの DC に Kerberos チケットを要求するかは、AD サイト、DNS、ネットワーク経路、キャッシュ状態に影響されます。
特定の DC だけで検証する場合は、テスト端末がその DC を利用していることを nltest や klist などで確認しながら進める必要があります。複数拠点に展開する場合は、AD サイト設計とセンサー配置をセットで見直すべきです。
SPN ワイルドカードを広げすぎる
cifs/* のような指定は便利ですが、対象が広がります。いきなり Enforce にすると、想定外のファイル共有や業務ツールに影響する可能性があります。
最初は監査モードで実際のアクセス状況を確認し、対象サーバー、対象ユーザー、例外を明確にしてから強制適用に移行するのが安全です。Microsoft の構成ガイドでも、Private Access Sensor は既定で Audit モードで導入され、EnforceMode への変更は段階的に行う流れが示されています。(Microsoft Learn)
例外設計が後回しになる
セキュリティ設計では例外を嫌いがちですが、ドメインコントローラーや認証基盤では、例外設計が可用性を守ります。Microsoft の構成ガイドでは、Global Secure Access クライアントを持たないユーザーや端末に対して、SPN ごとに IP アドレス、IP 範囲、UPN などで除外や包含を設定できることが説明されています。(Microsoft Learn)
例外は「抜け道」ではなく、段階導入と業務継続のための制御点です。ただし、例外が増えすぎるとゼロトラストの効果が薄れるため、期限、所有者、理由、見直し日を記録して管理してください。
ブレークグラス手順を用意しない
ドメインコントローラー周辺の制御は、誤ると管理者自身が復旧操作をできなくなる可能性があります。Microsoft の資料では、緊急時にすべてのトラフィックを許可する break glass mode や、条件付きアクセスで緊急アクセスアカウントを除外する考え方が説明されています。(Microsoft Learn)
本番適用前に、少なくとも次の項目を文書化しておきます。
| 項目 | 確認内容 |
|---|---|
| 緊急アクセスアカウント | MFA 障害やポリシー誤設定時に使えるか |
| センサー停止手順 | 誰が、どのサーバーで、どの条件で実施するか |
| break glass mode | 有効化方法、承認者、ログ記録の方法 |
| ロールバック条件 | どのエラー件数・業務影響で戻すか |
| 連絡経路 | ID チーム、ネットワークチーム、SOC、ヘルプデスクの連携 |
ゼロトラストアーキテクトが見るべき設計観点
ドメインコントローラー対応をセキュリティ機能の追加として見るだけでは不十分です。アーキテクチャ全体では、次の観点で評価する必要があります。
ID とネットワークの責任境界を再定義する
従来、AD チームは認証、ネットワークチームは VPN とファイアウォール、セキュリティチームは MFA とログ監視を担当することが多くありました。Microsoft Entra Private Access のような SSE/ZTNA 型の仕組みでは、この境界が重なります。
SPN 設計は AD の知識が必要です。Private Network Connector や通信経路はネットワークの知識が必要です。条件付きアクセスやデバイス準拠性は ID・エンドポイント管理の知識が必要です。成功させるには、単一チームの施策ではなく、共同設計のテーマとして扱う必要があります。
拠点内アクセスも「信頼済み」と決めつけない
オンプレミス勤務のユーザーは、物理的に社内にいるため信頼しやすいと考えられがちです。しかし、侵害済み端末、盗まれた認証情報、内部不正、ゲスト端末の接続を考えると、場所だけで安全とは言えません。
ドメインコントローラー対応は、社内 LAN 上の Kerberos 認証にも条件付きアクセスを適用する考え方を後押しします。これにより、「社外からのアクセスだけを厳しくする」段階から、「重要リソースへのアクセスは場所に関係なく検証する」段階へ進めます。
ログと検知の設計を同時に行う
Microsoft の発表では、この機能がハイブリッドユーザー向けの ITDR、Identity Threat Detection and Response の機会にもなると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
ただし、検知に活かすにはログ設計が必要です。誰が、どの端末から、どの SPN に、どの条件付きアクセス結果でアクセスしたのかを、SOC や運用チームが追えるようにする必要があります。導入時はブロック可否だけでなく、監査ログ、イベントログ、条件付きアクセスの結果、ヘルプデスク問い合わせを合わせて見る体制を作ってください。
ネットワーク管理者が確認すべきチェックリスト
導入前の確認項目を、ネットワーク管理者向けに整理すると次のようになります。
| チェック項目 | 確認内容 |
|---|---|
| DC への通信 | TCP 1337 の受信許可が必要な DC を把握しているか |
| 外向き通信 | *.msappproxy.net:443 への送信がプロキシや FW で許可されるか |
| Connector 配置 | DC と保護対象リソースに到達できる場所に配置されているか |
| クライアント展開 | 対象端末に Global Secure Access クライアントを配布できるか |
| 既存 VPN との共存 | ルーティング、DNS、プロキシ、EDR と競合しないか |
| AD サイト | テスト端末が想定した DC を利用するか |
| 例外経路 | 未管理端末、サービスアカウント、緊急運用端末の扱いを決めたか |
| ログ取得 | Sensor、Client、Entra 側ログを確認できる担当者がいるか |
ネットワーク観点では、「通信を通す」だけでなく、「どの通信を Private Access に載せ、どの通信をローカルに残し、どの通信を例外にするか」を整理することが重要です。
まず何から始めるべきか
最初の一歩は、製品設定ではなく棚卸しです。次の順番で進めると、PoC から本番展開までの失敗を減らせます。
- 重要な Kerberos 依存リソースを 10 個程度リスト化する
- それぞれの SPN、利用ユーザー、利用端末、拠点、業務影響を確認する
- 管理者向け RDP または重要ファイル共有など、影響範囲が限定できる対象を PoC に選ぶ
- 監査モードで実際の認証要求を確認する
- 条件付きアクセスを Report-only で検証する
- 除外・ブレークグラス・ロールバック手順を整えてから Enforce に移行する
この進め方なら、ゼロトラストの理想論だけでなく、現場運用に耐える形でドメインコントローラー保護を導入できます。
まとめ：DC 対応はハイブリッドゼロトラストの抜け穴を埋める更新
Microsoft Entra Private Access のドメインコントローラー対応は、単なる新機能ではありません。クラウドアプリには条件付きアクセスを適用している一方で、オンプレミス AD と Kerberos 認証には従来型の信頼モデルが残っている企業にとって、ハイブリッドゼロトラストの抜け穴を埋める更新です。
特に重要なのは、次の3点です。
- Kerberos 認証を使うオンプレミスリソースにも、条件付きアクセスや MFA を適用しやすくなる
- 社内・社外を問わず、ドメイン認証リソースへのアクセスを ID 中心で検証できる
- SPN、監査モード、除外、ブレークグラスを使い、段階的に導入できる
ゼロトラストアーキテクトは、クラウドアプリだけでなく、Active Directory、VPN、RDP、ファイル共有、業務データベースを含めた認証境界を見直すべきです。ネットワーク管理者は、DC、Connector、クライアント、ファイアウォール、既存 VPN の関係を棚卸しし、まずは限定された SPN とユーザー範囲で検証を始めるのが現実的です。
コメント