AWS Network Firewallのデプロイモデル

この記事は Deployment models for AWS Network Firewall (記事公開日: 2020 年 11 月 17 日) を翻訳したものです。一部更新・加筆しています。

前書き

AWSのサービスと機能は、セキュリティを最優先事項として構築されています。Amazon Virtual Private Cloud（VPC）を使用する際、お客様はネットワークアクセスコントロールリスト（NACL）とセキュリティグループ（SG）を使用してネットワークセキュリティを制御できます。しかし、多くのお客様はディープパケットインスペクション（DPI）やアプリケーションプロトコル検出、ドメイン名フィルタリング、侵入防止システム（IPS）など、それらの範囲を超える要件が求められます。また、大規模なシステムの場合、現在のSGおよびNACLでサポートされているものより多くのルールを必要とします。

このような場合のために、AWS Network Firewallをリリースしました。このサービスは、VPC向けのステートフルなマネージドネットワークファイアウォールおよびIPSサービスです。本サービスは何万ものルールをサポートしています。Network Firewallを初めて知る場合は、こちらの記事を先にご覧ください。Network Firewallの機能や使用例を説明しています。

この記事では、Network Firewallの一般的なユースケースのデプロイモデルに焦点を当てて解説します。

Network Firewallの仕組み

Network Firewallを正しく動作させるためには、トラフィックをNetwork Firewallのエンドポイントに対称的にルーティングする必要があります。このエンドポイントは、AWS PrivateLink のInterface型エンドポイントに似ています。主な違いは、ルートテーブルのターゲットになることができるということです。Network Firewallのエンドポイントは、専用のサブネットにデプロイします。このサブネットをNetwork Firewall サブネットまたは単にFirewallサブネットと呼びます。ユースケースと展開モデルに応じて、Firewallサブネットはパブリックまたはプライベートのいずれかになります。高可用性（HA）およびマルチAZ展開の場合、アベイラビリティーゾーン（AZ）ごとにサブネットを割り当てます。ベストプラクティスとして、Firewallサブネットには他のサービスをデプロイしないでください。Firewall サブネット内にあるサービスに関連したトラフィックは、Network Firewallを通して検査することができません。

ファイアウォールエンドポイントは、AWSコンソール上のVPCルートテーブルのターゲット選択画面においてvpce-idで表示されます。ファイアウォールエンドポイントはAWS Gateway Load Balancerを利用しているため、エンドポイントのElastic Network Interface（ENI）は「gateway_load_balancer_endpoint」タイプとなります。Network Firewallでネットワークトラフィックを検査するには、VPCのルートテーブルを適切に設定してトラフィックをファイアウォールエンドポイントに転送する必要があります。図1では、VPC Ingress Routing機能を使用して、ワークロードがあるサブネットとInternet Gateway（IGW）の間のパスにファイアウォールエンドポイントを挿入しています。この設定については、こちらの記事もご覧ください。

図1の構成ではインターネットへのすべてのトラフィックがNetwork Firewallによって検査および保護されるよう設定しました。ワークロードがあるサブネットをProtected サブネットと呼びます。

図1：単一のAZにデプロイされたNetwork Firewallとパブリックサブネットのワークロードのトラフィックフローとルートテーブル設定

Network Firewallは、トラフィックに対して完全に透過的であり、ネットワークアドレス変換（NAT）を実行しません。送信元と宛先のIPアドレスを保持します。
パケットがNetwork Firewallに到着すると、ルールエンジンに入り、検査されます。ルールエンジンと使用可能なルールの詳細については、ドキュメントを参照してください。

展開モデル

Network Firewallには、複数のデプロイモデルがあります。適切なモデルは、ユースケースと要件によって異なります。大きく次のようなモデルがあります。

分散型：個々のVPCにデプロイするモデル
集約型：East-West（VPCからVPC）やNorth-South（インターネットやオンプレミスへの通信）のトラフィックを集約する検査用VPCにデプロイするモデル
複合型：上記モデルの組み合わせ。例として、インターネットからVPC内への通信は個々のVPCにデプロイしたNetwork Firewallで検査、VPC同士の通信は検査用VPCにデプロイした Network Firewallで検査するようなモデル

デプロイモデルごとに、Network Firewallを他のサービスを組み合わせることができます。例えば、検査後のトラフィックをNAT Gatewayに転送することができます。

分散型の導入モデル

