ネットワーク NSX NSX Data Center

マイクロセグメンテーションの必要性、より頑丈なマイクロセグメンテーションの作り方

NSX-T Data Center NSX 分散ファイアウォールとは、「 ハイパーバイザー で VM の vNIC 単位でインラインのステートフルファイアウォールが実行できる」NSX-T の基本機能です。
通称、マイクロセグメンテーション（マイセグ）と呼ばれており、過去5年以上 NSX の鉄板活用例となっていました。今更ブログ？というイメージかもしれませんが、改めて基本から紹介したいと思います。

全３パートに分けて、NSX 分散ファイアウォールをいろいろな側面からご紹介していきますが、初回である前回は「そもそもNSX 分散ファイアウォールとは？」という基礎のお話を２つのパートに分けて紹介させていただきました。詳細は、こちらの記事 をご参考ください。

３回目にあたる今回は、分散ファイアウォールについて 昨今のサイバーセキュリティ動向と照らし合わせ、その有効性や活用術を紹介したいと思います。

ここからはマイセグのことを DFW (Distributed Firewall/分散ファイアウォール) と表現したいと思います。

 

過去の関連記事はこちら

 

 

 

 

マイクロセグメンテーションの必要性

NIST（米国標準技術研究所）でゼロトラストアーキテクチャーの定義が進んでおり、2020年8月に「NIST SP 800-207 Zero Trust Architecture (Final) 」が発行されましたこちらを参考に「ゼロトラスト実現に向けた、マイクロセグメンテーションの必要性とあるべき姿」を考えてみたいと思います。

こちらの第３章では、具体的な実装技術に言及して ゼロトラストアーキテクチャアプローチ を定義していて、論理コンポーネント（具体的な実装技術）として、３つの要素を提示しています。

 

その２つ目に、マイクロセグメンテーションという言葉が使われるようになりました。

「マイクロセグメンテーションによって、VMのようなワークロード（リソース）をセグメント化し、ワークロードへのアクセス制御を動的にできること」とあります。また、このマイクロセグメンテーションは、「様々な展開モデルに共通して利用できるべき」と表現されています。

 

個人の考えが含まれますが、「OS種別に限定されず、また VM/コンテナ のような様々なワークロードの展開モデルも組み合わせた運用とされる実環境を考慮しますと、マイクロセグメンテーションをどこでも共通して利用できる」といった仕組みであれば、ゼロトラスト実現に向けてより現実的な選択になるのかもしれません。

また、本定義では「マイクロセグメンテーションの動作では、不正アクセスなどを検知した際に、脅威に対して動的な対処ができたりワークフローを変更させたりができるようなインシデントレスポンスに適応できる仕組みが必要である」といったこともこの第３章の後半で挙げられていますし、「あまり高度でないゲートウェイ機器 や ステートレスファイアウォールを使用することは、管理コストとインシデントレスポンスのための設定変更が速やかにできないため、良い手段とは言えない」と指摘もされていました。

では、どういった仕組みでマイクロセグメンテーション を実装するのがゼロトラスト実現の近道となるのでしょうか。
この辺りを、これからじっくり解説していきたいと思います。

 

DFWでより頑丈なマイクロセグメンテーションを

では、上記でも マイクロセグメンテーション という言葉が使われるようになり、その必要性やあるべき姿が 言及されるようになりましが、ゼロトラストを実現させていく上で どういった実装方式が有効なのでしょうか。
DFWの場合を例に、データセンターワークロードに対する有効性を紹介していきたいと思います。

前述のNISTのゼロトラストアーキテクチャー定義では、マイクロセグメンテーションによって、「 ワークロードをセグメント化し、ワークロードへのアクセス制御を動的にできること 」とありました。

DFWでは、どうでしょうか。DFWはvNIC毎に ステートフルファイアウォールとして動作し、そこで動作するファイアウォール ルールは 、そのVMの vNICにリアルタイムに適用されます。例えば、DFWルールで決めたVM名やOS種別に VMが該当すると、そのDFWルールがリアルタイムに自動適用されますので、上記の定義の動的制御をDFW備えているといえます。こちらのデモビデオを通して、さらに深堀して解説したいと思います。

 

 

 

他にも VDIのような短時間に大量のWindows OS 仮想マシンがデプロイ・起動した場合でも、DFW によって 仮想マシン全ての vNIC にリアルタイムに アクセス制御のルールが適用され、こうしたワークロードの増減にも動的に対処されます。

自動化されていますので常に想定したルールが適用されますし、こうしたワークロードの変更による管理者の都度の作業も不要で、なにより人の手を介さないため作業ミスや漏れもなくなるので心強い仕組みですね。

 

 

 

次のポイントとして、仮想マシンの ゲストOSの種別 に依存することなく、仮想マシンが持つ 仮想NIC (vNIC) 毎に ステートフルファイアウォールが動作できる点は DFW の特徴の１つです。

