最終更新日：2026年5月24日
sg sg-security-management threat_vulnerability risk_assessment it_security_operations
まず結論
脆弱性対応のSLA（Service Level Agreement）設計とは、脆弱性の重大度ごとに「いつまでに何をするか」を事前に決める運用基準です。SG試験では、全件を同じ期限で処理するのではなく、重大度・業務影響・公開状況に応じて期限を切り分けられるかが問われます。
直感的な説明
病院のトリアージに近い考え方です。
- 命に関わる患者（重大脆弱性）は最優先で即対応
- すぐ命に関わらない患者（中程度脆弱性）は計画的に対応
- 軽症（低重大度）は定期診療で対応
脆弱性対応でも、同じ「不具合」でも急ぎ方が違います。選択肢で「すべて次回定例メンテで対応する」と書かれていたら、重大度を無視しているため不適切になりやすいです。
定義・仕組み
脆弱性対応SLA（Service Level Agreement）は、一般に次の要素で設計します。
- 重大度区分（例：Critical / High / Medium / Low）
- 対応期限（例：24時間以内、7日以内、30日以内）
- 対応内容（恒久対策か、暫定対策か）
- 例外承認フロー（期限内に難しい場合の承認手順）
- 測定指標（期限遵守率、期限超過件数、再発率）
特にSG試験では、次の切り分けが重要です。
- CVSSは優先順位を決める参考指標であり、SLAそのものではない
- パッチ未提供時は、アクセス制限・設定変更などのワークアラウンドで期限内対応を成立させる
- 期限超過を放置せず、リスク受容の承認記録を残す
公式情報として、IPAの脆弱性対策情報も実務整理に有用です。
IPA：情報セキュリティ対策支援（脆弱性対策情報）
どんな場面で使う？
- 脆弱性診断の結果が大量に出て、対応優先順位を明確化したいとき
- 監査で「なぜこの脆弱性を後回しにしたのか」の説明責任が必要なとき
- 委託先や運用ベンダに、期限付きで是正対応を依頼するとき
- インシデント予防の観点で、重大脆弱性を短期間で塞ぐ体制を作るとき
ケース問題では、「重大度が高いのに通常変更手順だけで長期間放置」「期限超過の承認記録がない」といった状況が不適切判断の典型です。
よくある誤解・混同
-
誤解1：CVSSが高いものだけ対応すればよい
→ 不適切です。資産の重要度・公開範囲・悪用状況も見て期限を調整します。 -
誤解2：パッチがないならSLA違反は仕方ない
→ 不適切です。暫定対策（通信遮断、機能停止、監視強化）を期限内実施する設計にします。 -
誤解3：全脆弱性を同じ期限で処理するのが公平
→ 不適切です。SG試験では「重大度別に期限を分ける」考え方が基本です。 -
誤解4：期限超過は担当者判断で先送りしてよい
→ 不適切です。リスク受容として管理者承認・記録が必要です。
まとめ（試験直前用）
脆弱性対応SLAは、重大度別に期限と対応内容を決める管理基準です。
CVSSは優先順位づけの材料であり、SLAそのものではありません。
パッチ未提供でもワークアラウンドで期限内対応を成立させる視点が重要です。
期限超過は放置せず、例外承認と記録でリスク受容を管理するのが実務・試験ともに基本です。