Deep Security エンジンオフライン｜全モジュール共通の復旧手順

はじめに

Trend Micro Deep Security を VMware 環境と組み合わせて運用していると、管理コンソール（DSM）に「不正プログラム対策エンジンがオフライン」や「セキュリティアップデートの失敗」といった警告が表示され、原因が DSVA・ESXi・仮想マシンのどこにあるのか、切り分けに時間がかかることがあります。

エンジンオフラインは、多くが「仮想マシン側のドライバー」「ESXi ホスト側の連携プロセス」「NSX ライセンスや同期状態」のいずれかに起因します。まず影響範囲（単一 VM か、ホスト全体か、特定エンジンのみか）を特定し、範囲に応じて仮想マシン・DSVA・ESXi の順に確認していく流れが復旧の近道になります。アップデート失敗については、Proxy の SSL インスペクションのほか、2025 年 9 月に一部エージェントで発生した iAU 証明書の期限切れも原因となり得ます。

本記事は Deep Security 20（現行の LTS）を基準に整理しています。かつて広く使われた Deep Security 11.0 系はサポート終了（EOL）に達しているため、11.0 前提のコマンドや画面は現行環境に合わせて読み替えることを推奨します。

Deep Security でエンジンがオフラインになる仕組みと前提

Deep Security の保護は、仮想マシンに導入する Agent 型と、ESXi ホスト上の専用アプライアンス（DSVA）で複数 VM をまとめて保護する Agent レス型に分かれます。エンジンオフラインの原因は両者で異なるため、まず自環境がどちらか（または両者を併用する Combined Mode か）を確認します。

Agent レス（DSVA）と Agent 型の違い

 Agent レス型: ESXi ホストごとに DSVA を 1 台展開し、VMware（NSX / Guest Introspection）と連携して、同一ホスト上の VM のファイル I/O や通信を VM の外側から検査します。VM ごとのソフト導入が不要で、パターンファイルを DSVA に集約できます。

 Agent 型: 各 VM・サーバーに Deep Security Agent（DSA）を導入します。OS を問わず機能を利用しやすく、Agent レスで非対応の機能も利用できます。

 ハイパーバイザーベースの不正プログラム対策・変更監視（System Security）は Windows のみ対応で、Linux は Agent レスの対象外です。この前提を外すと「Linux VM だけ保護されない」と誤認しやすいため、Linux VM は Agent 型での保護を前提に据えます。

参考: Deep Security Feature Releases and VMware compatibility matrix（Trend Micro）
“are currently unavailable for Linux platforms”
（ハイパーバイザーベースの不正プログラム対策・システムセキュリティは Linux プラットフォームでは利用できません）
https://success.trendmicro.com/en-US/solution/KA-0002788

対象バージョンと NSX 環境の現況

現行の LTS は Deep Security 20 で、Manager・Agent・Appliance の各コンポーネントを個別に更新できます。11.0 系は標準サポート 3 年・延長サポート 4 年の期間を終えて EOL に達しているため、本記事は 20 を基準に記載します。

あわせて、Agent レスが依存する VMware の Guest Introspection / Network Introspection は縮小方向にあります。Broadcom は Network Introspection for Security 機能を、最後の NSX 4.2.x リリース以降、または 2027 年 10 月 11 日のいずれか早い時点で終了するとしています。新規増設ではライセンス要件も変わるため、Agent レスの拡張よりも Agent 型（または Combined Mode）への移行を前提に設計するほうが、中長期的には安全です。

参考: End of Availability Announcement for NSX Network Introspection for Security（Broadcom）
“VMware will discontinue Network Introspection for Security feature after the last NSX 4.2.x release”
（VMware は Network Introspection for Security 機能を、最後の NSX 4.2.x リリース以降に終了します）
https://knowledge.broadcom.com/external/article/322083/end-of-availability-announcement-for-nsx.html

エンジンオフラインの切り分け（範囲の特定）

