VPC Block Public Accessを触ってみて気づいた色々な勘所

VPC Block Public Accessを触ってみて気づいた色々な勘所 JAWS-UGちばらき(茨城＆千葉支部共同開催) #1 はたはた

アジェンダ lはじめに lVPC Block Public Access について l実際に触ってみる lVPC Block
Public Accessの設定内容による挙動の確認 lCloudFront VPC Originsとの組み合わせ l使う上での注意点など lまとめ

自己紹介名前畠山大治（はたはた）業務プリセールスエンジニア @AWSパートナー好きなもの Perfume、読書、映画・アニメギター（練習中）
好きなAWSサービス VPC、CloudFront はたはた (@hatake_book)

VPC Block Public Access（BPA）とは lre:Invent直前（いわゆる ”pre:Invent”）で発表された、VPCとインターネットの間の通信を強制的にブロックできる機能 lブロックする方向は2種類の設定から選択可能 l双方向：インバウンドとアウトバウンド両方ブロック
lIngress-only ：インターネットからVPCへのインバウンドのみブロック lBPA設定を適用しない除外設定をサブネット単位で設定可能 l除外するトラフィックの方向も2種類から選択可能 l双方向：インバウンドとアウトバウンド両方を許可 lEgress-Only ：サブネットからインターネットへの通信を許可

まずは検証環境を準備従来通りのアーキテクチャでWebサーバーを構築しておく lIPv4とIPv6のデュアルスタック構成 lインターネットとの通信パターンを3種類用意 lEC2からのインターネットEgress（IPv4） lEC2からのインターネットEgress（IPv6） lインターネットからALBへのIngress（IPv4、IPv6） lEgress通信の確認にはGoogleのDNSを使用 l簡略化のためHTTPS化は未実施

BPAの設定を追加して挙動を確認まずは「双方向ブロック、除外設定なし」の設定を入れてみる（設定を入れた後に1分ほど待機すると有効化される）

BPAの設定を追加して挙動を確認「VPCとインターネットとの通信をすべてブロックする」という設定を入れているので、全通信がブロックされる通信経路結果 EC2からのインターネットEgress（IPv4）拒否 EC2からのインターネットEgress（IPv6）拒否インターネットからALBへのIngress（IPv4、IPv6）
拒否

BPAの設定を追加して挙動を確認先ほどの設定に「パブリックサブネットでの双方向通信を除外」という設定を追加してみる（設定を入れてから有効化されるまで5分ほど時間がかかる）

BPAの設定を追加して挙動を確認 EIGWもインターネットゲートウェイの一種なので、 IPv6のEgress通信のみ拒否される通信経路結果 EC2からのインターネットEgress（IPv4）許可 EC2からのインターネットEgress（IPv6）拒否インターネットからALBへのIngress（IPv4、IPv6）
許可「プライベートサブネットでのEgress通信を除外」という除外設定を追加する必要がある

VPCフローログでの出力内容を確認してみる lIPv6でのEgressが一度許可（ACCEPT）された後に拒否（REJECT）されている lVPCフローログのreject-reasonフィールドに「BPA」との記載ありセキュリティグループやNACLで許可された後、BPAで拒否されるという挙動になっている

BPAの設定を追加して挙動を確認今回の構成でBPAを導入するのであれば以下のような設定になる lパターン１ l双方向ブロック lパブリックサブネットでの双方向除外 lプライベートサブネットでのEgress-Only除外 lパターン２ lIngress-Onlyブロック lパブリックサブネットでの双方向除外

脱線：VPC エンドポイントとの通信はどうなる？ VPCエンドポイントに対するトラフィックは、いずれもBPAの制限対象にはならない lインターフェイス型 Ø 先ほどの構成からNAT Gatewayを消し、VPCエンドポイント経由でセッションマネージャーを使う状態に修正 Ø BPAでブロック設定を入れても、セッションマネージャー
は使用可能なのでVPCエンドポイントと通信できている lゲートウェイ型 Ø BPAでブロック設定を入れても、DynamoDBに接続可能なのでVPCエンドポイントと通信できている

CloudFront VPC Origins とは l re:Invent直前（いわゆる ”pre:Invent”）で発表された、CloudFrontの新機能 l プライベートサブネットにあるリソースを、CloudFrontディストリビューションのオリジンに設定できるように
l 対応しているリソースはALB、NLB、EC2インスタンス l ALB、NLBをパブリックサブネットに配置する必要がないため、よりセキュアな構成にすることができる Ø パブリックIPを削減することができるためコスト削減も見込める

CloudFront VPC Originsとの組み合わせ CloudFront VPC Originsを使い、インターネットに露出するリソースを極限まで減らした構成に作り替える

CloudFront VPC Originsとの組み合わせ前述のパターン1の設定「BPAで双方向ブロック、パブリックサブネットで双方向除外、プライベートサブネットでEgress-Only除外」を再度有効化してみると…

