Trend Vision One Endpoint Security(Server & Workload Protection)を1vCPUのインスタンスタイプで利用してみる

Trend Vision One Endpoint Security(Server & Workload Protection)を1vCPUのインスタンスタイプで利用してみる

Clock Icon2024.03.07

こんにちは、シマです。
皆さんはTrend Vision One Endpoint Security(Server & Workload Protection)(以降V1ES)を使っていますか?V1ESは、トレンドマイクロ社が提供するソリューションの1つで、Cloud One Workload Security(以降C1WS)の後継製品となり、クラウド上に存在するサーバ、インスタンスを保護するために必要な機能を提供するクラウド型総合サーバーセキュリティサービスです。
今回はそんなV1ESをt2.micro等の1vCPUインスタンスタイプに導入する方法について記述していきます。

背景

従来のCloud One Workload Security(以降C1WS)では、下記ページ内にあるように4vCPU以上のインスタンスタイプが推奨されています。

しかし、コストの兼ね合いから検証環境等については、t2.microインスタンスのような1vCPUのインスタンスに導入していたケースもあったかと思います。
※クレジット枯渇やCPU使用率の監視は必要です。

V1ESのシステム要件については、LinuxにおけるvCPU数は記載されていませんがWindowsにおいては4vCPUと記載されているので、おそらく同等かそれ以上のvCPUが必要であると想定されます。

そのため、C1WSの時と同様に1vCPU(t2.micro)のインスタンスタイプに以下の手順でV1ESのエージェント導入をしてみました。

結果として、V1ES管理画面において対象サーバが管理対象にならず、サーバ内に以下のような内容がログ(/opt/TrendMicro/EndpointBasecamp/logs/tmxbc.log)に出力されていました。

Error: Insufficient CPU cores detected (2 cores minimum required)

設定

V1ESのエージェントでは、ログの内容から2vCPUが必須要件なっていると想定されます。そのため、今回は従来のエージェントを導入してV1ESを利用していこうと思います。

エージェントのインストール

Trend Vision Oneコンソールへログインし、「Endpoint Security Operations」→「Server & Workload Protection」を選択します。

「管理」タブから、左ペインの「アップデート」→「ソフトウェア」→「ローカル」をクリックし、「インストールスクリプトの生成」ボタンを押下します。

各種パラメータを設定し、「ファイルに保存」ボタンを押下します。

保存したファイル「AgentDeploymentScript.sh」を対象EC2へ格納し、実行権限を付与してインストール処理を実行します。

[ec2-user@ip-10-0-3-153 ~]$ ll
total 4
-rw-r--r--. 1 ec2-user ec2-user 3430 Mar  5 04:36 AgentDeploymentScript.sh
[ec2-user@ip-10-0-3-153 ~]$ sudo chmod +x AgentDeploymentScript.sh
[ec2-user@ip-10-0-3-153 ~]$ ll
total 4
-rwxr-xr-x. 1 ec2-user ec2-user 3430 Mar  5 04:36 AgentDeploymentScript.sh
[ec2-user@ip-10-0-3-153 ~]$ sudo ./AgentDeploymentScript.sh
Downloading agent package...
Installing agent package...
warning: /tmp/agent.rpm: Header V4 RSA/SHA512 Signature, key ID xxxxxx: NOKEY
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
Host platform - NAME="Amazon Linux"
Updating / installing...
   1:ds_agent-20.0.1-3180.amzn2023    ################################# [100%]
This installer is PGP signed, signature is RSA/SHA512
enable ds_agent service with systemd
Created symlink /etc/systemd/system/multi-user.target.wants/ds_agent.service → /usr/lib/systemd/system/ds_agent.service.
DSA service started
Install the agent package successfully
HTTP Status: 200 - OK
2024-03-05 04:37:41.292049 [+0000]: Activation will be re-attempted 30 time(s) in case of failure
2024-03-05 04:37:41.292547 [+0000]: dsa_control
HTTP Status: 200 - OK
Response:
Attempting to connect to https://agents.workload.jp-1.cloudone.trendmicro.com:443/
SSL handshake completed successfully - initiating command session.
Connected with ECDHE-RSA-AES256-GCM-SHA384 to peer at agents.workload.jp-1.cloudone.trendmicro.com
Received a 'GetHostInfo' command from the manager.
Received a 'SetDSMCert' command from the manager.
Received a 'SetAgentCredentials' command from the manager.
Received a 'GetAgentEvents' command from the manager.
Received a 'SetAgentStatus' command from the manager.
Received a 'GetInterfaces' command from the manager.
Received a 'GetAgentEvents' command from the manager.
Received a 'GetHostMetaData' command from the manager.
Received a 'GetCapabilities' command from the manager.
Received a 'GetAgentStatus' command from the manager.
Received a 'GetAgentEvents' command from the manager.
Received a 'GetDockerVersion' command from the manager.
Received a 'GetCRIOVersion' command from the manager.
Received a 'GetPodmanVersion' command from the manager.
Received a 'SetXDRInformation' command from the manager.
Received a 'SetSecurityConfiguration' command from the manager.
Received a 'GetAgentEvents' command from the manager.
Received a 'GetAgentStatus' command from the manager.
Received a 'GetIoT' command from the manager.
Received a 'SetIoT' command from the manager.
Received a 'SetDSMCACert' command from the manager.
Received a 'Metrics' command from the manager.
Command session completed.

V1ESコンソール上でも問題なく管理対象になっていることが確認できました。

動作確認してみた

V1ESの各種設定が既に設定されている環境で、管理対象になっているEC2インスタンス内にEICAR テストファイルを作成し、不正プログラムを検出させてみました。問題なく隔離され、以下のようにアラートメールが送信されることが確認できました。

注意事項

今回の方式では従来のエージェントを利用しているため、Vision Oneからの新機能が利用できないと考えらえます。システム要件は以下の通りですので、基本的にはそちらを満たしたうえで、通常通りV1ESのエージェントを導入することが望ましいです。

最後に

今回は、1vCPUインスタンスタイプでV1ESを利用する方法について設定と動作確認をしてみました。
本記事がどなたかのお役に立てれば幸いです。

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.