Cross-vCenter NSX 環境における Deep Security の構成ベストプラクティス

トレンドマイクロ VMware テクニカルアライアンス担当 栃沢です。

私の役割の 1つとして、お客様毎の VMware 仮想環境とお客様の要望に対して、Deep Security をどのように導入するのが最適かをご提案させていただく、というものがあります。

その中で 2018年にいくつかのお客様からご相談をいただいたのが、Cross-vCenter NSX 環境における Deep Security の導入についてでした。

データセンターが複数にまたがっている場合には、vCenter Server の Block もデータセンター毎に配置されることが多く、Cross-vCenter NSX を利用して仮想マシンの一元管理と障害時のスムーズなデータセンター間移行を実現したいというニーズが増えてきているようです。また、同一データセンター内でも管理上 vCenter Server を分けているケース（開発環境と本番環境の分割管理）もあり、運用フェーズに応じて仮想マシンを移行していきたいというケースもあるようです。

そこで今回は Cross-vCenter NSX 環境において Deep Security を導入する場合のユースケースをご紹介したいと思います。

Cross-vCenter NSX 環境について改めて整理してみる

まず、Cross-vCenter NSX 環境について改めて整理をしてみましょう。

• 同一の Platform Services Controller（PSC）配下に各データセンターの vCenter Server が配置され、各 vCenter Server が同一 SSO ドメインに属していること。
  （vSphere 6.7 の場合は、Embedded PSC もサポートされていますが、Deep Security との連携とは直接関係がないため、言及は割愛しています。）
• 各 vCenter Server で拡張リンクモード設定が行われていること。
  拡張リンクモードにより複数の vCenter Server Block のインベントリ情報を一元管理することができるようになります。
• Cross-vCenter NSX 設定により NSX サービスも vCenter Sever を跨いだクラスタで一元管理できること。
  Cross-vCenter NSX 設定時に vCenter Server に紐づく NSX Manager のどちらをプライマリロールとするかを選択する必要があります。
  ※ ネットワークの拡張においては、各 vCenter Server Block のクラスタ間のオーバレイネットワークが同一セグメントで拡張されるようにする必要があります。
  ※ 物理的にデータセンターが分かれている場合は、ユニバーサル分散論理スイッチを展開して L2 ネットワークを拡張する必要があります。同一データセンターで各 vCenter Server 配下のクラスタ上に展開されている分散スイッチ上のネットワークアドレス体系が同一の場合（同一のネットワークスイッチ群に接続されている）場合には、ユニバーサル論理スイッチの展開は不要となるでしょう。

Cross-vCenter NSX 環境における Deep Security 構成のベストプラクティス

ここからはサンプルのデータセンター構成（2つのデータセンターにそれぞれ vCenter Server、NSX Manager が構築されている Cross-vCenter NSX 環境）で Deep Security を導入する際のベストプラクティスを解説していきたいと思います。
Cross-vCenter NSX 環境で Deep Security を導入する場合には、プライマリとして動作するデータセンター（以下の図ではデータセンター A）に Deep Security Manager（DSM）を配置することを推奨します。

Cross-vCenter NSX 環境に限らず、Deep Security と VMware NSX との連携にあたっては DSM、vCenter Server、NSX Manager の連携が非常に重要となります。
以下のような三角形のようなイメージでのコネクションにより、インベントリ情報の共有、ポリシー連携などが実現されます。
（ポリシー連携の詳細については、第6回ブログをご参照ください。）Cross-vCenter NSX 環境で DSM を連携する際には、データセンター A の vCenter Server / NSX Manager、データセンター B の vCenter Server / NSX Manager それぞれと接続設定をする必要があります。（拡張リンクモードで接続されているとしても、DSM はあくまで vCenter Server Block がそれぞれ独立して存在するものとして連携します。）
連携設定後、DSM の管理コンソールからは vCenter Server Block が両サイト分表示されることになります。

サンプル構成のように、DSM を片方のサイトに設置して、両サイトの vCenter Server 配下の仮想マシンを統合的に保護することによって、データセンター A からデータセンター B へ vCente Server 跨ぎで Enhanced vMotion した場合でも自動的に Deep Security のセキュリティ保護を継続することができます。
実際には、Enhanced vMotion した際には移行先の vCenter Server 上では新たな仮想マシンが生成されたように見えるため、その仮想マシンに新たなUUID が付与されたと認識して、NSX セキュリティポリシーが自動的に適用されて、合わせて Deep Security ポリシーも有効化される動作となります。
（Deep SecurityのポリシーとNSXセキュリティポリシーの関係については、第6回ブログをご参照ください。）

ここで、「なぜ、DSM を vCenter Server と同様に両サイトに置かないのか？」という疑問が出てくることでしょう。
その理由は、DSM がその管理配下に入る Deep Security Agent（DSA）、Deep Security Virtual Appliance（DSVA）をどのように管理するかということに関係してきます。

