本記事では、Trend Micro Deep Security（以下、Deep Security） をアップグレードする手順について前編と後編に分けて紹介します。後編ではDeep Security Virtual Appliance（以下、DSVA）のアップグレードから最後まで流れを記します。前編はこちらをご覧ください。また、本構成で扱うDeep Security の環境構築については導入編をご参照ください。
- アップグレード
アップグレード
Deep Security Vitural Appliance のアップグレード
DSVA のアップグレードは下記の流れで行います。
- 事前確認作業
- 仮想マシンの退避/ホストのメンテナンスモード実行
- DSVA 削除
- DSVA アップグレード（1台目）
- 仮想マシンの移行/正常性確認
- DSVA アップグレード（2台目）
- 正常性確認
本構成では、ESXi 2台で構成されるクラスタにて Guest Introspection（以下、GI） および DSVA を展開します。
事前確認作業
事前確認作業では、下記3項目を確認します。
- GI および DSVA のステータス
- DSVA 保護対象マシンのステータス
- アップグレード用ファイルがインポート済みであること
下図では、NSX より GI および DSVA のステータスを確認しています。インストールステータスが失敗となっている場合、事前に再展開をしておく必要があります。
仮想マシンの退避
保護対象マシンを、もう 1台のホストに退避します。
ホストのメンテナンスモード実行
ホスト上の保護対象マシン退避後に、ホストのメンテナンスモードを実行します。
その際、GI および DSVA は自動でシャットダウンされます。シャットダウン後、下図のようにインストールステータスは失敗となります。
DSVA 削除
停止状態の DSVA を削除します。[ディスクから削除]不可の場合、[インベントリから削除]の上データストア上からファイルを削除します。
DSVA アップグレード(1台目)
下図のように vCenter の[サービスの展開]にて、[解決]をクリックし、GI サービスを再展開します。このとき、ホストのメンテナンスモードが自動解除されます。再展開が完了し、ステータスが正常となることを確認します。DSVA も同様に再展開をします。
再展開された DSVA のバージョンを確認します。下図の[Virtual Applianceのバージョン]は組み込み Agent のバージョンを表し、[Appliance(SVM)のバージョン]は DSVA 自体のバージョンを表しています。
注意点として、NSX 環境では DSVA から Deep Security Manager（以下、DSM） への名前解決が必須です。 反対に、DSM から DSVA への名前解決は不要です。DNS サーバにて名前解決不可の場合、DSVA の hosts に DSM の情報を記載します。再展開時は hosts 情報等の設定は引き継がれないため、組込み Agent の自動アップグレードに失敗します。そのため hosts 追加後、組み込み Agent を手動アップグレードする必要があります。その際の手順は Deep Security Agent（以下、DSA） アップグレード時と同様です。
仮想マシンの移行
事前退避した保護対象マシンを、元のホストに戻します。この時、DSVA 11.0からDSVA 20.0による保護に切り替わります。
正常性確認
下記の 2項目を確認します。
- GI および DSVA のステータス
- DSVA 保護対象マシンのステータス
DSVA アップグレード(2台目)/正常性確認
1台目と同様の手順で実施します。
DSVA アップグレード時の注意点
事象：DSVA が新規バージョンでデプロイされない場合があります。
解決策：
- DSM 2台構成の場合、1号機と 2号機間で Appliance OVF ファイルの URL の切り替えを行います。
- DSVA のステータスが[失敗]となるため、再展開します。
※ DSVA は 2台とも再展開が必要なため、マシンの退避による片寄せアップグレードは不可です。コンバインモードを使用している場合、Agent 保護に切り替えることで保護を継続しながらアップグレードが可能です。一方、DSVA のみで管理している場合はアップグレード中は保護を無効化しておく必要があります。
DSVA アップグレード時の影響
新規 DSVA による保護への切り替え処理中（事前退避したマシンを元のホストに戻すタイミング）は、数分間 DSVA による保護が不可となります。
切り戻し方法
新規 DSVA を削除し、元のバージョンの DSVA を再展開します。
NSX-T 構築
NSX-T 構築は下記の流れで行います。
- NSX-T アプライアンスのデプロイ
- vCenter の登録
- NSX-T アプライアンス 2、3代目のデプロイ
- ファブリック設定
- IP アドレスプール設定
- セキュリティグループの作成
NSX-T アプライアンスのデプロイ
vSphere Client にて、 [OVF テンプレートのデプロイ]よりデプロイします。設定値等の詳細は割愛します。デプロイ完了後、ブラウザより下記 URL にてにて NSX Manager にログインします。
https ://<NSX-TのIP or FQDN>
vCenter の登録
コンピュートマネージャとして対象の vCenter Server を登録します。NSX-V と連携中でも登録することができます。
NSX-T アプライアンス 2,3台目のデプロイ
NSX-T は NSX Manager 3台によるクラスタ構成が推奨されています。そのため、下図のように NSX Manager 画面より、もう 2台の NSX-T アプライアンスのデプロイを実施します。クラスタ構成を組む場合は、クラスタ間で共有する仮想 IP を設定します。以降の作業はクラスタ IP に対し、ログインします。
ファブリック設定
DSVA 展開のために、配信対象の ESXi を NSX-T のトランスポートノードとして定義する必要があります。ホストに NSX のインストールをします。
また、トランスポートゾーン、トランスポートノードプロファイルの設定を行います。詳細な設定値は割愛します。
IP アドレスプール設定
TEP 用 IP アドレス、DSVA 用 IP アドレスをクラスタ内のホスト台数分用意します。
下図のように TEP 用 IP アドレスは、トランスポートノードプロファイルを作成する際に必要です。本構成のように評価版ライセンスでネットワーク機能を使用しない場合は、設定上必要なだけで通信は発生しないため適当な IP を使用できます。
セキュリティグループの作成
DSVA で保護するマシンを定義し、グループ化します。
下図では、[WinTESTDSVA]という文字列を名前に含む仮想マシンを対象に含める定義を設定しています。
NSX-V から NSX-T へ移行
NSX-T から NSX-T への移行は下記の流れで行います。
- 事前確認作業
- DSVA の無効化 / GI サービスの停止
- NSX-T のインストール
- DSVA および GI の削除
- Deep Security 移行
- NSX-V のアンインストール
- 正常性確認
事前確認作業
下記の 2項目を確認します。
- DSM および Deep Security Relay（以下、DSR） のステータス
- DSVA 管理対象マシンのステータス
DSVA の無効化
本構成ではコンバインモードのため、下図のように DSVA を無効化することで DSA による保護に切り替わります。メリットとして、保護を継続したまま移行が可能です。一方、DSVA のみで管理していた場合、マシン単位で無効化する必要があるため移行中は保護が不可となります。
GI サービスの停止
GI アプライアンスをシャットダウンします。切り戻しを考慮し、削除は行いません。
NSX-T のインストール
下図のように、DSVA 配信対象の ESXi に対し作成済みのトランスポートノードプロファイルをホストに適用することで、NSX-T の VIB をインストールします。
インストール後、[NSX 構成]が成功であること確認します。
DSVA および GI の削除
NSX-V より、DSVA と GI アプライアンスを削除します。
DeepSecurity 移行
DSM にて、下図のように NSX-V とのバインディングを削除します。NSX Manager から Deep Security 設定を削除不可のため、再バインディング（切り戻し）も不可です。
次に DSM にて、下図のように NSX-T に対するバインディングを追加します。[Managerのアドレス]では NSX のクラスタ IP を指定しています。
次に、下図のように NSX Manager より新規 DSVA を展開します。[サービスの展開]にて、vCenter、クラスタ、データストア、ネットワーク、を選択します。[展開の仕様]では、デプロイサイズを決めています。デプロイサイズは保護するマシンの数によって要件が異なります。また、[サービスセグメント]ではオーバーレイトランスポートゾーンを使用するサービスセグメントを事前に作成しています。
ネットワークの[詳細の編集]では下図のように、ネットワーク、ネットワークタイプ、IP プールを指定しています。
注意点として、DSVA から DSM への名前解決が不可の場合、展開後に組込み Agent の自動アップグレードに失敗します。そのため DSVA に DSM の hosts 追加後、組み込み Agent を手動アップグレードします。
サービスの展開完了後、サービスプロファイルおよびセキュリティポリシーを作成します。[ルール]を作成して使用するサービスプロファイルを指定し、セキュリティグループに割り当てます。
[サービスプロファイルの設定]にて、[パートナーサービス]にTrend Micro Deep Securityが確認でき、作成後[サービスプロファイルの状態]が成功となることを確認します。
DSVA 管理対象マシンを無効化し、再度有効化します。新しく展開された DSVA を適用するには、下図のようにマシンの再有効化が必要です。必要に応じてポリシーも再適用します。
DSVAによる保護の適用がされると下図のようAgentのみで機能していた保護がコンバージョンモードに変わっています。
NSX-V のアンインストール
下記 URL の vCenter の管理オブジェクトブラウザにログイン後、NSX-V のプラグインを削除します。
https ://＜vCenterのIP or FQDN＞/mob
次に、vCenter に SSH 接続し、対象の NSX-V のディレクトリを削除します。
vSphere Client サービスを再起動します。
NSX-V アプライアンスのシャットダウン後、削除します。
正常性確認
正常性確認は下記 2項目を確認します。
- DSM / DSR ステータス
- DSVA 管理対象マシンのステータス
NSX-V から NSX-T へ移行時の影響
DSVA 無効化時、DSA による保護への切り替え処理の数秒間は保護が不可となります。
DSVA 管理対象マシンを手動にて無効化している間、保護が不可となります。
切り戻し方法
Deep Security と NSX-V のバインディング削除前は、GI および DSVA を起動し、対象マシンを再度有効化します。一方、Deep Security と NSX-V のバインディング削除後は、早急な切り戻しは不可です。
コンバインモードを使用している場合、Agent による保護で一時的に代替運用可能です。一方、DSVA のみで管理している場合、問題解決まで保護不可です。NSX-V の再構築により元に戻すことは可能です。
vCenter と ESXi のアップグレード
vCenter Server 6.7 U2 → 7.0 U2へアップグレードします。
最後に、VMware vSphere ESXi 6.7 U2 → 7.0 U2へアップグレードします。
必要に応じて、ファームウェアおよびドライバのアップグレードを行います。
DSVA 配信対象ホストは、NSX-T の再インストールが必要です。
vCetner と ESXi のアップグレード詳細手順は割愛します。
以上が Deep Security のアップグレードでした。ご覧いただきありがとうございます。
