WSUSの自動承認は、コンソールのOptions → Automatic Approvals → New Ruleで、製品、分類、対象コンピューターグループ、必要に応じて期限を指定します。ただし本番全端末へSecurity/Criticalを即時自動承認するのではなく、まず検証リングだけへ自動承認し、成功と既知問題を確認してから先行・本番へ進めます。未承認だと配布されないのは基本ですが、承認済みでも同期、コンテンツ、クライアントGPO、検出、適用条件、再起動が整わないと入りません。
Deadlineは「承認を早める」だけでなく、端末で強制適用・再起動を招く可能性があります。重要サーバーへ一般PCと同じ期限を設定しません。
自動化する範囲を決める
更新分類ごとのリスクを整理します。Security Updates、Critical Updates、Updates、Definition Updates、Update Rollups、Upgrades、Drivers等を同じルールへ詰め込みません。Defender定義は短いサイクル、品質更新はリング、機能更新とドライバーは個別承認などに分けます。
対象製品も実在インベントリと照合します。Windows 11、Windows Server、Microsoft 365 Apps等で別ルールを作り、旧製品やPreviewを含めません。製品・分類を追加したら初回同期量と自動承認への影響を事前評価します。
コンピューターグループを準備する
Pilot、IT、Broad、Critical Servers等のWSUSグループを作り、端末割り当て方法を決めます。Client-side targetingではGPOのターゲット名とWSUS側を一致させます。端末がUnassigned Computersに残っている状態で本番ルールを作らないようにします。
パイロットには各OSビルド、言語、CPU、主要アプリ、VPN、プリンター、セキュリティ製品を代表する端末を含めます。情シスPCだけでは一般利用者権限や業務アプリの不具合を拾えません。
自動承認ルールを作る
- WSUS Administration ConsoleでOptionsを開きます。
- Automatic Approvalsを開き、Update RulesでNew Ruleを選びます。
- When an update is in a specific classificationを選び、対象分類を限定します。
- When an update is in a specific productを選び、対象製品を限定します。
- Approve the update for a specific groupでPilotだけを指定します。
- 必要な場合だけdeadlineを選び、ルール名、説明、所有者を記録します。
ルール名には製品、分類、対象、期限を含めます。条件を選ばず「すべての更新」を自動承認するルールを作りません。作成後にRun Ruleを実行すると既存の該当更新にも適用されるため、件数と範囲を確認してから実行します。
Revisionの自動承認
Automatic ApprovalsのAdvancedで、既に承認済み更新の新しいrevisionを自動承認する設定があります。メタデータ修正へ追随できますが、改訂内容を監査する要件と比較します。失効した更新を自動拒否する設定も、置換関係と例外を確認します。
承認状態は更新本体だけでなくrevision、置き換え、失効により変わります。WSUSレポートで何がどのルールにより承認されたかを記録し、手動承認との責任を分けます。
Deadlineの考え方
期限はセキュリティSLAを守るために使えますが、利用者通知、アクティブ時間、再起動ポリシー、クラスター/サーバー保守と組み合わせます。期限前にパイロット期間を確保できない日付を設定しません。時間帯とタイムゾーンも確認します。
ドメインコントローラー、ファイルサーバー、Hyper-V、RDS、業務DBを同時再起動させないよう、サーバーグループとオーケストレーションを分けます。WSUSの自動承認だけでクラスター順序やアプリ停止を管理しません。
ルールを検証する
- 対象製品・分類の更新だけがPilotへ承認される
- Preview、Driver、Feature Updateが意図せず入らない
- 更新ファイルがダウンロード完了している
- Pilot端末が検出・インストール・再起動・報告する
- 業務回帰テストと既知問題確認が完了する
- 期限、通知、再起動が利用者・サーバー方針どおり
自動承認後は、更新一覧のApproval、Needed、Installed/Not Applicable、Failedを確認します。承認件数が0なら同期や条件、製品/分類の選択を確認します。承認済みなのに0台適用なら、端末割当、GPO、対象OS、置換、前提更新、コンテンツを切り分けます。
本番へ進める方法
WSUSの自動承認ルール単体には「Pilot成功後に自動でBroadへ昇格」という高度なゲートがないため、手動承認、別ルールの実行日、管理自動化を設計します。成功率、重大インシデントなし、アプリ所有者承認をゲートにします。
PowerShell/APIで承認を自動化する場合は、対象更新ID、revision、グループ、分類、期限を読み取りで一覧化し、承認前レビューと監査ログを実装します。管理者秘密をスクリプトへ埋め込みません。
問題が出た場合
ルールを無効化し、追加自動承認を止めます。該当更新の承認をNot approvedまたはRemoval等へ変える判断はMicrosoftサポート条件を確認します。既にインストール済み端末は承認変更だけでは戻らないため、Known Issue Rollback、修正版、アンインストールを限定検討します。
どのルールが誤承認したか、製品・分類条件、Run Rule時刻、対象グループ、deadlineを保全します。ルールを削除して証跡を失わず、まず無効化してエクスポート/画面記録します。
月次レビュー
ルール所有者、製品、分類、グループ、期限、最終実行、承認件数、失敗率、例外を確認します。廃止OSのルールを削除し、新OSを追加する際はパイロットから始めます。自動承認によりレビュー工数を減らしても、既知問題確認と復元訓練は省略しません。
自動承認しない更新
Preview、Drivers、Upgrades、機能更新、ファームウェア、置換関係が複雑な更新は、組織の検証なしに自動承認しないのが安全です。特にドライバーは機種、PnP ID、OEMカスタマイズへ依存し、広い製品条件で別機種へ配ると起動・ネットワーク障害になり得ます。メーカー配布や管理製品と責任を分けます。
更新タイトルの文字列だけを条件にする非公式スクリプトは、名称変更や言語差で誤判定します。WSUS APIの製品、分類、UpdateID、Revision、失効、置換属性を使い、読み取りレポートを人が確認してから承認します。
同期失敗時の挙動
自動承認ルールがあっても、同期が失敗すれば新しい更新は取り込まれません。最終同期成功時刻、上流、TLS、プロキシ、DB、コンテンツダウンロードを監視し、承認件数が少ないことを平穏と誤解しません。月例公開日に期待更新数との差分を確認します。
メタデータだけ承認されコンテンツ未取得の場合、端末はダウンロードできません。WSUSContent容量、IIS、BITS、上流通信、EULAを確認します。再同期を連打せず最初のエラーを保全します。
例外端末と保留期限
業務都合で本番リングから外す端末には、理由、所有者、代替対策、期限、次回検証日を設定します。更新失敗端末を恒久的な除外グループへ移さず、修復、再イメージ、製品更改へ進めます。脆弱性悪用が確認された場合は隔離を含む緊急判断を行います。
監査用レポート
毎月、ルール一覧、承認更新、該当製品・分類、対象グループ、deadline、インストール率、失敗、未報告、例外、切り戻しを保存します。自動承認された事実だけでなく、誰がルールを変更し、どの検証ゲートを通過したかを変更管理と結び付けます。
コメント