こんにちは！クラウドの裏側でパケットの交通整理に日々奔走しているSREの私です。
AWSの世界へようこそ！Webアプリケーションを公開するとき、皆さんは必ず「ロードバランサー（ALB: Application Load Balancer）」を使うことになりますよね。世界中からやってくるユーザーのリクエストを受け止め、背後のサーバーたちへ上手に振り分けてくれる、いわばインフラの「優秀なコンシェルジュ」です。
さて、このコンシェルジュとお客さまが安全にお話（通信）をするためには、暗号化のルールである「TLS（Transport Layer Security）」が欠かせません。PCI DSSなどの厳しいセキュリティ基準をクリアしつつ、現代のモダンなWebサイトを作るためには、このTLSのバージョンや「暗号スイート」の選び方を知っておく必要があります。
「なんだか暗号とかバージョンとか、英語がいっぱいで難しそう…」と思いましたか？
大丈夫です！今回は、インフラやネットワークに初めて触れる方でもスルスルと理解できるよう、身近な例えを交えて一歩ずつ紐解いていきましょう！
—
1. TLSってなぁに？ 身近な例えでイメージしよう
まずは「TLS」がどんなものか、イメージを膨らませてみましょう。
インターネットの世界は、まるで「ハガキ」で手紙を送るようなものです。暗号化されていない「HTTP」通信は、宛先も中身も、途中ですれ違う郵便配達員（ルーターやプロバイダ）に丸見えの状態なんですよね。パスワードやクレジットカード情報をハガキに書いて送るなんて、ちょっとゾッとしますよね。
そこで登場するのが「TLS」です。
TLSを使うと、手紙の内容を頑丈な「ダイヤル式金庫」に入れて送るようなイメージになります。
- 鍵の受け渡し（ハンドシェイク）： コンシェルジュ（ALB）とお客さまが、「この合言葉（暗号の鍵）でやり取りしましょうね」とこっそり約束を交わします。
- 通信の保護（暗号化通信）： その後、金庫の中身（通信データ）は完全にスクランブル（暗号化）され、万が一途中で盗み見られても、絶対に中身を読み取られることはありません。
この「安全な金庫の仕組み」には、歴史とともにいくつかのバージョンが存在します。それが、今回主役となる TLS 1.0, TLS 1.1, TLS 1.2, そして最新の TLS 1.3 です。
—
2. ALBで選べるTLSの歴史と「世代交代」
ALBのリスナー（お客さまの窓口）を設定するとき、どのTLSバージョンを許可するかを選ぶことができます。それぞれの特徴を、古いものから順番に見ていきましょう。
TLS 1.0 と TLS 1.1（もう「引退」した古い世代）
これらは2000年代初頭に生まれた、いわば「昔の頑丈な鍵」です。当時は最先端でしたが、その後の技術の進歩とともに、数学的な弱点（脆弱性）が見つかるようになりました。
今や世界中の主要なセキュリティ基準（PCI DSSや主要ブラウザのベンダーなど）で「もう使ってはいけない！」と完全に引退勧告が出されています。現代のインフラでは、これらを有効にしておく理由はありません。
TLS 1.2（今なお支える「主力選手」）
2008年に登場したこのバージョンは、非常に長持ちしている優等生です。今でも多くの古いデバイスやシステムと通信するために、なくてはならない主力選手として活躍しています。
後述する「モダンな暗号スイート」と組み合わせることで、現在でも十分高い安全性を保つことができます。
TLS 1.3（圧倒的なスピードと安全性を誇る「最新鋭」）
2018年に登場した、最も新しく、最もクールなプロトコルです。
何がすごいって、「安全性が高くなった」だけでなく、「通信が速くなった」んです。従来のバージョンでは、鍵をやり取りするまでに何度も「キャッチボール（往復通信）」をする必要がありましたが、TLS 1.3ではそれが劇的に簡略化されました。スマホでWebページを開いたときの「最初の表示の速さ」に直結するため、特別な理由がない限り、私たちは今この TLS 1.3 を積極的に採用していきたいところです。
—
3. 暗号スイート（Cipher Suites）ってなに？
TLSのバージョンが決まったら、次は「どの料理のレシピ（暗号化のアルゴリズムの組み合わせ）を使うか」を選びます。これが暗号スイートです。
暗号スイートの名前は、最初は呪文のように見えますよね。例えば、AWSの最新ポリシーで推奨されるものの一つに ELB-TLS-1-2-2017-01 などに含まれる以下のような組み合わせがあります。
ECDHE-ECDSA-AES128-GCM-SHA256「うわ、長い！」と思わず声が出そうになりますが、実は左から順に役割が綺麗に分かれているだけです。分解して読んでみましょう！
1. ECDHE (鍵交換アルゴリズム):
お互いの通信で使う「共通の秘密の鍵」を安全に作り出すための仕組みです。「前方秘匿性（PFS: Perfect Forward Secrecy）」という超重要機能を持っており、万が一将来マスターキーが漏洩したとしても、過去の通信データが芋づる式に復号されないよう守ってくれます。
2. ECDSA または RSA (認証アルゴリズム):
「私は本物のALBですよ」と証明するためのデジタル証明書の方式です。
3. AES128-GCM (暗号化アルゴリズム):
実際にデータをガチガチに暗号化する本体です。現代のコンピュータで高速に処理でき、かつ安全性が高いものを選びます。
4. SHA256 (ハッシュ関数):
データが途中で改ざんされていないかをチェックするための「封印シール」のようなものです。
古い暗号スイート（例：RC4 や 3DES など）は、すでに鍵の解読方法がハッキンググループに破られているため、絶対に選ばないように設定を絞り込むのがSREの腕の見せ所です。
—
4. 実務で役立つ！AWS CLIを使ったALBのリスナーポリシー設定例
それでは、実際の現場でどのように設定するのかを見てみましょう。
AWSでは、あらかじめ用意された安全なプリセット（セキュリティポリシー）をALBに割り当てるのが一般的です。
例えば、最新のセキュリティ要件を満たすために、TLS 1.2 と TLS 1.3 のみを許可し、古い暗号スイートを完全に排除したポリシー（ELB-TLS-1-2-Ext-2020-06 など）をHTTPSリスナーに適用する場合のAWS CLIコマンドの例は以下のようになります。
# 既存のHTTPSリスナー（ポート443）のセキュリティポリシーをモダンなものに更新するコマンド
aws elbv2 modify-listener \
--listener-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:listener/app/my-alb/1234567890abcdef/abcdef1234567890 \
--ssl-policy ELB-TLS-1-2-Ext-2020-06実務でのポイント
--ssl-policyに指定する文字列によって、許可するTLSのバージョンや暗号スイートの組み合わせが決まります。- AWS公式ドキュメントにある「TLS セキュリティポリシー」の表を参考に、システムの要件（古いスマホやフィーチャーフォン、社内専用端末などの対応が必要か）とセキュリティのバランスを見て選びます。基本的には、特別なレガシー要件がない限り、AWSが提供する最新の推奨ポリシーを選んでおけば間違いありません。
—
5. まとめ
いかがでしたでしょうか？今回は、ALBにおけるTLSプロトコルバージョンと暗号スイートの選び方について、身近な例えを交えて解説しました。
- TLS 1.0 / 1.1 は完全にレガシー。 今すぐ無効化しましょう！
- TLS 1.2 は主力選手。 互換性のためにまだ必要です。
- TLS 1.3 は最新鋭。 速さと安全性のために積極的に採用していきましょう！
- 暗号スイートの呪文も、分解すれば役割が分かる。
ECDHEなどのモダンな仕組みを選びましょう。
セキュリティの設定は、一度正しく組んでしまえば裏側で黙々とユーザーの大切なデータを守ってくれる縁の下の力持ちです。クラウドの仕組みを一歩ずつ理解し、自信を持って安全でモダンなインフラを構築していきましょう！
それでは、また次回のインフラ探訪でお会いしましょう。良きクラウドライフを！
コメント