Active Directory 72時間パッチ運用ガイド
— 事故を出さずに、速く直す —

0なぜ72時間・なぜ事故が起きるか

72時間の根拠

DC の脆弱性（Netlogon・Kerberos・LDAP・証明書サービス系など）は、認証の中枢を突くため影響が甚大で、公表から悪用開始までが極めて短い。月例の定期パッチ枠では間に合わないクラスがある。だから「緊急」に区分したものは、通常運用と別レーンで72時間以内に適用する体制を用意する。

それでも急ぐと事故る——AD特有の落とし穴

1脆弱性情報を即座に受け取る — 72時間の時計を正しく始める

72時間は「アドバイザリを受け取った瞬間」から始まる。受信が半日遅れれば、締切も半日削られる。だが人が一次情報サイトを常時監視するのは不可能。ここは仕組み（プッシュ化・自動化）で解くのが唯一の正解。そして時間外・選任なしの現実に合わせ、「いつ叩き起こすか」「他業務を止めてでもやるか」を事前ルール化する。

1-1. 情報源 — 一次情報を押さえる

二次的なニュースやSNSは速いが玉石混交。判断は必ず一次情報で裏取りする。最低限これだけは受信経路に組み込む。

1-2. 人力では無理 → 「プッシュ化・自動化」する

常時監視を人に割り当てるのは非現実的（そして必ず見落とす）。情報が"向こうから届く"経路に変換し、人は届いたものを捌くだけにする。

• RSS／メール／API をチャット＋モバイル通知に変換：Teams／Slack の Webhook に流し込む。無償で組むなら Power Automate／Zapier／GitHub Actions の定期実行（cron）や小さな自作スクリプトで、MSRC・KEV のフィードを取得して通知するだけでも十分機能する。
• 脆弱性管理ツールがあれば最強：Tenable／Qualys／Rapid7 等は、資産インベントリと突き合わせて「自社に該当する脆弱性だけ」を通知してくれる（有償だが、選任がいない組織ほど効果が大きい）。
• キーワードで AD 関連だけ拾う：フィルタ語の例 —— Active Directory / Domain Controller / Windows Server / Netlogon / Kerberos / LSASS / NTLM / LDAP / AD CS（Certificate Services）。これらに Critical や Remote Code Execution が重なるものを最優先で浮かせる。

1-3. ノイズを減らす（自社該当だけを浮かせる）

• 資産インベントリと突合：自社が使う OS・製品・バージョンの一覧を持ち、それに一致するものだけを「要対応」に上げる。該当しない大量の CVE に埋もれないための土台（資産管理は別ガイドの識別ドメイン参照）。
• タグ付けして仕分け：受信時に「深刻度／KEV掲載の有無／回避策の有無／自社該当」を機械的にタグ付けし、次の優先順位付け（1-5）へ渡す。

1-4. 平日日中に出ない・選任がいない場合の運用

臨時公開（out-of-band）は日本時間の夜間・休日に出ることもある。「気づけない」を仕組みで潰す。

• 通知はスマホに届く経路へ：メールだけだと夜間に埋もれる。チャットのモバイルPush など、手元で気づけるチャネルを主にする。
• オンコール輪番（3名で週替わり）：全員が常時見る必要はない。「今週の一次覚知担当」を1名に集約し、責任の所在を明確にする。負担を回して疲弊を防ぐ。
• "叩き起こす"基準を事前定義：夜間・休日に即応（担当を呼ぶ）するのは 「臨時公開 かつ 自社該当 かつ 回避策なし」 のときだけ。それ以外は翌営業日の一次トリアージで十分。全部を夜間対応にすると人が持たず、かえって重要案件を取りこぼす。
• 定例と臨時を区別：月例（Patch Tuesday）は原則翌営業日のトリアージで足りることが多い。即時性が本当に要るのは臨時公開（out-of-band）。ここにリソースを集中する。
• 一次トリアージのSLA目安：定例＝次の平日営業時間内／臨時でKEV該当＝覚知後すみやかに着手（＝72時間の起点）。

1-5. 他業務との優先順位づけ（割り込み判断を機械化する）

選任がいない＝常に他業務と競合する。「割り込んででもやるか」を個人の胆力に委ねず、マトリクスで機械的に決める。閾値は上長と事前合意しておく（standing approval：緊急対応を都度稟議なしで始めてよい常設承認とセット）。

2事故を防ぐ「構成」

