本記事は 2024年6月11日に公開された ”Simplify global security inspection with AWS Cloud WAN Service Insertion” を翻訳したものです。

AWS Cloud WAN は、データセンターやブランチオフィス、Amazon Virtual Private Cloud (Amazon VPC) VPC を接続する広域ネットワーク (WAN) の構築・運用に使用できるマネージド型の WAN サービスです。ネットワークポリシーを使用して、ネットワーク管理とセキュリティタスクを一元的に設定・自動化し、グローバルネットワークの完全な可視性を得ることができます。サービス開始以来、グローバルネットワークの作成とリソース間の接続を容易にする機能により、AWS Cloud WAN の認知度は高まっています。しかし、この接続性を重視したことに伴い、AWS ネイティブまたはサードパーティのファイアウォールを使用する際のセキュリティ検査機能の必要性が高まっています。お客様は、ネットワークの検査と保護の方法を求めており、AWS Cloud WAN を使用した安全なグローバルネットワークの設計に関するガイダンスを必要としています。お客様の理解を深めていただくため、AWS Cloud WAN を使用した安全なグローバルネットワークの設計方法について、すでにいくつかのブログ記事を公開しています。

従来のセキュリティ検査アプローチにおける課題

既存の検査アーキテクチャパターンには多くの利点がありますが、特に AWS Cloud WAN で大規模に展開する際に、お客様はいくつかの課題に直面してきました。

• インスペクションセグメントが共有されているため、Classless Inter-Domain Routing (CIDR) を使用する VPC ルートは、各 VPC アタッチメントをネクストホップとして、インスペクションセグメントのルートテーブルに動的に伝播されます。そのため、それぞれのファイアウォールにトラフィックをルーティングするためには、新しく追加された VPC ごとに、AWS Cloud WAN のインスペクションセグメントルートテーブルに静的ルートを設定する必要がありました。
• マルチリージョンネットワークのための AWS Cloud WAN による最適なルーティングの実現で説明されているような、マルチ AWS リージョンの地域分散型検査アーキテクチャは複雑さを伴います。
• 1 つのグローバルインスペクションセグメントでは、既存のソリューションで各リージョンのファイアウォールを経由してトラフィックを強制的にルーティングする方法がありませんでした。各 AWS リージョンでトラフィックを検査するという要件を満たし、対称的なルーティングを維持するために、顧客は各リージョンまたはエッジロケーションに固有のグローバル共有インスペクションセグメントを作成する必要がありました。
• それぞれの共有インスペクションセグメントは、コアネットワークごとのセグメントのクォータとしてカウントされます。

このブログ記事では、AWS Cloud WAN Service Insertion (Service Insertion) という新機能について説明します。この機能を使用すると、中央ポリシードキュメントを使用して AWS および他社のネットワークおよびセキュリティサービスを AWS Cloud WAN に組み込むことができ、運用の簡素化を実現できます。この機能を使用することで、シンプルなポリシーステートメントを定義するか AWS マネジメントコンソールを使用して、VPC 間、インターネットエグレス、ハイブリッド環境のトラフィックをネットワークまたはセキュリティアプライアンスに容易に振り分けることができます。また、この機能は、East-West (VPC 間) および North-South (インターネットエグレス) のセキュリティ検査のためにインスペクション VPC にデプロイされた AWS Network Firewall や Gateway Load Balancer などの AWS サービスへのポリシーベースのトラフィック誘導もサポートしており、セキュリティインフラストラクチャを AWS Cloud WAN デプロイメントの他の部分とシームレスに統合できます。

Service Insertion のメリット

お客様は AWS Cloud WAN を使用して一元化されたセキュリティアーキテクチャをデプロイすることで、セキュリティリソースを統合し、管理の負担を軽減し、セキュリティインフラストラクチャのコストを削減できます。セキュリティ検査機能には、East-West、North-South、またはハイブリッド環境の保護が含まれます。

