mTLS とは
mTLS は mutual TLS の略です。日本語では相互TLSと呼ばれます。
通常のHTTPSでは、主にブラウザがサーバ証明書を確認します。
Browser -> Server
Browser checks Server certificate
mTLSでは、通信する両者がお互いの証明書を確認します。
Service A <-> Service B
Service A checks Service B certificate
Service B checks Service A certificate
つまり、サーバ同士が「あなたは本当にそのサービスか」を確認する仕組みです。
なぜサーバ同士の本人確認が必要か
マイクロサービスでは、サービス同士の通信が大量に発生します。
- 注文サービスが決済サービスを呼ぶ
- 決済サービスが通知サービスを呼ぶ
- 在庫サービスが注文サービスに応答する
このとき、ネットワーク内から来たリクエストだから信頼する、という考え方は危険です。
ゼロトラストの考え方では、内部通信でも認証・暗号化・認可を行います。
JWT との違い
JWTとmTLSは役割が違います。
| 方式 | 主に確認するもの |
|---|---|
| JWT | ユーザー、権限、委譲された認可情報 |
| mTLS | 通信相手のサービス本人性 |
たとえば、BFFが注文APIを呼ぶとします。
GET /orders HTTP/1.1
Authorization: Bearer user_access_token
JWTで「どのユーザーの権限か」を伝え、mTLSで「この通信相手は本当にBFFか」を確認する、という組み合わせができます。
Service Mesh とは
Service Mesh は、マイクロサービス間通信を共通の仕組みで管理するための基盤です。
代表的な役割は次の通りです。
| 役割 | 内容 |
|---|---|
| mTLS | サービス間通信の暗号化と本人確認 |
| ルーティング | 通信先や割合を制御 |
| リトライ | 一時的な失敗に再試行 |
| タイムアウト | 待ち続けを防ぐ |
| 観測 | メトリクス、ログ、トレース |
| 認可 | どのサービスがどこへアクセスできるか制御 |
アプリケーションコードに毎回これらを書くのではなく、Service Meshの層で共通化します。
ポイント: JWT はアプリケーションレイヤーの認可情報、mTLS は通信相手の本人確認、Service Mesh はそれらを運用しやすくする基盤と考えると整理しやすいです。
ブラウザ認証とは別の層
mTLSやService Meshは、主にサーバ間・サービス間の話です。
ブラウザとBFFの間では、通常はCookieや通常のHTTPSを使います。
Browser -> Cookie over HTTPS -> BFF
BFF -> JWT + mTLS -> API
Service -> mTLS -> Service
つまり、ブラウザにJWTを置くかどうかの問題とは別の層で、サーバ同士の安全な通信を作るための技術です。
いつ必要になるか
mTLSやService Meshは、すべての小さなアプリで必要なわけではありません。
必要性が高くなるのは、次のような場面です。
- マイクロサービスが多い
- Kubernetes上で多数のサービスが通信している
- 内部通信も暗号化したい
- サービスごとのアクセス制御が必要
- 監査や可観測性が重要
- ゼロトラストを強めたい
一方、単体のWebアプリや小規模APIでは、まず通常のHTTPS、Cookie設定、認証認可、ログ設計を固める方が先です。
まとめ
mTLSは、サーバ同士が証明書で相互に本人確認する仕組みです。
Service Meshは、マイクロサービス間通信の認証、暗号化、観測、制御を共通化する基盤です。
- 通常のHTTPSは主にクライアントがサーバを確認する
- mTLSは双方が証明書を確認する
- JWTはユーザーや権限を伝える
- mTLSはサービス本人性を確認する
- Service Meshはサービス間通信の運用を支える
- ブラウザ認証とは別のサーバ間レイヤーの話
参考リソース
- 公式ドキュメント - mTLS と Service Mesh とは何か - サーバ同士の本人確認 を確認するための一次情報
