Home > Blogs > Japan Cloud Infrastructure Blog > 作成者別アーカイブ: Akira Kitamura

作成者別アーカイブ: Akira Kitamura

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

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

 

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

分散ファイアウォールと連携したマルウェア検出時の自動隔離

 

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

少し間が空いてしまいましたが、今回は Deep Security がマルウェアを検出した際に VMware NSX の分散ファイアウォールと連携して該当の VM を自動隔離する仕組みについてご紹介します。この連携はここ最近特に VMware Horizon の導入を検討されているお客様の多くでご利用をご要望されることが多いソリューションです。
ランサムウェアや標的型サイバー攻撃に対する対策の強化にあたり、インシデントが発生した段階でいち早く一次対処が可能となる点が採用のポイントになっています。

NSX 分散ファイアウォールによってユーザが利用する仮想デスクトップ環境のマイクロセグメンテーションを実装しておくだけでも、ランサムウェアや標的型サイバー攻撃の初期段階でよく見られる「横感染/拡散」を抑制することはできますが、さらに自動隔離を実装しておくことによって管理者の手を煩わせることなく感染した仮想デスクトップ(以下 VM)をネットワークから切り離すことが可能となります。また、あくまでこの「自動隔離」はハイパーバイザ上でのアクセス制御ポリシーによって行われますので、VM 側の vNIC には直接影響を与えないことも特徴です(ネットワークアドレスの変更や vNIC のステータスには変更はありません。)

以下にマルウェア検出時の自動隔離の仕組みと実装のポイントについて解説していきます。

 

Trend Micro Deep Security と NSX 分散ファイアウォールの連携イメージ

最初に Deep Security と分散ファイアウォールがどのように連携をするかのイメージを見ていきましょう。

  1. Deep Security Virtual Appliance(以下 DSVA)にて VM 上でのマルウェアを検出。DSVA からDeep Security Manager(以下 DSM)に不正プログラム対策イベントを検出
  2. DSM が不正プログラム対策イベントの検出をトリガーとして、NSX Manager に対して該当のVM への NSX セキュリティタグ情報を送信
  3. 該当の VM に対して NSX セキュリティタグが付与されることにより、予め設定されていた VM の NSX セキュリティグループが変更されることによって適用されるファイアウォールポリシーが変更されて、ネットワークアクセスが制限される

マルウェアを検出して NSX セキュリティタグを付与するまでは Deep Security の役割、実際の VM のアクセス制御を行うのは VMware NSX の役割となります。また、NSX セキュリティタグが付与された VM は vCenter 上からも確認することが可能です。

 

自動隔離を実現するために必要な設定

マルウェア検出時に設定しておくべきポイントは大きく以下の 3つがあります。

  • NSX セキュリティグループの作成
  • NSX 分散ファイアウォールの設定
  • Deep Security での NSX セキュリティタグ付与の設定

ここではすでに VMware NSX と Deep Security のエージェントレス型セキュリティ対策に必要な設定は完了している前提で上記の3つのポイントについて解説していきます。詳細の設定手順を確認したい方は、以下のインテグレーションガイドを参照してください。

VMware NSX & Trend Micro Deep Security インテグレーションガイド
<ダウンロード先>
Trend Micro Deep Security サポートウェブ
VMware テクニカルリソースセンター

 

【NSX セキュリティグループの作成】

エージェントレス型セキュリティ対策の実装が完了していれば、VM をグルーピングするためのセキュリティグループの設定はすでに行われているはずですが、以下の設定を加えておく必要があります。

  1. 通常運用時に所属しているセキュリティグループに対する NSX セキュリティタグが付与された VM を除外する設定の追加
  2. NSX セキュリティタグが付与された VM が所属するセキュリティグループの作成

NSX セキュリティグループの特性として、同一 VM が複数のセキュリティグループに参加することができてしまうため、1. 側で除外設定をしておかないと NSX セキュリティタグが付与された際に両方のグループに所属することになり、正しく隔離動作が行われなくなります。
また、2. の隔離用のセキュリティグループは正常時は VM が所属しないグループとなります。(設定の方法は上記に限らず設定はできると思いますので、環境に合わせて設定をしていただければと思います。)

 

【NSX 分散ファイアウォールの設定】

実際にマルウェアを検出した際に自動隔離するためには、先ほど設定をしたセキュリティグループを利用して隔離用のファィアウォールルールを作成する必要があります。
ここで、分散ファィアウォールにおけるセキュリティポリシー、グループの関係を整理しておきましょう。

分散ファイアウォールの設定は通常のネットワーク型ファィアウォールと同様で、送信元や送信先を IP アドレス(または IP アドレス)以外の仮想マシンやセキュリティグループなどをオブジェクトとして利用することでよりシンプルなルール設定が可能となっています。
実際には以下のようなファィアウォールルールを設定することになります。

この例ではルール ID #4/#5 に隔離用グループのアクセス制御ルールを記載しており、Incoming、Outgoing の通信を完全に遮断する形となっています。運用要件に応じて、隔離時にも通信が必要なトラフィックがある場合には適宜ルールをカスタマイズ、追加して対応することができます。特に VMware Horizon 環境の場合、Horizon Connection Server とのコネクションが切断されてしまうことで隔離した VM が削除されてしまうことがあり、そういった際には隔離グループと Horizon Connection Server との通信を許可するルールを設定しておくことも有効です。

また、自動隔離とは直接関係はしませんが、仮想デスクトップ環境において利用する場合、現在のクライアント PC に導入されるアプリケーションの多くは、サーバとの通信を行うのがほとんどで、クライアント間の Peer to Peer の通信が必要なことはありません。クライアント環境の脅威で特に留意が必要なランサムウェア感染時の横拡散や標的型サイバー攻撃の着弾を受けたクライアントからの攻撃者の探索活動に対しては、ルールID #3 のような仮想デスクトップ間の通信をブロックするルールを設定しておくことで被害の拡大を抑制することが可能となります。IP アドレスベースではなく、セキュリティグループをファイアウォールルールのオブジェクトとして指定できることで同一ネットワークにある仮想デスクトップ同士でも必要なセキュリティポリシーを柔軟に適用できるところは NSX 分散ファイアウォール活用の大きなメリットではないかと思います。

 

【Deep Security での NSX セキュリティタグ付与の設定】

あとは Deep Security 側で不正プログラム対策イベントが検出された際に NSX セキュリティタグを NSX Manager へ送信するために必要を設定しておく必要があります。
DSM のコンソールにアクセスをして、自動隔離を行いたい VM(正確には自動隔離を行いたい NSX セキュリティグループに割り当てた NSX セキュリティポリシー)に紐づく Deep Security ポリシーを選択します。

