Upgrade to Pro — share decks privately, control downloads, hide ads and more …

第33回 JAWS-UG札幌 クラウド女子会コラボ 勉強会

nagisa53
February 02, 2024

第33回 JAWS-UG札幌 クラウド女子会コラボ 勉強会

#jawsug
#クラウド女子会

nagisa53

February 02, 2024
Tweet

More Decks by nagisa53

Other Decks in Education

Transcript

  1.  VPC内で利用できるAWSマネージドなファイアウォール  特長  AWSにより可用性と自動スケーリングが管理される  ステートフル/ステートレスルールを用いアクセス制御を行う  TLSインスペクションも利用可能

     ドメインベースでの通信制御が可能  SuricataベースのIPSポリシーが利用可能  Managed Threat Signaturesとして提供されるマネージドルールを利用することも可能 AWS Network Firewallとは? インターネット向け通信のドメインベースでのアクセス制御や AWSマネージドサービスに閉じる形でIPSやUTMに準ずる機能を 利用したい場合に導入検討されることが多いサービス AWS Network Firewall
  2.  前提  NW Firewallを利用するためにVPC内にNetwork Firewall Endpointを作成する  Endpointは選択したサブネットに作成される(可用性を考慮する場合複数AZに作成) 

    Network Firewall Endpoint用には専用のサブネットを作成することが推奨  このサブネットに他のリソースを配置してしまうとそのリソースが検査できないため  NW Firewall自体にNAT GatewayのようなGIPへのNAPT機能はない  インターネット向け通信を行うにはコンポーネントにGIP付与 or NAT Gatewayが必要  検査したいトラフィックがNetwork Firewall Endpointを通過するように 特殊なルーティング設定を行う必要がある 実現するための技術として 前提となる知識 VPC Ingress Routing More Specific Routing(MSR)
  3.  VPC Ingress Routing  Internet Gatewayにデフォルトのローカルルートより優先される(ロンゲスト マッチさせられる)ルートテーブルを付与できる機能  例えば10.0.0.0/8のVPCのIGWに対し10.1.1.0/24向けの通信は特定のENIに向ける、など

     仮想アプライアンス製品(IPS、FWなど)を通すことを主な目的に2019年に機 能追加された  More Specific Routing(MSR)  デフォルトのローカルルートより具体的なルートがルートテーブルに追加可能  例えば右記のような形  2021年8月に利用可能になった機能 前提となる知識 宛先 Route 10.0.0.0/8 local 10.0.1.0/24 ENI-xx
  4.  ①:VPC内Outbound 通信 ルーティング構成は実際こうなる 10.0.0.0/16 Private subnet 10.0.3.0/24 Firewall subnet

    10.0.2.0/24 Public subnet 10.0.1.0/24 Internet gateway NAT gateway NFW Endpoint AWS Network Firewall Application 0.0.0.0/0 > Internet gateway 10.0.0.0/16 >local 10.0.3.0/24 > Network Firewall Endpoint → 保護対象サブネット向けのルールをNFWに向ける MSR 0.0.0.0/0 > NAT gateway 10.0.0.0/16 >local 0.0.0.0/0 > Network Firewall Endpoint 10.0.0.0/16 >local
  5.  ①補足  2021/8にMore Specific Routing(MSR)が利用できるようになるまでは、 NAT GatewayがNetwork Firewall Endpointの内側になる構成(VPC

    Ingress Routingで実現する方式)しか組めなかったため以下のような課題があった  Network Firewall到達時の送信元IPアドレスがNAT GatewayにNATされているため、 送信元IPアドレスベースのルールが利用できない  同様の理由で、Network Firewallのアクセスログから送信元の判別が困難 ルーティング構成は実際こうなる
  6.  ②:VPC内Inbound通信 ルーティング構成は実際こうなる 10.0.0.0/16 Private subnet 10.0.3.0/24 Firewall subnet 10.0.2.0/24

    Public subnet 10.0.1.0/24 Internet gateway NFW Endpoint AWS Network Firewall Application 0.0.0.0/0 > Internet gateway 10.0.0.0/16 >local 10.0.3.0/24 > Network Firewall Endpoint → 保護対象サブネット向けのルールをNFWに向ける MSR 0.0.0.0/0 > NAT gateway 10.0.0.0/16 >local 0.0.0.0/0 > Network Firewall Endpoint 10.0.0.0/16 >local 10.0.1.0/24 > Network Firewall Endpoint → ALBへの戻りの通信をNFWに向ける Application Load Balancer MSR ALBでSNATされている のでApplicationサーバ の直接の宛先はALB ALBでHTTPSを終端すれば NFW通過時に暗号化が解かれ た状態にできる
  7.  ②補足  P10の構成の課題としては、ALB→ Network Firewall Endpointとなるため、 Network Firewall到達時の送信元IPアドレスがALBになる(※) 

    構成としてALBとNetwork Firewall Endpointを逆にすることも可能 ( VPC Ingress Routingを利用)  ただし上記の場合HTTPS通信の場合に暗号化された状態でNetwork Firewallを通 るため、アプリケーション層の検査まで行う場合は、TLSインスペクションの利 用が必要となる ルーティング構成は実際こうなる ※後段にIPアドレスを伝える場合、ALBでX-Forwarded-Forの利用が可能だが、IPヘッダのSource Address はALBのままで、X-Forwarded-ForヘッダにALB到達時の送信元IPアドレスを含める形になる。AWS Network Firewallでは各ポリシーで利用する送信元IPアドレスとしてXFFを利用することはできないため、 送信元IPアドレスベースのポリシーを作成したい場合に課題になる。
  8.  ① + ②:①+②であれば1つのANFでInbound/Outbound制御が可能 ルーティング構成は実際こうなる 10.0.0.0/16 Private subnet 10.0.3.0/24 Firewall

    subnet 10.0.2.0/24 Public subnet 10.0.1.0/24 Internet gateway NFW Endpoint AWS Network Firewall Application 0.0.0.0/0 > Internet gateway 10.0.0.0/16 >local 10.0.3.0/24 > Network Firewall Endpoint → 保護対象サブネット向けのルールをNFWに向ける MSR 0.0.0.0/0 > NAT gateway 10.0.0.0/16 >local 0.0.0.0/0 > NFW Endpoint 10.0.0.0/16 >local 10.0.1.0/24 > Network Firewall Endpoint → ALBへの戻りの通信をNFWに向ける Application Load Balancer MSR NAT gateway
  9.  ③他VPCからの利用(Outbound集約) ルーティング構成は実際こうなる 共有VPC 10.0.0.0/16 Firewall subnet 10.0.2.0/24 Public subnet

    10.0.1.0/24 Internet gateway NAT gateway NFW Endpoint AWS Network Firewall 0.0.0.0/0 > Internet gateway 10.0.0.0/16 >local 10.1.0.0./16 > NFW Endpoint 0.0.0.0/0 > NAT gateway 10.0.0.0/16 >local 10.1.0.0./16 > TGW Client VPC 10.1.0.0/16 Private subnet 10.1.3.0/24 Client TGW subnet 10.1.4.0/24 TGW ENI TGW subnet 10.0.4.0/24 TGW ENI AWS Transit Gateway 0.0.0.0/0 > NFW Endpoint 10.0.0.0/16 >local 0.0.0.0/0 >共有VPC Attachment 10.1.0.0/16 >ClientVPC Attachment 0.0.0.0/0 >TGW 10.1.0.0/16 >local
  10.  ④他VPCからの利用(Inbound検査) ルーティング構成は実際こうなる 共有VPC 10.0.0.0/16 Firewall subnet 10.0.0.0/24 NFW Endpoint

    AWS Network Firewall 10.0.0.0/16 >local 10.2.0.0./16 > TGW 10.3.0.0/16 > TGW Ingress VPC 10.2.0.0/16 TGW subnet 10.2.1.0/24 TGW ENI TGW subnet 10.0.1.0/24 TGW ENI AWS Transit Gateway 0.0.0.0/0 > NFW Endpoint 10.0.0.0/16 >local Public subnet 10.2.0.0/24 Application Load Balancer 0.0.0.0/0 >IGW 10.2.0.0/16 >local 10.3.0.0/16 > TGW Application VPC 10.3.0.0/16 TGW subnet 10.3.1.0/24 TGW ENI Private subnet 10.3.0.0/24 Application 10.3.0.10 Internet gateway Target:10.3.0.10 0.0.0.0/0 >共有VPC Attachment 0.0.0.0/0 >共有VPC Attachment ※往復の通信を1本の線に省略 10.2.0.0/16> Ingress VPC Attachment 10.3.0.0/16 >Application VPC Attachment 0.0.0.0/0 >TGW 10.3.0.0/16 >local :TGW Attachment