MENU

SSLインスペクション(TLSインスペクション)とは?仕組み・企業での活用・プライバシー配慮をわかりやすく解説

暗号化通信が当たり前になった今、「社内のHTTPS通信を監視したいが、中身が見えない」という悩みを持つ情シス担当者は少なくありません。実は攻撃者もそれを知っていて、マルウェアのC2(コマンド&コントロール)通信やデータ窃取をHTTPS経由で隠ぺいするケースが増えています。

この記事では、SSLインスペクション(TLSインスペクション)の仕組み・企業での活用法・導入時の注意点を、現場で使えるレベルで解説します。「暗号化=安全」という思い込みが生む盲点をどう克服するか、一緒に考えていきましょう。

目次

SSLインスペクションとは?

SSLインスペクション(SSL/TLS Inspection)とは、ファイアウォールや次世代UTM(統合脅威管理装置)がHTTPS通信を一時的に復号し、内容を検査したうえで再暗号化して転送する技術です。

「SSL」という名称が定着していますが、現在の標準はTLS 1.2/TLS 1.3です。製品によってはSSLインスペクション・TLSインスペクション・Deep Packet Inspection(DPI)など呼び名が異なりますが、基本的な仕組みは同じです。

なぜ必要かというと、2024年現在、インターネットトラフィックの90%以上がHTTPS化されています。このため、従来のファイアウォールではマルウェアの通信・機密データの流出・フィッシングサイトへの接続を「暗号化されているから見えない」状態で素通りさせてしまう問題が生じます。

攻撃者はHTTPS通信をどう悪用するか(敵を知る)

防御の前に、攻撃者の視点を理解することが重要です。

1. マルウェアのC2通信

感染端末が攻撃者のC2サーバーと通信する際、HTTPS経由で行うケースが増えています。企業のファイアウォールは一般的にHTTPS(443番ポート)の通信を許可しているため、検知を回避しやすいのです。

特にEmotet・Cobalt Strike・QakBotといったマルウェアは、正規サービスのドメインやHTTPS通信を偽装してC2トラフィックを隠蔽する手法が確認されています。

2. 機密データの持ち出し

悪意のある内部者(または感染端末経由)が、機密ファイルをHTTPS経由でクラウドストレージや外部サービスにアップロードするケースがあります。DLP(データ損失防止)ツールを導入していても、HTTPS通信の中身が見えなければ検知できません。

3. フィッシングサイトのHTTPS化

「HTTPSなら安全」という誤解を悪用し、フィッシングサイト自体がHTTPS証明書を取得するケースが急増しています。ユーザーがURLバーの鍵マークを見て安心してしまうため、SSLインスペクションで接続先の実態を確認することが有効です。

SSLインスペクションの仕組み

SSLインスペクションは、技術的には「管理された中間者(Man-in-the-Middle)」の仕組みです。

1. 通信フローの概要

# 通常のHTTPS通信(インスペクションなし) クライアント ─(暗号化)─ Internet ─(暗号化)─ Webサーバー # SSLインスペクションあり クライアント ─(暗号化A)─ UTM/Firewall ─(暗号化B)─ Webサーバー ↑ ここで復号・検査・再暗号化

2. 証明書の仕組み

SSLインスペクションを実現するために、ファイアウォールは「中間CA証明書」を持ちます。この証明書を社内PCにあらかじめインストールしておくことで、クライアントはファイアウォールが生成した証明書を「信頼できる証明書」として受け入れます。

中間CA証明書: ファイアウォールが発行する自己署名証明書。社内PC全台にグループポリシー(GPO)等で配布する必要がある
セッション分割: ファイアウォールはクライアントとの間(セッションA)と、実サーバーとの間(セッションB)を別々のTLSセッションとして管理する
検査内容: マルウェアスキャン、URLフィルタリング、DLPポリシーのチェック、アプリケーション識別

3. TLS 1.3での変化点

TLS 1.3ではForward Secrecy(前方秘匿性)が強化されており、一部のインスペクション手法が制限されています。最新のUTM製品はTLS 1.3インスペクションに対応していますが、製品の対応状況を必ず確認しましょう。

具体的な導入手順

1. 対象トラフィックの選定

すべてのHTTPS通信をインスペクション対象にするのは避け、まずリスクの高い通信から絞り込みます。

インスペクション推奨: 未分類のWebサイト、新規ドメイン(登録後30日以内)、ファイル転送サービス、SNS、フリーメール
インスペクション除外推奨: 銀行・金融機関、医療機関、VPNサービス、プライバシーポリシー上の制約があるサービス(後述)

トラフィック種別 インスペクション推奨度 理由
未分類サイト・新規ドメイン 高(優先対象) マルウェアC2・フィッシングの隠れ蓑になりやすい
クラウドストレージ(個人向け) データ流出経路として悪用されやすい
金融機関・証券会社 低(除外推奨) 規制上の制約・EV証明書の検証が崩れる
社内SaaSツール(Salesforce等) 要検討 ライセンス条項で検査を禁止している場合がある

