ID セキュリティについて考える：Okta と Microsoft のアプローチが示唆する未来

What Okta and Microsoft’s Approaches Tell Us About the Future of Identity Security

2026/09/04 InfoSecurity — この夏の数週間で、企業のアイデンティティ管理を担う 2 社が関連する複数の発表を行った。まず Microsoft は、Microsoft Entra ID でパスキーを既定の認証方式とし、SMS／音声による認証オプションを年末までに非推奨とすることを発表したほか、2027年3月には Self-Service Password Reset (SSPR) 機能でのセキュリティ質問を廃止する。

ほぼ同時期に、Okta の Threat Intelligence チームが公開した調査結果では、アカウントを乗っ取る攻撃者がパスキーの登録／アカウント復旧フローを標的とするケースが増えていることが詳述されている。また、脅威アクターから頻繁に標的とされる組織の大半が、フィッシング耐性の高い認証方式を利用していることも Okta は確認している。

こうした動きが重なったことで、すべての CIO が考えるべき問題が提起されている。組織全体に対してフィッシング耐性の高い MFA を導入した後に、従業員がデバイスを紛失したと申告した場合には、いったい何が起きるのだろうか。

強力な認証は攻撃を阻止するのではなく、攻撃経路を変える

セキュリティにおける厳しい現実の 1 つは、防御を強化しても攻撃自体は止まらず、攻撃経路が別の場所へと移ることである。フィッシング耐性の高い MFA によりログイン画面の突破が困難になるにつれて、アイデンティティ・ライフサイクルの中で依然として脆弱な部分へと攻撃者が移行している。

Okta は最近の調査で、この傾向を明確に示している。強力なサインイン・ポリシーにより、脅威アクターの標的がユーザー・ライフサイクルにおける次の脆弱なポイント、つまり登録／アカウント復旧へ移ると説明している。

Microsoft も同様の傾向を確認している。2026年5月に同社の脅威インテリジェンス研究者が報告したのは、Storm-2949 として追跡される脅威グループが、認証制御を突破せずにクラウド環境を侵害した事例である。この攻撃者は、標的アカウントの Self-Service Password Reset (SSPR) を開始し、IT サポートを装いながら従業員へ電話をかけ、表示された MFA プロンプトを承認するよう誘導した後に、既存の認証方式を削除して自身のデバイスを登録した。

この事例では、技術的に認証機構が突破されたわけではなく、復旧プロセスも設計どおりに動作しており、MFA プロンプトも正規のものであり、実際の従業員が承認していた。問題は、SSPR フローにおいて Authenticator を再登録する人物が本人であることを検証していなかった点にあり、結果として巧妙な攻撃者が悪用可能なソーシャルエンジニアリングの機会を生み出していた。

アカウント復旧が弱点となる理由

アカウント復旧時の認証が必要になるのは、従業員が通常使用している本人確認手段を失ったタイミングである。通常の認証とは異なり、強力な主要認証要素を失った場合には、その復旧プロセスにセキュリティ全体が大きく依存することになる。

多くの企業では、復旧時の代替認証方式として、登録済みデバイスへのプッシュ通知や、SMS またはメールで送信される One-Time Passcode などが用いられている。自己サービスで処理される場合もあるが、筆者が目にする限りでは、アカウント復旧がヘルプデスクへ送られるケースが多い。

ここで重要なのは、これらの認証要素が確認するのは、その人物が誰であるかではなく、デバイス／電話番号／受信トレイといった何らかの対象に、その人物がアクセスできるという事実だという点である。したがって Storm-2949 の事例が示すように、Authenticator による認証手段が、攻撃者に悪用される可能性がある。

Passkeys は有効かつ必要な仕組みであるが、アカウント復旧の問題自体を解決するわけではない。デバイスの紛失／盗難／交換が発生すれば、従業員は再び復旧フローを利用することになり、通常は別の認証要素へとダウングレードしなければならないため、必要なのは、より高い保証レベルを持つ認証手段へ移行できる復旧フローを設計することである。

アカウント復旧制御を評価する方法

今年の IT セキュリティ評価で中心に据えるべき問いは、「アカウント復旧手順では、その操作を行う人物自身を検証しているのか、それとも何らかの対象へアクセスできることを検証しているのか」である。この違いを踏まえると、問題の捉え方も変わってくる。認証が答えるのは「どの認証主体が操作しているのか」という問いであるのに対し、適切な復旧に答える必要があるのは、より難しい「どの人間が操作しているのか」という問いである。

アカウント復旧制御を評価する場合は、以下の項目についてテストする必要がある。

• それぞれの人間のアイデンティティを確認しているのか、それとも特定の認証情報／デバイスを所持していることを確認しているのか。
• 従業員が紛失したもの自体が主要な認証要素である場合にも機能するのか。つまり、スマートフォンを湖へ落とした場合も機能するのか。
• ソーシャルエンジニアリングの機会を生み出さないか。
• 明確な判定結果を返すのか、それとも誰かによる解釈が必要なシグナルを返すのか。
• 従業員が手動による例外対応を要求しない程度に、迅速／簡便なプロセスとなっているか。

フィッシング耐性の高い認証へ移行することは適切な判断であり、特定の攻撃カテゴリ全体を排除することにつながるが、その移行によってリスクが復旧プロセスへ集中するため、復旧においてもログインに適用されるものと同等の厳格さが必要となる。

この問題へ適切に対応する組織は、アカウント復旧を本質的に変化したアイデンティティの問題として扱い、従業員を採用するときや、高権限を伴う操作を承認するときに確認する問いをアカウント復旧時にも適用することになる。つまり、この人物が本当に本人なのかという問いである。

パスキーのようなフィッシング耐性の高い認証に加え、復旧時にも本人を検証できる方式を採用すれば、攻撃者が別の入口から侵入する様子を、2027年を通じて見続けることにはならないだろう。

認証の強化に伴い、アカウント復旧プロセスが狙われるケースが増えていることを示す記事です。 Okta や Microsoft Entra ID でフィッシング耐性の高い認証が普及する一方、アカウント登録や復旧時の脆弱性を狙った侵害が増加しています。攻撃者がヘルプデスクや SSPR (Self-Service Password Reset) を悪用することで、正規の認証を回避してアカウントを乗っ取るリスクが拡大しています。対応策として、単なるデバイス所持の確認ではなく、復旧時における本人厳格検証の導入／ソーシャルエンジニアリング対策の強化／高度な復旧フローの再構築が求められます。