不正プログラム対策の[詳細]タブより、NSX セキュリティのタグ付けを有効化する設定を行います。
NSX セキュリティタグはすでに用意されている 3つのタグのうちどれを利用していただいても問題ありません。(high / medium / low のどれを選択しても挙動は一緒です。)
また、自動隔離された後に、フル検索を手動で実施した際に新たなウイルスを検出しなかった場合に NSX セキュリティタグを自動的に削除(隔離グループから通常のグループへの復帰)したい場合には、[この後の不正プログラム対策が不正プログラム検出イベントが生成されずに完了した場合、以前に適用された NSX セキュリティタグは削除されます。]にチェックボックスを入れてください。(もちろん、vCenter から該当 VM の NSX セキュリティタグを手動で外すことも可能です。)

また、DSM と DSVA との間ではデフォルト 10分に 1回のハートビートで相互の状態確認を行っています。不正プログラム対策イベントはハートビートのタイミングで DSVA から DSM へ通知されるため、このままだと感染検出時に即時に隔離を行うことができません。そのために、DSVA がホスト上の VM で不正プログラム対策イベントを検出した場合に、ハートビートのタイミングを問わず、即時に DSM にイベントを通知する設定を行う必要があります。
この設定は DSM のコンソールから設定はできないため、OS上でコマンド実行を行っていただく必要があります。(以下は Windows OS で DSM を構築した場合のコマンド例)

DSM のプロセスの再起動が発生します。
また、DSVA に設定を反映することが必要なため、この後に必ず DSVA に対するポリシーの再配信を行ってください。(設定反映のためのポリシー配信のため、各 VM に対するポリシー配信ではないことを注意)

上記の一連の設定を完了すれば、Deep Security の不正プログラム対策イベントを起点とした自動隔離を行うことができるようになります。

 

 

まとめ

いかがでしたでしょうか。
Deep Security と VMware NSX の連携は単純にエージェントレスでのセキュリティ対策を実現するだけではなく、インシデント発生時のオペレーションの自動化を図るためにも利用することができます。本編でも記載をしましたが、NSX 分散ファイアウォールをうまく利用することで通常時でもランサムウェアの拡散や標的型サイバーいかがでしたでしょうか攻撃着弾時の横感染のリスクを低減できますし、いざとなったときにさらに強固な隔離用ファイアウォールルールを自動適用することができます。
みなさんが当たり前に使っているファイアウォール、ウイルス対策ですが、Deep Security とVMware NSX の連携をうまく活用していただくことでセキュリティレベルの向上の運用性の向上の両立を図っていただけるのではないかと思います。
ぜひ、お試しください!

 

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネスSE部 パートナーSE2課
栃沢 直樹(Tochizawa Naoki)

 

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

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

 

VMware Cloud on AWS 環境も Trend Micro Deep Security で守ることができるんです!

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

2018年11月に VMware Cloud on AWS が東京リージョンでリリースをされました。
VMware Cloud on AWS のリリースにより、従来オンプレミス環境で vSphere を採用していたユーザはよりパブリッククラウドとの連携を生かした運用を実現する道が開けてきたと思います。
パブリッククラウドの活用にあたってもセキュリティ要素の検討は必ず必要となり、従来のセキュリティ対策との兼ね合いも気になるところでしょう。

トレンドマイクロはすでに VMware Cloud on AWS のユーザとして、当社のサーバセキュリティ製品である Deep Security での連携などをすでに進めています。
今回は VMware Cloud on AWS 環境に対して Deep Security がどのような連携が可能になっているかをご紹介します。
今回ご紹介するこのブログの内容は、トレンドマイクロの VMware マイクロサイトにも転載されています。

 

マルチクラウド環境に対する Deep Security の位置づけ

Deep Security は統合サーバセキュリティ製品として多くのお客様にご利用をいただいていますが、物理、仮想化環境だけではなくパブリッククラウド、コンテナサービス、サーバレスも含めたマルチクラウド環境への対応を日々目指して開発を継続しています。

 

そして、Deep Security はシングルコンソールでオンプレミス環境とクラウド環境を一元管理できる仕組みを提供しています。
これによりインフラ環境を問わずにセキュリティレベルを統一していくことが容易となると同時に仮想マシン、インスタンスの新規デプロイ、移行にもシームレスに対応することが可能です。

 

VMware Cloud on AWS 環境における Deep Security の連携

VMware Cloud on AWS 環境においても Deep Security を連携することが可能になっています。Deep Security Manager(以下DSM)が vCenter Server と連携する仕組みを利用することによってオンプレミスの vCenter ServerVMware Cloud on AWS の vCenter サービスと連携をしてインスタンス情報をリアルタイムに同期します。また、現時点(2018年12月時点)では、VMware Cloud on AWS 上で利用できる保護モジュールは Deep Security Agent(以下DSA)のみとなります。

 

実際にどのような手順で連携をすればよいかを順を追って解説します。

VMware Cloud on AWS vCenter への接続準備

  1. VMware Cloud on AWS コンソール画面から展開する SDDC を選択して、“OPEN VCENTER” をクリック
  2. vCenter へのアクセスを許可するための Management Gateway に対するインターネット経由での Firewall アクセスルール、または、オンプレミス環境からの VPN アクセス(vCenter への HTTPS(TCP443)を許可)が設定されていれば連携可能
    DSMとvCenter の連携についてもこのポートを利用します。(DSM から vCenter へ HTTPS セッションを利用してリアルタイムに情報連携)○Firewall ルール例

VMware Cloud on AWS vCenter と DSM の連携設定

  1. DSM にアクセスして、[コンピュータ]画面から ”VMware vCenterの追加” を選択
    オンプレミスの vCenter Server との接続設定と同様の設定を行います。
  2. vCenter の Administrator 権限を持つアカウントでアクセス設定
    vCenter とのアクセス情報を入力して “次へ” に進むと vCenter へのテストアクセスが実行されます。アクセスができない場合にはエラーとなり、次の設定画面に進めません。
    NSX Manager の設定画面はスキップして “次へ” に進みます。
  3. vCenter からデータセンター配下のホスト、仮想マシン情報が取得されていることを確認して “完了” をクリック
  4. オンプレミスの vCenter とともに VMware Cloud on AWS のリソース情報が一元管理できていることを確認。

 

 

