はじめに
ログに初見のエラーが記録されたらまずはエラーメッセージで検索するかと思います。
しかし、欲しい情報が見つからないことも多々あります...。
文章では説明が見つかったとしても、実際にどのような内容がログに記録されるか情報がなく、該当するのか判断できないこともあります。
今回私が遭遇した問題もエラーの出力内容で検索して情報がヒットしなかったパターンでした。
その内容についてまとめてみました。
S3アクセスログに記録されたエラー
今回、Amazon S3 バケットのアクセスログに記録されたのは以下の内容です。
この内容が他のバケットのアクセスログでも同じタイミングで記録されていました。
HEAD / HTTP/1.1" 400 AuthorizationHeaderMalformed 375 - 2 - "-" "AWSSupport-TrustedAdvisor～
原因
Trusted Advisor によるチェックを有効にしていることが原因です。
Trusted Advisor が第三者としてバケットにアクセスを行い、パブリックに公開されていないこと（アクセスできないこと）を確認する際に記録されるログです。
「400 AuthorizationHeaderMalformed」であるため一見関係ないように見えますが、当該エラーが定期的に記録されることは Trusted Advisor の仕様です。
説明
オープンアクセス許可を持つ、または認証された AWS ユーザーへのアクセスを許可する Amazon Simple Storage Service (Amazon S3) のバケットをチェックします。
このチェックでは、明示的なバケットアクセス許可、およびそのアクセス許可をオーバーライドする可能性のあるバケットポリシーが調べられます。
Amazon S3 バケットのすべてのユーザーにリストアクセス許可を付与することは推奨されません。これらのアクセス許可により、意図しないユーザーがバケット内のオブジェクトを頻繁にリストすることがあります。
結果として、予想される料金よりも高くなる可能性があります。
すべてのユーザーにアップロードと削除のアクセス許可を付与すると、バケットのセキュリティの脆弱性が生じる可能性があります。
対処
当該エラーが定期的に記録されることは期待される動作であり、特に問題はありません。
抑制するためにはTrusted Advisorによるチェックそのものを停止する必要があります。
一方で、Trusted Advisorによるチェックはセキュリティを担保するためのベストプラクティスであり、当該チェックの停止は非推奨です。
そのため、Trusted Advisor の記録は無視するかフィルターなどで除外するしかありません。
さいごに
SEあるあるの1つとして、自力でログに出力されたエラーを確認できたとしても、調べた対処方法が本当に合っているか判断できないことがあります。
特に本番環境で発生している場合は、安易に手を入れることができないため、とりあえずやってみるということができません。開発環境では事象が発生していないのに本番環境だけ発生している場合は最悪です...。
同じエラーメッセージで検索して、本記事に辿り着いた人のお役に立てれば幸いです。