各パブリッククラウドでの3rd partyのFWインスタンスを用いた構成方法についてまとめました。
ドキュメント調べただけの机上知識＆仕様変更の多いサービスなので読み物程度として鵜呑みにしすぎないようにしてください。実現性に関しては別途検証したらまた記事にしようとおもいます。
なるべく推奨構成を取ろうとしていますが、こんなシンプルな構成のサービスは存在しないので所々独断が混じっています。
本記事で実現したい構成
・インターネットからパブリッククラウド上の公開サーバへアクセスする(今回はhttpを想定)
・同クラウド上に仮想FWインスタンスを構築し、上記アクセス時には必ず経由するようにする
※Fortigate,Paloaltoの資料を参考に、両製品とも概ね共通の構成を取るとの認識のもと記載しています。
本記事での着目ポイント
FWを挟まない場合は基本公開するwebサーバのインスタンスにPrivate IP, Public IPを紐づけてクラウドサービス側でDNATされるが、FWが手前にある場合にどういったNAT設定、ルーティング設定が必要かを比較する。
仮想FWインスタンスの基本構成
仮想FWインスタンスはクラウドサービスのドキュメント上では「Network Virtual Appliance」や「middle box appliance」と言った呼称で言及される。基本的にクラウドサービスのインスタンスにFW製品のOSを搭載する形で実装する。
インスタンス上でのルーティングを可能にするため、FWインスタンスのもつすべてのNICに対して「送信元/宛先チェック」の類の設定を無効化する必要がある。
PAやFortigateのリファレンスアーキテクチャとして出てくるものは概ね以下の３セグメントにNICを構えた構成。HAを利用する場合はHAセグメント分にもう1つのセグメント&NICが必要。
AWSは例外で、external(internet側)のsubnetのNICでmanagemantアクセスも兼用する2セグメント構成がリファレンスアーキテクチャとして見受けられる。
AWS編
(参考)Reference Architecture
Paloalto: https://www.paloaltonetworks.jp/apps/pan/public/downloadResource?pagePath=/content/pan/ja_JP/resources/whitepapers/aws_reference_architecture
Fortigate: https://www.fortinet.com/content/dam/fortinet/assets/white-papers/wp-aws-reference-architecture.pdf (英語)
構成図
Reference Architectureから以下が推奨構成と考えられる。（アクセス制御は適切に設定されているとして省略）（管理インターフェース関連も省略）
NAT
Public IPはFWのインスタンスが持つため、Internet Gateway, FWの2段階のNATが必要となる。
この構成ではwebサーバ1台についてNATを書いているが、サーバ台数が多い場合以下が考えられる。
・FWのENIにIPアドレスを追加する(セカンダリプライベートIPアドレス)→ instance type毎に上限あり(数十程度)
・上記上限に達した場合、同一IPでポートを使い分ける(ポートフォワーディング)
ルーティング
シンプルに通信可能であることを前提に検討。
セキュリティ観点では送信先サブネットの性質によっては転送させず破棄にしてしまう等もありうるかも。
ゲートウェイルートテーブルはターゲットに"ミドルボックスアプライアンスのネットワークインターフェイス"が設定可能とドキュメントに記載があるため、VPCに入ってくるトラフィックすべてをFWにインターセプトするような構成も可能かと考えられる。（この構成に関してはOCI編に記載。）
調査範囲のAWSのアーキテクチャ資料ではインターセプトする構成は見かけられなかった。
インバウンド
インターネットからのインバウンド通信について、本構成では特段変わったルーティングは不要。
① IGWでDNATを実施
② 宛先をゲートウェイルートテーブルから検索し、ターゲット「Local」のため、直接DNAT後の宛先（FW/untrust ENI）へ転送
③ FWにてDNATを実施
④ FWのルーティング設定より、FW/trust ENIへ転送
⑤ trustサブネットのルートテーブルから、DNAT後の宛先(webサーバ)のターゲットが「Local」のため直接webサーバへ転送
アウトバウンド(戻り)
Privateサブネットのルートテーブルにおいて、インターネット向け(0.0.0.0/0)のターゲットをFW/trustのENIとすることでFWを経由させる設定が必要。
Azure編
(参考)Reference Architecture
PaloAlto： https://www.paloaltonetworks.jp/apps/pan/public/downloadResource?pagePath=/content/pan/ja_JP/resources/whitepapers/azure_reference_architecture
Fortigate: https://github.com/fortinet/azure-templates/tree/main/FortiGate/A-Single-VM
構成図
（アクセス制御は適切に設定されているとして省略）（管理インターフェース関連も省略）
NAT
構成図下部に記載の通り、internet→Azureに入るタイミング, FWの2か所でNATを実施する。
仮想アプライアンスにPublic IPを紐づけた場合、AWS/OCIでいうところのInternet Gatewayのような明示的なゲートウェイサービスは存在しない。（はず、自信がない部分なので有識者の方はコメントいただけると有難いです）
サーバ台数が多い場合の対処はAWS編と同様となる。
・FWのNICにIPアドレスを追加する(セカンダリIPアドレス)→ NICあたり256個のIP設定が可能(すごい)
・上記上限に達した場合、同一IPでポートを使い分ける(ポートフォワーディング)
ルーティング
ほぼAWSと同様。
明示的なゲートウェイがない分、インターネットからVNETへ入ってくる通信のルーティングが不可能である。強制的にNAT後のPrivate IPへ転送されるため、OCI編で記載するインターセプト構成は取れないと思われる。
OCI編
(参考)Reference Architecture
ns-inboundと書いてある構成を参考
Paloalto: https://docs.oracle.com/en/solutions/secure-app-palo-alto-firewall/index.html#GUID-CB6D7F26-0DEA-4B27-A265-E6169D8992E9
Fortigate: https://docs.oracle.com/ja/solutions/secure-oci-workloads-fortigate/index.html#GUID-40CF25A9-E13A-4C92-8E21-D395920BB46A
※PAはPAでNATをしている記載あり、fortiはNATの言及なし(但し、untrustサブネットがPublic IPを持つと記載)なのですが今回はFWインスタンスでNATはしない構成を考えていきます。
構成参考：https://docs.oracle.com/ja/solutions/oci-network-firewall/index.html#GUID-875E911C-8D7D-4205-952B-5E8FAAD6C6D3
上記はOCIサービスのNetwork Firewallのinboundネットワークの構成。Network FirewallをそのままFWインスタンスに置き換えた形が今回記載する構成。OCIのNetwork FirewallはNAT機能がない。
構成図
（アクセス制御管理インターフェース関連省略）
NAT
AWS編、Azure編の構成と異なり、webサーバのVNICのPrivate IPに対してPublic IPを紐づける。
Internet Gatewayにおいて1回だけNATを行う。
FWにPublic IPを持たせる必要がないので、サーバ台数多くても特に数量制限等困らないはず。
ルーティング
インターネットからVCNへの通信に対してゲートウェイルート表でルーティング指定ができるため、webサーバのNICに直接転送せずにFWアプライアンスをネクストホップとして経由させることができる。
インバウンド
通信フローは以下。
①Public IP宛の通信がIGWに着信
②IGWにてPublic IP→Private IPへNATを実施
③IGWのルート表に従い、Private IP宛の通信をFWへ転送
④FWにてポリシー適用、trust側NICへ転送
⑤Trustセグメントからwebセグメントへルーティング(VCN内ルーティング)
⑥サーバに着信
アウトバウンド(戻り)
①サーバから送信元を宛先として発信
②サーバのセグメントのルート表に従い、FWのtrust側NICへ転送
③FW内処理、untrust側NICへ転送
④untrustセグメントのルート表に従い、IGWへ転送
⑤IGWにてPrivate IP→Public IPへのNATを実施
⑥インターネット側へ転送
おわり
Azure NWの癖がつよい（個人の感想）
各サービス自前のFWやWAFを利用するのがシンプルでよいと思いますが要件合わない場合にアプライアンス製品を検討することがあるかもしれません。きちんと利用するならAD/AZでインスタンス冗長化する必要あり→それに伴い手前にLBが必要、フローティングIPが必要、クラスタ設定の類が必要等、OS側/クラウド側ともに構成が複雑化していきます。ベンダーに聞きましょう。