🛡️ CloudFront HTTPセキュリティヘッダー

高級ホテルの門番で理解する!レスポンスにセキュリティを追加する完全ガイド

📌 結論:3つの方法でセキュリティヘッダーを追加できる

🏆 推奨
📋
Response Headers Policy
CloudFront標準機能
コード不要!
設定画面でポチポチするだけ

🏨 ホテルの「標準セキュリティ」
⚡ 高機能
λ
Lambda@Edge
Lambdaで自由にカスタマイズ
複雑なロジックも可能
レイテンシ:やや大きい

🏨 ホテルの「専属コンシェルジュ」
🚀 軽量
CloudFront Functions
軽量・高速な処理
シンプルな変換向き
レイテンシ:最小

🏨 ホテルの「自動ドア」

🏨 HTTPセキュリティヘッダーとは?

🏨 高級ホテルの「セキュリティバッジ」で理解しよう!

👤
お客様
(ブラウザ)
⬇️
📨
リクエスト
「ページをください」
➡️
🏨 CloudFront(高級ホテル)
🛎️
門番(エッジロケーション)
✅ セキュリティバッジを発行
✅ 「このホテルのルール」を伝達
✅ 危険な行為を禁止
➡️
📄
レスポンス
(Webページ)
⬇️
🛡️
セキュリティヘッダー付き
「安全なルール」が添付

🎯 HTTPセキュリティヘッダー = ホテルの「セキュリティルール書」

🏨
CloudFront 高級ホテル(エントランスでルールを伝達)
📋
セキュリティヘッダー 「当ホテルのセキュリティルール」書類
👤
ブラウザ ルールに従う宿泊客
😈
攻撃者 ルールを悪用しようとする不審者

🔐 主要なセキュリティヘッダー6選

🔒
Strict-Transport-Security
HSTS(HTTPS強制)
ブラウザに「このサイトは常にHTTPSで接続してね」と指示。HTTP接続を自動的にHTTPSにリダイレクト。
🏨 ホテルのたとえ

「当ホテルは正面玄関(HTTPS)からのみ入館可能です。裏口(HTTP)は使用禁止!」

📜
Content-Security-Policy
CSP(コンテンツ制限)
どこからスクリプトや画像を読み込めるか制限。XSS攻撃を防ぐ最強の盾。
🏨 ホテルのたとえ

「部屋に持ち込める荷物は、指定の業者からのみ!不審な荷物は受け取り拒否!」

📦
X-Content-Type-Options
MIMEスニッフィング防止
ブラウザが勝手にファイルタイプを推測するのを禁止。悪意あるファイル実行を防ぐ。
🏨 ホテルのたとえ

「荷物のラベルを信用せよ!中身を勝手に開けて確認するな!(偽装防止)」

🖼️
X-Frame-Options
クリックジャッキング防止
このページを他サイトのiframe内に埋め込むことを禁止。偽サイトでの悪用を防ぐ。
🏨 ホテルのたとえ

「当ホテルの写真を他のパンフレットに無断掲載禁止!(偽ホテル対策)」

⚔️
X-XSS-Protection
XSSフィルター有効化
ブラウザ内蔵のXSSフィルターを有効化。反射型XSS攻撃を検知・ブロック。
🏨 ホテルのたとえ

「不審な動きをする宿泊客は、警備員が自動検知して退去させます!」

🔗
Referrer-Policy
リファラー情報制御
リンククリック時に「どこから来たか」情報をどこまで伝えるか制御。プライバシー保護。
🏨 ホテルのたとえ

「宿泊客がどこから来たかは、必要最小限しか外部に伝えません(プライバシー保護)」

🔄 セキュリティヘッダー追加の流れ

CloudFrontでヘッダーが追加されるタイミング

👤
ユーザー
リクエスト
➡️
🌐
CloudFront
取得
➡️
🗄️
オリジン
(S3/ALB等)
🛡️
セキュリティヘッダー
付きレスポンス
⬅️
ヘッダー追加
ここで追加!
⬅️
レスポンス
📄
オリジンからの
レスポンス

💡 ポイント:セキュリティヘッダーはレスポンス時に追加される
オリジン(S3等)を変更せず、CloudFrontだけで対応可能!

⚙️ 3つの方法を詳しく解説

🛠️ どの方法を選ぶべき?

📋
Response Headers Policy
CloudFrontマネージドポリシー
🏆 推奨 簡単

✅ メリット

  • ✨ コード不要(GUI設定のみ)
  • ✨ AWS管理のプリセットあり
  • ✨ レイテンシ影響なし
  • ✨ 追加コストなし
  • ✨ メンテナンス不要

⚠️ デメリット・制限

  • ⚠️ 動的な値設定は不可
  • ⚠️ 複雑な条件分岐は不可
  • ⚠️ カスタムロジックは不可

🎯 こんな場合におすすめ:
「標準的なセキュリティヘッダーを追加したい」「とにかく簡単に設定したい」
90%以上のケースでこれを選べばOK!

λ
Lambda@Edge
エッジで実行するLambda関数
上級者向け 高機能

✅ メリット

  • ✨ 完全なカスタマイズ可能
  • ✨ 動的な値の設定OK
  • ✨ 複雑な条件分岐OK
  • ✨ 外部API呼び出し可能
  • ✨ Node.js / Pythonで記述

⚠️ デメリット・制限

  • ⚠️ コード記述が必要
  • ⚠️ レイテンシが追加される
  • ⚠️ 追加コストがかかる
  • ⚠️ us-east-1でのみ作成可能
  • ⚠️ メンテナンスが必要
