インターネットからのイングレストラフィックフローのためのファイアウォールのデプロイ設計

この記事は Design your firewall deployment for Internet ingress traffic flows （記事公開日：2021 年 2 月 21 日）を翻訳したものです。一部更新・加筆しています。

前書き

インターネットに接続するアプリケーションを公開するには、外部の脅威や不要なアクセスから保護するためにどのようなセキュリティ管理が必要かを慎重に検討する必要があります。これらのセキュリティ管理は、アプリケーションの種類、環境の規模、運用上の制約、または必要な検査のレイヤによって異なる場合があります。ネットワークアクセスコントロールリスト (NACL) とセキュリティグループ (SG) を実行すると十分な保護が得られる場合や、追加のファイアウォールコンポーネントが必要になる場合があります。

NACL や SG 以外にも、AWS Web Application Firewall (AWS WAF) をデプロイしたり、サードパーティのセキュリティアプライアンスを AWS ネットワークに導入したりすることもできます。AWS Network Firewall や AWS Gateway Load Balancer などの新しいサービスの追加により、AWS でのファイアウォールアーキテクチャの設計における柔軟性がさらに高まりました。

各サービスのさまざまなアーキテクチャオプションについては、過去のブログ記事「 VPC ルーティングの機能強化とネットワークファイアウォールのデプロイモデル」、「AWS Gateway Loadbalancer と Transit Gateway を使用した集中型のインスペクションアーキテクチャ」、「AWS WAF による多層防御」（いずれも英語版のみ）で説明されています。また、DDoS 耐障害性のベストプラクティスを取り上げたホワイトペーパー（英語のみ）も公開されておりますので、適宜ご参照ください。

このブログ記事では、インターネットに接続するアプリケーションへのインバウンドトラフィックを保護するためのさまざまなファイアウォールオプションに関するネットワークアーキテクチャについて説明します。このブログ記事では、インターネットからのイングレスフロー（例：インターネットから VPC）に着目します。その理由は、関連するネットワークのデプロイオプションは要件によって大きく異なる場合があり、最大限考慮することが必要であるためです。下りフロー (VPC からインターネットへ) および East/West (VPC から VPC 、または VPC からオンプレミス) の検査パターンは十分に確立されており、上記のリンク先の以前のブログ記事で詳しく説明されています。

なぜ、イングレストラフィックのフィルタリングのために NACL やセキュリティグループ以上のことが必要なのか？

NACL とセキュリティグループはどちらもファイアウォールとして動作します。NACL はステートレスで、サブネット境界を保護します。セキュリティグループはステートフルなので、すでに許可されたフローへのリターントラフィックは自動的に許可されます。セキュリティグループは、サブネットに関係なく Elastic Network Interface に適用されます。

多くの場合、これらのセキュリティ制御で十分ですが、追加のセキュリティ制御が必要になる場合もあります。以下に、追加のファイアウォールが必要となる主な理由のいくつかを示します。

スケール

NACL では最大 40 個のルールエントリ（デフォルトは 20 個）、SG では 1,000 個のルールエントリ（デフォルトで 60）が許可されます。これらのクォータを超える場合は、追加のコントロールポイントを実装する必要があります。たとえば、AWS Network Firewall はデフォルトで 30,000 個のステートフルルールエントリをサポートします。

検査レイヤ

NACL とセキュリティグループはどちらもネットワークレイヤとトランスポートレイヤで動作します。つまり、IP アドレス、プロトコル、ポートに基づいて制御を適用できますが、アプリケーションパラメータにはルールを適用できません。また、アプリケーショレイヤの検査はサポートされていません。例えば、HTTP/S 接続のペイロード情報に基づくフィルタリング (特定の HTTP ヘッダーに基づくブロック) を適用する必要がある場合は、AWS WAF を使用できます。

集中管理

大規模な分散環境では、複数の VPC やアカウントにデプロイされたセキュリティグループと NACL を集中的に制御することが困難な場合があります。追加のファイアウォールを必要としない解決策の 1 つは、AWS Firewall Manager Service を使用してセキュリティグループの制御と監査を一元化することです。別の方法として、ファイアウォール (AWS ネイティブまたはサードパーティ) を実行して、中央のセキュリティチームがルールを管理することもできます。十分な自動化がなければ、このアプローチでは新しいアプリケーションを導入する際に運用上のボトルネックが生じる可能性があることに注意が必要です。

ファイアーウォールによるイングレスフィルタリングの考慮事項

ファイアウォールソリューションを決定する際には、基本機能以外にも考慮すべき事項が数多くあります。以下に、ソリューションをネットワークに導入する方法に影響するエリアをいくつか示します。