分散型の導入モデルでは、保護が必要な各VPCにNetwork Firewallを導入します。各VPCは個別に保護され、VPCを分離することで影響範囲を小さくします。各Network Firewallは、それぞれ独自のファイアウォールポリシーを持つことができ、また、複数のファイアウォールで共通のルールグループ（再利用可能なルールの集まり）を介してポリシーを共有することもできます。これにより、各Network Firewallを独立して管理することができ、設定ミスの可能性を低減し、影響範囲を限定することができます。

図 2: Network Firewall をそれぞれのVPCにデプロイした構成例

ワークロードやトラフィックパターンに応じて、検討すべきNetwork Firewallの導入モデルがいくつかあります。以下にそれらのモデルをご紹介します。

1) ワークロードとIGWの間のトラフィックを保護する

この展開モデルでは、Network Firewallを使用して、あらゆるインターネット行きのトラフィックを保護します。ワークロードのサブネットには、対応するAZのファイアウォールエンドポイントへのデフォルトルートがあります。Firewallサブネットには、IGW経由のデフォルトルートがあります。Network FirewallはNATを行わないため、インターネットへの出入りは、ワークロードサブネット内の個々のElastic Network Interface（ENI）に関連付けられたパブリックIPまたはEIPに依存します。IGWではVPC Ingress Routingを利用して戻りのトラフィックを対応するAZのファイアウォールのエンドポイントに誘導します。これにより、トラフィックは正しいファイアウォールエンドポイントに対称的に戻され、ステートフルトラフィックインスペクションを維持することができます。

図3: マルチAZでインターネット行きの通信を保護するアーキテクチャとルートテーブル設定例

2) パブリックサブネット内のAWSサービスとIGWの間のトラフィックを保護する

Network Firewallは、Application Load Balancer (ALB)やNAT GatewayなどのAWSサービスを保護するためにも導入できます。ALBでは、バックエンドのターゲットをプライベートサブネット内に配置することができます。ALBとインターネットの間のトラフィックは、バックエンドターゲットに配信される前にNetwork Firewallによって検査されます。同様に、NAT Gatewayは保護されたパブリックサブネット内に配置することができます。NAT Gatewayは、プライベートサブネットのルートテーブルのデフォルトルートテーブルのターゲットです。NAT Gatewayとインターネット間のトラフィックは検査されます。マルチAZを維持するために、NAT Gatewayも各AZに配置されます。

図4：マルチAZでインターネットとALB/NAT Gateway間のトラフィックを検査するアーキテクチャとルートテーブル設定例

なお、図4のALBやNAT Gatewayでは、ワークロードのソースIPはNAT GatewayまたはALBのソースIPとなります。ワークロードのソースIPで検査する必要がある場合は、この記事で後述するインターネットのEgressとIngressの集約型の展開モデルを使用してください。

集約型の展開モデル

集約型の展開モデルでは、AWS Transit Gatewayと連携することが前提となります。Transit Gatewayはネットワークハブとして機能し、VPC間やオンプレミスのネットワークをシンプルに接続できます。また、Transit Gatewayは、他のTransit Gatewayとリージョン間ピアリング機能を有し、AWSバックボーンを利用したグローバルネットワークを構築します。

集約型のもう一つの大きな特徴は、検査用VPCです。検査用VPCは、各AZの2つのサブネットで構成されています。1つはファイアウォールのエンドポイント専用サブネット、もう1つはTransit Gatewayのアタッチメント専用サブネットです。図5は、3つのAZを持つAWSリージョンが検査用VPCのために合計6つのサブネットを持つ例を示しています。これはマルチAZの構成です。

各Transit Gatewayのサブネットには、トラフィックが同じAZ内のファイアウォールのエンドポイントに転送されるように、専用のVPCルートテーブルが必要です。これらのルートテーブルには、同じAZ内のファイアウォールエンドポイントを指すデフォルトルート（0.0.0.0/0）があります。

図5：検査用VPCの概要

ファイアウォールエンドポイントからの戻りトラフィックについては、単一のルートテーブルが設定され、Transit Gatewayに向かうデフォルトルートが含まれています。トラフィックは、Network Firewallで検査された後、同じAZでTransit Gatewayに戻されます。図6は、検査用VPCのトラフィックフローを示しています。

図6：Transit Gatewayから検査用VPCへのトラフィックフロー

