UTM (統合脅威管理; FortiGate) on AWSを構築するにはどんなネットワーク設定？？

2024/11/14 NW-JAWS 登壇資料、AWSにおけるUTM AMIを導入する際のネットワーク周りのユースケースを紹介。

Transcript

1. / UTM (統合脅威管理; FortiGate) on AWS を 構築するにはどんなネットワーク設定？？ （DCとの接続テストも合わせて共有！） 2024/11/14 NW-JAWS #13 豊岡大地
2. / /12 ―― 今回の内容について ―― 2 こんな方向けのセッション • AWS VPC設計のサンプル増やし • よく使うサービスを案件で活用したときに気づいた、３つのTipsをご共有！ Amazon Route53 AWS VPC/ELB --- AWS Direct Connect/Site to Site VPN
3. / /12 ―― UTMって？ ―― UTM・FortiGateとは？？ UTM (Unified Threat Management) は「統合脅威管理」。 FortiGateは、日本のUTM市場シェア No.1*で、 外部からのセキュリティの脅威と内部からの情報漏えいの両方から、社内NWを防衛。 *フォーティネットジャパン株式会社のサイトより引用 実際の操作画面 • AWSではAMIを提供 • FortiGate一台で統合的にカバー FW, アンチスパム, アンチウイルス, IPS, Webコンテンツフィルタリング など 3
4. / /12 ―― 案件概要 ――  概要 弊社で運用しているコンタクトセンタPBXのEoL契機に、更改に向けて セキュリティ監視基盤をクラウドで構築  要望 Client Data Center (DC) UTM on AWS 4
5. / /12 ALB ―― はじめの構成概略図 ―― ap-northeast-1 DCへのトラフィックをEC2に導入したUTMで監視、下記を構想 ap-northeast-3 Route 53 DX Gateway AWS Direct Conect DC ALB Client 5
6. / /12 Pri Pri Pri Pri .99/32 .99/32 ―― FortiGateと通過パケット監視用のIPアドレス ―― オーソドックスの構成では、管理画面へとロードバランスされてしまう、、！ ALB Pub Pub Pri Pri ALB Pub Pub .100/32 .100/32 .100/32 .100/32 Target Group（インスタンス登録） Target Group（IP指定*） 6 • EC2に付与されたENIにセカンダリIPを加える • 別サブネットに属するENIを出口として用意する EC2上のUTM*では静的ルートにサブネット 予約IP**の一つであるVPCルータIPに向けた ルートを加える。 *該当サブネット配下以外は向けられない場合 **10.0.0/24の場合は、.1/32 https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/subne t-sizing.html
7. / /12 外部 ALB ap-northeast-1 DCへのトラフィックをEC2に導入したUTMで監視する構成 ap-northeast-3 Route 53 Client 7 外部 ALB AWS Direct Connect 東京DC XX.YY.ZZ1/26 AWS Site-to-Site VPN .X1/32 .X2/32 .X3/32 .X4/32 大阪DC XX.YY.ZZ2/26 DX Gateway 上と同じ！ ―― 今回お伝えしたい、２箇所目/3 ！――
8. / /12 外部 ALB ―― 今回お伝えしたい、２箇所目/3 ！―― ap-northeast-1 基本的に東京リージョンをプライマリ ap-northeast-3 Route 53 Client 7 外部 ALB AWS Direct Connect 東京DC XX.YY.ZZ1/26 AWS Site-to-Site VPN .X1/32 .X2/32 .X3/32 .X4/32 大阪DC XX.YY.ZZ2/26 DX Gateway 上と同じ！ フェイルオーバールーティングポリシーで プライマリ・セカンダリを設定
9. / /12 外部 ALB ―― 今回お伝えしたい、２箇所目/3 ！―― ap-northeast-1 基本的に東京リージョンをプライマリ ap-northeast-3 Route 53 Client 7 外部 ALB AWS Direct Connect 東京DC XX.YY.ZZ1/26 AWS Site-to-Site VPN .X1/32 .X2/32 .X3/32 .X4/32 大阪DC XX.YY.ZZ2/26 DX Gateway 上と同じ！ フェイルオーバールーティングポリシーで プライマリ・セカンダリを設定 内部 ALB リスナールールの ホストヘッダにて、 サブドメインを加えて DC側Target IPの制御 • preifxA.domain.com -> .X1/32 • preifxB.domain.com -> .X2/32 : • preifxA.domain.com -> .Y1/32 • preifxB.domain.com -> .Y2/32 : 内部 ALB ヘルスチェック、どうしよう、、？ #生のALBドメインではアクセスできない、、
10. / /12 ―― Route53のヘルスチェックの方法 ―― 方法としては2つ揃えることができました。 1. ALBのリスナールールにホストヘッダとは、別のリスナールールを加えて そのドメインをRoute53のヘルスチェックに登録 ※選択肢で、パスとクエリ文字列を検討。 ⇒パスはDC側のディレクトリ構造も変更する必要があったのでクエリ文字列を設定 2. 内部ALBのヘルスチェックをCloudWatch Alarm に登録し、 そのCloudWatch AlarmをRoute53のヘルスチェックのソースに登録 ※プライベート網のIPをヘルスチェックのソースにすることができる 参考サイト：https://dev.classmethod.jp/articles/route53-internalelb-dns-failover/ #現状は１にしていますが、生のALBドメインをアクセスできる設定を許容しておくか検討、、 8
11. / /12 外部 ALB ―― 今回お伝えしたい、３箇所目/3 ！―― ap-northeast-1 ap-northeast-3 Route 53 Client 9 外部 ALB AWS Direct Connect 東京DC XX.YY.ZZ1/26 AWS Site-to-Site VPN 大阪DC XX.YY.ZZ2/26 DX Gateway 上と同じ！ 内部 ALB 内部 ALB .X1/32 .X2/32 .X3/32 .X4/32 Direct ConnectとSite to Site VPNのフェイルオーバーテストについて！
12. / /12 ―― 今回お伝えしたい、３箇所目/3 ！―― Direct Connect/Site to Site VPNは、Direct Connectが優先されます。 参考サイト：https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html そのため、 Site to Site VPNの接続調査をするには、DX側の接続を落とす必要があります。 Direct Connectにはフェイルオーバーテストが用意されています！ こちらで一時的にDirect Connect側を落とすこと ができます！ ※私はこの設定を知らず、 わざわざ別組織の方をDCに伺っていだき、 DC側のスイッチ設定をいじってもらいました 10
13. / /12 ―― 最終的な構成図 ―― DC側は触れなかったため、 検証段階では別VPCにPeeringで代替 UTMそのものの管理画面はSSMで 踏み台経由でアクセス 11
14. / /12 ―― まとめ ―― 12  AWS上でUTMを構築する場合は、、 • 管理画面用に加えて、通過パケット監視用のIPをENIのセカンダリIPで足す • 入口/出口のため、別ENIをEC2にアタッチ ※UTM側で静的ルート設定がサブネット配下しかできない場合はサブネットの予約IPを用いる  Route53のヘルスチェックでは、外形監視の他にCloudWatch Alarm を連携を用いればプライベート網のIP到達をトリガーに組むことができます！  Direct ConnectとSite to Site VPNの切り替えは、 Direct Connectページにフェイルオーバーテストが用意されています！