本記事では、Trend Micro Deep Security（以下、Deep Security） をアップグレードする手順について前編と後編に分けて紹介します。本構成で扱うDeep Security の環境構築については導入編をご参照ください。
- アップグレードの例
- 事前確認事項
- アップグレード
アップグレードの例
お客様環境でのアップグレードの例
本記事では、実際のお客様環境の構成を基にアップグレード方法を記します。
・vCenter Server 6.5 U2 → (vCenter Server 6.7 U3) → vCenter Server 7.0 U2
・ESXi 6.5 U2 → (ESXi 6.7 U2) → ESXi 7.0 U2
・Deep Security 11.0 → Deep Security 20.0
※ 2台の Linux 仮想マシン上に Deep Security Manager（以下、DSM）および Deep Security Relay（以下、DSR）をインストールし、冗長化します。
・【移行】NSX-V 6.4.5(評価版ライセンス) → NSX-T 3.1.2 (評価版ライセンス)
※Deep Security Virtual Appliance（以下、DSVA）の展開に必要です。
事前確認事項
互換性
Deep Security でサポートされる ESXi と NSX のバージョンの組み合わせについては下記リンクをご参照ください。
VMware 製品同士の互換性については下記リンクをご参照ください。
Deep Security Agent（以下、DSA） / DSVA による保護がサポートされる仮想マシンの OS(Deep Security 20.0) については下記リンクをご参照ください。
help.deepsecurity.trendmicro.com
下記に本構築で参照した互換性の表をまとめました。
NSX-V から NSX-T に移行する際に vCenter および ESXi がバージョン 6.7でないと NSX-V と NSX-T の両方との互換性が取れないため、NSX と連携している vCenter および ESXi に関しては、一時的にバージョン 6.7を挟む必要あります。
Deep Security と NSX-V / NSX-T の互換性に関して、下記の表通りとなりますが ESXi のバージョンによってはサポートしない場合もあります。
DSVA の保護下にあり Guest Introspection（以下、GI） の機能を利用しているマシンがある場合は、VMware Tools と NSX の互換性の考慮が必要なため、場合によっては VMware Tools をアップグレードする必要があります。GI とは、DSVA による保護機能を利用するために、ESXi サーバーへのインストールが必要なコンポーネントです。
ESXi と vCenter の互換表
NSX と vCenter の互換表
NSX と ESXi の互換表
Deep Security(DSVA) と NSX の互換表
その他の事前確認事項
システム要件については下記リンクをご参照ください。
Deep Security 20.0の通信要件については下記リンクをご参照ください。
help.deepsecurity.trendmicro.com
リリースノートについては下記リンクをご参照ください。
help.deepsecurity.trendmicro.com
Deep Security 20.0の通信要件については下記リンクをご参照ください。
help.deepsecurity.trendmicro.com
アップグレード
アップグレードの流れ
- vCenter と ESXi のアップグレード(6.5 → 6.7)
- DSM & DSR のアップグレード
- DSA のアップグレード
- DSVA のアップグレード
- NSX-T 構築
- NSX-V → NSX-T への移行
- vCenter と ESXi のアップグレード(6.7→7.0)
上記が全体のアップグレードの流れです。ポイントとして、NSX 環境と連携している vCenter および ESXi は NSX-V と NSX-T をサポートさせるためにバーション 6.7にアップグレードします。 NSX と連携していない vCenter および ESXi が他にある場合は直接バージョン 7.0へアップグレードします。
アップグレード前の DSVA 11.0では NSX-T をサポートしないため、NSX の移行前にバーション 20.0へアップグレードします。
vCenter と ESXi のアップグレード
vCenter Server 6.5 U2 → 6.7 U3へアップグレード
vCenter が複数ある場合、NSX と連携している vCenter のみバーション 6.7のアップグレードを挟みます。それ以外に vCenter 環境がある場合は NSX 互換性考慮不要のためバーション 7.0にアップグレードします。
必要に応じてゲスト OS の VMware Tools をアップグレード後の vCenter および ESXi がサポートするバージョンにアップデートします。DSVA 管理マシンの場合、移行後の NSX-T がサポートするバージョンにアップデートします。
ESXi 6.5 U2 → 6.7 U2へアップグレード
DSVA 配信対象の ESXi ホストのみバーション6.7のアップグレードを挟みます。配信対象外の ESXi ホストは NSX 互換性考慮不要のためバーション 7.0にアップグレードします。必要に応じて、ファームウェアおよびドライバのアップグレードをします。
vCetner と ESXi のアップグレード詳細手順は割愛します。
Deep Security Manager ＆ Deep Security Relay のアップグレード
DSM と DSR のアップグレードの流れは下記の通りです。本構成では、DSM と DSR が同居且つ 2台による冗長構成となっています。
- 事前作業
- DSM アップグレード(1台目)
- アップグレード用ソフトウェアのインポート
- DSR アップグレード(1台目)
- 正常性確認
- DSM / DSR アップグレード(2台目)
- 正常性確認
事前作業
事前作業は下記の流れで行います。
- ステータス確認
- データベースバックアップの取得
- DSM サーバー上にアップグレード用のインストーラを配置
ステータス確認では、下記の 3項目でステータスがオンラインであることを確認します。
- [管理]>[Manager ノード]>[DSM]
- [管理]>[アップデート]>[Relay の管理]>[DSR]
- [コンピュータ]>[各管理対象マシンの詳細設定]
次に、データベースのバックアップを取得します。切り戻しおよびサポートへの問い合わせで必要となった場合の備えとなります。バックアップの方法はデータベースの種類によって異なりますが、本記事では詳細を割愛します。
最後に、DSM サーバー上にアップグレード用のインストーラを配置します。本構成では、OS が Linux のため WinSCP などのツールを利用して任意のフォルダに格納します。
DSM アップグレード(1台目)
1台目の DSM アップグレードは下記の流れで行います。
- アップグレード事前検証
- DSM 2台のうち、片方を停止
- アップグレード実行
- アップグレード完了後、Deep Security にログイン
本環境で DSM サーバの OS は RHEL 7を使用しています。アップグレード事前検証ではDSM サーバー上で下記のコマンドを実行します。結果は CSV ファイルとして出力されます。メモリ容量が不足している場合など、警告が表示されます。
#bash Manager-Linux-20.0.XXX.x64.sh –q –console -t
問題なくアップグレードできることを確認した後、DSM 2台の片方を停止します。両方のサーバーが起動状態の場合アップグレードに失敗するためです。DSM 停止後、下記コマンドでアップグレードを実行します。
#bash Manager-Linux-20.0.XXX.x64.sh –q –console
アップグレード完了後、ブラウザにて下記 URL にアクセスします。
https ://＜DSMサーバのIPまたはFQDN＞:4119
アップグレード用ソフトウェアのインポート
DSA(DSR)、DSVA のアップグレード用ファイルをインポートします。
DSA の場合
ダウンロードセンターから直接取得するか、コンピュータ上にダウンロードしたファイルをインポートします。最新バージョンを自動的にインポートすることも可能です。
DSVA の場合
ダウンロードセンターから取得不可のため、コンピュータ上にダウンロードしたファイルをインポートします。
DSR アップグレード(1台目)
Relay 導入済みマシン（本構成では DSM）を選択し、Agent のアップグレードを行います。保護マシンに対するセキュリティアップデート送信のため、Relay は必ずアップグレードしておく必要があります。
DSMにて、[コンピュータ]>[処理]>[Agent ソフトウェアのアップグレード]をクリックします。次に、[Agent ソフトウェアのアップグレード]にて Agent バージョンを確認し、最後にスケジュールが[NOW]であることを確認し[OK]で処理が開始されます。
正常性確認
1台目の DSM および Relay がアップグレードされていることを確認します。
事前作業時と同様に DSM と DSR のステータスを確認します。この段階では、2台目の DSM は停止中のためオフライン状態となっています。
DSM / DSR アップグレード(2台目) /正常性確認
2台目の DSM を起動し、1台目と同様の手順でアップグレードおよび正常性確認を行います。このとき、片方の DSM 停止は不要です。理由として、1台目のアップグレードで DB のスキーマアップグレードも完了済みのためです。これにより、2台目のアップグレード処理は短時間で完了します。
DSMアップグレード時の注意点
データベースとして Microsoft SQL Server を使用している場合、下記の TLS バーションの考慮が必要です。
- DSM 10.0以降の場合、TLS 1.2の使用が推奨されています。
- DSM 11.1以降を新規インストールする場合、DB が TLS 1.2をサポートすることが必須です。※ 10.0未満から 11.1以降にアップグレードする場合、TLS 1.2の使用は必須ではありません。
- DSM 20.0にアップグレードする場合、DB が TLS 1.2をサポートすることが必須です。
→SQL サーバを TLS 1.2をサポートするバージョン以上に、更新する必要があります。
DSMアップグレード時の影響
DSM 停止時も DSA および DSVA による保護は継続されます。停止中に発生したイベントは DSA および DSVA のローカルに保管され、復帰後 DSM へ送信されます。予約タスクの実行、ポリシーの配信・更新は不可です。
切り戻し方法
DB バックアップを使用したリストアを行います。ただし、リストア後に DSA や DSVA にて不整合が発生しオフラインとなる可能性があります。環境の規模によっては、問い合わせによるトライアンドエラーも選択肢の一つです。
Deep Security Agent のアップグレード
DSA アップグレードは下記の流れで行います。
- 事前確認作業
- DSA アップグレード
- 正常性確認
事前確認作業
事前確認作業では、DSM アップグレード時と同様に DSM、DSR のステータスを確認し、DSA 保護対象マシンのステータスを確認します。また、アップグレード用ファイルがインポート済みであることを確認します。
DSA アップグレード/正常性確認
DSR アップグレード時と同様に、DSA 保護対象マシンを選択し Agent ソフトウェア のアップグレードを実行します。正常性確認も DSR アップグレード時と同様です。
DSAアップグレード時の注意点
不正プログラム対策機能を利用する Windows 版 DSA の場合、証明書の更新が必要です。
インターネット接続可能且つ証明書の自動更新が有効になっていない場合、アップグレードに失敗します。
上記条件を満たしている場合でも、FW 等で制限がかかっている可能性あるため事前に証明書の手動インポートが必要となります。下記 URL から取得できます。
DSAアップグレード時の影響
Agent アップグレード中は、Agent による対象マシンの保護が数秒間程度不可となります。Windows マシンの場合、DSA 20.0へのアップグレードでは OS 再起動が不要なドライバ設計がされていますが、他の要員で必要になる可能性があります。
切り戻し方法
DSA をアンインストールし、元のバージョンの DSA を再インストールします。この際、Windows マシンの場合は再起動が必要です。Linux マシンの場合は再起動は不要です。
前編はここまでです。ご覧いただきありがとうございます。後編では、DSVA のアップグレードから最後まで記していますのでご参照ください。