アプリケーションタイプ

検討中のソリューションは対象となるアプリケーションタイプをサポートしますか？　たとえば、Web Application Firewall は HTTP/S アプリケーションの保護には優れていますが、他の種類のトラフィックには適していません。複数の種類のアプリケーションがある場合は、そのすべてをカバーしたり、異なるファイアウォールソリューションを組み合わせたりできるファイアウォールが必要になることがあります。

環境サイズ

イングレストラフィックに対してファイアウォール保護を必要とする VPC が 1 つまたは複数ありますか？　マルチ VPC、マルチアカウント環境では、ファイアウォールを分散する (各 VPC には独自のデータプレーンパスと固有のファイアウォールを設置する) か、一元化する (トラフィックが別の VPC 内のアプリケーションに転送される前にセキュリティスタックをホストする単一の VPC を通過する) かを決定する必要があります。

検査のレイヤ/暗号化

ファイアウォールインスペクションはパケットのどのレイヤまで適用すべきですか？　たとえば、ネットワークレイヤに基づいてルールを適用すれば十分ですか？　それともアプリケーションレイヤの検査も必要ですか？　インターネット上のトラフィックの大部分は暗号化されています。アプリケーションレイヤでそのトラフィックを検査するには、トラフィックを復号化できるファイアウォールアプライアンスが必要です。

運用/自動化

AWS ネットワークにファイアウォールを追加すると、運用上のオーバーヘッドが発生します。どのようなソリューションを選んでも、そのソリューションを大規模に管理し、自動化と統合ができることを確認する必要があります。たとえば、AWS Network Firewall と AWS WAF は、複数の VPC や AWS アカウントにデプロイされている場合でも、AWS Firewall Manager を使用して一元的に管理できます。適切な自動化を行わないと、運用上のボトルネックが生じ、アプリケーションのデプロイに時間がかかる可能性があります。

IPv6 サポート

以下に示すすべてのアーキテクチャが IPv6 をすでにサポートしているわけではありません。IPv6 トラフィックのイングレスフィルタリングをサポートする必要がある場合は、AWS のドキュメントで最新の更新を確認する必要があります。

以下で説明するアーキテクチャは、接続フローに基づいて分割されており、分散型と集中型のデプロイメントについて解説されています。

分散型デプロイメントのアーキテクチャ

分散型イングレスアーキテクチャは、各 VPC が専用のインターネットゲートウェイ (IGW) を経由してインターネットに出入りする独自のパスを持つことに依存しています。つまり、VPC が 1 つでも複数でも、イングレストラフィックのデータパスはそれぞれ同じになります。このアプローチにより、管理が容易になり、障害時の影響範囲 (blast radius) が減少し、トラブルシューティングが簡素化されます。

イングレストラフィックを分散しても、エグレストラフィックも分散する必要があるというわけではありません。これらのトラフィックは個別に取り扱うことができます。Elastic Load Balancing (特に Network、Classic、Application Load Balancer) を介して環境に入ってくるトラフィックは、常にそのロードバランサーを経由して戻ります。VPC からインターネットへのトラフィックは、別のパスをたどることができます。

次のセクションでは、ネイティブおよびサードパーティのさまざまなファイアウォールソリューション向けの分散型アーキテクチャについて説明します。また、ファイアウォールサービスにトラフィックを流す方法、複数の VPC にまたがるスケーリング方法、ソースクライアント IP アドレスの可視性など、各オプション間の主な違いについても説明します。各アーキテクチャは、インターネットから VPC でホストされているアプリケーションへのトラフィックの流れを示しています。

AWS WAF

Figure 1. AWS WAFの分散型デプロイメント

トラフィックをファイアウォールに誘導する:

AWS WAF は、Application Load Balancer(ALB)、Amazon CloudFront、Amazon API Gateway、AWS AppSync (注：最後の 2 つは図中に示されていない) と直接統合されます。トラフィックの検査を開始するには、既存の ALB または CloudFront ディストリビューションでサービスを有効にする必要があります。

アプリケーションの種類と暗号化:

AWS WAF は HTTP/S アプリケーションのみをサポートします。ALB と CloudFront の両方が TLS を終了し、WAF が暗号化されていないトラフィックにアクセスできるようにします。

複数の VPC へのスケーリング:

複数の VPC にわたってサービスをデプロイする場合は、アプリケーションに使用される各 Application Load Balancer または CloudFront ディストリビューションで WAF を有効にします。AWS Firewall Manager を使用すると、複数の WAF デプロイにわたってポリシーを一元的に管理および適用できます。

クライアント IP アドレスの可視性:

AWS WAF は CloudFront または ALB に接続しているクライアントの実際の IP アドレスにアクセスできます。この IP アドレスは、宛先のバックエンドまで IP パケットに保持されるわけではないことに注意が必要です。ALB と CloudFront は、トラフィックをバックエンドに転送するときに X-Forwarded-For HTTP ヘッダーに実際のクライアント IP を含めます。

AWS Network Firewall

Figure 2. AWS Network Firewall の分散型デプロイメント

トラフィックをファイアウォールに誘導する:

AWS Network Firewall は、「Bump-in-the-Wire」として透過的にトラフィックに挿入されます。AWS Network Firewall エンドポイントとして、アベイラビリティーゾーンごとに 1 つずつ、個別のサブネットにデプロイする必要があります。トラフィックを検査するには、VPC サブネットルートテーブルを使用してトラフィックをファイアウォールエンドポイントにルーティングします。

AWS Network Firewall エンドポイント経由でイングレストラフィックを転送するには、IGW でイングレスルートを設定する必要があります。ELB サブネット宛てのトラフィックは、それぞれのアベイラビリティーゾーンの適切なファイアウォールエンドポイントを経由してリダイレクトされます。イングレスルーティングの詳細については、このブログ記事を参照してください。

アプリケーションの種類と暗号化:

AWS Network Firewall はあらゆる種類のトラフィックを処理できますが、TLS 復号化はサポートされていないため、暗号化されたトラフィックにアプリケーションレイヤーインスペクションを適用することはできません。

トラフィックが暗号化されていても、AWS Network Firewall はネットワークレイヤとトランスポートレイヤ以外にも一部の制御を適用できます。TLS プロトコルの Server Name Indivation 拡張を調べることができ、TLS バージョンと TLS フィンガープリントを強制できます。

複数の VPC へのスケーリング:

分散モデルでは、VPC ごとに個別の AWS ネットワークファイアウォールをデプロイする必要があります。その展開にかかるコストを必ず考慮してください。ネットワークファイアウォールの価格は、こちらで確認できます。

AWS Firewall Manager Service を使用すると、数百ものアカウントと VPC に分散したネットワークファイアウォールを 1 か所から管理できます。

クライアント IP アドレスの可視性:

図 2 に示すように、ELB と IGW の間にネットワークファイアウォールを展開すると、実際のクライアント IP アドレスが可視化されます。

最近より具体的なルーティングが開始されたことで、ALB (注：インスタンスターゲットを持つネットワークロードバランサーはサポートされていません) とバックエンドサーバーの間にネットワークファイアウォールをデプロイすることも可能です。ただし、そのアーキテクチャでは、ファイアウォールは受信パケット内の実際のクライアント IP を認識しません。

Gateway Load Balancer

Figure 3. Gateway Load Balancer の分散型デプロイメント

トラフィックをファイアウォールに誘導する:

AWS Network Firewall と同様に、Gateway Load Balancer (GWLB) エンドポイントは、VPC サブネットルーティングと IGW Ingress Route を使用して、「Bump-in-the-Wire」として透過的にトラフィックに挿入されます。GWLB エンドポイントは、アベイラビリティーゾーンごとに 1 つずつ、個々のサブネットに作成します。これらのエンドポイントは、GWLB をホストする別の VPC とサードパーティのセキュリティアプライアンスへのパスを提供します。

トラフィックを検査するには、適切な GWLB エンドポイントにトラフィックをルーティングします。そこから、GWLB とサードパーティのファイアウォールに透過的に送信されます。トラフィックが検査されると、GLWB エンドポイントに戻り、サービスをホストしている Elastic Load Balancer に進みます。このフローのどの時点でも、トラフィックがプロキシされたり、5-TUPLE の詳細（送信元 IP、宛先 IP、送信元ポート、宛先ポート、プロトコル）が変更されたりすることはありません。

アプリケーションの種類と暗号化:

処理されるトラフィックのタイプと復号化のサポートは、GWLB の背後にあるサードパーティベンダーによって異なります。復号化を有効にすると、個々のファイアウォールのパフォーマンスが低下することもあります。各ファイアウォールのベンダーに問い合わせて、製品の機能に関する詳細を調べる必要があります。

ファイアウォールが復号化を実行している場合は、該当する証明書をファイアウォールに展開する必要があります。AWS Certificate Manager (ACM) で生成された証明書は、ファイアウォールに直接デプロイできないことに注意してください。ACM の外部で証明書を作成し、後でインポートする必要があります。ACM がサポートするサービスの詳細については、こちらをご覧ください。

複数の VPC へのスケーリング:

1 つの GWLB に、異なる VPC からの複数の GWLB エンドポイントを関連付けることができます。アーキテクチャに VPC を追加したら、新しい VPC ごとに追加の GWLB エンドポイントを作成するだけで済みます。ファイアウォールのキャパシティを必ず監視し、必要に応じてスケールアウトしてください。このブログ記事（英語版のみ）では、GWLB 展開のベストプラクティスについて詳しく説明しています。

クライアント IP アドレスの可視性:

AWS Network Firewall と同じルールが適用されます。ELB と IGW の間に GWLB エンドポイントを展開すると（図 3 を参照）、実際のクライアント IP アドレスが可視化されます。最近より具体的なルーティングが開始されたことで、ALB (注：インスタンスターゲットを持つ NLB はサポートされていません) とバックエンドサーバーの間に GWLB Endpoint をデプロイすることも可能です。ただし、ファイアウォールは、そのアーキテクチャではパケット内の実際のクライアント IP アドレスを認識しません。

ELB Sandwich

Figure 4. ELB Sandwich の分散型デプロイメント

トラフィックをファイアウォールに誘導する:

AWS Network Firewall や Gateway Load Balancer のデプロイとは異なり、ELB Sandwich モデルは透過的ではありません。サードパーティのファイアウォールは、インターネットに直接接続されている ELB のターゲットとして挿入されます。

通常、インターネットに接続している ELB は、アプリケーションを区別するために、特定のポート上のファイアウォールにトラフィックを転送します。たとえば、ALB を使用している場合、パスベースのルーティングを構成して、異なるポート上のファイアウォールに異なるホスト名を送信できます (app1.example.com の場合は 8081、app2.example.com の場合は 8082 など)。

ファイアウォールはトラフィックを検査した後、該当する内部 ELB にトラフィックを転送します。

アプリケーションの種類と暗号化:

トラフィックを復号化できるかどうかは、サードパーティのファイアウォールの機能によって異なります。詳細については、該当するベンダーに確認してください。また、インターネットに接続している ELB で TLS を終端したら、暗号化されていないトラフィックをファイアウォールに転送することもできます。

複数の VPC へのスケーリング:

分散モデルでは、各 VPC には独自のファイアウォールセットが必要であり、これがコストに影響する可能性があります。ファイアウォールのベンダーと協力して、価格モデルを理解してください。

管理の観点から、選択したファイアウォールベンダーが、多数のファイアウォールの分散展開を管理するためのツールを提供していることを確認しましょう。大規模な環境では、独自のポリシーで多数のファイアウォールを制御することが課題となる場合があります。

クライアント IP アドレスの可視性:

クライアント IP の保持は、使用するインターネットに直接接続する ELB のタイプによって異なります。NLB はクライアント IP を保持できます。このドキュメントでは、そのために必要なことについて詳しく説明しています。ALB の場合、パケット内のクライアント IP は保持されません。ALB はこれを X-Forwarded-For HTTP ヘッダーに追加します。

集中型デプロイメントのアーキテクチャ

分散アーキテクチャを使用できないシナリオ (アプリケーション VPC で IGW を許可しないポリシーがある場合など) では、集中型のアーキテクチャを検討できます。集約されたフローを作成すると、アーキテクチャが複雑になり、障害時の影響範囲が大きくなることに注意してください (つまり、エッジ VPC に集約された ELB の設定ミスが複数のバックエンドアプリケーションに影響を及ぼす可能性があります)。

AWS ネットワークへのすべてのトラフィックは、このモデルではセキュリティスタックをホストするエッジ VPC を経由します。そこから、Transit Gateway または PrivateLink 経由で別の VPC 内のターゲットアプリケーションに転送されます。

ELB が別の VPC 内のリモートターゲットにトラフィックを送信する場合、ターゲットタイプとして IP を使用する必要があります。NLB エンドポイントと PrivateLink エンドポイントの両方に、どの ELB のターゲットにもなり得る静的 IP アドレスがあります。

ターゲットアプリケーションを ALB でホストすると、その IP アドレスが変更される可能性があります。ALB で静的 IP アドレスを取得するには、NLB の背後に配置する必要があります。このブログ記事では、その設定について詳しく説明しています。

以下のアーキテクチャは、分散デプロイメントのセクションで既に説明したのと同じ考慮事項に沿っています。セットアップが集約された場合にインターネットからのトラフィックがどのように流れるかを示すことで、前に示したデプロイメントを拡張しています。

Transit Gateway モデルと PrivateLink モデルでは、パフォーマンスとスケーリングに違いがあることに注意してください。検討している各サービスのクォータについて理解するには、各サービスのドキュメントを参照してください。