パッチ運用の安全性は、当てる前の"構成"で半分決まる。1台落ちても業務が止まらない土台を作る。

• DC は最低2台、可能なら3台以上：1台をパッチ・再起動している間、他のDCが認証・DNSを継ぎ、業務を止めずに片系ずつ適用できる。DCが1台の環境は、まずここから是正する（最重要）。
• クライアントのDNS/優先DCを分散：全端末が同じDCだけを向いていると、そのDC停止で影響が出る。プライマリ／セカンダリDNSを複数DCに分散設定。
• FSMO 役割の把握（FSMO：ドメイン全体で1台だけが持つ特殊な役割。PDCエミュレータ等）：役割保有DCは最後に適用する。必要なら適用直前に別DCへ一時移管する選択肢も持つ。
• 検証環境（ステージング）を持つ：本番と同構成の小さな検証ドメインを1つ。仮想1〜2台で十分。ここで先にパッチを当て、致命的な不具合を"本番前"に検知する。
• DCは役割を絞る：DC上に他の業務サービスを同居させない。同居があると「パッチ↔業務」の影響範囲が絡み合い、切り分けが難しくなる。
• 時刻同期の基準を固定：PDCエミュレータを時刻源に。パッチ後のログ突合・認証(Kerberos)の健全性に効く。

372時間を回す「体制」

締切のある作業は、事前に決めた"回し方"がないと属人化して事故る。兼任3名でも回る最小の体制を作る。

2-1. 事前に取り付けておくもの（平時の仕込み）

• 緊急変更の事前承認（standing approval）：「緊急区分のDCパッチは、規定手順に従う限り都度の稟議なしで臨時メンテを実施してよい」という経営・情シス責任者の常設合意。これがないと72時間は守れない。
• アドバイザリの購読：ベンダーのセキュリティ更新情報と JPCERT/CC 注意喚起を購読し、公表を即座に受け取る（見落としが時計のスタートを遅らせる）。
• メンテナンス時間帯の合意：業務影響を最小化する時間帯（夜間・早朝）を事前に業務部門と合意。72時間内であれば深夜帯を選べる。
• 連絡・広報テンプレ：万一業務影響が出た場合の一次連絡文面を用意しておく。

2-2. 役割（3名で兼任）

4パッチ運用のライフサイクル

72時間の中を、6つのステップに分けて回す。各ステップに「完了の目印」を置き、飛ばさない。

5適用前の準備（土台）— ここを省くと戻せなくなる

• System State バックアップを取得：適用直前に、対象DCのシステム状態（AD DB・SYSVOL・レジストリ等の復元に必要な一式）をバックアップ。DC復旧の正攻法はスナップショット復元ではなくこのバックアップからのリストア。
• 正常時の状態を"記録"しておく：適用前に repadmin /replsummary と dcdiag を実行し、「正常な状態」を先に保存。適用後との差分で異常を判定できる（ベースライン）。
• スナップショットは「補助」かつ慎重に：現代のハイパーバイザーは仮想マシン生成ID（VM-GenerationID）に対応し、DCのスナップショット復元をある程度安全に扱えるが、過信しない。復旧の第一手段は System State リストアと位置づける。
• 変更記録を起票：対象KB・順序・実施者/確認者・開始/終了時刻・ロールバック条件を1枚に。72時間の証跡そのものになる。
• ロールバック手順を先に決める：「何が起きたら戻すか（＝中止条件）」を適用前に文章で確定（→ 10章）。渦中で決めると判断を誤る。

6段階適用（リング方式）— 速さと安全の両立点

「速く」を担保するのが段階適用。一気に当てないことが、実は最速で安全に完了する道。

各リングの鉄則

• 1台ずつ・順番に。前のDCが「確認合格」するまで次に進まない。並行適用しない。
• 先行1台は少し"寝かせる"：適用・再起動後、認証やレプリケーションを一定時間（可能なら数十分〜数時間）観察してから次へ。時間差が、遅発する不具合を捕まえる。
• 常に「既知正常機」を1台残す：全DCを更新し切る直前まで、未適用の正常なDCを1台残す。何かあっても認証の継続点になる。
• 再起動の間隔を空け、レプリケーション収束を待つ：再起動後は repadmin /replsummary でエラー0を確認してから次へ。

7ツール

配布・適用・確認・監視の各段を、環境規模に合ったツールで支える。小規模なら無償の標準機能で十分回る。

8適切に適用されたかの確認