Network Firewallはネットワークトラフィックに対して透過的であるため、検査用VPC CIDRをルーティングする必要はありません。この例では、CGNAT用のIPアドレス(100.64.0.0/16)を使用しています。検査用VPCに他のワークロードを使用しないでください。検査用VPCの内部では、Network Firewallがステートフルなトラフィック検査機能を維持します。これは新機能により可能になりました。Transit Gatewayのアプライアンスモードです。この機能は、リターントラフィックが同じAZで処理されることを保証します。このドキュメントに従って、必ず有効にしてください。有効にしないと、正常に通信ができません。

専用の検査用VPCは、VPCやインターネット、オンプレミスネットワーク間のインスペクションを管理する一元的VPCです。ファイアウォールポリシーとルールグループは十分なRule Group Capacityを利用できるようにして、将来的にルールが増えることに備えてください。また、このアーキテクチャは送信先と送信元のIPアドレスが保持されます。

それでは、集約型のデプロイモデルの様々なパターンを見ていきましょう。以降ではシングルAZの場合を例として説明していきますが、前述の通りマルチAZの際にはTransit Gatewayのアプライアンスモードを有効化する必要があることをご留意ください。

注：HOME_NETルールグループ変数は、ステートフルドメインリストやSuricata互換のIPSルールグループで処理対象となるソースIP範囲を定義するために使用されます。デフォルトでは、ファイアウォールのエンドポイントが配備されているVPCのCIDRに設定されています。このモデルでは、VPCやオンプレミスネットワークのすべてのCIDR範囲を処理の対象とするために、この変数を拡張する必要があります。詳細はドキュメントを参照してください。

1) East-Westトラフィック検査モデル

図7：VPC間のトラフィックを検査用VPC集約して保護する展開モデル

このモデルは、East-West( VPC同士の通信)のトラフィックを検査する要件をカバーしています。例えば、Transit Gatewayを使用して同じまたは異なるAWSアカウントのVPC同士を接続する場合です。

このモデルでは、VPC間のすべてのトラフィックが検査用VPCを通過するように、同じTransit Gateway内で2つのルートテーブル（図7に「Firewall Route Table」と「Spoke Inspection Route Table」として示されています）を使用します。すべてのスポークVPCはスポーク検査用のルートテーブルに関連付けられており、検査用VPCのアタッチメントにデフォルトルートが設定されています。すべてのスポークVPCのルートはTransit Gatewayのファイアウォールルートテーブルに伝搬され、パケットがSpoke VPCに戻る経路を確保します。

図8に示すように、Transit GatewayのInter-Region Peering機能を使用して、他のAWSリージョンへのトラフィックの検査にも同じモデルを使用できます。リモートのAWSリージョンはスポークとして扱われます。

図8：AWSリージョンAのVPCとAWSリージョンBのVPC間のトラフィックが、Transit GatewayによってNetwork Firewallに集約され保護されている様子

2) North-Southのトラフィック保護：Transit GatewayとDirect Connect GatewayおよびAWS Site-to-Site VPNを経由したオンプレミスとの接続

前述のモデルを拡張し、Transit Gatewayを経由したVPCとオンプレミス間のNorth-Southトラフィックの検査をご説明します。Transit Gatewayは、AWS Direct ConnectまたはAWS Site-to-Site VPNを介してオンプレミスに接続できます。

このモデルの重要な要件は、Transit VIFを使用してAWS Direct ConnectをTransit Gatewayに接続することです。オンプレミスへのVPNの場合は、AWS Site-to-Site VPNも使用でき、図9のようにTransit Gatewayを構成する必要があります。

図9: VPCとオンプレミス間のトラフィックを集約し、Network Firewallにより保護する構成例

Transit Gateway のルートテーブルでは、Direct ConnectやSite-to-Site VPNをSpoke Inspection Route Tableにアタッチし、Spoke VPCと同様に扱います。検査用VPCからの戻りの通信を正常に機能させるには、図9に示すように、Direct Connect GatewayやSite-to-Site VPNから受け取った経路情報をFirewall Route Tableに伝播させます。

ここではAWS Client VPNのユースケースについては説明しませんが、AWS Client VPNをスポークVPCの1つに関連するワークロードと考えることができます。AWS Client VPNは、関連するVPCのサブネットごとにENIを作成し、リモートクライアントからのトラフィックはENIのIPにNATされます。これにより、トラフィックはスポークVPC内の他のワークロードと同様に、Network Firewallによってルーティングされ、検査されます。

3) North-Southのトラフィック保護：インターネットゲートウェイの集約

