こんにちは！インフラやセキュリティの世界へようこそ。
新人のIT担当者や、「セキュリティって何だか難しそう……」と不安を感じている開発者の皆さんに向けて、日々の業務で役立つ知識を優しく、そして現場のリアルな視点でお伝えしていきますね。
今回は、クラウドインフラの玄関口である「ロードバランサー（ALB / NLB）のTLS終端と、最新暗号スイートの強制」というテーマを取り上げます。
「いきなりアルファベットの専門用語が出てきて頭が痛くなりそう……」と思いましたか？大丈夫です！身近な例えから一歩ずつ紐解いていきましょう。
—
1. 家の鍵に例える「通信の暗号化」とTLSの基本
皆さんが普段、ネットショッピングをしたり社内システムにログインしたりするとき、URLの先頭が https:// から始まっているのを見たことがありますよね。あの「s」は「Secure（安全）」の頭文字で、ブラウザとサーバーの間で行われるやり取りが、第三者に見えないようにこっそり暗号化されていることを意味しています。
この暗号化の仕組みを支えているのが TLS（Transport Layer Security） という技術です（昔の名前であるSSLと呼ばれることも多いですね）。
ここで、ちょっと身近な防犯に例えてみましょう。
想像してください。あなたが大切な手紙を遠くの友人に送るとき、その辺の道端にポイッとむき出しのまま置いていたらどうなりますか？通りすがりの人に中身を読まれてしまいますよね。これが、暗号化されていない http:// の状態です。
そこで、頑丈な鍵付きのジュラルミンケースに手紙を入れて送ることにしました。この「鍵付きのケース」こそが TLS です。そして、「どの鍵を使って施錠するか」というルールの組み合わせのセットを、セキュリティの世界では「暗号スイート（Cipher Suite）」と呼んでいます。
—
2. 古い鍵（TLS 1.0 / 1.1）が抱えるヤバい現実と攻撃者の狙い
さて、ここで問題です。昔の家で使われていたような「古いタイプのピッキングしやすい鍵」を今でも使い続けていたらどうなるでしょうか？
泥棒は、簡単にその鍵を破って家に侵入してしまいますよね。
インターネットの世界も全く同じです。
古いバージョンの TLS 1.0 や TLS 1.1、そして古くて脆弱な暗号スイート（例えば RC4 や 3DES など）には、すでに設計上の古い弱点がいくつも見つかっています。
攻撃者（ハッカー）は、まさにこの「手薄な裏口」を常に狙っています。
もしユーザーが古いスマホやブラウザからあなたのシステムにアクセスしたとき、ロードバランサーが「あ、古い鍵でもいいですよ、どうぞどうぞ」と受け入れてしまったらどうなるでしょう？
途中のネットワーク経路で悪意ある人物に通信を傍受され、パスワードやクレジットカード情報などの機密データが丸見えになってしまうんです。これが、古い暗号化を放置する最大の恐怖です。
—
3. ロードバランサー（ALB / NLB）の「TLS終端」ってなに？
ここで、クラウド（AWSなど）でよく使われるロードバランサー（ALB：Application Load Balancer / NLB：Network Load Balancer）の出番です。
ロードバランサーは、いわば「会社の巨大なエントランス受付」のような役割をします。世界中からやってくる大量のアクセスを、裏で動いている複数のサーバー（Webサーバーなど）にバランスよく振り分けてくれます。
このエントランスで、外部からやってきた暗号化された通信の「鍵をパカッと開けて（これをTLS終端と呼びます）」、平文（通常のデータ）にしてから後ろのサーバーへ渡す、という処理をロードバランサーに一任するのが現代のクラウドインフラの基本アプローチです。
裏側のサーバー一台一台に重たい暗号化・復号化の計算をさせると、サーバーのCPUが悲鳴を上げてしまいますからね。エントランス（ロードバランサー）が一手に引き受けて効率化するわけです。
—
4. 完全前方秘匿性（PFS：Perfect Forward Secrecy）という最強の盾
さて、今回のテーマのもう一つのキモである PFS（Perfect Forward Secrecy / 完全前方秘匿性） についてもお話ししておきましょう。
これが何かと言うと、「万が一、将来的にサーバーのマスターキー（合鍵の大元）が何らかの理由で盗まれてしまったとしても、過去にやり取りしたすべての通信の秘密は絶対に守られる」という、極めて強力なセキュリティの仕組みです。
一般的な古い暗号方式だと、もしマスターキーが敵の手に渡ってしまったら、過去に録音（傍受）して保存しておいた通信データをすべて巻き戻して解読されてしまいます。これはタイムマシンで過去の秘密をのぞき見されるようなものです。
しかし、PFSをサポートする暗号スイートを使っていれば、通信ごとに毎回「その場限りの使い捨ての鍵（一時セッションキー）」が自動生成され、使い終わったら秒で捨てられます。だから、たとえ将来マスターキーが盗まれても、過去の通信データはゴミクズのままで、絶対に中身を読まれません。
現場のエンジニアとしては、「PFSをサポートしない古い暗号スイートは、セキュリティポリシーとして一切排除する」という強い意志を持つことが求められます。
—
5. 実務で設定する！最新かつ安全なセキュリティポリシーの例
それでは、実際にAWSのALBなどで適用すべき「モダンで安全な設定」の具体例を見ていきましょう。
AWSでは、あらかじめ推奨されるセキュリティポリシー（Predefined Security Policy）が用意されています。
インフラをコードで管理する（IaC）時代ですので、ここでは例として Terraform を使った設定コードを見てみましょう。実務でそのまま参考にできるように、日本語で丁寧にコメントを添えておきます。
# AWSのApplication Load Balancer (ALB) にアタッチするHTTPSリスナーの設定例
resource "aws_lb_listener" "https_listener" {
load_balancer_arn = aws_lb.main.arn
port = 443
protocol = "HTTPS"
# SSL証明書の指定
certificate_arn = aws_acm_certificate.issued.arn
# 【超重要】AWSが提供する最新かつ最も安全な事前定義セキュリティポリシーを指定
# 古いTLS 1.0/1.1を完全に排除し、TLS 1.2およびTLS 1.3のみを許可します
ssl_policy = "ELBSecurityPolicy-TLS13-1-2-2021-06"
default_action {
type = "forward"
target_group_arn = aws_lb_target_group.app.arn
}
}この設定のポイント
ssl_policyにELBSecurityPolicy-TLS13-1-2-2021-06というモダンなポリシーを指定しています。- これにより、脆弱な古いプロトコル（TLS 1.0や1.1）や、PFSに対応していない古い暗号スイートが自動的に弾かれます。
- 開発者やインフラ担当者が個別の複雑な暗号スイートの文字列を羅列してミスをするリスクを減らし、AWSの推奨するベストプラクティスを安全に適用できるのがメリットです。
—
6. まとめ：一歩ずつ、安全なインフラを作っていこう
今回は、ロードバランサーのTLS終端と最新の暗号スイートの強制について、防犯や鍵の例えを交えながら解説しました。
セキュリティの対策は、一度構築して終わりではなく、時代の変化（新しい脆弱性の発見など）に合わせてアップデートしていく継続的な営みです。「うちは古いシステムもあるから……」と妥協せず、サポートが終了した古いTLSや暗号スイートは勇気を持って無効化していきましょう。
「小難しい用語がたくさん出てきたな」と感じた方も、まずは「通信の鍵を新しく丈夫なものに作り替えるんだな」というイメージを持っていただければ大成功です。
一歩ずつ、確実に安全なシステム環境を作っていきましょう！それではまた次回の技術解説でお会いしましょう。
コメント