mTLS と双方向認証

サーバーが「自分自身」を証明するには TLS 証明書を使用し、クライアントが「自分自身」を証明するには mTLS を使用します。双方が証明書を表示し、検証し合います。ゼロトラストアーキテクチャにおいて、mTLS はサービス間通信のアイデンティティの基盤ですが、証明書の配布とローテーションの運用コストが主な障壁となっています。

概要

標準的な TLS はサーバーのアイデンティティのみを検証します。mTLS（mutual TLS）はクライアント証明書の検証を追加します。サーバーはハンドシェイク中に CertificateRequest を送信し、クライアントは証明書を提示する必要があります。これにより、IP やネットワーク位置に依存せずに双方向でアイデンティティを証明する「ゼロトラスト」ネットワークの基盤が実現します。SPIFFE はサービスアイデンティティを標準化し、Istio/Linkerd は mTLS を使用して service mesh 内の各 pod 間の通信を自動的に暗号化します。独自 CA の構築は mTLS の必須条件です。証明書の発行と失効を完全に制御する必要があります。

TLS vs mTLS: ハンドシェイクの違い

プライベート CA の管理

mTLS をデプロイする最初のステップ: プライベート CA を構築する

# 1. ルート CA の作成（オフライン、ハードウェアセキュリティモジュールまたはエアギャップ環境のマシン）:
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ca.key
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt \
  -subj "/CN=Private CA" -extensions v3_ca

# 2. サーバー/クライアント証明書の発行:
openssl genpkey -algorithm EC -out server.key
openssl req -new -key server.key -out server.csr \
  -subj "/CN=metrics-agent-001"
openssl x509 -req -days 90 -in server.csr -CA ca.crt -CAkey ca.key \
  -out server.crt -set_serial 0x01

# 3. 失効（侵害された証明書がある場合）:
openssl ca -revoke server.crt -keyfile ca.key -cert ca.crt

SPIFFE

mTLS の証明書 CN/SAN に SPIFFE ID を含めるための標準化されたサービスアイデンティティフレームワーク:

SPIFFE ID: spiffe://trust-domain/path
  trust-domain: 組織/クラスターの識別子
  path: サービス/インスタンスの識別子

例: spiffe://liz6.com/metrics-agent/li-cn-node-2

X.509 証明書内:
  SAN URI: spiffe://liz6.com/metrics-agent/li-cn-node-2
  → URI SAN によって検証可能（CN のみではない）

SVID (SPIFFE Verifiable Identity Document):
  = X.509 証明書（短期間: デフォルト 1 時間）+ 秘密鍵
  → SPIRE agent によって自動的にローテーションされる

Service Mesh (Istio/Linkerd)

比較

参考

• RFC: 8446, 8705
• SPIFFE: spiffe.io, github.com/spiffe/spire
• Istio: istio.io/latest/docs/concepts/security/#mutual-tls-authentication

Keywords: mTLS, client certificate, SPIFFE, SPIRE, service mesh, private CA, certificate revocation, SVID