このモデルでは、Transit Gatewayに接続されたVPCやオンプレミスからのインターネットトラフィックを集約して検査します。出口集約用VPC(Central Egress VPC)を用意し、IGWにアクセスできるパブリックサブネットにNAT Gatewayを設定しています。

Spoke VPCやオンプレミスから発生したトラフィックは、検査用VPCに転送されて処理されます。その後、Transit GatewayのFirewall Route Tableにあるデフォルトルートを使用して出口集約用VPCに転送されます。デフォルトルートは、図10に示すように、出口集約用VPCのアタッチメントをターゲットに設定されています。

NAT Gatewayを使用すると、Spoke VPCのプライベートサブネットにあるワークロードを、インターネットやパブリックIP空間にあるAWSサービスに接続できるようになります。また、NAT Gatewayの代わりに、NATインスタンスやAWS Marketplaceのパートナーソリューションを使用することもできます。AWS Network Competency Programに掲載されている様々なパートナーについての詳細情報をご覧いただけます。

図10: Network Firewallによって検査したトラフィックを、出口集約用VPC(Central Egress)にルーティングする構成例

なお、Network Firewallを中央の出口集約用VPCに導入することも可能です。これは複合型の導入モデルで説明します。

4) North-South: Transit GatewayとNLB/ALBまたはリバースプロキシによるインターネットからの通信の一元化

AWSの外部から流入するトラフィックを一元化することが可能です。このシナリオでは、Web Application Firewall（WAF）やサードパーティのLoad Balancer（LB）などのマーケットプレイスのネットワークアプライアンスが、Ingress VPCに展開されます。このアプライアンスは、通信を終端し、バックエンドインスタンスへの新しい接続を確立します（リバースプロキシとも呼ばれます）。この方法では、クライアントとサーバーの間にアプリケーションロジックを導入することができ、また、セキュリティ目的で使用することもできます。ALBやNLBなどのAWSサービスをこの構成で導入することも可能です。ただし、このモデルでは、クライアントのソースIPアドレスが保持されず、ソースIPアドレスは通信を終端するアプライアンスのIPアドレスとなります。そのため、送信元IPアドレスベースで制御するセキュリティ機能を利用する場合は注意が必要です。なお、ALB/NLBのターゲットはインスタンスIDではなくIPアドレス指定になります。

図11は、集約管理型の導入モデルにおいて、Ingress VPCとNetwork Firewallを組み合わせた場合のアーキテクチャを示しています。

図11: ALBからバックエンドワークロードに送信されるトラフィックがInspection VPCのNetwork Firewallで検査される構成

なお、Network Firewallを中央の出口集約用VPCに導入することも可能です。これは複合型の導入モデルで説明します。

集約型と分散型を組み合わせた複合型の導入モデル

集約型と分散型を組み合わせた複合型の導入モデルでは、Network Firewallを、検査用VPCに加えてローカルなインターネットの出入口を必要とする各VPCにも導入することができます。このモデルでは、ワークロードはローカルIGWを使用し、検査用VPCを介して内部ネットワーク（VPC、オンプレミス）に接続することができます。このようなVPC内のプライベートサブネットには、出口集約用VPCを使用することもできます。

1) 特定のVPCにインターネット用の独自のIGWを構成し、専用のNetwork Firewallで保護する

パブリックサブネットは、Network Firewallで保護することができます。このアーキテクチャでは、ALBやNLBなどのロードバランサーは、ターゲットIPを追跡するための追加の設定をすることなく、EC2 Auto Scaleグループのコンテナやアプリケーションをターゲットにすることができます。NAT Gatewayを使用してプライベートサブネットに独自のIGWを設置することもできますが、出口集約用VPCがコスト面で勝る場合に導入を検討できます。図12では、パブリックサブネットを保護するために、Spoke VPC BがローカルのIGWとファイアウォールのエンドポイントを備えています。

図12:専用のNetwork Firewallで保護された独自のIGWを持つSpoke VPC B

2) East-Westの検査用VPCとインターネット出口集約用VPCの併用

お客様の中には、集約化したインターネット通信をNetwork Firewallで保護しつつ、VPC同士のトラフィックには別のNetwork Firewallを使用したいと考える方もいらっしゃるでしょう。このアーキテクチャでは、トラフィックがVPC同士の検査用VPCを使用せずにインターネット出口集約用VPCに直接行くため、データ処理コストの削減という観点で効果があります。

