LoginSignup

Why not login to Qiita and try out its useful features?

We'll deliver articles that match you.

You can read useful information later.

LoginSign up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Kt2337(Kei Tanigashira)

TGW+GWLBでセキュリティ仮想アプライアンスを導入する際のルーティングパターン及び設定例

Posted at

要約

  • AWSでは、AWS Transit Gateway（TGW）およびAWS Gateway Load Balancer（GWLB）を用いた、セキュリティ仮想アプライアンスの導入が可能

    • 概念はAWS公式のドキュメントがよくまとまっているので、そちら参照 *1

  • 導入に際しては、GWLB・TGWに加え、VPC・Subnet毎のネットワーク（ルーティング）設定が肝になる

    • こちらも別記事がよくまとまっているので、詳細はそちら参照 *2

  • 本記事では、実際に設定を行ってみて判明した内容も含め、

    • マルチAZ環境を想定した、具体的なルーティング設定例 を紹介
    • 特に 「インターネットからVPC内へのインバウンド通信」をセキュリティ仮想アプライアンスで検査する場合のルーティング例について、以下の2パターンを解説
      1. VPC Ingress Routing *3 を用いた、SSL終端前の通信を転送するパターン
      2. 通常のSubnet RouteTableを用いた、SSL終端後の通信を転送するパターン
    • それぞれのパターンについての細かな留意点を記載
      • 所感として、パターン1は制約が多く、パターン2が良いように思う

  • 参考記事

システム構成イメージ

  • 以下のような前提・要件を想定する
    • 前提
      • マルチAZ環境（本記事では2AZ分のCIDR情報を例示。第3オクテットをインクリメントする形で3AZに拡張可能な想定。）
      • インターネットに公開するWebコンテンツが存在する
        • ALB + Fargate（Web Server）でホスティング中
      • 当該Web Serverを含め、このシステムからインターネットへのアウトバウンド通信は、ホワイトリスト形式で通信を制御する必要あり
        • NLB + Fargate（Proxy Server）を通過させる形で実現中
      • VPC間はAWS Transit Gateway（TGW）を用いてルーティング中
    • 要件
      • 上記のシステムに対し、セキュリティ仮想アプライアンスを導入したい
      • 少なくとも、以下の通信はセキュリティ仮想アプライアンスにてインスペクションしたい
        • インターネットからVPC内へのインバウンド通信
        • VPC内からインターネットへのアウトバウンド通信

01_GWLB+TGW_前提.drawio.png

  • システム構成としては、AWS Gateway Load Balancer（GWLB）および GWLB Endpoint（GWLBE）を追加する形で実現する

02_GWLB+TGW_システム構成.drawio.png

ルーティング設定例

  • インスペクション対象の通信をGWLB及びその背後のセキュリティ仮想アプライアンスに転送するためには、RouteTableの設定が重要になる
    • 「インターネットからVPC内へのインバウンド通信」
      • ALB + Fargate（Web Server）が存在するVPCのルーティング変更が必要
      • 以下の2パターンが想定される
        1. VPC Ingress Routing *3 を用いた、SSL終端前の通信を転送するパターン
        2. 通常のSubnet RouteTableを用いた、SSL終端後の通信を転送するパターン
    • 「VPC内からインターネットへのアウトバウンド通信」
      • NLB + Fargate（Proxy Server）が存在するVPCのルーティング変更が必要

パターン1：VPC Ingress Routing *3 を用いた、SSL終端前の通信転送

  • ルーティング設定例（赤字部分の設定が特徴）

03_GWLB+TGW_パターン1.drawio.png

  • 実際に構築してみて判明したこととして、
    • Global Accelarator＋ALBの構成では、本パターンは採用不可
      • Global Accelarator＋ALBの構成では、IGWの構築を必要とするもののGateway RouteTableは効かない（AWS内部の特殊なルーティングによりGA→ALBに転送される）
      • AWS公式サポートに問い合わせ、上記仕様を確認済
    • SSL証明書の秘密鍵をセキュリティ仮想アプライアンスに設定する必要があった
      • ACM（AWS Certificate Manager）のAWS提供SSL証明書を用いる場合、秘密鍵を取得不可能であるため、採用不可となる
    • 性能観点でも、パターン2に比べて理論的に不利 と考えられる
      • 以下の挙動となるため
        • セキュリティ仮想アプライアンス側で（ALB到達前の通信を）復号化→インスペクション→暗号化
        • その後（通常の動きとして）ALBで通信を復号化→Web Serverに転送
    • セキュリティ仮想アプライアンスに到達する通信のアクセス元IPアドレスは、ALBへの通信を試みた通信元端末のIPアドレスとなる

パターン2：通常のSubnet RouteTableを用いた、SSL終端後の通信転送

  • ルーティング設定例（赤字部分の設定が特徴）
    04_GWLB+TGW_パターン2.drawio.png

  • 実際に構築してみて判明したこととして、

    • セキュリティ仮想アプライアンスに到達する通信のアクセス元IPアドレスは、ALBのプライベートIPアドレス となる
    • ALBへの通信を試みた通信元端末のIPアドレスを取得したい場合は、XFF（X-Forwarded-For） Headerの値をセキュリティ仮想アプライアンス側で参照する必要あり *4

  • 参考記事
    *4 https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-listeners.html#x-forwarded-headers

所感

  • 制約事項や商用環境での運用保守を考えると、パターン2の方式が現実的か

05_GWLB+TGW_比較表.drawio.png

  • どちらのパターンにおいても、セキュリティ仮想アプライアンスの導入には往路・復路の通信を考慮したルーティング設定が必要なため、折に触れて復習が必要
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin

Qiita Conference 2025 will be held!: 4/23(wed) - 4/25(Fri)

Qiita Conference is the largest tech conference in Qiita!

Keynote Speaker

ymrl、Masanobu Naruse, Takeshi Kano, Junichi Ito, uhyo, Hiroshi Tokumaru, MinoDriven, Minorun, Hiroyuki Sakuraba, tenntenn, drken, konifar

View event details
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?