トップ > CloudFront が AWS-managed prefix list に対応しました

CloudFront が AWS-managed prefix list に対応しました

記事タイトルとURLをコピーする

どうもこんにちは
技術課の山本です

休日は山に登っています

f:id:swx-yamamoto:20220209223714p:plain
山中湖パノラマ台付近
そして新内眞衣さん卒業おめでとうございます(これを言いたくてブログを書きました)

さて本題です
CloudFront が AWS-managed prefix list に対応しました

aws.amazon.com

prefix list (プレフィクスリスト)ってなに？

docs.aws.amazon.com

Cidr ブロックをリストにして束ねたものです
セキュリティグループやルートテーブルの設定・管理を楽にしてくれます

例として 2つの Cidr ブロックを 1つのプレフィクスリストに束ねて
pl-my.network と名前を付けます ※カスタマー管理プレフィクスリスト

プレフィクスリストの名前 エントリするCidr ブロック
pl-my.network 172.32.1.1/32
172.32.2.1/32

これら2つの Cidr ブロックからの ssh 通信を許可するセキュリティグループのルールは以下のようになります

ルール番号 ポート(プロトコル) ソース
1 22(TCP) pl-my.network

プレフィクスリストが無いと 以下のようにセキュリティグループの許可ルールを設定することになります

ルール番号 ポート(プロトコル) ソース
1 22(TCP) 172.32.1.1/32
2 22(TCP) 172.32.2.1/32

このように
CIDR ブロックは異なるものの同じポート(プロトコル)許可を持つセキュリティグループのルールはプレフィクスリストを使用する 1 つのルールに統合できます

さて新しく 3つ目の CIDR ブロックをプレフィクスリストに追加してみます

プレフィクスリストの名前 エントリするCidr ブロック
pl-my.network 172.32.1.1/32
172.32.2.1/32
172.32.3.1/32

セキュリティグループにはこの更新が自動的に反映されます
プレフィクスリストを更新するとプレフィクスリストを使用している全てのセキュリティグループを自動更新します

このようにプレフィクスリストはセキュリティグループやルートテーブルの設定・管理を楽にしてくれます
反面、更新の影響も大きいので要注意です

AWS-managed prefix list (AWSマネージドプレフィクスリスト)ってなに？

prefix list (プレフィクスリスト)には以下の2種類があります

  1. カスタマー管理プレフィクスリスト
    • AWSの利用者がCIDR ブロックを設定して管理する プレフィクスリスト
      • 他の AWS アカウントとも共有可能
  2. AWS マネージドプレフィクスリスト
    • AWS サービスの CIDR ブロックが入ったプレフィクスリスト
      • 利用者がCIDR ブロックを変更、共有、削除することは不可
      • サービス毎にある (DynamoDB のプレフィクスリスト、 S3 のプレフィクスリスト)
      • 利用者側はセキュリティグループやルートテーブルへの適用が可能

AWS-managed prefix list (AWSマネージドプレフィクスリスト)は AWSサービスの利用している CIDR ブロックに関する通信設定(セキュリティグループ・ルートテーブル)に用います
例としては「DynamoDBやS3(の利用しているIPアドレス範囲)への通信はVPCエンドポイントを通るようにルートテーブルを設定する」です

  1. DynamoDBとS3のVPCエンドポイント(ゲートウェイ型のVPCエンドポイント)を作成します
  2. DynamoDBやS3と通信が必要なルートテーブルの「送信先」に DynamoDBやS3 の AWS マネージドプレフィクスリストを追加します
  3. 2の「ターゲット」(ゲートウェイ)をVPCエンドポイントにします
送信先 ターゲット(ゲートウェイ)
DynamoDBのAWSマネージドプレフィクスリスト(pl-xxxx) DynamoDBのVPCエンドポイント(vpce-xxxx)
S3のAWSマネージドプレフィクスリスト(pl-xxxx) S3のVPCエンドポイント(vpce-xxxx)

AWS マネジメントコンソールで見るとこんな感じです
f:id:swx-yamamoto:20220210082803p:plain

f:id:swx-yamamoto:20220210084922p:plain

f:id:swx-yamamoto:20220210082628p:plain

