非永続・プール型の Azure Virtual Desktop（AVD）で Windows 11 Enterprise multi‑session を利用すると、Microsoft Defender for Endpoint（MDE）の「初回オンボーディングに約 3〜4 時間遅延」との記述が気になります。本稿では、その“遅延”が意味するものを正しく解像し、実運用でセキュリティ ギャップを生まないための実装手順・検証方法・ベストプラクティスを、現場でそのまま使える形で整理します。
非永続型 AVD と MDE の前提をそろえる
まず用語と前提を確認します。ここでいう「非永続型」は、セッションホストが再起動・再作成のたびに初期化される（差分が残らない）形態で、ユーザープロファイルは FSLogix 等で外部に保持します。セッションホスト OS は Windows 11 Enterprise multi‑session、エンドポイント保護は Microsoft Defender for Endpoint（以下 MDE）と同梱の Defender ウイルス対策（以下 Defender AV）を利用する構成です。
「3〜4 時間の遅延」は何を指すのか（結論）
この数字は、EDR テレメトリの集約・相関、TVM（Threat & Vulnerability Management）などポータル側の“リッチ機能”が完全に使えるようになるまでのおおよその目安を指します。
- デバイスの可視化：オンボーディング完了後、数分（目安 5〜15 分）で Defender セキュリティ ポータルにデバイスが出現します。
- ポリシー適用：Defender AV、ASR（攻撃面削減）、ファイアウォール、クラウド提供の保護などのポリシーは即時適用が前提です。したがって“3〜4 時間”= ポリシー未適用の空白ではありません。
- フル機能化：EDR の詳細タイムライン、アラート相関、TVM スコア、ソフトウェアインベントリなど一部の可視化・評価は数時間の整合待ちが発生します。
時間軸で俯瞰する
| タイミング | 状態 | 代表的な確認ポイント | セキュリティ影響 |
|---|---|---|---|
| 0〜数分 | オンボーディング スクリプト/ポリシー適用 | Sense サービス起動、Get-MpComputerStatus が有効化を返す | リアルタイム保護有効 |
| 5〜15 分 | ポータルにデバイス出現 | デバイス一覧に登場、基本ヘルス表示 | 継続的に保護 |
| 1〜4 時間 | EDR/TVM の相関・集約 | 詳細タイムライン、TVM スコア、インベントリが充実 | 可視化が豊かになる（保護自体は継続） |
なぜ「遅延」が発生するのか（仕組みの理解）
MDE のバックエンドは、センサー（Sense）から送られるイベントを保全しつつ、複数の分析パイプラインで正規化・相関・重複排除を行い、時間軸や脅威インテリジェンスと結びつけます。TVM の脆弱性情報やソフトウェア在庫は追加クロールやマッチングを経て公開されるため、初回はどうしても“見える化が育つ時間”が必要になります。一方で、Defender AV のリアルタイム保護・クラウド保護は即時に有効化され、ASR/ファイアウォール/ネットワーク保護などの構成は OS とクライアント上で直ちに効くことがポイントです。
セキュリティ ギャップは生じるのか
結論はNOです。初回の 3〜4 時間はあくまで“可視化の完全化”までの整合時間であり、デバイス側の保護が欠落する時間ではありません。ただし、誤った配布・自動化（VDI モード未使用、ESP でのブロック未設定、ネットワーク疎通不足）によって、サインイン直後の瞬間に保護が揃わないリスクは現実にあります。以下のベストプラクティスに従うことで、非永続環境でも“起動直後から守られている状態”を実現できます。
即効性のあるベストプラクティス
1. ゴールドイメージに最新の Defender コンポーネントを内包
- イメージ作成直前に Windows Update（品質更新）を適用し、Defender プラットフォーム／エンジン／定義を最新化。
- シグネチャとプラットフォームをプリキャッシュすることで、起動直後のダウンロード渋滞を回避できます。
- Sysprep 前に
Update-MpSignatureで最終同期してからキャプチャするのが定番です。
2. オンボーディングは必ず「VDI モード」を使用
- MDE のオンボーディング パッケージは通常版と VDI 版が提供されています。非永続・プール型では VDI モードを使用し、クローンごとに一意の Device IDを付与して重複レコードや誤集約を防ぎます。
- イメージに VDI 版を組み込むことで、展開のたびにセンサーが正しく再登録されます。
3. Intune の Enrollment Status Page（ESP）で“保護が揃うまでサインインをブロック”
- ESP を Windows 用に有効化し、必須のセキュリティ プロファイル（AV/ASR/EDR/Firewall）とオンボーディングを完了条件に設定。
- ユーザーがセッションに入る前に最小限の構成が適用済みであることを保証します。
4. ターゲティングは「Azure AD 動的グループ」＋「Intune デバイス フィルター」
- Azure AD 動的グループで AVD セッションホストを自動収集（ネーミング規則・タグベースなど運用に合わせて）。
- Intune のデバイス フィルターで OS エディション = Windows 11 Enterprise multi‑session を条件に、AV/ASR/EDR/Firewall ポリシーを即時付与します。
5. オンボーディング確認は“ポータル待ち”ではなく、まず端末側で
Senseサービスが Running であること。Microsoft‑Windows‑SENSE/Operationalログに成功イベント。Get-MpComputerStatusのヘルス指標が有効を返すこと。- これらでポータルが完全反映される前でも保護状態を確信できます。
実装ステップ（サンプル手順）
A. ゴールドイメージの整備
- 最新の Windows 更新を適用（品質更新、Defender プラットフォーム更新）。
- 管理者 PowerShell で以下を実行：
Set-MpPreference -MAPSReporting Advanced Set-MpPreference -SubmitSamplesConsent SendSafeSamples Update-MpSignature Get-MpComputerStatus | Select AMServiceEnabled,AntivirusEnabled,RealTimeProtectionEnabled,AntispywareEnabled,IoavProtectionEnabled - 不要なサードパーティ AV/EDR は削除（競合回避）。
- 必要な FQDN/プロキシ許可（自動更新・クラウド保護・EDR センサー送信）を確認（URL は環境のセキュリティ基準に従い許可）。
B. MDE オンボーディング（VDI モード）を組み込む
- 管理ポータルから VDI 用オンボーディングパッケージを取得。
- イメージ内でスクリプトを実行、もしくはタスクスケジューラに登録して初回ブート直後に確実に動かす。
- 実行後、以下で状態確認：
Get-Service Sense # Status が Running であればセンサーは稼働 Get-MpComputerStatus | Select AntivirusEnabled,RealTimeProtectionEnabled,IsTamperProtected # クラウド接続の健全性テスト PowerShell.exe -Command "Start-Process -Verb RunAs PowerShell -ArgumentList 'Test-MpConnection'"
C. Intune ポリシー（最小セット）
- Defender AV：リアルタイム保護、クラウド提供の保護、サンプル自動送信、有害サイトブロック。
- ASR：最小でも「Office の子プロセス生成のブロック」「疑わしいスクリプトのブロック」「LSASS からの資格情報窃取のブロック」などの基礎セット。
- EDR：ブロック モード（他社 AV がない前提なら有効化）。
- Firewall：ドメイン/プライベート/パブリック プロファイル有効化＋最小例外。
- Device Control/可搬媒体：読み取り専用や実行ブロックなど運用基準に合わせる。
D. ESP を有効化して“構成完了までブロック”
Windows デバイス向け ESP を有効化し、必須アプリ/スクリプトとセキュリティ プロファイルを完了条件に設定。AVD ホストの初回ブート時に自動的に構成が完了するまで、ユーザーのサインインを許可しないようにします。
即時確認に使えるコマンド集（コピペ可）
# 1) MDE センサー（Sense）状態
Get-Service Sense | Format-List Status,StartType,Name
# 2) Defender AV 健康状態
Get-MpComputerStatus | Select-Object AMServiceEnabled,AntivirusEnabled,AntispywareEnabled,RealTimeProtectionEnabled,IsTamperProtected,IoavProtectionEnabled
# 3) ASR ルール適用確認
Get-MpPreference | Select-Object AttackSurfaceReductionRules_Actions,AttackSurfaceReductionRules_Ids
# 4) シグネチャ/プラットフォームの更新
Update-MpSignature
# 5) クラウド接続の検証
Test-MpConnection
# 6) 必要に応じて Defender 設定のエクスポート
Get-MpPreference | ConvertTo-Json -Depth 3“可視化は数時間後”でも安全にする運用の型
- 起動順序の固定化：ネットワーク・プロキシ初期化 → VDI オンボーディング → Defender/ASR/Firewall 適用 → ESP 完了 → サインイン、の順で自動化。
- テレメトリ到着を待たない監視：デバイス側ログとサービス状態を一次信頼。ポータルは二次確認。
- 定義のプリロード：イメージ側で最新化。非永続ゆえに“毎回新規”の初動コストを抑える。
- 重複レコード対策：VDI モード必須。再作成のたびにクリーンな Device ID を付与。
ASR 基本セット例（ブロック推奨）
| 目的 | 代表ルール | 推奨アクション | 備考 |
|---|---|---|---|
| Office からの攻撃面削減 | Office の子プロセス生成をブロック | Block | 業務ツール例外は事前に精査 |
| スクリプト悪用対策 | Win32 API 呼び出しのブロック、疑わしいスクリプトのブロック | Block | 導入初期は Audit で学習も可 |
| 資格情報保護 | LSASS からの認証情報窃取をブロック | Block | 認証トラブル時は監査で切り分け |
トラブルシューティング（よくある詰まり）
| 症状 | 原因の傾向 | 現場での対処 |
|---|---|---|
| ポータルに出てこない | ネットワーク/プロキシでセンサー送信が阻害、VDI モード未使用 | Test-MpConnection、プロキシ許可、VDI 版で再オンボード |
| デバイスが重複表示 | 通常モードでのオンボードやイメージ複製手順の不備 | VDI モードで再展開、古いレコードの整頓 |
| ASR が効いていない | Intune ターゲティングのミス、ESP で未完状態のままサインイン | デバイス フィルターの見直し、ESP でブロックを強化 |
| 毎回シグネチャ更新に時間 | 非永続ゆえの初期状態＋帯域不足 | イメージ側で更新済みに、起動後の帯域制御を実施 |
ネットワーク設計の注意
- クラウド提供の保護とセンサー送信の疎通を優先。プロキシは 起動直後に認証可能な方式（機械アカウント/透過）を選択。
- URL ベースの許可は自動更新・脅威インテリジェンス反映の生命線。
codeブロック内に列挙すれば誤ってリンク化されにくい運用ノウハウです。
# 例: 許可リスト（参考、実環境に合わせて精査）
# * セキュリティ テレメトリ系
# *.windowsdefender.com
# *.wd.microsoft.com
# * 更新系
# *.windowsupdate.com
# *.download.windowsupdate.com
# * クラウド保護系
# *.smartscreen.microsoft.com
# *.mp.microsoft.com
配布とターゲティング（実装例）
Intune デバイス フィルター（例）
ポリシー割り当て時に「OS エディション = Windows 11 Enterprise multi‑session」でフィルターし、AVD セッションホストだけに即時適用します。さらに、ホスト名の接頭辞（例：W11AVD-）やデバイス カテゴリで二重に絞り込むと、誤適用の事故が減らせます。
Azure AD 動的グループ（例）
ホスト命名規則（例：W11AVD-*）やタグ（Azure VM の名前タグ）を前提に動的グループ化し、アサイン先を自動化します。実際のルール言語・対象プロパティは環境のディレクトリ設計に合わせて選定してください。
“初回から守る”を担保する検証シナリオ
- 新規セッションホストを展開し、ESP でユーザーを待機させたまま、管理者セッションで以下を実施。
Get-Service Senseが Running、Get-MpComputerStatusが全て True を返すことを確認。- ASR の代表ルールで意図したブロック/監査が発生するかを安全なテストで検証。
- ESP 完了 → ユーザーサインイン → ログオン スクリプト/アプリの正常動作を確認。
- 数時間後、ポータルの TVM/インベントリが充実していることを確認（可視化の遅延が“保護の欠落”ではないことの裏取り）。
KQL（高度なハンティング）ひな型
可視化が整うまでの間も、流入イベントから新規ホストの挙動を早期把握するためのクエリ例です。環境に合わせて調整してください。
// 直近 4 時間に初回登録されたデバイス
DeviceInfo
| where Timestamp > ago(4h)
| summarize by DeviceName, OSPlatform, LoggedOnUsers
// Defender エンジン/プラットフォーム バージョンの分布
DeviceTvmInfoGathering
| summarize arg_max(Timestamp, *) by DeviceName
| project DeviceName, EngineVersion, PlatformVersion
// ASR が Block/Audit を出したイベント
DeviceEvents
| where ActionType startswith "Asr"
| project Timestamp, DeviceName, ActionType, FileName, InitiatingProcessFileNameガバナンスと運用の勘所
- Tamper Protection（改ざん防止）は既定で有効にし、例外は最小限に。
- 変更管理：ゴールドイメージの更新→小規模リングにて A/B 検証→本番拡大、の順に。
- 可観測性：起動フェーズの失敗（プロキシ認証・センサー）を早期検知できるよう、イベント転送やログ保管（SIEM）を仕込む。
- キャパシティ：非永続は初動の更新要求が集中しやすい。起動ストーム時の帯域/プロキシ負荷を見積る。
ケーススタディ：よくある“惜しい”構成
| アンチパターン | 何が起きるか | 修正ポイント |
|---|---|---|
| 通常モードのオンボーディングをイメージに焼く | Device ID 重複／古いレコード残存で調査が困難 | VDI モードで再作成、古いレコードの整理 |
| ESP を使わず、サインインを即許可 | 一部プロファイル未適用のままユーザーが利用開始 | ESP で必須プロファイル完了までブロック |
| ゴールドイメージが古い | 初回起動ごとに大量ダウンロード→起動遅延 | イメージ更新直後にキャプチャ、Update-MpSignature の実施 |
| プロキシがユーザー依存の認証 | システム/サービスの初動通信が拒否される | 機械アカウント/透過認証に変更、例外の適用 |
よくある質問（FAQ）
Q1. 3〜4 時間の間、脅威は検出・ブロックされないの？
A. いいえ。Defender AV・ASR・ファイアウォールなどエンドポイント上の保護は即時に働きます。遅延の対象は主にポータル側の高度な可視化です。
Q2. 非永続だと定義が毎回消えるのでは？
A. そのとおりです。だからこそイメージに最新の定義・プラットフォームを内包し、起動直後の更新負荷を減らします。
Q3. デバイスが重複表示される
A. VDI モード未使用やイメージ化手順の問題が典型。VDI 版オンボーディングで再構築し、古いレコードはクリーンアップを。
Q4. ESP を入れるとログオンが遅くならない？
A. 初回構成は多少長くなりますが、“保護が揃う前にユーザーが業務を始めるリスク”を除去できます。非永続では特に効果的です。
まとめ
- “3〜4 時間遅延”は、EDR/TVM などポータル側のリッチ機能が整うまでの時間を指します。
- デバイスは数分でポータルに現れ、AV・ASR・Firewall などの保護は即時適用されます。
- VDI モード、ESP によるブロック、デバイス フィルター、最新イメージという 4 点セットで、非永続でも起動直後から十分に安全な AVD を構築できます。
付録：現場で使えるチェックリスト
| カテゴリ | 確認項目 | OK の状態 |
|---|---|---|
| イメージ | Defender プラットフォーム/定義が最新 | 更新日が最新、Update-MpSignature 実施済み |
| オンボーディング | VDI 版を採用 | 展開後に重複デバイスが生成されない |
| ネットワーク | 初回ブート時にプロキシが認証不要/透過 | Test-MpConnection 成功、センサー送信阻害なし |
| Intune | OS エディションでフィルター、AV/ASR/Firewall/EDR を割り当て | 適用状況が Success、監査/ブロックが計画通り |
| ESP | 完了条件に必須プロファイルを含める | ユーザー前に構成が完了 |
| 検証 | Sense 稼働、AV 健全性 OK、ASR イベント出力 | コマンド/イベントで確認済み |
非永続型 AVD と MDE の組み合わせは、適切な“初動”さえ抑えれば非常に強力です。「3〜4 時間」という数字に過剰に怯む必要はありません。意味を正しく理解し、守りの実効性を担保する手順とチェックを仕込んで、安心してスケールさせていきましょう。
コメント