復旧の第一歩は影響範囲の特定です。単一 VM か、ホスト全体か、特定エンジン種別か、の 3 分岐で原因の当たりが変わります。

flowchart TD
    A[エンジンオフラインを検知] --> B{影響範囲は？}
    B -->|特定の 1 VM のみ| C[VM 側のドライバー / VMware Tools を確認<br/>ケース A へ]
    B -->|同一 ESXi 上の VM が全般的に| D[DSVA / ESXi 連携プロセスを確認<br/>ケース B へ]
    B -->|特定エンジンだけが全体で| E[NSX ライセンスとポリシー設定を確認]
    C --> F[改善しなければ vCenter / NSX の同期状態を確認]
    D --> F

 単一 VM のみで発生: その VM の Guest Introspection ドライバー（vsepflt）や VMware Tools の不具合が疑わしいケースです。ケース A に進みます。

 同一 ESXi ホスト上の VM が全般的に発生: その DSVA、または ESXi 側の連携プロセス（MUX）の停止・スタックが疑わしいケースです。ケース B に進みます。

 特定のエンジン種別（ファイアウォール・侵入防御・Web レピュテーション など）だけが全体でオフライン: NSX ライセンス階層やポリシー設定に起因することが多く、切り分けの観点が異なります（次の制約を参照）。

エンジン種別ごとの前提（NSX ライセンスと agentless の可否）

「特定のエンジンだけが全体でオフライン」というケースでは、故障ではなくライセンス・設計上の制約が原因のことがあります。Agent レスで利用できるエンジンは NSX のライセンス階層に依存します。NSX の下位（無償相当）ライセンスでは、Agent を併用しない限りファイアウォール・侵入防御・Web レピュテーションを各ポリシーで無効化しておく必要があり、有効なままだと該当エンジンがオフラインとして扱われます。これらを Agent レスで利用するには、上位（Advanced / Enterprise 相当）の NSX ライセンスが必要になります。

「特定エンジンだけオフライン」の多くは、この前提に対してポリシーで当該エンジンを有効化していることが原因です。Agent レスで賄えない機能は、対象 VM に DSA を併用する Combined Mode で補います。

参考: Troubleshooting Anti-malware and Firewall Engine Offline errors in Agentless NSX（Trend Micro）
https://success.trendmicro.com/en-US/solution/KA-0004430

ケース別の復旧手順

ケース A: 特定の仮想マシンのみで発生する場合

単一 VM のみで発生する場合、DSVA と連携するドライバー（vsepflt・vmci）や VMware Tools の不具合が主因です。

考えられる主因は次のとおりです。

• VM がスリープ・サスペンド状態（復帰で解消することがある）
• VMware Tools の Guest Introspection（NSX File Introspection）ドライバーの停止・未導入
• NSX 環境でのセキュリティタグ・ポリシー適用漏れ

ドライバーの稼働確認（Windows）は、管理者権限のコマンドプロンプトで行います。

sc query vsepflt
sc query vmci

STATE が RUNNING であれば正常です。STOPPED や「指定されたサービスがインストールされていない」と表示される場合はドライバー側の問題です。msinfo32 の「システム ドライバー」からも vsepflt の有無を確認できます。

対処としては、VMware Tools の修復インストール（インストール時に Guest Introspection ドライバーを含める）が有効です。VMware Tools のバージョンによって、当該ドライバーは「vShield Drivers」または「NSX File Introspection Drivers」として表示されます。

参考: Troubleshooting Anti-malware Engine Offline errors（Trend Micro）
“Make sure that the Guest Introspection driver (vsepflt) is installed and running”
（Guest Introspection ドライバー（vsepflt）が導入され、稼働していることを確認します）
https://success.trendmicro.com/en-US/solution/KA-0004430

ケース B: 同一 ESXi 上の仮想マシンで全般的に発生する場合

ホスト単位で全般的に発生する場合、その DSVA か ESXi 側の連携プロセスの停止・スタックが疑わしい状況です。上から順に確認します。

