パッチ管理SLAの作り方｜「緊急・重要・通常」3段階で回す現実的運用設計

そもそもパッチ管理とは、ソフトウェアの脆弱性やバグを修正するパッチ（修正プログラム）を、組織内のシステムやIT資産に計画的に適用・管理するプロセスです。サイバー攻撃の多くは既知の脆弱性を悪用するため、迅速なパッチ適用は企業を守るセキュリティ対策の根幹と言えます。

しかし、このパッチ管理に明確なSLAがないと、以下のような問題が生じます。

SLAを導入する最大のメリットは、脆弱性対応の基準を客観的かつ明確にできる点です。「どのレベルの脆弱性を」「いつまでに対応するか」を定義することで、組織全体で共通認識を持つことが可能になります。

これにより、リスクに基づいた優先順位付けが正当化され、リソースを効率的に配分できます。さらに、ISMS（情報セキュリティマネジメントシステム）認証や外部監査においても、SLAに基づいた運用記録はコンプライアンスを遵守していることの強力な証明となります。

効果的なSLAを策定するには、まず自社のセキュリティポリシーに基づいた優先順位付けが重要です。すべてのパッチを同じ速度で適用しようとすると、現場が疲弊し運用が破綻します。

そこで現実的なアプローチが、「緊急」「重要」「通常」の3段階で脆弱性の深刻度を分類し、それぞれに異なるSLAを設定する方法です。これにより、限られたリソースを最もリスクの高い脆弱性対策に集中させ、効率的なパッチ管理が実現します。

「緊急」に分類されるのは、放置すれば事業継続に致命的な影響を与えかねない、最も深刻な脆弱性です。これらはインシデント管理の一環として、最優先で対応する必要があります。

判断基準は、世界共通の脆弱性評価システムCVSSのスコアが「緊急（Critical）」レベル（9.0-10.0）であること、攻撃コードが公開されていること、そして自社の公開サーバーや基幹システムなど重要なIT資産に影響を及ぼすこと、などが挙げられます。

SLA目標は、発見から「24時間〜72時間以内」のパッチ適用完了が一般的です。CSIRT等の専門チームと連携し、迅速な影響範囲の特定、検証、適用を進めます。業務時間外の緊急対応も想定した運用体制が不可欠です。

「重要」に分類されるのは、即時対応は不要なものの、放置すれば大きなセキュリティリスクとなる脆弱性です。CVSSスコアが「警告（High）」レベル（7.0-8.9）に該当するものや、将来的に悪用される可能性が高いものが対象となります。

SLA目標は「14日以内」や「30日以内」など、計画的な対応が可能な期間を設定します。緊急対応とは異なり、事前の影響調査やテストを入念に行う時間を確保できます。通常の定期メンテナンスに組み込み、システムへの影響を最小限に抑えながら適用を進めるのが一般的です。

「通常」に分類されるのは、リスクが比較的低く、急ぐ必要のない脆弱性や、機能改善・安定性向上を目的としたアップデートです。CVSSスコアが「注意（Medium）」以下（6.9以下）のものが該当します。

SLA目標は「90日以内」や「次回の定期メンテナンス時」など、比較的長い期間を設定します。四半期に一度のメンテナンスで他のパッチとまとめて適用し、運用コストを抑制します。このレベルのパッチ管理は、パッチ管理ツールを活用して自動化し、より深刻度の高い脆弱性へ人的リソースを集中させることが推奨されます。

SLAを定義しただけでは、パッチ管理は機能しません。目標を確実に達成するため、一貫した運用プロセスと明確な体制の構築が不可欠です。パッチ管理は一般的に「情報収集」→「評価・分析」→「テスト」→「適用」→「確認」というサイクルで運用します。

このサイクルを円滑に進めるため、各ステップの役割と責任者を明確化し、文書化して共有することが、安定したパッチ管理ポリシーの基盤となります。

正確な情報を迅速に収集することがパッチ管理の出発点です。JVN (Japan Vulnerability Notes) やNVD (National Vulnerability Database) といった公的機関のデータベース、OSやソフトウェアベンダーのセキュリティ情報を常に監視する仕組みが必要です。

同時に、管理すべきIT資産を正確に把握することが大前提です。どのサーバーに何のソフトウェアがインストールされているかなど、IT資産管理が不十分では対応漏れにつながります。IT資産管理ツールを活用し、常に最新の情報を維持しましょう。

収集した脆弱性情報と自社のIT資産情報を照合し、リスクを評価するフェーズです。ここで前述した「緊急」「重要」「通常」の3段階へ分類（トリアージ）します。

