TLS終端の位置設計 — 手前で解くか背後まで暗号のまま通すか

TLS終端をどこに置くかという判断は、「外部との通信を暗号化している」という事実だけを確認して終わりにしてはならない。ロードバランサや前段プロキシで一度解いた後、その通信がどこを通るかを設計に組み込まなければ、外向きの暗号化が整備された裏で内部は平文が流れ続ける構造が生まれる。本記事では、終端位置の選択肢を比較しながら、どの区間を暗号化し、どこを許容するかという線引きの判断軸と、証明書管理・mTLS・可観測性とのトレードオフを整理する。

前段で解いた後の内部通信が平文のまま放置される構造

ロードバランサが終端した後の実態

クライアントからの通信をロードバランサのHTTPS終端で受け取り、バックエンドへはHTTPで転送する構成は、Webシステムの世界で長く使われてきた。ロードバランサ側でTLSを処理するため、バックエンドのアプリケーションサーバーはTLSライブラリを持たなくてよく、証明書管理の対象を一点に絞り込める。設計としての合理性はある。しかし問題は、ロードバランサとバックエンドの間を流れる通信が、インフラ上の同じネットワークセグメントを経由するという事実だ。10台規模のアプリサーバー群が同一VPCやデータセンターセグメント内に置かれている場合でも、その内部ネットワークへのアクセスが完全に統制されているとは限らない。アクセス制御と通信内容の暗号化は別の問題であり、混同してはならない。

平文通信が許容されてきた背景

内部通信を平文のまま通すことが長らく受け入れられてきた理由は、ネットワーク境界防御モデルへの信頼にある。「外部から入れなければ内部は安全」という前提のもと、ファイアウォールやVLANで区切りさえすれば内部通信の暗号化は過剰という判断が多くの現場で採用された。2010年代前半までは、社内ネットワークや閉域クラウドでの平文内部通信はほぼ標準的な構成だった。しかしゼロトラスト概念の台頭と、クラウド環境での多テナント共有インフラの普及により、「内部にいれば信頼できる」という前提が崩れ始めた。侵害後の水平移動（ラテラルムーブメント）を防ぐ設計として、内部通信の暗号化が改めて問われるようになっている。

この構造が問題になる典型的な場面

構築を任されたある担当者が、クラウド上に20台以上のコンテナノードを持つマイクロサービス基盤を整備した際、外部向けTLSはAPI Gatewayで終端していた。しかし内部のサービス間通信は平文HTTPで設計されており、コンテナランタイムのログに平文の認証トークンがそのまま記録されていた。これはネットワーク盗聴の問題として顕在化したのではなく、ログ収集基盤や監視ツールへの不要な情報露出という形で問題となった。設計の不備がセキュリティ問題として現れる経路は外部攻撃だけではなく、内部の観測基盤のアクセス制御と通信の暗号化範囲は整合して設計しなければならない。

内部も暗号化すべき区間と平文で許容する区間の判断

暗号化が必要な区間を決める基準

「全区間を暗号化する」という方針自体は正しい方向性だが、運用コストを無視した実装は持続しない。どの区間を優先して暗号化するかの判断基準として、まず「認証情報・個人情報・機密データが流れるか」を問う。APIのレスポンスにJWTや氏名・住所が含まれるサービス間通信は、内部であっても暗号化の対象とすべき区間だ。次に「通信路が物理的・論理的に隔離されているか」を確認する。同一ホスト上のプロセス間通信と、異なるホスト間を跨ぐ通信ではリスクプロファイルが大きく異なる。さらに「監査・コンプライアンス要件が通信内容の記録を求めているか」も判断に加える。PCIDSS対象のカード情報が流れる区間は、規格上も暗号化が必須となる。

平文が許容される条件と前提

一方で平文通信を許容できる場面も存在する。同一物理ホスト上に閉じたプロセス間通信、あるいは暗号化されたオーバーレイネットワーク（WireGuardやIPsecのトンネルで全通信を包んでいる場合）の内部では、上位層のTLSを重ねる設計は二重の処理コストになりうる。ただしこの許容にも前提条件がある。オーバーレイネットワークの鍵管理が適切に行われており、ネットワーク層の暗号化が実際に全経路に適用されていることを確認できることが必須だ。「VPCだから安全」という理由だけで平文を許容するのは根拠が薄い。VPCやプライベートネットワークはアクセス制御であり、通信内容の暗号化ではないという区別を設計判断の前提として押さえておく。

境界の引き方と運用コスト

