本ヘルプセンターは英語版を翻訳したものです。また、一部には翻訳ソフトウエアにより機械的に翻訳した内容が含まれます。翻訳については順次対応しておりますが、最新の情報になっていない場合があります。最新の情報は英語版のページでご確認ください。表示言語は、画面右上の言語名をクリックして切り替えられます。

本ヘルプセンターの一部の記事には外部リンクが含まれています。万一リンク切れなどお気づきの点がございましたら、お手数ですが弊社サポート窓口までご連絡ください。

Deep SecurityからWorkload Securityへの移行

デプロイメントを Trend Micro Cloud One に移行する準備をしているDeep Security管理者- Workload Security は、移行を成功させるためのロードマップとして、この記事の手順を使用できます。

一般に、移行を成功させるための操作の順序は次のとおりです。

  1. Workload Security アカウント、ユーザー、ロール、および認証を設定する
  2. APIキーを作成する
  3. Workload Securityへのリンクを準備する
  4. ポリシーの移行
  5. 共通オブジェクトの移行
  6. クラウドアカウントを移行する
  7. エージェントの移行
  8. その他のDeep Security設定の移行
  9. ネットワークと通信の設定

Workload Security アカウント、ユーザー、ロール、および認証を設定する

Workload Security サービスを使用するには、 Trend Micro Cloud One アカウントが必要です。設定、ポリシー、またはコンピュータをサービスに移行する前にアカウントを設定します。

Trend Micro Cloud OneでのSAMLのサポートには、具体的には Workload Security と共通レベルの2つのレベルがあります。ここでは、 Deep Securityを Workload Securityに接続する方法について説明します。

Trend Micro Cloud One には2種類のアカウントがあります。2021年8月4日以降に作成された 新しいアカウント と、その日付以前に作成された 旧アカウント です。所有しているアカウントの種類がわからない場合は、Trend Micro Cloud Oneアカウントの変更を参照してください。

新しい Trend Micro Cloud One アカウントをお持ちの場合は、新しいIdentity and Access Managementシステムが用意されています。 Workload Securityへの移行時にユーザと役割を正しく管理する方法については、 Trend Micro Cloud One アカウントおよびユーザ管理ドキュメント を参照してください。

従来の Trend Micro Cloud One アカウントを使用している場合は、ユーザおよびロールの権限をDeep Securityの実装から Workload Securityの従来のアカウントに手動で移行する必要があります。従来のアカウントのユーザとロールの設定は、 Deep Securityソフトウェアの実装とほぼ同じで、既存の機能を複製します。

Deep Security ManagerでSAMLを使用している場合は、 Workload SecurityコンソールでSAMLを設定し、IDプロバイダにエクスポートされた適切なサービスプロバイダのメタデータをインポートして、認証と役割のマッピングを実行する必要があります。

ADFS経由でSAML経由で委任されないかぎり、認証のためのActive Directoryとの統合は Workload Security ではサポートされません。

APIキーを作成する

指示に従って のAPIキーを作成します。事前定義された役割「Deep Security Migration」をAPIキーに割り当てます(手順については、「 ユーザへのルールの割り当て」を参照してください)。「Deep Security Migration」の役割は、 Workload Security によって事前に設定および管理されており、エージェントまたはポリシーの移行を実行する権限があります。関連する権限は、追加の移行機能が実装されると、将来変更される可能性があります。

APIキーには「Full Access」の役割を割り当てないことを強くお勧めします。この役割は機能しますが、セキュリティ上の問題を引き起こします。

Workload Securityへのリンクを準備する