• Network Service Insertion のためのルーティングの簡素化：お客様は、VPC 間、VPC からインターネット、またはオンプレミスへのトラフィックを、ネットワークファイアウォールやロードバランサーなどのネットワークアプライアンスを経由させる必要がよくあります。AWS Cloud WAN Service Insertion により、複雑なルーティング設定を作成・管理したり、サードパーティの自動化ツールを使用したりすることなく、VPC にデプロイされたネットワークやセキュリティアプライアンスに対象のネットワークトラフィックを簡単に転送できます。
• マルチリージョンのセキュリティ検査の容易なデプロイ：ほとんどの AWS Cloud WAN のお客様は、リージョン拡張や災害復旧のユースケースに対応するため、マルチリージョンネットワークをデプロイしています。Service Insertion 機能により、マルチリージョンのデプロイが簡素化され、複雑なマルチリージョンネットワーク設定を必要とせずに、リージョン内およびリージョン間のトラフィックをセキュリティインフラストラクチャ経由に振り分けることができます。

主要な概念

このブログ投稿では、AWS Cloud WAN のコンポーネントであるグローバルネットワーク、コアネットワーク、コアネットワークポリシー、アタッチメント、コアネットワークエッジ、ネットワークセグメントについて理解していることを前提としています。

上記で説明した概念に加えて、このブログ記事で説明するアーキテクチャを理解するためには、AWS Cloud WAN Service Insertion 機能の新しいコンポーネントである Network Function Group (NFG) を理解することが重要です。

Network Function Group (NFG)

NFG は、内部的には、NAT、ファイアウォール (AWS Network Firewall や Gateway Load Balancer、またはサードパーティサービス)、侵入検知・防止システム、データ損失防止など、グローバルな AWS Cloud WAN ネットワークの一部として展開される特殊なネットワークやセキュリティ機能を指すコアネットワークアタッチメントの集合で構成される単一のセグメントです。

NFG を使用すると、AWS Cloud WAN に接続された VPC やオンプレミスネットワークにデプロイされたネットワーク機能 (Network Function) を使用して、同一セグメント間または異なるセグメント間のトラフィックを自動的に制御できます。ネットワーク機能が存在するコアネットワークアタッチメント (VPC、Site-to-Site VPN、Connect、Transit Gateway ルートテーブル) のセットを含む NFG を指定できます。さらに、トラフィックをネットワーク機能にリダイレクトする必要があるセグメントまたはセグメントペアを指定できます。AWS Cloud WAN は、それぞれの NFG に対して指定されたコアネットワークアタッチメントを通じて、セグメント間のネットワークトラフィックを自動的にリダイレクトします。このリダイレクトは、コアネットワーク上の同一リージョン (リージョン内) およびクロスリージョン (リージョン間) のトラフィックの両方で機能します。AWS Cloud WAN の コアネットワークポリシードキュメント を使用して、以下のように主要な設定項目を指定できます：

1. 1 つまたは複数のネットワーク機能を表す NFG。
2. NFG の一部であるコアネットワークアタッチメント。
3. ネットワーク機能を使用して制御する必要がある、セグメント間またはセグメント内のトラフィックを持つセグメント (シナリオ 2 のアタッチメント)。

Cloud WAN のネットワークセグメントと NFG の主な違いを理解することも重要です。

トラフィックを制御するために、NFG は以下のセグメントアクションを導入します。

• ‘send-via‘: NFG のアタッチメントを介して、同一セグメントまたは異なるセグメント間のワークロード間のトラフィックを、ネクストホップを上書きして制御します。
  • ‘single hop’: 優先されるソースまたはデスティネーションリージョンを使用して、トラフィックは単一の中間アタッチメントを通過します。使用するリージョンのリストを設定でき、優先的に使用するリージョンを設定することもできます。
  • ‘dual-hop’: トラフィックは、ソースとデスティネーションの両方のコアネットワークエッジに挿入されたアタッチメントを通過します。このオプションでは、インスペクションアタッチメントは、Service Insertion が有効化された各セグメントのすべてのリージョンに配置される必要があります。
• ‘send-to‘: NFG のアタッチメントを介して、セグメントに関連付けられたワークロードからのエグレストラフィックを、デフォルトルート (0/0, ::/0) を使用してインターネットまたはハイブリッドに転送するために使用します。

これらの概念の詳細については、AWS Cloud WAN ドキュメントをご参照ください。

図 1: Service insertion NFG