現実の設計では「外部向けは暗号化、内部は許容」という二値ではなく、信頼境界ごとに区間を整理することが有効だ。外部クライアント→ロードバランサ、ロードバランサ→リバースプロキシ、リバースプロキシ→アプリサーバー、アプリサーバー→データベースという経路を一本の線として見たとき、どのセグメント間がどのような信頼境界を跨いでいるかを明確にする。信頼境界を跨ぐ区間には暗号化を適用し、同一信頼ドメイン内の区間は証明書管理コストと照らし合わせて判断する。この整理なしに「全部やる」か「全部省く」かの二択に落としてしまうと、運用フェーズで設計の意図が引き継げなくなる。

ロードバランサ終端・リバースプロキシ終端・アプリまでパススルーの比較

各方式の特性と選択基準

TLS終端の位置として代表的な3つの方式を整理する。それぞれに向いているユースケースとトレードオフがあり、どれが正解かは構成の規模・セキュリティ要件・運用体制によって変わる。

方式	TLS処理の位置	LBより後の内部通信	証明書管理の集約度	向いているケース	主なトレードオフ
ロードバランサ終端	LB（最前段）	平文（HTTP）	高い（1〜2箇所）	管理コストを最小化したい小〜中規模構成	内部通信が平文になる。LBより後段での盗聴・露出リスクが残る
リバースプロキシ終端	Nginx / Envoy等（中間層）	プロキシ〜アプリ間は選択可	中程度（プロキシ層に集約）	マイクロサービス・サービスメッシュ構成	プロキシ自体の管理が加わる。サイドカー化が必要な場合あり
アプリまでパススルー（TLSパススルー）	アプリサーバー	暗号化されたまま通過	低い（アプリ層ごとに分散）	L7ロードバランシング不要・エンドツーエンド暗号化が必須の構成	LBでのHTTPヘッダ操作不可。証明書管理がアプリ側に分散する

ハイブリッド構成という選択肢

実際の本番環境では、単一の方式だけで完結しないケースが多い。外部向けにはロードバランサで終端しつつ、サービスメッシュ（IstioやLinkerdのサイドカープロキシ）によってサービス間通信を別途暗号化する構成は、マイクロサービス規模が30サービスを超えてくると検討される。この場合、証明書の発行体（CA）をLB用のパブリック証明書と、内部mTLS用のプライベートCAに分けて管理することになる。2つの証明書体系を並走させる運用コストは小さくなく、この設計を採用するかどうか自体がひとつの判断点となる。選択の基準は「セキュリティ要件が内部通信の相互認証を求めているか」と「証明書管理を継続的に回せる運用体制があるか」の2点だ。

証明書の配置と更新をどの層で回すか

証明書を置く層と管理の集約

TLS終端の位置を決めたら、次に問われるのは証明書をどこに置き、どのサイクルで更新するかだ。ロードバランサ終端であれば、クラウドプロバイダのマネージド証明書（AWS ACMやGCPのマネージドSSLなど）を使うことで更新の自動化がしやすい。しかし自前のリバースプロキシが終端を担う場合は、Let’s EncryptのCertbotやacme.shを使った更新設計が必要になる。更新処理は単にスケジューラで起動すればよいというものではなく、更新の成否通知・証明書の有効期限監視・プロキシのgraceful reloadをセットで設計しなければ、本番で証明書切れが発生したときの検知が遅れる。これを「スクリプトがあるから大丈夫」と思い込んで放置している現場は少なくない。

自動更新設計で見落とされる確認手段

Let’s Encryptの証明書有効期限は90日であり、更新スクリプトを30日前に起動するよう設定しても、スクリプトの失敗が2回続けば期限切れになる計算だ。現場では、更新処理自体は成功しているのにプロキシのリロードが走らず古い証明書のまま運用が続いていた、という話をよく聞く。自動更新の設計において確認すべきは「証明書ファイルが更新されたか」ではなく「サーバーが新しい証明書を実際に提供しているか」という外形監視の有無だ。監視の対象は証明書のフィンガープリントと有効期限の両方を含めるべきで、これを整備していない場合の復旧工数は3〜5時間規模になることがある。

内部証明書（プライベートCA）のライフサイクル

内部通信の暗号化にプライベートCAを立てる場合は、ルート証明書の配布とローテーションが別途設計の対象になる。VaultやCert-Managerのようなツールを使ってプライベートCAを運用するとき、ルートCAの有効期限が10年に設定されていることが多く、担当者が変わった後に更新が忘れられるリスクがある。内部証明書の管理設計は、発行・更新・失効・ルートCA更新という4つのライフサイクルを文書化し、Infrastructure as Codeに組み込む形で引き継ぎ可能な状態にしておくことが望ましい。証明書管理は構築時点の設計だけでなく、5年・10年先の引き継ぎを見据えた設計として考える必要がある。

相互TLS（クライアント認証）をどこまで広げるかの決め方

mTLSを導入する判断基準

