Active Directoryの復旧：最悪のシナリオに備えた計画

組織のわずか36％が過去12か月間に Active Directory（AD）のセキュリティ評価を実施したと、The Netwrix 2026 Data and Identity Security Reportによると報告されています。同じ調査で、73％が自分のADに権限昇格を可能にする誤設定がないと完全には確信していないことがわかりました。

Microsoft Threat Intelligenceは、脅威アクターが人間が操作するサイバー攻撃の78％以上でドメインコントローラーを侵害し、評価されていない環境の隙間を悪用していると報告しています。

これにより、ADの災害復旧はアイデンティティのレジリエンスの問題となり、最悪のシナリオは、すべてのドメインコントローラー（DC）がダウンし、レプリケーションが破損しているか、バックアップ自体が暗号化されているフォレスト全体のイベントです。

バックアップスケジュールとリカバリープランは異なることを証明します。スケジュールはデータがどこかに存在することを証明します。プランは、ビジネスがプレッシャー下でそのデータから動作するディレクトリを再構築できることを証明するため、実用的なプランは生き残るべき最悪の障害、復旧手順、および機能を証明するテストの頻度を定義します。

Active Directoryの災害復旧とは何ですか？

Active Directoryの災害復旧は、個別のオブジェクト復旧では対応できない、フォレスト全体の障害（フォレスト全体の停止、破損、または侵害など）後にADフォレスト全体を復元するための文書化された順序付きプロセスです。

フォレストの復旧は、厳格な依存関係に基づく順序に従います。計画では、どのドメインコントローラーが最初に復旧するか、チームがFlexible Single Master Operations (FSMO roles)を再割り当てする順序、および破損したデータを伝播させずにレプリケーションを再確立する方法を定義します。

この用語は、次のようなあらゆるものに広く適用されます： 削除された単一のユーザーアカウントの復元から フォレスト全体の再構築までであり、両者はまったく異なる計画を必要とします。ADリサイクルビンから単一オブジェクトを復元する場合は、周囲のフォレストが正常であることを前提としています。フォレスト全体の復旧は、フォレスト自体が破損しているという前提から始まります。

最悪のAD障害シナリオはどのようなものですか？

これらのAD障害シナリオは、組織が通常のトラブルシューティングではなく完全なフォレスト回復を追求するよう促します。

ランサムウェアがすべてのドメインコントローラーを一度に暗号化または消去する

ランサムウェアの攻撃者は現在、ドメインコントローラーを直接狙っており、highly privileged accountsを取得すると、攻撃者は同じ操作の一環としてバックアップを削除できます。バックアップDCが本番環境と同じネットワークセグメントにある場合、ADをダウンさせる攻撃と同じ攻撃で復元用のバックアップもダウンさせることができます。 Microsoftの基準によるフォレストの復旧条件は、すべてのDCが論理的に破損しているか物理的に損傷しており、事業継続が不可能な状態であることです。

Maerskの2017年のNotPetya事件は、このシナリオの教科書的な例です。このマルウェアは1時間以内にMaerskのグローバルネットワーク上のほぼすべてのドメインコントローラーを消去し、攻撃が発生した際にガーナのアクラオフィスの1つのDCが停電で電源が切れていたため、同社は完全な損失を免れました。その唯一の生存コピーがMaerskに残りのActive Directoryフォレストを再構築させましたが、MaerskのCISOは後にこう述べました 回復にかかった9日間は「十分ではない」と。より広範な再構築は最終的に約4,000台のサーバーと45,000台のPCをカバーし、Maerskは 総費用を最大3億ドルと見積もりました。

侵害された管理者アカウントがOU、GPO、またはサブツリー全体を削除する

Domain Admin または Schema Admin 権限を持つ不正な管理者は、レプリケーションストリーム内で正当な操作と区別がつかない変更を加えることができます。バックアップからの既知の正常なベースラインがなければ、個別のオブジェクト復元でどの変更が悪意のあるものか特定できません。

組織単位（OUs）、Group Policy Objects (GPOs)、またはサブツリーの削除は、通常の管理操作のように見えるため、しばしば見過ごされます。Kerberosチケット、SIDHistory、AdminSDHolder、またはGPOsを変更する永続化技術は、チームが信頼できるバックアップから復元し結果を検証しない限り、ディレクトリデータベース内に残る可能性があります。

