Security Hub CSPMコントロールCloudFront.1の対象がS3オリジンタイプのみになっていました
はじめに
清水です。先日MediaPackageをオリジンとしたCloudFrontディストリビューションを作成しました。MediaPackageオリジンであり、かつ検証用途だったことからデフォルトルートオブジェクトは設定せず、Security Hub CSPMのCloudFront.1コントロールは「抑制済み（SUPPRESSED）」としようと考えました。しかし、待てど暮らせどSecurity Hub CSPMのCloudFront.1コントロールに該当CloudFrontディストリビューションが現れません。確認したところ、CloudFront.1では S3オリジンタイプのみがチェック対象 となっていることがわかりました。本ブログエントリでは、このSecurity Hub CSPM CloudFront.1コントロールの適用対象リソースの更新について詳細を確認してみたのでまとめてみたいと思います。
User GuideからCloudFront.1コントロールの更新を確認してみた
まずはAWS Security HubユーザーガイドのCloudFront.1コントロールを確認してみましょう。以下の通り、S3オリジンタイプのCloudFrontディストリビューションが対象であり、カスタムオリジンの場合は本コントロールが適用されない旨が明記されていますね。
引用元: Amazon CloudFront の Security Hub CSPM コントロール - AWS Security Hub
さて、以前からこのCloudFront.1コントロールについてはS3オリジンのみが対象だったのでしょうか。まさかの筆者の思い込みだったというオチだったら悲しいななどと思いながら、同ユーザーガイドのSecurity Hub CSPM コントロールの変更ログページを確認してみます。CloudFront.1で検索してみると、2025/10/22付けでこのコントロールが更新されていたことが確認できます。更新内容も「カスタムオリジンを利用するディストリビューションは検出結果を生成しない」ということで、S3オリジンのみが対象となったことと合致しますね。（思い込みじゃなくてよかった……！）
Internet Archive Wayback Machineでも確認してみましょう。更新のあった2025/10/22より少し前、2025/08/05時点のページがキャプチャで確認できました。以下の通り、チェック対象としてS3オリジンを対象としていることや、カスタムオリジンの場合は除外するといった記載はありません。オリジンタイプにかかわらず、ルートオブジェクトの設定をチェックしていたことが確認できますね。
引用元: Amazon CloudFront の Security Hub コントロール - AWS Security Hub （Internet Archiveから2025/08/05時点のキャプチャ）
デフォルトルートオブジェクトを設定しないディストリビューションを検出させてみた
最新のSecurity Hub User Guideの記載内容からCloudFront.1コントロールの現在の仕様としてはS3オリジンタイプのみをチェック対象としていること、またInternet Archiveから以前の仕様としてはオリジンタイプにかかわらずチェック対象であったことが確認できました。
筆者が今回気になっていた、MediaPackageオリジンでCloudFront.1コントロールがチェックされなかったのは最新の仕様によるもの、ということは確認できましたが、せっかくなので実際にデフォルトルートオブジェクトを設定しない、カスタムオリジンタイプならびにS3オリジンタイプのディストリビューションを作成してSecurity Hub CSPMで検出されるかどうかを実際に試してみたいと思います。
デフォルトルートオブジェクトを設定しないディストリビューションの作成
デフォルトルートオブジェクトを設定せずに、いくつかのオリジンタイプでCloudFrontディストリビューションを作成します。
まずはOrigin typeをMediaPackageとしてディストリビューションを作成しました。
ES6XXXXXXXXXXというIDでディストリビューションが作成されました。Security Hub CSPMの画面はこのディストリビューションIDでの確認になるので、それぞれのパターンとともに控えておきましょう。
続いて、EC2をオリジンとしたディストリビューションを作成しました。Origin typeでOtherを選択して、EC2のパブリックDNSをCustom originのドメイン名として登録します。
E8MXXXXXXXXXXというIDでディストリビューションが作成されました。
そして3つ目としてS3オリジンなディストリビューションを作成します。（Browse S3）ボタンからS3バケットを選択しました。
EV2XXXXXXXXXXというIDでディストリビューションが作成されました。
オリジンタイプによるCloudFront.1コントロールの検出有無を確認
オリジンタイプの異なる3つのCloudFrontディストリビューションをデフォルトルートオブジェクトを設定せずに作成しました。
ステータスが有効になったことを確認し、Security Hub CSPMのマネジメントコンソールを参照してみます。AWS基礎セキュリティのベストプラクティス v1.0.0でCloudFront.1コントロールを確認してみました。検出項目としていくつかほかのリソースもあったのですが、リソースIDをCloudFrontのARNで指定して検索してみた結果が下記になります。 S3オリジンタイプで作成したディストリビューションIDEV2XXXXXXXXXXは検出されていますが、ほかのディストリビューションは検出されていません ね。
カスタムオリジンのディストリビューションにS3オリジンを追加
CloudFront.1コントロールがS3オリジンタイプのみを対象としてチェックしていることを実際に確認してみました。もう1つ追加のパターンとして、カスタムオリジンタイプのディストリビューションに、S3オリジンを追加した際の挙動を確認しておきましょう。
先ほど作成したMediaPackageオリジンのディストリビューション（ES6XXXXXXXXXX）にS3オリジンを追加してみました。
なお、設定としてはオリジンの追加のみで、BehaviorでパスパターンによるS3オリジンへの振り分けは設定していません。
再度Security Hub CSPMのCloudFront.1コントロールを確認してみましょう。チェック対象にディストリビューションIDES6XXXXXXXXXXも挙がっていることが確認できますね。
複数オリジンが設定されているCloudFrontディストリビューションの場合は、S3オリジンが含まれていればCloudFront.1コントロールのチェック対象となるようです。
まとめ
Security Hub CSPMのCloudFront.1コントロールについて、最新の仕様ではS3オリジンタイプのCloudFrontディストリビューションのみが対象となっていることを確認しました。2025/10に更新されていることがユーザーガイドから確認できました。また、以前はたしかに、オリジンタイプにかかわらずルートオブジェクトの設定をチェックしていたことについても確認しました。
CloudFront.1コントロールですが、S3オリジンやApache HTTP Serverのような設定によってファイル一覧が返ってしまうような環境をオリジンとしている際には非常に有用な機能である認識です。うっかり設定を誤ってしまい、ファイル一覧を表示させないための予防処置になりますよね。
ただ個人的に、環境によってはルートオブジェクトを何にするべきかの判断が難しいケースもあるよな、とも思っていました。本ブログエントリで例に挙げたMediaPackageオリジンの場合もそうです。場合によってはS3オリジンを別途追加し、BehaviorでルートオブジェクトをS3オリジン配下のパスに設定するのも手段なのかな、などと思案しています。
今回のCloudFront.1の更新により対象はS3オリジンのみとなったため、ファイルの一覧が返るといったリスクがない環境であればデフォルトルートオブジェクトを設定しない、という選択肢も取りやすくなったのかなと思います。とはいえ、Apache HTTP ServerなどWebサーバがカスタムオリジンとなっている環境では、チェック自体はされなくなりましたが引き続きリスクとしては潜んでいる状況です。上手にデフォルトルートオブジェクト設定を活用していきたいですね。
なお、このCloudFront.1コントロールについては2023/12/15の時点で重要度（重大度）がCRITICALからHIGHに更新されています。こちらも留意しておきましょう。
