Deep Security管理者は、環境をTrend Cloud One - Endpoint & Workload Securityに移行する準備をしている場合、この記事の手順を使用して、移行を成功させるためのロードマップを作成できます。
注意Deep Security Manager 20.0.513 (20 LTS Update 2021-10-14) 以降である必要があります。
|
一般的に、成功する移行のための操作順序は以下の通りです:
Workload Security アカウント、ユーザ、ロール、および認証を設定する
Workload Securityサービスを使用するには、Trend Cloud Oneアカウントが必要です。設定、ポリシー、またはコンピュータをサービスに移行する前に、アカウントを設定してください。
SAMLには、Trend Cloud Oneで2つのサポートレベルがあります。Workload Security専用と共通レベルです。これらの手順は、Deep SecurityをWorkload
Securityに接続する方法を説明しています。
Trend Cloud Oneには2種類のアカウントがあります。2021年8月4日以降に作成された[新規アカウント]と、それ以前に作成された[レガシーアカウント]です。どちらのタイプのアカウントを持っているかわからない場合は、Trend Cloud Oneアカウントの変更を参照してください。
新しいTrend Cloud Oneアカウントは、新しいIdentity and Access Managementシステムを使用します。Trend Cloud Oneアカウントとユーザ管理ドキュメントを確認して、Workload Securityへの移行時にユーザと役割を正しく管理する方法を深く理解してください。
従来のTrend Cloud Oneアカウントをお持ちの場合、Deep Securityの実装からWorkload Securityの従来のアカウントにユーザおよびロールの権限を手動で移行する必要があります。従来のアカウントのユーザおよびロールの構成は、Deep
Securityソフトウェアの実装とほぼ同一であり、既存の機能を再現します。
Deep Security ManagerでSAMLを使用している場合、Workload SecurityコンソールでSAMLを設定し、認証とロールマッピングを行うアイデンティティプロバイダにエクスポートされた適切なサービスプロバイダメタデータをインポートする必要があります。
注意ADFS経由でSAML経由で委任されないかぎり、認証のためのActive Directoryとの統合は Workload Security ではサポートされません。
|
ロールとAPIキーを作成
カスタムロールの定義の指示に従ってカスタムロールを作成します。サービスWorkload Securityの事前定義された権限Deep Security Migrationをロールに割り当てます。Deep
Security Migration権限は、エージェントやポリシーの移行を実行する権限を持つWorkload Securityによって事前設定され、管理されています。追加の移行機能が実装されると、関連する権限が将来変更される可能性があります。ロールを作成した後、新しいAPIキーの作成の手順に従って、定義されたロールでAPIキーを作成します。
注意トレンドマイクロは、APIキーにフルアクセスの役割を割り当てないことを強く推奨します。これによりセキュリティ上の懸念が生じます。
|
Workload Securityへのリンクを準備する
Trend Vision One Endpoint Security (以前はMigrate to Workload Securityツールと呼ばれていました) への移行は、Trend
Vision One Endpoint Security - サーバ&Workload ProtectionおよびTrend Cloud One - Endpoint
& Workload Securityの両方の移行を可能にします。なお、ツール自体に加えて、関連するロール構成も名前が変更されました。
ユーザがTrend Vision One Endpoint Securityリンクを管理するには、[Trend Vision One Endpoint Security Linkの管理を許可します]のロール権限を割り当てる必要があります。
-
Deep Security Managerコンソールで、[サポート情報]→[Trend Vision One Endpoint Securityへの移行]を選択します。
-
[Trend Vision One Endpoint Securityへのリンク]ページで:
-
前のセクションで作成したAPIキーを入力します。
-
Workload Security アカウントがあるリージョンを選択します。
-
[保存]をクリックしてください。