相互TLS（mTLS）は、サーバーだけでなくクライアント側も証明書を提示してお互いを認証する仕組みだ。サービス間通信にmTLSを使えば、「VPC内にいるから信頼する」という境界防御依存から脱し、通信の相手方を証明書レベルで識別できる。ゼロトラストアーキテクチャにおける内部通信制御として有効な手段だが、全サービス間に一律に展開するかどうかは慎重に判断する必要がある。証明書の発行・失効・ローテーションがサービスの数だけ必要になり、50サービス規模のマイクロサービス基盤では証明書の管理オーバーヘッドが無視できない水準になる。

適用範囲の段階的な拡張と運用体制の整合

mTLSの適用を段階的に広げる場合、「外部公開APIとバックエンド間」「決済・認証サービスへの内部呼び出し」など、機密性の高い通信路から始めることが現実的な進め方だ。サービスメッシュを使っている環境では、サイドカープロキシがmTLSを肩代わりするためアプリコードの変更なしに適用範囲を広げられる。一方、サービスメッシュを持たない環境でmTLSを個別に実装する場合は、各サービスのTLS設定と証明書配布の仕組みをゼロから整備しなければならず導入工数が大きい。どこまでやるかの判断は、「リスクの高い通信路はどこか」と「運用体制が証明書管理を継続的に回せるか」の2点を軸に置くとよい。運用体制が追いつかない範囲に適用しても、失効対応が遅れて結果的にセキュリティ水準が下がる。

全区間暗号化にして通信の調査ができなくなる境界

パケットキャプチャ・デバッグへの影響

内部通信を全区間TLSで暗号化する設計は、セキュリティ観点では望ましいが、障害発生時の調査手段を制約するという側面も持つ。平文のHTTP通信であれば、パケットキャプチャツールで通信内容を直接確認できた。しかしTLSで暗号化された状態では、キャプチャしてもペイロードは読めない。特に本番環境でのデバッグが求められる場面——サービス間のAPIコールが断続的に失敗するが、アプリログには原因が出ていないといった状況——では、通信内容を直接確認できないことが調査時間を大幅に伸ばす要因になる。暗号化の範囲を広げる前に、代替の調査手段を設計に含めておくことが必要だ。

可観測性を確保する設計の組み込み方

全区間暗号化とデバッグ可能性を両立させるには、可観測性の設計を暗号化と同時に、あるいは先に整えておく必要がある。分散トレーシング（OpenTelemetryなど）によるサービス間リクエストの追跡、アプリケーション層でのリクエスト・レスポンスのログ記録（センシティブフィールドをマスクした上で）、そしてサービスメッシュが持つメトリクス（レイテンシ・エラーレート・接続数）の収集が主要な手段となる。ログとトレースが適切に実装されていれば、パケットキャプチャに頼らなくても原因の絞り込みが可能だ。逆に言えば、可観測性の設計が不十分なまま全区間暗号化を実装すると、デバッグ手段を失った状態で本番を運用することになる。この境界は設計段階で必ず確認しておきたい。

TLS終端設計チェックリスト

以下のチェックリストを設計レビューの際に活用することで、終端位置の決定から証明書管理・可観測性の確保まで、見落としを減らすことができる。

• 終端位置の明示: TLSをロードバランサ・リバースプロキシ・アプリのどこで終端させるかを明示し、その判断理由が設計書に記録されているか。
• 内部通信の暗号化範囲の定義: 信頼境界ごとに「暗号化する区間」と「許容する区間」を区別しており、その根拠（同一ホスト・オーバーレイ暗号化・コンプライアンス要件）が整理されているか。
• 証明書の有効期限監視: パブリック証明書・内部プライベートCA証明書それぞれの有効期限が、外形監視の対象として設定されているか。
• 自動更新の動作確認手段: 更新スクリプトの成否通知に加え、サーバーが実際に新しい証明書を提供しているかを確認する外形監視が存在するか。
• プライベートCAのライフサイクル文書化: ルートCAを含む内部証明書の発行・更新・失効・ルートCA更新の4フェーズが、IaCまたは設計文書として引き継ぎ可能な状態になっているか。
• mTLSの適用範囲と優先順位: クライアント証明書認証を適用すべき通信路が優先順位付きで明確になっており、証明書ローテーションの運用設計があるか。
• 可観測性の確保: 分散トレーシングまたはアプリケーションログにより、TLS暗号化後もリクエストの追跡が可能な状態か。センシティブフィールドのマスク設計も含めて整備されているか。
• デバッグ手段の代替定義: パケットキャプチャが使えない前提で、本番障害時の調査フローが定義されているか。
• 複数CA体系の整合性: パブリック・プライベートの複数CAを併用する場合、それぞれの対象範囲が重複なく定義されているか。
• 設計意図の引き継ぎ可能性: 証明書管理と終端設計の意図がIaCまたは設計文書として残っており、担当者交代後も運用継続できる状態か。