破損したレプリケーションまたはすべてのDCに広がる不正なスキーマ変更

攻撃者または管理者は、データ破損を広げるスクリプトを実行できます。フォレスト全体にわたって、競合する変更でスキーマを拡張し、それがどこにでも複製されることもあります。エラーが目に見えるようになる頃には、回復計画でクリーンと想定しているドメインコントローラーを含め、フォレスト内のすべてのドメインコントローラーに既に存在している可能性があります。スキーマパーティションはフォレスト全体に共有されているため、破損したスキーマはすべてのドメインの操作を一度に停止させます。

地理的に冗長なDCがないサイト全体のハードウェア障害または自然災害

Microsoftのフォレスト復旧基準は論理的な破損と物理的な損傷に焦点を当てており、単一サイトの物理的なイベントも同じ結果をもたらします。すべてのドメインコントローラーを単一のサイトまたはデータセンターで運用する組織は、火災、洪水、停電などの単一の事象でフォレスト全体を失うリスクがあり、生産環境および共置されたバックアップDCが停止します。地理的冗長性は、この種の障害に対する主要な構造的防御策です。

プロセスの途中でスキーマを破損させる失敗したADのアップグレードまたは移行

攻撃による障害を超えて、スキーマの変更はフォレストを不整合な状態にすることもあります。スキーマの変更はすべてのDCに複製され、通常の運用ではほとんど元に戻せないため、ロールバックは必ずしも簡単ではなく、破損または競合するスキーマはすべてのドメインで同時にフォレスト全体の操作を破壊する可能性があります。

ADの災害復旧計画が重要な理由

計画なしでは、上記のすべてのシナリオが同じ結末を迎えます。即興で、プレッシャーの中、依存するすべてのシステムがすでにダウンしている状態で。

ランサムウェアグループは現在、ドメインコントローラーとバックアップを直接狙っています

文書化された戦術は これがエンドポイント暗号化をはるかに超えて進んでいることを示しています。攻撃者は現在、ドメインコントローラの仮想マシンをシャットダウンして資格情報データベースを直接抽出し、制御下にある不正なドメインコントローラにFSMOロールを移行しています。

この露出は調査データにも表れています。The Netwrix 2026 Data and Identity Security Reportの調査によると、過去12か月間に無許可のIDが機密データにアクセスするインシデントを経験したと報告した組織は25％でした。

バックアップが自動的に安全であると想定する復旧戦略は、これらの攻撃の展開方法にはもはや合いません。

ADがダウンした瞬間にすべての依存システムもダウンします

メール、ファイルアクセス、VPN、およびほとんどのビジネスアプリケーションはADで認証されるため、ダウンタイムのコストは依存するすべてのシステムで時間単位で累積します。identity、DNS、ネットワーク、シークレット、またはデータベースが利用できない場合、アプリケーションは復元されても使用不能のままであり、指定された復旧時間目標を超えてダウンタイムが延長される可能性があります。

First National Bank Minnesota はその必要性を直接感じ、Netwrix Auditor のサポートを受けて3週間でActive Directoryの再構築を完了し、当初の見積もりは6か月でした。

Microsoftのフォレスト回復プロセスは長く、順序依存で厳しいです

公式のMicrosoft AD forest recovery guide は機械的な再構築手順を詳細に説明しており、侵害後のセキュリティ回復、計画とガバナンス、経営陣や保険会社への報告は明示的に除外しています。依存関係の順序を無視してドメインコントローラーを復元したり、metadata cleanup をスキップするなど、順序を間違えた手順は再構築を無効にし、やり直しを強いる可能性があります。

取締役会やサイバー保険会社は、検証済みの復旧時間目標を求めています

テスト済みのAD復旧時間目標は、経営陣、取締役会、および保険会社に具体的な指標を提供します。これは現実的な条件下で実施された実際の復元を反映しています。災害復旧計画が存在するという一般的な声明は、測定されたフェーズ時間と完了基準を伴う日付入りの復元テストよりも運用上の証拠が少ないです。

