私たちが普段「MFA（多要素認証）」と呼んでいる仕組みは、ID・パスワードに加えてSMSのワンタイムパスワードや認証アプリのプッシュ通知などを組み合わせ、不正ログインを防ぐためのものです。このMFAを導入していれば安全という考え方が広く共有されてきましたが、近年では、MFAを導入していても不正ログインが成立するケースが増えています。要因としては、攻撃者が利用者と正規サービスの間に入り込み、ID・パスワードだけでなく、ワンタイムパスワードや承認操作までリアルタイムに中継し、認証後のセッションを奪う手口が一般化しているためです。

業界ではこうした脅威に強い方式を「フィッシング耐性のあるMFA」と呼ぶことがあります。ただし、本質は“多要素であること”ではなく、たとえ偽サイトに誘導されても認証結果が攻撃者に再利用されないことです。そこで本稿では、多要素認証ではなく単一の認証要素に注目して 「フィッシング耐性のある認証」 という軸で整理し、企業の認証基盤として特にクライアント証明書がなぜ有力なのかを考えます。

フィッシング攻撃の変化

従来のフィッシング攻撃は、正規サイトのHTMLや画像をコピーした偽サイトを用意し、利用者が入力したパスワードなどの資格情報を攻撃者が受け取るというものでした。メールやチャットメッセージなどを入口に、利用者が本物と微妙に異なるURLへ誘導されることがあるため、日常業務の延長線上にある導線が悪用されることから、不審に気づきにくいのが厄介な点です。

しかし、それらの攻撃への対策として、MFAの広範な普及によって、パスワードを盗むだけでは侵入できないケースが増えました。その結果、攻撃側も手法を変えて“コピーサイト型”から“中継型”へと変化しています。

特に、現在問題になっているのは、Adversary-in-the-Middle（AiTM）と呼ばれるリバースプロキシを使った"中継型"の攻撃です。攻撃者は利用者と正規サービスの間に中継サーバを配置することで通信に入り込み、入力されたID・パスワードやMFAの承認操作をリアルタイムに転送します。そして認証が通ると、正規サービスが発行したセッション情報（Cookie やアクセストークンなど）を詐取しMFA通過後のログイン状態を乗っ取ります。そのため、利用者の視点では、正規サイトとの通信と区別がつかず、そしてMFAも正常に完了するため、不正に気づくことは困難です。

ここで論点になるのは、「MFAを導入しているかどうか」ではありません。MFAでも突破されてしまうケースがある以上、導入している認証方式が「中継されても再利用されない設計になっているか」が重要です。だからこそ企業は、自社が使用している認証方式を見直し、「フィッシング耐性のある認証」の導入を検討する必要があります。

米国の認証ガイドラインでの整理

こうした変化を理解するうえで重要な参照先が、米国のNIST（National Institute of Standards and Technology）が公開するNIST SP 800-63Bです。これはデジタル・アイデンティティにおける認証の要件を示すガイドラインで、日本でも認証設計の参考として広く参照されています。

NISTの認証ガイドラインでは、以前から「偽の検証者に認証を成立させてしまわないこと」が重要な性質として扱われてきました。近年は、それがフィッシング耐性という観点でより明示的に整理されています。理解の鍵になるのが、認証をサービスの識別子に結び付ける考え方（Verifier Name Binding　以下、VNB）と、成立中の通信チャネルに結び付ける考え方（Channel Binding　以下、CB）です。

※ここでの「検証者」とは、認証を受け付けるサービスやシステムのことを指します。

VNBとCBの違い

VNBは、認証を正規サービスのドメイン名やサービス識別子に結び付ける考え方です。
VNBの代表的な実装のパスキーでは、資格情報の利用がRP ID（Relying Party Identifier）に結び付けられます。そのため、見た目が似ていても別ドメインの偽サイトに、同じ認証結果をそのまま持ち込むことは困難です。

CBは、認証結果をいま成立している通信チャネルそのものに結び付ける考え方です。
そのため、ある接続で成立した認証を、別の接続にそのまま持ち込むことはできません。

