相互TLS（mTLS）の実装パターン

標準TLSでは、証明書によってクライアントに対してサーバーだけを認証します。相互TLS（mTLS）ではこれを拡張し、双方が証明書を提示して検証します。クライアントは、サーバーがTLSハンドシェイク中にCertificateRequestを使って要求した後、クライアント証明書を提示します。サーバーは、信頼するCAに基づいてクライアント証明書を検証します。mTLSはゼロトラストネットワークの基盤です。ネットワーク境界のセキュリティに依存するのではなく、接続のたびにサービス同士を暗号学的に認証します。Istio、Linkerd、Consul Connectなどのサービスメッシュは、マイクロサービス間でmTLSを透過的に実装します。

mTLSのハンドシェイクは、TLS 1.3を次のように拡張します。ServerHelloとサーバーの証明書およびFinishedの後、サーバーは、受け入れ可能な認証局と署名アルゴリズムを指定するCertificateRequestメッセージを送信します。クライアントは、Certificate（クライアント証明書チェーン）とCertificateVerify（クライアントの秘密鍵を使ってトランスクリプトに対して生成した署名）で応答します。サーバーは、信頼するCAストアに基づいてクライアント証明書チェーンを検証し、CertificateVerifyの署名を検証します。両方の検証に成功すると、接続は相互認証済みになります。証明書に対応する秘密鍵がなければ、クライアントはCertificateVerifyを偽造できません。

サービスメッシュ環境では、クライアント証明書は通常、内部CAによって発行されます。IstioはSPIFFE（Secure Production Identity Framework for Everyone）のSVIDを使用します。各ワークロードは、spiffe://cluster.local/ns/default/sa/payment-serviceのようなSPIFFE URI SAN（Subject Alternative Name）を持つ証明書を取得します。これらの証明書は短期間（24時間）だけ有効で、メッシュのコントロールプレーン（istiod）によって自動的にローテーションされます。ユーザー向けのmTLS（企業VPNやAPIクライアントなど）では、証明書を企業CAがより長い有効期間で発行し、従業員のデバイスにはMDM（Mobile Device Management）を通じて配布する場合があります。

サーバー側のmTLS検証には、いくつかの手順があります。(1) チェーン検証 — クライアント証明書がサーバーのクライアントCAストアにある信頼されたルートCAまでつながることを検証します。(2) 有効期間の確認 — 証明書が期限切れでなく、かつ有効期間の開始前でもないことを確認します。(3) 失効確認 — OCSPまたはCRLによって証明書が失効していないことを検証します。(4) SAN/CNの照合 — 証明書のSAN（SPIFFE URI、DNS名、またはメールアドレス）から識別情報を取り出します。(5) 認可 — 認証された識別情報が要求されたリソースへのアクセスを許可されていることを確認します。手順4と5には、基本的なTLS設定を超えるアプリケーションレベルのロジックが必要です。

有効期間の短い証明書を使用すると、明示的な失効が不要になります。証明書が24時間で期限切れになる場合、漏えいによる影響期間を限定できるためです。ローテーションには次の処理が必要です。(1) 事前ローテーション — 古い証明書が期限切れになる前に新しい証明書を発行します（有効期間の80%でローテーションします）。(2) ダウンタイムなしの切り替え — 移行期間中、サービスは古い証明書と新しい証明書の両方を受け入れる必要があります。(3) グレースフルリロード — TLSスタックは既存の接続を切断せずに認証情報を再読み込みする必要があります（nginx: nginx -s reload; Envoy: dynamic xDS certificate update）。SPIFFE Workload API（SPIREによって実装）は、UnixドメインソケットAPIを通じた証明書の配布とローテーションを自動化します。

Istioは、各Podに注入されたEnvoyサイドカープロキシを介して、透過的にmTLSを実装します。コントロールプレーン（istiod）は、mesh root CAによって署名された中間証明書を使用するCAとして機能します。各Podのサイドカーは、SDS（Secret Discovery Service）APIを介してSPIFFE SVIDを受け取ります。PeerAuthenticationポリシーでmTLSモードを設定します。STRICT（mTLS必須）、PERMISSIVE（mTLSと平文の両方を受け入れ、移行用）、またはDISABLEです。AuthorizationPolicyリソースは、通信可能なサービスを定義し、クライアント証明書内のSPIFFE identityに基づいて検査されます。これにより、アプリケーションコードを変更せずに、クラスター内でゼロトラストを実現します。

