MFA未適用アカウントはなぜ危険か？アスクル事例で見る例外運用の入口

MFA未適用アカウントが危険な理由

例外アカウントは、強い認証の前提を一気に崩します

MFA未適用アカウントが危険なのは、「1 個くらい例外があっても大丈夫そう」に見えやすいからです。ですが実務では、例外アカウントほど管理者権限、委託先接続、夜間作業、共有 ID、古い運用と結び付きやすく、事故が起きたときの影響が大きくなります。通常の従業員アカウントなら SSO や標準ポリシーに乗っていても、例外運用だけが別管理のまま残りやすいからです。

しかも例外アカウントは、日常の棚卸しから漏れやすい傾向があります。委託先が使う臨時アカウント、ベンダー保守用アカウント、共有の管理者 ID、緊急用の停止回避アカウントなどは、「今も使っているのか」「誰が責任者か」「最後に確認したのはいつか」が曖昧なまま残りやすく、強制適用の外側に置かれがちです。そこが事故の入口になります。

アスクル事例で見えるのは、認証統制の是正が応急対応だったことです

アスクル事例の整理記事でも触れているとおり、アスクルのセキュリティページ↗では、2025年10月22日に外部クラウドサービスへの不正アクセスが発生し、10月24日までに認証情報のリセット、管理アカウントへの MFA 適用、EDR シグネチャ更新を完了したと示されています。この記事で言いたいのは、「原因は必ず MFA 不足だった」と断定することではありません。公式公表がそこまで言っていないからです。

ただし、応急対応の中に管理アカウントへの MFA 適用が入っている以上、認証統制が重要な是正対象だったことは読み取れます。つまり、事故対応の現場では「侵入口を塞ぐ」「認証情報を入れ替える」「高権限アカウントへ追加認証を入れる」が同時進行で必要になります。MFA未適用アカウントは、その一連の対応を難しくする代表例です。

主役はMFAの入門解説ではなく、例外運用の統制です

CISA のMore than a Password↗は、パスワード単独より MFA の方が安全だと整理していますが、現場で詰まるのは「MFA とは何か」ではなく、誰に適用できておらず、なぜ例外になっているかの方です。既に多くの組織は本番アカウントへ MFA を導入しています。それでも事故が起きるのは、例外アカウントの統制が弱いからです。

そのため本記事では、一般利用者向けの MFA 啓発よりも、委託先アカウント、管理者アカウント、共有 ID、リモートアクセス、休眠アカウントの棚卸しと是正を主役にします。ここを外すと、MFA の導入率が高く見えても実際の危険は下がりません。

最優先で棚卸ししたいアカウント

委託先アカウントは、通常の人事異動フローに乗らないことがあります

まず優先すべきなのは、委託先や保守ベンダーが使うアカウントです。これらは入社・異動・退職の標準フローに乗らず、契約更新や担当交代のたびに見直されるとも限りません。その結果、「今は別会社が使っている」「作業は終わったが残したまま」「共有メールで受けているので MFA 適用が後回し」といった例外が残ります。

特に危険なのは、委託先アカウントが高権限や外部接続と結び付いている場合です。サポート用ポータル、管理画面、クラウド基盤、監視画面、バックアップ、ファイル共有などへ入れるアカウントで MFA 例外が残ると、利用者数は少なくても影響範囲は大きい状態になります。

共有 ID と緊急用アカウントは、誰の責任かが曖昧になりやすいです

次に見落としやすいのが、共有の管理者 ID と緊急用アカウントです。共有 ID は運用上便利でも、誰が使ったのか、どの作業のためか、どの経路で認証したのかを追いにくくします。しかも「共有だから MFA を掛けづらい」「スマートフォンを紐付けにくい」という理由で、例外の温床になりがちです。

緊急用アカウントも同じで、「本番障害時にすぐ入れるように」という理由で MFA 未適用のまま残すと、本来は最後の安全弁であるはずのアカウントが最も危険な入口になります。残すなら、利用条件、保管責任、監査ログ、例外期限まで含めて定義しなければいけません。

