脆弱性管理を継続運用に落とし込む方法

なぜ「脆弱性管理」は続かないのか：単発の診断で終わる落とし穴

「脆弱性が見つかったら直す」自体は多くの企業が理解しています。しかし現場では、年1回の診断レポートを受け取って満足してしまい、数か月後には新しい脆弱性が増えている――という状況が起きがちです。これは担当者の努力不足ではなく、脆弱性管理を“イベント”として扱っている構造が原因です。脆弱性（セキュリティホール、弱点）は、OSやソフトの更新、クラウド設定変更、委託先のライブラリ更新など、日々の変化で増減します。つまり、開発がない会社でも「ITの変化」がある限り脆弱性は発生します。

継続運用に落とし込めない主な理由は3つあります。1つ目は「対象の棚卸しがない」こと。何を守るべきか（サーバ、PC、SaaS、ネットワーク機器、Webサイト等）が不明確だと、脆弱性の検知も優先順位付けもできません。2つ目は「判断の基準がない」こと。緊急に直すべき脆弱性と、計画的に直せば良い脆弱性を分けられず、担当者が疲弊します。3つ目は「運用の持ち場が決まっていない」こと。情シス、総務、委託先、各部門の境界でタスクが滞留しやすく、対応が遅れて攻撃者に狙われます。

この記事では、専門知識が深くなくても実行できる形で、脆弱性管理（Vulnerability Management）を“毎月回る業務”に変える方法を解説します。ポイントは、セキュリティの理想論ではなく、中小企業や情シスで回せる運用設計に落とすことです。

継続運用の全体像：見える化→優先順位→修正→確認→再発防止

脆弱性管理を継続運用にするには、やるべきことを少ない工程に分解し、毎回同じ手順で回せるようにします。おすすめは次の5工程です。

• 見える化（資産の把握）：何が稼働しているか、誰が責任を持つかを整理
• 検知（発見）：脆弱性スキャン、更新状況の収集、ベンダー情報の監視
• 優先順位付け（トリアージ）：直す順番を決め、直さない判断も記録
• 修正（是正）：パッチ適用、設定変更、代替策（緩和策）を実施
• 確認と再発防止：修正の確認、例外の期限管理、ルール化

ここで重要なのは、脆弱性の「深刻度」だけで順番を決めないことです。例えば、同じ深刻度でも「インターネットに公開されているWebサーバ」と「社内のみの端末」では危険度が違います。また、攻撃が実際に流行している脆弱性（悪用が観測されているもの）は、社内の影響範囲が小さくても優先すべき場合があります。そこで、情シスや経営層が意思決定しやすいように、判断軸を固定します。

実務で使いやすい判断軸は、公開範囲（外部公開か）×重要度（止まると困るか）×悪用状況（攻撃が増えているか）×修正難易度（業務影響）の4つです。これを毎回の会議やチケットで同じフォーマットにすると、属人化を避けられます。以降のセクションで、これを「台帳」「運用ルール」「月次サイクル」の形に落とします。

まずやるべきは資産台帳：脆弱性管理は“守る対象”がないと始まらない

脆弱性管理の最初の一歩は、スキャンツールよりも「資産台帳（アセット台帳）」です。台帳がないと、脆弱性が出ても「それ誰の担当？」「そのサーバまだ使ってる？」となり、対応が遅れます。特に中小企業では、過去に作ったWebサイト、テスト環境、使われなくなったVMなどが放置され、そこが侵入口になるケースがあります。攻撃者は“最新の堅牢な本番”ではなく、忘れられた弱い場所を狙います。

台帳は立派なツールでなくて構いません。最初はスプレッドシートで十分です。最低限、次の項目を埋めてください。

• 名前/種類：Webサーバ、ファイルサーバ、PC、ルータ、SaaSなど
• 場所：クラウド（AWS/Azure/GCP）、データセンタ、社内
• 公開範囲：インターネット公開/社内限定/VPN経由
• 重要度：止まったら困る業務、個人情報や機密の有無
• 管理者：情シス、委託先、部門責任者（連絡先まで）
• 更新方法：自動更新/手動/委託先作業、保守契約の有無
• 備考：メンテ時間、依存関係、再起動要否

台帳作りの現実的な進め方は「全部を完璧に」ではなく、侵入リスクが高い順に埋めることです。具体的には、(1)インターネット公開のWebサイト/管理画面、(2)VPN・リモートアクセス、(3)クラウドの管理者アカウント、(4)ファイル共有、(5)端末（PC）という順番が多いです。これだけで、脆弱性管理の成果が出やすい領域を先に押さえられます。