これらを端的に言えば、VNBは「偽サイトで使えないようにする」考え方であり、CBは「別の接続へ持ち出せないようにする」考え方です。この2つの考え方の違いは、AiTMのような中継型攻撃を考えるときに特に意味を持ちます。

なぜクライアント証明書が有力なのか

CBとしてのmTLS

CBの考え方と強く整合する実装例のひとつが「mTLS」です。

mTLSでは、クライアントは証明書を提示するだけでなく、TLSハンドシェイク中にCertificateVerifyと呼ばれる署名メッセージを送ります。この署名はそのハンドシェイクで交わされた情報に対して行われるため、別のTLS接続へそのまま転用することはできません。結果としてNISTが定義するCB、「認証を通信チャネルに結び付ける」 と同等の効果をもたらします。なお、署名対象の詳細はTLS 1.2と1.3で異なりますが、「そのチャネルに結び付いた署名である」という性質はどちらも共通しています。

mTLSにある根本的な強さ

企業が自社サービスにmTLSを設定している場合、正規サービスはTLSハンドシェイクの段階でクライアント証明書の提示と署名検証を求めます。
秘密鍵が適切に保護され攻撃者に窃取されていない限り、通常のAiTMプロキシはその秘密鍵を利用できません。そのため、正規サービスとのTLSハンドシェイク自体が完了できず、接続が確立されません。結果として、認証結果を別の接続へ持ち出す余地がなく、AiTM型の中継攻撃に強い構造になります。

mTLSの守備範囲の広さ

パスキーはVNBに加えてAiTMへの耐性も持つ優れた方式ですが、ユーザー操作を伴う認証が前提です。一方でmTLSは、API認証・B2B接続・サービス間通信・端末認証まで、企業内のあらゆるTLS通信に一貫して適用できる点で異なります。クライアント証明書は、それらに共通する「信頼の部品」として使いやすく、企業の通信全体に信頼を埋め込めるのが大きな強みです。
さらに、先述の通り、認証が成立しない場合は通信経路そのものが確立されないため、「認証をどこで成立させるか」という設計の組み立てを行いやすくなります。

mTLS導入時のポイント

では、mTLSを導入する際にはどのような点に注意すべきなのでしょうか。大きく分けて3点挙げられます。

第一に、証明書のライフサイクル管理が欠かせません。発行、配布、更新、失効まで含めて設計されていなければ、せっかくの強い認証も運用で崩れます。証明書ベースの認証は、導入そのものよりも運用で真価が問われます。

第二に、認証局（CA）自体の信頼性の確認が欠かせません。CA がどのように運用されているかは信頼の土台そのものです。CA秘密鍵の保護、発行権限の統制、監査体制といった運用の質が、クライアント証明書の信頼性に直結します。

参考：クライアント証明書認証の安全性が確保される、CA秘密鍵保護の重要性

第三に、入口対策と認証対策は分けて考えるのが健全です。メールやチャットメッセージなど、偽サイトへ誘導される経路を減らす対策は重要です。しかし、入口対策だけで誘導をゼロにすることはできません。だからこそ、誘導されたあとでも認証結果を再利用されない設計、すなわち、フィッシング耐性のある認証が必要になります。

まとめ

フィッシング攻撃の手法が変化している昨今で問われているのは、「MFAを入れているかどうか」ではありません。利用している認証が、中継されても再利用されないかどうかです。

そこで、mTLSは、認証がTLSハンドシェイクに結び付くため、中継攻撃に持ち込めない構造を持ちます。さらに現実には、秘密鍵を持たない攻撃者プロキシは正規サービスとの接続自体が成立しません。加えて、企業内のあらゆるTLS通信に適用できる守備範囲の広さも含め、企業認証基盤として有力な選択肢です。

フィッシング耐性を「ログイン方式の比較」にとどめず、通信基盤の設計として捉えることが、これからの企業認証ではますます重要になっていくでしょう。