¶ ADセキュリティ基本
¶ 🧭 このページについて
Active Directory（AD）は、組織の認証・認可を担う中核基盤である。
そのため、攻撃者にとっても「侵入できれば横展開しやすい」最重要ターゲットになる。
本ページでは、専門ツールに依存せず、AD運用で最低限押さえるべきセキュリティの基本を、
「やること（対策）」「よくある落とし穴（事故パターン）」「確認の観点」まで含めて整理する。
（Tierモデル、PAW、特権ID管理、監査高度化などは別ページで扱う）
¶ 🗺 ADセキュリティの全体像（入口）
¶ 👤 1. アカウント管理（まず事故を減らす）
ADはアカウントが全ての起点になる。
「不要アカウントを減らす」「権限を分離する」だけで事故が減る。
¶ ✅ やること（基本）
- 退職者・異動者・不要アカウントは速やかに無効化する
- 共有アカウントは作らない（作るなら用途限定・期限付き）
- 管理者用アカウントと通常業務アカウントを分ける
- サービスアカウントは用途ごとに分ける（使い回さない）
¶ ⚠ よくある落とし穴（典型）
- 退職者アカウントが放置され、侵入経路になる
- 「とりあえず作った共有アカウント」がずっと残る
- 管理者アカウントを普段使いして端末感染→AD全体へ波及
¶ ✅ 確認の観点
- 使われていないアカウントが棚卸しされているか
- “管理作業は管理アカウントだけ” が徹底できているか
¶ 🛡 2. 特権（管理者権限）は最小にする
ADの事故は「特権の漏洩」が致命傷になりやすい。
Domain Admins を増やすほど、攻撃者の当たりが増える。
¶ ✅ やること（基本）
- Domain Admins / Enterprise Admins は最小人数にする
- 日常作業と管理作業を分離する（アカウント分離）
- 管理作業は “必要な時だけ” 昇格できる形に寄せる（運用ルールでも可）
- 管理作業をする端末を分ける（最低でも「普段使いPCで管理しない」）
¶ ⚠ よくある落とし穴（典型）
- 便利だから Domain Admins に入れてしまう
- 管理者がブラウザ・メール・チャットのPCで管理作業をしてしまう
¶ ✅ 確認の観点
- 特権グループのメンバーが説明可能か（なぜ必要か）
- “管理作業をする端末” が決まっているか
¶ 🔑 3. 認証（Kerberos/NTLM）を理解する
¶ ✅ Kerberosが基本
ADの標準認証。
時刻がずれると認証が失敗する（一般的に許容は5分以内）。
¶ ✅ NTLMは可能なら減らす
互換性のために残ることがある。
ただし利用範囲が広いほどリスクは増える。
¶ ⚠ よくある落とし穴（典型）
- 時刻同期が崩れてログオン障害が起きる
- NTLMを広く許容し続けてしまう
¶ ✅ 確認の観点
- 時刻同期（NTP）が運用で監視されているか
- NTLMが必要な範囲が把握できているか
¶ 🔒 4. 通信（LDAP/LDAPS）を暗号化する
LDAP（389）は平文通信。
アプリ連携や機器連携が増えるほど、平文LDAPは攻撃面になる。
¶ ✅ やること（基本）
- 可能なら LDAPS（636）を標準にする
- アプリ連携（NAS/機器/Web）も LDAPS 前提に統一する
- 証明書（AD CS 等）とセットで運用する
¶ ⚠ よくある落とし穴（典型）
- Simple Bind を平文LDAPで許可してしまう
→ 資格情報漏洩リスクが高い - 証明書期限切れでLDAPSが止まり、アプリ認証が落ちる
¶ ✅ 確認の観点
- どのシステムがLDAPを使っているか一覧化されているか
- 証明書期限の管理がされているか
¶ 🖥 5. 端末・サーバ（GPO/ローカル管理者）が最後に効く
ADの設計が良くても、端末の管理が弱いと突破される。
¶ ✅ やること（基本）
- ローカル管理者を乱立させない
- 端末の設定をGPOで統一する（最低限でOK）
- DCや管理端末は特に堅くする（不要ソフトを入れない）
¶ ⚠ よくある落とし穴（典型）
- ローカル管理者が大量に存在し、横展開が容易になる
- GPOが現場ごとにバラバラで、原因追跡ができない
¶ ✅ 確認の観点
- 管理者権限の端末配布が統制されているか
- GPOが“追加しっぱなし”になっていないか（棚卸し）
¶ 🧾 6. 監査・ログ（検知できないと守れない）
「守る」だけでなく「気づける」ことが重要。
DCのイベントログは最低限定期確認する。
¶ ✅ やること（基本）
- 重要操作がログに残る設定にする（運用ルールでも可）
- DCのイベントログを定期確認する（まずは週1でも）
¶ ✅ 見るログ（基本セット）
- Security（認証失敗・特権利用の兆候）
- Directory Service（AD DS関連）
- DNS Server（SRV登録/名前解決の兆候）
- System（時刻同期・サービス停止・基盤障害）
¶ ⚠ よくある落とし穴（典型）
- ログはあるが、誰も見ていない
- 異常に気づくのが「止まってから」
¶ ✅ 確認の観点
- “どのログを誰がいつ見るか” が決まっているか
- 異常時の連絡先・判断基準があるか
¶ 7. バックアップと復旧（最後の砦）
ADは「壊れたら終わり」にしない設計が必要。
¶ ✅ やること（基本）
- 復旧手順（誰が・何を・どの順で）を決めておく
- バックアップは定期実行する
- 復旧に必要な情報（構成/権限/証明書など）を文書化する
¶ ⚠ よくある落とし穴（典型）
- バックアップはあるが、戻し方が分からない
- 重要な証明書や構成が属人化している
¶ ✅ 確認の観点
- “復旧できる” を一度は検証しているか（机上でも可）
- 復旧に必要な情報がWikiに揃っているか
¶ ✅ まとめ（最低限ここだけ押さえる）
ADセキュリティは、難しいことをやるより先に次を守る。
- 特権を絞る（Domain Adminsを増やさない）
- 管理用アカウントを分離する（普段使いしない）
- 通信を暗号化する（LDAPS）
- 端末とGPOで統一する（ばらつきを減らす）
- ログを見て気づけるようにする（Security/System/Directory Service/DNS）
- 復旧できる状態にする（バックアップ＋手順）
この基本ができているだけで、事故の確率は大きく下がる。