トップ > AWS Network Firewall > PrivateLink 経由で Network Load Balancer (NLB) に到達する通信を、バックエンドの EC2 インスタンスに転送する前に、AWS Network Firewall で検査するよう構成してみる

PrivateLink 経由で Network Load Balancer (NLB) に到達する通信を、バックエンドの EC2 インスタンスに転送する前に、AWS Network Firewall で検査するよう構成してみる

AWS Network Firewall AWS Transit Gateway
記事タイトルとURLをコピーする

こんにちは😸
カスタマーサクセス部の山本です。

映画「ルックバック」をサブスクリプションサービスでようやく観ることができ、深く感動しました。 作中で背景に描かれていた鳥海山が印象的で、ぜひ一度登ってみたいと強く思いました。

はじめに

本記事の執筆中に、以下のニュースが発表されました。これにより、記事の内容が古くなる可能性があります。 現時点では東京リージョンでまだ利用できません。近い将来に試してみたいと考えています。

関連記事

Transit Gateway を活用し、インターネット通信時に利用する NetworkFirewall のエンドポイントを一元的に集約する構成について、以下のブログに執筆しています。 Transit Gateway と Network Firewall を連携させたネットワーク構成の参考になるかと思います。

Transit Gateway を使用して、AWS Network Firewall Endpoint の集約を考えてみる。 - サーバーワークスエンジニアブログ

ユースケース

  • 会社内の異なる部門や子会社間などにおいて、コンプライアンス要件を満たすセキュアなデータ連携が必要である場合
    • 機微情報の安全性を強く求められるケースなど

図

往路

復路

構成のポイント

構成の主要なポイントは以下の通りです。

  1. PrivateLink を他の AWS アカウントと共有している
  2. PrivateLink に Network Load Balancer (NLB) を関連付けている
  3. バックエンドの EC2 インスタンスは異なる VPC に配置

バックエンドの EC2 インスタンスを異なる AWS アカウントの VPC に配置した理由は、ルーティングの可視性と理解のしやすさを向上させるためです。

補足：NLB と同じ VPC に EC2 インスタンスを配置する場合でも、NLB と EC2 のサブネットを適切に分割することで、同様のネットワーク構成を実現できます。 → 6/24 追記：Transit Gateway を経由して NetworkFirewall を使用する場合は NLB と EC2 の VPC を分ける必要があります。１つの VPC に NLB / NetworkFirewall / EC2 を配置する構成は可能です。

通信の流れ

NLBを配置する VPC1、EC2 を配置する VPC2 からの通信が、上にある内部監査用 VPC を経由して、そのあとに本来の宛先VPCに向かうような経路設定をしました。
以下の前提を理解すると、通信の流れが分かるようになるかなと思います。

  1. VPC内のノードから Transit Gateway Attachment に通信がきた場合は、Attachment に関連付けた Transit Gateway のルートテーブルを参照する（矢印1→2など）
  2. Transit Gateway のルートテーブル から Transit Gateway Attachment に通信がきた場合は、Transit Gateway Attachment のあるサブネットのルートテーブルを参照する（矢印3→4など）

Transit Gateway の ルートテーブルの説明

  • Transit Gateway の ルートテーブル 1
    • 内部監査用 VPC で検査を終えた通信が、本来の宛先となる VPC に向かって通信するトランジットゲートウェイルートテーブルを作成しました。内部監査用 VPC に関連付けました。
  • Transit Gateway の ルートテーブル 2
    • 各VPCからの通信を内部監査用のVPC に集約して検査するためのトランジットゲートウェイルートテーブルを作成しました。NLB と EC2 を配置した VPC 1, 2 に関連付けました。

参考

NLB の AWS アカウント

NLB と EC2 を作成します（割愛）
そのあとに、VPCのコンソールでエンドポイントサービスを作成します。 NLB を選択します。 「プリンシパルを許可」タブで設定を行い、共有する AWS アカウントの情報を入れます。PrivateLinkを使用する「VPC another」のある AWS アカウントです。作業を行う IAM ユーザーまたはロールの ARN で大丈夫です。 設定後の画面です。検証でしたので、対象の AWS アカウントすべてのプリンシパルを意味する arn:aws:iam::123456789012:root と入力しました。123456789012 は共有する対象のAWSアカウント番号です。
最後に「サービス名」をコピーしておきます。
com.amazonaws.vpce.ap-northeast-1.vpce-svc-hogehogefugafuga

先ほど許可したIAM ユーザーまたはロールでログインします。 VPCエンドポイントを作成します。
「PrivateLink Ready パートナーのサービス」を選びます。
先ほどコピーしておいた「サービス名」を入力します。

NLB の AWS アカウント

「エンドポイント接続」というタブから「エンドポイント接続リクエストの承諾」を実行すると、使用可能になります。

※NLB のセキュリティグループで、送信元の IP アドレスとポートの許可は必要です。

トランジットゲートウェイルートテーブル

  • Transit Gateway の ルートテーブル 1

    • 内部監査用 VPC で検査を終えた通信が、本来の宛先となる VPC に向かって通信するトランジットゲートウェイルートテーブル

  • Transit Gateway の ルートテーブル 2

    • 各VPCからの通信を内部監査用のVPC に集約して検査するためのトランジットゲートウェイルートテーブル
    • 拡張性を持たせるためにクラスC のプライベートIPアドレス192.168.0.0/16を記載しました。

参考資料

以下資料の「応⽤︓公開サーバ宛の通信を集約する」スライドを PrivateLink に応用すると、この記事の内容になるかなと思います。

まとめ

本記事では、AWS Network FirewallとPrivateLinkを組み合わせたデータ連携の構成について解説しました。

主なポイント

  • PrivateLink経由でNLBに到達する通信を、AWS Network Firewallで検査する構成
  • 異なるAWSアカウント間での安全なデータ連携が可能
  • Transit Gatewayの2つのルートテーブルを活用し、通信の集約と制御を実施
    • ルートテーブル1：内部監査用VPCでの検査後の各VPCへの通信
    • ルートテーブル2：各VPCからの通信を内部監査用VPCに集約

この構成は、特に機微情報を扱う場合やコンプライアンス要件の厳しい環境での部門間・子会社間のデータ連携などに有効かなと思います。

余談

昔から、私の身近な山として、南アルプスの山々があります。
去年、仙丈ケ岳から塩見岳に向かう仙塩尾根をランニングした際に、「間ノ岳 1 時間」という看板があったものの、スルーしてしまいました。
今年の夏はこのフラグを回収してもいいのかもしれません。
南アルプスは年間数mmの速さで隆起していて、気づいたら間ノ岳は日本で３番目に高い山になっていました。（北アルプスの奥穂高と並び三位）

山本 哲也 (記事一覧)

カスタマーサクセス部のインフラエンジニア。

山を走るのが趣味です。