Deep Security で「エンジンオフライン」や「アップデート失敗」が発生した時の対処法

はじめに

Trend Micro の Deep Security、特に VMware 環境と連携した Agent レス型 の運用は、各サーバーへのソフトインストールが不要で管理が楽な反面、トラブルが起きると「どこに原因があるのか（DSVA？ ESXi？ VM？）」の切り分けが難しいです。

本記事では、運用中に遭遇しやすい 2つの代表的なエラー について、対処方法を紹介します。

前提環境：Agent レス型運用とは

本記事は、Deep Security Virtual Appliance (DSVA) を使用した Agent レス型 の運用環境を前提としています。

Agent レス型は、各仮想マシン（VM）個別にセキュリティソフトをインストールするのではなく、ハイパーバイザー（ESXi）上に専用のセキュリティ仮想マシン（DSVA）を立て、そこが一括してウイルススキャン等を代行する仕組みです。

本記事のトラブルシューティングは、Deep Security 11.0 および VMware vShield / NSX 環境での経験に基づいています。 最新の Deep Security 20系や NSX-T 環境では、コマンド（vShield-Endpoint-Mux 等）が変更されている場合がありますので、適宜ご自身の環境に合わせて読み替えてください。

Deep Security (Agent レス) の仕組みとメリット

通常、サーバーのセキュリティ対策といえば、OS ごとにソフト（Agent）をインストールするのが一般的です。 しかし、Trend Micro Deep Security の 「Agent レス型」 は、その常識を覆す仕組みを持っています。

DSVA（Virtual Appliance）の役割

Agent レス型運用の主役となるのが、DSVA（Deep Security Virtual Appliance）です。 これは、VMware ESXi などのホスト（物理サーバー）上に 1台だけ展開される、セキュリティ専用の仮想アプライアンスです。

DSVA はハイパーバイザー（VMware）と直接連携し、同じホスト上にいる全ての仮想マシンの通信やファイルを「外側から」監視します。 いわば、「マンションの各部屋に警備員を置くのではなく、エントランスに最強の警備員（DSVA）を一人置いて、全室を監視する」 ようなイメージです。

なぜリソース節約になるのか（メリット）

この仕組みを採用することで、従来の運用に比べて大幅なリソース節約が可能になります。

各 VM へのインストール不要

OS ごとにセキュリティソフトをインストールしたり、管理したりする必要がありません。VM を新規作成した瞬間から、自動的に保護対象に含めることができます。

「AV ストーム」の回避（CPU/メモリ節約）

従来型では、始業時などに全台が一斉にウイルススキャンやアップデートを開始すると、サーバー全体が重くなる現象（AVストーム）が発生しがちでした。 Agent レスなら、スキャン処理や定義ファイルの更新は DSVA が一手に引き受けます。 重複した処理がなくなるため、サーバー全体のリソース消費を大幅に抑えられます。

ディスク容量の節約

各仮想マシン内に、肥大化しがちな「パターンファイル（定義ファイル）」を持つ必要がありません。DSVA だけが最新データを持っていれば良いため、ストレージ容量の節約にも繋がります。

VDI（仮想デスクトップ）環境など、同じような OS が大量に稼働する環境では、この「リソース効率の良さ」が特に大きな効果を発揮します。

エラー①：不正プログラム対策エンジンがオフライン

Deep Security 管理画面（DSM）のアラートで最も心臓に悪いのが、この 「不正プログラム対策エンジンがオフライン（Anti-Malware Engine Offline）」 というエラーです。

何が起きているのか？

このエラーが表示されている間、対象の仮想マシンは 「無保護（Unprotected）」 の状態です。ウイルススキャンが行われておらず、感染リスクが高まっているため、早急な復旧が必要です。

まずは切り分け（範囲の特定）

トラブルシューティングの第一歩は、「どこまで影響が出ているか」を確認することです。以下のどちらに当てはまるかを確認してください。

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

特定の VM だけがおかしい場合、DSVA と通信するための 「VMware Tools」 や 「専用ドライバー」 が正しく動いていない可能性が高いです。

考えられる原因

仮想マシンがスリープ状態

スリープ中は Agent レス保護も停止します（復帰すれば直ります）

VMware Tools の不具合

必須コンポーネントが停止している。

NSX ポリシーの適用漏れ

セキュリティタグ等が外れている（※NSX環境の場合）

ドライバーの稼働確認（Windows の場合）

対象の仮想マシンにログインし、コマンドプロンプト（管理者権限）で以下のコマンドを実行します。 Deep Security と連携するためのドライバ（vsepflt と vmci）の状態を確認します。