DFW は VMware ESXi の 分散仮想スイッチで動作し、仮想マシンに加えて コンテナ環境で動作する K8s Pod に対しても、ステートフルファイアウォールによるアクセス制御ができたりします。他にも、ここ数年はDFWの実装発展により KVM環境の仮想マシンも制御できたり、OpenShiftにも対応していますし、API連携によりAWS, Azureインスタンスに対しても DFWで設定したアクセス制御のルールを適用することができるようになっていたりするんですよ。

 

(ESXi以外の環境での、DFWの動作の詳細については、また他の記事で触れたいと思います)

 

このようにDFWでは、OS種別に限定されず、VM/コンテナ のような「様々な展開モデルを組み合わせても、マイクロセグメンテーションを共通して利用できる」ようになっていて、前述のNIST ゼロトラストアーキテクチャー定義に非常に類似した実装を既に持っていたりします。

 

最後のポイントとして、「脅威に対して動的な対処ができたりワークフローを変更させたりができるようなインシデントレスポンスに適応できる仕組み」がマイクロセグメンテーションに求められていました。
DFW を使うことで、脅威を検知した際に DFWルールを動的に変更させ、該当の仮想マシンをネットワークから自動隔離することもできたりします。このユースケースは、マイセグ と サードパーティマルウェア対策ソフトウェア との連携ということでVMwareでは長年鉄板構成となっており、以前から提供/活用いただいている成熟したユースケースなんです。こちらの動作概要を少し補足しますね。ネットワーク上で動作しているマルウェア対策ソフトウェアが仮想マシンを外側から監視し、マルウェア対策ソフトがマルウェアを検知した場合、マルウェア対策ソフトがマルウェアが検知した仮想マシンに対して NSX APIを使ってフラグを立てます。このフラグによってNSXでDFWルールを変えることができ、マルウェアを検知した場合のDFWルールとして、例えば全通信を遮断するといったDFWルールに変更しておくことにより、マルウェアが感染した仮想マシンを通常のネットワーク上から切り離したり、検疫ネットワークに変更することが可能になるというわけです。

 

これは、今までマルウェア感染が疑われる物理PCに対して行っていた、ネットワークケーブルを抜く のと同様の操作を仮想マシン環境においても可能にし、かつ自動化までしてしまった非常に効率的な事例になります。自治体などの公共系のお客様、IT管理者の省人化と高度化に熱心なお客様などに特にご採用が多いユースケースになります。

マルウェア検知した仮想マシンに対して NSX APIを使ってフラグを立てる動作に対応した サードパーティのマルウェア対策ソフトウェアは、トレンドマイクロ社のDeep Security など複数ありますので、ぜひ調べてみてください。

 

 

また、NSX API はどなたでも自由に操作するができますので、SIEMと連携したり、Ansibleなど自作のワークフローに組み込むと、自動化やより高度な活用ができるかと思います。NSX APIの活用例もまた他の記事で触れたいと思います。

 

 

 

より頑丈なマイクロセグメンテーションの作り方

DFWでは、仮想マシン vNIC と 仮想スイッチの間に ステートフルファイアウォールが動作します。仮想マシン毎にファイアウォールを動作させてマイクロセグメンテーションを行いたい場合、エージェント型を使うアプローチもありますが、エージェント型のアプローチはDFWと２つの点で異なります。

こちらの二点に焦点をあて、それぞれ整理して解説するとともに、「より頑丈なマイクロセグメンテーションの作り方」としてまとめていきたいと思います。

１つ目、エージェント型のアプローチは ゲストOS依存となり利用が限定的という点です。

一般的なエージェント型のアプローチは、Linux の ipsets/iptablesであったり、 Windows Defender の Firewallルールを エージェントを介してルール変更させることで アクセス制御を実施しています。ゲストOSによってルールの管理は異なりますし、エージェント対応したゲストOSを利用する必要があるので、ゲストOS依存となり活用範囲が限定的となってしまいますね。。

DFWでは、前述のようにゲストOS種別には限定されませんし、VM/コンテナ のような「様々な展開モデルを組み合わせても、マイクロセグメンテーションを共通して利用できる」ようになっており、前述のNISTのゼロトラストアーキテクチャー定義に対してカバーでき、様々なユースケースに広く応用いただける機能になっています。

 

２つ目、攻撃者によってゲストOSが持つ保護機能は無効化できてしまうという点です。
こうしたゲストOSレベルでの対策の場合、一度 ゲストOSの Root 権限が奪取されると、攻撃者によりエージェントによる保護が解除され、エージェントが OS を効果的に保護することは事実上不可能な状態になってしまいます。

 

 

 

 

過去の攻撃者グループが実際に行なった攻撃手順でも、ゲストOSが持つ保護機能の無効化事例は複数存在していますので、いつくか事例をみてゆきましょう。

 

