【入門編】 クラウドネイティブなロードバランサー(ALB/NLB)のTLS終端設定 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

皆さん、こんにちは！インフラやクラウドのセキュリティの世界へようこそ。
クラウドサービスを使ったシステム開発、毎日お疲れ様です！AWSのALB（Application Load Balancer）やNLBといったロードバランサーを触る機会も増えてきたのではないでしょうか。

さて、Webサイトを安全に公開するために欠かせない「HTTPS（SSL/TLS通信）」。今回は、その通信の入り口であるロードバランサーでの「TLS終端設定」について、新人エンジニアの皆さんにもすっきりと理解してもらえるよう、身近な防犯の例えを交えながら優しく紐解いていきたいと思います。

一歩ずつ、安全なインフラの作り方を学んでいきましょう！

—

1. ロードバランサーでの「TLS終端」って、例えるならどんなこと？

まずは、「TLS終端（SSLオフロードとも呼ばれます）」というちょっとカッコいい言葉の意味からですね。

難しく考えず、身近な「宅配ボックス付きのマンション」を想像してみてください。

  • 暗号化された通信（HTTPS）： 住人宛ての荷物が、誰にも中身を見られないように頑丈な「カギ付きのジュラルミンケース」に入れられて届く状態です。
  • ロードバランサー（ALB/NLB）： このマンションの「コンシェルジュ（管理人さん）」だと思ってください。

住民（バックエンドのWebサーバー）が一軒一軒、届いたジュラルミンケースのカギを全部自分で開けていたら、毎日の仕分け作業だけでヘトヘトになってしまいますよね。サーバーのCPUパワーもすごく消費してしまいます。

そこで、「入り口のコンシェルジュ（ロードバランサー）が住民の代わりにカギを開けて中身を確認し、マンションの中（内部ネットワーク）は安全な通路だから、普通のダンボール箱に移し替えて各部屋に届けよう！」 という仕組みが「TLS終端」です。

入り口でしっかりと不審な荷物がないかチェックしつつ、サーバーの負担を減らせる一石二鳥の仕組みなんですよ。

—

2. 攻撃者はどこを狙う？古いプロトコルと暗号スイートの危険性

では、この入り口のコンシェルジュ（ロードバランサー）の設定が甘いと、どうなるでしょうか？

ここで登場するのが、暗号化の「ルールブック」のお話です。通信の暗号化に使われるルールには、古いものから新しいものまで歴史があります。

  • 古いルール（TLS 1.0 や TLS 1.1）： 大昔の合鍵のようなもので、現代の強力なコンピューターを使えば、泥棒が簡単にカギをピッキングして中身を覗き見（盗聴）できてしまいます。
  • 新しいルール（TLS 1.2 や TLS 1.3）： 現代の最新かつ最強のセキュリティ金庫です。どれだけがんばっても、泥棒には絶対に開けられません。

もし、ロードバランサーの設定で「古いルール（TLS 1.0など）」のままでも受け入れるようにしていると、悪意ある攻撃者はその古い隙をついて通信を傍受し、パスワードや個人情報をこっそり盗み取ってしまいます。

だからこそ、「古い合鍵の通り道はシャットターを下ろして完全に入り口を塞ぎ、最新の強力な金庫のルール（暗号スイート）だけを受け付けるように設定する」 ことが、現代のインフラ要塞化において絶対に欠かせない作業になるんです。

—

3. 【実践】AWS ALBでの最新TLSポリシー設定を覗いてみよう

それでは、実際にクラウド（AWSのALB）を例に、安全な設定（セキュリティポリシー）がどうなっているかを見てみましょう。

AWSでは、ロードバランサーに適用するTLSのルールセットを「セキュリティポリシー（Security Policy）」という名前であらかじめ用意してくれています。

実務で新しいシステムを構築する際は、一番新しくて安全なポリシーを選ぶのが鉄則です。設定ファイルのサンプルやイメージを見てみましょう。

推奨される最新のセキュリティポリシー設定例

TerraformなどのInfrastructure as Code（IaC）ツールを使ってALBのリスナーを設定する場合、以下のように記述します。

# AWS ALBのHTTPSリスナー設定の例
resource "aws_lb_listener" "https" {
  load_balancer_arn = aws_lb.main.arn
  port              = 443
  protocol          = "HTTPS"
  
  # 最新かつ最も安全なセキュリティポリシーを指定する
  # (古いTLS 1.0やTLS 1.1を完全に排除し、TLS 1.2およびTLS 1.3のみを許可)
  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
  
  # あらかじめ取得しておいたSSL/TLS証明書のARNを指定
  certificate_arn   = aws_acm_certificate.example.arn

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.main.arn
  }
}

この ssl_policy = "ELBSecurityPolicy-TLS13-1-2-2021-06" という一行を指定するのがポイントです。この設定を入れるだけで、古くて危なっかしい暗号化の方式をすべて拒否し、安全なものだけを強制してくれます。

—

4. 防御の仕上げ：セキュリティヘッダーでブラウザ側も守る

ロードバランサーで通信の入り口をしっかりガードしたら、次は「ブラウザ（ユーザーが使っている画面）」側への配慮も行いましょう。

どれだけ入り口を厳重にしても、ユーザーのブラウザが「危ない偽物の道」に誘導されてしまっては意味がありません。そこで、ロードバランサーやWebサーバーから、ブラウザに対して「常に安全なHTTPS通信だけを使いなさい！」と命令する強力な看板（レスポンスヘッダー）を出す必要があります。

代表的なものが Strict-Transport-Security（通称 HSTS）というヘッダーです。

HSTSヘッダーの意味と設定

  • 何をしてくれるの？： ユーザーがうっかり「http://example.com」と古いアドレスでアクセスしようとした時、ブラウザが自動的に「いや、安全な https:// に書き換えてアクセスしなさい！」と強制してくれます。中間者攻撃という「通信をこっそりすり替える悪い泥棒」を防ぐ決定打になります。

もしアプリケーション側やロードバランサーのレスポンスヘッダー設定で付与する場合、以下のような形式で設定します。

# ブラウザに安全なHTTPS接続を強制するHSTSヘッダーの例
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  • max-age=63072000: 「これから2年間は、絶対に安全な通信以外は受け付けないでね」とブラウザに記憶させます。
  • includeSubDomains: メインのサイトだけでなく、そのサブドメイン（例：*.example.com）もすべて安全な通信を強制します。

—

まとめ：安全なインフラ作りは「入り口の施錠」から

今回は、ロードバランサーにおけるTLS終端設定と、古いプロトコルの無効化について解説しました。

1. ロードバランサーでのTLS終端は、マンションの優秀なコンシェルジュのように、安全な入り口で通信のチェックと復号を行い、サーバーの負担を減らす。
2. 古いプロトコル（TLS 1.0 / 1.1）はピッキングの危険があるため、最新のセキュリティポリシーを適用して完全にシャットアウトする。
3. HSTSなどのセキュリティヘッダーを活用して、ブラウザ側からも安全な通信を徹底させる。

セキュリティの対策と聞くと難しく身構えてしまうかもしれませんが、「家の頑丈な鍵を閉めるのと同じだな」とイメージできれば、やるべきことはぐっとシンプルに見えてきますよね。

皆さんが構築するクラウドインフラが、安全で信頼される素晴らしいものになるよう、ぜひ今日のポイントを日々の開発や運用に活かしてみてください。それでは、また次回のセキュリティ解説でお会いしましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました