この記事はSRA Advent Calendar 2022の22日目の記事です。

Advanced Cloud Engineering事業部の杉本です。
日頃の業務では、オンプレのネットワークや、AWSやAzureの基盤の構築・運用を行なっています。

前回(と言っても6年前..)のAdvent Calendar 2016はJuniperのSRXの自動化について投稿しましたが、今回は、AWSのネットワーク周りの記事にしたいと思います。

AWS Network Firewall について

一言で言うと、マネージドなファイアウォールで、機能としては以下があります。

ステートレスファイアウォール
ステートフルファイアウォール
- 5tuple
- Domain
- Suricata互換のIPS

マルチリージョンで作ってみた

前提条件

環境を作るにあたり、以下の制限を設けました。

オンプレ、AWS間の通信は全て Network Firewall を経由させる
オンプレ側は東京・大阪それぞれにDCがあり、DirectConnectは冗長化されている
DirectConnectの接続機器はステートフルファイアウォールで東西のセッション同期はない
Region内/外のVPC間の通信は全て Network Firewall を経由させる
VPC が増えても困らないよう、Transit Gateway で集約する

概要

今回はDirectConnectが東京、大阪それぞれのDirect Connect Locationを利用して接続されている環境で、かつ TransigGateway で複数のシステムのAWSアカウントが収容されている環境を作ってみました。TransitGatewayを持つ集約用のAWSアカウントにFW用のVPCを収容させます。

FW用VPCのサブネットのデザインです。東京、大阪それぞれに/1６を使用することにします。FW VPCの中は、3AZに対してサブネットを2つずつ配置します。1つはVPCに入ってくる用のサブネット、もう一つはFW Endpointを配置する用のサブネットです。

キモはRouteTableとTGW Association

構築する上で、この構成のキモはRouteTableと TransitGateway の Association でした。
突然、込み入った構成図ですが、以下のようになります。

VPC RouteTable

RouteTable	0.0.0.0/0 の next-hop	備考
System A,B VPC	TransitGateway
FW VPC 手前側	Network Firewall Endpoint	それぞれのAZで用意が必要
FW VPC Endpoint側	TransitGateway

TransitGateway RouteTable

RouteTable	0.0.0.0/0 の next-hop	備考
A	FW VPC TGW Attachment
B	なし

オンプレミスの経路は集約経路が Longest Match するよう広告されており、広告されている経路より弱い経路(広いCIDR)を対向リージョンの TGW に static で向けています。

TransitGateway Association

VPC	TransitGateway Associateion	備考
System A,B VPC	A
FW VPC	B
DirectConnect	A
TransitGateway Peer	A	対向リージョンのA

AZ跨ぎについて

この状態で、Firewall のルールで ICMP を許可した後、SystemA,B それぞれの EC2インスタンスを立て ping で疎通確認をしても AZ跨ぎの通信が Timeout します。送信先側でパケットキャプチャすると、ICMP　Echo Request は送信先に届いており、ICMP Echo Reply を返しているのですが、Reply パケットが何処かで消失しているようです。

キモは TransitGateway の Appliance mode

AWS のドキュメントによると、TransitGateway のアプライアンスモードを有効にすることで、往復の経路を同じ AZ にできるようです。てっきり、3つの AZ にデプロイされた FW Endpoint はセッション情報を同期しているのかと思ってましたが違うようです。

Transit Gatewayのアプライアンスモードです。
この機能は、リターントラフィックが同じAZで処理されることを保証します。

設定は AWS CLI で modify-transit-gateway-vpc-attachment を実行します。これにより、復路で通過する AZ が往路と同じ AZ になるため、ICMP Echo Reply が期待通り返りました。

% aws ec2 modify-transit-gateway-vpc-attachment --transit-gateway-attachment-id tgw-attach-********** --options ApplianceModeSupport=enable 
    "TransitGatewayVpcAttachment": {
        "TransitGatewayAttachmentId": "tgw-attach-***********",
        "TransitGatewayId": "tgw-*******************",
        "VpcId": "vpc-**************",
        "VpcOwnerId": "************",
        "State": "modifying",
        "SubnetIds": [
            "subnet-*****************",
            "subnet-*****************",
            "subnet-*****************"
        ],
        "CreationTime": "2022-12-21T02:23:39+00:00",
        "Options": {
            "DnsSupport": "enable",
            "Ipv6Support": "disable",
            "ApplianceModeSupport": "enable" <<== ここが変わる
        }
    }
}

めでたく AZ 跨ぎ、Region 跨ぎのトラフィックを FW を通過させることができました。
今回、AWS Network Firewall は一つの AWSアカウント内にデプロイしているのですが、東西リージョンにデプロイしているため、一箇所でルールを管理したくなりました。

AWS Firewall Manager について

AWS Firewall Manager は複数のAWSアカウントにわたる Firewall ルールを管理。そのほか、Security Group, WAF, Shield Advanced 保護, Route53 Resolver DNS Firewallルールを管理できるらしい。

今回、AWSアカウントは一つだけど、複数リージョンにデプロイしてるから、これで管理したら便利そう！！

Q: 複数リージョンにわたってセキュリティポリシーを作成することは可能ですか?

いいえ。AWS Firewall Manager セキュリティポリシーはリージョンに固有のものです。
各 Firewall > Manager ポリシーはその特定の AWS リージョンで利用できるリソースのみを含むことができます。運営している各リージョンに対して新規ポリシーを作成してください。

がーーん😭

次回、「複数リージョンの AWS Network Firewall のポリシー管理」に続く！

AWS Network Firewall をマルチリージョンで作ってみた