AWSマネージドプレフィクスリストを利用して
DynamoDBやS3(の利用しているIPアドレス範囲)への通信はVPCエンドポイントを通るようにルートテーブルを更新できました
プレフィックスリストの内容(CIDR ブロック)はAWSが管理・更新しています
そのため各サービスの利用するIPアドレス範囲を利用者側は意識しません

CloudFront が AWS-managed prefix list に対応すると嬉しいことってなに？

アップデートを読んでみます

Posted On: Feb 7, 2022

Starting today, you can use the AWS managed prefix list for Amazon CloudFront to limit the inbound HTTP/HTTPS traffic to your origins from only the IP addresses that belong to CloudFront’s origin-facing servers. CloudFront keeps the managed prefix list up-to-date with the IP addresses of CloudFront’s origin-facing servers, so you no longer have to maintain a prefix list yourself.

You can reference the managed prefix list for CloudFront in your Amazon Virtual Private Cloud (VPC) security group rules, the subnet route table, the common security group rules with AWS Firewall Manager, and any other AWS resource that can use a managed prefix list. For example, you can use the managed prefix list for CloudFront in the inbound rules of your VPC security group to allow only CloudFront IP addresses to access your EC2 instances. When using the managed prefix list with the common security group rules for AWS Firewall Manager, you can limit access to multiple Application Load Balancers (ALB) across all your AWS accounts. Please see the AWS Managed Prefix List for more details.

The managed prefix list is available for immediate use via the AWS Console, and the AWS SDK in all regions except China, Asia Pacific (Jakarta), and Asia Pacific (Osaka). The prefix list can be referenced in your CloudFormation templates in the available regions. There is no additional fee for using the CloudFront managed prefix lists. For further information, please see the CloudFront developer guide.

3行で和訳します

  1. CloudFrontのオリジン(ALB,EC2など)へのインバウンドHTTP / HTTPS通信を「CloudFrontのオリジンに面したサーバー(CloudFront’s origin-facing servers)に属するIPアドレス」のみからに制限可能
  2. セキュリティグループのルール、ルートテーブル、AWS Firewall Managerの共通セキュリティグループのルールなどAWSマネージドプレフィックスリストを使用可能なサービスでCloudFrontのAWSマネージドプレフィックスリストを使用可能
  3. 中国、ジャカルタ、大阪以外の全リージョンで使用可能

まとめると
CloudFront のオリジン(ALB,EC2など)に付けるセキュリティグループのルールに 「CloudFrontのAWSマネージドプレフィックスリスト」からのHTTP / HTTPS通信許可のみを設定しておくことにより
オリジンにCloudFront以外から直接通信しないようになります
今のところ大阪リージョンは使えない点は注意ですね
DRサイトを大阪リージョンにしてると同じ構成に出来ないですね

このアップデートの前までの対応

CloudFront の利用している Cidr ブロックをオリジンのセキュリティグループに自分で 登録する

CloudFront の使用する IPアドレス範囲が 公開されています
このIPアドレス範囲をカスタマー管理のプレフィックスリストやセキュリティグループに自分で登録します
AWS IP アドレスの範囲 - AWS 全般のリファレンス

下の json の "service": "CLOUDFRONT" となっているものが対象です
https://ip-ranges.amazonaws.com/ip-ranges.json

なお IP アドレス範囲は動的に変わるため追従が必要で運用負荷が高いです

IP アドレス以外の方法(カスタムヘッダ)でオリジンにCloudFront以外から直接通信しないように制御する

CloudFront から カスタムヘッダ(key/value)を付与して ALB は該当のカスタムヘッダ(key/value)を持つ通信のみ許可します
以下ブログの「① カスタムヘッダの追加による制御」を参照ください
CloudFront のオリジンへ直接アクセスさせない方法まとめ - サーバーワークスエンジニアブログ

オリジンがALBの構成図です
f:id:swx-yamamoto:20220209210348p:plain

