この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。Microsoft LearnのEnterprise Access ModelとActive Directory Forest Recovery、CISAのRemote Access Softwareに関する公開資料を確認し、NTDS.dit単体ではなく、ドメインコントローラーへ到達する管理経路をどう守るかという視点で整理しています。検証ステータス：🛡️ Microsoft Learn・CISA公式情報確認済み／防御・管理・復旧を中心に再構成
Active Directoryを守るとき、NTDS.ditという1つのファイルだけを見ても十分ではありません。
DCへ管理アクセスできる人・端末・RMM・バックアップ・EDR・ログ・復旧手順までを、ひとつの管理経路として考えることが重要です。
正規の管理ツールは業務に必要だからこそ、「そのツールがあるか」ではなく、誰が、どこから、いつ、何の目的で使うのが正常なのかを先に決めておくと、異常を見つけやすくなります。
NTDS.ditを守るときに見る範囲
| 守る対象 | 実務で確認したいこと |
|---|---|
| 特権アカウント | 日常利用とAD管理を分離できているか |
| 管理端末 | どの端末・踏み台からDCを管理してよいか決まっているか |
| RMM・保守ツール | 承認済み製品、導入先、管理者、通常の通信先を把握しているか |
| バックアップ | 正常な実行時間、サービス、保存先、復旧手順を把握しているか |
| EDR・ログ | DC、RMM、VPN、ID基盤などのログを関連づけて確認できるか |
| 復旧 | AD侵害を想定したフォレスト回復手順を準備しているか |
ファイルへのACLだけを強くしても、強い権限を持つ管理経路が広いままでは防御として片手落ちです。逆に、管理経路を明確にすると「いつもと違う操作」を見つけるための基準も作れます。
NTDS.ditとは何か
NTDS.dit はActive Directory Domain Servicesのディレクトリデータベースです。ユーザー、グループ、コンピューターなど、ドメイン運用に必要な重要情報を扱います。
そのため、DCの保護では「ファイルそのもの」だけでなく、DCへログオンできる人、管理用端末、バックアップ製品、リモート管理ソフトウェア、EDRなど、DC上で高い権限を持つ周辺システムも同時に見ます。
RMMは「あるか」ではなく「正しく使われているか」を見る
RMM（Remote Monitoring and Management）は、ヘルプデスクや保守担当者が多数の端末を遠隔管理するための便利な仕組みです。リモート操作や保守を効率化できる一方、管理機能が強いため、組織として使い方を把握しておく必要があります。
CISAのRemote Access Softwareに関するガイドでも、承認済みソフトウェアの管理、利用状況の把握、ログ取得、異常な利用の監視といった考え方が示されています。
最初に「正常なRMM」を一覧にする
- 承認しているRMM製品名
- 導入してよいサーバー・PC
- DCへの導入が本当に必要か
- 管理担当者と管理用アカウント
- 通常の接続元・通信先
- 通常の利用時間帯
- サービス名、インストール先、署名者
- 変更申請・保守記録との対応関係
製品名だけで許可・拒否を判断するのではなく、「承認済み製品が、承認済みの場所から、承認済みの用途で使われているか」を見るのがポイントです。
DCの管理経路を分ける
Microsoft LearnのEnterprise Access Modelでは、企業のアクセスをControl plane、Management plane、Data/Workload planeなどに分け、重要な管理経路を高いレベルで保護する考え方が示されています。
Active DirectoryのようなID基盤は、他のシステムへのアクセスそのものを左右します。日常業務と強い管理権限を同じ経路で扱わないことが重要です。
- 普段使うユーザーアカウントとAD管理アカウントを分ける
- AD管理専用の端末や踏み台を用意する
- 特権アカウントでメールや一般Web閲覧を行わない
- 管理端末から不要な用途へ資格情報を持ち込まない
- RMM、バックアップ、EDRなどの管理基盤も重要資産として扱う
監視は「いつもの状態との差」で見る
正規のRMMやバックアップ製品は、通常運用でも強い権限を使います。したがって、あるプロセスが動いた、あるサービスが存在する、という1点だけでは正常・異常を判断しにくいことがあります。
次のように複数の観点を組み合わせると、確認しやすくなります。
| 観点 | 確認例 |
|---|---|
| 利用者 | 普段その作業をするアカウントか |
| 端末 | 承認済み管理端末からの操作か |
| 時間 | 保守時間・バックアップ時間と一致しているか |
| 変更 | 新しいサービスや管理ツールが増えていないか |
| 通信 | 通常利用しない通信先が増えていないか |
| 関連ログ | EDR、RMM、VPN、ID基盤で同じ時刻に変化がないか |
正常な状態を先に記録しておくことが、異常を見つけるための基準になります。
バックアップやRMMを雑に止めない
DCが重要だからといって、バックアップや遠隔管理を一律に禁止すれば安全になるとは限りません。復旧や保守ができなくなれば、可用性のリスクが増えます。
制御を強めるときは、次の順番で進めると整理しやすくなります。
- 現在使っている製品と管理経路を棚卸しする
- 正常時のログと通信を記録する
- 不要な製品・経路を減らす
- 監査モードや検証環境で影響を確認する
- 必要な例外を整理してから段階的に制御する
「止める」より先に、「何が正常か」を把握することが重要です。
AD侵害が疑われたらフォレスト回復まで考える
ADの重要部分に影響が疑われる場合、単純にパスワードを変更して終わり、とは考えません。影響範囲、証拠保全、管理経路、資格情報、復旧順序を含めて判断します。
MicrosoftはWindows Server向けにActive Directory Forest Recoveryの手順を公開しています。平常時に、自組織ではどのバックアップから、どの順序で、どこまで復旧できるのかを確認しておくと、障害時・インシデント時の判断材料になります。
KRBTGTは通常運用の「定期2回リセット」ではない
旧版では「定期的に2回連続でリセット」としていましたが、この説明は修正します。
Microsoftのフォレスト回復手順では、復旧手順の中でKRBTGTパスワードを2回リセットし、既定設定ではリセット間に10時間待つよう案内しています。通常運用で機械的に2回繰り返すものとして説明するのは適切ではありません。
実施時は、Kerberosチケットの有効期間、DC間レプリケーション、復旧計画を確認します。
管理者向けチェックリスト
| 確認 | 項目 |
|---|---|
| □ | 承認済みRMM・バックアップ・遠隔管理ツールの一覧がある |
| □ | DCに本当に必要な管理ソフトだけが導入されている |
| □ | AD管理アカウントと日常利用アカウントを分離している |
| □ | DCを管理できる端末・接続元を限定している |
| □ | 管理ツールの追加や変更を把握できる |
| □ | DC、EDR、RMM、VPN、ID基盤のログを確認できる |
| □ | バックアップの正常時動作と復旧方法を確認している |
| □ | Active Directory Forest Recoveryを自組織向けに整理している |
まとめ
NTDS.ditの保護は、1ファイルだけを守る話ではありません。
ADを管理できる人、端末、RMM、バックアップ、EDR、ログ、復旧手順をひとつの管理経路として設計することが重要です。
正規ツールは業務に必要だからこそ、正常な使い方を先に定義し、そこから外れた動きを追える状態を作ることが、実務的な防御につながります。
公式情報・一次情報
- CISA ― Guide to Securing Remote Access Software
- Microsoft Learn ― Enterprise access model
- Microsoft Learn ― Active Directory Forest Recovery: Reset the krbtgt password
※Windows Server、バックアップ、EDR、RMMの構成によって適切な運用は変わります。本番環境の変更は、可用性と復旧要件を確認しながら段階的に検証してください。
この記事の更新履歴
この記事は、生成AIを活用した自動レビュー・更新フローにより内容を見直し、必要な修正を反映しています。
2026年9月13日
- 追加 現行のpapanda925標準レイアウトに合わせ、「この記事について」と検証ステータス、管理者向けチェックリスト、公式情報・一次情報を追加しました。
- 変更
NTDS.dit単体の攻撃手順中心の記事から、RMM・管理端末・バックアップ・EDR・ログ・復旧まで含むActive Directory管理経路の防御へ全面的に再構成しました。 - 変更 KRBTGTの説明をMicrosoftのActive Directory Forest Recoveryに基づく内容へ修正し、通常運用で機械的に2回リセットするものではないことを明確にしました。
- 削除 旧本文に残っていた内部プロンプト、未検証表記、具体的な
NTDS.dit抽出手順など、現在の公開ルールに合わない記述を削除しました。