# 現行の systemd 環境
sudo systemctl restart ds_agent

# 旧環境（init）でドキュメント上の記載
sudo /etc/init.d/ds_agent restart

ケース C: Agent 型 Linux でカーネル更新後にオフラインになる場合

Agent レスではなく各サーバーに DSA を導入している Linux 環境では、カーネル更新の直後に不正プログラム対策エンジンがオフラインになる事象が代表的です。不正プログラム対策・Web レピュテーション・ファイアウォール・侵入防御・変更監視のいずれかを有効にしている場合、稼働中のカーネルに対応するカーネルモジュール（KSP: Kernel Support Package）が導入されていないとエンジンが読み込めません。

主な発生パターンは 2 つです。

• カーネルを新しいバージョンへ更新した直後: それまで導入済みのモジュールが新カーネルと非互換になり、対応 KSP の再取得が必要になります。
• DSA をアップグレードした直後: エージェント側が新しくなり、既存のカーネルモジュールと非互換になります。

確認と復旧の手順は次のとおりです。

# エージェントの状態確認
sudo /opt/ds_agent/dsa_query -c GetAgentStatus

# サービスの再起動（systemd 環境）
sudo systemctl restart ds_agent

補足として、Secure Boot を有効にした Linux で公開鍵が未登録の場合も、不正プログラム対策エンジンがオフライン、または基本機能のみの状態になります。Secure Boot を利用する場合は公開鍵の登録を確認し、利用しない場合は Secure Boot を無効化することで復旧につながります。

参考: Agent Linux kernel support（Deep Security 20 Help Center）
https://help.deepsecurity.trendmicro.com/20_0/on-premise/agent-linux-kernel-support.html

セキュリティアップデート失敗の原因と対処

パターンファイルの更新に失敗する事象は、Proxy の SSL インスペクションと、パターン署名（iAU）証明書の期限切れという 2 系統に大別できます。DSM や Relay がトレンドマイクロのアップデート元へ到達できていても、通信の検証段階で失敗しているケースが多く、原因ごとに対処が分かれます。

Proxy の SSL インスペクションによる失敗

企業ネットワークでは、Proxy で SSL インスペクション（復号検査）を有効にしている場合があります。この場合、Proxy が正規の証明書を Proxy 自身の証明書へ置き換えて中継するため、DSA・Relay 側が証明書の不一致を検知し、安全側に倒して接続を遮断します。これがアップデート失敗の一因です。SSL インスペクションの仕組みそのものは、詳細は関連記事『SSL/TLS インスペクションの仕組みと注意点』を参照してください。

対処の基本は、トレンドマイクロのアップデート関連通信（Active Update サーバーおよび Relay 宛て）を、Proxy の SSL インスペクション対象から除外（ホワイトリスト化）することです。除外により、証明書の置き換えが発生しなくなり、正規の検証が通ります。除外できない運用では、当該通信を復号しない Proxy 経路へ振り分ける方法も検討します。

なお、コミュニティ等では「アップデート元 URL の末尾に // を追加すると、その接続の証明書検証が無効化されて回避できる」という方法が共有されています。この挙動はトレンドマイクロの公式ドキュメントでは確認できませんでした。証明書検証を無効化する前提の回避策であり、Proxy 経路の安全性を担保できる場合に限られます。可能であれば、証明書検証を維持したまま解決できる除外設定を優先することを推奨します。設定を行う場合は、事前に対象環境の公式リファレンスで挙動を確認してください。

参考: Configure the update source（Deep Security 20 Help Center）
https://help.deepsecurity.trendmicro.com/20_0/on-premise/command-line-interface.html

iAU（パターン署名）証明書の期限切れ

もう 1 つの原因が、パターン署名に用いられる iAU 証明書の期限切れです。証明書が失効すると、Proxy の有無にかかわらず更新に失敗します。2025 年 9 月には一部の DSA で iAU 証明書が期限切れを迎え、該当エージェントで「Security Update Check and Download Failed」や「不正プログラム対策の保護がない、または期限切れ」が表示される事象が周知されました。