このように Deep Security を利用することによって、オンプレミスも VMware Cloud on AWS の双方の仮想マシンを統合管理し、同一のセキュリティポリシーを適用することが可能になります。
(そのほかにも AWS マネジメントコンソール、Azure ポータルと連携することも可能です。)
マルチクラウド環境への移行が進むにつれて、仮想マシンがどういった環境にあるかに問わず、統一したセキュリティを担保するためには、セキュリティツールがインフラ環境にリアルタイムに連携できることが大前提となります。
そしてリアルタイムに連携できることで、仮想マシンの増減に対しても Deep Security 側で登録を行わなくてもシームレスにセキュリティの適用が可能となり、セキュリティの適用を忘れてしまう、ということも避けられます。
ぜひ、皆さんの環境でもオンプレミスの vCenter、VMware Cloud on AWS の vCenter と Deep Security を連携してみてください。きっと有効性を体感していただけると思います。

 

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネスSE部 パートナーSE2課
栃沢 直樹(Tochizawa Naoki)

 

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

エージェントレス型セキュリティ環境におけるWindows 10 Creators Updateの対応

 

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

Windows 10環境への移行が進む中でWindows 10 Creators Updateへの対応についてご質問を頂くことが多くなってきております。
仮想デスクトップ環境では、Creators Updateがリリースされた場合にVMware vSphereVMware NSXVMware Horizon、VMware Toolsを確認する必要があります。そして、エージェントレス型セキュリティ対策ではさらにDeep Security Virtual Appliance(DSVA)との互換性を意識していく必要があります。今回は各ソリューションが互換性の面でどのような関係性があり、どのようなポイントを確認していけばよいか、順を追って解説したいと思います。

 

仮想マシンOSがVMware仮想環境で利用できるか確認するポイント

仮想マシンにはポップアップツールであるNotifierを除いてセキュリティ機能を提供するDeep Securityのコンポーネントは導入されません。DSVAによるエージェントレス型セキュリティを提供するためには、仮想マシン側にVMware Tools のVMCIドライバに含まれるNSXファイル自己検証ドライバ(vsepflt)を導入しておく必要があり、NSXファイル自己検証ドライバがフックする情報を基に不正プログラム対策などの機能を提供しています。
詳細は第5回ブログをご覧ください。

VMwareの仮想環境上でどのWindows OSが利用できるかを確認するためには、VMware Tools とOSの互換性をチェックする必要があります。
確認のポイントは以下の2つです。

1) 仮想マシンに導入するOSがVMware Toolsに対応しているかを確認する
 VMware Compatibility Guide にて確認することができます。

2) VMware Toolsが利用を予定している vSphere / NSX に対応しているかを確認する
 VMware Product Interoperability Matrices にて確認することができます。

ここでのポイントは、該当するWindows OSがサポートするVMware Toolsを確認し、VMware Toolsが利用可能なvSphereNSXの組み合わせを把握する、という点です。この組み合わせ(=互換性)が満たされていないとVMwareのサポートを受けられなくなる可能性がありますので、必ずチェックをしましょう。

 

エージェントレス型セキュリティ提供可否を確認するためのDSVA互換性チェック

導入する仮想環境のバージョンが確認できたら、その環境でDSVAが利用可能かを確認します。
DSVAの互換性は、vSphere及びNSXのバージョンに依存します。VMware Toolsとは直接の互換性を持っていません。また、仮想デスクトップ環境において利用されるHorizonとも依存関係はないので意識する必要はありません(もう少し踏み込むとvCenter Server、NSX ManagerがDeep Security Managerと連携できれば、仮想デスクトップ展開ソフトウェアは意識しない)。
以下のサイトにてDSVAがvSphere及びNSXのどのバージョンと互換性があることをDeep Securityのバージョン毎に確認することができます。

Deep Security and VMware compatibility matrix

 

DSVA利用時のWindows 10 Creators Update の対応について

ここまでの解説を見てお分かりいただけたかと思いますが、DSVA環境における利用可能なOSは直接的にはVMware Toolsのバージョンに依存します。VMware Toolsについては、仮想マシンのOS種別単位で対応が定義されており、Windows 10のCreators Update(RS3、RS4など)のサービスオプションごとの互換性を意識する必要はありません。 対応OSについては、VMware Toolsのリリースノートを参照してください。

 

[参考情報]VMware HorizonのWindows10のサポート

DSVAとの互換性とは直接関係ありませんが、Horizonによる仮想デスクトップ環境の導入の際にはOSがどのようにサポートしているかを確認する必要があり、よくご質問をいただきますので、その情報もここでご案内しておきたいと思います。

以下のKBにはHorizonのWindows 10のサポートバージョンが記載されていますが、あくまでHorizonの互換性であり、VMware Toolsの対応バージョンは考慮されていませんので上記の互換性の確認を行って対応OSの確認をする必要があります。
https://kb.vmware.com/s/article/2149393

また、Horizon環境のサポートポリシーとして、Windows10サービスオプションが「対象(Targeted)」となっているバージョンについてはTech Preview Supportということで上記KBでもサポートされないステータスとして管理されています。
Microsoftが公開しているWindowsのリリース情報も適宜確認するようにしましょう。
https://www.microsoft.com/ja-jp/itpro/windows-10/release-information

 

まとめ

仮想マシンのOSの利用できる環境を確認する方法についてご理解いただけたでしょうか?
簡単な互換性の関係をまとめると以下のようになります。

Windows 10を例にここではお話してきましたが、レガシーOS(Windows Server 2003など)の対応も同様に確認することができます。
ただし、VMware、トレンドマイクロそれぞれでレガシーサポートの対応について定義しておりますので、必ずサポートの可否、対応条件および制限事項について事前に確認するようにしましょう。

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネスSE部 パートナーSE2課
栃沢 直樹(Tochizawa Naoki)

 

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

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

 

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

コンバインモードの正しい理解と知っておきたいこと

 

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

前回、DSVADSAの使い分けについて解説をしましたが、Deep Security Virtual ApplianceDSVA)で保護しているESXiホスト上にDeep Security Agent(DSA)がインストールされたWindows仮想マシンが配置された場合、Deep Securityでは“コンバインモード”というモードで動作します。
コンバインモードについては、誤解しやすい点もあるので、今回はその正しい理解と抑えておいていただきたい点をまとめてお伝えしたいと思います。

 

コンバインモードの有効化と状態

前回のブログにも書きましたが、コンバインモードが有効化されるのはWindows仮想マシンのみとなります。
コンバインモードを有効にするために必要な設定は特段ありません。対象の仮想マシンが DSVA で保護可能な状態になっており、かつDSA がインストールされていると自動的にコンバインモードによる保護が有効になります。そして、コンバインモードが有効になるのはWindows OSのみです。(前回も解説しましたが、設定が特に必要ないという点では、DSAをインストールしたLinux OSをDSVAが稼動しているESXiホスト上で動作させる際にDSAでの保護が自動的に継続されることと共通しています。詳細は前回ブログをご確認ください。)

