エラー発生の背景
2025年4月20日午前4時から9時（UTC）にかけ、Microsoft Entra IDの新機能が誤って大量のアカウントをロックアウトしました。Entra IDとは、企業向けのID管理サービスであり、4月15日に導入されたMACE Credential Revocation（リーク認証情報検知）機能が動作中に不具合を起こし、利用者のパスワードが不正流出と誤判定されました。当初はダークウェブで漏えい情報を検出したと説明され、管理者から混乱と憤りの声が上がりました。数日前から警告が発生していたものの、正確な原因は不明のまま、影響範囲だけが拡大していったのです。
誤検知トリガーの詳細
MACE Credential Revocationは短命ユーザートークンのメタデータを誤ってログし、流出警告を乱発しました。本来はダークウェブ上の流出データベースと照合し、危険度の高い認証情報を検知する機能ですが、新たに内部ロギングが強化された影響で、短期間で発行されたリフレッシュトークンが大半のアカウントで「漏洩」と判定されました。影響を受けたアカウントは共通点が乏しく、特定攻撃ではなくシステムエラーだったことは、リリース直後から疑念を招きました。
被害の実態とユーザー報告
Reddit上のシステム管理者たちは「全員MFA設定なのにリスクスコアが一気に“高”に上がった」と証言しています。ある企業では約6件のアカウントが同時にロックされ、従業員が社内ポータルにアクセスできなくなるトラブルが発生しました。別の組織では、エラーコード53003や「Conditional Access Policy」違反のメッセージが不規則に表示され、地域的なサービス障害も疑われましたが、公式の稼働状況には異常は記録されていませんでした。この混乱は9to5GoogleやTechRadar Proなどのメディアでも取り上げられ、管理者は緊急対応に追われました。
Microsoftの正式発表と原因
Microsoftは4月18日に内部ログ処理の不具合を認め、4月20日に問題を修正、影響トークンを無効化したと公式発表しました。Windows Health Dashboardには「一部短命ユーザートークンのメタデータが意図せずログ記録されたため、漏えい警告が誤生成された」と記載されています。エラー発生はUTC基準で午前4時から午前9時の5時間に限定され、同日中にログ処理を修復、対象トークンをリセットしてサービスを安定化させたと説明されました。影響を受けた管理者には個別通知が送られ、サポートチームが追加対応を続けるとされています。
影響範囲と対象バージョン
本問題はEntra IDを利用する全組織に共通して発生し、特定のOSやブラウザ依存はありません。Azure ADバックエンドの一部ログ処理に起因するため、Windows、macOS、Linuxの各環境、モバイルアプリにも横断的に影響しました。特に大企業や教育機関ではID管理の中核システムが一時停止し、テレワーク環境から社内システムへの接続が遮断される事態となりました。Microsoft 365の他サービスは直接の影響を免れていますが、Entra ID経由の認証停止は多くのクラウドサービスに波及しました。
導入組織の対応手順
管理者はまずAzureポータルでリスクの高いサインインログを確認し、対象ユーザーのトークンを再発行してください。具体的な手順は以下の通りです。 1. Azure Portalに管理者権限でログイン 2. 「Azure Active Directory」→「セキュリティ」→「サインインログ」を開く 3. 期間を2025年4月20日午前4時〜9時に絞り込み、リスクイベントを確認 4. 該当ユーザーの「パスワードリセット」と「多要素認証トークンの再生成」を実施 5. Conditional Accessポリシーの閾値を一時的に緩和し、影響範囲を縮小 これにより、誤検知によるロックアウトを緩和し、正常なユーザーアクセスを迅速に復旧できます。
再発防止策と運用改善
今後はログ出力設定を分離し、流出検知とメタデータログ処理を独立管理する必要があります。運用管理者は以下の対策を講じてください。 - **ログ監査の強化**：短命トークンと永続トークンのログを分離し、不正フラグと混同しない設定を適用 - **監視アラートのカスタマイズ**：リスクスコア上昇時の通知先と閾値を細分化し、誤警告を迅速に見分ける - **定期リハーサル**：更新前のステージング環境で、MACE機能を含むセキュリティ機能の動作検証を実施 - **ユーザートレーニング**：障害発生時のセルフサービス手順を社内マニュアルに明記し、ユーザー自身が一時解除できる準備 これらにより、同様のシステムエラーによる大規模ロックアウトを未然に防止できます。
まとめと独自分析
Microsoftの迅速な修正対応は評価できるものの、情報開示の遅れが運用混乱を招きました。今回の一件は、リリース前テスト不足とログ設計の不備が招いた典型的なケースです。独自分析として、企業はセキュリティ機能の更新時に「障害発生リスク評価」を導入し、リリース前に影響度を定量化する仕組みを整備することを強く推奨します。具体的には、更新を行う週の運用時間帯をズラす「メンテナンスウィンドウ」設定や、影響範囲が大きい機能には段階的リリースを実施する「カナリアデプロイ」の適用です。これらを実践すれば、次回以降の大規模アカウントロックアウトを未然に回避し、安定したID管理運用を実現できます。
