Amazon CloudFront VPC オリジンの魅力と WAF バイパスからの脱却

どうもセキュリティエンジニアリングの西川です。風邪を引いたせいでしばらくお酒が飲めていません。クラフトビールが冷蔵庫に所狭しと配置されていて、一向に減らないため妻から以下略

Amazon CloudFront VPC オリジンが2024/11/20に発表されましたがもうみなさん触られましたか？今日はセキュリティ観点でこの機能がどうして嬉しいのかやこれがない場合の落とし穴について話をしていこうと思います

何が嬉しいの？

ALB や EC2 インスタンスへ直アクセスができなくなるということが嬉しいです。これらのリソースはプライベートサブネットに配置され、外部から直接そういったリソースへアクセスができなくなり、必ず同一アカウント上に存在する CloudFront 経由でのアクセスに限られるようになります。さらに CloudFront に WAF を設定している場合、それがオリジンアクセスによってバイパスされなくなるということです。

具体的には下記の図のような構成になります。

今までとどう違うの？

上記の画像のような構成になっていた場合に　何も設定しなければ ALB へ直接アクセスが可能でした。EC2 が Public サブネットにある場合、EC2 へも直接アクセスできることもありました。つまり CloudFront に WAF が設定されていたとしてもそれが機能しないということになります。

そのような状況にならないようにオリジンへのアクセスを防ぐためには下記の画像のように ALB で CloudFront のマネージドプレフィックスリストを設定したり、CloudFront でカスタムヘッダを付与してそれを ALB で検証する必要がありました。 ※マネージドプレフィックリストを設定している様子

※カスタムヘッダーの設定と検証を設定している様子

これらの設定は意外に面倒で、初めから CloudFront だけがオリジンとして存在するのが望ましい状態です。また設定ミスなどによって外からアクセスできないつもりが、実はアクセスできてしまっていたみたいなことも気にしなくて良くなります。

ALB での不十分な検証

先述のとおり、今まではオリジンアクセスを防ぐために ALB で CloudFront のマネージドプレフィックスリストや CloudFront でカスタムヘッダを付与してそれを ALB で検証する必要がありました。しかしこれらはバイパスされる可能性はまだあります。

特に CloudFront のマネージドプレフィックスリストだけでは不十分で、その理由としては当該 ALB のドメインさえわかれば CloudFront を別の AWS アカウントから参照することが可能です。つまり、クロスアカウントで設定することができてしまうということです。

このような場合は同様に CloudFront の IP アドレスから ALB へアクセスが行くのでリクエストが通ってしまうことになります。何が困るかというと、正規の CloudFront には WAF が設定されていたとして、例えば攻撃者が用意した CloudFront にはそれが存在しません。その場合、WAF にいくら屈強なルールを仕込んでいたとしても素通りしてしまうことになります。

ですので、マネージドプレフィックスリストと合わせてカスタムヘッダも検証するのが好ましいというのがあるのですが、CloudFront VPC オリジンによってこの問題が解決されるわけです（非常に嬉しい）

当該 ALB のドメインなんてわかるの？

わかることがあります。というのも CloudFront から ALB へのアクセスを https 化したい場合、ALB へサブドメインを当てることになりますが、その際に例えば CloudFront にあてているドメインが example.com だとした場合、alb.example.com としているケースがあるからです。

そういった場合には容易に正規の CloudFront をバイパスすることが可能です。

ですので、CloudFront VPC オリジンはとても嬉しいのです！！この興奮が伝われば幸いです。