mTLSとは

詳細な図解

mTLSを読むときの前提

mTLS（Mutual TLS）は、サーバーだけでなくクライアントも証明書を提示し、双方の本人性を確認するTLSです。API間通信、社内サービス連携、端末認証、Service Meshで使われます。

実務では、クライアント証明書の発行元、配布先、秘密鍵保護、CN/SANや属性、失効確認、更新手順、認可との役割分担を確認します。

証跡には、接続元、接続先、提示されたクライアント証明書、issuer、serial、SAN、失効確認結果、認証ログ、許可ポリシー、確認時刻を残します。

認証と認可を分ける

mTLSはクライアントが証明書を持っていることを確認できますが、それだけで全操作を許可してよいわけではありません。証明書の主体、属性、接続元、API権限を別に評価します。

CNやSANだけで強い権限を与えると、証明書再利用や名称衝突で事故になります。アプリ側の認可、RBAC、サービスアカウント、監査ログと組み合わせます。

• 証明書で誰を認証しているか確認する。
• API権限やロールを別に確認する。
• 証明書主体と台帳を照合する。

配布、更新、失効を見る

mTLSの難所は証明書の配布と更新です。端末、サーバー、Pod、サイドカー、APIクライアントなど配布先が多いほど、期限切れや旧証明書残存が起きやすくなります。

紛失端末や退職者、漏えいしたクライアント証明書は失効が必要です。OCSPやCRLを使って失効確認できるか、認証基盤が失効情報を見ているか確認します。

• クライアント証明書の配布先を棚卸しする。
• 更新前後の並行期間を設計する。
• 失効情報が認証判断へ反映されるか確認する。

障害時の切り分け

mTLSで接続できない場合、サーバー証明書、クライアント証明書、CA信頼、秘密鍵不一致、期限切れ、失効、SNI、TLSバージョン、アプリ認可のどこで失敗したかを分けます。

ログにはTLS handshake失敗だけが出ることもあります。サーバー側、クライアント側、プロキシやService Meshのログを同じ時刻で突合します。

• handshake失敗とアプリ拒否を分ける。
• 提示証明書と秘密鍵の対応を確認する。
• Service Meshやプロキシのログも見る。

変更証跡と引き継ぎ

mTLS運用では、CA、発行対象、配布先、失効手順、更新周期、認可ポリシー、緊急停止手順を残します。証明書ファイルだけ共有しても運用は成立しません。

引き継ぎでは、PKI管理者、API所有者、端末管理者、Service Mesh担当、関連語としてTLS、証明書、OCSP、CRLを残すと確認しやすくなります。

• 証明書主体と配布先台帳を更新する。
• 失効と更新のRunbookを整備する。
• 認証ログと認可ログの見方を残す。

関連語

同じ主要カテゴリの用語

セキュリティ・認証の学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能