外部接続と結び付くアカウントは、優先度を上げて扱うべきです

リモートアクセス、外部クラウド管理画面、保守用接続、障害対応用ポータルに入れるアカウントは、通常の社内アプリより優先度を上げて扱うべきです。CISA も MFA によって、リモートアクセス技術、メール、請求システムのような重要システムへの侵入を難しくできると整理しています。つまり、外から届く経路に近いアカウントほど、MFA 例外を残す余地を小さくすべきです。

ここは VPN 脆弱性やサーバ設定の問題だけに寄せず、接続先を扱える人の認証統制まで含めて見た方が実務に合います。接続点だけを直し、アカウント例外を放置すると、別の経路から同じような事故が起きやすくなります。

例外運用が危険に変わる典型パターン

最も多いのは、「例外の理由が消えたのに運用だけ残る」ことです

例外運用が危険になる典型は、一時的な事情が終わったのに、アカウントだけ残ることです。障害対応、ベンダー作業、移行期間、古いアプリ、共有運用など、例外の理由は最初はもっともらしく見えます。ですが、期限も責任者もなく残すと、数か月後には誰のための例外だったのか分からない状態になります。

これが危険なのは、技術的な弱さよりも運用の見えなさが増えるからです。標準ポリシーの外に出たアカウントは、棚卸しの対象から漏れ、パスワード更新も MFA 強制も遅れ、事故後の追跡も難しくなります。例外を許すなら、終わらせる条件まで最初に決める必要があります。

プッシュ通知だけに頼ると、誤承認と疲労攻撃に弱くなります

CISA は 2022年10月31日のアラート↗で、組織はフィッシング耐性のある MFA を強く優先し、それがすぐに難しい場合でもプッシュ型 MFA の疲労攻撃を緩和するために番号照合を使うべきだと整理しています。ここから分かるのは、「MFA を入れたか」だけではなく、どの方式で、どの例外を残しているかまで見ないと危険度は分からないということです。

特に委託先や管理者アカウントで、SMS や単純なプッシュ承認だけに頼る状態が続くと、運用負荷が軽い代わりに誤承認や疲労攻撃の余地が残ります。高権限アカウントほど、方式の強さまで含めて見直す必要があります。

休眠アカウントは『誰も使っていないから安全』ではありません

休眠アカウントは、「使っていないから今は問題ない」と放置されやすいですが、現実にはその逆です。使っていないアカウントは利用者本人が異変に気付きにくく、監査でも後回しになりやすく、侵害されても発見が遅れます。しかも高権限や委託先用途の休眠アカウントなら、被害はさらに大きくなります。

そのため、MFA 例外を減らす運用は「新しいアカウントに MFA を入れる」ことよりも、「不要になった例外を止める」「休眠アカウントを止める」ことから始めた方が効果が出やすいです。数を減らせば、それだけ強制対象を増やしやすくなります。

CISAの指針から見る是正の順番

まずは『MFA なし』をなくし、重要システムから順に強制します

CISA の MFA ページでは、MFA によってリモートアクセス技術、メール、請求システムのような重要システムへの侵入を難しくできると説明しています。これはそのまま実務の優先順位に落とせます。つまり、外部から届く、止まると困る、権限が強いシステムから順に、MFA 未適用をなくしていくべきです。

ここで大事なのは、全アカウントを一律に眺めないことです。まずは委託先、管理者、リモートアクセス、クラウド管理、共有 ID、緊急用アカウントの棚卸しを優先し、その中で MFA 未適用、方式が弱い、ログが薄い、責任者不明のものを上位に置く方が進めやすくなります。

最終目標はフィッシング耐性のある方式、移行期は番号照合です

CISA は「どんな MFA でもないよりはよい」としつつ、同時にフィッシング耐性のある MFA を目標にし、移行期は番号照合で疲労攻撃を抑えるという優先順を示しています。ここは現場で誤解されやすいところです。単に導入率を上げるだけでなく、強度の低い例外をどう減らしていくかまで考えなければいけません。