まずは、MITRE ATT&CK フレームワーク をチェックしてみます。アメリカ連邦政府の資金提供うける NPO である MITRE社の 「ATT&CK™」フレームワーク内では、攻撃者グループなどが実際に使用した攻撃手法や戦術をナレッジベースとして整理し公開しています。

 

 

このナレッジベースの中で、今回のような攻撃手順は 「Defense Evasion」 戦術フェーズにある 「Impair Defenses」 テクニックの中で具体的に説明されています。（下図ATT&CK v7の緑枠. 2020/10更新版v8が最新）

 

例えば、「Disable or Modify Tools」や「Disable or Modify System Firewall」といったように、過去の攻撃者グループが実際に行なった攻撃手順としてゲストOSが持つ保護機能の無効化テクニックが複数存在していることがわかります。

 

 

また、産業系や社会インフラを主にターゲットとしたランサムウェア EKANS の挙動も皆様記憶に新しいのではないでしょうか。複数のセキュリティ調査会社が EKANS の挙動を解析され公開していますが、「正規のWindowsファイアウォール設定を変更し、暗号化完了まで全ブロックして 終わるとブロックを解く」といったようにゲストOSが持つ保護機能を無効化させようとします。

 

エージェント型のアプローチは上記２つの点をあらかじめ把握した上で、セキュリティ対策を検討する必要がありそうですね。。

 

では、DFWはどうでしょうか。DFWでは、仮想マシンが持つ 仮想NIC (vNIC) 毎に ステートフルファイアウォールが動作し、仮想マシンの ゲストOS に依存することなく利用することができます。
また、ゲストOSの Root 権限が奪取され攻撃者によりゲストOSが持つ保護機能が無効化されても、DFW はハイパーバイザーで動作するのでファイアウォールによる保護は無効化されません。

 

これで、１つの仮想マシンが侵害されてもDFWで内部感染など通信を抑制・予防は継続できますね。少し話が派生しますが、あとは、SIEMやマルウェア対策ソフトウェアと連携して、この脅威を検知したらば、DFWルールを変更することで、該当の仮想マシンをネットワークから自動隔離し脅威拡散を予防することができたりします。

 

 

さらに、SIEMであったり、Ansibleにより、vCenter Server API で該当の仮想マシンのスナップショットをとったり、シャットダウンさせるなど、自作のワークフローに組み込んでしまって自動化やより高度な活用もできてしまいます。皆さまのいろんなアイディアを、ワークフローやプレイブックに盛り込んでみて下さい。

 

 

 

 

 

まとめ

さて、今回は NSX 分散ファイアウォール 紹介シリーズの２回目ということで、 昨今のサイバーセキュリティ動向と照らし合わせ、その有効性や活用術を紹介しました。

皆さまの中には、こちらの記事をご覧になる以前から、「データセンター にある多種多様なゲストOSのサーバや仮想アプライアンスを一元的にネットワークのセキュリティレベルを どう高く維持していけばいいの？」であったり、「昨今のゼロトラストの実現に向けてじゃあ何から始めたらいいの？」といった事をお悩みだった方もいらっしゃったのではないでしょうか。

DFWでは、ゲストOS種別に依存せず、攻撃に対してもネットワーク上から正確に保護できることがご理解いただけたのではないでしょうか。APIまで活用していくことで、自作のワークフローに組み込んでしまって自動化やより高度な活用もできたりしますので、DFWでより頑丈なマイクロセグメンテーションを作ってみていただけたらと思います。

是非 NSX 分散ファイアウォール を活用してみてください。

 

 

次回は分散ファイアウォールの運用での使い所などを通して、分散ファイアウォールの実態をさらに深堀した内容をご紹介していきたいと思います。

 

〜お知らせ〜

 ※NSX-T Data Center、および VMware SD-WAN by VeloCloud  について入門編から中級編まで各種セミナーも定期開催しております。
より詳細についてご興味を持っていただけたお客さまはこちらも併せてご参加をご検討ください。 

各種オンラインセミナーの開催日時はこちらから https://vmware-juku.jp/seminar/


※VMwareでは、各種製品をクラウド上でご評価いただくHands-on Labs（HOL） という仕組みを無償でご提供しています。
今回ご紹介した各種ソリューションへの最初の一歩の入り口としてぜひご活用ください。

おすすめのHOLメニューはこちらから ( http://labs.hol.vmware.com/HOL/catalogs/catalog/1212 )

 

 

Susumu Nagatoishi

ヴイエムウェア株式会社 - クラウドインフラストラクチャ技術部 - プリンシパル ソリューション アーキテクト, VCIX-NV(2018,2020,2022), VCAP-NV NSX-T 3.1 Feb/2022, VMware SD-WAN Troubleshoot 2020, CCIE (R/S - 13Years)

関連記事