警告
以前にDeep Securityと Workload Security の間の接続を設定していて、リンクを変更する場合は、リンクを変更する前に、以前の接続を使用するすべての移行関連タスクが完了していることを確認してください。そうしないと、予期しない動作が発生する可能性があります。各Deep Security Managerテナントは、1つのTrend Vision One Endpoint Securityリンク (以前はWorkload Securityリンクと呼ばれていました) のみを許可します。Trend Vision One Endpoint Securityリンクの作成中 (以前はWorkload Securityリンクと呼ばれていました)、Deep Security ManagerはWorkload Securityに接続してリンクを認証し、情報を取得します。Deep Security ManagerのインストールにWorkload Securityへの接続にプロキシが必要な場合は、Workload Securityのプロキシを構成してください。 -
-
[Trend Vision One Endpoint Securityへの移行]ページが表示され、[設定の移行]タブが選択されています。ユーザがすべての移行タスクを処理できるようにするには、ロール権限[Allow migration to Trend Vision One Endpoint Security]を割り当てる必要があります。
その他のDeep Security設定の移行
次に、Deep Security環境で使用している場合は、次のアーティファクトを移行します。
VMwareコネクタとデータセンターゲートウェイ
VMware環境で稼働している仮想マシンには、他のワークロードと同様にエージェントを展開してWorkload Securityサービスにアクティブ化することができます。VMインベントリを取得するためにVMware
vCenterに接続したい場合、Workload SecurityはvCenterと通信する必要があります。これはデータセンターゲートウェイを通じて行われます。データの設定とvCenterインベントリのインポート手順については、Workload SecurityにVMware vCenterを追加するを参照してください。
コンピュータグループとスマートフォルダ
コンピュータグループとスマートフォルダには、まだ直接移行する方法はありません。Deep SecurityとWorkload Securityコンピュータグループを一覧表示および作成するためのAPIがあるため、適切なAPI呼び出しをスクリプト化することで、多数のグループの移行を自動化できます。
プロキシ設定
現在、Deep SecurityからWorkload Securityへのプロキシ設定を自動的に移行する方法はありません。プロキシの設定の指示に従って、Workload Securityでエージェント通信のプロキシ設定を手動で構成できます。
Managerのプロキシは Workload Security サービスの一部であり、トレンドマイクロが管理しているため、プロキシを設定する必要はありません。
イベントとアラートのログ記録
Deep SecurityとWorkload Securityの主な違いは、マネージャ内でのイベントとアラートデータの保持です。Workload Securityはセキュリティイベントを32日間、システムイベントを91日間保持します。イベントをより長く保持する必要がある場合、Trend MicroはイベントをSIEMまたはログサーバにエクスポートすることを推奨します。
すでにイベントログを使用している場合、アラートやイベントを受信するためにインフラストラクチャの変更が必要になることがあります。Deep Security Managerがすべてのアラートやイベントをsyslogを介してローカルのsyslogサーバに送信する従来のオンプレミス展開では、そのsyslogサーバがWorkload
Securityから直接アクセスできない場合があります。次の代替案を検討してください:
-
Workload Securityサービスからアクセス可能な新しいsyslogサーバを作成するには、次の手順に従ってください: Workload SecurityイベントをSyslogまたはSIEMサーバに転送する。
-
Manager経由ではなくローカルのSyslogサーバにイベントを直接送信するようにAgentを設定します。SyslogでTLS暗号化を使用するには、イベントを Workload Security サービスから転送する必要があります。エージェントは現在、SyslogイベントのTLS暗号化をサポートしていません。
-
Amazon SNSをsyslogの代替として使用します。Amazon SNSのセットアップを参照してください。
追加設定
他のアーティファクトの構成 (システム設定、レポート、イベントベースおよびスケジュールされたタスク、タグ、バージョン管理、API Keysなど) は、現在のところ自動移行機能の一部ではありません。これらはWorkload
Securityで手動で再作成できます。これらのアーティファクトの多くは、Deep SecurityおよびWorkload SecurityのAPIで構成可能であり、自動化することができます。
注意Deep SecurityからWorkload Securityへの移行時に、一部のシステム設定がサポートされない、または適用されない場合があります。これらの設定の移行をAPI呼び出しで自動化する際には注意が必要です。これらの設定に関するガイダンスについては、トレンドマイクロ
サポートにお問い合わせください。
|
Trend Micro Vision One (XDR) の登録
Trend Micro Vision OneはWorkload Securityに含まれていますが、Workload Securityコンソールで有効にするには登録トークンが必要です。また、ポリシーやコンピュータ設定でアクティビティモニタリングを有効にすることもできます。詳細については、Workload SecurityとTrend Micro Vision Oneの統合を参照してください。
ネットワークと通信の設定
次の項目を評価します。
必要なポート、プロトコル、およびURL
Deep Security AgentとWorkload Security間のネットワーク通信は、AgentとDeep Security Manager間の通信とは異なります。インターネットへのアウトバウンドアクセスが制限されている環境では、いくつかのURLを特に許可する必要があります。完全なリストについては、ポート番号、URL、およびIPアドレスを参照してください。
プロキシ設定
エージェントがWorkload Securityサービスと通信するためのプロキシの設定に関する情報については、プロキシの設定を参照してください。
SOCKS4およびSOCKS5プロキシは、エージェント通信ではサポートされていません。エージェント通信にプロキシを使用する必要がある場合は、エージェントが Workload
Security サービスに対して有効化される前に、HTTPプロキシを実装します。
帯域幅の使用率
Deep Security Agentの配置に関するネットワーク計画を検討する際は、 エージェントのダウンロードと有効化、および継続的な操作とセキュリティパターンのアップデートの両方について、
エージェントの全体的なライフサイクルを考慮してください。
既存のDeep Security Agentを再インストールする必要はなく、Workload Securityサービスに再アクティブ化するだけで済みます。アクティベーションスクリプトを使用して行われる新しいデプロイメントでは、次の帯域幅使用量が予想されます:
-
エージェントのダウンロードとアクティベーション: Linuxでは5 MB、Windowsでは25 MB
-
初回セキュリティ更新のダウンロード: 50 MB Linux; 102 MB Windows
継続的なエージェントトラフィックは、検出アクティビティ、ポリシー設定、およびモジュールの使用状況によって大きく異なります。次のガイドラインに類似した、管理トラフィックのベースラインの使用を想定します。
-
セキュリティアップデート(毎日1回、 スマートスキャン オン):60MB
-
セキュリティアップデート(1日1回、 スマートスキャン オフ):120MB
-
ハートビートのオーバーヘッド: 1回のハートビートにつき40 KB。デフォルトの間隔は10分; エージェント1台あたり1日約5.7 MB
スマートスキャンの詳細については、Workload SecurityのSmart Protectionを参照してください。
ベースラインのトラフィックを超えると、エージェントが Workload Security および Vision One サービスと通信するため、検出が追加の帯域幅消費を引き起こします。これは予測が難しいですが、検出が少ない場合はエージェントごとに1時間あたり0.1
MB、検出率が高い場合はエージェントごとに1時間あたり最大3 MBの使用量を見込んでください。
Relay構成
ほとんどの場合、Workload Securityサービスによって提供されるRelayで十分です。いくつかのシナリオでは、Relayを使用することで操作が改善されることがあります。詳細については、Relayの動作および追加のRelayの展開を参照してください。
Deep Security APIと Workload Security APIを使用した移行
この記事および関連する記事では、 Deep Security Managerおよび Workload Security UIを使用して移行を実行する方法について説明します。APIを使用する場合:
-
一般的な要件とヒントについては、こちらの記事を参照してください。
-
API documentに従ってWorkload Securityリンクを作成してください。
-
次の情報については、Deep Security APIドキュメントを参照してください。
-
ポリシー移行ステータスを確認するには、HTTP GET 呼び出しを使用して
/policymigrationtasks/{taskID}からステータスを取得します。詳細については、Workload Security Automation Center を参照してください。
製品内の移行機能で現在サポートされていない項目は、通常、 Deep Securityと Workload Security APIの組み合わせを使用して移行し、 Deep
Security配置から関連する設定またはオブジェクトを読み取り、 Workload Security アカウントに書き込むことができます。 。
いくつかのアーティファクトは現在のAPIでは利用できませんが、従来のRESTおよびSOAP APIを介してアクセス可能であり、いくつかの機能はDeep Securityにのみ存在し、移行はサポートされていません。
Workload Securityでサポートされていない機能:
-
Deep Securityのマルチテナント設定は、
/tenantsAPIに従います。Trend Cloud Oneでの複数アカウント管理は従来のオンプレミスマルチテナントを上回り、これらの設定はWorkload Securityには適用されません。 -
VMware環境向けのAgentレス 保護
現在のAPIにないレガシーREST APIの機能:
-
ステータス監視
-
SAML設定
-
プロキシの設定、制御、および割り当て
-
イベントの取得
現在のAPIにないSOAP APIの機能:
-
プロキシの設定、制御、および割り当て
-
イベントの取得
-
処理(エージェントのアップデート、検索の実行など)
-
ルール設定
