パスワードだけでアカウントを守る時代は終わった。2025年に発生した国内外の主要インシデントを分析すると、侵害されたアカウントの8割以上でMFA（多要素認証）が設定されていなかったか、フィッシングに無力なSMS認証のみが適用されていたことが判明している。
多要素認証は「導入すれば終わり」ではない。どの方式を選ぶか、どのサービスに優先的に適用するか、AiTM攻撃のような高度な回避手法にどう対処するか――こうした判断を誤ると、MFAを導入していても侵害を防げない。
本記事では、MFAの基礎から最新の脅威への対処法まで、企業のセキュリティ担当者が実務で使える知識を体系的に整理する。
なぜMFAが必須か――パスワードだけでは防げない理由
パスワードはすでに信頼できない認証手段
2026年時点で、サイバー攻撃の侵入起点として最も多く報告されているのが認証情報の窃取と悪用だ。その背景には複数の構造的な問題がある。
クレデンシャルスタッフィング攻撃の常態化
過去十数年に発生したデータ侵害によって、数十億件のIDとパスワードの組み合わせがダークウェブ上で流通している。攻撃者はこれらのリストを自動化ツールに入力し、標的サービスに対して大量のログイン試行を実施する。ユーザーが複数のサービスで同じパスワードを使い回していれば、一つのサービスの漏洩が連鎖的に他のサービスへの不正アクセスを引き起こす。
フィッシングによる直接窃取
生成AIの普及により、日本語として自然なフィッシングメールを大量生成するコストが劇的に下がった。IPA（情報処理推進機構）の2026年版「情報セキュリティ10大脅威」においても、フィッシングを起点とした認証情報窃取は上位に位置し続けている。巧妙に作られた偽サイトに誘導されたユーザーが、正規サイトと見分けがつかないまま認証情報を入力してしまう事例が増加している。
パスワードの管理限界
人間が記憶できるパスワードの数には限界がある。推奨される「サービスごとに異なる複雑なパスワードを使う」という原則を守り続けられるユーザーは少なく、結果としてパスワードの使い回しや単純なパターン（企業名＋年度＋記号など）が蔓延している。攻撃者はこのパターンを熟知しており、辞書攻撃やルールベースの攻撃で効率的にパスワードを推測する。
2026年の国内インシデント動向
2025年から2026年にかけて国内で発生したサイバーセキュリティインシデントのうち、クラウドサービスへの不正アクセスを原因とする情報漏洩事案の約75%で、MFAが未設定または設定が不完全だったことが複数の調査報告で指摘されている。特に中堅・中小企業においては、Microsoft 365やGoogle Workspaceの管理者アカウントがMFAなしで運用されているケースが依然として多い。
MFAを適切に設定した環境では、認証情報が漏洩した場合でも不正ログインの99.9%以上をブロックできるというMicrosoft社の統計は広く知られている。しかし「MFAを入れているから安全」という過信が、次節で説明するAiTM攻撃への無防備につながっている点にも注意が必要だ。
MFAの種類と強度比較
MFAには複数の方式があり、それぞれ利便性・強度・コスト・フィッシング耐性が異なる。自社の要件に合った方式を選択するためには、各方式の特性を正確に理解する必要がある。
MFA方式の比較表
方式 | 認証の仕組み | フィッシング耐性 | 利便性 | 導入コスト | 主な用途 |
|---|---|---|---|---|---|
SMS／音声認証 | 登録した電話番号にワンタイムパスワードを送信 | 低（傍受・SIMスワップに脆弱） | 高（デバイス不要） | 低 | 一般消費者向け、社外ユーザー対応 |
TOTP（認証アプリ） | 30秒ごとに変わるワンタイムパスワードをアプリで生成 | 中（フィッシングサイトへの入力は防げない） | 中（アプリが必要） | 低 | 業務アカウント全般 |
プッシュ通知型 | スマートフォンアプリへのプッシュ通知で承認 | 中（疲労攻撃に注意） | 高（ワンタップ） | 低〜中 | Microsoft Authenticator等との連携 |
FIDO2／WebAuthn | デバイスの生体認証や専用キーで秘密鍵認証 | 高（オリジンに紐付くためフィッシング不可） | 高（生体認証で完結） | 中 | 特権アカウント、ハイリスク操作 |
ハードウェアセキュリティキー | 物理デバイス（YubiKey等）による認証 | 最高（フィッシング完全耐性） | 中（デバイス携帯が必要） | 中〜高 | 特権アカウント、金融・医療・政府機関 |
パスキー（Passkey） | FIDO2ベースでプラットフォーム統合 | 高 | 最高（OS標準対応） | 低（ソフトウェアのみ） | 全社展開の将来標準 |
証明書ベース認証（CBA） | PKIクライアント証明書による認証 | 最高 | 低（証明書管理が複雑） | 高 | エンタープライズ環境、行政 |
各方式の詳細
SMS・音声認証
最も普及しているMFA方式だが、セキュリティ強度は最も低い。主要なリスクは以下のとおりだ。
- SIMスワッピング攻撃：攻撃者が携帯キャリアを騙して電話番号を別のSIMカードに移管させ、SMSを傍受する
- SS7プロトコルの脆弱性：電話網の基幹プロトコルの設計上の弱点を突いてSMSを傍受する
- AiTM攻撃との組み合わせ：フィッシングサイトがリアルタイムでSMSコードを中継し、正規サービスへのログインに利用する
国際電気通信連合（ITU）や米国国立標準技術研究所（NIST）は、SMS認証を単独の認証手段として使用することを推奨しない立場を示している。既存環境でSMS認証しか設定できない場合でも、より強固な方式への移行計画を立てるべきだ。
TOTP（認証アプリ）
Google Authenticator、Microsoft Authenticator、Authyなどのアプリが生成する6桁のコードを使う方式。秘密鍵はデバイス内に保存されるため、SMS認証よりも傍受リスクは低い。ただし、AiTM攻撃のようにリアルタイムでコードを中継する攻撃には無力であるという本質的な限界がある。
プッシュ通知型（Number Matching対応）
Microsoft Authenticatorに代表されるプッシュ承認型は使いやすい一方、「MFA疲労攻撃（MFA Fatigue Attack）」の標的になりやすい。攻撃者が繰り返し認証要求を送り続け、ユーザーが誤ってまたは煩わしさから承認してしまう手法だ。対策として、Number Matching機能（ログイン画面に表示された番号と一致する数字をアプリで選ぶ）を有効化することが必須となっている。
FIDO2・WebAuthn
FIDO2はパスワードを使わない認証標準であり、デバイス内の秘密鍵と公開鍵のペアで認証する。秘密鍵はデバイスから外部に出ることがなく、認証はアクセス先のオリジン（ドメイン）に紐付く。そのため、偽ドメインのフィッシングサイトでは認証が成立しない構造になっている。これが「フィッシング耐性MFA」と呼ばれる理由だ。Windows Hello、Apple Face ID/Touch ID、YubiKeyなどがFIDO2認証器として利用できる。
ハードウェアセキュリティキー
YubiKeyに代表されるUSB・NFC対応の物理デバイスで認証する方式。FIDO2の最高水準の実装であり、特権アカウントや機密システムへのアクセスに適している。デバイスを持ち歩く必要があり、紛失時の運用対応が課題となるが、セキュリティ強度は現存する認証方式の中で最も高い。
AiTM攻撃とフィッシング耐性MFAとは
MFAをバイパスする「AiTM攻撃」
Adversary-in-the-Middle（AiTM）攻撃は、フィッシングサイトが本物のサービスとユーザーの間にリバースプロキシとして介在する攻撃手法だ。ユーザーは偽サイトにIDとパスワードを入力するが、偽サイトはその情報をリアルタイムで本物のサービスに転送する。サービス側がMFAコードの入力を求めると、偽サイトはそれもユーザーに要求し、受け取ったコードをそのまま転送する。
結果として、ユーザーが正常にMFAを完了したと思った瞬間に、攻撃者のセッションが認証されてしまう。SMS認証・TOTP認証アプリ・プッシュ通知型のいずれも、このリアルタイム中継型の攻撃には無力だ。
Microsoft 365を狙ったAiTMフィッシングキット（Evilginx2、Modlishkaなど）はサイバー犯罪者向けにサービス化されており、高度な技術知識がなくても利用できる状態になっている。2025年以降、国内でもAiTMを使ったMicrosoft 365アカウントの侵害事例が複数報告されている。
フィッシング耐性MFA（Phishing-Resistant MFA）
AiTM攻撃に対抗できる唯一の手段が、フィッシング耐性MFAだ。具体的には以下の方式が該当する。
- FIDO2・WebAuthn（パスキーを含む）
- 証明書ベース認証（CBA）
これらの方式は、認証がアクセス先のドメインに暗号的に紐付いているため、偽ドメインのフィッシングサイトでは認証が完結しない。攻撃者がセッショントークンを盗もうとしても、認証器がそのドメインを正規と判断しないため、秘密鍵による署名が行われない。
米国政府（CISA）は2022年以降、政府機関および重要インフラに対してフィッシング耐性MFAへの移行を義務化している。日本においても、金融庁・総務省のガイドラインでフィッシング耐性MFAへの言及が増えており、特に金融機関・医療機関・重要インフラ事業者はこの水準への移行を計画すべき段階にある。
導入優先順位の考え方
MFAをすべてのアカウント・サービスに一度に展開することは現実的でない。リスクの高いアカウントから段階的に適用することが実務上の正しいアプローチだ。
優先度：最高（即時対応）
特権アカウント
グローバル管理者、セキュリティ管理者、課金管理者など、テナント全体に影響を与える権限を持つアカウントは最優先でMFAを適用する。これらのアカウントが侵害された場合の影響範囲は組織全体に及ぶ。フィッシング耐性MFA（FIDO2またはCBA）の適用が推奨される。
リモートアクセス起点
VPN、リモートデスクトップ（RDP）、ジャンプサーバーへのアクセスはMFAなしでは論外だ。リモートアクセスは外部ネットワークからの直接接触点であり、攻撃者が最初に狙う入口となる。
優先度：高（3ヶ月以内）
全従業員のクラウドサービスアカウント
Microsoft 365、Google Workspace、Salesforce、BoxなどのSaaSサービスは業務の中核を担い、機密情報が集中している。全従業員に対してMFAを適用する。既存環境での急速な展開ではTOTPまたはプッシュ通知型から始め、段階的にFIDO2へ移行するロードマップが現実的だ。
クラウドインフラの管理コンソール
AWS Management Console、Azureポータル、Google Cloud Consoleは、インフラ全体への影響力を持つ。特に本番環境へのアクセス権を持つIAMユーザー・ロールにはMFAを強制する。
優先度：中（6ヶ月以内）
開発者・エンジニアのツールチェーン
GitHubやAzure DevOpsなどのソースコード管理サービスへのアクセスにMFAを適用する。ソースコードの改ざんやサプライチェーン攻撃の起点となり得るためだ。
その他のSaaSアプリケーション
業務で使用する全SaaSアプリケーションをインベントリ化し、MFA対応状況を確認した上で順次展開する。シングルサインオン（SSO）を活用することで、個々のSaaSにMFAを設定するのではなく、IdP（Identity Provider）レベルで一元管理できる。
主要サービスへの設定ポイント
Microsoft 365（Entra ID）
条件付きアクセスポリシーによるMFA強制
Microsoft 365でのMFA適用は、セキュリティの既定値群（Security Defaults）ではなく、条件付きアクセスポリシーで管理することを強く推奨する。理由は、条件付きアクセスの方が細かい制御が可能で、特定のリスク条件（新しい場所からのアクセス・レガシー認証ブロックなど）に応じた動的な認証強化が実現できるからだ。
設定手順の概要は以下のとおりだ。
- Microsoft Entra管理センターにグローバル管理者でサインインする
- 「保護」→「条件付きアクセス」→「新しいポリシー」を選択する
- 対象ユーザー（全ユーザーまたはグループ指定）とクラウドアプリ（Microsoft 365全体）を設定する
- 「アクセスの許可」でMFAを要求するよう設定する
- Number Matchingを有効化するため、「認証方法」ポリシーでMicrosoft Authenticatorのプッシュ通知設定を調整する
フィッシング耐性MFAの適用
特権ロールを持つユーザーには、条件付きアクセスで「認証強度」をFIDO2セキュリティキーまたはWindows Helloのみに制限する設定を追加する。これにより、TOTP等の弱いMFAでは特権操作を実行できない環境が実現できる。
レガシー認証プロトコルのブロック
SMTP AUTH、POP3、IMAP4などのレガシープロトコルはMFAをバイパスできる。条件付きアクセスで「その他のクライアント」をターゲットにブロックするポリシーを設定し、Modern Authenticationのみを許可する。
AWS（Amazon Web Services）
ルートアカウントのMFA
AWSのルートアカウントはすべての権限を持つため、MFAの設定は絶対条件だ。AWS管理コンソールで「セキュリティ認証情報」からMFAデバイスを登録する。可能であれば、ルートアカウントへの通常アクセスそのものを禁止し、MFAデバイスはハードウェアキーを使用することを推奨する。
IAMユーザーへのMFA強制
IAMポリシーを使って、MFAが未設定のユーザーが実行できる操作を自分のMFA設定のみに制限する条件付きポリシーを適用する。代表的な実装として、aws:MultiFactorAuthPresent条件キーを使ったDeny文がある。
` Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } } `
このDeny文を含むポリシーを全IAMユーザーにアタッチすることで、MFA認証なしのAPIコール・コンソール操作をすべて拒否できる。
Organizations SCP（サービスコントロールポリシー）の活用
AWS Organizationsを使用している場合、SCPでMFA未設定のユーザーによる重要操作を組織全体でブロックする設定が有効だ。
VPN・リモートアクセス
RADIUSとIdPの統合
企業VPNにMFAを適用する最も一般的な方法は、RADIUSサーバーを経由してMicrosoft Entra ID、Okta、Duo SecurityなどのIdPと連携する構成だ。ユーザーがVPN接続を試みると、IdPがMFA認証を要求し、完了後にVPN接続が確立される。
対応製品の確認
Cisco ASA、Palo Alto GlobalProtect、Fortinet FortiClientなどの主要VPN製品はSAMLやRADIUSを通じたMFA連携をサポートしている。自社VPN製品のドキュメントで対応する認証方式を確認した上で連携設計を行う。
リスクベース認証の検討
ゼロトラストアーキテクチャへの移行を視野に入れる場合、VPNのMFAに加えてデバイスコンプライアンス（最新OSパッチ適用済みか、MDM管理下か）をアクセス条件に組み込むことで、より厚い防御が実現できる。
運用・ヘルプデスク対応のポイント
MFAは導入後の運用設計が重要だ。ユーザーからの問い合わせへの対応方針が曖昧だと、ソーシャルエンジニアリングの抜け穴になり得る。
バックアップ認証手段の整備
スマートフォンを紛失した・機種変更したなどの理由でMFAが使えなくなるケースは必ず発生する。以下の対策を事前に設計する。
複数の認証方法の登録
Microsoft 365であれば、TOTP認証アプリとバックアップコードを両方登録させる。または認証アプリに加えてFIDO2キーを登録しておくことで、一方が使えなくなっても認証できる。
テンポラリアクセスパス（TAP）
Microsoft Entra IDのテンポラリアクセスパス機能を活用すると、管理者が時間制限付きの一時的な認証バイパス（TAP）を発行できる。ユーザーはこのTAPを使って新しい認証方法を登録する。ヘルプデスクが電話やチャットで「MFAを外してほしい」と言われた場合に即座に対応するのではなく、本人確認の上でTAPを発行する手順を標準化しておくことが重要だ。
ヘルプデスクを狙ったソーシャルエンジニアリング対策
2023年以降、ヘルプデスク担当者を騙してMFAのリセットをさせるソーシャルエンジニアリング攻撃が増加している。MGM Resortへの攻撃（2023年）はヘルプデスクを起点にMFAリセットが行われたことで知られている。
ヘルプデスク対応の標準手順として以下を設ける。
- MFAリセット要求に対しては、必ず管理者承認のワークフローを通す
- 本人確認は電話音声だけでなく、社員番号・所属部署・上長名などの複数情報で確認する
- 特権アカウントのMFAリセット要求は、本人と上長の双方への確認を必須とする
- MFAリセットのログを監視アラートに組み込み、不審なパターン（短時間での複数リセット等）を検知する
MFA疲労攻撃への対応手順
ユーザーに対して「見覚えのないMFA認証要求が来た場合は絶対に承認しない」「不審な場合は即座にセキュリティ担当に報告する」という教育を徹底する。また、ユーザーが承認しないまま多数の認証要求が届いた際に、自動的にアカウントを一時ロックする設定をMicrosoft Entra IDのサインインリスクポリシーで実装することも有効だ。
パスキーへの移行ロードマップ
パスキー（Passkey）とは
パスキーはFIDO2標準に基づいたパスワードレス認証技術で、AppleのiCloud Keychain、GoogleのパスワードマネージャーなどのOSプラットフォームに組み込まれている。ユーザーがウェブサービスにログインする際、デバイスの生体認証（Face IDや指紋認証）で確認するだけでフィッシング耐性のある認証が完了する。
従来のFIDO2/WebAuthnとの違いは、デバイス間の同期に対応している点だ。ハードウェアセキュリティキーのように物理デバイスを持ち歩く必要がなく、iCloudやGoogleアカウントを通じてパスキーが複数デバイスに同期されるため、デバイス紛失時の復旧も容易になった。
移行ステップ
パスキーへの段階的な移行は以下の順序で進めることが現実的だ。
Phase 1：現状棚卸しと目標設定（0〜1ヶ月）
現在使用しているMFA方式の全体像を把握する。サービスごとにパスキー対応状況を確認し、対応済みのサービスから移行対象を特定する。Microsoft 365、Google Workspace、GitHub、AWSコンソールはいずれもパスキー対応済みだ。
Phase 2：パイロット導入（1〜3ヶ月）
ITスタッフや社内ヘビーユーザーを対象に、Microsoft 365とGitHubへのパスキー登録をパイロット的に実施する。社内デバイスの生体認証（Windows Hello、Face IDなど）を有効化し、パスキー登録の手順をヘルプデスクが案内できる状態にする。
Phase 3：特権アカウントへの適用（3〜6ヶ月）
管理者・特権ユーザーのアカウントに対して、パスキーまたはFIDO2ハードウェアキーをプライマリ認証手段として設定する。条件付きアクセスで特権操作に際してフィッシング耐性MFAのみを許可するポリシーを適用する。
Phase 4：全社展開（6〜12ヶ月）
全社員に対してパスキー登録を案内し、パスワード＋TOTP認証からパスキー認証への移行を促進する。移行完了後、古いTOTP認証を削除しパスワードレス環境への移行を進める。移行期間中はSMS認証など弱い方式を段階的に廃止するタイムラインも合わせて策定する。
移行時の注意点
- レガシーシステムとの互換性確認：パスキーに対応していないシステムが残る場合は、そのシステム専用の認証方針を別途設計する
- MDM（モバイルデバイス管理）との連携：会社管理デバイスにのみパスキーを登録させるポリシーを検討する。個人デバイスへの登録を許可する場合はデータ分離の観点でポリシーを整備する
- バックアップコードの管理：パスキー移行後も一定期間はバックアップ認証手段を残しておき、移行過程でのロックアウトリスクを低減する
AEVUSのMFA導入支援
MFAの導入は、技術的な設定作業だけでなく、組織全体の認証アーキテクチャの見直しと従業員への浸透が不可欠だ。「とりあえずMFAを入れた」という状態では、AiTM攻撃やヘルプデスクを狙ったソーシャルエンジニアリングに対応できない。
AEVUSでは、MFA導入・強化を含む認証セキュリティ全般の支援を提供している。
現状評価・ギャップ分析
既存のMFA設定状況を棚卸しし、フィッシング耐性の観点からのリスクを評価する。SMS認証・TOTPが残る環境における攻撃リスクの定量化と、優先度付きの改善ロードマップを提示する。
導入設計・実装支援
Microsoft Entra ID・AWS IAM・各SaaSサービスへのMFA設定、条件付きアクセスポリシー設計、レガシー認証ブロックの実装支援を行う。FIDO2・パスキー移行の技術設計とヘルプデスク運用フローの整備も対応する。
ペネトレーションテストによる検証
MFA設定完了後に、AiTMフィッシングシミュレーション・MFA疲労攻撃・ソーシャルエンジニアリングを含む実践的なペネトレーションテストを実施し、設定の実効性を第三者の視点で検証する。
認証セキュリティの強化やMFA導入に課題をお持ちの場合は、AEVUSにご相談ください。自社のリスク状況に応じた具体的な改善策をご提案します。
本記事は2026年6月時点の情報をもとに作成しています。各サービスの設定画面・機能は更新される場合があります。