ユーザが Workload Security リンクを管理するには、役割の権限 Workload Security リンクの管理を許可する を割り当てる必要があります。

  1. Deep Security Managerコンソールの右上隅で、[サポート]→[Workload Securityへの移行] を選択します。

    [サポート]メニューが表示された[マネージャ]画面のスクリーンショット

  2. 表示されるWorkload Securityアカウントへのリンクページで:

    [Workload Security アカウントへのリンク]画面のスクリーンショット

    1. 前のセクションで作成したAPIキーを入力します。
    2. Workload Security アカウントがあるリージョンを選択します。
    3. [ 保存]を選択します。

    以前にDeep Securityと Workload Security の間の接続を設定していて、リンクを変更する場合は、リンクを変更する前に、以前の接続を使用するすべての移行関連タスクが完了していることを確認してください。そうしないと、予期しない動作が発生する可能性があります。

    Deep Security Managerの各テナントで許可される Workload Security リンクは1つだけです。

    Workload Security リンクの作成時に、 Deep Security Managerは Workload Security に接続してリンクを認証し、情報を取得します。Deep Security Managerのインストール時に Workload Security に接続するためにプロキシが必要な場合は、(https://workload.<region>.cloudone.trendmicro.com), Workload Securityのプロキシを設定します。

  3. [ 設定の移行 ]タブが選択された状態で、[ Workload Securityへの移行 ]画面が表示されます。

    ユーザがすべての移行タスクを処理できるようにするには、役割権限 Workload Securityへの移行を許可するが割り当てられている必要があります。

    移行設定タブ

次に、 ポリシーを Workload Securityに移行します。

----------------------------------------------------------------------------------------------------------------------------------------

その他のDeep Security設定の移行

次の項目をDeep Security環境で使用している場合は、それらを移行します。

VMwareコネクタとデータセンターゲートウェイ

VMware環境で実行されている仮想マシンでは、他のワークロードと同様に、エージェントを Workload Security サービスに配信して有効化できます。VMware vCenterに接続して仮想マシンのインベントリを取得する場合は、 Workload Security がvCenterと通信する必要があります。これは、データセンターゲートウェイを介して実行されます。データの設定とvCenterインベントリのインポートの手順については、「 Workload SecurityにVMware vCenterを追加する」を参照してください。

コンピュータグループとスマートフォルダ

コンピュータグループとスマートフォルダには、まだ直接移行する方法はありません。Deep SecurityとWorkload Securityコンピュータグループを一覧表示および作成するためのAPIがあるため、適切なAPI呼び出しをスクリプト化することで、多数のグループの移行を自動化できます。現在、スマートフォルダ用のAPIはないため、手動で再作成する必要があります。

プロキシ設定

現在、プロキシ設定をDeep Securityから Workload Securityに自動的に移行する方法はありません。「 プロキシの設定」の手順に従って、 Workload Security でエージェント通信のプロキシ設定を手動で設定できます。

Managerのプロキシは Workload Security サービスの一部であり、トレンドマイクロが管理しているため、プロキシを設定する必要はありません。

イベントとアラートのログ

Deep Securityと Workload Security の主な違いは、Manager内でのイベントデータとアラートデータの保持です。Workload Security は、セキュリティイベントを32日間、システムイベントを91日間保持します。イベントを長期間保持する必要がある場合は、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暗号化をサポートしていません。
  • syslogの代わりにAmazon SNSを使用します。「 Amazon SNSを設定する」を参照してください。

追加設定

システム設定、レポート、イベントベースタスクと予約タスク、タグ、バージョン管理、APIキーなど、その他の項目の設定は現在、自動移行機能の一部ではありません。Workload Securityで手動で再作成できます。これらの項目の多くは、 Deep Security APIと 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と Workload Security の間のネットワーク通信は、エージェントとDeep Security Managerの間の通信とは異なります。送信インターネットアクセスが制限されている環境で明確に許可する必要があるURLもいくつかあります。詳細なリストについては、「 ポート番号、URL、およびIPアドレス」を参照してください。

プロキシ設定

Workload Security サービスへのエージェント通信用のプロキシーの構成については、「 プロキシの設定」を参照してください。

SOCKS4およびSOCKS5プロキシは、エージェント通信ではサポートされていません。エージェント通信にプロキシを使用する必要がある場合は、エージェントが Workload Security サービスに対して有効化される前に、HTTPプロキシを実装します。

検索されたサイズ使用率

Deep Security Agentの配置に関するネットワーク計画を検討する際は、 エージェントのダウンロードと有効化、および継続的な操作とセキュリティパターンのアップデートの両方について、 エージェントの全体的なライフサイクルを考慮してください。

既存のDeep Security Agentを再インストールする必要はなく、 Workload Security サービスに対して再有効化するだけです。有効化スクリプトを使用して実行する新しい配信では、次の帯域幅の使用が想定されます。

  • エージェントのダウンロードと有効化:Linuxでは5MB、Windowsでは25MB
  • 初期セキュリティアップデートのダウンロード:Linux 50MB、Windows 102MB

継続的なエージェントトラフィックは、検出アクティビティ、ポリシー設定、およびモジュールの使用状況によって大きく異なります。次のガイドラインに類似した、管理トラフィックのベースラインの使用を想定します。

  • セキュリティアップデート(毎日1回、 スマートスキャン オン):60MB
  • セキュリティアップデート(1日1回、 スマートスキャン オフ):120MB
  • ハートビートのオーバーヘッド:ハートビートあたり40KB。初期設定の間隔は10分で、エージェントあたり1日あたり約5.7MBです。

詳細については、Workload SecurityのSmart Protectionを参照してください。

エージェントが Workload Security および Vision One サービスと通信する際、ベースライントラフィックを超えると、検出によって帯域幅の消費量が増加します。これを予測することは困難ですが、検出量が少ない場合は1時間あたり0.1 MB、検出率が高い場合はエージェントあたり最大2〜3 MBの範囲で使用することが予想されます。

Relay の設定

ほとんどの場合、 Workload Security サービスによって提供されるリレーで十分です。Relayを使用すると操作が向上する場合があります。詳細については、「 Relayの仕組み 」および「 追加のRelayの配置」を参照してください。

Deep Security APIと Workload Security APIを使用した移行

この記事および関連する記事では、 Deep Security Managerおよび Workload Security UIを使用して移行を実行する方法について説明します。APIを使用する場合:

製品内の移行機能で現在サポートされていない項目は、通常、 Deep Securityと Workload Security APIの組み合わせを使用して移行し、 Deep Security配置から関連する設定またはオブジェクトを読み取り、 Workload Security アカウントに書き込むことができます。 。

一部の項目は現在のAPIでは使用できませんが、従来のRESTおよびSOAP APIを介してアクセスできます。また、一部の機能はDeep Securityにのみ存在し、移行ではサポートされません。

Workload Securityでサポートされていない機能:

  • /tenants APIによるDeep Securityマルチテナント設定Trend Micro Cloud One の複数アカウント管理は、従来のオンプレミスマルチテナンシーに取って代わり、これらの設定は Workload Securityには適用されません。
  • VMware環境向けのAgentレス 保護

現在のAPIにないレガシーREST APIの機能:

  • ステータス監視
  • SAML設定
  • プロキシの設定、制御、および割り当て
  • イベントの取得

現在のAPIにないSOAP APIの機能:

  • プロキシの設定、制御、および割り当て
  • イベントの取得
  • 処理(エージェントのアップデート、検索の実行など)
  • ルール設定