コンバインモードで動作していることは、Deep Security ManagerDSM)コンソール、DSAがインストールされたWindows OSのタスクトレイから確認することができます。

Deep Security Managerコンソール

■Deep Security Agentタスクトレイ

 

コンバインモードのアフィニティルール

コンバインモードでは、機能群ごとにDSA、DSVAどちらの防御コンポーネントで保護を実施するか(保護ソース)選択できるようになっています。
デフォルトでは以下のように動作するように設定されています。

  • 不正プログラム対策                 Appliance優先
  • Web レピュテーション/ファイアウォール/侵入防御   Agent優先
  • 変更監視                      Appliance優先

DSVAで対応していない機能であるセキュリティログ監視、アプリケーションコントロールは、DSAでの保護となるためコンバインモードのアフィニティルールの設定項目はありません。
また、コンバインモードはDeep Security 9.6から実装された機能ですが、アフィニティルールをデフォルトの設定から変更できるのはDeep Security 10.0以降になります。

機能群毎に選択できるコンポーネントの保護ソースの選択には以下の4つがあります。

  • Appliance 優先 : Appliance 有効化不可時に Agent にてセキュリティ機能を提供
  • Agent優先   : Agent 有効化不可時に Appliance にてセキュリティ機能を提供
  • Appliance のみ : Appliance 有効化不可時に Agent でのセキュリティ機能の移行を行わない
  • Agentのみ   : Agent 有効化不可時に Appliance でのセキュリティ機能の移行を行わない

このアフィニティルールの設定は、利用したい機能と仮想マシンに対するDeep Securityの機能利用による負荷を考慮して適宜変更することが可能です。

 

コンバインモードの保護ソースの変更のトリガー

Appliance優先、Agent優先を選択した場合、選択された保護ソース(DSVAまたはDSA)が無効化された場合に、もう一方の保護ソース(DSAまたはDSVA)に保護機能を移行するためのDSMからポリシーの配信が実行され、保護ソースが変更されます。各機能のステータスにエラーがあった場合などに保護ソースが変更されるようなフェイルオーバー(エラーに備えた冗長化)には対応していませんので、留意してください。

 

コンバインモード利用にあたって知っておくべきこと

コンバインモードの利用にあたって、知っておいて頂きたい点をいくつか挙げておきたいと思います。

  • Appliance優先、Agent優先を選択した場合、前述のとおりDSMからのポリシー配信が実行されます。Appliance優先でAgentに保護ソースが切り替わった場合、該当の機能モジュールがインストールされていない場合、機能モジュールのインストールが行われた後、ポリシーの配信が行われます。コンバインモードの保護ソース変更時にモジュールの自動インストールをさせたくない場合にはあらかじめ機能モジュールをインストールしておくか、Applianceのみを選択する必要があります。
  • コンバインモードでは、DSVA による保護を仮想マシン単位で無効化することはできません。
  • Deep Security Virtual ApplianceのCPU課金、かつ、侵入防御・ファイアウォール・Webレピュテーションを利用できるライセンスをご購入いただいている場合に限り、DSAで上記の機能を実装することが許諾されています。(vShield Endpoint環境でDSVAを利用していた場合に利用できた機能をDSAにて補完するための措置)ライセンスの詳細はこちらをご覧ください。

まとめ ~ DSVAとDSAを使い分ける上でのポイント

コンバインモードについてご理解をいただけたでしょうか?
少し複雑な部分もありますが、ポイントを抑えてコンバインモードもうまく活用を頂ければと思っております。
コンバインモードについてはこちらのFAQにも記載されておりますので、ご参照ください。

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネスSE部 パートナーSE2課
栃沢 直樹(Tochizawa Naoki)

 

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

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

 

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

エージェント型とエージェントレス型の使い分けのポイント

 

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

前回までエージェントレス型セキュリティ対策を提供するDSVAでウイルス対策、侵入防御をどのような仕組みで提供しているかを解説してきました。
Deep Securityにはエージェントによるセキュリティ保護も可能ですが、うまく使い分けて頂くことでよりセキュアなインフラ環境を構築することが可能です。
今回はこれからDeep Securityの導入を検討している、またはこれから実装する!といった皆様に向けて、エージェントレス型のDeep Security Virtual Appliance(DSVA)とエージェント型Deep Security Agent(DSA)の使い分け、組み合わせのポイントを解説していきたいと思います。

 

DSVA/DSAで提供できる機能の違い

まずは、DSVAとDSAで提供できる機能について見てみましょう。

※GI:VMware NSX にてGuest Introspectionが有効である必要がある機能
※NI:VMware NSX にてNetwork Introspectionが有効である必要がある機能
※OSのバージョン、ディストリビューション毎の対応状況の詳細については、Supported features by platformをご確認ください。

詳細部分で機能、OS毎に対応できる内容に差異がありますが、大枠は上記で確認を頂けると思いますが、特に以下の点は見落としがちな内容ですので、留意してください。

  • DSVAによる推奨設定の検索は、Guest Introspectionが有効である必要がありますので、Linux OSの仮想マシンで侵入防御機能を利用する場合には利用できません。推奨設定の検索を利用する場合にはDSAが必要となります。
  • Webレピュテーションはネットワーク系のプロセスで処理を行うため、DSVA環境ではNetwork Introspectionを有効にする必要があります。
    (Deep Security Virtual Appliance ウイルス対策では不正プログラム対策とWebレピュテーションが利用できますが、Network Introspectionが利用できるVMware NSXライセンスが必要になります。)

 

DSVAとDSAを組み合わせて利用もできる

DSVAはVMware vSphere/VMware NSXと連携をしてセキュリティ機能を提供していますが、DSVAで保護しているESXiホスト上にDSAが導入された仮想マシンを稼動させることも可能です。
Windows系仮想マシンとLinux系仮想マシンでは動作仕様が異なります。

  1. Linux OSの場合
    DSVAによる保護は行われず、DSAがすべてのセキュリティ機能を提供します。(DSVAが稼動するESXiホスト上で、DSAがすべてのセキュリティ機能を提供)

  1. Windows OSの場合
    DSVAとDSAで予め決められたルール(アフィニティルール)に従って、保護機能を分担してセキュリティ機能を提供します。これをコンバインモードといいます。コンバインモードについては次回詳しく解説します。