アーキテクチャ

ここでは、以下の 3 つのシナリオに焦点を当てます。

1. リージョン内、セグメント間のインスペクション
2. リージョン間、セグメント間のデュアルインスペクション
3. リージョン間、セグメント間のシングルインスペクション

シナリオ 1 – リージョン内、セグメント間のインスペクション

次の図 (図 2) は、シナリオ 1 を示しています。このシナリオでは、同一リージョン内の異なるセグメントにあるアタッチメントが、インスペクションアプライアンスを介してのみ相互に通信する必要がある場合を示しています。たとえば、開発チームが本番環境にエンジニアリング変更をプッシュする必要がある場合です。Prod VPC (10.1.0.0/16) と Dev VPC (10.11.0.0/16) は同じリージョン (リージョン 1) にありますが、それぞれ Prod セグメントと Dev セグメントに関連付けられています。Inspection VPC 1 (100.64.1.0/24) も同じリージョンに存在します。

図 2: リージョン内、セグメント間のインスペクション

同一リージョン内の Prod VPC 1 から Dev VPC 1 へのトラフィックパスに NFG を挿入するために必要なステップを見ていきましょう：

Step 1: 以下に示すサンプルポリシーを使用して、InspectionNFG Network Function Group (NFG) を作成します。

  "network-function-groups": [
    {
      "name": "InspectionNFG",
      "require-attachment-acceptance": false
    }
  ],

Step 2: 以下に示すサンプルのアタッチメントポリシーを使用して、Inspection VPC 1 アタッチメントを InspectionNFG NFG に関連付けます。

  "attachment-policies": [
    {
      "rule-number": 100,
      "condition-logic": "or",
      "conditions": [
        {
          "type": "tag-exists",
          "key": "stage"
        }
      ],
      "action": {
        "association-method": "tag",
        "tag-value-of-key": "stage"
      }
    }
  ]

Step 3: segment-actions を設定してネットワーク機能 (すなわち Inspection VPC 1) をトラフィックパスに組み込む前に、Inspection VPC 1 アタッチメントが作成され、InspectionNFG に関連付けられていることを確認する必要があります。以下に示すサンプルの AWS CLI を使用してアタッチメントを作成できます。

aws networkmanager create-vpc-attachment \
--core-network-id "<core-network-id>" \
--vpc-arn "<vpc-arn>" \
--subnet-arns "<subnet1-arn>" "<subnet2-arn>" \
--tags Key=stage,Value=InspectionNFG

Step 4: Inspection VPC 1 アタッチメントを作成し、Inspection NFG に関連付けたので、以下に示すサンプルの segment-actions を使用して、セグメント間トラフィックに InspectionNFG NFG を組み込みます。

  "segment-actions": [
    {
      "action": "send-via",
      "segment": "prod",
      "mode": "single-hop",
      "when-sent-to": {
        "segments": "*"
      },
      "via": {
        "network-function-groups": [
          "InspectionNFG"
        ]
      }
    }
  ],

“when-sent-to” の配下の “segments”: “*” はすべてのセグメントを意味します。つまり、Prod と他のセグメント (例えば、Dev、Test、Stage、QA など) の間で送信されるすべてのトラフィックが対象となります。”*” は、分離されたセグメントに対してセグメント内でのサービス挿入も提供します。

Inspection VPC 1 ネットワーク機能を通信経路に組み込むと、Prod セグメントと Dev セグメント間 (または、コアネットワークに存在する他のセグメント間) のすべてのトラフィックは、タグキー stage とタグ値 InspectionNFG を持つコアネットワークアタッチメントを使用して、Inspection VPC 1 のファイアウォールを経由して自動的に経路制御されます (図 3)。AWS Cloud WAN は以下の処理を行います:

• すべてのワークロードセグメントからのルートを、適切なワークロードアタッチメントにリダイレクトするネクストホップとともに、InspectionNFG ルートテーブルに伝播します。同一リージョン内で伝播されるルートは、そのネクストホップがローカルの NFG アタッチメントにリダイレクトされます。注意：後述のシナリオで説明するリージョン間ルーティングの場合、異なるリージョンからのルートは、ユーザー設定またはシステムデフォルトで設定された優先リージョンの NFG アタッチメントにネクストホップがリダイレクトされます。
• ポリシーで指定されたすべてのセグメントペアについて、対応するワークロードセグメントルートテーブルにルートを伝播し、ネクストホップをローカルの NFG アタッチメントとして設定します。

