はじめに:MFA導入だけで認証対策は十分なのか
ゼロトラストの考え方が広がる中、多くの企業で多要素認証(MFA)の導入が進んでいます。しかし、「MFAを導入している」という事実だけでは、十分な認証強度を確保できているとは限りません。
例えば、SMS認証、認証アプリによるワンタイムパスワード(OTP)、メールコード、プッシュ通知、FIDO2/WebAuthn、クライアント証明書はいずれも認証方式として利用されていますが、攻撃に対する耐性は同じではありません。
近年は、認証情報を盗み出すだけではなく、認証処理そのものを中継するAiTM(Adversary-in-the-Middle)攻撃などによって、従来型のMFAが回避されるケースも確認されています。そのため、「MFAだから安全」と考えるだけでは十分とは言えません。
ゼロトラストでは、「一度認証したから信頼する」のではなく、「誰が」「どの端末から」「何にアクセスし」「どのような操作を行うのか」を継続的に評価し、それに応じた認証強度を求めることが重要です。
この考え方を整理するうえで参考になるのが、NISTの公式ページで2025年に公開された正式版 NIST SP 800-63B-4(Digital Identity Guidelines: Authentication and Authenticator Management)です。同ガイドラインでは、認証強度を評価する指標として Authentication Assurance Level(AAL)が定義されています。
AALは単なる「MFAを導入しているか」を判断するためのものではありません。ゼロトラスト時代の認証設計において、「そのアクセスに対して十分な認証強度を求めているか」を考えるための実践的な物差しと言えます。
AALとは何か
AAL(Authentication Assurance Level)は、認証トランザクション全体の信頼性・強度を3段階で評価する考え方です。認証プロセスが、対象となるアクセスに対して必要な強度を満たしているかを判断するために利用されます。
重要なのは、AALが単純に「パスワード認証か」「MFAか」を区別するものではないということです。
認証強度は、次のような要素を総合的に評価して決まります。
- 利用する認証要素(知識・所持・生体)
- 認証器(Authenticator)の種類
- 公開鍵暗号の利用有無
- フィッシング耐性
- リプレイ攻撃への耐性
- Authentication Intent(本人が認証操作を意図して行ったことの確認)
- 認証鍵の保護方法(非エクスポート可能か)
- 再認証(Reauthentication)の条件
- セッション管理
つまり、AALは「認証方式」ではなく、「認証プロセス全体の品質」を評価するための指標です。
AAL1・AAL2・AAL3の違い
|
AAL |
認証強度 |
主な要件 |
フィッシング耐性 |
利用イメージ |
|
AAL1 |
基本 |
単要素または多要素認証を許容。パスワード、OTP、アウトオブバンド認証、暗号認証器などを利用可能。MFAの提供は推奨。 |
必須ではない |
一般的な低リスクサービス |
|
AAL2 |
高 |
2つの異なる認証要素、または多要素認証器が必要。少なくとも1つのフィッシング耐性認証オプションを提供する必要がある。 |
少なくとも1つのフィッシング耐性認証オプションの提供が必要 |
業務システム、クラウドサービス |
|
AAL3 |
非常に高 |
公開鍵暗号ベース、フィッシング耐性、非エクスポート可能な秘密鍵、2要素、リプレイ耐性、Authentication Intentが必要。 |
必須 |
特権管理、高リスク操作 |
AAL1
AAL1は基本的な認証レベルです。パスワード認証だけでなく、OTPや暗号認証器など幅広い認証方式が利用できます。また、多要素認証も利用可能ですが必須ではありません。NISTでは、AAL1であってもMFAを提供し、利用を促進することを推奨しています。
AAL2
AAL2では、2つの異なる認証要素、または多要素認証器による認証が必要です。
さらに、SP 800-63B-4では、少なくとも1つのフィッシング耐性を備えた認証オプションを提供することが求められています。
ここで重要なのは、「AAL2のすべての認証が常にフィッシング耐性認証でなければならない」という意味ではないことです。利用者やアクセス条件に応じて、フィッシング耐性を備えた認証方式を選択できる状態にしておくことが要求されています。
AAL3
AAL3は最も高い認証レベルです。
公開鍵暗号を利用した認証に加え、以下の条件が求められます。
-
フィッシング耐性
-
非エクスポート可能な秘密鍵
-
2要素認証
-
Authentication Intent
-
リプレイ耐性
想定される用途は、管理者権限の利用、重要インフラ、機密情報へのアクセス、重要な承認処理、重要設定の変更など、高リスクな操作です。
重要なのは「MFAかどうか」ではなく
「フィッシング耐性があるか」
ゼロトラスト時代の認証設計を考える上で、重要なポイントは、「MFAかどうか」ではなく「フィッシング耐性があるか」です。
一般的には、以下のような認証方式はいずれもMFAとして扱われます。
-
SMS認証
-
メールコード
-
認証アプリによるOTP
-
プッシュ通知
しかし、NIST SP 800-63B-4では、これらは原則としてフィッシング耐性を持つ認証方式とは見なされません。
その理由は、認証コードや認証結果が正規の認証先や認証セッションに暗号学的に紐付いていないためです。
例えばAiTM攻撃では、利用者は偽サイトにOTPを入力します。攻撃者はその値をリアルタイムで正規サイトへ転送することで認証を突破できます。
OTP自体は正しい利用者が生成していますが、「どの認証先に対して認証したのか」は保証されません。
NISTでは、このような攻撃を防ぐためにPhishing Resistance(フィッシング耐性)を重視しています。
フィッシング耐性を備えた認証では、認証結果が認証先(Verifier:認証要求を検証するシステム)や通信チャネルに暗号技術によって安全に結び付けられます。
そのため、攻撃者が認証処理を中継したとしても、その認証結果を別のサイトでは利用できません。
代表例として挙げられるのが、以下のような認証方式です。
-
FIDO2 / WebAuthn
-
クライアント証明書を利用した認証
ただし、これらを利用していれば自動的にNISTの要件を満たすわけではありません。認証結果が認証先(Verifier)や通信チャネルに暗号学的に紐付いているか、認証鍵の保護方法、Authentication Intentを満たしているかなど、実装構成まで含めて確認する必要があります。
つまり、ゼロトラスト時代に重要なのは、「MFAを導入しているか」ではなく、「攻撃者がその認証を悪用できない仕組みになっているか」を確認することです。
ゼロトラストとAALの関係
ゼロトラストでは、すべてのアクセスを同じ認証方式で保護するという考え方ではありません。
重要なのは、アクセス先、操作内容、利用者の権限、端末の状態、アクセス元ネットワーク、検知されたリスクなどを踏まえ、そのアクセスに見合った認証強度を要求することです。
例えば、社内ポータルへのアクセスと、Active Directoryの設定変更では求められる認証強度は異なります。また、同じ利用者であっても、通常業務と特権操作では必要な認証レベルは変わります。
その判断基準として活用できるのがAALです。一例として、次のような考え方が挙げられます。
|
利用シーン |
推奨される認証強度の考え方 |
|
一般的な業務システム |
AAL2相当 |
|
Microsoft 365や各種SaaS |
AAL2相当(可能であればフィッシング耐性認証を利用) |
|
管理者アカウント |
フィッシング耐性を備えたAAL2以上 |
|
サーバー・ネットワーク機器の管理 |
フィッシング耐性を備えたAAL2以上 |
|
機密データ閲覧・設定変更・決済処理 |
フィッシング耐性を備えたAAL2以上 |
|
特に高リスクな操作 |
AAL3相当を検討 |
また、すべての操作で最高レベルの認証を要求する必要はありません。
例えば、通常業務ではAAL2相当で認証し、管理画面へのアクセスや重要な設定変更を行う際だけ追加認証を求める「ステップアップ認証」を組み合わせることで、セキュリティと利便性のバランスを取りやすくなります。
ゼロトラストにおける認証設計では、「MFAを導入しているか」ではなく、「そのアクセスに対して十分な認証強度を求めているか」を確認する必要があります。AALは、その判断を行うための実践的な基準として活用できます。
パスワードポリシーも見直しが必要
本ブログの主題はAALですが、NIST SP 800-63B-4ではパスワードに関する考え方も整理されています。
従来は、これらのポリシーが広く採用されてきました。
-
英大文字・小文字・数字・記号をすべて含める
-
90日ごとに定期変更する
-
過去に利用したパスワードを使えなくする
しかし現在では、このようなルールだけでは十分な効果が得られず、利用者が推測しやすいパターンを繰り返す原因になることも指摘されています。
NISTが重視しているのは、次のような考え方です。
-
単要素認証で利用するパスワードは最低15文字
-
MFAの一部として利用する場合は最低8文字
-
漏えい済み・一般的・推測しやすいパスワードをブロックリストで拒否する
-
レート制限を実装する
-
パスワードマネージャーの利用を妨げない
-
定期変更は要求しない(漏えいが確認された場合を除く)
-
複雑性ルールを要求しない
つまり、パスワードそのものを複雑にすることよりも、長さを確保し、漏えい済みパスワードを排除し、MFAと組み合わせることが重視されています。
実務で確認すべきチェックポイント
ゼロトラストにおける認証設計を見直す際は、次の観点を確認すると整理しやすくなります。
| MFA方式がSMS、メールコード、OTP、単純なプッシュ通知だけに依存していないか |
| 管理者アカウントや重要システムに、FIDO2やクライアント証明書などフィッシング耐性を持つ認証方式を適用できているか |
| 一般ユーザーと管理者で同じ認証強度になっていないか |
| 重要操作時にステップアップ認証や再認証を求めているか |
| セッションタイムアウトや再認証タイミングが長すぎないか |
| パスワードポリシーが複雑性ルールや定期変更だけに依存していないか |
| 生体認証を単独の認証器として扱っていないか |
| パスワードリセット、MFA再登録、アカウント復旧の手順が、本来の認証よりも弱くなっていないか |
| ヘルプデスク対応やメール認証だけで、管理者アカウントや重要アカウントの復旧が可能になっていないか |
| アカウント復旧時にも、対象アカウントのリスクに応じた本人確認・通知・追加認証を求めているか |
特にアカウント復旧は、認証設計の抜け道になりやすい領域です。通常のログインを強化していても、復旧経路の認証強度が低ければ、攻撃者はそこを狙います。
認証方式だけでなく、パスワードリセット、MFA再登録、ヘルプデスクによる本人確認まで含めて、同じ基準で設計・評価することが重要です。
まとめ
MFAはゼロトラストを実現するための重要な要素ですが、「MFAを導入している」という事実だけでは十分とは言えません。
同じMFAでも、SMSやOTPとFIDO2/WebAuthnでは、フィッシング攻撃への耐性が大きく異なります。重要なのは、認証方式の名称ではなく、その認証が実際の攻撃にどこまで耐えられるかです。
NIST SP 800-63B-4で定義されるAALは、認証要素の数だけではなく、フィッシング耐性、公開鍵暗号の利用、Authentication Intent、鍵の保護、再認証、セッション管理などを含めて認証強度を評価する考え方です。
ゼロトラストにおける認証設計では、「MFAを導入しているか」ではなく、「そのアクセスに対して十分な認証強度を求めているか」を確認する必要があります。AALは、その判断を行うための実践的な基準として活用できます。
認証方式を見直す際には、「どの認証を導入するか」だけではなく、「どのアクセスに、どの認証強度を求めるべきか」という観点で設計を進めることが、これからのゼロトラスト時代には欠かせません。
「MFAは導入しているが認証強度として十分なのか分からない」「管理者アカウントやActive Directoryの認証を強化したい」「ゼロトラストを進めたいが、認証だけでなくネットワークも含めて何から着手すべきか整理したい」など、お悩みがありましたらお気軽にご相談ください。
当社では、認証・IDセキュリティの強化に加え、ネットワークインフラを含めたゼロトラストアーキテクチャの実現まで、お客様の環境や課題に応じて幅広くご支援しています。
また、本ブログの内容に関連する資料もご用意しています。認証方式の見直しや、既存環境を活かしたMFA適用を検討される際にご活用ください。

特に、長らく多くの組織で課題の1つとされてきたオンプレミスのActive Directory認証強化についても、弊社より具体的な構成や導入ステップをご紹介できます。
AD認証へのMFA適用や、既存環境を活かした認証強化をご検討中の方は、ぜひお気軽にお問い合わせください。
- トピック:
- セキュリティ対策機器
- サイバー攻撃
- ネットワーク
- IT資産/データ
- Silverfort








