方式を分ける2つの問い：何を守るか、誰が使うか

多要素認証（MFA）は、パスワードに別の要素を加えて本人を確認する仕組みです。方式の選択は、ほぼ2つの問いで決まります。

1つ目は、突破されたときの被害の大きさです。ドメイン管理者、クラウドの管理コンソール、DNSやドメインレジストラのアカウントを奪われると、被害は組織全体に広がります。こうしたアカウントでは、フィッシング耐性を最優先にします。フィッシング耐性とは、偽サイトに誘導されても認証情報が攻撃者に渡らない性質を指します。

2つ目は、利用者を管理できるかどうかです。社員には端末を配布でき、登録手順も教育できます。顧客の場合は、持っている端末もITへの慣れも人によって違います。サポートにかけられる手間も限られます。このため、利用者の負担と復旧のしやすさの比重が上がります。

基本の考え方は次のとおりです。被害が大きく、利用者を管理できるアカウントほど強い方式を選びます。被害が限られ、利用者の環境がばらばらなほど、導入しやすい方式から始めます。そのうえで段階的に強い方式へ移します。

4方式を同じ観点で比べる

方式フィッシング耐性導入・運用コスト利用者の負担端末紛失時の復旧
SMS・メールOTP低い低い（SMSは送信料がかかる）小さい容易（電話番号やアドレスを再登録）
認証アプリのTOTP低い低い中程度（コードを入力する）難しい（バックアップがなければ再登録）
プッシュ通知承認低い（番号照合で一部改善）中程度（対応するID基盤が前提）小さい中程度（アプリを再登録）
パスキー（同期型）高い中程度小さい容易（同期アカウント経由）
FIDO2セキュリティキー高い高い（購入と配布）小〜中（持ち歩きが必要）難しい（予備キーが必要）

この表は一般的な構成での目安です。実際の強さは、次に述べる弱点への対策と、復旧手順の設計によって変わります。

方式ごとの強みと弱点

SMS・メールOTP

OTPは、1回だけ使える確認コードです。SMSやメールで届くOTPは追加のアプリが要らないため、4方式のなかで最も導入しやすい方式です。

その代わり弱点がいくつかあります。まず、コードは人が入力する文字列です。そのため中継型フィッシング（AitM）で奪われます。これは、攻撃者が本物のサイトと利用者の間に偽サイトを置き、入力された内容を本物のサイトへ転送する手口です。SMSには、携帯電話番号を他人のSIMへ不正に移すSIMスワップの危険もあります。メールOTPは、メールアカウントが乗っ取られた時点で役に立たなくなります。米国NISTのガイドライン（SP 800-63B）は、電話網を使う認証を「制限付き」の手段として扱っています。

認証アプリのTOTP

TOTP（時刻ベースのワンタイムパスワード）は、スマートフォンのアプリが一定間隔で新しいコードを生成する方式です。通信網を使わないため、SIMスワップの影響は受けません。規格が標準化されており、サーバー側の実装も安く済みます。

ただし、コードを人が入力する点はSMSと変わりません。したがって中継型フィッシングは防げません。また、アプリのバックアップ機能を使っていない場合、端末を紛失するとコードを生成できなくなります。運用面では、登録時のQRコードに含まれる共有シークレットの扱いと、再登録の手順を決めておく必要があります。

プッシュ通知承認

ログインするとスマートフォンに通知が届き、利用者が承認ボタンを押す方式です。操作は簡単です。

弱点としてプッシュ疲労攻撃（MFA疲労攻撃）が知られています。パスワードを手に入れた攻撃者が承認要求を何度も送りつけ、利用者が根負けしたり誤って押したりして承認してしまう攻撃です。対策には、ログイン画面に表示された数字をアプリに入力させる番号照合や、アクセス元の地域とアプリ名の表示があります。執筆時点では主要な製品の多くが番号照合を提供しています。利用中の製品で有効になっているかは、管理画面で確認してください。

なお、番号照合を有効にしても十分ではありません。中継型フィッシングの偽サイトが番号を表示し、利用者がその番号を入力すれば突破されます。プッシュ通知承認は、フィッシング耐性のある方式には含まれません。

パスキー／FIDO2セキュリティキー

