セキュリティチームは長年にわたり、アカウント乗っ取りを困難にする取り組みを続けてきました。多要素認証(MFA)はパスワードのみの認証に重要な保護層を加え、条件付きアクセスやデバイス信頼性の検証は、ユーザーが機密システムに到達する前にさらなるチェックを追加しています。
しかし、こうした対策は攻撃者に別の経路を探させる動機を与えています。近年増加しているのが、認証メカニズムを取り巻くプロセス、特にアカウント復旧を狙う攻撃です。管理権限を持つ担当者を説得して第2要素を交換させることができるなら、わざわざユーザーの第2要素を盗む必要はないというわけです。
これにより、サービスデスクは単なるサポート機能にとどまらず、組織のID(アイデンティティ)セキュリティ境界の一部となっています。
MFAがアカウント乗っ取りのコストを引き上げた
攻撃者がユーザーの認証情報を窃取したとしても、MFAが導入されていれば、アカウントへのアクセスまでには第2の認証要素という壁が立ちはだかります。
さらにこの防御を強化しているのが、多くの組織がSMSなどの脆弱な要素から、認証アプリ、FIDOセキュリティキー、パスキーへと移行している点です。フィッシング耐性を備えた認証を導入すれば、認証情報の窃取をアカウントアクセスにつなげることが格段に難しくなります。また条件付きアクセスやデバイス信頼性の検証は、デバイス、位置情報、ログイン時の状況といった要素に基づき、さらなるチェックを追加します。
これはMFAが失敗しているという意味ではありません。むしろ多くの場合はその逆で、MFAが十分に機能しているからこそ、攻撃者は正面から突破するのではなく、これを回避する方法を見つけようとするインセンティブを持つのです。
それは、セッショントークンを盗む、既存の認証済みセッションを悪用する、あるいは通常のログインフローの外側にある認証プロセスを狙うといった形を取ります。そして、その中でも特に重要なプロセスの一つがアカウント復旧です。
どれほど強固な認証システムであっても、正規の従業員がそのシステムへのアクセスを失った場合にどうするかという、ごくありふれた問題への答えを用意しておく必要があります。その局面では、アカウントのセキュリティはMFA技術そのものよりも、リセットに使われるプロセスに左右されることが多くなります。
復旧経路が攻撃経路に変わるとき
従業員はスマートフォンを買い替えたり、セキュリティキーを紛失したり、電話番号を変更したり、デバイスを破損させたり、認証情報を忘れたりします。認証アプリが単純に使えなくなることもあります。
セルフサービスによる復旧が不可能になった場合、サービスデスクが典型的にはアカウントへの復帰経路となります。
組織やユーザーの権限にもよりますが、担当者はパスワードやMFAのリセット、既存の認証方法の削除、一時的な認証情報の発行、新しい認証アプリの登録承認、その他の方法でアクセスを復旧できる場合があります。
これらは必要なサポート機能である一方、セキュリティの観点からは機密性の高いID管理操作でもあります。だからこそ、リセット前の本人確認ステップが重要になります。通常はアカウントにアクセスするために複数の認証要素を満たす必要があるのに、それらの要素を交換する際にはわずかな質問に答えるだけで済むとすれば、復旧プロセスは同じIDに対するより脆弱な経路になり得るのです。
これは従来型のヘルプデスクの問題としてではなく、ID保証(アイデンティティアシュアランス)の問題として捉えられるようになってきています。例えばMicrosoftは現在、Entra IDにおけるアカウント復旧を「高保証」プロセスと位置づけ、従来の質問形式によるヘルプデスク復旧と、アクセスを復元する前に信頼を再確立するために設計された、より強力な本人確認とを対比させています。
原則はシンプルです。認証方法を交換するために使われるプロセスは、変更を要求している人物がそのアカウントの所有者本人であるという確信を与えるものでなければなりません。それができなければ、復旧経路は容易に攻撃経路へと変わってしまいます。
最近の攻撃が示すリスク
ハッキング集団Scattered Spiderの手口は、サービスデスクが直面する課題を如実に示しています。CISA、FBI、および国際的なパートナー機関による共同勧告によれば、同グループは従業員になりすまし、IT部門やヘルプデスクの担当者を説得してパスワードをリセットさせ、MFAを攻撃者が管理するデバイスへ移行させていたとしています。
同勧告はまた、攻撃者が乗っ取りを試みる前に、複数回の通話を重ねて組織のパスワードリセットプロセスについて情報収集する場合があると指摘しています。
2025年にMarks & Spencerを襲った攻撃は、巧妙ななりすましがどれほどの被害をもたらし得るかを示しています。Scattered Spiderは従業員になりすまし、第三者の業務委託先を騙してパスワードをリセットさせ、アクセス権を獲得しました。そこを足掛かりに、同グループはさらに多くのアカウントを侵害し、最終的には同小売企業のネットワーク全体にランサムウェアを展開しました。
M&Sのアーチー・ノーマン会長は英議会で、この事件により復旧費用を除いても利益が約3億ポンド押し下げられる見込みだと証言しており、ID(アイデンティティ)を狙ったソーシャルエンジニアリング攻撃が成功すれば、いかに大規模な経営上のインシデントに発展し得るかを浮き彫りにしています。
本人確認をサービスデスクのワークフローに組み込む
このギャップを埋めるには、サービスデスクの判断基準を「この人物は本人らしく聞こえるか」「本人確認の質問に答えられるか」といったものから、より強固な基準――「この人物はアカウントに紐づく従業員本人であることを安全に証明できるか」――へと転換する必要があります。
そこで役立つのが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に問い合わせると、本人確認を強化してサービスデスクを保護する方法を確認できます
