🏨 高級ホテルの「入館セキュリティ」で例えると超わかりやすい！
TLSセキュリティポリシー = ホテルの入館規則
「どんな身分証明書を持っている人を入れるか」を決めるルールです。
最新のパスポートしか認めないか、古い免許証でもOKか...
セキュリティを高めれば
安全だけど、古いお客様は入れなくなる
緩くすれば
多くのお客様を受け入れられるけど、リスクも上がる
このバランスを理解しましょう！✨
🏨 ホテルの入館システムで理解するTLSポリシー
TLSプロトコル = 鍵の種類
ホテルの部屋の鍵には世代があります。
🔑 TLS 1.3 = 最新のスマートロック
🗝️ TLS 1.2 = ICカードキー
🔐 TLS 1.1 = 古いマグネットキー
🗃️ TLS 1.0 = 昔ながらの金属キー
新しい鍵ほど セキュリティが高い けど、
古いお客様（ブラウザ）は対応していないことも。
暗号スイート = 本人確認方法
ホテルでの本人確認にも種類があります。
🛂 AES-256-GCM = 顔認証 + 指紋 + パスポート
📱 AES-128-GCM = 顔認証 + ICカード
💳 AES-256-CBC = ICカード + 暗証番号
📝 3DES = 紙の宿泊台帳（古い）
セキュリティポリシーは 「どの本人確認方法を許可するか」 を決めるルール！
⭐ ALBのデフォルトTLSポリシー
- ✅ TLS 1.3 最新・最強
- ✅ TLS 1.2 現在の主流
- ❌ TLS 1.1 非対応
- ❌ TLS 1.0 非対応
- 🔒 Forward Secrecy 対応
- 🔐 AEAD暗号 （GCM）対応
- ⚡ 高速化 （TLS 1.3）
- 🏅 PCI DSS 準拠
- 📊 セキュリティ： 高い
- 🌐 互換性： 良好
- ⚡ パフォーマンス： 優秀
- ✨ おすすめ度： ★★★★★
- 🌐 Chrome 30以降
- 🦊 Firefox 27以降
- 🧭 Safari 7以降
- 📱 iOS 9以降
📱 古いクライアントとの互換性チェック
デフォルトポリシー（TLS13-1-2-2021-06） で接続できるクライアント
TLS 1.2/1.3両方サポート。
High Sierra以降なら安心。
TLS 1.3もサポート。
Chrome for Androidは自動更新。
Chrome/Firefoxなら問題なし。
接続不可。アップグレード必須。
TLS 1.2非サポートのため接続不可。
TLS 1.2対応が不完全。
• 社内システムで古いWindows 7 + IE11ユーザーがいる
• 組み込み機器やIoTデバイスが古いTLSしか対応していない
• 海外の一部地域で古い端末の利用率が高い
→ ただし、セキュリティリスクを十分に理解した上で判断してください！
📊 主要TLSポリシー比較表
| ポリシー名 | TLS 1.3 | TLS 1.2 | TLS 1.1 | TLS 1.0 | 用途 |
|---|---|---|---|---|---|
|
TLS13-1-2-2021-06
⭐ デフォルト推奨 |
✅ | ✅ | ❌ | ❌ | 通常のWebサービス |
|
TLS13-1-3-2021-06
最高セキュリティ |
✅ | ❌ | ❌ | ❌ | 最新クライアント限定 |
|
FS-1-2-Res-2020-10
Forward Secrecy重視 |
❌ | ✅ | ❌ | ❌ | 金融・医療系 |
|
TLS-1-2-2017-01
TLS 1.2限定 |
❌ | ✅ | ❌ | ❌ | 標準的なセキュリティ |
|
TLS-1-1-2017-01
⚠️ レガシー |
❌ | ✅ | ✅ | ❌ | 古いクライアント対応 |
|
TLS-1-0-2015-04
⛔ 非推奨 |
❌ | ✅ | ✅ | ✅ | 最大互換性（非推奨） |
🔐 デフォルトポリシーの暗号スイート詳細
⚡ TLS 1.3 暗号スイート
- TLS_AES_128_GCM_SHA256
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
🚀 すべてAEAD暗号で高速・高セキュリティ
🛡️ TLS 1.2 暗号スイート（ECDHE系）
- ECDHE-ECDSA-AES128-GCM-SHA256
- ECDHE-RSA-AES128-GCM-SHA256
- ECDHE-ECDSA-AES256-GCM-SHA384
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-ECDSA-AES128-SHA256
- ECDHE-RSA-AES128-SHA256
🔒 Forward Secrecy対応で安全
📋 暗号強度の説明
- GCM = 認証付き暗号（推奨）
- AES-256 = 最強の対称暗号
- AES-128 = 十分に強力
- ECDHE = 楕円曲線鍵交換
- SHA-384 = 強力なハッシュ
💎 すべて業界標準を満たす強度
❌ サポートしない暗号（安全のため）
-
RC4- 脆弱性あり -
3DES- 古い・遅い -
MD5- 衝突攻撃に脆弱 -
EXPORT暗号- 意図的に弱い -
NULL暗号- 暗号化なし
🚫 これらを使うポリシーは避けましょう
💼 ユースケース別：どのポリシーを選ぶ？
一般的なWebサービス
幅広いユーザーにサービスを提供する場合。
デフォルトのままでOK！セキュリティと互換性のベストバランス。
金融・医療系システム
最高レベルのセキュリティが求められる場合。
TLS 1.3のみ。最新クライアント限定で最強セキュリティ。
社内システム（レガシー環境）
社内システムやイントラネット。
TLS 1.2のみ。より多くの暗号スイートをサポート。
IoT・組み込み機器
アップデートが難しいIoTデバイスとの通信。
⚠️ TLS 1.1は脆弱。可能な限り機器のアップグレードを検討。
🤔 ポリシー選択フローチャート
❓ 古いクライアント（TLS 1.1以下）をサポートする必要がある？
NO（通常はこっち）
→
デフォルトポリシーでOK！
TLS13-1-2-2021-06
YES
→ レガシーポリシーを検討
⚠️ リスクを理解した上で
❓ 最高レベルのセキュリティが必要？（金融・医療など）
YES
→
TLS 1.3専用ポリシー
TLS13-1-3-2021-06
NO（通常のセキュリティ）
→
デフォルトで十分！
TLS13-1-2-2021-06
AWSが推奨するデフォルトポリシーは、セキュリティと互換性のバランスが最適化されています。
2. 定期的に見直す：
TLSの世界は進化しています。年に1回は最新の推奨ポリシーをチェックしましょう。
3. 古いポリシーは避ける：
TLS 1.0/1.1をサポートするポリシーは、特別な理由がない限り使用しないでください。
4. テスト環境で確認：
ポリシー変更前に、実際のクライアントで接続テストを行いましょう。
5. CloudWatchでモニタリング：
TLSネゴシエーション失敗をアラートで監視し、互換性問題を早期発見しましょう。
🎓 まとめ
🏨 ホテルの入館規則 = TLSセキュリティポリシー
「どんな鍵（プロトコル）」と「どんな本人確認（暗号スイート）」を許可するか
セキュリティと互換性のバランスを決めるルールです
TLS13-1-2-2021-06
ほとんどのケースで
これでOK！
TLS 1.2 / 1.3
2015年以降の
ほぼ全ブラウザ対応
IE10以前、iOS 8以前
Android 4.xは
接続不可
🎯
結論：
特別な理由がなければ
デフォルトポリシーを使おう！
古いクライアント対応が必要なら、リスクを理解した上で
レガシーポリシーを検討しましょう 🔐