上記のようにDSVAとDSAが混在した環境でも利用することができるため、サーバ環境で複数の機能を利用したい場合でも柔軟に設計することが可能です。

 

まとめ ~ DSVAとDSAを使い分ける上でのポイント
DSVAとDSAの機能の違いとESXiホスト上での基本的な動作仕様を踏まえて、導入されるケースとして多い組み合わせをいくつかご紹介しておきます。

  • 仮想デスクトップ環境でWindows OSを展開してウイルス対策を行いたい場合にDSVAを利用する。(Webレピュテーションを利用する場合にはVMware NSXでNetwork Introspectionを有効化する必要あり)
  • LinuxサーバとWindowsサーバが混在する、またはWindowsサーバが大多数を占める環境において、Windowsサーバは機能に応じてDSVA、LinuxサーバはDSAにて保護する。
  • セキュリティログ監視、アプリケーションコントロールが利用したいユーザでサーバ環境を全面的にDSAで保護する。実際にはシステム環境に応じてさまざまなケースがあると思いますが、DSVA/DSAそれぞれでできることを理解頂きながら、うまく使い分けて頂ければと思います。

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネスSE部 パートナーSE2課
栃沢 直樹(Tochizawa Naoki)

 

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

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

 

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

エージェントレス型による侵入防御/Webレピュテーションの実装

 

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

前回はエージェントレス型ウイルス対策を実現するために必要となるVMware NSXのサービス設定とDeep Securityとの連携について解説を行いました。
この連携を行うことで、ウイルス対策以外にも侵入防御(IDS/IPS)、Webレピュテーションなどの機能をエージェントレスで提供することも可能となります。
ウイルス対策は仮想マシン上でアクセス(読み取り/書き込み/コピーなど)をした「ファイル」に対して処理を行っています。一方、Deep Securityにおける侵入防御、Webレピュテーションは仮想マシンが送受信する「パケット」に含まれる情報に対して処理を行っており、ウイルス対策などの「ファイル」に対する処理とは異なる仕組みによってセキュリティ機能を提供しています。今回はそのアーキテクチャについて解説していきます。

 

NSX ManagerとGuest Introspectionの役割は変わらない

ウイルス対策に限らず、Deep Security Virtual Appliance(DSVA)を利用する場合には、NSXサービスが必要となりますので管理プレーンとしてのNSX Manager、制御プレーンとしてのGuest Introspectionが必要となります。(前回も記述)

  • NSX Manager
    NSX Manager はすべての NSX コンポーネントの管理を実施する管理サーバとして動作します。vCenter Server とは別の仮想アプライアンスとして動作しますが、NSXが提供するサービスは vCenter Server から NSX Manager を経由して管理されます。
  • Guest Introspection
    Deep Securityなどサードパーティ製品がセキュリティサービスなどを提供する際に必要な仮想アプライアンスとして保護対象となるESXiホストに配信されます。DSVAによる不正プログラム対策、変更監視、侵入防御、Webレピュテーションなどのセキュリティ機能をエージェントレスで提供するために必要な仮想マシン毎のNSXセキュリティポリシーの管理を行います。

 

ネットワークイントロスペクションサービス

実際に仮想マシンが送受信する通信を検査するためには、ハイパーバイザーからDSVAに対してパケットを転送(リダイレクト)をさせるが必要があります。そのためにはNSXセキュリティポリシーで必要なルールを設定する必要があります。パケットのリダイレクトにはネットワークイントロスペクションサービスを設定します。

ネットワークイントロスペクションサービスで「サービスのリダイレクト」を指定して、サービス名から「Trend Micro Deep Security」を選択することにより、NSXセキュリティポリシーが適用された仮想マシンに対する通信をDSVAに対して転送(リダイレクト)されるようになります。リダイレクトさせる通信は送信元・送信先・サービスで制限すること可能となるため、仮想マシンの送信方向、受信方向それぞれにネットワークイントロスペクションサービスのルールを設定することが必要です。

 

パケット処理の流れとDeep Securityでの処理

仮想マシンのVNICからのパケットはハイパーバイザー上の仮想スイッチ上のdvFilterによって、NSXセキュリティポリシーに設定したネットワークイントロスペクションのルールに則ってリダイレクトされます。
ネットワークイントロスペクションを理解する上で重要なコンポーネントがdvFilterです。

  • dvFilterはネットワークイントロスペクションが有効化されると機能します。
  • dvFilterにはスロット(Slot)が複数用意されており、リダイレクトするサービス毎にSlotが割り当てられます。Slotには入力パスと出力パスが設定されています。
  • Slot 0-3はVMware用に予約されており、分散ファイアウォールを有効にした場合にはSlot 2が割り当てられます。
    DSVAをはじめとする3rd Party製品はSlot 4-11までに割り当てられます。
  • 通信はSlot 0から若い番号から順次有効なSlotにリダイレクトされます。Slotに割り当てられたサービスを入れ替えることで適用されるサービスの順番を入れ変えることも可能です。

実際にどのようにパケットが処理されているのか、上の図を例に見ていきましょう。

  1. 仮想マシンからの通信をパケットはdvFilterが分散ファイアウォールへのSlot の入力パス経由でリダイレクトされます。
  2. 分散ファイアウォールは設定されたファイアウォールポリシーに従ってパケットの制御を行います。
  3. 分散ファイアウォールを通過したパケットは、Slotの出力パス経由でdvFilterに戻され、ネットワークイントロスペクションサービスの設定に基づき、次に割り当てられているDeep SecurityのSlotにリダイレクトされます。
  4. リダイレクト先となるDSVAはDeep Securityセキュリティポリシーに従って、ファイアウォール、侵入防御、Webレピュテーションなどの機能によりパケットを検査し、必要な処理を行います。
  5. DSVAでの検索も通過したパケットはSlotの出力パス経由で再びdvFilterに戻され、仮想スイッチから外部のネットワークへ送信されます。

上記では仮想マシンからの送信トラフィックを例に記載をしましたが、仮想マシンへの受信トラフィックも同様にSlotの若い番号のサービスから順次パケットはリダイレクトされていきます。

 

まとめ

