mTLS

概要

mTLS（mutual TLS、相互 TLS）は、通信の両端 — サーバだけでなくクライアントも — が証明書を提示し合って互いの身元を確かめる TLS の使い方です。私たちが普段ブラウザで使う HTTPS では、証明書で名乗るのはサーバ側だけで、クライアント（ブラウザ）は匿名のまま接続します。mTLS はこれを対称にし、「接続してきた相手が本当に名乗り通りの相手か」を暗号学的に双方向で保証します。

登場する典型的な場面は、人間ではなく機械同士の通信です。マイクロサービス間の呼び出し、銀行 API のような高セキュリティな B2B 連携、IoT デバイスとサーバの接続など、「パスワードを入力する人間がいない」通信で、なりすましと盗聴を同時に防ぐ標準的な手段になっています。

なぜ生まれたか

TLS の仕様には最初からクライアント証明書の仕組みがありましたが、Web ではほとんど使われませんでした。一般ユーザーに証明書を配って管理させるのは非現実的で、クライアントの認証はパスワードやセッションで足りたからです。一方サーバ側では長らく、「境界の内側は信頼する」というモデルが支配的でした。ファイアウォールの内側に入ってしまえば、サービス同士は互いを疑わず平文で話す — 城壁と堀のモデルです。

このモデルは、攻撃者が一度内側に侵入すれば横方向に動き放題という弱点を抱えています。クラウド化とマイクロサービス化で「内側」の通信が爆発的に増え、その経路がデータセンターをまたぐようになると、境界防御だけでは守りきれなくなりました。そこで台頭したのが「ネットワークの場所を信頼の根拠にしない」ゼロトラストという考え方で、その実装手段として、すべてのサービス間通信を暗号化しつつ相手の身元も検証する mTLS が中核に据えられたのです。

詳細

ハンドシェイクの対比 — 追加されるのは「クライアントの名乗り」

mTLS は新しいプロトコルではなく、TLS ハンドシェイクのオプション部分を有効にしたものです。通常の TLS では、サーバが証明書を提示し、クライアントは公開鍵暗号の仕組みでその正当性を検証しますが、逆方向の検証はありません。mTLS では、サーバがハンドシェイク中に「あなたの証明書も見せてください」と要求し、クライアントは証明書の提示に加えて、対応する秘密鍵を持っている証拠（ハンドシェイクデータへの署名）を送ります。

検証の拠り所は双方とも同じで、証明書が信頼できる CA（認証局 — 証明書に署名して身元を保証する機関）から発行されているかを確かめます。公開 Web のサーバ証明書は世界共通の公開 CA が発行しますが、mTLS のクライアント証明書は通常、組織内に立てたプライベート CA が発行します。つまり「うちの CA が署名した証明書を持つ者だけが仲間」という、組織内の身分証システムを作る構図です。ハンドシェイクが成功した時点で、暗号化と双方向の認証が同時に成立しているのが mTLS の要点です。

サービスメッシュによる自動化

mTLS の理屈は単純ですが、全サービスに証明書の取得・検証・更新のコードを実装させるのは現実的ではありません。そこでマイクロサービスの世界では、サービスメッシュ（Istio や Linkerd など）がこの仕事を肩代わりします。各サービスの隣にサイドカーと呼ばれるプロキシを配置し、サービス間の通信をすべてこのプロキシ経由にすると、アプリケーションは平文で話しているつもりでも、プロキシ同士が自動で mTLS を張ってくれます。

証明書の発行も自動です。メッシュのコントロールプレーンが CA として働き、Kubernetes 上の各サービスに「あなたはこのサービスである」という短命の証明書を発行し続けます。これにより、mTLS は認証・暗号化にとどまらず、「注文サービスからの呼び出しだけを決済サービスに許す」といった、サービス単位の認可ポリシーの土台にもなります。ゼロトラストの文脈で mTLS が語られるのは、この「通信ごとに身元を検証し、身元に基づいて許可する」基盤になるからです。

運用の本丸は証明書のライフサイクル

mTLS 導入の難所は暗号技術ではなく運用です。証明書には有効期限があり、失効・更新・配布を回し続けなければなりません。期限切れ証明書による大規模障害は業界の定番事故で、「セキュリティ機構が自分たちのサービスを止める」という皮肉な形で現れます。また、漏えいした証明書を無効化する失効の仕組み（CRL や OCSP と呼ばれる失効確認の仕組み）は伝統的に運用が重く、現代の実践では「そもそも証明書の寿命を数時間〜数日と極端に短くし、失効を待たずに自然に死なせる」方向に進んでいます。短命証明書は自動更新が前提となるため、結局のところ mTLS の成否は「証明書の発行と更新をどれだけ人手から切り離せるか」で決まります。サービスメッシュや SPIFFE のようなワークロード識別の標準が重要視されるのは、まさにこの自動化のためです。

導入判断の目安として、社内サービス間・機械間の通信で相手の身元保証が必要なら mTLS は第一候補です。一方、不特定多数の人間が使う一般向け Web には向きません。その領域は今もサーバ認証のみの TLS + パスワードや OAuth などのアプリケーション層の認証が受け持っています。