図 3: リージョン内のセグメント間インスペクショントラフィックフロー

Packet walkthrough:

以下のステップでは、同一リージョン内の Prod VPC 1 のリソースが Dev VPC 1 のリソースと通信する際のパケットの流れについて説明します。

• (A) Prod VPC 1 のリソースが Dev VPC 1 のリソースへの接続を開始すると、Prod VPC 1 のルートテーブルを参照します。パケットはデフォルトルートエントリにマッチし、ターゲットとしてコアネットワークの Amazon リソースネーム (ARN) が指定されているため、パケットはコアネットワークにルーティングされます。
• (B) パケットがコアネットワークに到達すると、Prod VPC 1 は Prod セグメントに関連付けられているため、Region 1 をエッジロケーションとして Prod セグメントのルートテーブルを参照します。パケットは Dev VPC 1 CIDR エントリにマッチし、Inspection VPC 1 アタッチメントがターゲットとなっているため、パケットは Inspection VPC 1 にルーティングされます。
• (C) Inspection VPC 1 のファイアウォールが、設定されたセキュリティポリシーに基づいてトラフィックを検査し許可した後、パケットはコアネットワークに戻されます。
• (D) パケットがコアネットワークに到達すると、Inspection VPC 1 は InspectionNFG に関連付けられているため、Region 1 をエッジロケーションとして InspectionNFG ルートテーブルを参照します。パケットは Dev VPC 2 CIDR エントリにマッチし、Dev VPC 1 アタッチメントがターゲットとなっているため、パケットは Dev VPC 1 にルーティングされます。

戻りトラフィックは、同じパスを逆方向にたどります。

シナリオ 2 – リージョン間、セグメント間のデュアルインスペクション

次の図 (図 4) はシナリオ 2 を示しています。シナリオ 2 はシナリオ 1 と似ていますが、Prod VPC と Dev VPC が異なるリージョンに配置されている点が異なります。Prod VPC 1 (10.1.0.0/16) はリージョン 1 に配置され、Prod セグメントに関連付けられています。一方、Dev VPC 2 (172.25.0.0/16) はリージョン 2 に配置され、Dev セグメントに関連付けられています。

異なるセグメント間のアタッチメント間を流れるトラフィックを検査する必要性に加えて、各 AWS リージョンを個別の保護された環境として扱う必要がある場合もあります。これを実現するために、各リージョンには独自の Inspection VPC があり、リージョン 1 には Inspection VPC 1 (100.64.1.0/24)、リージョン 2 には Inspection VPC 2 (100.64.2.0/24) があります。シナリオ 1 (Step 1-3) と同様に、InspectionNFG NFG を作成し、両方の Inspection VPC を InspectionNFG に関連付けます。

図 4: リージョン間、セグメント間のデュアルインスペクション

以下に示す segment-actions モードの dual-hop を使用して、リージョン間、セグメント間のトラフィックパスに InspectionNFG NFG を挿入します。これにより、各リージョンの Inspection VPC にトラフィックを振り分けすることが可能になります。

  "segment-actions": [
    {
      "action": "send-via",
      "segment": "prod",
      "mode": "dual-hop",
      "when-sent-to": {
        "segments": "*"
      },
      "via": {
        "network-function-groups": [
          "InspectionNFG"
        ]
      }
    }
  ],

Inspection VPC 1 と Inspection VPC 2 のネットワーク機能を通信経路に挿入すると、Prod セグメントと Dev セグメント間 (または、コアネットワークに存在する他のセグメント間) のすべてのクロスセグメントトラフィックは、タグキー stage とタグ値 InspectionNFG を持つコアネットワークアタッチメントを使用して、それぞれ Inspection VPC 1 と Inspection VPC 2 のファイアウォールを経由して自動的にルーティングされます。これを図 5 で示します。

図 5: リージョン間、セグメント間のデュアルインスペクションのトラフィックフロー

Packet walkthrough:

以下のステップは、Prod VPC 1 のリソースが Dev VPC 2 のリソースと通信する際のパケットの流れについて説明します。

• (A) Prod VPC 1 のリソースが Dev VPC 2 のリソースへの接続を開始すると、Prod VPC 1 のルートテーブルを参照します。パケットはターゲットとしてコアネットワーク ARN を持つデフォルトルートエントリに一致し、パケットはコアネットワークにルーティングされます。
• (B) パケットがコアネットワークに到着すると、Prod VPC 1 が Prod セグメントに関連付けられているため、Region 1 をエッジロケーションとして Prod セグメントのルートテーブルを参照します。パケットは、ターゲットとして Inspection VPC 1 アタッチメントを持つ Dev VPC 2 CIDR エントリに一致し、パケットは Region 1 の Inspection VPC 1 にルーティングされます。
• (C) Inspection VPC 1 のファイアウォールが、設定されたセキュリティポリシーに基づいてトラフィックを検査し許可した後、パケットはコアネットワークに戻されます。
• (D) パケットがコアネットワークに到着すると、Inspection VPC 1 が InspectionNFG に関連付けられているため、Region 1 をエッジロケーションとして InspectionNFG ルートテーブルを参照します。パケットは、ターゲットとして Inspection VPC 2 アタッチメントを持つ Dev VPC 2 CIDR に一致し、パケットは Region 2 の Inspection VPC 2 にルーティングされます。
• (E) Inspection VPC 2 のファイアウォールが、設定されたセキュリティポリシーに基づいてトラフィックを検査し許可した後、パケットはコアネットワークに戻されます。
• (F) パケットがコアネットワークに到着すると、Inspection VPC 2 が InspectionNFG に関連付けられているため、Region 2 をエッジロケーションとして InspectionNFG ルートテーブルを参照します。パケットは、ターゲットとして Dev VPC 2 アタッチメントを持つ Dev VPC 2 CIDR エントリに一致し、パケットは Dev VPC 2 にルーティングされます。

戻りトラフィックは、同じパスを逆方向にたどります。

シナリオ 3 – リージョン間、セグメント間のシングルインスペクション

リージョンペアの場合、Service Insertion により、セグメント間のトラフィック検査を行うリージョンを選択できます。リージョン間およびセグメント間のトラフィック検査に使用するリージョンを選択するために、デフォルトで 順序付きリスト を使用します。以下に示す segment-actions モードの single-hop を使用して、リージョン間およびセグメント間のトラフィックパスに InspectionNFG NFG を挿入します。

  "segment-actions": [
    {
      "action": "send-via",
      "segment": "prod",
      "mode": "single-hop",
      "when-sent-to": {
        "segments": "*"
      },
      "via": {
        "network-function-groups": [
          "InspectionNFG"
        ]
      }
    }
  ],

図 6 に示すように、Region 1 と Region 2 のペアにおいて、Region 1 は us-east-1、Region 2 は us-west-2 であり、順序付きリストに従って、Region 1 (us-east-1) がインスペクションのデフォルトリージョンとして選択されています。そのため、Prod VPC と Dev VPC 間のすべてのリージョン間トラフィックは、インスペクションのために Region 1 の Inspection VPC 1 を経由してルーティングされます。

図 6: リージョン間、セグメント間のシングルスペクションのトラフィックフロー

Packet walkthrough:

以下のステップでは、Prod VPC 1 のリソースがシングルインスペクションを使用して Dev VPC 2 のリソースと通信する際のパケットの流れについて説明します。

• ステップ (A) から (C) は、シナリオ 2 で説明したものと同じですが、以下の点が異なります。
• (D) パケットがコアネットワークに到着すると、Inspection VPC 1 が InspectionNFG に関連付けられているため、リージョン 1 をエッジロケーションとして InspectionNFG ルートテーブルの検索を行います。パケットは Dev VPC 2 CIDR エントリと一致し、リージョン 2 をエッジロケーションとして InspectionNFG ルートテーブルの検索を実行するように要求します。