VMware NSXのパケット処理の仕組みをセキュリティ機能の観点から解説をしました。
DSVAはネットワークイントロスペクションサービスがリダイレクトするパケットに対してDeep Securityの機能を提供するように設計されていることがご理解いただけたのではないでしょうか。
VMware NSX環境でDSVAを利用する場合には、ファイアウォール機能はNSX分散ファイアウォールで実装して、Deep Securityのファイアウォール機能はOFFにしておくことを推奨しております。ファイアウォールのようなパケットヘッダーの処理を高速に行う処理は、仮想アプライアンスとして提供されるDSVAでソフトウェア処理するよりも、ハイパーバイザーで処理される分散ファイアウォールのほうが高速に処理することを期待できます。
シンプルなアクセス制御は分散型で高速に処理できるNSXで行い、パケットの内部を検査するような侵入防御やWebレピュテーションをDeep Securityで実施いただくことでサーバ環境のセキュリティを効率的に強化することも検討いただければと思います。

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネスSE部 パートナーSE2課
栃沢 直樹(Tochizawa Naoki)

 

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

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

 

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

エージェントレス型ウイルス対策のアーキテクチャ(2)

 

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

前回はDSVAによるエージェントレス型セキュリティのウイルス検索の流れについて解説をしました。VMware NSX/vSphereと連携をしてDSVAがウイルス対策をはじめとしたセキュリティ機能を提供するためにはNSX側でも必要なサービス設定をしておく必要があります。
NSX側のサービス設定があるからこそ、仮想マシンが生成されたタイミングでDeep Securityのポリシーを自動適用することが可能となりますし、vMotion/DRSによる仮想マシンのホスト間の移動が発生した場合のポリシーのシームレスな移行も可能となっています。
今回は、NSXとDeep Securityが連携した環境で仮想マシンの制御がどのように行われているのか、という側面からアーキテクチャを見ていきたいと思います。これはエージェントレス型セキュリティの実装において一番抑えておいて頂きたい点の1つです。

 

NSX ManagerとGuest Introspectionの役割

まず、エージェントレス型セキュリティ対策で必要となるコンポーネントとしてNSX ManagerとGuest Introspectionが挙げられます。それぞれの役割については第3回でも触れましたが改めておさらいをしておきましょう。

  • NSX Manager
    NSX Manager はすべての NSX コンポーネントの管理を実施する管理サーバとして動作します。vCenter Server とは別の仮想アプライアンスとして動作しますが、NSXが提供するサービスは vCenter Server から NSX Manager を経由して管理されます
  • Guest Introspection
    Deep Securityなどサードパーティ製品がセキュリティサービスなどを提供する際に必要な仮想アプライアンスとして保護対象となるESXiホストに配信されます。不正プログラム対策、ファイル変更監視などのセキュリティ機能をエージェントレスで提供する上で必要となる仮想マシン毎のNSXセキュリティポリシーの管理を行います。

エージェントレス型セキュリティ対策では、NSXサービスを利用するために管理コンポーネントとしてNSX Managerをデプロイし、サードパーティ製品が連携するために必要となるGuest Introspectionという仮想アプライアンスを各ESXiホストに配信することが必要になります。
ここでポイントとなるのは、Guest Introspectionが「仮想マシン毎のNSXセキュリティポリシーの管理」を行うという点です。ESXiホスト単位で配信されるGuest Introspectionがどのように「仮想マシン毎のNSXセキュリティポリシーの管理」しているのでしょうか。

  1. NSX ManagerはvCenter Serverと連携をして常に仮想マシンの状態・稼動しているホストの情報を保持しています。また、NSXサービスを利用する上では必ずセキュリティグループ/セキュリティポリシーの設定が必要になります。これによって仮想マシン毎に適用するNSXサービスを指定します。
    • セキュリティグループ
      仮想マシンが所属するオブジェクトグループとして指定
    • セキュリティポリシー
      NSXで提供するサービスを定義して、セキュリティグループにバインド
  1. NSX Managerは仮想マシン毎に割り当てられたセキュリティグループ・ポリシーを元に稼動するESXiホスト上のGuest Introspectionに対してNSXサービスの提供を指示します。
  1. Guest Introspectionは、ESXiホスト上のvShield-Endpoint-MUXに対して仮想マシン毎に管理用のTCPコネクションを張ります。

以下にNSXサービスが各ESXiホストにどのように配信されているかを図示しています。(直接Deep Securityとの連携はありませんが、Horizon Connection Serverも記載をしています。)

 

DSVAの位置付けとNSXサービスとDeep Securityポリシーの連携

エージェントレス型セキュリティ対策を提供するDeep Security Virtual Appliance(DSVA)は、上記のNSXサービスと連携をして各種セキュリティ機能を提供しています。
DSVAはGuest Introspectionと同様にESXiホスト毎に配信されます。また、ハイパーバイザ経由で各仮想マシンからのファイル情報、パケット情報の受け渡し及び各仮想マシンのNSXサービスステータスを受け取るため、Guest IntrospectionからvShield-Endpoint-MUXに張られるTCPコネクションに対応して、vShield-Endpoint-MUXからDSVAに対してもTCPコネクションが張られます(このコネクションも仮想マシン毎に張られます)。
これによって、DSVAがハイパーバイザ経由でエージェントレスのセキュリティサービスが提供するために必要なハイパーバイザ側のパスが確立されます。
このコネクションは非常に重要で、Guest Introspection → vSheild-Endpoint-MUX → DSVAのコネクションが確立できない場合には、DSVAに適切なDeep Securityポリシーが適用されていても、該当する仮想マシンへのNSXサービスが提供できない状況となるため、Deep Securityのセキュリティ機能は提供できません。

一方でDSVAを管理するDeep Security Manager(DSM)は、vCenter Server、NSX Managerと連携を行い、仮想マシンの状態・稼動しているホストの情報とともに適用されたNSXセキュリティサービスの情報をリアルタイムで同期しています。また、この管理サーバ間の連携によりNSX ManagerがDeep Securityのポリシー情報のエイリアス情報を保持することにより、NSXサービスと同様にどのDeep Securityポリシーを適用するべきかをDSMに指定することが可能となります。
(vCenter Server上の “Networking and Security” Security Policy Service ProfileとしてDeep Securityの“ポリシー”が選択可能となります。)

NSXセキュリティグループ、NSXセキュリティポリシーおよびDeep Securityポリシーの関係性は以下のようになります。

※このポリシー連携はNSX Advancedライセンス以上を利用している場合にのみ可能となり、NSX Standardライセンス以下の場合には、Deep Securityのイベントベースタスクを利用する必要があります。イベントベースタスクを利用する際には、NSX側ではSecurity Policy Service Profileにおいて“default(EBT)”を選択する必要があります。
イベントベースタスクについてはこちらをご参照ください。