未検証の計画は実際のインシデント時に失敗します

復旧計画のギャップは、実際のプレッシャー下で最も早く表面化します。これは発見するのに最もコストがかかるタイミングです。信頼と能力は異なるものを測定しており、テストだけがそれらを調和させます。

ADの災害復旧計画に含めるべき内容

以下の各コンポーネントは、何をカバーしているか、そして最も重要な時にそれを除外すると計画が破綻する理由を示しています。

• すべてのドメインコントローラーのシステム状態の不変のオフラインバックアップ： バックアップが本番環境と同じネットワークにある場合、ADを停止させたランサムウェアが復元用のコピーに到達する可能性があります。エアギャップまたは不変のストレージはリカバリメディアを同じ障害経路の外に保持し、AD対応のバックアップアプリケーションは復元時の更新シーケンス番号（USN）ロールバックを回避します。
• 文書化された順序付けされた再構築シーケンス：フォレストの復旧には厳密な順序依存関係があり、DCの復元やFSMOロールの再割り当てを順序通りに行わないと、フォレストが修復されるどころかさらに破損する可能性があります。Microsoftはプロセスにエンドツーエンドの自動化がないことを指摘しており、環境固有の計画に負担をかけています。
• ADに特化したテスト済みの復旧時間目標（RTO）： バックアップスケジュールはデータの存在を示し、RTOはビジネスが停止している時間を示します。これは経営陣や保険会社が確認できる数値です。 復旧ポイント目標（RPO）はそれに並び、どれだけのディレクトリ変更を失っても許容できるかを定義します。
• AD障害に対する定義されたコミュニケーションおよびエスカレーション計画： 実際のAD障害時には、チームが通常調整に使用するメール、Teams、チケットシステムなどのツールも多くの場合利用できません。計画には、オフラインで保存され事前に配布された連絡網を使って、チームがこれらのツールなしでどのように連絡を取るかを明記する必要があります。
• 予定された復旧訓練またはテーブルトップ演習： チームが一度もリハーサルしていない計画は、制御されたテストではなく実際のインシデント中にギャップが明らかになります。定期的な演習は、復旧チームがインシデントのプレッシャー下で作業する前に組織の筋肉記憶を構築します。

ディレクトリ復旧ソフトウェアは、細かいオブジェクト修復と完全なフォレスト再構築の両方の動作モードをサポートすべきであり、1つの障害タイプでチームがインシデント中に別のツールを使わざるを得なくならないようにします。

ディレクトリの復旧は、隣接するアイデンティティ制御にも依存します：zero standing privilege インシデント前の持続的な管理者の露出を減らし、ephemeral admin accounts 特権資格情報の有効期間を制限し、access certification 特権アクセスの証拠を最新の状態に保ちます。

最悪のシナリオを乗り越えるAD災害復旧計画の作り方

計画を正しい順序で立てることは、その内容と同じくらい重要です。以下の各ステップは前のステップに依存しており、飛ばして進むと依存関係に対してストレステストされていない、完成しているように見える計画ができます。

1. 最初にforest構造とすべての依存関係をインベントリしてください

回復手順を1つ書く前に、すべてのドメインコントローラー、FSMOロール保持者、信頼関係、およびDNS依存関係をマッピングしてください。このインベントリなしに作成された計画は、実際に必要な瞬間に依存関係を見逃します。Microsoftのガイダンスは フォレストルートドメインのDCリストを最も重要な項目とみなしています。なぜなら、そのドメインが最初に復旧されるからです。

グローバルカタログサーバー、サイトリンク、およびレプリケーショントポロジーを含めてください。これらはDCがオンラインに戻る順序を決定します。回復チームが正常な状態を把握できるように、インベントリとともに基本的なrepadmin /showreplおよびdcdiagの出力をキャプチャします。

各ドメインのDomain AdminパスワードとDirectory Services Restore Mode（DSRM）パスワードを今すぐ記録してください。システム状態の復元に必要で、死んだフォレストからは取得できません。

2. 一般的なDR計画とは別に、AD専用の復旧時間目標を設定します

