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

ロードバランサーのTLS終端：その「暗号設定」がサイバー攻撃の入り口になる理由

現場でインフラを預かるエンジニア諸君、ご苦労様。
今日はクラウドネイティブな環境における「ロードバランサー（ALB/NLB）のTLS終端」という、地味だが極めて重要な要塞化の話をする。

多くのエンジニアが「AWSやGCPがマネージドでやってくれているから大丈夫だろう」と高を括っているが、それが一番の盲点だ。デフォルト設定のまま運用していると、攻撃者は「プロトコルダウングレード攻撃」という古くて新しい手法で、君たちの堅牢なはずのシステムを覗き見ようとする。

1. なぜ「古い暗号スイート」が放置されているのか？

攻撃者が狙うのは、常に「最も弱い輪」だ。
例えば、TLS 1.0や1.1、あるいはCBCモードの暗号スイート（AES-CBCなど）を許可している環境。これは現代のセキュリティ基準では「鍵がかかっていない玄関」に等しい。

攻撃者は、わざわざ高度なハッキング手法を使わなくても、パケットをキャプチャし、弱い暗号化を強引に解読（POODLEやBEASTといった攻撃手法の亜種）することで、セッションハイジャックや機密情報の窃取を試みる。特に、レガシーなクライアントとの互換性を気にして設定を甘くしている現場は、格好の餌食だ。

我々の使命は、「捨てる勇気を持つこと」だ。古いブラウザやレガシーなデバイスが繋がらなくなることを恐れるな。脆弱な通信を許可して情報漏洩を起こすことの方が、ビジネス上のリスクは圧倒的に高い。

2. ALB/NLBで実装すべき「鉄壁のセキュリティポリシー」

AWSのALBを例に取ろう。コンソールでポチポチ設定するのもいいが、IaC（Terraformなど）で定義を固定化するのがプロの作法だ。

ここでは、AWSで最も推奨されるセキュアなセキュリティポリシー ELBSecurityPolicy-TLS13-1-2-2021-06 を適用する。これは、TLS 1.2と1.3のみを許可し、脆弱な暗号スイートを完全に排除した設定だ。

Terraformによる実装例

# セキュリティポリシーを強固に設定したALBリスナー定義
resource "aws_lb_listener" "front_end" {
  load_balancer_arn = aws_lb.main.arn
  port              = "443"
  protocol          = "HTTPS"
  
  # 最新のTLS 1.3/1.2のみを許可するポリシーを選択
  # TLS 1.0/1.1はここで完全に遮断される
  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
  certificate_arn   = aws_acm_certificate.cert.arn

  default_action {
    type = "fixed-response"
    fixed_response {
      content_type = "text/plain"
      message_body = "Forbidden"
      status_code  = "403"
    }
  }
}

この設定により、古い RC4 や 3DES といった脆弱な暗号化アルゴリズムは、ロードバランサーの入り口で即座に拒絶される。

3. アプリケーション層での防衛（HSTSの徹底）

ロードバランサーでTLSを強制しても、ブラウザが「HTTPでアクセスしたい」と意地を張る場合がある。これを防ぐのが Strict-Transport-Security (HSTS) ヘッダーだ。これがないと、中間者攻撃（MITM）によって通信をHTTPに落とさせられ、そのまま暗号化されていないデータを盗まれる。

Nginxやアプリケーション側で、以下のようなヘッダーを必ず付与せよ。

Nginxの設定例

server {
    listen 443 ssl;
    
    # HSTSヘッダーの付与
    # includeSubDomains: サブドメインにも強制
    # preload: ブラウザのプリロードリストに追加
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    
    # X-Frame-Optionsでクリックジャッキング対策
    add_header X-Frame-Options DENY always;
    
    # X-Content-Type-OptionsでMIMEタイプスニッフィング対策
    add_header X-Content-Type-Options nosniff always;
}

4. まとめ：明日からやるべきこと

私の経験上、セキュリティは「一度設定したら終わり」というものではない。以下の手順で定期的に監査を行ってほしい。

1. 棚卸し: 現在のロードバランサーに適用されているセキュリティポリシーを確認せよ。もし TLS1.0 や 1.1 が含まれていたら、今すぐ排除する計画を立てろ。
2. スキャン: nmap や testssl.sh を使って、外側から自分のサーバーがどのような暗号スイートを提示しているか確認せよ。

コマンド例: testssl.sh --severity HIGH your-domain.com

3. 自動化: IaC（Terraform/CloudFormation）のコードレビュー時に、セキュリティポリシーのバージョンが最新であることをチェックリストに加えよ。

セキュリティは、派手なハッキングを防ぐことではなく、「当たり前のことを、当たり前にやり続けること」だ。君たちの手で、強固なインフラを構築してほしい。応援している。