📝 Lambda@Edge サンプルコード(Node.js)
exports.handler = async (event) => {
    const response = event.Records[0].cf.response;
    const headers = response.headers;
    
    // セキュリティヘッダーを追加
    headers['strict-transport-security'] = [{
        key: 'Strict-Transport-Security',
        value: 'max-age=31536000; includeSubdomains'
    }];
    headers['x-content-type-options'] = [{
        key: 'X-Content-Type-Options',
        value: 'nosniff'
    }];
    headers['x-frame-options'] = [{
        key: 'X-Frame-Options',
        value: 'DENY'
    }];
    
    return response;
};
CloudFront Functions
軽量・高速な関数
軽量 高速

✅ メリット

  • ✨ Lambda@Edgeより高速
  • ✨ コストが安い(1/6程度)
  • ✨ どのリージョンでも作成可
  • ✨ シンプルな処理に最適

⚠️ デメリット・制限

  • ⚠️ JavaScriptのみ
  • ⚠️ 実行時間1ms以下制限
  • ⚠️ メモリ2MB制限
  • ⚠️ ネットワークアクセス不可
  • ⚠️ 外部ライブラリ使用不可
📝 CloudFront Functions サンプルコード
function handler(event) {
    var response = event.response;
    var headers = response.headers;
    
    // セキュリティヘッダーを追加
    headers['strict-transport-security'] = { 
        value: 'max-age=31536000; includeSubdomains'
    };
    headers['x-content-type-options'] = { 
        value: 'nosniff'
    };
    headers['x-frame-options'] = { 
        value: 'DENY'
    };
    
    return response;
}

📊 3つの方法を比較

🔍 どれを選ぶべき?完全比較表

比較項目 📋 Response Headers Policy λ Lambda@Edge ⚡ CloudFront Functions
🎯 難易度 超簡単 ⭐⭐⭐ 難しい ⭐⭐ 普通
💻 コード記述 不要 必要 必要
⚡ レイテンシ なし 数ms追加 ⚠️ 微小
💰 追加コスト なし あり ⚠️ 少額
🔧 カスタマイズ ⚠️ 限定的 完全自由 ⚠️ 制限あり
🔄 動的な値 不可 可能 可能
🌐 外部API呼出 不可 可能 不可
🏆 おすすめ度 ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐

📝 Response Headers Policyの設定手順

🚀 5ステップで完了!(推奨方法)

1

CloudFrontコンソールを開く

AWSマネジメントコンソール → CloudFront → 対象のディストリビューションを選択

⬇️
2

Behaviorを編集

「Behaviors」タブ → 編集したいBehaviorを選択 → 「Edit」をクリック

⬇️
3

Response Headers Policyを選択

「Response headers policy」セクションで、AWS管理ポリシーまたはカスタムポリシーを選択
おすすめ:「SecurityHeadersPolicy」(AWS管理)

⬇️
4

設定を保存

「Save changes」をクリックして設定を保存

⬇️

完了!🎉

デプロイ完了後(数分)、レスポンスにセキュリティヘッダーが追加されます

⚠️ ベストプラクティス

🎯 セキュリティヘッダー設定の注意点

🔒 HSTSは慎重に

max-ageを長くしすぎると、HTTPに戻せなくなる。まずは短い値(86400=1日)でテストしてから延長。

📜 CSPは段階的に

最初は「Content-Security-Policy-Report-Only」でテスト。いきなり本番適用すると、サイトが壊れる可能性あり。

🧪 ステージング環境でテスト

本番適用前に必ずステージング環境でテスト。SecurityHeaders.comなどのツールで確認。

📊 モニタリングを忘れずに

CloudWatch Logsでエラーを監視。CSP違反レポートを収集して、問題を早期発見。

❓ よくある質問

🤔 S3オリジンでもセキュリティヘッダーを追加できる?
はい、できます!
S3自体にはセキュリティヘッダーを設定する機能がありませんが、CloudFrontのResponse Headers Policyを使えば、S3から配信するコンテンツにもセキュリティヘッダーを追加できます。これがCloudFrontを使う大きなメリットの1つです。
🤔 オリジンが既にセキュリティヘッダーを返している場合は?
設定によって動作が変わります。
Response Headers Policyでは、オリジンのヘッダーを「上書き」するか「維持」するかを選択できます。Lambda@EdgeやCloudFront Functionsでは、コードで自由に制御可能です。
🤔 AWS管理のSecurityHeadersPolicyには何が含まれている?
主要なセキュリティヘッダーが含まれています:
• X-Content-Type-Options: nosniff
• X-Frame-Options: SAMEORIGIN
• X-XSS-Protection: 1; mode=block
• Strict-Transport-Security: max-age=31536000
• Referrer-Policy: strict-origin-when-cross-origin

より厳格な設定が必要な場合は、カスタムポリシーを作成してください。

🎓 まとめ

📋
Response Headers Policy
🏆 推奨!
コード不要
90%のケースでこれでOK
λ
Lambda@Edge
高機能・柔軟
複雑なロジック向け
外部API連携も可能
CloudFront Functions
軽量・高速
シンプルな処理向け
コスト効率◎
🏨 高級ホテルの「セキュリティルール」を思い出そう!

🔒 HTTPS必須(HSTS)= 正面玄関からのみ入館
📜 コンテンツ制限(CSP)= 指定業者の荷物のみ
🖼️ iframe禁止(X-Frame-Options)= パンフレット無断掲載禁止

CloudFrontでセキュリティヘッダーを追加して
安全なWebサイトを構築しよう!🛡️

Created by SSuzuki1063

AWS SAP Learning Resources