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 終端
ロードバランサーや CDN で TLS を復号し、バックエンドとの通信負荷を軽減する構成パターン
ゼロトラスト
ネットワークの内外を問わず全てのアクセスを検証し、暗黙の信頼を排除するセキュリティモデル
証明書ピンニング
特定の証明書や公開鍵のみを信頼し、中間者攻撃を防ぐセキュリティ手法
TLS 証明書
HTTPS 通信を実現するための電子証明書で、サーバーの身元を証明し通信を暗号化する
ACM
AWS Certificate Manager の略で、SSL/TLS 証明書を無料で発行・管理・自動更新するサービス
HTTPS / TLS
HTTP 通信を TLS で暗号化し、盗聴・改ざん・なりすましを防ぐプロトコル