ADのRTOは、それに依存するすべてのシステムのRTOよりも短くする必要があります。ADが復旧するまで他のシステムは完全に復旧できないためです。Microsoftのルールでは、子ドメインよりも親ドメインを先に復旧する必要があり、フォレストルートのRTOが下流のすべてを制御します。ADの復旧をより広範な災害復旧計画の一項目として扱うと、その緊急性が過小評価されることが多いです。

障害宣言から機能するフォレストルートDCが復旧し、レプリケーションが確認されるまでのAD RTOを測定します。すべての依存アプリケーションのRTOはこの数値を超える必要があります。

3. 再構築の手順を順番に書き、ADにロックされない場所に保管してください

The sequence needs to specify which DC restores first, in what order FSMO roles get reassigned, and how replication gets re-verified. For the first writable DC in a domain, the runbook needs to cover each recovery action in this order:

1. Active Directory Domain Services (AD DS) の非権威的な復元を実行します。
2. Complete an authoritative restore of SYSVOL, the shared system volume that stores domain scripts and Group Policy files.
3. Run metadata cleanup for DCs you aren't restoring.
4. Seize FSMO roles.
5. Invalidate the Relative Identifier (RID) pool and raise the available RID pool value by 100,000 to prevent reissuing RIDs consumed after the backup.
6. Reset the DC computer account password twice.
7. Reset the krbtgt password twice to protect the Kerberos Ticket Granting Ticket account, with a 10-hour wait between resets.

Write these steps clearly enough for the recovery team to follow them without normal AD-dependent tools. The plan itself has to live outside AD-dependent systems. A runbook stored on a SharePoint site that requires AD to authenticate is useless when AD is down.

4. Build immutable, air-gapped backups of system state

Backups need isolation from the production network so that whatever took down AD, whether ransomware or a compromised admin account, can't also reach the copies meant to restore it. Critical backups belong in separate storage protected from unauthorized modification.

バックアップの期間もフォレストのトゥームストーンの有効期間（デフォルトで180日）内に収める必要があります。ADは古いメディアからの復元を拒否するためです。

侵害後に作成されたバックアップは、SIDHistoryの操作、AdminSDHolderの変更、および悪意のあるGPOがディレクトリデータベース内に存在するため、ADとともにマルウェアや攻撃者の持続性を復元する可能性があります。隔離とクリーンな復元の検証により、攻撃者がディレクトリに再侵入するのを防ぎます。

5. 明確な所有権と名前付きのエスカレーション経路を割り当てる

復旧の各フェーズを実行する担当者と、ステップが失敗した場合にエスカレーションする相手を明確にし、実際のインシデント時に誰かが自発的に動くのを待って計画が停滞しないようにします。

事前に構築された依存関係のインベントリや指定された所有者がいない場合、復旧チームはすべての元のシステム設計者が不在の中、プレッシャー下でリアクティブに相互依存関係を発見します。

各フェーズにプライマリとバックアップを割り当て、両者が計画で定義されたオフライン通信チャネルを通じて連絡を取り合う方法を理解していることを確認してください。

必要になる前にAD復旧計画をテストする方法

紙の上にしか存在しなかった復旧計画は、テストで効果が証明されるまでは仮説のままです。

1. ライブフェイルオーバーテストを試みる前に、テーブルトップ演習を実施してください

本番環境に触れずに、書面の計画をチームに段階的に説明してください。機器を使わずに、スタッフが特定の緊急事態に対する役割と対応を話し合うディスカッション形式の演習を利用します。これにより、システムが危険にさらされる前に所有権や順序のギャップが明らかになり、その結果は次の実地訓練の範囲を明確にします。

2. 定められた周期で隔離されたテスト環境にフォレストを復元する

テーブルトップは計画の論理をチェックします。バックアップと再構築の手順が実際に機能するかどうかは、隔離された環境での実際の復元のみが確認します。

Microsoftは、仮想化されたDCを本番環境から分離された仮想ネットワークに移動し、テストで実際の復旧データが復元されることを証明するために、本番バックアップをラボで使用することを推奨しています。Microsoftはこの演習を推奨しています 少なくとも年に一度、またEnterprise AdminsまたはDomain Adminsグループのメンバーシップが変更された際にも実施してください。