Deep SecurityのポリシーとNSXサービスのセキュリティポリシーが連携することで、仮想マシン生成時にはNSX セキュリティポリシーに従ってDSMから稼動するESXiホスト上のDSVAに対して自動的にDeep Securityのポリシーが配信されます。また、vMotion/DRSにより仮想マシンがホスト間で移動した場合にもDSVA間のポリシーの移行を自動的に行うことができるようになっています。
NSXのサービスに加えてDeep Security “ポリシー”がどのように配信されているかを以下に図示しています。

 

まとめ

ここまで見てきたとおり、NSX+Deep Securityによるエージェントレス型セキュリティ対策は、“仮想マシン単位”でNSXサービスとDeep Securityポリシーの双方を連携させることで、vSphere環境上での変化にリアルタイムに対応しつつ、必要なセキュリティ機能を適用し続けることができるように実装されています。

今回は少し詳細な部分まで踏み込んで解説しましたが、vCenter Server/NSX Manager/DSMの管理サーバ群の連携、Guest Introspection-DSVAのコネクションの確立、この2点が重要なポイントです。それらがあって始めてDeep Securityポリシーを適用することが可能となります。ブラックボックスと思われがちなエージェントレス型セキュリティの仕組みも少し身近に感じていただけければうれしく思います。

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネスSE部 パートナーSE2課
栃沢 直樹(Tochizawa Naoki)

 

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

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

 

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

エージェントレス型ウイルス対策のアーキテクチャ(1)

 

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

前回まではVMware NSXとDeep Securityを組み合わせたエージェントレス型セキュリティのメリットや基本的なコンポーネントなどについてご紹介してきました。では、実際にどのようや仕組みでエージェントレス型セキュリティが実現されているのか?という疑問もあるかと思います。今回からは数回にわたってエージェントレス型セキュリティのアーキテクチャ、その際に抑えておくべきポイントなどを技術的な側面から解説していきたいと思います。

まずは、仮想デスクトップ(VDI)環境では多くご利用を頂いているエージェントレス型ウイルス対策がどのような仕組みで実現されているかを解説していきたいと思います。

 

エージェントレス型セキュリティ実装時のウイルス検索処理の流れ

はじめにVMware NSXとDeep Securityの連携によるエージェントレス型(仮想マシンにセキュリティソフトウェアを導入しない)でウイルス対策がどのような流れで実行されているかを確認しておきましょう。

  1. 仮想マシンにインストールされたGuest Introspection Driverに含まれるvsepfilt.sysがファイルのアクセス(読み取り/書き込み)を検出
  2. vepfilt.sysがESXiホスト上のプロセスvShield-Endpoint-MUXへアクセス情報を送信(VMCI経由)
  3. vShield-Endpoint-MUXからDSVAのプロセスds_amへアクセス情報を送信(TCP/IPコネクション経由)
    DSVAのマルウェアスキャンエンジンのスキャンポリシー(スキャン条件、スキャンキャッシュの有無など)に従いマルウェアスキャンが必要かどうかをチェック
    マルウェアスキャンが必要と判断された場合、vsepfilt.sysに対してファイル取得リクエストをレスポンス
  4. vsepfilt.sysが該当のストレージ領域からファイルを取得
  5. 検索対象ファイルをvShield-Endpoint-MUX経由でDSVA(ds_am)へ送信
  6. マルウェアスキャンエンジンがウイルス検索を実行
  7. ウイルス検索イベント(検索結果・実施アクション)をvsepfilt.sysへ通知
  8. マルウェア判定されていた場合、vsepfilt.sysがイベントに基づき隔離、削除などのアクションを実施

エージェントレス型のウイルス検索処理おいてポイントとなるのは以下の点です。

  • ウイルス検索する対象ファイルの検出、アクション自体はVMware vSphere/NSX側のコンポーネントが担っている
  • ウイルス検索の実行、アクションの決定はDeep Security Virtual Applianceが行う

また、Deep Securityにおいてこの仕組みは不正プログラム対策のほかに変更監視機能でも利用されています。変更監視機能では仮想マシン上のファイル、ディレクトリの情報を取得してベースラインからの改ざんがなされていないかを確認することができますが、ファイル、ディレクトリ情報の取得にもこの仕組みを利用しているわけですね。

 

エージェントレスでもトリガーするためのドライバが必要

そしてこの流れを見ていただいたわかるとおり、エージェントレスではありますが、仮想マシンでのファイルアクセスを検出するためのドライバが必要であるということも重要な点です。
このドライバがなければ、ファイルアクセスを検出することもウイルス検索のための上記のプロセスをトリガーすることもできません。
このブログではGuest Introspection Driverと記載をしてきていますが、現行バージョンではNSXファイル自己検証ドライバと呼ばれています。VMware Toolsに含まれるVMCIドライバのひとつでこれを有効化しておく必要があります。
ちなみにNSXファイル自己検証ドライバの下にあるNSXネットワーク自己検証ドライバというものもあります。“ネットワーク”とあるので、Deep Securityのファイアウォール、侵入防御機能などを利用する場合に有効化する必要があるのではないかと思われると思いますが、こちらのドライバはDeep Securityのどの機能を利用する場合でも有効化の必要はありません。

また、エージェントレス型セキュリティの場合、ウイルス検索の結果マルウェアが検出された場合、それをWindowsにログインしているユーザに通知する仕組みがありません。突然ファイルが見えなくなってしまっては何が起こっているかわかりませんね。業務サーバであればそれでも運用が困ることは少ないと思いますが、仮想デスクトップ環境ではそうはいきません。
そのため、Deep SecurityにはDeep Security Notifierというポップアップツールを提供しています。NotifierはNSXファイル自己検証ドライバと連携してDeep Securityの検出状況をユーザに提供することができます。
NSXファイル自己検証ドライバ、Notifierともにパターンファイルなどの情報は保持していませんので、ログインごとに仮想マシンが生成されるような仮想デスクトップ環境であってもマスターイメージにこの2つのモジュールをあらかじめインストールしておくことによりスムーズな展開、運用が可能となります。

 

まとめ

ここまでエージェントレス型セキュリティにおけるウイルス検索の流れと仕組みを見てきました。
ただし、まだ押さえておかなくてはならない点があります。DSVAはvSphere/NSXの仕組みを通してウイルス検索を行うファイル情報を受け取っていますが、この仕組みを利用できるようにNSX側のサービスを設定しておく必要があります。
次回はその仕組みについて解説をしたいと思います。

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネスSE部 パートナーSE2課
栃沢 直樹(Tochizawa Naoki)

 

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

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

 

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

VMware NSXとDeep Securityのユースケースと実現できることとは?

 

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

このたび、VMware vExpert 2018 に選出をいただきました。今後もVMwareソリューションの優位性やトレンドマイクロのソリューションを組み合わせたメリットや技術情報を皆さんにお伝えをしてければと思っております。

 