FIDO2は、FIDO AllianceとW3Cが策定した認証規格です。WebAuthnとCTAPという2つの仕様から成ります。認証用の鍵は、登録したサイトのドメインに結び付けられます。ログインのたびにブラウザが接続先のドメインを確かめるため、偽サイトでは認証が成立しません。利用者が入力して渡すコードもありません。このため、中継型フィッシングに耐えられます。

パスキーには2種類あります。1つは、Apple・Google・Microsoftやパスワード管理ソフトのアカウントを通じて複数の端末へ同期される同期型です。もう1つは、特定の端末やセキュリティキーの中に鍵がとどまるデバイス固定型です。同期型は、端末を紛失しても新しい端末で使えるため、復旧が簡単です。一方で、安全性が同期元アカウントの保護に左右され、組織が鍵の所在を把握しにくくなります。

USBやNFCで接続するセキュリティキーは、鍵が端末の外に出ないため管理しやすい方式です。反面、購入と配布に費用がかかります。紛失に備えて、1人2本を登録するのが一般的な推奨です。また、古い業務システムやVPN装置など、FIDO2に対応していない接続先が残ることも導入時の課題になります。

復旧手段が最大の抜け穴になる

強い方式を選んでも、端末紛失時の復旧手段が弱ければ、攻撃者は復旧手段のほうを狙います。たとえばパスキーを必須にしていても、「端末をなくした」という電話だけでヘルプデスクがSMS認証に切り替える運用なら、実際の強さはSMSと同じです。ヘルプデスクへのなりすましで認証をリセットさせる手口は、執筆時点までに実際の侵害事例でも報告されています。

対策は、復旧経路にも本来の方式と同じ水準の本人確認を求めることです。社員の場合は、予備のセキュリティキーの事前登録、上長や別の管理者による承認、対面やビデオ通話での確認を組み合わせます。バックアップコード（紛失時に使う使い捨てのコード）を発行するなら、その発行と使用をログで監視します。顧客向けサービスでは、復旧に一定の待機期間を設け、登録済みの連絡先へ通知する方法がよく使われます。

用途と予算ごとの選び方

管理者アカウント：セキュリティキーを基本にする

特権アカウントは人数が少ないため、1人2本のFIDO2セキュリティキーを配っても総額は大きくなりません。デバイス固定型なら、鍵が個人の同期アカウントに保存される心配もありません。SMSやTOTPへの切り替え（フォールバック）は無効にします。緊急時用のアカウント（ブレークグラスアカウント）は別のキーで保護し、そのキーは物理的に施錠して保管します。

一般社員：今のID基盤で使える方式から引き上げる

まずは、Microsoft Entra IDやGoogle Workspaceなど、利用中のID基盤が対応している方式から始めるのが現実的です。当面プッシュ通知を使う場合は、番号照合を必ず有効にします。Windows HelloやTouch IDのような生体認証付きの端末がそろっていれば、パスキーへの移行を計画します。予算が限られる場合は、メールや経理、クラウド管理など、狙われやすい部署から先にパスキーやセキュリティキーへ移します。SMSは、移行期間中の一時的な手段にとどめます。

顧客向けサービス：選択肢を残し、パスキーへ誘導する

顧客に特定の端末を持たせることはできません。そこで、パスキーを推奨する方式として示し、同期型ならではの復旧のしやすさを生かします。これが、負担と安全性の釣り合いがとれた選択です。パスキーを使えない環境のためにTOTPやSMSを残す場合は、送金や登録情報の変更といった重要な操作の直前に再認証を求めます。そうすることで、弱い方式が破られたときの被害範囲を絞れます。SMSは利用者数に比例して送信費用が増えるため、規模の大きいサービスほどパスキー移行のコスト面での利点も大きくなります。

導入前に文書化しておく3つのこと

方式を選ぶときは、次の3点もあわせて文書にしておくと判断がぶれません。1つ目は、アカウントを被害の大きさで区分し、区分ごとに許可する方式を決めることです。2つ目は、区分ごとに弱い方式へのフォールバックを認めるかどうかです。3つ目は、端末を紛失したときに、誰がどの手段で本人確認をして再登録を行うかです。3つ目が決まっていない組織は、方式の強化よりも先に復旧手順を整えてください。各方式の技術要件は、NIST SP 800-63-4とFIDO Allianceの公式情報で確認できます。