3. 実際の復旧期間を測定する

計画のRTOは、実際のテスト復元で測定された場合にのみ有効です。未検証の数値は推測にすぎません。隔離、復元、FSMOの取得、レプリケーションの検証など、各フェーズの実際の時間を記録し、計画がチームが実際に実行できる内容を反映するようにしてください。

Help Net Securityは2024年に報告しました 企業のわずか6％が1時間以内にADを復旧できるとされており、これはほとんどの公表されたRTOがチームの想定を大幅に上回っていることを意味します。dcdiagのチェック完了、正常稼働中；SYSVOLおよびNETLOGON共有が存在し、DNSは正常に稼働しています。

4. フォレストのトポロジーが変わるたびに計画を更新してください

新しいドメインコントローラー、スキーマの変更、または新しい信頼関係は再構築シーケンスの一部を無効にする可能性があるため、計画には年次レビューに加えてトリガーベースのレビュー周期が必要です。FSMOロールホルダー、サイトトポロジー、またはレプリケーションリンクの変更が計画のずれの最も一般的な原因です。

マイグレーション、アップグレード、新しいアプリケーションの展開をトリガーリストに追加してください。これらは既存のシーケンスで考慮されていない依存関係を導入する可能性があるためです。トリガーされたすべてのレビューは、更新されたインベントリで終了し、変更がトポロジー、trusts、またはスキーマに関わる場合は、新しい復元テストを行う必要があります。

NetwrixがActive Directoryの復旧をサポートする方法

Netwrix Identity Recovery は、このプランが区別する両方の復旧モードをカバーします。オブジェクトレベルのインシデントの場合、ディレクトリの変更履歴を保持し、削除または変更されたユーザー、グループ、GPO、DNSレコードをフォレストの他の部分に影響を与えずに既知の正常な状態にロールバックします。

上記の最悪のシナリオに対して、ADフォレストの完全な復旧シーケンスを自動化します。適用範囲はEntra IDとOktaにまで及び、ハイブリッドアイデンティティは同じランブックで復旧します。

復旧の判断は証拠にも依存します。なぜなら、侵害時の最初の質問は、どのバックアップが攻撃者よりも前かということだからです。

Netwrix Auditor は継続的な AD change auditing を通じてそのコンテキストを提供し、誰がいつ何を変更したかを示し、悪意のある変更と正当な変更を区別する前後の値を表示します。状態時点レポートは、ディレクトリの構成を2つの時点で比較し、チームが侵害がいつ始まったか、どのバックアップがそれより前かを特定するのに役立ちます。

チェシャー郡政府は、ディレクトリがダウンしている間に回復チームが必要とする証拠の速度で、15分で27,000ファイルの変更インシデントを調査するためにNetwrix Auditorを使用しました。

同じツールで訓練と実際のインシデントを実行することで、すべてのフェーズが比較可能になり、隔離されたラボで測定されたRTOはチームが経営陣に報告する数値と同じになります。

AD復旧計画をテスト済みの実用的なプロセスに変えましょう

真の準備状況は、経営陣が確認できる証拠にかかっています。つまり、日付のある復元テスト、測定されたAD RTO、tombstoneの有効期限内の正常なバックアップセット、そして各回復フェーズの責任者を明記したランブックが必要です。

このパッケージは、取締役会、監査人、サイバー保険会社が現在尋ねている質問に答え、それぞれの項目が主張ではなくリハーサルに基づいているため、信頼できます。

最初の単独復元では、見落とされていたDSRMパスワード、誰もインベントリしていなかった依存関係、そして想定されたRTOを破るフェーズが明らかになります。2回目の演習はよりスムーズに進行し、ビジネスが計画できる数値を生み出します。そこからは、トリガーベースのレビューにより、ドメインコントローラー、トラスト、スキーマの進化に合わせてフォレストと計画が整合され、文書化された計画と実際の環境のギャップがリスクに戻って広がることはありません。

デモをリクエストして、Netwrix Identity Recoveryが独自のトポロジーでフォレストの再構築、詳細なロールバック、およびリカバリ演習をどのように処理するかをご覧ください。