図13：North-Southトラフィック用の集約インスペクションVPCとインターネット出口集約用VPC用の専用Network Firewall

それぞれのモデルの比較

次の表は、お客様のユースケースに最も適したデプロイメントモデルを決定するのに役立ちます。

	分散型	集約型	複合型
East-WestのVPC同士の通信	非対応	対応	対応
North-Southのインターネット通信	対応	対応	対応
North-SouthのオンプレミスやDirect connect、 VPNの通信	非対応	対応	対応
集中管理	AWS Firewall Managerで複数の Network Firewallを管理	一つのNetwork Firewallで管理	AWS Firewall Managerで複数の Network Firewallを管理
送信元IPアドレスの保持	構成次第で保持	保持	構成次第で保持
設定ミスのリスクと被害範囲	各VPCに留まる	集約している対象の通信に影響	各VPCや、集約している対象の通信に影響
コスト	・Network Firewall Endpoint ごとの料金・Network Firewallの通信料金	・Network Firewall Endpoint ごとの料金・Network Firewallの通信量・Transit Gatewayのアタッチメントごとの料金・Network Firewallの通信料金	・Network Firewall Endpoint ごとの料金・Network Firewallの通信量・Transit Gatewayのアタッチメントごとの料金・Network Firewallの通信料金

検討事項

Network Firewallは、サブネット/AZごとに1つのファイアウォールエンドポイントで表現されていますが、AWS Hyperplane技術に基づいており、高い可用性を備えています。Network Firewallの単一コンポーネントの障害がAZの障害を引き起こすことはありません
トラフィックが同じAZ内で検査されるように、ワークロードが使用するすべてのAZにファイアウォールエンドポイントが展開されていることを確認してください
Transit Gatewayは、データ処理コストとアタッチメントコストがかかります。Transit Gatewayは、集約型および複合型の展開モデルに必要です
Network Firewallのエンドポイントごとにコストがかかります。多数のAmazon VPCがある場合は、複合展開モデルの使用を検討してください。Network Firewallエンドポイントは、必要な場所にのみ展開してください
Network Firewallは、VPC Peeringにより接続されたVPC間や、Virtual Private Gateway(VGW)を使用してVPCに直接接続されたオンプレミスネットワークのトラフィックを検査することはできません。また、同じVPC内にあるワークロードサブネットとTGWアタッチメントの間にも導入することはできません。検査用VPCは、Transit Gatewayでトラフィックを集約することで実現できます。ただし、検査用VPCはトラフィックの送信元や送信先になることはできません
Network Firewallは、ブランチオフィス間のトラフィックがAWSを通過する際に検査するためにも使用できます。導入モデルは集約型と似ており、各ブランチオフィスには固有のTransit Gatewayアタッチメントが必要です

まとめ

Network Firewallは、様々なユースケースで大規模にトラフィックを透過的に検査する機能を提供します。正しい導入モデルは、求める結果によって異なります。Network Firewallは、単一のVPCまたは複数のVPCアーキテクチャに導入することができ、分散型および集約型の両方の導入モデルでトラフィック要件に合わせて拡張することができます。これは、VPCやAWS Hyperplaneのような独自に設計されたSDN基盤とNetwork Firewallを組み合わせることで実現されます。一元化された管理とトラフィック検査は、多くのネットワークセキュリティ機能を必要とする大規模な組織にとって有益なものとなります。

Shakeel Ahmad

Shakeel Ahmadは、オーストラリアのメルボルンを拠点とするシニアソリューションアーキテクト
で、ネットワークとクラウドインフラストラクチャを専門としています。コンピュータサイエンス
の理学士号とネットワークシステムの理学修士号を取得しています。テクノロジーに情熱を注ぎ、
お客様がAWS上でart of the possible（可能性の芸術）を採用するためのソリューションを構築す
る支援をしています。

Evgeny Vaganov

Evgeny Vaganovは、AWSのアジア・パシフィック・ジャパン(APJ)地域のシニア・スペシャリスト
・ソリューションズ・アーキテクト(ネットワーキング)です。それ以前は、オーストラリアとニュージ
ーランドのお客様のクラウド導入をサポートしていました。学習と実験に情熱を注ぎ、クラウドネッ
トワーキングを誰もが簡単に使えるようにすることを目標としています。

本ブログは、ネットワークソリューションアーキテクトの奥村が翻訳しました。原文はこちらです

Amazon Web Services ブログ