LASSIC Media らしくメディア
mTLSとは｜相互TLS認証の仕組みと使いどころ
サービス間の通信やAPI連携が広がるほど、「通信の相手を確かめる仕組み」の重みは増していきます。Webサイトへのアクセスで使われる通常のTLSは、利用者側がサーバの証明書を確認する一方向の仕組みですが、社内外のシステムをつなぐAPIやマイクロサービスの世界では、逆にサーバ側が「呼び出しているのはどのシステムか」を見極めたい場面が出てきます。そこで用いられるのが、双方が証明書を提示し合うmTLS（相互TLS認証）です。
この記事では、発注者やプロジェクトマネージャー、システム連携の設計に関わる方に向けて、mTLSの考え方と通常のTLSとの違い、導入される場面、運用面で押さえておきたい点を整理します。証明書がCAから発行されチェーンとしてつながって検証される仕組みそのものは別記事に譲り、本記事では「双方が相手を確かめ合う」という相互認証の着眼点に絞って解説します。
mTLS（相互TLS認証）とは
mTLS（mutual TLS、相互TLS認証）とは、通信を始める際に、クライアントとサーバの双方が証明書を提示し、互いに相手を確認し合う仕組みです。「相互」という言葉が示す通り、確認する側とされる側があらかじめ固定されておらず、両方が証明書を出し合う点が特徴といえるでしょう。
TLSという技術そのものは、Webサイトの閲覧などで広く使われており、通信内容を暗号化する役割と、接続先のサーバが本物であるかを確認する役割を担っています。ただし通常のTLSでは、証明書を提示するのはサーバ側だけで、クライアント側（ブラウザや呼び出し元のアプリ）は特に名乗りを立てません。この「片側だけの証明」を両側に広げたものが、mTLSだとイメージすると分かりやすいはずです。
サービス間通信やAPI連携が増えている環境では、サーバ側にとっても「呼び出し元が想定するシステムかどうか」を見極めたい場面が出てきます。IDやパスワード、APIキーだけに頼るのではなく、証明書という形でクライアント側の身元を確かめる手段として、mTLSが選ばれるようになってきました。呼び出す側・呼び出される側という上下関係ではなく、対等な立場で互いに証明書を差し出す、という点にmTLSらしさが表れているといえるでしょう。
この記事のポイント
- mTLS（相互TLS認証）は、クライアントとサーバの双方が証明書を提示し合い、互いを確かめる仕組みです。
- サーバ側だけを確認する通常のTLSと違い、呼び出し元も証明書で見分けられる点が特徴です。
- サービス間通信やゼロトラスト、IoT・API連携など、相手があらかじめ決まる場面で採り入れられています。
通常のTLSとの違い
mTLSの位置づけをつかむには、日頃よく使われる一方向のTLSと並べて見るのが早道です。両者は同じTLSという土台を使いながら、確認し合う範囲が異なります。
一方向のTLSでは、クライアントがサーバの証明書を検証し、接続先が偽物でないかを確かめます。ブラウザでのアクセスの大半はこの形で、クライアント側は証明書を持たず、名乗りを立てないのが通例です。これに対してmTLSでは、サーバ側もクライアントへ証明書の提示を求め、あらかじめ信頼すると決めたCA（認証局）が発行した証明書かどうかを検証します。下の表に、主な違いを整理しました。
| 観点 | 通常のTLS（一方向） | mTLS（相互） |
|---|---|---|
| 認証の対象 | サーバのみ | クライアントとサーバの双方 |
| 証明書を用意する側 | サーバ側だけ | クライアント側・サーバ側の双方 |
| 典型的な用途 | Webブラウザからの一般的なアクセス | サービス間通信・API連携・IoT機器接続 |
| 管理する証明書 | サーバ証明書のみ | サーバ証明書とクライアント証明書の両方 |
| 運用の手間 | 比較的少ない | 発行・失効・更新の管理項目が増える |
表から分かる通り、mTLSを取り入れると、サーバ側で管理する証明書の種類や運用の手間は増えていきます。その分だけ、通信の相手を双方向で確かめられるという性質が加わるわけです。どちらを選ぶかは、通信の相手が不特定多数の利用者なのか、あらかじめ決まったシステム同士なのかによって変わってきます。
mTLSの仕組み
mTLSの通信は、通常のTLSのやり取りに、クライアント側の証明書検証という手順を足した形で進みます。おおまかな流れを追ってみましょう。
まず、クライアントがサーバへ接続を試みると、サーバは自分の証明書を提示します。クライアントは、この証明書があらかじめ信頼するCAによって発行されたものかを確かめ、問題がなければ通信を続けます。ここまでは、通常のTLSと同じ流れです。
mTLSでは、続いてサーバ側からクライアントへ証明書の提示を求めます。クライアントは自分の証明書を送り返し、サーバはそれを信頼するCAの情報と照らし合わせて検証するのです。双方の検証が済んで初めて、通信が確立します。企業間のAPI連携や社内のサービス間通信では、この信頼するCAを自社や特定の取引先の間だけで運用する「プライベートCA」とする例も少なくありません。
なお、証明書がどのようにCAから発行され、チェーンとしてつながって検証されるのかという仕組みそのものについては、別記事「証明書チェーンの仕組み」で詳しく取り上げています。本記事では、その検証の仕組みを踏まえたうえで、「双方が証明書を出し合って確かめ合う」という相互認証の考え方に絞って見ていきます。
mTLSが使われる場面
mTLSは、不特定多数の利用者を相手にする場面よりも、通信の相手があらかじめ決まっているシステム同士の連携で採り入れられることが多い技術です。代表的な場面を挙げます。
| 使われる場面 | 相互認証が生きる理由 |
|---|---|
| サービス間通信（マイクロサービス） | 内部の呼び出し元を証明書で見分け、想定しない経路からの呼び出しに気づきやすくする |
| ゼロトラストネットワーク | 社内ネットワークにいることを前提とせず、通信のたびに端末やサービスの身元を確かめる |
| サービスメッシュ | Istioなどの基盤でサイドカー間の通信にmTLSを組み込み、経路上の通信をまとめて相互認証する |
| IoT機器とバックエンドAPI | 多数の機器がクラウド側のAPIへ接続する構成で、機器ごとに証明書を持たせて識別する |
| 取引先とのB2B API連携 | 決まった取引先システムとだけデータをやり取りする窓口に、双方の証明書を求める |
共通しているのは、「通信の相手が誰なのか、あらかじめ見当がついている」という前提です。相手が不特定多数のWeb利用者ではなく、決まったサービスや機器であるからこそ、双方に証明書を持たせるという運用が現実的になります。裏を返せば、相手を絞り込みにくい一般公開のWebサイトでは、mTLSは向かない場面が多いといえるでしょう。
導入のメリット
mTLSを取り入れる狙いは、通信の相手を証明書という形で確かめられるようにする点にあります。IDとパスワードの組み合わせやAPIキーだけで呼び出し元を判断する仕組みと比べると、鍵の管理主体が変わり、なりすましのリスクを下げる方向に働きやすくなります。とくに、パスワードのように使い回されたり漏れたりしやすい情報に依存しない点は、サービス間通信における利点として挙げられるでしょう。
加えて、ゼロトラストの考え方と相性がよいことも見逃せません。社内ネットワークにいるからといって無条件に信頼するのではなく、通信のたびに双方の身元を確かめる、という発想にmTLSは自然と合致します。サービスメッシュのようにサイドカー間の通信すべてにmTLSを組み込む構成では、開発者が個々のアプリケーションで認証処理を書かなくても、基盤側で相互認証をまとめて担わせられる点も、運用上の利点として語られることが多いところです。
もう一つ挙げるなら、誰がどのサービスへ接続したのかを、証明書に紐づけて追いやすくなる点があります。障害調査やアクセスの棚卸しの場面で、呼び出し元をIPアドレスだけでなく証明書の識別情報から絞り込めると、原因の切り分けにかかる時間を縮めやすくなるでしょう。もっとも、これらの利点は証明書の管理体制が整っていて初めて生きるものであり、次に見る運用面の設計とセットで検討する必要があります。
運用と導入時に押さえておきたい点
mTLSは、いったん組み込めばそれで完結する仕組みではありません。証明書という「有効期限のあるもの」を扱う以上、運用の設計が導入の成否を左右するのです。仕組みそのものは枯れた技術であっても、運用体制の作り込みが甘いと、期限切れによる通信断や、退職者・廃棄機器の証明書が使われ続けるといった問題につながりかねません。押さえておきたい観点を挙げます。
証明書の発行・失効の運用体制
クライアント証明書を誰が発行し、どのCAで管理するのかを、導入前に決めておく必要があります。社内やグループ企業間で完結する連携であればプライベートCAを立てる例が多く、退職や契約終了、機器の廃棄といった場面で証明書を失効させる手順もあわせて整えておくことが求められます。CRL（失効リスト）やOCSPといった失効確認の仕組みをどう組み込むかも、早い段階で検討したいところです。
ローテーションの自動化
証明書には有効期限があり、期限が切れれば通信が止まってしまいます。台数や接続先が少ないうちは手作業でも回せますが、サービスや機器の数が増えるほど、更新のし忘れが通信断につながるおそれが大きくなるのです。多くの現場では、証明書の発行・配布・更新をツールで自動化し、人手による更新作業をできるだけ減らす運用が採られています。
外注・発注時に確認したい点
mTLSの導入を外部へ依頼する際は、「誰が証明書を発行し、失効や更新をどう回すのか」という運用面まで含めて相談することが望ましいでしょう。仕組みを組み込むところまでで区切るのか、運用開始後の証明書管理や監視まで哻せるのかで、必要な体制は大きく変わってきます。既存の認証基盤やAPI Gatewayがmutual TLSに対応しているかどうかも、あわせて確認しておきたい項目です。
まとめ
- mTLS（相互TLS認証）は、クライアントとサーバの双方が証明書を提示し合い、互いを確かめる仕組みである。
- サーバのみを確認する通常のTLSと異なり、呼び出し元も証明書で見分けられる点が特徴となる。
- サービス間通信、ゼロトラスト、サービスメッシュ、IoT・B2B API連携など、相手があらかじめ汾まる場面で採り入れられている。
- 証明書という形で身元を確かめるため、パスワードやAPIキーのみに頼る運用よりなりすましのリスクを下げる方向に働きやすい。
- 証明書の発行・失効・ローテーションという運用面の設計が、導入後の安定した運用を左右する。
よくある質問
mTLSと通常のTLSは、何が違いますか。
確認し合う範囲が異なるのです。通常のTLSでは、クライアントがサーバの証明書を検証し、接続先が偽物でないかを確かめますが、クライアント側は証明書を持ちません。mTLSでは、これに加えてサーバ側もクライアントへ証明書の提示を求め、あらかじめ信頼するCAが発行したものかどうかを検証します。双方が証明書を出し合って確かめ合う点が、いちばんの違いといえるでしょう。
mTLSは、どのような場面で導入されていますか。
通信の相手があらかじめ決まっているシステム同士の連携で採り入れられることが多くなっています。具体的には、社内のマイクロサービス間通信、ゼロトラストネットワークにおける端末やサービスの認証、Istioなどのサービスメッシュにおけるサイドカー間通信、多数の機器を抱えるIoTとバックエンドAPIの接続、取引先とのB2B API連携などが代表例です。相手を絞り込みにくい一般公開のWebサイトでは、あまり使われない傾向にあります。
証明書の失効やローテーションは、どのように運用すればよいですか。
CRLやOCSPといった失効確認の仕組みをどう組み込むかを決めたうえで、証明書の発行・配布・更新をできるだけツールで自動化する運用が広く採られています。台数や接続先が少ないうちは手作業でも回せますが、数が増えるほど更新のし忘れが通信断につながりやすくなるため、早い段階から自動化の仕組みを組み込んでおくと、後々の運用負荷を抑えられるでしょう。
mTLSを導入すれば、なりすましのリスクはなくなりますか。
リスクをゼロにする仕組みではないのです。パスワードやAPIキーのみに頼る運用と比べると、証明書という形で身元を確かめる分、なりすましのリスクを下げる方向に働きやすくなりますが、秘密鍵の管理がずさんであったり、失効の仕組みが機能していなかったりすれば、その効果は薄れてしまいます。証明書の発行から失効までの運用体制をあわせて整えることが、導入の効果を左右します。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、サービス間通信やAPI連携における認証方式の検討から証明書運用の設計、実装、公開済みシステムの見直しまでを一貫して支援する体制です。要件定義の段階から実装、テスト、リリース後の運用・保守まで、工程を分けずに任せられる点も強みでしょう。ゼロトラスト構成やマイクロサービス間の認証設計でお困りの際も、ご相談いただけます。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
出典
- RFC 8446「The Transport Layer Security (TLS) Protocol Version 1.3」（IETF）
- Amazon API Gateway Developer Guide「Mutual TLS authentication for REST APIs」