また、委託先が運用しているシステムでも、台帳上の「社内責任者」は必ず決めてください。脆弱性対応の連絡は緊急性が高く、委託先との契約範囲外だと止まります。“社内の窓口が不在”が最大の遅延要因になりがちです。

検知の仕組み：スキャン・情報収集・ログの3点セットで漏れを減らす

脆弱性を継続運用にするための「検知」は、1つの手段に依存しないことが大切です。おすすめは、(1)脆弱性スキャン、(2)ベンダー情報・アラートの収集、(3)最低限のログ監視の3点セットです。いずれも、難しい分析より“気づける状態”を作ることが目的です。

まず脆弱性スキャンは、社内ネットワーク向けと外部公開向けで考えます。外部公開（Webサイト、VPN、リモートデスクトップ等）は、攻撃者から見える範囲なので優先度が高いです。スキャン結果は「危険」と出ても誤検知があり得ますが、放置よりは良いので、毎月または四半期で定期実行し、差分（増えた/減った）を追います。スキャンできないSaaSは、次の情報収集で補います。

次に情報収集です。OSやソフトウェア、クラウドサービスは、重大な脆弱性が出ると緊急パッチや注意喚起が出ます。代表例はWindows更新、ブラウザ更新、VPN機器の脆弱性情報、メール関連の不具合などです。情シスがすべてを追うのは大変なので、「自社の台帳にある製品だけ」を監視対象に絞るのが現実的です。各ベンダーのアドバイザリや、利用しているクラウドのアラート、セキュリティニュースの要点だけを週1回見る運用でも効果があります。

最後にログ監視です。高度なSIEMをいきなり導入する必要はありませんが、少なくとも「異常があったら気づける」ようにします。例えば、管理者ログインの失敗が急増、海外IPからのアクセス、深夜の大量通信など、分かりやすい兆候をアラートにします。脆弱性が悪用されると、攻撃者はまず侵入の足がかりを作り、権限を上げ、横展開します。脆弱性の修正が間に合わない場合でも、兆候検知で被害を小さくできるのがログの価値です。

優先順位付けと意思決定：直す・待つ・緩和するを迷わないルール

脆弱性管理が回らない最大の原因は「優先順位の迷い」です。スキャン結果や脆弱性情報は多く、すべてを即対応するのは不可能です。そこで、判断をテンプレ化して、担当者が1人で抱えないようにします。おすすめは、脆弱性を「A：即対応」「B：計画対応」「C：監視」「D：例外（期限付き）」に分ける運用です。

分類の基準は、以下のように具体化すると迷いが減ります。

• A（即対応）：外部公開に影響、かつ悪用が流行/容易、または重要データに直結（原則72時間以内を目標）
• B（計画対応）：公開範囲は限定的だが重要度が高い、または将来的に悪用が増えそう（次回メンテ枠で対応）
• C（監視）：影響範囲が小さい/回避策がある/環境に該当しない可能性（情報更新を追う）
• D（例外）：パッチ適用が業務停止につながる等で見送る（必ず期限と代替策を設定）

重要なのは、D（例外）を“無期限の放置”にしないことです。例外を認めるのは現実的ですが、その場合は代替策（緩和策）をセットにします。例えば、対象サーバへのアクセス元制限、WAFのルール追加、管理画面のIP制限、該当機能の一時停止、権限の見直しなどです。そして「いつまでに恒久対応するか」を決めます。例外を記録して期限管理するだけで、脆弱性の放置リスクは大きく下がります。

もう1つ、情シスと経営層のコミュニケーションを楽にするコツがあります。それは、脆弱性の説明を「専門用語」ではなく「業務影響」で言い換えることです。例えば「CVSSが高い」ではなく、「このままだと外部から侵入され、取引先情報が漏える可能性がある」「復旧に数日かかると受注が止まる」のように伝えます。判断者が理解できる言葉に落とすと、修正の承認が早くなり、結果として継続運用が回り出します。

月次で回る運用手順：チケット化・SLA・変更管理で“習慣”にする

継続運用に落とし込むための具体的な形として、「月次の定例」と「緊急時フロー」を分けて設計します。月次は淡々と回し、緊急時は短い動線で動けるようにするのがポイントです。まず月次の基本フローは以下です。