評価の際は、CVSSスコアといった技術的な深刻度だけでなく、「ビジネスインパクト」の観点も加味することが極めて重要です。例えば、CVSSスコアは中程度でも、会社の基幹システムに関する脆弱性であれば、優先度を「重要」に引き上げる、といった判断が求められます。

本番環境に適用する前に、必ずテスト環境で事前検証を行います。パッチ適用により、既存システムが正常に動作しなくなる可能性があるためです。特に基幹システムへのパッチ適用は、入念なテストが事業継続の観点から不可欠です。

テスト完了後、適用日時、作業手順、担当者、関係部署への通知方法、そして問題発生時の切り戻し計画などを明確にした適用計画を策定します。

計画に基づき、本番環境へパッチを適用します。クライアントPCなど台数が多い場合は、専用ツールで自動化することで、効率化と適用漏れ防止が実現できます。

パッチ適用後は、システムが正常に動作しているかを確認し、適用状況を台帳などに正確に記録します。この記録は、SLAを遵守していることを示す証跡となり、後の監査対応でも重要な役割を果たします。

パッチ管理の運用とSLAは、企業のコンプライアンス遵守において非常に重要な要素です。ISMSの国際規格であるISO 27001や、NISTサイバーセキュリティフレームワークなど、多くのガイドラインで技術的な脆弱性管理が明確に要求されています。

これらのフレームワークでは、「脆弱性を識別し、リスクを評価し、適切な対策を期限内に実施すること」が求められます。ここで定義されたSLAは、脆弱性対応の「期限」の根拠となり、組織として体系的なリスク管理を行っていることを示す客観的な証拠となります。

内部・外部監査では、「パッチ管理のポリシーは存在するか」「SLAは遵守されているか」「運用記録は適切か」といった点が厳しくチェックされます。明確なSLAとそれに基づく運用記録は、企業のセキュリティガバナンスの高さを証明します。

理想的なパッチ管理を目指す上で、多くの企業が直面する共通の課題と解決策を紹介します。

正確なインベントリ情報がなければ、どのシステムにパッチを適用すべきか判断できません。 【解決策】 IT資産管理ツールやMDM（モバイルデバイス管理）ツールを導入し、常に最新の資産情報を自動的に収集・可視化する体制を整えます。

特に独自開発システムは影響範囲の特定が難しく、担当者が適用を躊躇しがちです。 【解決策】 本番環境を模した検証環境を整備し、事前テストのプロセスを標準化します。また、段階的に適用範囲を広げるアプローチも有効です。

手動でのパッチ管理は継続的な努力が必要で、担当者の負担が非常に大きくなります。 【解決策】 パッチの配布や適用状況の確認を自動化するツールの導入が最も効果的です。EDR等のセキュリティソリューションと連携させれば、脆弱性検知から対応までをよりシームレスに行えます。

効果的なパッチ管理（Patch Management）は、サイバー攻撃から企業を守る根幹的なセキュリティ対策です。その運用を現実的かつ持続可能なものにするには、「緊急」「重要」「通常」といった段階的なSLA（サービスレベル目標）の策定が不可欠です。

SLAを設けることで、対応の優先順位が明確になり、限られたリソースを最重要の脆弱性対策に集中させることができます。また、明確なポリシーと運用プロセスは、属人化を防ぎ、コンプライアンスや監査への対応力を強化します。

完璧な体制を最初から目指すのではなく、まずは自社のIT資産を正確に把握し、クリティカルな脆弱性だけでもSLAを定めて運用を始めることが重要です。この機会に自社の運用体制を見直し、より強固なセキュリティ基盤の構築へ一歩を踏み出してみてはいかがでしょうか。

A1: SLAの目標期間は、企業の事業内容、システム環境、許容リスクレベルによって異なります。記事で紹介した「緊急：24～72時間」「重要：14～30日」「通常：90日以内」は一般的な目安です。自社のリソースやテストにかかる時間などを考慮し、現実的に達成可能な目標を設定することが重要です。

A2: ゼロデイ脆弱性（修正パッチが未提供の脆弱性）が発見された場合、通常のパッチ管理とは異なるインシデント対応が必要です。ベンダーからの情報を待ちつつ、IPS/IDSでのシグネチャ更新、EDRでの挙動監視、一時的なサービスポートの遮断といった「回避策」を検討します。修正パッチが公開され次第、即座に「緊急」としてSLAに基づき適用プロセスを開始します。

A3: 外部業者にアウトソーシングする際は、まずサービス範囲（情報収集のみか、適用作業までか）と対象資産を明確にします。契約時には必ずSLAを盛り込み、対応時間や報告形式、障害発生時の責任分界点を文書で合意することが重要です。業者の実績やセキュリティ体制、監査対応経験も選定のポイントになります。