特に管理者や委託先アカウントでは、方式の違いがそのまま危険度の差になります。一般社員向けに暫定運用が残っていても、管理者や外部接続アカウントでは後回しにしない方が安全です。

是正は『導入率』より『例外削減率』で見る方が実務に合います

組織が MFA を導入済みでも事故が止まらない理由は、導入率の数字と実際の危険が一致しないからです。95% のアカウントに MFA が入っていても、残り 5% が委託先、管理者、共有 ID、休眠アカウントなら、危険は十分残ります。したがって現場では、全体導入率より、危険な例外をどれだけ減らせたかを追う方が意味があります。

具体的には、例外アカウント件数、管理者系の MFA 未適用件数、休眠アカウント停止件数、番号照合または強い方式への移行件数、責任者不明アカウントの解消件数などです。この見方に変えると、MFA が「入っているかどうか」から「危険な例外が減っているかどうか」へ議論を移せます。

委託先や外部接続の見直しならASM診断 PRO

ASM診断 PRO は ID ガバナンスや認証基盤の代替ではありません。ただし、MFA 例外を減らす運用では、アカウント台帳だけでなく外から見える公開面、管理画面、外部接続点、古い導線を合わせて見直す必要があります。委託先や保守接続の見直しでは、「契約上は把握しているが、今も公開されているか分からない」接点が残りやすいからです。

そのため、例外アカウントの是正と並行して、どのドメイン、サブドメイン、管理画面、公開ドキュメント、外部接続点が外から見えるかを確認できると、説明と是正をつなぎやすくなります。レポート雛形や台帳テンプレートと組み合わせると、認証統制と公開面整理を別々にせず進めやすくなります。

よくある質問（FAQ）

MFA未適用アカウントは、数が少なければ後回しでもよいですか？

いいえ。数よりも権限と接続先を見るべきです。少数でも、委託先、管理者、共有 ID、リモートアクセスに結び付くアカウントなら優先度は高くなります。

共有 ID に MFA を掛けづらい場合はどうすべきですか？

原則は共有 ID を減らし、個人 ID へ分解することです。どうしても残す場合でも、利用条件、承認フロー、監査ログ、保管責任、例外期限を明文化しなければ危険です。

委託先アカウントは VPN や接続装置の対策より後でもよいですか？

後ではありません。接続点の対策と認証統制は並行で進めるべきです。外部接続を見直しても、強い権限を持つ例外アカウントが残っていれば別の経路で再発しやすくなります。

MFA を導入済みでも危険が残るのはなぜですか？

全体導入率が高くても、危険な例外アカウントが残っていれば意味が薄いからです。休眠アカウント、共有 ID、委託先、管理者、弱い認証方式の例外をどれだけ減らせるかが重要です。

番号照合やフィッシング耐性のある方式まで進めるべきですか？

はい。CISA も、移行期は番号照合で疲労攻撃を抑えつつ、最終的にはフィッシング耐性のある方式を目指す考え方を示しています。特に高権限アカウントでは優先度を上げるべきです。

まとめ

MFA未適用アカウントが危険なのは、単に MFA が入っていないからではありません。例外アカウントほど、委託先接続、管理者権限、共有 ID、休眠運用、外部接続と結び付きやすく、事故時の影響が大きいからです。アスクルの公式公表でも、10月24日の応急対応に認証情報リセットと管理アカウントへの MFA 適用が含まれており、認証統制が重要な是正対象だったことが分かります。

実務の第一歩は、全社一律の導入率を見ることではなく、危険な例外を減らすことです。委託先、管理者、共有 ID、リモートアクセス、休眠アカウントを台帳へ戻し、責任者、期限、ログ、認証方式まで含めて再確認してください。そのうえで、外から見える公開面と接続点も洗い直すと、認証統制と公開面整理をつなげて進めやすくなります。