1. 月初：台帳の更新（新規システム、廃止、委託先変更）
2. 同週：スキャン実施・更新状況収集・アラート確認
3. 翌週：トリアージ会（A/B/C/D分類、期限設定、担当割当）
4. 月中：修正作業（パッチ適用、設定変更、緩和策）
5. 月末：確認（再スキャン/動作確認）、例外の棚卸し、次月の課題整理

この運用を支えるのがチケット（課題管理）です。メールや口頭だけで脆弱性対応を回すと、担当変更や繁忙期で必ず抜けます。JiraやBacklog、Redmine、あるいはMicrosoft Plannerでもよいので、脆弱性対応は必ずチケット化します。チケットのテンプレとしては、(1)対象資産、(2)脆弱性の概要、(3)優先度（A/Bなど）、(4)期限、(5)対応方針（パッチ/緩和/例外）、(6)確認方法、の6点があると運用が安定します。「確認方法」まで書くことで、直したつもりの取りこぼしを防げます。

次にSLA（対応目標）を決めます。厳密な契約でなくても、社内ルールとして「Aは72時間以内」「Bは30日以内」「Dは90日以内に再判断」など、目標を置くだけで意思決定が早くなります。委託先が関わる場合は、保守契約に“脆弱性対応の範囲と時間”が含まれているか確認し、含まれないなら追加契約やスポット対応の条件を決めておきます。ここが曖昧だと、重大な脆弱性が出たときに稟議が間に合いません。

最後に変更管理です。パッチ適用は失敗すると業務停止につながるため、「怖いから先延ばし」が発生します。対策はシンプルで、(1)影響の出る時間帯（メンテ枠）を決める、(2)ロールバック手順（戻し方）を決める、(3)関係者への連絡テンプレを作る、の3つです。これだけで心理的ハードルが下がり、脆弱性管理が“毎月の作業”になります。

よくある失敗と回避策：ツール導入より先に整えるべきこと

脆弱性管理の相談で多い失敗は、「高機能なツールを入れたのに運用が回らない」ことです。ツールはあくまで補助で、継続運用の成否は体制とルールで決まります。ここでは、非エンジニアの方でも判断しやすい形で、典型的な失敗と回避策をまとめます。

• 失敗：対象範囲が広すぎて頓挫
  回避策：最初は外部公開と重要業務に絞る。台帳も“重要な20%”から埋める。
• 失敗：結果レポートが難解で放置
  回避策：A/B/C/D分類と期限、担当者だけを抜き出した「対応一覧」を作る。経営層には業務影響で説明する。
• 失敗：委託先に丸投げして連絡が遅れる
  回避策：社内窓口を必ず置き、緊急連絡フロー（誰が誰に電話するか）を決める。契約範囲も事前確認。
• 失敗：例外が増えて“穴”が残る
  回避策：例外は期限付き。緩和策（アクセス制限、WAF、機能停止）を必須にし、月末に棚卸しする。
• 失敗：パッチが怖くて延期が常態化
  回避策：メンテ枠とロールバック手順をテンプレ化。小さく頻繁に当てる運用に変える。

また、見落とされやすいのが「認証情報（ID/パスワード、APIキー）の管理」と「バックアップ」です。脆弱性が悪用された場合、侵入後にアカウントを奪われたり、ランサムウェアで暗号化されたりするリスクがあります。脆弱性管理と並行して、管理者アカウントの多要素認証、退職者アカウントの停止、バックアップの復元テストなどを最低限行うと、被害を現実的に抑えられます。“侵入されない”だけでなく“侵入されても立て直せる”が継続運用のゴールです。

まとめ

脆弱性管理を継続運用に落とし込むには、年1回の診断を増やすよりも、資産台帳・優先順位ルール・月次サイクルを先に整えることが近道です。まず「守る対象」を見える化し、スキャンやアラートで脆弱性（セキュリティの弱点）を継続的に検知し、A/B/C/Dの基準で迷わず判断できる状態を作りましょう。対応はチケット化し、期限と確認方法を固定すると属人化が減ります。

特に、例外（直せない脆弱性）を“期限付き・緩和策付き”で管理すること、委託先任せにせず社内窓口と緊急連絡フローを持つことが、現場で効くポイントです。脆弱性はゼロにできませんが、運用で「見つける」「優先する」「直す」「確認する」を回せば、攻撃される確率と被害の大きさを着実に下げられます。