ページの先頭です

ページ内を移動するためのリンク
本文へ (c)

ここから本文です。

AWS VPCネットワークの脅威検知アーキテクチャ

ライター:吉田 将大
システムインテグレータでソフトウェア開発業務を経験した後、2018年にネットワンシステムズに入社。
前職での経験を活かした開発案件の支援や、データ分析基盤製品・パブリッククラウドの導入を支援する業務に従事。
保有資格: AWS認定ソリューションアーキテクトプロフェッショナル

目次

昨年から新型コロナウィルスの影響で多くのイベントがオンライン開催になっていますが、Amazon Web Services (以下 AWS)の年に1度の大規模カンファレンスである「re:Invent」も、3週間にわたるバーチャルカンファレンスとなっております。

以前こちらのブログで、AWS Transit Gatewayを使用した複数VPC構成のネットワークの構築方法や、Palo Alto Networks社製のファイアウォール(以下、FW)を組み合わせたセキュリティソリューションをご紹介しましたが、昨年のAWSのネットワーク関連のアップデートにより、アーキテクチャを大きく改善できそうです。

ということで今回は、AWS re:Invent 2020のセッションの内容も交えながら、昨年のネットワーク関連のアップデートでAWS VPCネットワーク内の脅威検知アーキテクチャがどのように改善されるかについてご紹介します。

VPCやAWS Transit Gatewayについてはこちらのブログでご紹介しておりますので合わせてご覧ください。
AWS Transit Gatewayで複数VPC構成のネットワークを構築する

脅威検知のアーキテクチャパターン(分散型と集中型、North-SouthとEast-Westトラフィック)

本題に入る前に、ネットワークセキュリティの脅威検知のアーキテクチャのパターンにはどのようなものが存在するかについてご説明します。

分散型と集中型

脅威検知のアーキテクチャを考える際に、その機能をどこに配置するかという観点があります。

例えば、個々のVPCやオンプレミスネットワークにそれぞれFWを設置し個別に管理するアーキテクチャを考えたとします。
これは構成も単純であり、それぞれのFWの障害が他のネットワークに影響する範囲も少なく、冗長なネットワークを経由しないためパフォーマンスも向上する可能性があります。

しかし、数個程度のネットワークであれば問題ないかもしれませんが、VPCやオンプレミスネットワークが数百に及ぶ場合、それぞれのFWをメンテナンスするコストは大きな問題となり得ます。
このようなアーキテクチャを分散型アーキテクチャと呼びます。

一方で、FWが設置された単一のネットワークを用意し、全てのネットワーク間のトラフィックがそのFWを経由する設計はどうでしょうか。

セキュリティを管理するチームは、数百のネットワークに分散されたFWの管理から解放され、大きなコストメリットが得られます。また、セキュリティ管理チームにはハブとなるネットワークのリソースに対する権限のみを付与すればよいため、アクセス権限の管理も簡素化されます。

しかし、全てのネットワークのトラフィックがハブネットワークに設置したFWを経由するため、そのFWに障害が発生したり、トラフィックを処理しきれなかったりする場合は、全てのネットワークに影響することになり、FWのスケーラビリティと可用性が重要です。
このようなアーキテクチャを集中型アーキテクチャと呼びます。

多くの社内ネットワークを運用されているエンタープライズのお客様は、上記の運用上のメリットから集中型のアーキテクチャを採用されるケースが多く、そしてFWのスケーラビリティと可用性に課題を抱えているのではないでしょうか。

North-SouthトラフィックとEast-Westトラフィック

次に、どのようなネットワーク間の通信を制御するかという観点です。

一般的に、内部ネットワークと外部ネットワーク間の通信を、North-Southトラフィックと呼びます。
一方で、内部ネットワークのホスト間の通信はEast-Westトラフィックと呼ばれます。

外部ネットワークとの通信であるNorth-Southトラフィックの対策が重要視されることが多いですが、ハイブリッド及びマルチクラウドの利用や、アプリケーションのマイクロサービス化による内部ネットワークのホスト間の通信量の増加、そしてTrustネットワークとUntrustネットワークの境界線を設けないゼロトラストセキュリティの考え方が普及した影響で、East-Westトラフィックへのセキュリティ対策も求められています。

既存のアーキテクチャの課題

以前こちらのブログでご紹介した、サードパーティのPalo Alto NetworksのFWアプライアンスを使用してAWS VPC上にセキュリティゲートウェイを構築するソリューションですが、AWSの制限でいくつかの課題がありました。
AWS Transit Gatewayでハイブリッドクラウドの ネットワークセキュリティを統合管理する

こちらのソリューションは、AWS上にハブとなるVPCを作成しPalo Alto Networks社製VM Series次世代ファイアウォールをデプロイして、全てのネットワーク間のトラフィックのゲートウェイとして機能させる、集中型の脅威検知アーキテクチャです。

課題① スケーラビリティと、パフォーマンス・運用コストのトレードオフ

分散型と集中型のセクションでもご説明しましたが、集中型アーキテクチャでは、ハブとなるネットワークに配置したFWの可用性とスケーラビリティが課題となります。