Deep Security では DSA、DSVA の保護に問わず、仮想マシン毎に割り振るべきポリシーを管理しており、その仕組みに ”フィンガープリント” を利用しています。
DSA または DSVA の保護対象になる仮想マシンは、DSM の管理配下で有効化処理をされた時点で仮想マシン毎に固有のフィンガープリントを発行され、一意に管理されます。（コンバインモードで保護されている仮想マシンは、DSA と DSVA 双方のフィンガープリントを保持します。コンバインモードについての詳細は、第9回ブログをご参照ください。）フィンガープリントを保持することにより、対象の仮想マシンは必ず一意の DSM に紐づくことが保証され、vMotion などにより他の環境に移動した際にも、勝手に他の DSM の管理下に入ってしまうことを防ぐためにセキュリティ的なプロテクトをかけることができます。（フィンガープリントは、仮想マシンに対する無効化処理を行い、なおかつ、DSA の場合にはエージェントが保持しているフィンガープリントを手動でリセットしない限り削除されません。）

上記のように、Deep Security は VMware vSphere / VMware NSX の仕組みとは別に独自の仕組みによって、DSM と保護対象である仮想マシンをセキュリティ保護する DSA / DSVA との間で各仮想マシンを一意に管理しているため、Cross-vCenter NSX 環境で DSM を利用する場合には、DSM はどちらかのサイトにだけ配置して、各 vCenter Server、NSX Manager と連携をすることが運用面からも最適と考えられます。

vCenter Server Block に対応して DSM を配置した場合の留意点

もし、DSM をデータセンター B にも配置して、vCenter Server Block と対になる形で構成したい場合には、前述の通り、Deep Security は VMware vSphere / VMware NSX の仕組みとは別にフィンガープリントにより DSM と DSA が一意に紐づいていることから、Enhanced vMotion を実行する仮想マシンに DSA がインストールされている場合、移行先の vCenter Server 配下のクラスタで有効化されたとしても、DSA のフィンガープリントが移行元の DSM となっているため、正常に保護を行うことができなくなります。正常に有効化をするためには、Enhanced vMotion 実行後に DSA のリセット処理を行う必要があります。この処理は、仮想マシン上から手動にて実行する必要があります。

また、いくつかの機能については、DSM 側で情報を保持して機能を提供しているため、以下の制約が発生します。

• 各サイトにおいて、それぞれ同一の DSM 上のポリシー、vCenter Server / NSX Manager の NSX セキュリティポリシー / セキュリティグループを設定しておく必要がある。
• 推奨設定の検索の結果、変更監視のベースラインが移行元 DSM から移行先 DSM へ引き継がれない。（推奨設定の検索、ベースラインの新たに構築を実施する必要がある。）

Cross-vCenter NSX 環境で Deep Security 連携する場合の制約事項

ベストプラクティスに則った構成であっても、いくつかの制約事項があります。

• 移行元の vCenter Server 配下で DSA が有効化されていなかった仮想マシンが、Enhanced vMotion した場合には、移行先の vCenter Server で起動したタイミングで、DSA の有効化が自動的に行われます。（NSX セキュリティポリシーによって、新しい UUID を付与された仮想マシンが起動したと認識して、Deep Security ポリシーを含めたサービス適用を行うため。）
• DSVA で変更監視を行っている場合、変更監視のベースラインマッチングを行うエージェントデータベースを移行できないため、ベースラインを新たに構築する必要がある。

少し複雑な内容だったかもしれませんが、ご理解いただけましたでしょうか？
基本的には、以下の点を抑えて設計をいただければ、正しい設計をいただけるのではないかと思います。

• DSM は vCenter Server / NSX Manager とそれぞれの Block 毎に連携設定を行う。
• DSM と DSA / DSVA は仮想マシン毎にフィンガープリントによって一意に紐づいている。
• 構成に応じた制約事項、留意事項があることをあらかじめ理解しておく。

執筆者：
トレンドマイクロ株式会社
エンタープライズSE本部
セールスエンジニアリング部　サーバセキュリティチーム
シニアソリューションアーキテクト / VMware vExpert
栃沢 直樹（Tochizawa Naoki）

【VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化】

1. 1. Horizon インスタントクローンにも適用可能！仮想デスクトップ環境にフィットしたセキュリティ対策
   2. VMware NSX + Deep Secuirty連携によるエージェントレスセキュリティとは？
   3. VMware NSX + Deep Security連携にかかわるコンポーネントと基本構成
   4. VMware NSXとDeep Securityのユースケースと実現できることとは？
   5. エージェントレス型ウイルス対策のアーキテクチャ（１）
   6. エージェントレス型ウイルス対策のアーキテクチャ（２）
   7. エージェントレス型による侵入防御/Webレピュテーションの実装
   8. エージェント型とエージェントレス型の使い分けのポイント
   9. コンバインモードの正しい理解と知っておきたいこと
   10. エージェントレス型セキュリティ環境におけるWindows 10 Creators Updateの対応
   11. 分散ファイアウォールと連携したマルウェア検出時の自動隔離
   12. Cross-vCenter NSX 環境における Deep Security の構成ベストプラクティス

The post VMware NSXとTrend Micro Deep Securityで実現する仮想化セキュリティの最適化（１２） appeared first on Japan Cloud Infrastructure Blog.