Home > Blogs > Japan Cloud Infrastructure Blog > 月別アーカイブ: 2018年12月

月別アーカイブ: 2018年12月

vROps 6.7は初心者に優しい!#5

5回目:vSAN運用管理者にはvROpsは欠かせないツール

— Back Number —

#1:仮想基盤のパフォーマンスは使用率だけでは図れない
#2:アラートからブレイクダウン
#3:仮想マシンのリストはカスタムビューで
#4:6.7バージョンはメトリックの活用がポイント
#5:vSAN運用管理者にはvROpsは欠かせないツール

日本ヒューレット・パッカード株式会社の中川明美です。
5回目は「vSAN運用管理者にはvROpsは欠かせないツール」です。

vSAN監視のために、vROpsとの連携が強化されていますね。6.7からは「vCenter Server の vRealize Operations Managerプラグイン」が提供されています。
先日弊社教育サービスに、パートナー様から、「エンドユーザー様からのご依頼により、vROpsの知識を身につけたい」とお問い合わせがありました。
「vSANの運用監視のためにvROpsの活用方法をお知りになりたいのでしょうか」とお尋ねしたところ、「vSAN前提で、vROpsの設計から学習したい」というご要望でした。
vSANの運用監視をされるのはエンドユーザー様ですから、vSANの導入が増えるにしたがい、vROps連携の依頼も増えるのかもしれませんね。
vROps 7.0からはVMware Cloud on AWSと連携することも可能です。連携する対象が増え、この数年vROpsの啓もう活動をしてきた私には楽しい状況です(笑)。

vCenter ServerでもvSANの基本的なパフォーマンスメトリックを監視することはできます。vSANのパフォーマンスメトリックは他のメトリックとは異なり、vCenter Serverに保存されず、 vSANデータストアに存在するオブジェクトとして格納されます。データを表示できる時間は1時間から24時間、保持日数は90日間です。vROpsのデータ履歴の保持期間はデフォルト6か月です。

KB:How to configure Data Retention in vRealize Operations Manager 6.x and later (2147600)

加えて、vROpsはvCenter Serverにはないメトリックの提供、収集したデータのカスタマイズ表示が可能です。

先に、「vCenter Server の vRealize Operations Managerプラグイン」からご紹介します。

◆vCenter Server の vRealize Operations Managerプラグイン◆

vSphere Clientから、「VMware vROps Client Plugin」を確認できます。

ホームまたはメニューから、「vRealize Operations」を選択します。

プラグインを使用する場合は、この画面から「インストール」または「既存インスタンスの構成」を選択し、進めます。完了後、表示されるまで多少のタイムラグがあります。vSANはvCenter Serverより数分遅れて表示されます。

<vCenter ServerのvRealize Operations Manager プラグインのドキュメント>
詳細は次のドキュメントを参照ください。
https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.vrops/GUID-57D6EFBD-3FD2-4EDC-A754-594F7AFE546E.html

 

画面右側の「クリック リンク(赤枠)」メニューから、vSANの画面に切り替えます。また「vRealize Operations(緑枠)」リンクをクリックすると、新規タブにvROpsのログイン画面が表示されます。

< vSANの概要 >

すべてのvSANクラスタを対象に、「最低限このメトリックのみ確認しておけばよいでしょう」というデータが表示されています。アラートの「詳細表示 (赤枠) 」をクリックすると、このプラグイン内のアラートリストの画面に遷移します。

< vSANのクラスタ ビュー >

「クラスタの変更 (赤枠)」から、各vSANクラスタのデータへ切り替え、1つのクラスタのメトリックを確認することができます。
1点気になるのが、「最終更新日(緑枠)」の時刻はJST (Japan Standard Time) ですが、各メトリックの時刻はUTC (Universal Time, Coordinated) で表示されているようです。黒いポップアップはグラフの一番右にマウスを合わせ表示しています。
下図では、最終更新日は12:40 PM、ポップアップの時刻は3:26です。9時間ほどの差があります。この時刻はHost Clientで確認するUTCの時刻とほぼ一致しています。
「vSANの概要」も合わせ、ここは注意点かもしれません。

< vSANの アラート >

vSANクラスタ内のアラートを表示します。

ここからは、vRealize Operationsです。

◆vRealize OperationsのvSANダッシュボード◆

vROps 6.7では事前に提供されるvSANに関するダッシュボードが4つあります。
ここでは、「vSAN運用概要」と「vSANへの移行」の2つのダッシュボードを取り上げます。

< vSAN運用概要 >

vSANのプラグインはvSANに特化したデータ表示ですが、vROpsは一画面でコンピュータリソースのデータも表示されます。CPUやメモリリソースも同時に確認できます。
ディスクデータの赤色の点線枠は現在の値です。現在値と履歴トレンド (傾向) がわかるのは便利です。
ディスクに関する値はTB (テラバイト) で表示されています (青色の点線枠) 。大容量のサイズを構成していない場合は、単位はGB (ギガバイト) の方が把握しやすいかもしれませんね。

ダッシュボードの「ウィジェットの編集 (鉛筆のアイコン) 」をクリックし、編集画面から表示する単位を変更することができます。カスタマイズにはAdvanced以上のエディションが必要です。

この環境のディスクサイズは少量のため、単位をGBに変更したことで管理しやすくなりました。事前に提供されるダッシュボードもカスタマイズするとより使いやすくなりますね。

< vSANへの移行 >

非vSAN (従来の) データストアまたはvSANデータストア内の仮想マシンのストレージメトリックを監視することができます。以前のバージョンの「vSANデプロイの最適化」ダッシュボードと比べてシンプルになりました。仮想マシンのディスクパフォーマンスを考慮しつつ、非vSANデータストアとvSANデータストアとの間で仮想マシンの移行の検討をすることができます。

◆ご紹介ドキュメント◆

このBlogを執筆するにあたり、参考にした英語のドキュメントを共有します。

◆まとめ◆

vROpsのバージョンが上がると、vSANとの連携が強化されますね。
vSANの運用管理は、Web Clinet、vSphere Client、Host Clientからもできますが、仮想基盤全体のメトリックの集約と分析にはvROpsの出番です。パフォーマンスはコンピュータリソースの視点も必要です。vROpsを使用して、コンピュータリソースが必要なのか、ディスク容量が必要なのかを把握できます。さらにvRealize Log Insightも準備すれば、重要なログインベントメッセージの検索が容易になります。トラブルシューティング時は安心ですね。先にご紹介したvSANのドキュメント内にLog Insightのデモがあります。ぜひご確認ください。
こちらでご紹介した内容が、みなさんのお役に立てたなら幸いです。

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)