「再起動できた＝OK」ではない。①パッチが入ったか ②ADが健全か ③業務が動くかの3層で確認する。各DCで適用直後に必ず実施。

7-1. パッチが適用されたかの確認

# 対象KBが入っているか
Get-HotFix -Id KB1234567

# OSビルド番号を確認（更新で上がる）
winver
# または
[System.Environment]::OSVersion.Version

# 直近の更新履歴
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5

7-2. AD が健全かの確認（最重要）

# DCの総合診断（各種テストを一括実行）
dcdiag /v

# レプリケーションの要約。エラー列が 0 であること
repadmin /replsummary

# このDCのレプリケーション詳細（失敗が無いか）
repadmin /showrepl

# レプリケーションを手動で走らせて疎通確認
repadmin /syncall /AdeP

# SYSVOL(DFSR)の状態
dfsrdiag ReplicationState

# 重要サービスが起動しているか（NTDS/DNS/Netlogon/KDC）
Get-Service NTDS,DNS,Netlogon,kdc | Format-Table -Auto

7-3. 業務が動くかの確認（機能テスト）

• 認証テスト：テスト用アカウントで実際にログオンできる。
• DNS 解決：nslookup で当該DCを指定し、名前解決が返る。
• GPO 適用：クライアントで gpupdate /force → gpresult /r でポリシーが適用される。
• イベントログ：Directory Service / DNS Server / System ログに、再起動後の新規エラー・警告が出ていない（イベントビューアーで applied 後の時刻以降を確認）。

# 再起動後に出た Directory Service のエラー/警告を確認
Get-WinEvent -LogName 'Directory Service' -MaxEvents 50 |
  Where-Object LevelDisplayName -in 'Error','Warning'

972時間プレイブック（時系列の型）

実際の時計の進め方の一例。夜間メンテを織り込みつつ、確認に時間を使う余裕があると分かる。

10ロールバックと事故時対応

9-1. 中止条件（適用前に決めておく）

• 先頭DCで dcdiag が failed、repadmin にレプリケーション失敗、NTDS/DNS/Netlogon が上がらない。
• 認証・ログオン・DNS 解決に業務影響が観測された。
• この場合、次のDCへ進めず、その場で切り分け・是正 or ロールバックに切り替える。

9-2. 戻し方（軽い順に）

9-3. 業務影響が出た場合

• まず健全DCへ寄せて影響を止める（原因究明より復旧優先）。
• 事前テンプレで業務部門・責任者へ一次連絡。
• 収束後、原因・時系列・再発防止を記録（次回のトリアージ精度が上がる）。

11適用できない場合の例外運用

互換性・業務都合で72時間内に当てられないケースは必ず出る。放置せず"意識的に受容する"手順にする。

• 回避策（緩和策）を先に打つ：ベンダーが示す一時緩和（機能の無効化・対象ポートの遮断・攻撃元の制限）を適用し、パッチまでの露出を下げる。
• リスク受容の記録：適用を遅らせる場合、理由・代替緩和・再適用の期限・承認者を明文化する。黙って先送りにしない（監査・内部監査で必ず問われる点）。
• 監視を上げる：未適用の間、当該脆弱性を突く挙動の監視を強化する。
• 外部公開面の即時確認：DC やその周辺が外部から到達可能でないか（本来到達不可のはず）を再点検する。

12チェックリスト

平時に整えておく（構成・体制）

• □ DC が最低2台（できれば3台）ある／クライアントのDNSが複数DCに分散
• □ FSMO 役割の保有DCを把握している
• □ 検証（ステージング）環境がある
• □ 緊急変更の事前承認（standing approval）を得ている
• □ アドバイザリと JPCERT/CC を購読している
• □ メンテ時間帯・連絡テンプレを用意している
• □ System State バックアップの取得・リストアを演習済み

適用の都度（毎回この順で）

• □ トリアージ（該当KB・深刻度・回避策・既知不具合）と72h起点の記録
• □ System State バックアップ取得＋正常ベースライン記録（dcdiag/replsummary）
• □ 中止条件・ロールバック手順を明文化
• □ Ring 0（検証）→ Ring 1（先行1台）→ 確認→ 寝かせる
• □ Ring 2（残り・1台ずつ）→ 各台確認／既知正常機を1台残す
• □ Ring 3（FSMO保有）を最後に適用・確認
• □ 各DCで3層確認（パッチ／AD健全性／機能テスト）合格
• □ 全DCの適用バージョン・確認結果・所要時間を記録・保管

13用語集