IT用語集 2024/12/16

耐フィッシング多要素認証とは？ 10分でわかりやすく解説

コラム

耐フィッシング多要素認証を選ぶときの軸は、多要素認証を入れたかどうかではなく、認証情報を偽サイトへ入力した場面でも突破されにくい方式を選べているかどうかです。SMSや認証アプリのワンタイムパスワードはパスワード単体より防御力が上がりますが、攻撃者にリアルタイムで中継される余地が残ります。これに対して、FIDO2/WebAuthnや、管理端末を前提にしたデジタル証明書ベースの認証は、正規サイトや正規環境との結び付きで認証を成立させるため、同じ条件では悪用されにくくなります。

優先順位を付けるなら、管理者アカウント、メール、シングルサインオン（SSO）、重要な社内システムの順で検討すると判断しやすくなります。特にゼロトラストやID基盤の見直しと合わせる場合は、方式そのものの耐性に加えて、紛失時の復旧、共有端末での扱い、例外運用の閉じ方まで先に決めておく方が後戻りを減らせます。

耐フィッシング多要素認証とは

定義

耐フィッシング多要素認証とは、利用者が誤ってフィッシング詐欺の偽画面へ誘導された場合でも、入力情報の窃取や単純な中継だけでは認証を成立させにくいよう設計された方式を中核に据えた認証運用です。利用者の判断ミスを前提にしながら、なりすましログインを成立させにくくする点に特徴があります。

通常のMFAと何が違うか

多要素認証という言葉は広く使われますが、すべての方式が同じ耐性を持つわけではありません。手入力したコードをサーバー側で照合する方式と、正規ドメインに紐づく公開鍵資格情報を使う方式では、フィッシングに対する前提が違います。単に「MFAを導入済み」と整理すると、この差が埋もれます。

SMS／メールOTP	コードを手入力する方式です。偽サイトに入力した値を攻撃者がそのまま中継できるため、耐フィッシング方式には含めにくい整理になります。
認証アプリOTP	アプリ生成コードを使う点はSMSより扱いやすい一方、手入力したコードが中継される余地は残ります。パスワード単体よりは前進ですが、耐フィッシングとは別に整理した方が実態に合います。
プッシュ承認	利便性は高いものの、誤承認や承認疲れへの配慮が欠かせません。番号照合や詳細表示は補強策として役立ちますが、方式そのものの評価と分けて考えます。
FIDO2／WebAuthn	認証鍵が正規ドメインに紐づき、偽サイトでは使いにくい方式です。セキュリティキーやパスキーで実装しやすく、耐フィッシングの中核候補になりやすくなります。
証明書／スマートカード	管理端末やカードに格納した証明書を使う方式です。利用環境を管理しやすい組織では、高い耐性を確保しやすい選択肢になります。

この違いを押さえると、「MFAを増やす」ではなく「どの方式を中核に置くか」という判断に切り替えやすくなります。

なぜ従来型MFAでは足りない場面があるのか

コードを盗むのではなく、中継する攻撃がある

攻撃者は、利用者からID・パスワード・確認コードをまとめて奪うだけではなく、入力された内容をリアルタイムで正規サイトへ中継することがあります。利用者の側では普段どおりにログインしているように見えても、その背後で攻撃者が同じ認証フローを進めている構図です。

このとき、手入力したOTPや安易な承認操作に依存する方式は突破される余地が残ります。逆に、認証鍵が正規サイトのオリジンやドメインに結び付いている方式は、偽サイト側で同じ資格情報を使いにくくなります。

「ワンタイムだから安全」で止まると判断を誤りやすい

ワンタイムパスワードは再利用を防ぎやすい方式ですが、入力した値がそのまま別のセッションへ使われる状況までは止められません。ここを見落とすと、MFAの導入状況と耐フィッシング性を同じものとして扱ってしまいます。

代表的な耐フィッシング方式

FIDO2／WebAuthnとパスキー

FIDO2／WebAuthnは、公開鍵暗号を使って認証する方式です。資格情報は利用先の正規ドメインに紐づき、利用者は端末内でPINや生体認証を使って認証操作を行います。認証のたびに秘密鍵そのものを送るわけではないため、偽サイト側で同じ資格情報を再利用しにくくなります。

導入時は、セキュリティキーを配布する形、端末内のパスキーを使う形、両方を併用する形のどれが自社に合うかを見ます。共有端末が多い環境では運用設計が変わりやすく、個人所有端末まで広げる場合は復旧フローも含めて設計しておく方が安全です。

証明書ベース認証

クライアント証明書を使う方式は、管理端末や管理ブラウザを前提にしやすい組織で候補に入りやすくなります。端末と利用者をまとめて管理したい場合や、社給端末中心の運用では候補に入りやすくなります。用途によってはスマートカードも同じ系統の選択肢として扱えます。

ただし、証明書ベース認証は配布、更新、失効、端末更改時の再発行まで含めて設計しないと、セキュリティの強化より運用の混乱が先に出ます。方式の強さだけで決めると失敗しやすい領域です。

プッシュ承認はどう位置付けるか

プッシュ承認は全面的に捨てるか残すかで考えるより、どの領域では補助策として残し、どの領域では中核方式から外すかで整理した方が実務に合います。番号照合、端末情報表示、短時間の連続要求抑止は誤承認対策として役立ちますが、管理者やメールのように被害が大きい領域では、FIDO2／WebAuthnや証明書ベース認証を優先する方が整理しやすくなります。

どこから導入するか

優先順位を付けやすい領域

管理者アカウント
メールとシングルサインオン（SSO）
VPNやリモートアクセス基盤
決裁、送金、顧客情報閲覧など影響が大きい業務

この順で見ていくと、少人数でも先に効果を出しやすくなります。全社一斉導入にこだわるより、被害が大きい領域から必須化し、一般ユーザーへ段階的に広げた方が例外処理も整理しやすくなります。

導入がつまずきやすい点

古い業務システムがFIDO2／WebAuthnに対応していない
共有端末や共用アカウントが残っている
紛失、機種変更、退職時の復旧・失効手順が決まっていない
例外措置としてOTPを広く残し、結局そこが抜け道になる

導入の成否は、認証画面を変えた時点では決まりません。例外運用をどう閉じるか、復旧手続きをどこまで厳格にするか、ヘルプデスクがどの権限で何を戻せるかまで決めておく必要があります。

向いているケースと向きにくいケース

耐フィッシング方式が向いているのは、管理者、メール、ID基盤、社外公開サービスの運用担当のように、1件の突破で被害が広がりやすい領域です。逆に、共有端末が多く、本人確認や復旧のルールが未整備のまま広げると、現場負荷だけが先に増えることがあります。こうした環境では、対象範囲を区切ってから展開した方が混乱を抑えやすくなります。