外部APIクライアントの場合、mTLSはAPIキーやOAuthトークンよりも強力な認証を提供します。クライアントは、秘密鍵を安全なストレージ（HSM、OSキーストア、またはパスフレーズで保護したソフトウェアキー）に保持します。クライアント証明書は、APIエンドポイントが想定するCAにピン留めされます。各APIリクエストはTLS層で認証されるため、別途Authorizationヘッダーを用意する必要はありません。CloudflareのAPI Shield、AWS API Gatewayのクライアント証明書、Google CloudのサービスアカウントmTLSは、いずれもこのモデルを実装しています。侵害されたAPIキーはどこからでも使用できますが、侵害されたmTLS秘密鍵を悪用するには、クライアントを実行しているデバイスも盗み出す必要があります。

mTLSの導入には、いくつかの運用上の課題があります。(1) 証明書の配布 — 特にPodが動的にスケールアップ・ダウンする環境では、すべてのサービスにクライアント証明書を安全に届ける必要があります。(2) CAの侵害 — 内部CAは価値の高い標的であり、侵害されるとすべてのサービス証明書が無効になります。HSMで保護されたCAとオフラインroot CAによって、このリスクを軽減できます。(3) デバッグ — 暗号化されたmTLSトラフィックは標準的なデバッグツールからは見えにくいため、サービスメッシュの可観測性ツール（Jaeger、Kiali）が必要です。(4) ミドルボックスとの互換性 — TLSインスペクションプロキシは、クライアント証明書を通過させるよう明示的に設定しない限り、mTLSを妨げます。(5) 証明書の有効期限切れによるインシデント — ローテーションに失敗すると、サービス全体が停止する可能性があります。

SPIFFE（Secure Production Identity Framework for Everyone）は、X.509 SVIDを使用したワークロードidentityの標準を定義します。SPIRE（SPIFFE Runtime Environment）は、そのリファレンス実装です。SPIRE Serverは、登録機関およびCAとして機能します。SPIRE Agentsは各ノード上で実行され、ノードアテスター（AWS instance identity、Kubernetes service account JWT、TPM）とワークロードアテスター（Unix PID、コンテナランタイムのメタデータ）を使用してワークロードidentityを証明します。Workload APIは、シンプルなgRPC APIを使用し、Unixドメインソケット経由でSVIDをワークロードに提供します。SPIREは、Envoy、Nginx、主要なサービスメッシュと統合し、証明書ソースとして機能します。

高セキュリティのmTLS環境では、秘密鍵をソフトウェアのキーストアではなく、Hardware Security Module（HSM）に格納する必要があります。TLSライブラリ（OpenSSL、BoringSSL）はPKCS#11インターフェース経由で秘密鍵を読み込み、署名処理をHSMに転送します。秘密鍵が平文でHSMの境界外に出ることはありません。クラウドHSMの選択肢には、AWS CloudHSM、Azure Dedicated HSM、Google Cloud HSMがあります。デバイスレベルのmTLS（IoT、企業のノートPC）では、TPM 2.0が同様の機能を提供します。TLSクライアントキーはTPMにバインドされ、署名にはTPMの認証が必要となるため、侵害されたデバイスからのキー抽出が極めて困難になります。

mTLSのテストには、クライアント証明書を提示できるツールが必要です。OpenSSL s_client: openssl s_client -connect host:443 -cert client.pem -key client.key -CAfile server-ca.pem。curl: curl --cert client.pem --key client.key --cacert server-ca.pem https://host。サービスメッシュをテストする場合は、istioctl proxy-config secret pod/nameを実行すると、現在の証明書とその有効期限を確認できます。Pod内でkubectl execを実行してサイドカーの管理エンドポイント（localhost:15000）にcurlし、アクティブなリスナーとmTLS設定を調べることもできます。自動ローテーションのテストでは、証明書のローテーションイベントをまたいでも接続が安定して維持されることを検証してください。

標準的なTLSと比べて、mTLSではどのような追加手順が行われますか？

mTLSはTLSにクライアント証明書認証を追加し、双方が相手の証明書を検証します。SPIFFE SVIDは、証明書のSANに含まれるSPIFFE URIを介して、標準化されたワークロードidentityを提供します。IstioはEnvoyサイドカーを介してmTLSを透過的に実装し、STRICTとPERMISSIVEのモードを提供します。短期間（24時間）の証明書を使用すると、失効処理が不要になり、侵害された場合の影響期間を短縮できます。SPIREはWorkload APIを介して、証明書の発行とローテーションを自動化します。高セキュリティ環境では、mTLS秘密鍵をHSMまたはTPMに格納してください。運用上の課題には、CAキーの保護、ミドルボックスとの互換性、ダウンタイムなしのローテーションなどがあります。