こんにちは！インフラやセキュリティの現場にいると、「古い暗号はもう危ないから捨てよう！」という話をよく耳にすると思います。でも、「そもそも古い暗号って何がダメなの？」「TLS 1.3って具体的に何がすごいの？」と疑問に思うことはありませんか？
セキュリティの世界へようこそ！今回は、新人のIT担当者や開発者の方に向けて、AWSのCloudFrontやALB（Application Load Balancer）を使った「TLS 1.3の強制と古い暗号スイートの無効化」について、身近な例えを交えながら一歩ずつ優しく紐解いていきたいと思います。
難しい専門用語が出てきても置いてけぼりにしませんので、ぜひリラックスして読んでいってくださいね！
—
1. 家の鍵で例える「暗号化」と「古い暗号」の危うさ
まずは、私たちが普段使っているWebの通信（HTTPS）が、現実世界でどう動いているのかをイメージしてみましょう。
あなたがネットショップでクレジットカードを使って買い物をする時、あなたのパソコンとお店のサーバーの間でデータのやり取りが行われますよね。この時、通信が丸見えだと、途中で悪い人にカード番号を盗み見られてしまいます。だから、通信を金庫に入れて鍵をかける、つまり「暗号化」しているんです。
レガシーな鍵（古いTLSバージョン）の危険性
ここで問題になるのが「鍵の古さ」です。昔使われていた鍵の仕組み（例えば、TLS 1.0やTLS 1.1といった古いルール）は、例えるなら「昔ながらの簡単な十字型の鍵」のようなものです。
泥棒（サイバー攻撃者）の技術は日進月歩で進化しています。古い十字型の鍵なんて、今の泥棒にかかればピッキングツールで数秒で開けられてしまいますよね。それと同じように、古いTLSバージョンには「解読されやすい脆弱性」がいくつも見つかっているため、現在では「使ってはいけない御法度」とされています。
だからこそ、最新で頑丈なセキュリティの扉である「TLS 1.3」を強制し、古い鍵（TLS 1.0 / 1.1）を完全に締め出す必要があるのです。
—
2. 完全前方秘匿性（PFS）ってなに？ 身近な例えでスッキリ理解
TLS 1.3を語る上で絶対に外せないキーワードが、「完全前方秘匿性（Perfect Forward Secrecy: PFS）」という、なんだか呪文のような名前の仕組みです。漢字が並んでいて難しそうに見えますが、意味が分かると「なるほど！」となりますよ。
マスターキー方式の弱点
これまでの古い暗号スイートでは、サーバーとクライアントが通信を始めるときに「共通の合い言葉（マスターキー）」を1つ決めて、そのキーでずっと会話をしていました。
これを例えるなら、「実家の玄関の合鍵を1本作って、家族みんなで何年もその鍵を使い回している状態」です。
もし万が一、その合鍵が1回でも泥棒に盗まれてしまったらどうなるでしょう？ 過去に家族がその鍵を使って開けたすべての部屋（過去の通信データ）が、後からこっそり覗き見られてしまいますよね。ネットの世界では、悪い人たちが通信データをわざわざ「録画（保存）」しておいて、後からマスターキーが破られた瞬間に過去のやり取りをすべて暴く、という攻撃が行われています。これでは怖すぎますよね。
TLS 1.3とPFSの仕組み
これに対して、TLS 1.3で標準化されているPFS（完全前方秘匿性）を取り入れた通信は、まったく違います。
例えるなら、「会話をするたびに、その場限りの使い捨ての鍵を新しく作り、会話が終わったらシュレッダーで粉々に捨てる」という仕組みです。
これなら、たとえ今日、たまたま運悪く鍵の仕組みを破られたとしても、昨日や一昨日に交わした会話の使い捨ての鍵はもう存在しません。だから、過去のデータは絶対に守られます。「前方へ向かって秘密が守られ続ける（Forward Secrecy）」というのは、こういう素晴らしい理由があるからなんですね。
—
3. クラウド時代の防犯対策：CloudFront / ALBでの実践
「理屈はわかったけれど、実際のインフラではどうやって設定すればいいの？」と思いますよね。
AWSの代表的な配信インフラである CloudFront や ALB では、ポチポチと設定をいじるだけで、この強固なセキュリティを簡単に適用することができます。
ここからは、実務でそのまま役立つ設定のポイントを見ていきましょう！
① AWS ALB（Application Load Balancer）での設定
ALBでHTTPS通信を受け付ける際、リスナーの「セキュリティポリシー」という項目を選択します。ここで古いポリシーを選んでしまうと、レガシーな暗号スイートが許可されてしまいます。
最新かつ安全なセキュリティポリシーを指定する際のイメージを見てみましょう。TerraformなどのIaC（コードによるインフラ管理）ツールを使う場合は、以下のように記述して安全性を担保します。
# ALBのHTTPSリスナー設定のサンプル（Terraform）
resource "aws_lb_listener" "https" {
load_balancer_arn = aws_lb.main.arn
port = 443
protocol = "HTTPS"
ssl_policy = "ELBSecurityPolicy-TLS13-1-2-2021-06" # 推奨：TLS 1.3をサポートし、古い暗号を排除した最新ポリシー
certificate_arn = aws_acm_certificate.example.arn
default_action {
type = "forward"
target_group_arn = aws_lb_target_group.example.arn
}
}ここで指定している ELBSecurityPolicy-TLS13-1-2-2021-06 というポリシーを選ぶのがポイントです。これにより、TLS 1.0や1.1といった古いバージョンは自動的に遮断され、PFSをサポートした安全な暗号スイート（AES-GCMやChaCha20-Poly1305など）だけが許可されます。
② Amazon CloudFront（CDN）での設定
世界中にコンテンツを配信するCloudFrontでも同様です。「ビューア証明書（Viewer Protocol Policy / Security Policy）」の設定で、古いTLSを排除します。
コンソール画面やAPIで設定する際は、以下の点を確認しましょう。
- SSL/TLS トランスポートの最小バージョン:
TLSv1.2_2021またはTLSv1.2_2019（AWS側でTLS 1.3の通信も自動的に処理されます） - レガシーなTLSバージョンの排除:
TLSv1やTLSv1.1は絶対に選択しないようにチェックを外します。
これを行わないと、古いガラケーやサポートが切れた古いブラウザからのアクセスをずるずると許してしまい、セキュリティ監査で「脆弱性あり」と指摘されてしまいます。思い切ってレガシーを切り捨てる勇気が、Webサイトを守る第一歩になります。
—
4. 導入後の落とし穴？ 現場でよくあるトラブルと対策
「よし、じゃあ早速すべての古い暗号を無効化しよう！」と意気込んで設定を変えた後、現場でよくあるのが「一部のユーザーから『サイトが見られない』というクレームが来る」というトラブルです。
これは大抵の場合、ユーザー側が使っている社内システムの古いプログラムや、何年もアップデートしていない古いスマホ（レガシーな環境）が、TLS 1.2や1.3に対応していないことが原因です。
インシデントを防ぐためのアプローチ
いきなり本番環境でバッサリと古い暗号を切り捨てるのではなく、一歩ずつ進めるのがプロの技です。
1. アクセスログの分析: まずはCloudFrontやALBのアクセスログ（またはWAFのログ）を解析し、「現在、どれくらいの割合で古いTLSバージョン（TLS 1.0/1.1）を使ったアクセスが来ているか」を調べます。もし自社の社内システムや特定の古いAPI連携がまだ古いバージョンを使っていれば、先にそちらのプログラムをバージョンアップ（TLS 1.2/1.3対応へ改修）しなければなりません。
2. 段階的な切り捨て: 影響範囲を関係部署にアナウンスし、「〇月〇日以降、古いセキュリティ方式のサポートを終了します」と告知した上で、安全にポリシーを切り替えます。
—
まとめ：一歩ずつ、セキュアなインフラへ
今回は、TLS 1.3の強制と古い暗号スイートの無効化について、家の鍵や使い捨ての合鍵（PFS）の例えを交えて解説しました。
- 古い暗号スイートやTLSバージョン（TLS 1.0/1.1）は、ピッキングされやすい「古い鍵」なので今すぐ無効化する。
- TLS 1.3とPFS（完全前方秘匿性）を導入することで、会話ごとに使い捨ての鍵を生成し、過去の通信データも徹底的に守る。
- CloudFrontやALBの設定（セキュリティポリシー）を最新のものにアップデートし、定期的にログを確認する。
セキュリティの対策と闻くと難しく感じてしまうかもしれませんが、基本の原理は「頑丈な鍵に変えること」の積み重ねです。ぜひ、今日からあなたの担当するインフラ環境の見直しに役立ててみてくださいね。一歩ずつ、安全で強いシステムを作っていきましょう！
コメント