ネットワークセキュリティ

TLS復号てぃーえるえすふくごう

TLS暗号化通信SSL検査中間者検査ファイアウォールプロキシ

TLS復号について教えて

簡単に言うとこんな感じ！

暗号化された通信（HTTPS）は「封筒に入った手紙」みたいなもの。TLS復号は、会社のセキュリティ機器がその封筒をいったん開けて中身を確認し、また封をして届ける仕組みだよ。「安全な通信の中にウイルスや情報漏えいが隠れていないか」チェックするために使われるんだ！

TLS復号とは

TLS復号（TLS Decryption）とは、TLS（Transport Layer Security）によって暗号化された通信を、中継点でいったん復号して内容を検査し、再度暗号化して宛先に転送する技術・仕組みのことです。「SSLインスペクション」「TLSインターセプト」「HTTPS検査」とも呼ばれます。

現代のウェブ通信の大半はTLSで暗号化されており、マルウェアの通信や機密情報の外部送信も「暗号化の陰」に隠れやすくなっています。ファイアウォールや次世代ファイアウォール（NGFW）、プロキシサーバーがTLS復号を行うことで、暗号化されたパケットの中身を確認し、脅威の検出や情報漏えい防止（DLP）を実現できます。

一方で、TLS復号はプライバシーや証明書信頼の問題、パフォーマンスへの影響も伴います。導入する際は技術的な正しさだけでなく、法的・倫理的な観点での社内ポリシー整備も不可欠です。

TLS復号の仕組みと構造

TLS復号は「中間者（Man-in-the-Middle）として意図的に割り込む」構造を持ちます。通常の通信と何が違うかを整理しましょう。

通常のTLS通信 vs TLS復号あり

項目	通常のTLS通信	TLS復号あり
クライアントの接続先	本物のサーバー	中継機器（プロキシ等）
サーバー証明書	本物のサーバー証明書	中継機器が発行した証明書
通信の暗号化	クライアント↔サーバー間で一貫	クライアント↔機器、機器↔サーバーで分割
中間での検査	不可能	可能（マルウェア検知、DLPなど）
パフォーマンス	高い	機器の処理能力に依存
プライバシーリスク	低い	通信内容が機器に見える

TLS復号の動作フロー

[クライアント]─────────────[中継機器]──────────────[Webサーバー]
      │                        │                        │
      │  ① TLS接続要求         │                        │
      │───────────────────────>│                        │
      │                        │  ② 本物サーバーへ接続  │
      │                        │───────────────────────>│
      │                        │  ③ サーバー証明書受信  │
      │                        │<───────────────────────│
      │  ④ 偽（代替）証明書発行│                        │
      │<───────────────────────│                        │
      │  ⑤ 暗号化通信（機器まで）                        │
      │───────────────────────>│                        │
      │                        │  ⑥ 復号して内容検査   │
      │                        │  ⑦ 再暗号化して転送   │
      │                        │───────────────────────>│

ポイント：証明書の「なりすまし」

中継機器は「自分が本物のサーバーであるかのように振る舞う証明書」をクライアントに送ります。クライアントがこれを信頼するためには、中継機器のルート証明書をクライアントのOSや端末に事前にインストールしておく必要があります。企業環境では、これをグループポリシー（GPO）などで一括配布するのが一般的です。

覚え方

「封筒を開けて、読んで、また封をして届ける宅配業者」

普通の暗号化通信は「鍵のかかった金庫で輸送」ですが、TLS復号は「配達業者が中身を確認できる特別な権限を持っている」イメージです。

歴史と背景

1990年代後半〜2000年代: SSLによるHTTPS通信が普及。当初は一部のECサイトや金融系のみ
2013年: スノーデン事件により、通信の盗聴・監視への関心が世界的に高まる
2015年頃〜: Googleが検索ランキングにHTTPS対応を加味。HTTPS化が急速に普及
2016〜2018年: 暗号化通信の比率が全ウェブトラフィックの50%を超え、「暗号化の中にマルウェアが潜む」問題が顕在化
2018年: TLS 1.3 が RFC 8446 として標準化。従来の検査手法の一部が困難になり、TLS復号の仕組みの見直しが必要に
2020年代: クラウド型セキュリティ（SASE、Secure Web Gateway）でのTLS復号が主流になりつつある。エンドポイントエージェントと組み合わせた可視化も普及

TLS復号が使われる主な用途・製品カテゴリ

主な用途

用途	概要
マルウェア通信の検知	C2サーバー（指令サーバー）への暗号化通信を検査・遮断
情報漏えい防止（DLP）	機密データの社外送信を暗号化通信の中から検知
フィッシング対策	暗号化されたフィッシングサイトへのアクセスを検査
コンプライアンス監査	規制対象の通信内容を記録・監査
帯域管理	大容量の暗号化ストリーミングを識別・制限

TLS復号の対応・非対応カテゴリ

企業ではすべての通信を復号するわけではなく、カテゴリで除外設定するのが一般的です。

TLS 1.3導入による影響

TLS 1.3（2018年標準化）では、セキュリティ強化のために鍵交換の仕組みが大幅に変わりました。これにより、パッシブ（受動的）な傍受による復号が原理的に不可能になり、TLS復号には必ずプロキシ型（能動的な中継）が必要です。また、暗号化されたSNI（ECH: Encrypted Client Hello） の普及により、どのサーバーに接続しているかすら見えなくなる方向に進んでいます。

規格・RFC番号	内容
RFC 8446	TLS 1.3 の標準仕様。前方秘匿性（PFS）の必須化などセキュリティ強化
RFC 5246	TLS 1.2 の標準仕様。多くのTLS復号製品が現在も対応
RFC 8744	TLSにおけるSNIの暗号化（ECH）に関する課題の整理
RFC 9001	QUIC プロトコルにおけるTLS使用。HTTP/3の基盤でありTLS復号が困難