副題:NIST SP 800-63-4が引いた線をどう読むか
想定読者:IAM担当、CISO、デジタルチャネル担当、セキュリティ設計者
第1回で見たとおり、AiTMフィッシングもMFA疲労も、認証そのものを突破する攻撃ではありません。認証の結果を横取りする攻撃です。だとすれば、対策は「MFAを入れる」ではなく「横取りできない認証方式に変える」になります。
2025年8月26日、NISTはSP 800-63-4(デジタルアイデンティティガイドライン)の最終版を公表しました。ここで引かれた線が、方式選択の判断材料になります。
1. 「MFAなら何でもよい」が終わった理由
広く使われているMFAの方式は、次のように整理できます。
方式 | AiTMフィッシング | MFA疲労 | SIMスワップ等 |
|---|---|---|---|
SMS OTP | 迂回される | ― | 影響を受ける |
ワンタイムパスワード(TOTPアプリ) | 迂回される | ― | 影響なし |
プッシュ通知承認 | 迂回される | 影響を受ける | 影響なし |
番号一致(Number Matching)付きプッシュ | 迂回される | 大幅に低減 | 影響なし |
FIDO2/Passkey | 原理的に成立しない | 該当しない | 影響なし |
証明書ベース認証(デバイス証明書・PIV相当) | 原理的に成立しない | 該当しない | 影響なし |
上から5つ目までの方式には共通点があります。利用者が「何か」を相手に渡していることです。コード、承認、数字。渡すものがある限り、間に入った攻撃者が受け取って転送できます。
2. 「フィッシング耐性」とは何を指すのか
NIST SP 800-63B-4は、フィッシング耐性のある認証を、認証器が署名された、検証者を限定したアサーション(audience-restricted assertion)を生成するものと定義しています。基盤となるのは公開鍵暗号です。
実装上、何が起きているかというと次のとおりです。
- 認証器(端末のセキュアな領域やセキュリティキー)が秘密鍵を保持し、外に出さない
- 署名の対象に、接続先のドメイン(オリジン)が含まれる
- 偽サイトに署名を渡しても、その署名は偽サイトのドメインに紐づいており、正規サイトでは検証に通らない
つまり利用者が騙されても、暗号的に成立しないという設計です。人間の判断力に依存しない点が、教育や注意喚起との決定的な違いになります。

