🏨 高級ホテルの入口で例えると超わかりやすい！
ALBのセキュリティポリシー = ホテルのドアマンのルールブック
「どんなお客様を通すか」「どんな身分証明を認めるか」を決めるルールです。
プロトコル
= お客様が話す「言語」（新しい言語 vs 古い言語）
暗号化方式
= お客様の荷物を守る「金庫」の種類（最新型 vs 旧型）
このルールブックを
「セキュリティポリシー」
と呼びます✨
🏨 高級ホテルのドアマンで完全理解！
ALB = ホテルの正面玄関
🎯 役割：
お客様（リクエスト）をホテル内（サーバー）に案内する入口。
ただし、誰でも入れるわけではありません！
お客様（リクエスト）をホテル内（サーバー）に案内する入口。
ただし、誰でも入れるわけではありません！
🔐 セキュリティポリシー = ドアマンのルールブック：
「どんな言語を話すお客様を通すか」
「どんなセキュリティカードを持っていれば入れるか」
これを事前に決めておくルールです。
「どんな言語を話すお客様を通すか」
「どんなセキュリティカードを持っていれば入れるか」
これを事前に決めておくルールです。
TLSプロトコル = 言語
🆕 TLS 1.3（最新の言語）：
「今一番安全で効率的な言語」
最新のスマートフォンやブラウザが話せます。
「今一番安全で効率的な言語」
最新のスマートフォンやブラウザが話せます。
📱 TLS 1.2（標準の言語）：
「ほとんどの人が話せる標準語」
少し古いデバイスでも対応可能。
「ほとんどの人が話せる標準語」
少し古いデバイスでも対応可能。
⚠️ TLS 1.0/1.1（古い言語）：
「もう使わないほうがいい古語」
セキュリティに問題あり！
「もう使わないほうがいい古語」
セキュリティに問題あり！
暗号スイート = 金庫の種類
💎 強い暗号（AES-256-GCM）：
「最新の生体認証付き金庫」
破られる可能性がほぼゼロ！
「最新の生体認証付き金庫」
破られる可能性がほぼゼロ！
🔐 標準暗号（AES-128-GCM）：
「一般的な電子ロック金庫」
十分安全で多くの場面で使える。
「一般的な電子ロック金庫」
十分安全で多くの場面で使える。
⚠️ 弱い暗号（RC4、DES）：
「古いダイヤル式金庫」
プロなら簡単に開けられる！危険！
「古いダイヤル式金庫」
プロなら簡単に開けられる！危険！
セキュリティポリシー = ルールの組み合わせ
🎯 つまり：
「どの言語を話すお客様を通すか」＋「どの金庫を使うか」
この組み合わせがセキュリティポリシーです！
「どの言語を話すお客様を通すか」＋「どの金庫を使うか」
この組み合わせがセキュリティポリシーです！
📌 例えば：
• 厳格なポリシー ：「最新言語のみ＋最強金庫のみ」
• 標準ポリシー ：「標準言語も＋普通の金庫もOK」
• 緩いポリシー ：「古い言語も＋古い金庫もOK」
• 厳格なポリシー ：「最新言語のみ＋最強金庫のみ」
• 標準ポリシー ：「標準言語も＋普通の金庫もOK」
• 緩いポリシー ：「古い言語も＋古い金庫もOK」
🧩 セキュリティポリシーの3つの構成要素
TLSプロトコル
何か：
通信の「言語」のバージョン
役割： クライアントとALBが安全に会話するための約束事
例え： 日本語の「旧仮名遣い」と「現代仮名遣い」のような違い
選択肢：
• TLS 1.3（最新・推奨）
• TLS 1.2（標準）
• TLS 1.1/1.0（非推奨）
役割： クライアントとALBが安全に会話するための約束事
例え： 日本語の「旧仮名遣い」と「現代仮名遣い」のような違い
選択肢：
• TLS 1.3（最新・推奨）
• TLS 1.2（標準）
• TLS 1.1/1.0（非推奨）
暗号スイート
何か：
データを暗号化する「方法」の組み合わせ
役割： 通信内容を第三者に見られないようにする
例え： 金庫の「鍵の複雑さ」と「ロックの種類」
含まれるもの：
• 鍵交換方式（ECDHE等）
• 認証方式（RSA等）
• 暗号化方式（AES等）
• ハッシュ関数（SHA等）
役割： 通信内容を第三者に見られないようにする
例え： 金庫の「鍵の複雑さ」と「ロックの種類」
含まれるもの：
• 鍵交換方式（ECDHE等）
• 認証方式（RSA等）
• 暗号化方式（AES等）
• ハッシュ関数（SHA等）
セキュリティポリシー
何か：
上記2つの「許可リスト」
役割： ALBが受け入れる通信条件を定義
例え： ホテルの「入場ルールブック」
AWS提供ポリシー例：
• ELBSecurityPolicy-TLS13-1-2-2021-06
• ELBSecurityPolicy-2016-08
• ELBSecurityPolicy-FS-1-2-Res-2020-10
役割： ALBが受け入れる通信条件を定義
例え： ホテルの「入場ルールブック」
AWS提供ポリシー例：
• ELBSecurityPolicy-TLS13-1-2-2021-06
• ELBSecurityPolicy-2016-08
• ELBSecurityPolicy-FS-1-2-Res-2020-10
📡 TLSプロトコル - バージョン比較
TLS 1.0
1999年〜
⛔ 非推奨
既知の脆弱性あり
PCI DSS非準拠
PCI DSS非準拠
TLS 1.1
2006年〜
⛔ 非推奨
脆弱性が発見済み
主要ブラウザで無効化
主要ブラウザで無効化
TLS 1.2
2008年〜
✅ 現役
広く使われている
古いデバイスも対応
古いデバイスも対応
TLS 1.3
2018年〜
🌟 推奨
最新・最速・最強
ハンドシェイク高速化
ハンドシェイク高速化
💡
TLS 1.3 の主なメリット
1. 高速化：
ハンドシェイクが1往復で完了（TLS 1.2は2往復）= 接続が約33%高速化
2. より安全： 古い脆弱な暗号スイートを完全排除
3. シンプル： 設定ミスが起きにくい構造
4. 0-RTT： 再接続時はさらに高速（ただし注意が必要な機能）
2. より安全： 古い脆弱な暗号スイートを完全排除
3. シンプル： 設定ミスが起きにくい構造
4. 0-RTT： 再接続時はさらに高速（ただし注意が必要な機能）
🔐 暗号スイート - 金庫のグレード
🏦
銀行の金庫で例えると...
暗号スイートは「金庫システム」のようなもの。以下の4つの要素で構成されます：
• 鍵交換方式 = 金庫の「合鍵の渡し方」（ECDHE = 一度だけ使える暗号化されたメッセージで渡す）
• 認証方式 = 金庫を開ける「本人確認」の方法（RSA = 身分証明書で確認）
• 暗号化方式 = 金庫の「ロックの種類」（AES = 最新の電子ロック）
• ハッシュ関数 = 金庫の「改ざん検知」の仕組み（SHA = 封印シール）
• 鍵交換方式 = 金庫の「合鍵の渡し方」（ECDHE = 一度だけ使える暗号化されたメッセージで渡す）
• 認証方式 = 金庫を開ける「本人確認」の方法（RSA = 身分証明書で確認）
• 暗号化方式 = 金庫の「ロックの種類」（AES = 最新の電子ロック）
• ハッシュ関数 = 金庫の「改ざん検知」の仕組み（SHA = 封印シール）
強い暗号
AES-256-GCM
ECDHE鍵交換
SHA-384ハッシュ
→ 金融・医療向け
ECDHE鍵交換
SHA-384ハッシュ
→ 金融・医療向け
標準暗号
AES-128-GCM
ECDHE鍵交換
SHA-256ハッシュ
→ 一般的なWebサイト
ECDHE鍵交換
SHA-256ハッシュ
→ 一般的なWebサイト
弱い暗号
RC4、DES
静的RSA鍵交換
MD5/SHA-1
→ 使用禁止！
静的RSA鍵交換
MD5/SHA-1
→ 使用禁止！
✅ 推奨される暗号スイート
TLS 1.3用：
• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
TLS 1.2用：
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-RSA-AES256-GCM-SHA384
🌟 積極的に使用
• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
TLS 1.2用：
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-RSA-AES256-GCM-SHA384
⚠️ 許容される暗号スイート
互換性のために：
• ECDHE-RSA-AES128-SHA256
• ECDHE-RSA-AES256-SHA384
注意：
古いクライアント対応が必要な場合のみ使用。 新規構築では避けることを推奨。
📌 必要な場合のみ
• ECDHE-RSA-AES128-SHA256
• ECDHE-RSA-AES256-SHA384
注意：
古いクライアント対応が必要な場合のみ使用。 新規構築では避けることを推奨。
🚫 避けるべき暗号スイート
使用禁止：
• RC4系すべて
• DES/3DES系
• MD5使用のもの
• 静的RSA鍵交換
• CBC モード（可能なら避ける）
理由： 既知の脆弱性あり
⛔ 絶対に使わない
• RC4系すべて
• DES/3DES系
• MD5使用のもの
• 静的RSA鍵交換
• CBC モード（可能なら避ける）
理由： 既知の脆弱性あり
📋 AWS提供セキュリティポリシー一覧
| ポリシー名 | TLS 1.3 | TLS 1.2 | TLS 1.1 | TLS 1.0 | 用途 |
|---|---|---|---|---|---|
|
ELBSecurityPolicy-TLS13-1-2-2021-06
🌟 最新推奨 |
✅ | ✅ | ❌ | ❌ | 新規構築に最適 |
| ELBSecurityPolicy-TLS13-1-0-2021-06 | ✅ | ✅ | ✅ | ✅ | TLS 1.3 + 後方互換 |
|
ELBSecurityPolicy-FS-1-2-Res-2020-10
🔒 高セキュリティ |
❌ | ✅ | ❌ | ❌ | 金融・医療向け |
|
ELBSecurityPolicy-2016-08
📌 デフォルト |
❌ | ✅ | ✅ | ✅ | 互換性重視（非推奨） |
| ELBSecurityPolicy-TLS-1-2-2017-01 | ❌ | ✅ | ❌ | ❌ | TLS 1.2のみ |
⚠️
重要な注意点
デフォルトポリシー（ELBSecurityPolicy-2016-08）は古い！
ALBを作成すると自動的にこのポリシーが設定されますが、TLS 1.0/1.1を許可しているため、 セキュリティ監査で指摘されることがあります。
→ 新規構築時は必ずポリシーを変更しましょう！
ALBを作成すると自動的にこのポリシーが設定されますが、TLS 1.0/1.1を許可しているため、 セキュリティ監査で指摘されることがあります。
→ 新規構築時は必ずポリシーを変更しましょう！
💼 ユースケース別：どのポリシーを選ぶ？
金融・医療・政府系
要件：
• PCI DSS / HIPAA 準拠
• 最高レベルのセキュリティ
• 前方秘匿性（Forward Secrecy）必須
• 監査対応が必要
• PCI DSS / HIPAA 準拠
• 最高レベルのセキュリティ
• 前方秘匿性（Forward Secrecy）必須
• 監査対応が必要
推奨ポリシー：
ELBSecurityPolicy-FS-1-2-Res-2020-10
または
ELBSecurityPolicy-TLS13-1-2-2021-06
ELBSecurityPolicy-FS-1-2-Res-2020-10
または
ELBSecurityPolicy-TLS13-1-2-2021-06
一般的なWebサービス
要件：
• モダンブラウザ対応
• バランスの取れたセキュリティ
• パフォーマンス重視
• 新規構築
• モダンブラウザ対応
• バランスの取れたセキュリティ
• パフォーマンス重視
• 新規構築
推奨ポリシー：
ELBSecurityPolicy-TLS13-1-2-2021-06
TLS 1.3の高速化メリットも享受！
ELBSecurityPolicy-TLS13-1-2-2021-06
TLS 1.3の高速化メリットも享受！
レガシーデバイス対応
要件：
• 古いスマートフォン対応
• IoTデバイス接続
• 古いブラウザサポート
• 移行期間中のシステム
• 古いスマートフォン対応
• IoTデバイス接続
• 古いブラウザサポート
• 移行期間中のシステム
推奨ポリシー：
ELBSecurityPolicy-TLS13-1-0-2021-06
⚠️ TLS 1.0/1.1は早めに廃止計画を！
ELBSecurityPolicy-TLS13-1-0-2021-06
⚠️ TLS 1.0/1.1は早めに廃止計画を！
内部システム・API
要件：
• 社内システム間通信
• マイクロサービス間通信
• クライアントを制御可能
• 最新環境のみ
• 社内システム間通信
• マイクロサービス間通信
• クライアントを制御可能
• 最新環境のみ
推奨ポリシー：
ELBSecurityPolicy-TLS13-1-2-2021-06
クライアント側も最新に統一！
ELBSecurityPolicy-TLS13-1-2-2021-06
クライアント側も最新に統一！
🔄 TLS通信の流れ（ハンドシェイク）
クライアント
ブラウザ等
→
🤝 TLSハンドシェイク
1️⃣ クライアント「この言語話せる？」
2️⃣ ALB「この言語でいこう」
3️⃣ 証明書の確認
4️⃣ 暗号鍵の交換
5️⃣ 暗号化通信開始！
2️⃣ ALB「この言語でいこう」
3️⃣ 証明書の確認
4️⃣ 暗号鍵の交換
5️⃣ 暗号化通信開始！
→
ALB
セキュリティポリシー適用
→
バックエンド
EC2等
📌 セキュリティポリシーが判断するポイント
1. プロトコルバージョン
クライアントが提示したTLSバージョンは許可されているか？
クライアントが提示したTLSバージョンは許可されているか？
2. 暗号スイート
クライアントが提示した暗号方式は許可されているか？
クライアントが提示した暗号方式は許可されているか？
3. マッチング
両方OKなら最も強い組み合わせで接続！
両方OKなら最も強い組み合わせで接続！
💡
セキュリティポリシー選択のベストプラクティス
1. 新規構築は最新ポリシーを選択：
デフォルトの「ELBSecurityPolicy-2016-08」は使わない。 「ELBSecurityPolicy-TLS13-1-2-2021-06」を選択しよう。
2. TLS 1.0/1.1は廃止の方向で：
2020年以降、主要ブラウザはTLS 1.0/1.1を無効化。 レガシー対応が必要でも、廃止計画を立てよう。
3. 前方秘匿性（Forward Secrecy）を確保：
「FS」が含まれるポリシーを選ぶと、過去の通信が後から解読されるリスクを軽減。
4. 定期的な見直し：
AWSは新しいポリシーを追加し続けている。年1回は最新ポリシーへの移行を検討。
5. テスト環境で検証：
ポリシー変更前に、対象クライアントが接続できるかテスト環境で必ず確認！
6. CloudWatchでモニタリング：
TLSネゴシエーション失敗のメトリクスを監視し、問題を早期発見。
デフォルトの「ELBSecurityPolicy-2016-08」は使わない。 「ELBSecurityPolicy-TLS13-1-2-2021-06」を選択しよう。
2. TLS 1.0/1.1は廃止の方向で：
2020年以降、主要ブラウザはTLS 1.0/1.1を無効化。 レガシー対応が必要でも、廃止計画を立てよう。
3. 前方秘匿性（Forward Secrecy）を確保：
「FS」が含まれるポリシーを選ぶと、過去の通信が後から解読されるリスクを軽減。
4. 定期的な見直し：
AWSは新しいポリシーを追加し続けている。年1回は最新ポリシーへの移行を検討。
5. テスト環境で検証：
ポリシー変更前に、対象クライアントが接続できるかテスト環境で必ず確認！
6. CloudWatchでモニタリング：
TLSネゴシエーション失敗のメトリクスを監視し、問題を早期発見。
⚙️ セキュリティポリシーの設定方法
📋 AWS CLIでの設定例
# HTTPSリスナーのセキュリティポリシーを変更 aws elbv2 modify-listener \ --listener-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:listener/app/my-alb/xxx/yyy \ --ssl-policy "ELBSecurityPolicy-TLS13-1-2-2021-06" # 現在のポリシーを確認 aws elbv2 describe-listeners \ --listener-arns arn:aws:elasticloadbalancing:... \ --query "Listeners[].SslPolicy"
🖥️ マネジメントコンソールでの設定
- EC2 → ロードバランサー → 対象のALB選択
- 「リスナー」タブを開く
- HTTPSリスナーを選択
- 「編集」をクリック
- 「セキュリティポリシー」を変更
- 「変更を保存」
⚠️ 設定時の注意点
- ✅ HTTPSリスナーのみに適用される
- ✅ 変更は即座に反映される
- ✅ 既存の接続には影響しない
- ✅ 新しい接続から新ポリシー適用
- ⚠️ 厳しいポリシーは古いクライアントを拒否
- ⚠️ 事前にテスト環境で検証推奨
🎓 まとめ
🏨 ホテルのドアマン = ALBセキュリティポリシー
「どの言語（TLSプロトコル）を話すお客様を通すか」＋
「どの金庫（暗号スイート）を使うか」を決めるルールブック
📡
TLSプロトコル
通信の「言語」
TLS 1.3 / 1.2 推奨
TLS 1.0 / 1.1 は廃止へ
🔐
暗号スイート
データを守る「金庫」
AES-GCM 推奨
RC4、DES は禁止
📋
ポリシー選択
用途に合わせて選択
新規は最新を選ぶ
定期的に見直す
🎯 結論：迷ったらこれ！
新規構築？
→
ELBSecurityPolicy-TLS13-1-2-2021-06
金融・医療系？
→
ELBSecurityPolicy-FS-1-2-Res-2020-10
レガシー対応必須？
→
ELBSecurityPolicy-TLS13-1-0-2021-06
+ 廃止計画
セキュリティポリシーは
「守りの要」
🛡️
デフォルトのまま放置せず、適切なポリシーを選んで
安全な通信環境を構築しましょう！🎉