パッチ管理とSLA

優先順位付けによって何を修正すべきかが分かります。パッチ管理は、実際にそれらの修正を期日どおり、環境全体にわたって完了させるための、規律あるプロセスです。

SLA（サービスレベル合意）は、重要度ごとに修正を完了させるべき期間を定めます。SLAがなければ、緊急の修正は先送りされ、説明責任も失われます。

再現可能なサイクルによって、システムを最新の状態に保てます:

• 利用可能なパッチを特定します（ベンダーのアドバイザリ、スキャン結果）。
• 適用の関連性とリスクを評価します。
• 非本番環境でテストします。
• 管理された段階的な展開でデプロイします。
• パッチが適用され、システムが正常であることを検証します。

各ステップに担当者と証跡を割り当て、より広いVMライフサイクルと対応させます。

SLAは意図を期限に変えます。発見から修正までに許される最大時間を、重要度に応じて段階的に設定します。目標の例:

• 重大 / KEV: 7～15日（インターネットに公開されている場合はさらに短く）。
• 高: 30日。
• 中: 90日。
• 低: ベストエフォート / 次回サイクル。

SLAsによって滞留期間を測定可能にし、認識するだけでなく、完了させるためのプレッシャーを生み出します。

期限はCVSSだけでなく、実際のリスクに結び付けます。KEVに登録されている、またはインターネットに公開されている重大な脆弱性には、内部向けの中程度の脆弱性よりも短いSLAを設定します。

参考となるフレームワークもあります。CISAは連邦政府機関に対し、設定された期限内にKEVの修正を義務付けています。また多くの企業は、CVSSに関係なく、実際に悪用されている脆弱性について同様に短縮されたタイムラインを採用しています。

パッチによって問題が発生することがあります。テストをステージングで行うことで、本番環境に影響する前にリグレッションを検出できます:

• まず代表的なテストグループに適用します。
• 重要な機能と性能を検証します。
• 既存のソフトウェアとの競合がないことを確認します。

速度と安全性のバランスを取ります。実環境で悪用されているKEVの場合は、通常の更新よりも多くのリスクを受け入れ、より迅速にパッチを適用します。

段階的に（リングデプロイ）展開します。まずパイロットグループ、次により広いリング、最後に全体へ展開します。各リングで健全性を監視してから次に進みます。

常にロールバック計画を用意します。スナップショット、パッケージのダウングレード、または設定の復元などです。パッチによって障害が発生した場合は、調査中でも迅速に元へ戻せなければなりません。

手動パッチ適用では規模に対応できません。集中管理ツールを使用します:

• WindowsにはWSUS / SCCM / Intune。
• Linuxフリートには構成管理（Ansible, Puppet, Chef）。
• クラウドとコンテナには、パッチを適用して再構築したゴールデンイメージ／ベースイメージ。

自動化によって一貫性を確保し、パッチのリリースからデプロイまでの時間を短縮できます。

ベンダーの対応待ち、脆弱なレガシーシステム、または必要な稼働率のために、すぐにパッチを適用できない場合があります。その間は代替制御を適用してリスクを低減します:

• ネットワークのセグメンテーション／ファイアウォールルール。
• WAFまたはIPSシグネチャによる仮想パッチ。
• 脆弱な機能またはサービスの無効化。

これらは時間を稼ぐ手段であり、実際の修正を恒久的に置き換えるものではありません。

サポート終了システムには、パッチがまったく提供されない場合があります。選択肢は次のとおりです:

• 制限されたネットワークセグメントに隔離します。
• 厳格なアクセス制御と監視で保護します。
• 期限を設けて移行または廃止を計画します。
• 有効期限付きで残余リスクを正式に受け入れます。

すべてを文書化します。パッチを適用できないシステムを文書化せずに放置すると、監査上のリスクや侵害のリスクになります。

プログラムが実際に約束を果たしているかを追跡します:

• 重要度別のMTTRとSLA目標の比較。
• SLA遵守率（期限内にクローズされた割合）。
• チーム別および資産別の期限超過／滞留中の検出結果。
• パッチ適用率（最新状態にあるフリートの割合）。

担当チーム別に報告することで、説明責任を明確にし、対応の遅い領域に注意を向けます。

デプロイ後に検証します。再スキャンしてCVEが解消され、システムが正常であることを確認し、証跡とともに検出結果をクローズします。繰り返し発生する問題（何度も再発するライブラリや、慢性的に遅れているチーム）は、プロセス改善に反映します。

適切に行われたパッチ管理は、優先順位付けされたリスクを、測定可能で期限どおりのリスク低減へと変えます。

修正SLAの役割を確認します。

パッチ管理では、特定、評価、テスト、段階的なデプロイ、検証を通じて、優先順位付けされた検出結果を修正完了まで導きます。ロールバック計画と自動化がこれを支えます。SLAは重要度とリスクに応じた期限を設定し、KEVやインターネット公開資産にはより短い期限を設けることで、修正を期日どおりに完了させます。

パッチ適用が不可能な場合は、代替制御と、期限を区切って文書化したリスク受容を使用します。MTTR、SLA遵守率、適用範囲を測定し、得られた教訓をライフサイクルに反映します。