CloudFront VPC Originsとの組み合わせインターネットからWebサーバーに到達不可能に通信経路結果 EC2からのインターネットEgress（IPv4）許可 EC2からのインターネットEgress（IPv6）許可
インターネットからALBへのIngress（IPv4、IPv6）拒否インターネットからCloudFront VPC Origins向けの通信がインバウンドと判定されているプライベートサブネットでの設定を双方向除外に変更する必要がある

CloudFront VPC Originsとの組み合わせ今回の構成でBPAを導入するのであれば以下のような設定になる lパターン１ l双方向ブロック lパブリックサブネットでのEgress-Only除外 lプライベートサブネットでの双方向除外 lパターン２ lIngress-Onlyブロック
lプライベートサブネットでの双方向除外

今後意識すべき観点 l BPAのブロック方向の設定によって除外設定の内容も変わる、という点に考慮して設計を行う必要がある l 既存リソースがある環境で導入する場合は… Ø あらかじめ除外設定を入れておいた上で、BPA設定のブロック方向を「Ingress-Only」に設定、そこから除外設定を追加していくという手順が比較的シンプル l
新規構築をする場合は… Ø あらかじめ除外設定を入れておいた上で、「Ingress-Only」のBPA設定をとりあえず入れておくとガバナンスを効かせることができる l インターネット接続を問答無用で遮断する機能なので設定は慎重に！ Ø 設定はかなりシンプルだが影響は非常に大きい Ø アーキテクチャによる設計の違いにも留意する必要あり BPA設定のブロック方向と除外設定の組み合わせ

今後意識すべき観点 l セキュリティグループ、NACLよりも強力な機能なので権限管理をしておくと安心 Ø 権限設定の例 • 「VpcBlockPublicAccess」が含まれれ
るEC2のAPIアクションのみを制限する IAMポリシー • 2025年1月現在、対象のAPIアクションは6つ存在している権限管理 { "Version": "2012-10-17", "Statement": [ { "Sid": "Stmtxxxxxxxxxxxxx", "Action": [ "ec2:CreateVpcBlockPublicAccessExclusion", "ec2:DeleteVpcBlockPublicAccessExclusion", "ec2:DescribeVpcBlockPublicAccessExclusions", "ec2:DescribeVpcBlockPublicAccessOptions", "ec2:ModifyVpcBlockPublicAccessExclusion", "ec2:ModifyVpcBlockPublicAccessOptions" ], "Effect": "Deny", "Resource": "*" }, { "Sid": "Stmtxxxxxxxxxxxxx", "Action": "*", "Effect": "Allow", "Resource": "*" } ] }

今後意識すべき観点 l re:Invent期間中に発表されたOrganizationsの新機能「宣言型ポリシー」で、BPA がサポートされている！ Ø 宣言型ポリシー：ある特定のサービスの設定内容を、組織内で強制的に指定できる機能 l しかし、除外設定を宣言型ポリシーで作成することは不可 Ø 各アカウントの各リージョンで除外設定を別途追加する必要があるので、活用シーンは
限られそう権限管理（宣言型ポリシー）参考：https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-vpc- block-public-access

まとめ l BPAを使用するとVPCとインターネットの間のトラフィックを制御できる Ø セキュリティやガバナンスを強化する効果がある l BPAとCloudFront VPC Originsを組み合わせることで、よりセキュアな環境を作ることができる
l 設計時には既存の構成とは少し異なる観点が必要になるため、「BPAの設定がどの通信に影響するのか」は事前にちゃんと検証しておく必要がある l 強力な機能なので、ユーザーの権限管理もしておくと安心 Ø 宣言型ポリシーでもサポートされているが、まだちょっと機能不足な雰囲気 Ø 「特定のタグがついてるサブネットは除外」とかできたら便利そう、今後に期待

宣伝 l 「OpsJAWS Meetup33」を3/4（火）に開催します！ Ø オンライン、オフライン（目黒）どっちも開催予定 l AIOpsをテーマに、AWS Hero みのるんさんに登壇いただきます！
l LT枠も募集中！！（2/17まで募集、締め切り次第抽選実施）

参考資料 l Amazon VPC Block Public Access による VPC セキュリティの強化
Ø https://aws.amazon.com/jp/blogs/news/vpc-block-public-access/ l VPC とサブネットへのパブリックアクセスをブロックする Ø https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/security-vpc-bpa.html l [アップデート]複数VPCのインターネット通信を制御する機能「VPC Block Public Access (BPA)」がリリースされました！ Ø https://iret.media/128465 l Amazon CloudFront VPC オリジンの紹介: アプリケーションのセキュリティ強化と運用の合理化 Ø https://aws.amazon.com/jp/blogs/news/introducing-amazon-cloudfront-vpc-origins-enhanced- security-and-streamlined-operations-for-your-applications/ l Restrict access with VPC origins Ø https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content- vpc-origins.html

VPC Block Public Accessを触ってみて気づいた色々な勘所

VPC Block Public Accessを触ってみて気づいた色々な勘所

da-hatakeyama

More Decks by da-hatakeyama

Other Decks in Technology

Featured

Transcript