mTLS(相互TLS認証) えむてぃーえるえす(そうごてぃーえるえすにんしょう)
簡単に言うとこんな感じ!
普通のHTTPS通信は「サーバーが本物か」をブラウザが確認するだけだけど、mTLSは「お前は誰だ?」ってサーバー側もクライアントを証明書で確認するんだ。いわば「お互いに社員証を見せ合う」双方向の本人確認だよ!
mTLS(相互TLS認証)とは
mTLS(Mutual TLS) とは、TLS(Transport Layer Security)による暗号化通信において、サーバーとクライアントの 両方が証明書を提示し合い、互いに相手の正当性を検証する 認証方式のことです。「相互TLS認証」や「クライアント認証つきTLS」とも呼ばれます。
通常のTLS通信(一般的なHTTPS)は「サーバー認証」のみで、ブラウザがサーバーの証明書を確認してサーバーを信頼します。しかし mTLS では クライアント側も証明書を持ち、サーバーに提示することで自分の身元を証明 します。これにより「なりすまし」や「不正なクライアントからのアクセス」を防ぐことができます。
マイクロサービスやゼロトラストネットワーク、API間通信など、「どちらの通信相手も信頼を事前に確認したい」シーンで急速に普及しており、ゼロトラストセキュリティの核心技術 のひとつとして重要視されています。
mTLSのハンドシェイク(通信確立の仕組み)
通常のTLSとmTLSでは、接続確立(ハンドシェイク)の手順に大きな違いがあります。
| ステップ | 通常TLS(サーバー認証のみ) | mTLS(相互認証) |
|---|---|---|
| ① | クライアントが接続要求 | クライアントが接続要求 |
| ② | サーバーが サーバー証明書 を送る | サーバーが サーバー証明書 を送り、クライアント証明書の要求 も行う |
| ③ | クライアントがサーバー証明書を検証 | クライアントがサーバー証明書を検証し、自身のクライアント証明書 を送る |
| ④ | 暗号化通信スタート | サーバーがクライアント証明書を検証し、通過すれば暗号化通信スタート |
覚え方:「mは『Mutual(お互い)』のm」
mTLSの「m」は Mutual(ミューチュアル=お互いの) の頭文字です。「m=みんなで(お互いに)証明書を見せ合う」と覚えるとバッチリです。
クライアント証明書とは
mTLSで使う クライアント証明書 は、PKI(公開鍵基盤)に基づいたデジタル証明書で、サーバー証明書と同じ仕組みで発行されます。
| 項目 | サーバー証明書 | クライアント証明書 |
|---|---|---|
| 誰が持つか | サーバー | クライアント(端末・サービス) |
| 何を証明するか | このサーバーは本物 | このクライアントは正規のもの |
| 発行者 | CA(認証局) | CA または 内部CA |
| 使われる場面 | 全てのHTTPS | mTLS、VPN、社内システム |
歴史と背景
- 1990年代 — SSL/TLSの仕様策定時から「クライアント認証」の仕組み自体は存在していたが、構成の複雑さから普及は限定的だった
- 2000年代 — 企業VPNや金融機関のシステム間通信など、特定の高セキュリティ領域での利用が中心
- 2010年代前半 — スマートフォンや社員端末の管理(MDM)でクライアント証明書が使われ始める
- 2016年頃〜 — マイクロサービスアーキテクチャ の普及とともに、サービス間の通信認証としてmTLSが注目される
- 2018年〜 — ゼロトラストネットワーク の概念が広まり、「すべての通信を検証する」思想の実装手段としてmTLSが急速に普及
- 2020年代 — Istio・Envoy・Linkerdなどの サービスメッシュ がmTLSを自動管理する機能を提供し、クラウドネイティブ環境での標準的な通信セキュリティ手段となる
通常TLS vs mTLS:使い分けの整理
どちらを使うべきか迷ったときの判断基準を整理します。
| 観点 | 通常TLS | mTLS |
|---|---|---|
| 認証の向き | サーバー → クライアント(一方向) | 双方向(相互) |
| クライアント証明書 | 不要 | 必要 |
| 主な用途 | Webサイト閲覧、一般API | サービス間通信、ゼロトラスト、IoT |
| 管理の複雑さ | 低い | 高い(証明書の発行・更新・失効管理が必要) |
| なりすまし耐性 | クライアント側は担保しない | 双方向で担保 |
| 向いているシーン | 一般ユーザー向けサービス | 内部マイクロサービス、BtoB API |
mTLSが活躍する具体的なシーン
【シーン1: マイクロサービス間通信】
注文サービス ──(mTLS)──▶ 在庫サービス
→ 「お前は本当に注文サービスか?」を証明書で確認
【シーン2: ゼロトラストVPN代替】
社員PC ──(mTLS)──▶ 社内アプリ
→ パスワードだけでなく端末証明書でも認証
【シーン3: IoTデバイス管理】
センサーデバイス ──(mTLS)──▶ クラウドAPI
→ デバイス固有の証明書でなりすましを防止
mTLSの落とし穴:証明書管理の負荷
mTLSの最大の課題は 証明書ライフサイクルの管理 です。
| 課題 | 内容 |
|---|---|
| 証明書の発行 | クライアントごとに証明書を発行する仕組みが必要 |
| 有効期限管理 | 期限切れになると通信が突然できなくなる |
| 失効処理 | 不要になったクライアントの証明書を無効化する運用 |
| 自動化 | 規模が大きくなると手動管理は現実的でない |
→ これらを解決するため、サービスメッシュ(Istio など)や SPIFFE/SPIRE のような証明書自動管理ツールが使われます。
関連する規格・RFC
| 規格・RFC番号 | 内容 |
|---|---|
| RFC 8446 | TLS 1.3の仕様。mTLSの基盤となるプロトコル定義 |
| RFC 5246 | TLS 1.2の仕様。クライアント認証(CertificateRequest)の仕組みを定義 |
| RFC 5280 | X.509証明書とCRL(証明書失効リスト)の形式仕様 |
| RFC 8705 | OAuth 2.0におけるmTLSを使ったクライアント認証の仕様 |
関連用語
- TLS — mTLSの基盤となる暗号化通信プロトコル
- PKI(公開鍵基盤) — クライアント証明書・サーバー証明書を発行・管理する仕組み
- X.509証明書 — mTLSで使われるデジタル証明書の標準フォーマット
- ゼロトラストネットワーク — 「すべての通信を検証する」セキュリティモデル。mTLSはその実装手段
- サービスメッシュ — マイクロサービス間のmTLSを自動管理するインフラ層
- CA(認証局) — クライアント証明書・サーバー証明書を発行する信頼の起点
- OAuth 2.0 — mTLSと組み合わせてAPIアクセス認証を強化するプロトコル
- マイクロサービス — mTLSが特に必要とされるサービス分割アーキテクチャ