2. 中間CA証明書の展開

社内PC・スマートフォンにファイアウォールの中間CA証明書を配布します。未配布のデバイスはSSLインスペクション通過時に「証明書エラー」が出てしまいます。

# Windowsグループポリシーで中間CA証明書を展開する手順(概要) # 1. ファイアウォールからCA証明書(.cer)をエクスポート # 2. GPO: コンピューターの構成 > Windowsの設定 > セキュリティの設定 > 公開キーのポリシー # 3. 「信頼されたルート証明機関」にCA証明書をインポート # 4. ドメイン参加PCへポリシー適用(gpupdate /force) # Linuxの場合(Ubuntu/Debian) sudo cp firewall-ca.crt /usr/local/share/ca-certificates/ sudo update-ca-certificates # Linuxの場合(RHEL/CentOS/Rocky) sudo cp firewall-ca.crt /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust

3. 除外リストの設定

プライバシーや技術的な理由でインスペクションを行うべきでない通信は「バイパスリスト(除外リスト)」に登録します。

法的・プライバシー上の除外: 銀行・証券・医療系サービス(患者情報・口座情報を傍受するリスク)
技術的な除外: 証明書ピンニング(Certificate Pinning)を行うアプリ(一部のモバイルアプリ・Windowsアップデート)
SLAや利用規約上の除外: クラウドSaaSが利用規約でインスペクションを禁止している場合

中小企業でも今日からできること

「専用のUTMを持っていない」という企業でも、段階的に取り組める対策があります。

ステップ1: 可視化から始める: まずは無料のDNSフィルタリング(Cloudflare Gateway・OpenDNSなど)を導入し、悪意のあるドメインへの接続を遮断する
ステップ2: 中小企業向けUTMの検討: FortiGate・SonicWall・Cisco Meraki MXなどは中小企業向けライセンスがあり、SSLインスペクションも対応している
ステップ3: 証明書配布の準備: Active Directory環境があればGPOで証明書配布が容易。AD未導入の場合はintune(Microsoft Endpoint Manager)やJamf等のMDMが有効
ステップ4: 段階的にカバレッジを拡大: いきなり全通信をインスペクションしようとすると業務影響が出やすい。まず「未分類サイト」「新規ドメイン」だけを対象にして、問題がなければ拡大する

クラウドセキュリティとの連携については、姉妹サイトクラウドマスターズ.TOKYOでクラウドネットワーク設計の基礎も解説しています。

よくある誤解と注意点

【誤解1】SSLインスペクションを入れれば万全

SSLインスペクションはあくまで「見えない通信を見えるようにする」ための手段です。検査エンジン(マルウェアスキャン・URLフィルタ)が最新のシグネチャで稼働していなければ、復号しても検知できません。ツールの定期更新と組み合わせることが必須です。

【誤解2】証明書ピンニングアプリはすべて除外すべき

証明書ピンニングを行うアプリがSSLインスペクションの対象になると、アプリが「不正な証明書だ」と判断して接続を拒否します。ただし「除外すべきかどうか」はアプリとビジネスリスクに応じて判断が必要です。無条件に全部除外すると監視の抜け穴が増えます。

【注意】従業員への説明義務

SSLインスペクションは、従業員のHTTPS通信を企業側が復号・閲覧できることを意味します。プライバシーポリシーや就業規則に「業務端末のネットワーク通信は会社が監視する場合がある」旨を明記し、従業員に周知することが法的・倫理的に重要です。「知らないうちに監視されていた」という信頼失墜を防ぐためでもあります。

【注意】TLS 1.3のOCSP Staplingとの相性

TLS 1.3ではOCSP Stapling(証明書失効確認の効率化機能)が一般化しています。一部の実装でSSLインスペクションがこれを適切に処理できない場合があります。UTMのリリースノートを確認し、TLS 1.3の対応状況を把握した上で導入しましょう。

本記事のまとめ

ポイント 内容
SSLインスペクションとは HTTPS通信を復号・検査・再暗号化する技術。UTM/次世代ファイアウォールに内蔵
必要な理由 マルウェアC2・データ窃取・フィッシングがHTTPS通信を悪用するため
導入のポイント 中間CA証明書の全端末配布、除外リストの設計、従業員への周知が必須
中小企業の現実解 まずDNSフィルタリングから着手し、UTM導入時にSSLインスペクションを有効化
注意点 証明書ピンニングアプリの除外設計、TLS 1.3対応確認、プライバシーポリシーの整備

暗号化通信が増えるほど「見えないから安全」という錯覚が生まれやすくなります。SSLインスペクションは、その錯覚を正す有効な手段のひとつです。導入ハードルは高く見えますが、段階的なアプローチで着実に進めることができます。

社内のHTTPS通信、本当に「見えて」いますか?

暗号化通信の盲点を放置したまま「うちは大丈夫」と思っていませんか?
正しいセキュリティ知識を体系的に身につけたい方へ、メルマガで実践的なセキュリティ対策ノウハウをお届けしています。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次