なおALB の場合はリスナールールでヘッダに応じた制御が可能ですので必ずしも AWS WAF が必要というわけではありません
上の「CloudFront の利用している Cidr ブロックをオリジンのセキュリティグループに自分で 登録する」方法の運用負荷が高いため
こちらの方法が一般的です
運用負荷としてはカスタムヘッダ(key/value)を類推されないようなものにして設定し機密情報として管理しておく必要があります

このアップデートの後に可能なこと

CloudFront のオリジン(ALB,EC2など)に付けるセキュリティグループのルールに 「CloudFrontのAWSマネージドプレフィックスリスト」からのHTTP / HTTPS通信許可のみを設定しておくことにより
オリジンにCloudFront以外から直接通信しないようになります

オリジンがALB (+ Fargate クラスター)の構成図です
f:id:swx-yamamoto:20220209210909p:plain

実際にやってみた

CloudFront と ALB (+ Fargate クラスター)を東京リージョンにデプロイしました(上の構成図と同じ構成です)
比較のため最初は ALB のセキュリティグループに 0.0.0.0/0 からのHTTP 通信許可を設定しておきます
f:id:swx-yamamoto:20220209213516p:plain

ALB の DNS 名に接続すると nginx に接続できました
f:id:swx-yamamoto:20220209213244p:plain

CloudFront の DNS 名に接続すると nginx に接続できました
f:id:swx-yamamoto:20220209214208p:plain

東京リージョンの VPCサービス画面から CloudFrontのAWSマネージドプレフィックスリスト を確認します
com.amazonaws.global.cloudfront.origin-facing という名前のプレフィックスリストがあります
f:id:swx-yamamoto:20220209212508p:plain

ALB のセキュリティグループに CloudFrontのAWSマネージドプレフィックスリスト からのHTTP 通信許可のみを設定します
f:id:swx-yamamoto:20220209223504p:plain

設定後
f:id:swx-yamamoto:20220209215258p:plain

ALB の DNS 名に接続すると nginx に接続できなくなっていました
f:id:swx-yamamoto:20220209220057p:plain CloudFront の DNS 名に接続すると nginx に接続できました
f:id:swx-yamamoto:20220209220004p:plain

注意点 (2022/02/14 追記)

CloudFrontのマネージドプレフィクスリストは最大エントリ数が 55 のため
セキュリティグループのルールを 55 個消費します
セキュリティグループのルール数はデフォルトで最大60になっています
必要に応じて緩和してください

Work with AWS-managed prefix lists - Amazon Virtual Private Cloud

It counts as 55 rules in a security group. The default quota is 60 rules, leaving room for only 5 additional rules in a security group. You can request a quota increase for this quota.

ルートテーブルについては ルート数がデフォルトで 50 になっています
そのため ルートテーブルに追加する際には事前に制限緩和してください

It counts as 55 routes in a route table. The default quota is 50 routes, so you must request a quota increase before you can add the prefix list to a route table.

詳細は弊社佐竹の以下ブログに記載があります

blog.serverworks.co.jp

余談

東京リージョンにあるCloudFrontのAWSマネージドプレフィックスリストにエントリは 44個ありました
f:id:swx-yamamoto:20220209214834p:plain

またバージニアとムンバイを見てみても同じエントリ数・内容でした(他リージョンは不明)
CloudFront の使用する IPアドレス範囲 https://ip-ranges.amazonaws.com/ip-ranges.json を確認すると今日時点で CloudFront が利用している Cidr Block は 131 ありました
うち "region": "GLOBAL" のものが 82 個
うち "region": "ap-northeast-1" のものが 3 個
ですので エントリ数とは合いません
またCloudFront の DNS 名(xxxx.cloudfront.net)を正引き(dig)した IP アドレス範囲はエントリに入っていませんでした
アップデートに記載の通り「CloudFrontのオリジンに面したサーバー(CloudFront’s origin-facing servers)に属するIPアドレス」に限定してくれているようです

まとめ

CloudFront のオリジンに直接接続させない方法に手軽な方法が一つ加わりました
有力な実装候補ではないでしょうか

山本 哲也 (記事一覧)

カスタマーサクセス部のインフラエンジニア。

山を走るのが趣味です。

"; doc.innerHTML = entry_notice + doc.innerHTML; }
' } }) e.innerHTML = codeBlock; });