はじめに
過去に社内で複数回「パブリッククラウドと仮想アプライアンス型ファイアウォール」の話をしてきたので、自分の頭の整理もかねて改めてまとめました。
仮想アプライアンス型ファイアウォールが必要な理由
パブリッククラウドでは、インスタンス単位で適用できるファイアウォールが提供されています。AWS であれば Security Group、Azure であれば Network Security Group です。にもかかわらず、さまざまなネットワークベンダが仮想マシン上で動作するアプライアンス型のファイアウォール（ Network Virtual Appliance、通称 NVA ）をリリースしています。
インスタンス単位のファイアウォールか存在しているにもかかわらずパブリッククラウド上で NVA が必要になる主なユースケースは次の通りです。
1. FQDN で通信を制御したい
ホスト型ファイアウォールは、IP アドレスによる通信制御のみをサポートします。そのため、FQDN で通信を制御できません。社内との通信を制御するだけであれば IP アドレスのみで十分ですが、インターネットとの通信を制御しようとすると 通信先によっては FQDN による通信制御が必要になる場合があります。
2. 通信制御を集中管理したい
ホスト型ファイアウォールだけで通信を制御すると、ホスト型ファイアウォールを設計する担当者の力量によって通信制御のレベルが変わる可能性があります。ネットワーク型ファイアウォールを通信経路上に設置すれば、ホスト型ファイアウォールの設定が穴だらけであっても、ネットワーク型ファイアウォールで通信制御のレベルを担保できます。
3. UTM 機能を利用したい
ホスト型ファイアウォールは、IP アドレスとポート番号をもちいたレイヤ4の通信制御を提供します。アンチウイルスやスパム対策、ウェブフィルタなどの UTM 機能は提供されません。これらの機能を利用した通信制御を行いたい場合は、ネットワーク型ファイアウォールが必要です。
冗長化方式
ネットワーク型のファイアウォールを設置するには冗長化が必要不可欠です。シングル構成の NVA は仮想ネットワーク全体の単一障害点になってしまいます。
ただし、NVA の冗長化方式にはパブリッククラウドならではのクセがあります。クセが生み出される理由は、パブリッククラウドが OS 上で動作する仮想アドレスを認識しないことです。
オンプレミスのアプライアンスは、アプライアンスがサポートする冗長化方式を使うことで可用性のある仮想アドレスを作り出します。そして、周辺機器がこの仮想アドレスを利用してルーティングテーブルすることでネットワーク全体の可用性を担保します。
パブリッククラウドでは、クラウドベンダの用意する物理ネットワークの上に、ソフトウェアで仮想ネットワークが構築されます。ソフトウェアが認識する範囲はソフトウェアが作り出した仮想ネットワークや仮想マシンまでであり、仮想マシンの中で動作する OS 独自のネットワーク設定を認識しません。そのため、オンプレミスと同じように OS 上で仮想 IP アドレスを作ったとしても、クラウドベンダ側の仮想ネットワークが仮想 IP アドレスを認識しないため、仮想ネットワークは仮想 IP アドレスを利用してルーティングできません。
そのため、パブリッククラウド上で Network Virtual Appliance を冗長化するためには、クラウドの仮想ネットワークと OS が連動した新たな冗長化方式を実装する必要があります。現時点で実装されている冗長化方式は次の3つです。
1. ロードバランサを利用する
１つ目のアプローチは、パブリッククラウドが提供するロードバランサを利用する方式です。2台の NVA が仮想アドレスを共有できないのなら、ロードバランサを利用して2台の NVA にパケットを届けることで可用性を担保しようというアプローチです。Azure のロードバランサには全てのポートを負荷分散する HA ポートという機能があります。この機能を利用すれば、仮想アドレスを利用しなくても二台の NVA にパケットを転送できます。
ただし、パブリッククラウドのロードバランサはリソースを効率的に利用することを目的にデザインされているため、全ての通信を片方のインスタンスだけに転送する、いわゆる片寄ができません。原則として、ロードバランサは2台の NVA にパケットを分散してしまいます。その結果、行きと戻りのパケットが異なる NVA を経由する非対称ルーティングになるリスクがあります。NVA をステートフルファイアウォールとして動作させる場合、非対称ルーティングのパケットは破棄されてしまうので通信が成立しません。
非対称ルーティングのイメージ
戻りのパケットが同じ NVA を経由するように、パケットが NVA を通過した時点で送信元 IP アドレスを NVA のアドレスで送信元 NAT 変換するというアプローチもあります。ですが、送信元 NAT には、実際の送信元IPアドレスが分からなくなる、NATをサポートしないアプリケーションがあるといった課題があります。ご利用は計画的に。
送信元NATによる対象ルーティング
2. ルーティングを切り替える
２つ目のアプローチが、ルーティングテーブルを使う方法です。
パブリッククラウドの仮想ネットワークにはルーティングテーブルの機能があり、仮想マシンが発信したパケットの転送先をユーザが自由に指定できます。パケットのネクストポップを NVA のIPアドレスにすることで仮想マシン同士の通信を NVA で制御できます。ただし、ルーティングに重み付けが設定できないため、ネクストポップは常に１つになってしまいます。前述の通り仮想アドレスはつかえないので、ネクストポップは NVA のいずれか1台のアドレスになります。
ルーティングを利用した片寄せ
ネクストホップがいずれか1台になるので、通信は片方の NVA に寄ります。非対称ルーティングになるリスクはありません。そのかわり、ネクストホップに指定されている1台で障害が起きた場合には、ネクストホップを書き換える必要があります。パブリッククラウドはルーティングテーブルの設定を API で変更できるので、ネクストポップに設定されているインスタンスが死んだ場合 API を叩いてネクストポップをもう1台の IP アドレスに切り替えます。
障害時の経路変更
具体的な実装方法は大きく２つです。１つ目は、NVA 以外のサーバで NVA を死活監視して、監視に失敗したらそのサーバが API を叩く実装です。もう１つは、NVA 自身が互いに相手を監視しあい監視に失敗したら NVA 自身が API を叩く実装です。前者の実装は FortiGate で採用されています。後者の実装は Check Pointで採用されています。
- FortiGate
- CheckPoint
3. IPアドレスを付け替える
最後の実装が 仮想マシンの IP アドレスを付け替える方式です。
前述の通り、パブリッククラウドのソフトウェアは、OS 内部に存在するネットワークを認識できません。認識できるのは仮想マシンに割り当てられている IP アドレスだけです。そこで OS だけでなく仮想マシンでも1つの IP アドレスを共有すれば、仮想 IP アドレスを疑似的に再現できます。
具体的には、通常時は1号機の仮想マシンに仮想 IP アドレスを設定しておき、1号機に障害が発生した場合は1号機の仮想マシンから仮想 IP アドレスを削除して、2号機の仮想マシンに仮想 IP アドレスを設定しなおします。仮想ネットワークのルーティングテーブルのネクストホップは付け替えられる IP アドレスを向いているため、通信は片方の NVA に寄ります。非対称ルーティングになるリスクはありません。
IP アドレスの付け替え方は、アプライアンスやパブリッククラウドによって異なります。AWS 上で動作する PaloAlto は NIC ごと付け替えることで IP アドレスの付け替えを実現します。Azure 上で動作する PaloAlto は、NIC に割り当てたセカンダリ IP アドレスだけを付け替えます。
- PaloAlto on AWS
- PaloAlto on Azure
まとめ
パブリッククラウドと仮想アプライアンス型ファイアウォールについて、必要性と具体的な冗長化方法をまとめました。アプライアンスによって実装が大きく異なるので、要件を満たす機能を有しているかを事前に評価することをお勧めします。従量課金型の NVA を使うもよし、ベンダから評価用ライセンスを入手したうえで BYOL 型の NVA を使うもよし、オンプレミスと比較して評価は容易です。評価せずに BYOL のライセンスを買ってしまうと、最悪の場合無駄になります。事前の準備を忘れずに。