mTLS と相互認証・サービスメッシュの信頼基盤

mTLS が解く問題：ネットワーク位置を信用しない

通常の TLS は片側認証です。クライアントはサーバー証明書を検証して相手を確かめますが、サーバーから見たクライアントは匿名で、本人確認はアプリ層のトークンやパスワードに委ねられます。社内ネットワークという「内側だから安全」という前提が崩れた今、この非対称性が問題になります。同一クラスタ内で動くサービス同士は、ネットワーク位置だけを根拠に相互を信頼してしまいがちだからです。

**mTLS（mutual TLS）**は、この前提を捨てます。通信する両者がそれぞれ証明書を提示し、相手の秘密鍵所有を相互に検証する。ネットワークのどこにいるかではなく、どの鍵を持つかで身元を判定する点が本質で、これがゼロトラストの通信基盤になります。

ハンドシェイクの非対称：片側認証との違い

mTLS が普通の TLS と異なるのは、ハンドシェイク中の数メッセージだけです。サーバーが自分の証明書を送った後、続けて CertificateRequest をクライアントへ送る。これが「あなたの証明書も見せてください」という要求の合図です。

TLS 1.3 の mTLS ハンドシェイク（要点のみ）

Client → Server: ClientHello
Server → Client: ServerHello, EncryptedExtensions,
                 CertificateRequest,     ← クライアント証明書を要求
                 Certificate(サーバー証明書),
                 CertificateVerify,      ← サーバー秘密鍵での署名
                 Finished
Client → Server: Certificate(クライアント証明書),
                 CertificateVerify,      ← クライアント秘密鍵での署名
                 Finished

鍵となるのは CertificateVerify です。証明書を提示するだけなら、公開されている他人の証明書をコピーして名乗れてしまう。CertificateVerify は、これまでのハンドシェイクのトランスクリプト（やり取りのハッシュ）に対し、証明書の公開鍵に対応する秘密鍵で署名したものです。検証側は証明書内の公開鍵で署名を確かめるため、秘密鍵を実際に握っている当事者しか正しい署名を作れません。これにより「証明書を持っている」のではなく「証明書に対応する秘密鍵を所有している」ことが証明されます。

SPIFFE：ID を URI として表す

mTLS を実運用するうえでの難所は、証明書をどう発行・配布・更新するかです。ここで標準として広まったのが SPIFFE（Secure Production Identity Framework For Everyone） です。SPIFFE はワークロードの身元を、人間の名前ではなく SPIFFE ID という URI で表します。

spiffe://example.org/ns/payment/sa/checkout
        └─ trust domain ─┘└──── path ────┘

trust domain（信頼ドメイン）は1つの CA が支配する信頼境界、path はその中での個別ワークロードを表す論理名です。この ID を運ぶ実体が SVID（SPIFFE Verifiable Identity Document） で、最も一般的な形式は X.509 証明書です。証明書の SAN（Subject Alternative Name）の URI フィールドに spiffe://... を埋め込み、これを mTLS の証明書としてそのまま使います。

ポイントは、検証側が証明書チェーンの正当性を確かめたうえで、SAN に入った SPIFFE ID で認可を判断できることです。「正しい CA が発行した、payment/checkout という ID の証明書」という事実だけで、IP やホスト名に依存せず相手を識別できます。

SPIRE：短命 ID をどう自動発行するか

SPIFFE は仕様で、その代表的な実装が SPIRE（SPIFFE Runtime Environment） です。SPIRE の核心は、証明書を分単位の短命にして自動で配り替える点にあります。長命の証明書を配ると、漏洩時の被害が長期化し、鍵管理ライフサイクルでいう失効（CRL/OCSP）への依存が増えます。SVID を例えば1時間で失効させれば、漏れても短時間で無効化され、失効リストへの依存自体を薄められます。

SPIRE が証明書を渡す前に解く問題は「目の前のワークロードは本当に名乗りどおりの相手か」という認証で、これを二段で行います。

ワークロードは秘密鍵を SPIRE Agent から平文でもらうのではなく、自分で鍵ペアを生成し公開鍵だけを Agent に渡して署名（CSR）を依頼します。秘密鍵がプロセスの外に出ないため、配布経路の漏洩リスクが下がります。Agent は認証が通ったワークロードにだけ署名済み SVID を返し、有効期限が近づくと自動で新しい SVID を発行し続けます。

サービスメッシュ：サイドカーが mTLS を肩代わりする

これらを実務に載せるのがサービスメッシュです。各サービスの隣に サイドカープロキシ（Envoy など）を置き、アプリの代わりにプロキシ同士が mTLS を張ります。アプリは平文でローカルのプロキシと話すだけで、ネットワークを越える区間は自動的に相互認証・暗号化される。

[App A] ──平文──> [Sidecar A] ══ mTLS ══> [Sidecar B] ──平文──> [App B]
                       │                       │
              SVID を受け取る            SVID を検証し
              SPIFFE ID で発信元を提示    SPIFFE ID で認可

この構成の利点は、アプリのコードを一切変えずに相互認証を導入できることです。証明書のローテーションもサイドカーが裏で処理するため、アプリは証明書の存在すら意識しません。さらに認可ポリシーを「SPIFFE ID が payment/checkout のものだけが ledger に接続できる」のように ID ベースで書けるため、IP アドレスの増減に振り回されない、最小権限に沿ったアクセス制御になります。

まとめ

mTLS は TLS ハンドシェイクに CertificateRequest と双方向の CertificateVerify を加え、両当事者が証明書の正当性と秘密鍵の所有を相互に証明する仕組みです。SPIFFE は身元を spiffe:// の URI（SVID）として標準化し、SPIRE がノード・ワークロード認証を経て短命証明書を自動発行・ローテーションすることで、秘密の事前共有なしに信頼を立ち上げます。サービスメッシュのサイドカーがこれらを肩代わりし、アプリ無改修で「正しい鍵を持つ相手だけと通信する」ゼロトラストを成立させます。

土台となる公開鍵基盤（PKI）とX.509 チェーン検証、データを運ぶTLS レコード層、そしてゼロトラストと鍵管理ライフサイクルを併せて読むと、mTLS が「分散システムの相互信頼をどう設計するか」という問いの答えになっていることが原理から見えてきます。