前回に引き続き、vRealize Network Insight (vRNI) のユースケースについて、今回はセキュリティ視点をご紹介します。
ユースケース 2 – セキュリティ
セキュリティ計画
まず、リリース当初から提供している「セキュリティ計画」です。
vRNI は NSX Data Center のマイクロセグメンテーションを実現するために、vSphere の分散スイッチからフローを収集し、トラフィックを分析し、可視化を提供してきました。機能強化によって様々なワークロード（VM、Kubernetes サービス、パブリッククラウドのインスタンス、物理サーバ）に対応し、オンプレミスだけでなくパブリッククラウドにもカバー範囲を広げています。
vRNI はデータの収集元をデータソースと呼びます。
下記プロトコルを利用し、さまざまな環境からフロー情報を収集します。
- vSphere の分散スイッチや NSX Data Center 、VMware SD-WAN : IPFIX
- 物理ネットワーク機器 : NetFlow バージョン 5、7、9 または sFlow
- パブリッククラウド : API 経由
現在のバージョンのサポート対象製品やデータソースの追加設定については、こちらを参照ください。
指定した範囲、エンティティに基づいて分析するセキュリティ計画の画面では、まず、左のドーナツチャートで、トラフィック流れとその実際のフローが確認できます。想定しているエンティティ間以外で通信が発生していないかを確認するために使うことができます。
例えばグループ化の基準で、サブネットを選択すると、どのサブネットでフローが発生しているか、どのサブネットとの間でフローが流れているか、さらに特定のサブネットに上記のように画面上でマウスを移動すると方向が色（青色は送信、黄色は受信、緑色は双方向）で確認できます。その線をクリックすれば、フローの詳細情報や、現在利用中の通信のみを許可する推奨のファイアウォールルールを見ることができます。
対策を行う場合にはルールを作成する必要がありますが、その場合にエンティティでセキュリティグループもしくはアプリケーション層を選択した場合は XML で、それ以外は CSV でエクスポートが可能です。
このルールのエクスポートは NSX for vSphere では使われてきましたが、NSX-T では NSX Intelligence によるルール作成と適用が可能なため、今後は使われる機会は減ると思います。
もちろん推奨ルール作成以外にも使いどころがあり、アプリケーション視点でのユースケースでご紹介しました NSX と連携し、ブロックされた、保護されたフローの表示が有益です。
下記のようにフロータイプを選択することで、対象のフローだけをフィルターできます。
- すべての許可されたフロー : 分散ファイアウォールルールでアクション[許可]により通ったフロー
- ドロップされたフロー : 分散ファイアウォールルールでドロップされたフロー
- 保護されたすべてのフロー : 送信元 [任意]、宛先[任意]、サービス[任意]、アクション[許可]以外のルールを通ったフロー
- 保護対象でないすべてのフロー : 送信元 [任意]、宛先[任意]、サービス[任意]、アクション[許可]のデフォルトルールを通ったフロー
特に、ドロップされたフローを選択すると、通したいのに許可されていないフローを発見し、保護対象でないすべてのフローを選択すると、逆に通してはいけないのに通っているフローを発見することに使えるかもしれません。
この機能は現状のトラフィック把握に役立つため、NSX を導入する前に使っていただくことがあります。またゼロトラストを実現するための一部として考える時には、ITが把握していない送信元から宛先のフローや、アプリが利用する想定外のポート番号を見つけ出すことにも役に立つかと思います。
次に、トラフィック分布はサマリーされた情報を把握するのに役に立ち、East-West (データセンター内のサーバ間) と North-Sourth (データセンター外とのトラフィック) の割合や、East-West のうちのスイッチング（現在のバージョンでは日本語表示の不具合により切り替え済みと表示されています。現在修正中）とルーティングの割合を表示し、数値をクリックすることで実際のフローを確認できます。インターネットに接続がないクローズドの環境を構築している時には、インターネット/North-South の値に注目するといいかと思います。
そして、バイト数別の上位ポートでは、どんなトラフィックがこの環境の中を流れているのか、トラフィックの上位 100 個のポート一覧を表示します。
環境内のアプリケーションで利用されているポート番号の把握
ここからはさらに別の使い方をご紹介します。
上記でご紹介したセキュリティ計画の上位ポートでは全利用ポートは表示できないことが多いため、すべての利用ポート番号を確認・把握したい場合、検索バーより
sum(bytes) of flows group by port
または
flows group by port order by sum(bytes)
を利用すると表示できます。
さらにセキュリティ用途として、例えば脆弱性をついたランサムウェアが利用する特定のポート番号と同じものが使われているフローはないかを知りたい場合、flows where port=’ポート番号’ order by bytes
が利用できます。
WannaCry の場合、Windows SMB バージョン 1 が利用する TCP 445 を使っていましたので、下記のように検索して、利用しているソース（送信元）を調べることができます。
個々のフローの詳細は適用されているファイアウォールルールを含めて確認できますので、デフォルトルールで保護対象でないすべてのフローとしてファイアウォール ルールが使用されていた場合は、送信元と宛先を見てアプリケーションの担当者に確認する等、調査が必要になるかもしれません。
ルール構成とルールに属するワークロードやインスタンス情報の把握
従来の物理ファイアウォールで行ってきたようなIPアドレスベースでのルール設定が減ってきています。実際、NSX ではセキュリティグループ、セキュリティタグのようなワークロード（仮想マシン）が持つ属性によって、パブリッククラウドではセキュリティグループの設定によって、ファイアウォールルールが設定できます。
そのような設定状態を把握するために、vRNI が使えます。
security group
と検索するだけで、セキュリティグループのリストが表示され、フィルターを使えば特定の環境下のものだけを抽出できます。
セキュリティグループを指定すると、セキュリティグループに関連するファイアウォール ルール、関係するセキュリティグループ（また入れ子状態）、グループ内の仮想マシン、フロー等が確認できます。運用後の設定確認に便利です。
また、ファイアウォール を運用しているときに課題となる、ルールが意図した通りに機能しているか確認する検索クエリとして、
firewall rule masked event
があります。ルールは上に記載のルールから順にチェックされ、ヒットすると処理されるため、より細かなルールが上にあるべきですが、そうなっていないマスクされたルールをこの検索クエリで洗い出すことができます。
PCIコンプライアンスチェック
こちらも前回ご紹介済ですが、範囲で特定のアプリケーションを選択する代わりに、vCenter、データセンター、クラスタ、リソースプール等の vSphere環境を選択したり、NSX のセグメントを選択して、PCIコンプライアンスチェックをすることが可能です。
最大 50 ページ分まで、PDF へのエクスポートも可能ですので、データ量が多い場合は範囲を絞っていただければと思います。
次回は、また別のユースケースをご紹介します。