前回はVMware NSX環境でDeep Security Virtual Appliance(DSVA)によるエージェントレス型セキュリティを実装するために必要なコンポーネントと基本構成について解説しました。
VMware NSX環境でDeep Securityを利用いただくケースとしては、大きく分けると2つのシチュエーションがあります。

  1. 仮想デスクトップ(VDI)環境
  2. サーバマイクロセグメンテーション(いわゆるサーバ環境の保護)

今回はそれぞれのケースでどのように利用されているかをご紹介したいと思います。

 

ユースケース1:仮想デスクトップ(VDI)環境

仮想デスクトップ環境におけるDeep Securityによるエージェントレス型セキュリティ対策は、VMware NSXが登場する前にVMwareがサードパーティ連携を提供していたVMware vShield Endpointというコンポーネントとの連携も含めると2011年あたりからご提供しています。
いまや仮想デスクトップ環境のセキュリティといえば、“Deep Security”というくらいまで認知を頂けるようになるほど業種を問わず多くのお客様にてご利用頂いており、数万台規模でご導入いただいている企業、団体様もございます。
採用いただいているポイントとしては、第2回でも少し記載をしていますが、改めてあげて整理をしてみたいと思います。

(1)仮想デスクトップ(仮想マシン)毎にセキュリティソフトウェアを導入する必要がない

エージェントレス型セキュリティに移行するとESXiホスト毎にセキュリティ専用アプライアンス(DSVA)が配信されることとなり、仮想デスクトップ側にセキュリティソフトウェアを導入する必要はなくなります。また、仮想デスクトップユーザは、朝の時間帯で発生するパターンファイルのアップデートやお昼の時間帯などの定期的なウイルス検索によって仮想デスクトップのパフォーマンスが悪くなってしまうような事象が解消され、セキュリティソフトウェアの稼動を意識することなく業務に従事できるようになり、利便性の向上にも寄与することができます。

(2)セキュリティ対策に共有リソースを使用するため、消費リソースを削減できる

仮想デスクトップ環境では、サーバ環境に比べると1台のESXiホストに対する仮想マシンの集約率が高くなる傾向があります。100台近い仮想デスクトップが集約された環境でそれぞれにウイルス対策ソフトウェアを導入すればホストベースで見ると100台分のアプリケーションリソースを消費していることになります。
各仮想デスクトップのセキュリティ機能をDSVAにオフロードすることにより、集約率の高い環境であればあるほど、ホストからみたリソースの消費は効率化されます。効率化されたリソースの分だけさらに集約率を向上させることにより、ハードウェアコストの削減につなげることも可能です。
※集約率とセキュリティ対策に必要なDSVAなどのセキュリティ専用アプライアンスのサイジングとのバランスは考慮する必要があります。

(3)vSphere環境でのユースケースを考慮した実装となっている

vSphere環境では多くの場合、DRS/vMotionを利用して仮想マシンの最適なリソース配置を行っています。仮想デスクトップが他のホストにvMotionしてもvCenterのインベントリ情報をDeep Securityがリアルタイムに監視することにより、自動的に他のホスト上でもセキュリティ対策を継続します。また、Horizon のリンククローンやインスタントクローンなどの展開方式に関わらず対応できるような設計となっています。
インスタントクローンへの対応については、第1回の記事をご覧ください。

Horizon インスタントクローンにも適用可能!仮想デスクトップ環境にフィットしたセキュリティ対策

 

ユースケース2:サーバマイクロセグメンテーション

Deep Securityはもともとサーバセキュリティ製品としてリリースをされ、物理環境、クラウド環境、そして仮想化環境問わずさまざまな環境でご利用いただいています。
加えて、サーバセキュリティに必要な多くの機能を提供が可能で、環境に関わらず同一のコンソールから一元管理できることも大きなメリットとなっています。

各監督官庁がリリースするセキュリティガイドラインや国際的なセキュリティ統一基準(PCI-DSSなど)などに準拠するために利用いただいているケースも多くあります。

Deep SecurityとVMware NSXを利用いただくことにより、各ESXiホストに配置される分散ファイアウォールでの仮想マシン単位での適切なアクセス制御とDeep Securityの各セキュリティ機能によるサーバ要塞化を実現することができます。

また、vCenter Server / NSX Managerが連携していることによりポリシーの適用漏れがないかを簡単に確認することもでき、セキュリティ強化にとどまらず、セキュリティ実装の証明、適用している内容の可視化、そして運用の効率化という側面からも優位性が高いソリューションとなっています。

 

さらにVMware NSXとDeep Securityが連携していると、Deep Security Virtual Applianceでセキュリティイベントを検出した際に、NSX分散ファイアウォールと連携して該当の仮想デスクトップのネットワーク通信の制御(実質的な隔離)を行うことも可能です。
ウイルスを検出した際に、PCのLANケーブルを抜くようなオペレーションを自動的に実行してくれるというわけですね。(ウイルスの隔離に失敗した場合にだけ隔離するといった細かい制御も可能です。)
自動隔離まで行わない場合でも分散ファイアウォールを仮想化環境で使うことには大きなメリットがあります。
それはランサムウェアや標的型サイバー攻撃に対する被害の拡散の防止です。分散ファイアウォールでは仮想デスクトップ同士の通信をブロックするポリシーを1行で書くことができますので、これによって同一セグメントにありながら、ランサムウェアや標的型サイバー攻撃の足がかりとなるマルウェアを実行してしまった場合でも他の端末に対して情報を取得したり、感染を行う“横”の通信(Lateral Movement)をブロックすることができます。サーバセグメントにおいても不必要な通信に対するアクセス制御を行うことよって被害の拡大を最小限に食い止めることが可能となりますし、その状況を可視化することもできます。

 

 

まとめ

Deep Securityはどのような環境においてもご利用いただける統合型エンドポイントセキュリティ製品となっています。VMware NSXと連携することでアクセス制御を中心としたセキュリティ機能の向上もさることながら、実際の運用現場で必要となる情報を可視化して実装を証明できるといった側面もあります。
セキュリティレベルの向上と合わせて、こういった部分も注目をしてセキュリティの実装要件を検討いただくことで、よりフィットしたセキュリティの適用が可能になると思います。

次回以降は、少し技術的なお話に移って生きたいと思います。なぜ、エージェントレスでセキュリティ実装が可能なのかをアーキテクチャを深堀りしながら解説していきたいと思います。

 

執筆者:
トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネスSE部 パートナーSE2課
栃沢 直樹(Tochizawa Naoki)

 

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

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