セキュリティベンダーSophosが、世界のITおよびセキュリティ担当者5000人を対象として2026年に実施した調査によると、調査対象となった組織の71％が、2025年から2026年にかけての過去1年間に認証基盤に関連したセキュリティ侵害を少なくとも1回経験した。同社が2024年11月1日から2025年10月31日にかけて世界70カ国・34業種で発生したインシデント661件を分析すると、インシデント全体の67％が認証情報の窃取などのID関連の攻撃手法に起因しており、攻撃者が組織内に侵入してからオンプレミスADサーバに到達するまでの所要時間は、中央値でわずか3.4時間だった。

　攻撃者が、システム復旧に欠かせない認証基盤に侵入すると、ランサムウェア（身代金要求型マルウェア）による被害からの復旧はさらに困難だ。認証基盤の保護に特化したセキュリティベンダーSemperisは2025年7月、世界1500の組織に所属するITおよびセキュリティ担当者を対象に、ランサムウェア攻撃とその対策に関する調査を実施した。それによると、ランサムウェア攻撃を受けた組織の83％で認証基盤が侵害されていた。

　一般的な復旧手順に認証基盤の回復手順が組み込まれにくい理由は、単純に「作業が難しいから」だ。

　Microsoftが公開している、ADのドメイン（管理グループ）を束ねた全体構造「ADフォレスト」の復旧ガイドを見れば、その複雑さは一目瞭然だ。2026年10月時点では全29ステップ、付録を含めると149ページに及ぶ。一度ミスをすれば、最初からやり直さなければならないこともある。

　従来型のバックアップ手法を漫然と適用すると、事態を悪化させる恐れさえある。ADのデータを復元したからといって、無害でクリーンな認証基盤を取り戻せるとは限らない。攻撃者がシステム内部に侵入した後に作成されたバックアップでシステムを復元すれば、正規のデータとともに、攻撃者が埋め込んだ悪意ある設定変更も復元される恐れがある。

　認証基盤の復旧がいかに複雑で時間がかかるのかは、大規模なサイバー攻撃の被害のニュースとして、これまでに何度も実証されてきた。

　医療機関Ascension Healthが2024年5月にランサムウェア攻撃を受けた際、約2万5000台のサーバのうち、攻撃を受けたのはごく少数だった。一方で、認証基盤をクリーンな状態で復旧させなければ、これを使う他のシステムを安全に起動できない状態だった。攻撃後、同機関は電子カルテ（EHR）システムへのアクセスを地域ごとに順次復旧させたが、全ての復旧には6週間を要した。この間、米国内の複数の州にまたがる同機関の医療施設は、紙のカルテや伝票による手動での業務を実施せざるを得なかった。

　大規模なサイバー攻撃を受けた後にADの復旧が難航する問題は、今に始まったことではない。2017年6月に発生したマルウェア「NotPetya」の攻撃では、世界的な海運大手A.P. Moller - Maerskが全拠点のドメインコントローラーを破壊されて、ADの再建を完了するまでに9日間を費やした。

　復旧後もマルウェアが認証基盤内に残留する可能性があることも問題だ。攻撃者は、設定ミスのある証明書テンプレートを悪用して、多要素認証（MFA）を回避可能な「隠し管理者アカウント」を作成する。ハイパーバイザー層にバックドアを仕掛けて、OSの再起動や一般的な初期化作業を潜り抜ける手口も確認されている。これらの手口は一般的な復旧時のチェックをくぐり抜けるように設計されているため、標準的な健全性チェックを通過した復旧済みシステムでも、攻撃者が潜んでいる可能性があるのだ。

復旧ツールと復旧に向けた準備のギャップ

　復旧計画で認証基盤は個別の優先事項として扱われないことがほとんどだ。調査会社Gartnerが2026年に実施したITレジリエンス調査では、多くの組織が基本的な復旧機能を備えているものの、戦略や連携の不十分さが理由で、それらの復旧機能を効果的に活用できていないことが明らかになった。

　災害復旧およびサイバーレジリエンス企業のRecovery Pointがこの調査を分析したところ、バックアップの自動化や復旧用の独立した隔離復旧環境（IRE：Isolated Recovery Environment）は導入が進んでいた。一方で、改ざん防止ストレージ（イミュータブルストレージ）やクリーンなシステムイメージ（ゴールデンイメージ）など、認証基盤に特化した保護対策を導入していない組織が目立った。

　Semperisは2025年11月に世界10カ国のセキュリティリーダーを対象とする調査結果を公開した。調査対象の組織では、認証基盤に対する脅威の検出と対応に特化したフレームワーク「ITDR」（Identity Threat Detection and Response）の計画を策定している組織のうち、90％が認証基盤の脆弱性を検出できると回答した。しかし、特定されたIDの脆弱（ぜいじゃく）性を修正する手順を計画に盛り込んでいた組織は45％にとどまった。検出ツールの導入ばかりが先行して、侵害発生後の復旧・修復手順が置き去りにされているのが現状だ。

　攻撃者がシステムへのアクセス権獲得、権限の昇格、復旧の妨害を目的として、認証情報や認証基盤を標的にするケースが相次いでおり、認証基盤に特化した復旧の必要性は高まっている。かつてサイバー攻撃の最大の標的は「社内ネットワークと外部の境界」だったが、今や「認証基盤」が最大の攻撃対象（アタックサーフェス）になった。その結果、企業はID・アクセス管理（IAM）への投資を強化している。調査会社Forrester Researchは、IAM関連の支出額が2024年から2029年まで年平均成長率15.3％で増加し、275億ドルに達すると予測する。

　現代の脅威に応じた認証基盤の復旧体制を確立するためには、以下の対策を講じる必要がある。

• 認証基盤のバックアップを保護する
  • 本番稼働している認証基盤の認証情報とは独立して、バックアップが存在することを確認する。管理者の認証情報を盗んだ攻撃者であっても到達できない場所に、オフラインまたはネットワークから物理的に隔離（エアギャップ化）した状態でコピーを保管する。
• 認証基盤の復旧をテストする
  • インシデント発生時に初めて手順を考えるのではなく、事前に認証基盤の復旧手順を練習しておく。認証基盤の復旧訓練は一般的な災害復旧の訓練とは切り離して実施する。クリーンな状態の認証基盤を取り戻すまでの時間を計測して、標準の目標復旧時間（RTO）と併せて管理する。
• 復旧用インフラを分離する
  • 再感染のリスクを減らすため、本番ネットワークから切り離された、認証基盤復旧用の独立したシステムを構築する。1つのアカウントが侵害されても双方にアクセスできないように、バックアップを管理するアカウントと本番環境を管理するアカウントを分ける。
• IDの完全性を検証する
  • 復旧完了と判断する前に、隠しアカウントや不正なアクセス権限がないかどうかを確認して、その上でシステムを本番環境に戻す。