本ヘルプセンターは英語版を翻訳したものです。また、一部には翻訳ソフトウエアにより機械的に翻訳した内容が含まれます。翻訳については順次対応しておりますが、最新の情報になっていない場合があります。最新の情報は英語版のページでご確認ください。表示言語は、画面右上の言語名をクリックして切り替えられます。
本ヘルプセンターの一部の記事には外部リンクが含まれています。万一リンク切れなどお気づきの点がございましたら、お手数ですが弊社サポート窓口までご連絡ください。
Workload Securityへのエージェントの移行
これは、 Deep Securityから Workload Securityへの移行プロセスの一部です。移行プロセスの全体像については、「 Deep SecurityからWorkload Securityへの移行」を参照してください。
前提条件
- APIを使用して移行する場合は、 Deep Security Manager 20.0.321(20 LTS 2021-01-26)以降を使用していることを確認します。または、Deep Security Manager移行ツールを使用して移行する場合は、Deep Security Manager 20.0.513(20 LTS Update 2021-10-14)以降を使用していることを確認します。
- Deep Security Agent 20.0.0-2419以降を使用していることを確認します。次に、 Workload Security コンソールで、[管理]→[アップデート]→[ソフトウェア]→[ローカル]に移動し、対応するDeep Security Agentパッケージがあることを確認します。
- 移行がサポートされているプラットフォームでエージェントが実行されていることを確認します。
- エージェントプラットフォームサポート表 に、 Deep Security Manager 20でサポートされるエージェントプラットフォームを示します。
- エージェントの移行は現在、Intelアーキテクチャ上のWindowsおよびLinuxプラットフォームでのみ完全に検証されています。
- Windows 2008 32ビット版ではエージェントの移行はサポートされていません。
- Deep Security Managerと Workload Securityでは機能が異なるため、エージェントを移行する前にこれらの機能を無効にしてください。
- FIPS 140-2:FIPS 140-2が有効な場合、 Deep Security Managerは移行を拒否します。
- Virtual Appliance: Virtual Appliance (エージェントレスまたはコンバインモード)で保護されているコンピュータは移行を拒否されます。
- Trend Micro Cloud One アカウントの作成、 APIキーの作成、Workload Securityへのリンクの準備など、「 Deep SecurityからWorkload Securityへの移行」に記載されている前述の手順をまだ実行していない場合は完了します。
移行ツールを使用してエージェントを移行する
- Deep Security Managerコンソールの右上隅で、[サポート]→[Workload Securityへの移行]を選択します。
- 表示される[Workload Securityへの移行]画面で、[ Agents ]タブを選択します。
- [[コンピュータ] ページを使用した移行]を選択します。Deep Security [Computers] 画面が表示されます。
- 移行するコンピュータを1台以上選択します。
- [処理]> [Workload Securityへの移行]を選択します。
- 表示されるダイアログボックスで、移動時にエージェントに適用する設定を指定し、[移行]を選択します。
- セキュリティポリシー: Deep Securityポリシーを Workload Security に移行し、移行したエージェントに同じポリシーを適用したままにする場合は、[移行済みポリシーを割り当てる]を選択します。別のポリシーを割り当てる場合は、Workload Securityからポリシーを選択するを選択し、新しいポリシーを選択します。
- コンピュータグループ:エージェントが Workload Securityに配置されるコンピュータグループ。
- Relayグループ:すべてのエージェントは、 Workload Securityのプライマリ Relayグループ に割り当てられます。
- Workload Security Managerへの接続に使用するプロキシ:エージェントからWorkload Securityへの接続に必要なプロキシを選択します。
- Relayに接続するプロキシ:Workload Security上のRelayに接続する必要がある場合は、プロキシを選択します。
- 既存のホスト名、表示名、および説明を使用して移行:移行したエージェントの既存のホスト名、表示名、および説明を使用する場合に選択します。
- コンピュータレベルの設定オーバーライドで移行:コンピュータレベルでオーバーライドのある設定を移行する場合に選択します。ルールの割り当ては含まれません。
- 移動ステータスを確認するを確認します。
- 問題が発生した場合は、 トラブルシューティングを確認してください。
移動ステータスを確認する
移動タスクのステータスは、API応答、コンピュータのページ、およびシステムイベントで確認できます。移動ステータスは、 スマートフォルダの検索条件でもあります。
移動タスクの元の状態は、エージェントがオンプレミスのDeep Security Managerによって管理されている状態です。
Status | Description | 元の状態に復元する方法 |
移行要求済み |
Workload Security への移動タスクが要求されました。 移動タスクはDeep Security Managerによって受け入れられましたが、まだエージェントに送信されていません。 |
N/A |
移行中 |
コンピュータを Workload Securityに移動しています。 エージェントは移動タスクを受け入れ、 Workload Securityに移動しています。 |
N/A |
移行完了 |
コンピュータは Workload Securityに正常に移動されました。 Deep Security Managerは、移動されたエージェントが Workload Securityで有効化されていることを識別できます。 |
エージェントを手動で再有効化してDeep Security Managerに戻します。 エージェントはすでに Workload Security 公開証明書を信頼していることに注意してください。エージェントを有効化してDeep Security Managerに戻す前に、 ds_agent_dsm_public_ca.crt ファイルを手動で削除する必要があります。 |
移行失敗 |
エージェントから Workload Securityへの接続の問題により、コンピュータは Workload Security に移動されませんでした。 エージェントが事前チェックの実行中に移動タスクを拒否しました。 移動を再試行する前に:
|
コンソールで[警告]をクリアします。 エージェントは引き続きDeep Security Managerによって管理されます。 |
移動失敗 (応答なし) |
エージェントが移動タスクに適切なタイミングで応答しなかったため、コンピュータが Workload Security に移動されませんでした。 移動を再試行する前に:
|
コンソールの警告をクリアします。 エージェントは引き続きDeep Security Managerによって管理されます。 |
移動失敗 (有効化に失敗) |
Workload Security への移動が、アクティベーションの問題により失敗し、ロールバックされました。 事前チェックに成功しましたが、エージェントを Workload Securityに有効化できませんでした。 移動を再試行する前に:
|
コンソールの警告をクリアします。 エージェントは引き続きDeep Security Managerによって管理されます。 |
移動に失敗した (管理対象外) |
アクティベーションの問題により、 Workload Security への移動が失敗し、移動を自動的にロールバックできませんでした。コンピュータが管理対象外の状態です。 事前チェックに成功しましたが、エージェントを Workload Securityに有効化できませんでした。 この状態のエージェントは、ロールバック中に不明な問題が発生した可能性があり、エージェントの手動操作が必要です。 この問題のトラブルシューティング:
移動を再試行する前に:
|
Deep Security Managerにエージェントを手動で復元します。 エージェントは引き続きホストコンピュータを保護していますが、 Deep Security Managerによって管理されていません。 詳細については、 「トラブルシューティング」セクションを参照してください。 |
スマートフォルダ を使用して移動ステータスを表示する
- スマートフォルダエディタで、 検索条件を展開します。
- 最初のドロップダウンリストで、プロパティ[ステータス: 移行ステータス]を選択します。
- 2番目のドロップダウンリストで、「移行完了」や「移行失敗」などの値を選択します。
トラブルシューティング
管理対象外のエージェントを手動で復元する
dsa_move.log ファイルを確認して、移動の失敗の根本原因を特定します。エージェントの停止または開始に失敗したため、エージェントの復元に失敗した可能性があります。
エージェントを停止できなかった場合
復元プロセス中にエージェントの停止に失敗した場合、ログに次のエラーメッセージが表示されます。
Unable to stop the agent. Agent restore failed.
エージェントを復元する方法は次のとおりです。
- エージェントサービスを停止します。
-
エージェントのバックアップを復元します。
- エージェントの作業ディレクトリを探します。
- Windowsのエージェント作業ディレクトリ: %ProgramData%\Trend Micro\Deep Security Agent\
- Linux / Unixのエージェント作業ディレクトリ: /var/opt/ds_agent/
- そのディレクトリ内で、バックアップ名は backup_ で始まり、日付で終わります。次に例を示します。backup_2021-05-11_20.11.45
- diag ディレクトリと backup_* ディレクトリを除いて、エージェントの作業ディレクトリからすべてを削除します。
- backup_* ディレクトリからエージェントの作業ディレクトリにすべてをコピーします。
- エージェントサービスを開始します。
- dsa_control -mを使用してDeep Security Managerにハートビートを送信する
- エージェントが正常に復元された( Deep Security Managerで正常に有効化された)場合は、 backup_* ディレクトリを削除します。
エージェントを起動できなかった場合
復元プロセス中にエージェントの起動に失敗した場合は、次のエラーメッセージがログに表示されます。
Unable to start the agent. Agent restore failed.
エージェントを復元する方法は次のとおりです。
- エージェントサービスを開始します。
- dsa_control -mを使用してDeep Security Managerにハートビートを送信する
エージェントを移行するその他の方法
環境に十分な自動化ツールがある場合は、 Workload Security コンソール内の配信スクリプトから有効化コマンドを抽出することで、エージェントを再有効化できます。エージェントを持たない新しいホストでは、スクリプト全体を実行する必要があります。既存のエージェントがインストールされているホストでは、インストールスクリプトの最後のコメントにある dsa_control コマンドを実行するだけで済みます。プロキシを使用している場合は、このコマンドの前の数行を書き留めてから、有効化コマンドを実行する前に正しい値を指定して実行してください。再有効化の際に再起動する必要はなく、プロセス中に保護が失われることもありません。
十分な自動化インフラストラクチャがない環境では、 Deep Security MoveAgent APIを使用できます。これにより、対象の Workload Security アカウントに設定された Workload Security リンクを使用して、エージェントが自動的に再有効化されます。この方法では、 Deep Security Manager 20.0.321(20 LTS 2021-01-26)以降とDeep Security Agent 20.0.0-2419以降が必要です。手順については、Deep Security APIと Workload Security APIを使用した移行。
Workload Securityのオプションを有効にして、有効化時にエージェントを自動的にアップグレードし、最新のエージェントで完全なセキュリティ管理を実現することをお勧めします。 Trend Micro Cloud One リージョン で利用可能な最小エージェントバージョンは異なります。可能なかぎり最新のバージョンのエージェントを使用することをお勧めしますが、お使いのアカウントで使用できない古いバージョンのエージェントが必要な場合は、トレンドマイクロのサポートにお問い合わせください。