Why It Fits
選ぶ理由
- 双方向で強力な認証
- ネットワーク層で透過的に効く
- サービスメッシュ/ゼロトラストに好適
Product Profile
証明書ベース
サーバだけでなくクライアントも証明書で身元を示す相互認証。改ざん・なりすましに強く、ゼロトラストやサービス間通信で使われる。詳しくは [TLS](/network/tls/) も参照。
Specifications
Introducing
Decision Guide
採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。
Why It Fits
Trade-offs
Deep Dive
mTLS(相互 TLS)は、通信する双方が証明書を提示し合って互いに認証する仕組みです。通常の TLS(HTTPS)ではサーバだけが証明書を出しますが、mTLS ではクライアントも証明書を提示します。
これにより「サーバが本物か」だけでなく「クライアントが本物か」も確かめられ、双方向で相手を信頼できる強固な接続になります。
TLS のハンドシェイクの中で、サーバ証明書の検証に加えてクライアント証明書の検証が行われます。
双方の証明書が正当だと確認できて初めて、暗号化された通信が確立します。
トークンやパスワードによる認証が「アプリケーション層で誰かを確かめる」のに対し、mTLS は接続そのものの層で相手を認証します。
人のログインよりも、機械間(サービス間)の通信を強く保護したい場面に向いています。
サービス間通信や、境界を信用せず常に検証するゼロトラスト環境で採用されます。証明書ベースのため、なりすましに強いのが利点です。
一方で運用負荷は重く、証明書の発行・配布・更新・失効を継続的に回す必要があります。多数のサービスに展開する場合は、証明書を自動で管理する基盤(PKI やサービスメッシュなど)の整備が前提になります。
Implementation View
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
サービス間(マイクロサービス)通信
種別: 証明書ベース / 目的: 相互認証 / トークン/形式: クライアント証明書
ネットワーク層で透過的に効く
証明書の発行・更新・失効の運用が重い
Best Fit