先述のソリューションではAWS Transit Gatewayでハブ&スポークのネットワークを構築していますが、ハブVPC内のFWの可用性とスケーラビリティを向上させるオプションは大きく2つあります。

  • VPCアタッチメントとルートテーブル書き換えによるActive/Standby構成
  • BGPとVPNオーバレイによるロードバランス

VPCアタッチメントとルートテーブル書き換えによるActive/Standby構成は、ハブVPCとAWS Transit Gatewayを直接接続し、ハブVPC内の着信サブネットのVPCルートテーブルでアクティブなFWへのトラフィックを制御する方法です。

こちらはAWS Transit Gatewayの50 Gbpsの帯域をフルに活用でき、かつ構成もシンプルにすることができるため運用コストを抑えることができます。
しかし、ルートテーブルの仕様上、AZ(アベイラビリティゾーン)内の複数のActiveなFWにトラフィックを分散するといったことができないため、
可用性の向上」にはなりますが「スケーラビリティ」には課題が残ります。

BGPとVPNオーバレイによるロードバランス構成は、ハブVPC内の各FWとAWS Transit Gatewayをオーバレイネットワークで接続し、BGPのECMP(等コストマルチパス)ロードバランスによりFWへのトラフィックを制御する方法です。

こちらはオーバレイネットワークによって負荷分散やフェールオーバが実施されるため、可用性・スケーラビリティともに向上させることができますが、一方でスループットは1.25 Gbpsに制限され、オーバレイネットワークを管理するための運用コストも増加します。

課題② VPC間East-Westトラフィックの非対称ルーティング問題

ステートフルファイアウォールという種類のFWでは、往きと戻りの通信が同一経路でないと、正しくパケットを検査できません。往きと戻りのトラフィックが別々の経路を通るルーティングを非対称ルーティングと呼びます。

AWS Transit GatewayにVPCアタッチメントで接続されたVPC間の通信では、パフォーマンスと可用性を最適化するため、デフォルトの設定ではトラフィックの送信元ホストが配置されたAZと同じ宛先VPC内のAZに着信します。
しかし、往復のトラフィックを検査するステートフルインスペクションの機能を持ったファイアウォールにとっては、このルーティングは非対称ルーティングを引き起こし、正常なパケット検査の障壁となります。

例えば、AZ-Aに配置したホストとAZ-Cに配置したホスト間のトラフィックは、往きではAZ-AのFWを経由し、戻りはAZ-CのFWを経由します。

そのため、VPC間の異なるAZに配置されたホストのEast-Westトラフィックの非対称ルーティングを防ぐためには、経由するFWで送信元NATを設定し、送信元を自身のIPアドレスに変換する必要があります。

アップデートによる課題の解決

それでは、昨年のAWSのアップデートでこれらの課題がどのように解決されるかについてご説明します。

AWS Gateway Load Balancerによるスケーラビリティ問題の解決

これまでのVPCアタッチメント構成では、VPCルートテーブルのターゲットにAWSのロードバランサーサービスを指定することができず、単一のFWインスタンスを指定していました。

そのため、FWの障害回避や負荷分散の目的でハブVPCに着信したトラフィックの転送先FWを変更する場合は、VPCのルートテーブルを明示的に書き替える必要がありました。

2020年11月に発表されたAWS Gateway Load Balancerは、インラインファイアウォールのような、ゲートウェイアプライアンスの負荷分散のために最適化された新しいロードバランサ―サービスで、Gateway Load Balancer Endpointというインターフェース型のエンドポイントを提供します。

VPCルートテーブルのターゲットに単一のFWインスタンスを指定する代わりに、Gateway Load Balancer Endpointを指定することで、複数のFWインスタンスへの負荷分散が可能になります。

これにより、ロードバランスにVPNオーバレイの必要がなくなり、パフォーマンスと運用を犠牲にせずにスケーラビリティを向上させることができます。

VPCアタッチメントの「アプライアンスモード」で非対称ルーティングを回避

2つ目のVPC間East-Westトラフィックの非対称ルーティングの問題は、新しいVPCアタッチメントの「アプライアンスモード」オプションによって解決されます。

ハブVPCとAWS Transit Gatewayを接続しているVPCアタッチメントのアプライアンスモードを有効にすると、有効なトラフィックフローの期間中は、同一のAZに必ず着信するようになります。

これによって、先述の例のAZ-Aに配置したホストとAZ-Cに配置したホスト間のトラフィックは、往きも戻りもAZ-AのFWを経由させることができ、不要なNATルールを管理する運用上の負担を軽減できます。

まとめ

今回はAWS VPCネットワークの脅威検知アーキテクチャの2020年末改訂版ということで、AWSのアップデートを受け、既存のアーキテクチャがどのように改善されるかということについてお話ししました。

残念ながら2021年1月現在では、まだGateway Load Balancerは東京リージョンでは利用できませんが、Load Balancerという主要な機能であり、既存のアーキテクチャを大きく改善するアップデートのため、東京リージョンでリリースされる日もそう遠くはないはずです。

パブリッククラウドとオンプレミスデータセンターの大規模ネットワークの脅威検知アーキテクチャに課題をお持ちのお客様にご興味を持っていただければ幸いです。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。

RECOMMEND