mTLS
クライアントとサーバーが互いに証明書を検証し、双方向で認証する TLS の拡張
mTLS とは
mTLS (Mutual TLS) は、通常の TLS がサーバーの証明書のみを検証するのに対し、クライアントの証明書もサーバーが検証する双方向認証である。マイクロサービス間通信やゼロトラストアーキテクチャで使われる。
TLS vs mTLS
TLS と mTLS の違いを図で示す。
TLS (一方向):
クライアント → サーバー証明書を検証 → 暗号化通信
(サーバーはクライアントを検証しない)
mTLS (双方向):
クライアント → サーバー証明書を検証
サーバー → クライアント証明書を検証 → 暗号化通信
(双方が相手を検証)
| 観点 | TLS | mTLS |
|---|---|---|
| サーバー認証 | ✅ | ✅ |
| クライアント認証 | ❌ | ✅ |
| 用途 | Web サイト、API | マイクロサービス間、IoT |
| 証明書管理 | サーバーのみ | サーバー + クライアント |
ユースケース
代表的なユースケースを以下にまとめる。
| ケース | 理由 |
|---|---|
| マイクロサービス間通信 | サービス間の認証を証明書で行う |
| ゼロトラスト | ネットワーク境界ではなく ID で認証 |
| IoT デバイス | デバイスの正当性を証明書で検証 |
| B2B API | パートナー企業のクライアントを証明書で認証 |
API Gateway に信頼する CA 証明書 (トラストストア) をアップロードし、クライアントはその CA が発行した証明書を提示する。
サービスメッシュでの mTLS
Istio や AWS App Mesh は、サイドカープロキシ (Envoy) が自動的に mTLS を処理する。アプリケーションコードの変更は不要。
Pod A [App] → [Envoy Proxy] ←mTLS→ [Envoy Proxy] → [App] Pod B
証明書の管理
証明書の管理には ACM Private CA (AWS のプライベート CA)、cert-manager (Kubernetes での自動発行・更新)、HashiCorp Vault (シークレット管理 + PKI) がある。
よくある課題
- 証明書の有効期限切れで通信が突然止まる → 自動更新を設定
- 証明書のローテーション中に一時的に接続エラーが発生 → 新旧両方の証明書を信頼する期間を設ける
- デバッグが困難 →
openssl s_clientで証明書チェーンを確認
mTLS を扱う関連書籍も多い。
この記事は役に立ちましたか?
関連用語
TLS 終端 (TLS Termination) とは - ロードバランサーで HTTPS を復号する構成
TLS 終端はロードバランサーや CDN で HTTPS を復号しバックエンドの暗号化負荷を軽減する構成。AWS ALB/Nginx での設定例とセキュリティ上の注意点を解説
ゼロトラスト
ネットワークの内外を問わず全てのアクセスを検証し、暗黙の信頼を排除するセキュリティモデル
証明書ピンニング
特定の証明書や公開鍵のみを信頼し、中間者攻撃を防ぐセキュリティ手法
WebSocket API
API Gateway の WebSocket API でサーバーレスなリアルタイム双方向通信を実現する仕組み
BFF (Backend for Frontend)
フロントエンドごとに専用のバックエンドを用意し、クライアントに最適化された API を提供するパターン
サービスディスカバリ
マイクロサービスが他のサービスのネットワーク位置を動的に発見する仕組み