CloudFrontの標準ログ記録において「S3 Legacy」を設定していない場合の、AWS Security Hub CSPM[CloudFront.5]の挙動を確認してみた

CloudFrontの標準ログ記録において「S3 Legacy」を設定していない場合の、AWS Security Hub CSPM[CloudFront.5]の挙動を確認してみた

2025.10.13

こんにちは!クラウド事業本部の吉田です。

唐突ですが、AWS Securty Hub CSPMのCloudFront.5の内容はご存じでしょうか?

CloudFrontディストリビューション上で標準ログ記録が有効化されているかどうかを確認するコントロールです。
修復手順については、下記のブログで解説されております。

【Security Hub修復手順】[CloudFront.5] CloudFront ディストリビューションでは、ログ記録を有効にする必要があります | DevelopersIO

上記の記事の執筆時は、CloudFrontの標準ログの出力先はS3のみでした。

その後、アップデートにより標準ログの出力先として、CloudWatch LogsとAmazon Data Firehoseが追加されました。
出力先の追加に加えて、記録する項目やフォーマットの指定もできるようになりました。
詳細な内容は、アップデート紹介のブログを確認してください。

CloudFront 標準ログがアップデート!新機能のパーティションやJSON出力を試してみた | DevelopersIO

アップデートに伴い、従来の標準ログの出力先は「S3 Legacy」という扱いになっております。
箇条書きにすると、現状の標準ログの出力先は下記の通りとなっております。

  • 標準ログ記録(v2)
    • CloudWatch Logs
    • Amazon Data Firehose
    • S3
  • 標準ログ記録(Legacy)
    • S3

ここで、現在のCloudFront.5の公式ドキュメントの解説文を確認します。

このコントロールは、CloudFront ディストリビューションでサーバーアクセスのログ記録が有効になっているかどうかをチェックします。ディストリビューションでアクセスのログ記録が有効でない場合、コントロールは失敗します。このコントロールは、ディストリビューションに対して標準ログ記録 (レガシー) が有効になっているかどうかのみを評価します。

引用元:Amazon CloudFront の Security Hub コントロール - AWS Security Hub #[CloudFront.5] CloudFront ディストリビューションでは、ログ記録を有効にする必要があります

コントロールに紐づいているconfigルールのドキュメントも確認します。

Amazon CloudFront ディストリビューションが、標準ログ記録 (レガシー) を使用して Amazon S3 バケットにアクセスログを配信するように設定されているかどうかを確認します。CloudFront ディストリビューションにレガシーログ記録が設定されていない場合、ルールは NON_COMPLIANT です。

引用元:cloudfront-accesslogs-enabled - AWS Config

公式ドキュメントを読む限り、標準ログ記録(v2)のいずれかの出力先の設定を有効化していても、標準ログ記録(Legacy)が有効化されていなければ、CloudFront.5は失敗することになります。

ログを出力しているのにコントロールが失敗するのは、少し納得がいかないですよね。
そこで、実際にどのような挙動になるのか確認し、現時点のCloudFront.5の対応方針をまとめてみました。

結論

  • 公式ドキュメントにある通り、標準ログ設定において「S3 Legacy」以外のログ設定を設定してもコントロールは成功しない
  • 「S3 Legacy」以外のログ設定を設定している場合は、検知されているCloudFrontディストリビューションのワークフローステータスを「抑制済み」に設定する
  • コントロールの内容がアップデートされるまでは、コントロールを無効化することも検討する

動作検証

出力先を「標準ログ記録(v2):CloudWatch Logs」に設定

まずは、出力先を「標準ログ記録(v2):CloudWatch Logs」に設定します。
ディストリビューションの画面から「Logging」タグをクリックした後、「Add」ボタンをクリックしますと、標準ログ記録の出力先一覧が表示されます。
今回は「Amazon CloudWatch Logs」を選択します。

vscode-drop-1760317839271-un5gahcdmjp.png

事前に作成したロググループか、新規作成したロググループを選択します。

vscode-drop-1760317873727-elm6ztmuze5.png

では、CloudFront.5のステータスを確認しましょう。
残念ながら失敗していますね。

vscode-drop-1760318032405-spyrcnr7uhs.png

CloudFront.5に紐づいているConfigルールの方も確認します。
検証用のディストリビューションが、非準拠リソースとして表示されておりました。
次の検証からは、このConfigルールの結果を見ていくことにします。
(AWS Security Hub CSPMのキャプチャを取るのを失念しておりました)

vscode-drop-1760318348505-4k39wpdun48.png

出力先を「標準ログ記録(v2):S3」に設定

では、次に「標準ログ記録(v2):S3」を設定します。
出力先がレガシーの時と同じS3ですから、成功してほしいです。
手順は、先ほどのCloudWatch Logsの設定と同様です。

vscode-drop-1760318686510-enwd80gcumm.png

vscode-drop-1760318692560-ngmzfhfek6i.png

vscode-drop-1760318754957-joap4ilys2l.png

こちらも残念ながら失敗します。

出力先を「標準ログ記録(legacy):S3」に設定

最後に、「標準ログ記録(legacy):S3」に設定します。

vscode-drop-1760319258611-zodb4driddr.png

「標準ログ記録(v2):S3」の時とは違い、「標準ログ記録(legacy):S3」の場合は、出力先のS3バケットのACLを有効にする必要があります。

vscode-drop-1760319264605-jrisjlcx8bf.png

Configルールを確認します。
今までの設定とは異なり、検証用のディストリビューションが準拠リソースとして表示されました。

vscode-drop-1760319391495-9c0giy2g234.png

公式ドキュメント通り、標準ログ設定において「S3 Legacy」以外のログ設定を設定してもコントロールは成功しないことがわかりました。

CloudFront.5の対応方針

言わずもがなですが、CloudFront.5がある理由は、ロギングがされているかどうかというチェックするためのものです。
しかし、現状はロギングを有効化していたとしても、設定によっては検知されてしまうという状況です。

出力先の追加、記録する項目やフォーマットの指定が可能になったことを踏まえると、標準ログ記録(v2)ではなく標準ログ記録(legacy)を有効化するメリットはありません。
したがって、CloudFront.5の対応方針としては下記を推奨します。

  • CloudFrontのログ設定は、標準ログ記録(v2)を設定
  • 標準ログ記録(v2)を設定したディストリビューションに関しては、ワークフローステータスを「抑制済み」に設定

CloudFront作成時に標準ログ記録(v2)を設定することをガイドラインとして整備できている場合は、
AWS Securty Hub CSPMの運用負荷軽減としてCloudFront.5を無効化することも検討してください。

繰り返しとなりますが、2025年10月時点の内容となります。
アップデートが来ましたら、再度ブログを執筆させていただきます。

この記事をシェアする

FacebookHatena blogX

関連記事

CloudFrontの標準ログ記録において「S3 Legacy」を設定していない場合の、AWS Security Hub CSPM[CloudFront.5]の挙動を確認してみた | DevelopersIO