OSとソフトウェアの更新を管理する機能です。セキュリティー対策の基礎であり、多くの組織でNinjaOne導入の主目的になります。個別のOS設定に入る前に、全体の流れと設計上の判断点を押さえてください。
パッチ適用の全体の流れ
処理は4つの段階に分かれます。
| 段階 | 内容 |
|---|---|
| スキャン | デバイスに未適用の更新があるかを調べる |
| 承認 | どの更新を適用するかを決める |
| 適用 | 承認された更新をインストールする |
| 再起動 | 適用を有効にするために再起動する |
スキャンと適用は別のスケジュールで設定します。スキャンだけしていて適用の設定を忘れる、という設定漏れが起こりやすいので注意してください。
4番目の再起動を軽視しないでください。再起動していない更新は適用されていないのと同じです。一覧上は適用済みに見えても、実際には有効になっていない状態が発生します。
各更新は、この流れの中で5つの状態のいずれかを取ります。
| 状態 | 位置付け |
|---|---|
Pending | スキャンで検出されたが、まだ承認されていない |
Approved | 承認済み。配信を待っている |
Rejected | 配信しないと判断された |
Installed | 適用が完了した |
Failed | 適用に失敗した |
状態別の確認方法はPatch Intelligence AIと適用状況の確認で扱います。
対応範囲
OSの更新
Windows、macOS、Linuxのそれぞれに対応しますが、仕組みと制約は異なります。
| OS | 特徴 |
|---|---|
| Windows | 最も細かく制御できる。承認や除外の設定が豊富 |
| macOS | OSの仕様上、制御できる範囲に制限がある |
| Linux | ディストリビューションのパッケージ管理に依存する |
同じ設定を全OSに適用することはできません。Policyを分ける必要があります。
サードパーティー製ソフトウェアの更新
ブラウザーやランタイムなど、OS以外のソフトウェアも更新できます。Third-Party Patchingと呼ばれる機能です。
脆弱性の多くはサードパーティー製ソフトウェアで発生します。OSの更新だけを管理していても、リスクの大部分は残ります。詳細はThird-Party PatchingとWinGet連携を参照してください。
Policyとの関係
パッチの設定はPolicyの中にあります。したがって、そのPolicyが適用されている全デバイスに同じ設定が効きます。
ここから、Policyを分ける必要性が明確になります。
| デバイスの性質 | 必要な設定 |
|---|---|
| クライアント端末 | 業務時間外に適用し、利用者に通知して再起動 |
| 一般サーバー | 計画された時間帯に適用し、自動で再起動 |
| 基幹サーバー | 適用を保留し、計画停止時に手動で実施 |
再起動の可否がPolicyを分ける最も大きな理由です。設計はPolicyとは：設計の考え方を参照してください。
導入前に決めておくこと
設定を始める前に、次の5点を決めてください。
- 適用のサイクル（毎週か、月次か）
- 再起動を許容できる時間帯（デバイスの区分ごと）
- 承認の方針（自動承認か、確認してから適用か）
- 検証環境を設けるか
- 適用状況を誰がいつ確認するか
3番目は重要です。全て自動承認にすると運用は楽ですが、問題のある更新が全台に配信されるリスクがあります。逆に全て手動承認にすると、承認作業が滞って適用されないまま放置されます。
多くの組織では、セキュリティー更新は自動承認、機能更新は手動承認、という切り分けが現実的です。
導入直後に起きること
Agentを展開した直後は、大量の未適用更新が検出されます。これは正常です。
いきなり全台に適用しないでください。次の順で進めます。
- 検証用のデバイス数台で適用し、問題がないことを確認する
- 影響の小さい部署から段階的に広げる
- 業務時間外に実施し、翌営業日に問題がないか確認する
- 問題がなければ全体に展開する
【注意】 長期間更新されていなかったデバイスでは、適用に時間がかかり、複数回の再起動が必要になることがあります。導入初回の適用は、業務への影響が少ない期間に計画してください。
適用状況の確認
適用の結果は必ず確認してください。設定しただけで適用されていると思い込むのが、最も多い失敗です。
確認する内容はPatch Intelligence AIと適用状況の確認で扱います。