はじめに
情報漏洩のニュースが相次ぐ昨今、自分が関わるシステムでも、外部から内部情報が見えてしまっていないかを確認しました。
システム構築後の試験中に curl -I でレスポンスヘッダーを確認したところ、AWSの内部情報を含むヘッダーが、構築した全環境（本番・ステージング・開発）で返っていることに気づきました。本件は関係者に報告済みで、現在は修正済みです。本記事では、同様の問題がないかを確認する方法と、考えられる対処方法をまとめます。
なお、筆者は当該環境のAWSアカウントへの権限を持っていないため、原因の特定や設定変更は筆者自身では行っていません。原因については仮説として記載し、読者の方が自分の環境で確認できる手順を載せています。
以下は一般的な対処方法です。実際に当該環境で採用された方法とは異なる場合があります。本番環境に適用する前に、必ず検証環境で動作を確認してください。
先に結論
-
curl -Iで、S3のメタデータやKMSキーのARNなどが見える場合がある - httpとhttpsの両方を確認する（httpはリダイレクトだけが返り、問題のヘッダーが見えないことがある）
- 秘密情報として厳重に扱う必要はないとされることが多い
- ただし、不要な内部情報は出さないほうが安全（防御の多層化）
確認方法
自分が管理している環境（または許可を得た環境）で、次のコマンドを実行します。
curl -sI http://example.com
curl -sI https://example.com
-s は進捗表示を消すオプション、-I はヘッダーのみを取得（HEADリクエスト）するオプションです。
特定のヘッダーだけ見たい場合は、次のようにします。
curl -sI https://example.com | grep -i -E '^(server|x-amz)'
httpの結果（例）
HTTP/1.1 301 Moved Permanently
Server: CloudFront
Location: https://example.com/
HTTPからHTTPSへのリダイレクトはCloudFrontが返すため、オリジン（S3）のヘッダーは見えません。
httpsの結果（例）
HTTP/1.1 403 Forbidden
Server: AmazonS3
x-amz-server-side-encryption: aws:kms
x-amz-server-side-encryption-aws-kms-key-id: arn:aws:kms:ap-northeast-1:123456789012:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
x-amz-server-side-encryption-bucket-key-enabled: true
x-amz-meta-codebuild-buildarn: arn:aws:codebuild:ap-northeast-1:123456789012:build/xxxxxxxx
x-amz-meta-codebuild-content-sha256: xxxxxxxx
x-amz-meta-codebuild-content-md5: xxxxxxxx
x-amz-version-id: xxxxxxxx
※ アカウントIDなどは伏せています（123456789012 はAWSドキュメントの例示用IDです）。
見えていた情報とリスク
| ヘッダー | 見える情報 | 評価 |
|---|---|---|
x-amz-server-side-encryption-aws-kms-key-id |
AWSアカウントID、KMSキーARN | 暗号化方式とキーの存在が分かる |
x-amz-meta-codebuild-buildarn |
AWSアカウントID、CodeBuildのビルドID | CI/CDにCodeBuildを使っていることが分かる |
Server: AmazonS3 |
オリジンがS3であること | 構成の一部が分かる |
リスクの考え方（過大評価しないために）
- AWSアカウントIDは、AWSが厳密な機密情報として扱っているものではありません。IDが分かっただけでIAMにログインできるわけではありません。
- 一方で、アカウントIDやARNは、攻撃者にとっての偵察情報になります。たとえば、IAMロールやユーザーの存在を推測する材料に使われる可能性が知られています。
- そのため、単体で侵入されるほどの脆弱性ではないものの、不要な情報は出さないのが望ましい、という位置づけです（深刻度は低め）。
403なのにメタデータが見える理由（仮説・未検証）
通常、S3がアクセスを拒否した場合、オブジェクト固有のメタデータは返らないと考えられます。それにもかかわらず今回メタデータが見えていたため、次の可能性を考えています。
- CloudFrontのカスタムエラーレスポンスが設定されており、403のときに
/index.htmlを返している - その結果、
index.htmlのヘッダー（暗号化情報やCodeBuildのメタデータ）がそのまま返っている
SPA（シングルページアプリ）では、403/404を index.html に置き換える設定がよく使われます。
⚠️ これは仮説です。筆者は環境の設定を確認できていないため、実際の原因は異なる可能性があります。
もしこの仮説が当たっている場合、「403だからアクセスは拒否されている」と考えるのは誤りで、実際にはコンテンツが返っていることになります。
自分の環境で確認する方法
方法1: curlで比較する（権限不要）
# 存在しないパス
curl -sI https://example.com/this-path-does-not-exist
# index.html を直接
curl -sI https://example.com/index.html
# 本文の確認
curl -s https://example.com/this-path-does-not-exist | head -n 20
存在しないパスのヘッダーが /index.html のものと一致し、本文がHTMLであれば、カスタムエラーレスポンスが関係している可能性が高いです。
方法2: コンソールで確認する（権限がある場合）
- AWSコンソール → CloudFront → 該当ディストリビューション
- 「エラーページ」タブで、403/404に対するカスタムエラーレスポンスの有無を確認
方法3: AWS CLIで確認する（権限がある場合）
aws cloudfront get-distribution-config --id <ディストリビューションID> \
--query 'DistributionConfig.CustomErrorResponses'
対処方法の例
以下は一般的な対処方法です。筆者の環境では実施・検証していません。本番環境に適用する前に、必ず検証環境で動作を確認してください。
対処1: CloudFrontのレスポンスヘッダーポリシーで削除する
CloudFrontの機能で、オリジンから受け取ったヘッダーを、ビューアーに返す前に削除できます。
- AWSコンソール → CloudFront → ポリシー → レスポンスヘッダー → ポリシーを作成
- ヘッダーの削除設定で、次のヘッダーを追加する（コンソールの表記は変更されることがあります）
x-amz-server-side-encryption
x-amz-server-side-encryption-aws-kms-key-id
x-amz-server-side-encryption-bucket-key-enabled
x-amz-meta-codebuild-buildarn
x-amz-meta-codebuild-content-sha256
x-amz-meta-codebuild-content-md5
x-amz-version-id
3. 該当ディストリビューションのビヘイビアに、作成したポリシーを適用する
Server: AmazonS3 を削除対象にできるかは、筆者は未確認です。
対処2: CloudFront Functionsなどで削除する
ヘッダーポリシーで削除できないヘッダーがある場合は、CloudFront Functions（viewer response）やLambda@Edgeでヘッダーを削除する方法もあります。
対処3: 暗号化方式を見直す
SSE-KMSを使っているとKMSキーのARNがヘッダーに出ます。要件上問題なければ、SSE-S3にするとARNは出なくなります。
ただし、次の点に注意が必要です。
- バケットのデフォルト暗号化を変えても、既存オブジェクトは自動では変わらない（再アップロードなどが必要）
- 監査や権限管理でKMSを使う要件がある場合は、変更できない
対処4: CodeBuild側のメタデータ
x-amz-meta-codebuild-* はCodeBuildがS3に成果物を配置する際に付与されるものと考えています。ただし、これを止める設定が存在するかは筆者は確認できていません。ヘッダー側で消す（対処1・2）のが現実的だと思います。
対処後の確認
対処後は、必ず同じコマンドで再確認してください。
curl -sI https://example.com | grep -i -E '^(server|x-amz)'
ヘッダーが消えていれば成功です。
まとめ
-
curl -sIをhttpとhttpsの両方で実行すると、CloudFront配信のレスポンスヘッダーに内部情報が出ていないか確認できる - AWSアカウントIDは単体で致命的な情報ではないが、不要な情報は出さないほうがよい
- 403でもメタデータが見える場合、カスタムエラーレスポンスが関係している可能性がある（未検証）
- 対処は、レスポンスヘッダーポリシーでの削除が手軽
免責事項
- 本記事は、筆者個人の調査・見解に基づくもので、所属組織の見解を示すものではありません。
- 「403なのにメタデータが見える理由」および「対処方法の例」は、筆者が自分で検証したものではなく、一般的な情報に基づく仮説・例示です
- 本記事の内容の正確性・完全性は保証しません。特に「403なのにメタデータが見える理由」は筆者の仮説であり、検証していません。
- 本記事で紹介する確認コマンドは、自分が管理する環境、または明示的に許可を得た環境でのみ実行してください。第三者のサイトに対する無断の調査は行わないでください。
- 設定変更は、サービスへの影響が出る可能性があります。本番環境に適用する前に、必ず検証環境で確認してください。
- 本記事の内容を利用したことで生じた損害について、筆者は責任を負いません。
- 記載しているドメイン、アカウントID、ARN、ハッシュ値はすべて例示用の値であり、実在のものではありません。