3. NIST SP 800-63-4が引いた線
実務に効く変更点は3つあります。
変更点1:AAL3ではフィッシング耐性が必須
認証保証レベル(AAL)の要件が整理され、AAL3では公開鍵暗号に基づく認証とフィッシング耐性が必須になりました。AAL2でもフィッシング耐性のある方式の提供が求められます。
項目 | AAL2 | AAL3 |
|---|---|---|
認証方式 | 異なる2要素、または多要素認証器 | 公開鍵暗号に基づく認証が必須 |
フィッシング耐性 | 提供が求められる | 必須 |
鍵のエクスポート | 許容 | 不可 |
再認証の間隔 | 24時間ごと、非活動1時間 | 12時間ごと、非活動15分 |
変更点2:同期可能なパスキーはAAL3では使えない
これが方式選択に直接効きます。SP 800-63B-4は、同期可能な認証器(syncable authenticators)をAAL3で用いてはならないと明記しています。理由は、クラウド同期のために秘密鍵がエクスポート可能である必要があるためです。
AAL2以下では許容され、付録に個別の要件が置かれています。
変更点3:パスワードの要求が変わった
パスワードを残す場合の要求も更新されました。
- 文字種の組み合わせを強制する構成規則を課してはならない
- 定期的な変更を要求してはならない(漏えいの証拠がある場合は変更を強制する)
- 最小長は、単独要素として用いる場合15文字以上、多要素の一要素として用いる場合8文字以上
- 漏えいデータベースや辞書語との照合(ブロックリスト)が必須
第1回で触れたPassword Sprayの標的になりやすい「複雑性要件を満たしつつ推測しやすいパスワード」は、まさに構成規則が生んでいたものです。この変更は、攻撃の実態を踏まえた修正といえます。
4. Passkeyの2つの形と使い分け
「パスキー」と一括りにされますが、実務上は2種類あります。
同期パスキー | デバイス束縛パスキー | |
|---|---|---|
秘密鍵の所在 | プラットフォームのクラウドに同期 | 1台の端末またはセキュリティキー内 |
端末を紛失したとき | 別端末で復元できる | 復元できない(再登録が必要) |
NISTのAAL | AAL2まで | AAL3に対応しうる |
向く用途 | 一般顧客向けチャネル、行内の一般業務 | 特権ID、基幹システム、行内の管理者作業 |
金融機関での現実的な方針は、2つを併用し、守るものの重要度で使い分けることになります。顧客向けチャネルでは同期パスキーで利便性と耐性を両立させ、特権IDや基幹システムの操作にはデバイス束縛型(FIDO2セキュリティキーや証明書ベース認証)を求める、という設計です。
5. 導入の論点 ― 最大の弱点はアカウント回復
パスキーを導入しても、次の3つを放置すると耐性は実現しません。
論点1:アカウント回復(最重要)
認証をどれだけ強くしても、「端末を紛失しました」という申告に対してSMSと生年月日で本人確認して再登録を許していれば、攻撃者はそこを通ります。回復経路の強度が、全体の強度を決めます。
対応としては、回復時に複数の要素を求める、対面や既存の強い認証器による確認を要求する、回復直後は取引制限をかけるといった設計が考えられます。認証方式の選定と同じ熱量で設計すべき箇所です。
論点2:レガシー認証経路の遮断
新しい認証を有効にしても、古いプロトコルや例外ルートが生きていれば、攻撃者はそちらを使います。IMAP/POP等の基本認証、パスワードのみで通る管理用インターフェース、条件付きアクセスの除外リスト。導入と同じ計画の中で、旧経路の停止を工程として置く必要があります。
論点3:段階導入の順序
全社一斉は現実的ではありません。効果の大きい順に進めます。
- 特権ID・管理者アカウント(影響が最大で、対象者数が少なく、教育もしやすい)
- 基幹システム・機微データへのアクセス
- 一般業務利用者
- 顧客向けチャネル(利便性とサポート体制の準備が必要)
導入設計チェックリスト(10項目)
- 守る対象ごとに求めるAALを決めたか
- AAL3相当が必要な領域を特定したか(同期パスキーでは満たせない)
- 同期パスキーとデバイス束縛型の使い分けを方針化したか
- アカウント回復経路の強度を、認証本体と同じ基準で設計したか
- 回復直後の取引制限・監視強化を設けたか
- レガシー認証・例外経路の棚卸しと停止計画を作ったか
- 条件付きアクセスの除外リストを定期的に見直す仕組みがあるか
- パスワードを残す領域で、構成規則の撤廃とブロックリスト照合に移行したか
- 認証方法のダウングレードを検知できるか(第1回の着眼点3)
- 特権IDから順に段階導入する計画になっているか
まとめ
フィッシング耐性のある認証の価値は、「強い」ことではなく人間の判断に依存しないことにあります。利用者が騙されても成立しない仕組みだからこそ、教育では埋まらない差が生まれます。
ただし、認証の入口を固めても、侵入後に残る権限の経路は別の問題です。次回は、Active DirectoryとEntra IDを中心としたAttack Pathの可視化と、ITDR・PAMによる制御点の設計を扱います。
主要出典
- NIST SP 800-63B-4「Digital Identity Guidelines: Authentication and Authenticator Management」(2025年8月26日)
- NIST SP 800-63-4「Digital Identity Guidelines」(2025年8月26日)
- MITRE ATT&CK「T1621 Multi-Factor Authentication Request Generation」
- MITRE ATT&CK「T1550 Use Alternate Authentication Material」
- 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」(2024年10月、2025年7月一部改正)
本記事は公開情報に基づく一般的な解説です。標準の更新に応じて定期的に見直します。なお、再認証間隔などの具体値は原典の規定をご確認ください。