• Relay が比較的新しいビルドの場合: システムイベントに IAURELAY_STATUS_DIGITAL_SIGNATURE_CERT_EXPIRE が表示されます。
• Relay が古いビルドの場合: IAURELAY_STATUS_CHECK_DIGITAL_SIGNATURE_FAILURE が表示されます。

対処は、Manager・Relay を最新の Deep Security 20 リリースへ更新し、最新パターンを再取得することが基本です。旧バージョンの Relay で解消しない場合は Relay の再インストールを検討します。同じ「アップデート失敗」でも、Proxy 起因か証明書失効起因かでイベントの説明文が異なるため、まずシステムイベントの説明を確認して切り分けると、対処を誤りにくくなります。

参考: Expiration of iAU certificates in some Deep Security Agent versions（Trend Micro）
“Security Update: Security Update Check and Download Failed”
（セキュリティアップデートの確認とダウンロードに失敗しました）
https://success.trendmicro.com/en-US/solution/ka-0019326

エラー・ステータス早見表

切り分けの起点として、公式で確認できる代表的な表示と主因を整理します。個別の数値イベント ID については、DSM のシステムイベント詳細と対応する公式 KB で意味を確認することを推奨します。

参考: “Security Update: Pattern Update on Agents/Appliance Fail” error in Deep Security（Trend Micro）
https://success.trendmicro.com/en-US/solution/KA-0017207

Agent レスと Agent 型（Combined Mode）の選定

エンジンオフラインの復旧と並行して、構成そのものの見直しが有効な場面もあります。Agent レスは VM ごとの導入が不要で運用負荷が低い一方、利用できるエンジンが NSX ライセンスとプラットフォーム（Windows / Linux）に左右されます。前述のとおり、Agent レスの土台となる NSX の Guest Introspection / Network Introspection は終息方向にあります。

選定の目安は次のとおりです。

• Windows 中心で NSX を継続運用: 当面は Agent レスも選択肢になりますが、終息時期を見据えた移行計画を並行して検討します。
• Linux を保護対象に含む: 不正プログラム対策・変更監視は Agent 型が前提となるため、Agent 型を基本に据えます。
• ファイアウォール・侵入防御・Web レピュテーションを広く使う: 上位 NSX ライセンスが要るため、要件次第では Agent 型（または Combined Mode）のほうが構成をシンプルに保てます。
• 中長期の安定性を重視: NSX 側の機能終息を踏まえ、Agent 型を主体とする構成へ段階的に移行する方針が、将来の非互換リスクを抑えやすくなります。

Combined Mode は、Agent レスと Agent 型を併用し、機能ごとに保護の担い手を使い分ける構成です。Agent レスで賄えない機能だけを Agent 型で補うことで、移行期の空白を作らずに運用できます。セキュリティ製品の運用に関する記事は、関連記事一覧（/security/）にも整理しています。

まとめ

Deep Security のエンジンオフラインとアップデート失敗は、原因の切り分けが復旧の起点になります。仮想マシン・DSVA・ESXi のどこに起因するかを範囲から特定し、Agent レスと Agent 型それぞれの前提に沿って対処することが有効です。NSX の機能終息も見据え、構成の見直しもあわせて検討することを推奨します。

• エンジンオフラインは影響範囲の特定から切り分ける。
• 単一 VM はドライバー、ホスト全体は DSVA と MUX を確認
• Linux はカーネル更新後の KSP 未対応でオフライン化
• 特定エンジンのみの停止は NSX ライセンス制約が主因
• アップデート失敗は Proxy 検査と iAU 証明書失効の 2 系統
• iAU 証明書は 2025 年 9 月に一部失効、Manager と Relay の更新で対処
• NSX 機能の終息を見据え Agent 型主体への段階移行を検討

以上、最後までお読みいただきありがとうございました。