マカフィーのvNSP on AWSの構造をシニアセールスエンジニアに訊いた

2017年8月23日に開催されたマカフィーによる記者発表会で、同社がこれまでvSphereの上でオンプレミス版のソフトウェアによるIPS（Intrusion Protection System）として展開してきたvNSP（仮想Network Security Platform）を、Amazon Web Services（AWS）に対応させた「AWS向けMcAfee vNSP」を発表した。その際に「AWSでは並列アーキテクチャーを採用しているので、vNSPがボトルネックになることはない」という説明が行われた。

通常、外部から到達するパケットを調査することで、マルウェアや侵入などの攻撃を防御するのがIPSの役割である。専用のハードウェアによって実現されるファイアウォールやIPSでは、専用アプライアンスとしてASICなどによって高速なパケット検査を実行するが、AWSというクラウド環境においてはどのように実行されるのだろうか、また並列アーキテクチャーというのが何を指しているのか？　さらにNSP on AWSの構造はどうなっているのか？　これらの疑問点を、マカフィー株式会社のシニアセールスエンジニアの安田哲氏にぶつけてみた。

マカフィー株式会社シニアセールスシステムズエンジニア、安田哲氏

まずvNSPとはなにかについて教えて下さい。

安田：もともとVMwareの環境、つまりvSphereの仮想化環境において仮想マシンのトラフィックを防御するシステムとしてハードウェアで実現されていたNSPを、ソフトウェアで実現していたものがvNSPです。当初はファイアウォールの内側にあるサーバー間の通信、つまり「イースト～ウェスト」の通信を監視するために作られました。外部との通信である「ノース～サウス」の通信はハードウェアのNSPが担当し、ファイアウォールの後ろにあるサーバー同士の通信をソフトウェアのvNSPが受け持つ、ということですね。しかし今回AWSの上で実装したものとは構造が違います。

構造の違いを教えてください。

安田：そもそもAWSの場合はオンプレミスのデータセンターとは異なり、ルーターやネットワークスイッチなどに外部からハードウェアを設置したりはできません。そのため、通常のハードウェアによるNSPとは違う方法論で構成する必要があります。そこでマカフィーでは、仮想マシンにインストールするVirtual Probeという軽量のプロセスを作って、それが仮想マシンの通信をフックし、外部の「センサー」と呼ばれるvNSPに通信を迂回させてそこでパケットの検査を行う方式を実現しました。

ということは外部から仮想マシン向けに入ってきたパケットは一旦、外部のセンサー（vNSP）に迂回させてそこでの検査を終わったものがまたProbeに戻ってきてから仮想マシンに到達するということですか。

安田：そうです。実際の検査は複数のProbeからの通信を受けるvNSPが行いますが、この実体はAWSのEC2上の仮想マシンですので、オートスケーリングによって複数稼働させることが可能です。そのあたりのヘルスモニタリングなどは、vNSPとは別の「コントローラー」と呼ばれるプロセスが監視しています。そしてそれらのプロセスを管理するNSM（Network Security Manager）が管理ツールとして動く、と言う感じですね。

なるほど。一つの大きなハードウェアでやるのではなく、仮想マシンにインストールされた軽量のプロセスが通信をフックして、別の仮想マシンのプロセスが検査を行う。そしてそのvNSPは複数稼働させることができるので、並列アーキテクチャーというわけですね。仮想マシンにインストールするということは、先日質問したようにコンテナやPaaSのようなワークロードだと……

安田：ちょっと考えないといけないでしょうね（笑）。ただこの方式だとAWS、GCP、Azureのいずれにも、それほど苦労せずに実装できます。またProbeもWindowsサーバーや、Linuxの各種ディストリビューションに対応しています。vNSPは「最低限この仮想マシンで稼働させてください」という目安はありますので、必要に応じて複数稼働させれば、性能面でもそれほど問題にならないはずです。

この場合の料金体系はどうなっているのですか？

安田：vNSPに関して言えば、通過するデータ量によって課金が行われます。それとは別にvNSP、コントローラー、管理ツールはお客様のAWSリソースを消費することになるので、その部分は負担していただくことになります。仮想マシンにインストールするProbeは軽量ですのでそれほど負担にはならないはずです。もう少しするとベンチマークなどのデータが出てくると思いますので、それで確認したいと思います。あとvNSPとProbeをインストールした仮想マシンは、同じアベイラビリティゾーンに配置することが必要だと思います。これは通信のレイテンシーを下げるという意味から言えば当然といえば当然ですが。

あと仮想マシンにインストールということは、システムがUpdateされるような場合はまたビルドし直さないといけないということになりますね。

安田：それについてはChefなどのツールからコマンドラインでの実行が可能になりますから、その仕組みを作ってしまえば、自動化することは可能です。またvNSPもProbeも更新の必要があるような場合は管理ツールから実行できますので、管理自体は容易だと思います。

今回のAWS上のvNSPは、本来ゲートウェイ的に設置するべきものをAWSの仕組みから見て難しいというところから発想して、仮想マシンのProbeとそれを受け取るセンサーつまりvNSPで実装するという構造になったということだろう。実際にシステムの性能面でどのくらいの負担になるのか、コストはどのくらいかかるのかなどについては、これから知見が蓄積されていくという状況だろう。

オンプレミスの環境とは異なり、ネットワーク上の任意の場所にゲートウェイを置けないパブリッククラウドにおいては、アプリケーションが稼働する仮想マシンにProbeをインストールして別の仮想マシンがパケットの検査を行うという構造は現実解であると思われる。DockerコンテナやPaaSの中で動くコンテナ、さらにKubernetesでオーケストレーションされたワークロードに関しては再度、アーキテクチャーを考え出す必要があるだろう。ベストの解は、パブリッククラウドベンダーがサービスの一環としてIPS/IDSを提供することしかないのではないか。その際にどのベンダーの機能が組み込まれるのか、またコンテナ向けのvNSPがどういう形で実現するのか、引き続き注目したい。