【ITニュース解説】【AWS】S3アクセスログに記録される「400 AuthorizationHeaderMalformed」について

S3という言葉を聞いたことはあるだろうか。これはAmazon Web Services（AWS）が提供するクラウドストレージサービスで、ウェブサイトの画像や動画、アプリケーションのバックアップデータなど、さまざまな種類のファイルを安全に保存できる場所だ。システムエンジニアを目指す上で、S3は非常に基本的ながら強力なサービスの一つであり、その使い方や管理方法を学ぶことは避けて通れない道となる。

S3に保存されたファイルへのアクセスは、常に監視され、記録されている。これをS3の「アクセスログ」と呼ぶ。アクセスログには、誰が、いつ、どのファイルに、どのような操作を試みたかという情報が記録される。これは、セキュリティ上の問題がないかを確認したり、システムにトラブルが発生した際に原因を特定したりするために不可欠な情報となる。例えば、意図しないアクセスがあった場合や、特定の操作が失敗した場合、その詳細がログに残されているため、原因究明の手がかりとなるのだ。

今回注目するエラーメッセージは、S3のアクセスログに記録される「400 AuthorizationHeaderMalformed」だ。このメッセージは、S3へのアクセスを試みた際に何らかの問題が発生したことを示している。HTTPステータスコードの「400」は「Bad Request」、つまりリクエストが無効であることを意味する。そして、「AuthorizationHeaderMalformed」は、その無効なリクエストの中でも、特に「認証ヘッダー（Authorization Header）」という部分が「Malformed（不正な形式である）」ことを指している。

S3にアクセスするには、そのアクセスが正当なものであることを証明する必要がある。この証明のプロセスを「認証（Authorization）」と呼び、そのために必要な情報が「認証ヘッダー」に含まれてリクエストと共にS3に送信される。具体的には、AWSのユーザー識別子である「アクセスキー」と、それに対応する「シークレットアクセスキー」を使って生成される「署名」と呼ばれる情報が用いられることが多い。これは、S3にアクセスするための「身分証明書」や「鍵」のようなものだと考えるとわかりやすい。この認証ヘッダーが正しくない、あるいは完全に欠落していると、S3はアクセスを許可できない。

では、なぜこの認証ヘッダーが「不正な形式」になるのだろうか。考えられる原因はいくつかある。最も一般的なのは、アクセスキーやシークレットアクセスキーが間違っている場合、あるいはそれらを使って生成された署名が、S3の期待する形式と異なっている場合だ。特に、AWSでは「署名バージョン4」という複雑な署名アルゴリズムが使われており、これの計算にミスがあると「AuthorizationHeaderMalformed」エラーが発生することがある。また、一時的な認証情報（例えば、AWSのIAMロールが提供する一時クレデンシャル）を使っている場合、その有効期限が切れていれば、同じエラーが記録される。開発中のアプリケーションでS3へのアクセスを試みる際に、認証情報の設定ミスや、署名生成ロジックの不具合が原因となるケースも少なくない。

今回の記事で特に興味深いのは、S3バケットポリシーによって特定のIPアドレスからのアクセスが拒否される設定になっている場合でも、この「400 AuthorizationHeaderMalformed」が記録されることがある、という点だ。通常、S3に設定されたバケットポリシーは、誰がどのような条件でS3リソースにアクセスできるかを制御する「アクセス制御リスト」のような役割を果たす。例えば、「特定のIPアドレスからのみアクセスを許可する」というポリシーを設定した場合、それ以外のIPアドレスからのアクセスは拒否されるはずだ。しかし、そのような拒否されたアクセスにおいても、この「400 AuthorizationHeaderMalformed」エラーが記録されることがあるという。

これは、S3がリクエストを処理する際の内部的な順序に関係していると考えられる。S3はリクエストを受け取ると、まずそのリクエストに含まれる認証情報の正当性を確認しようとする。もし、リクエスト元のIPアドレスがバケットポリシーによって許可されていない場合でも、S3はまず「このリクエストは誰からのものか、正しく認証されているか」という点を見ようとする。その認証情報自体が不正な形式であれば、S3はIPアドレスによるポリシー評価の前に、「認証情報がおかしい」というエラーを返す場合があるのだ。つまり、アクセスが許可されない理由は複数存在し、そのうち認証情報の不備が先に検出されると、IP制限による拒否よりも優先して「400 AuthorizationHeaderMalformed」が記録されるというわけだ。これにより、単純にIPアドレスでアクセスが拒否されただけだと思っていても、ログには別のエラーが表示され、混乱を招くことがある。

したがって、S3のアクセスログを分析する際には、エラーコード「400 AuthorizationHeaderMalformed」だけを見て判断するのではなく、ログに記録されている他の情報、例えば「リクエスター（アクセスを試みたエンティティ）」や「操作内容」、「ユーザーエージェント（どのようなクライアントからアクセスされたか）」なども合わせて確認することが非常に重要となる。このエラーが記録されたからといって、必ずしも悪意のあるアクセスや、深刻なシステムの問題を指しているとは限らない。時には、開発中のテスト環境からの設定ミスであったり、期限切れの認証情報を使った古いアプリケーションからのアクセスであったりする可能性もある。

システムエンジニアとして、S3のようなクラウドサービスを扱う上で、アクセスログを正確に読み解く能力は非常に価値が高い。エラーメッセージ一つ一つが何を意味するのかを理解し、それがどのような状況で発生するのかを多角的に分析することで、システムの安定稼働を支え、セキュリティを確保するための重要な手がかりを得ることができる。今回取り上げた「400 AuthorizationHeaderMalformed」も、一見すると難解なエラーメッセージだが、その背景にある認証の仕組みやS3の内部処理の順序を理解すれば、問題解決の糸口が見えてくるはずだ。これからもさまざまなエラーメッセージに遭遇するだろうが、それらを一つずつ解読していく姿勢が、優れたシステムエンジニアへの第一歩となる。