• (E) リージョン 2 をエッジロケーションとして InspectionNFG ルートテーブルの検索を行います。パケットは、Dev VPC 2 アタッチメントをターゲットとする Dev VPC 2 CIDR エントリに一致し、Inspection VPC 2 ではなく、パケットは Dev VPC 2 にルーティングされます。

戻りトラフィックは、同じパスを逆方向にたどります。

考慮事項

• NFG はグローバルな性質を持ち、コアネットワークに属するどの AWS リージョンからでもアタッチメントを追加できます。たとえば、コアネットワークが 3 つの AWS リージョン (us-east-1、eu-west-1、ap-west-1 など) にまたがって運用されている場合、これら 3 つのリージョンのいずれからでも、単一の NFG にインスペクションまたはファイアウォール VPC を追加できます。
• NFG は、コアネットワークごとの AWS Cloud WAN セグメントのクォータから、1 つのグローバルセグメントを消費します。
• ワークロードセグメントと NFG の両方で、すべてのアタッチメントタイプ (VPC、VPN、connect、transit gateway) がサポートされています。
• このブログ投稿の執筆時点では、動的アタッチメント (VPN、connect、transit gateway peering) を通じて NFG にアドバタイズされた動的ルートは、NFG ルートテーブルにインストールされません。また、Service Insertion を機能させるためには、デフォルトルート (0/0、::/0) を動的アタッチメントを通じて NFG にアドバタイズする必要があります。詳細については、AWS Cloud WAN のドキュメントを参照してください。
• コアネットワークごとに複数の NFG がサポートされていますが、セグメントペア内のインサーションごとに単一の NFG のみが許可されます。アタッチメントはセグメントまたは NFG のいずれかに関連付けることができますが、両方に関連付けることはできません。通常、ワークロードアタッチメント (ワークロード VPC) はセグメントに関連付けられ、インスペクション VPC (ファイアウォール、侵入検知システム、侵入防止システムアプライアンスをホスト) は NFG に関連付けられます。
• 同じコアネットワークで複数の NFG を設定できます。ただし、同じセグメントまたはセグメントペアに複数の NFG を挿入することはできません。
• 同じセグメントに接続されたリソース間のトラフィックを検査する必要がある場合は、該当するワークロードセグメントの分離モードを有効にします。この設定により、挿入が必要なネットワーク機能をバイパスすることなく、セグメントに関連付けられたアタッチメント間の直接接続を防止します。
• AWS Cloud WAN のアプライアンスモードは、Service Insertion とは独立しており、VPC 内のセキュリティインフラストラクチャを通じてステートフルインスペクションを確実に行いたい場合に必要です。特定のネットワークフローの双方向のトラフィックが同じアベイラビリティーゾーンに、そして結果として同じセキュリティアプライアンスにステートフルインスペクションの目的で転送されるようにするには、インスペクション VPC アタッチメントでアプライアンスモードを有効にする必要があります。
• AWS Cloud WAN は IPv4 と IPv6 の両方をサポートしています。
• 通常のAWS Cloud WAN の料金以外に、Service Insertion の使用に関する追加料金はありません。

業界をリードするパートナー

AWS Cloud WAN Service Insertion のローンチにおいて、業界をリードするパートナー企業と協力できたことを嬉しく思います。パートナー企業の素晴らしい取り組みとコメントをご紹介します：

まとめ

このブログ記事では、AWS Cloud WAN Service Insertion について説明しました。これは、中央のポリシードキュメントを使用して AWS および他社のネットワークとセキュリティサービスを AWS Cloud WAN にシームレスに挿入できる新機能です。この機能を使用すると、シンプルなポリシーステートメントを定義するか、コンソールを使用することで、VPC 間または VPC とオンプレミス間のトラフィックをネットワークまたはセキュリティアプライアンスを通じて簡単に制御できます。また、この新機能を使用したリージョン内およびリージョン間のインスペクションアーキテクチャについても説明しました。詳細については、AWS Cloud WAN のドキュメントをご参照ください。

更新情報:

• 2024 年 6 月 28 日: 図 5 とそれに続くパケットの説明に修正を加えました。
• 2024 年 11 月 25 日: 業界をリードするパートナーとして Fortinet が追加されました。

著者について

翻訳は Solutions Architect の疋田 洋一が担当しました。原文はこちらです。