MFAの最大の弱点：アカウント回復が新たな攻撃経路となっている

長年にわたり、セキュリティチームはアカウント乗っ取りを困難にしてきました。多要素認証（MFA）は、パスワードのみの認証に重要な保護機能を追加し、条件付きアクセスやデバイスの信頼性確認は、ユーザーが機密システムにアクセスする前にさらなるチェックを追加しています。

しかし、こうした制御措置は、攻撃者に別の経路を探す動機を与えてしまいます。ますます一般的になりつつある攻撃の中には、認証メカニズム、特にアカウント復旧に関するプロセスを標的とするものがあります。結局のところ、管理権限を持つ人物を説得して、自分の代わりに第二要素を変更してもらえばよいのですから、わざわざユーザーの第二要素を盗む必要などないのです。

そのため、サービスデスクは単なるサポート機能以上の存在となっています。組織のIDセキュリティ境界の一部となっているのです。

MFAによりアカウント乗っ取りのコストが上昇

たとえ攻撃者がユーザーの認証情報を盗み出したとしても、MFA がある限り、攻撃者とアカウントの間には依然として 2 番目の認証要素が立ちはだかる。

その障壁をさらに強化しているのは、多くの組織がSMSなどの脆弱な認証要素から、認証アプリ、FIDOセキュリティキー、パスキーへと移行しているという事実です。フィッシング耐性のある認証により、認証情報の盗難をアカウントへのアクセスに結びつけることが著しく困難になります。また、条件付きアクセスやデバイスの信頼性評価により、デバイス、場所、ログイン時の状況といった要素に基づいた追加のチェックが加わります。

これらはいずれも、MFAが失敗したことを意味するものではありません。多くの場合、その逆が真実です。MFAは十分に機能しているため、攻撃者は正面から攻撃するよりも、それを回避する方法を見つける動機を持つのです。

具体的には、セッショントークンの窃取、既存の認証済みセッションの悪用、あるいは通常のログインフローの外にある認証プロセスを標的とすることが考えられます。そして、最も重要なプロセスの一つがアカウント復旧です。

どの強力な認証システムであっても、依然として日常的な問題に対する答えが必要です。それは、「正当な従業員がシステムへのアクセス権を失った場合、どうするか」という問題です。その時点で、アカウントのセキュリティは、それを保護するMFA技術よりも、アカウントをリセットするために使用されるプロセスに大きく依存することになります。

「復旧経路」が「攻撃経路」となる場合

従業員はスマートフォンを買い替えたり、セキュリティキーを紛失したり、電話番号を変更したり、端末を破損させたり、認証情報を忘れたりすることがあります。場合によっては、認証アプリが単に利用できなくなることもあります。

セルフサービスによる復旧が不可能になった場合、通常はサービスデスクを経由してアカウントへのアクセスを回復することになります。

組織やユーザーの権限によっては、エージェントがパスワードやMFAをリセットしたり、既存の認証方法を削除したり、一時的な認証情報を発行したり、新しい認証アプリの登録を承認したり、その他の方法でアクセスを復旧させたりできる場合があります。

これらは必要なサポート機能である一方、セキュリティの観点からは、機密性の高いID管理上の操作でもあります。そのため、リセット前の検証手順が極めて重要となります。通常、ユーザーがアカウントにアクセスするには複数の認証要素を満たす必要がありますが、それらの要素を置き換えるために数問の質問に答えるだけで済む場合、復旧プロセスが同一のIDへのより脆弱な経路となってしまいます。

これは、従来のヘルプデスクの問題というよりも、アイデンティティ保証の問題として扱われるようになってきています。例えば、マイクロソフトは現在、Entra IDにおけるアカウント復旧を「高保証」プロセスと位置づけ、従来の質問ベースのヘルプデスクによる復旧と、アクセスが復元される前に信頼を再確立するように設計された、より強力な本人確認とを対比させています。

その原則は単純です。認証方法を置き換えるために使用されるプロセスは、変更を要求している人物がアカウントの所有者であることを確実に証明できなければなりません。そうでなければ、回復経路は瞬く間に攻撃経路へと変貌してしまう可能性があります。

最近の攻撃が浮き彫りにしたリスク

ハッカー集団「Scattered Spider」が用いた戦術は、ヘルプデスクが直面する課題を如実に示しています。CISA、FBI、および国際的なパートナーによる共同勧告によると、このグループは従業員を装い、IT担当者やヘルプデスクスタッフを説得してパスワードをリセットさせ、多要素認証（MFA）を攻撃者が制御するデバイスに移行させていたとのことです。

同勧告では、攻撃者が乗っ取りを試みる前に、組織のパスワードリセット手順を把握するために数回にわたり電話をかける可能性があるとも指摘されている。

2025年に発生したマークス＆スペンサー（M&S）への攻撃は、高度ななりすまし攻撃がいかに甚大な被害をもたらし得るかを示しています。「Scattered Spider」は従業員になりすまし、外部委託業者を騙してパスワードをリセットさせ、アクセス権を取得しました。そこから、同グループはさらに多くのアカウントを侵害し、最終的には小売業者のネットワーク全体にランサムウェアを展開しました。

M&Sのアーチー・ノーマン会長は議会で、この事件により、回収額を除いて約3億ポンドの利益減が見込まれると述べ、身元を標的としたソーシャルエンジニアリング攻撃が成功した場合、いかに重大な事業上のインシデントになり得るかを強調した。

本人確認をサービスデスクのワークフローに組み込む

このギャップを埋めるには、サービスデスクの対応を「この人は正当な人物に聞こえるか？」や「確認の質問に答えられるか？」といった判断から、より強固な基準、「この人物は、そのアカウントに関連付けられた従業員であることを安全に証明できるか？」へと移行させる必要があります。

そこで役立つのが「Specops Secure Service Desk」です。このソリューションは、機密性の高いサービスデスクのワークフローにおいて本人確認を必須のプロセスとし、容易に推測されたりフィッシング攻撃で入手されたりする情報への依存や、ソーシャルエンジニアによって操作されかねない判断への依存を軽減します。

Specops Secure Service Deskは、Active DirectoryやEntra ID内の既存のIDデータを利用でき、Duo、Okta、PingID、Symantec VIPなどの認証サービスと連携可能です。15種類以上のMFA要素に対応しているため、サービスデスクは別途登録プロセスを設けることなく、さまざまなタイプのユーザーを認証できます。

重要な点として、本人確認はリスクの高い操作の直前に位置付けられています。エージェントは、問い合わせ者の本人確認が成功した場合にのみ、パスワードのリセット、アカウントのロック解除、および次回のログイン時のパスワード変更を要求することができます。また、本人確認イベントをSIEMや分析プラットフォームにエクスポートすることで、監査やSOCのワークフローを支援することも可能です。

Specopsでサービスデスクのセキュリティを強化

強力な認証は、そのリセットや回復に用いられるプロセスも同様に安全である場合にのみ機能します。サービスデスクでの本人確認をIDセキュリティプロセスの一部として扱うことで、正当なサポートを困難にすることなく、ソーシャルエンジニアリングのリスクを低減できます。

Specopsは、パスワードのリセットやアカウントのロック解除といったリスクの高いサービスデスク操作の前に、より強力な本人確認を導入できるよう組織を支援します。

今すぐSpecopsにお問い合わせいただき、本人確認を強化してサービスデスクのセキュリティを確保する方法をご確認ください

本記事はSpecops Softwareによる提供・執筆です。