sc query vsepflt
sc query vmci

正常な状態: STATE が RUNNING と表示されていれば正常です。 もし STOPPED や、そもそも「サービスが見つかりません」となる場合は異常です。

対処法：VMware Tools の再インストール

ドライバーが動いていない、または挙動がおかしい場合は、VMware Tools の再インストール（または修復） が最も確実な解決策です。

1. コントロールパネルから VMware Tools をアンインストール
2. 再起動後、VMware Tools を新規インストール

インストール時のオプションで 「Guest Introspection (NSX File Introspection)」 などのセキュリティドライバが含まれていることを確認してください（標準インストールなら通常は含まれます）

ケースB：ESXi 上の全ての仮想マシンで発生する場合

特定の ESXi ホスト上の VM が全滅している場合、そのホストを守っている DSVA (Deep Security Virtual Appliance) か、ESXi 側の連携プロセス がスタックしている可能性があります。

対処①：DSVA の Agent 再起動

まずは、警備員である DSVA の調子を戻しましょう。 対象の DSVA に SSH またはコンソールでログインし、Agent サービスを再起動します。

# Deep Security Agent の再起動
sudo service ds_agent restart

これで復旧しない場合は、対処②へ進みます。

対処②：ESXi 側のサービス再起動

ESXi 側で、DSVA と通信するための「仲介役」プロセスを再起動します。 ※対象の ESXi ホストへ SSH 接続し、以下のコマンドを実行します。

# vShield-Endpoint-Mux の再起動
/etc/init.d/vShield-Endpoint-Mux restart

このコマンドを実行しても、稼働中の仮想マシン（ゲストOS）自体が停止することはありませんが、念のためメンテナンス時間帯の実施を推奨します。

エラー②：セキュリティアップデートに失敗（Proxy 環境）

2つ目は、Deep Security Manager（DSM）や Relay が、トレンドマイクロのサーバーからパターンファイルをダウンロードする際に失敗する事象です。

特に、「プロキシサーバー（Proxy）」 を経由している環境で発生しやすいトラブルです。

事象とエラー内容

管理コンソール上で、以下のようなエラーメッセージが表示され、いつまで経っても最新の保護ルールが適用されません。

DSM 側

「セキュリティアップデート：Agent/Appliance でのパターンファイルのアップデート失敗」

Relay 側

「セキュリティアップデート：セキュリティアップデートの確認とダウンロード失敗」

原因：Proxy による SSL/TLS インスペクション

企業ネットワークでは、セキュリティ強化のために プロキシサーバーで 「SSL デコード（通信の中身を見る機能）」 を有効にしている場合があります。

この場合、プロキシがトレンドマイクロの純正証明書を、プロキシ自身の証明書に置き換えて（Re-sign して）通信します。 Deep Security 側（特に Ver 11.0 以降）はこれを 「通信が改ざんされた（中間者攻撃）」 と判定し、安全のために接続をブロックしてしまいます。これがアップデート失敗の正体です。

【解決策】URL末尾に // を追加する

この問題を回避する方法として「アップデート元 URL の末尾にスラッシュを2つ追加する」というのがあります。

1. DSM 管理コンソールの 「管理」>「システム設定」>「アップデート」 タブを開きます。
2. 「セキュリティアップデート元」にて、「その他のアップデート元」 にチェックを入れます。
3. URL を以下のように記述します（末尾に // を追加）

https://ipv6-iaus.trendmicro.com/iau_server.dll//

なぜこれで直るのか？（仕組み）

「スラッシュを2つ付けるだけで直るなんて、おまじない？」と思われるかもしれません。 実はこれ、Deep Security の内部仕様を利用した回避策です。

URL の末尾に // を追加することで、その接続に対する 厳密な TLS 証明書検証（TLS 認証）が無効化 されます。 これにより、プロキシによって証明書が置き換えられていても、「証明書エラー」として弾くことなく、通信を許可するようになります。

この設定は証明書の正当性チェックをスキップするものです。 「信頼できる社内プロキシを経由している」という前提でのみ実施してください。

まとめ

本記事では、Deep Security (Agentレス) 運用において、特に遭遇しやすい2つのトラブルと対処法を紹介しました。

Agent レス運用は、一度安定してしまえば非常に楽な構成ですが、トラブル時は「仮想基盤（VMware）」と「セキュリティ（Trend Micro）」の両方の知識が求められます。 本記事のコマンドや回避策が、現場の復旧作業の助けになれば幸いです。

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