脆弱性対応の体制を社内で作る方法

脆弱性対応は「技術」より先に「体制」で決まる

脆弱性は、プログラムの欠陥や設定ミスなどにより、攻撃者に悪用され得る“すき”のことです。ニュースで見る大規模な情報漏えいも、発端は「古いソフトを更新していなかった」「公開設定を誤っていた」といった身近な脆弱性であることが少なくありません。

ただし、脆弱性対応は「詳しいエンジニアがいないと無理」と思われがちです。実務では逆で、最初に必要なのは、誰が・何を・いつまでに判断して動くかを決める“体制”です。詳しい人が少なくても、役割と手順が決まっていれば、外部ベンダーやクラウド事業者の力を借りながら十分に回せます。

特に中小企業や情シスが少人数の会社では、次のような“あるある”が事故の温床になります。

• 緊急パッチが出ても、どのシステムに影響するか分からず放置される
• 更新すると業務が止まりそうで怖くて先送りになる
• 担当者が休むと判断が止まり、結局誰も動けない
• SaaSや外部委託が増え、何を守るべきか見えなくなる

この記事では、専門知識が深くなくても社内で運用できる「脆弱性管理（vulnerability management）」の作り方を、手順・役割分担・優先順位付け・例外処理まで含めて解説します。目標は、完璧を目指すことではなく、「把握できる」「期限を切れる」「証跡が残る」状態を作ることです。

まず決めるべき「守る範囲」：資産台帳がないと始まらない

脆弱性対応が回らない最大の原因は、「どこに対して対応すべきか」が曖昧なことです。脆弱性スキャンツールや診断を入れても、対象が漏れていれば意味がありません。そこで最初に、IT資産の棚卸し（資産台帳）を作ります。難しい台帳ではなく、“対応の漏れを防ぐ最低限の一覧”が目的です。

最低限そろえる資産台帳（例）

• システム名（例：受注管理、採用サイト、社内ファイル共有）
• 種別（Webサイト／Webアプリ／サーバ／PC／ネットワーク機器／SaaS）
• 公開範囲（インターネット公開／社内のみ／取引先のみ）
• 重要度（売上に直結、個人情報あり、停止すると業務停止…など）
• 担当部署・責任者（最終判断者と連絡先）
• 運用形態（自社開発／外部委託／SaaS／クラウドのマネージド）
• 保守契約・ベンダー窓口（緊急時に連絡できる情報）

ポイントは、詳細な構成図を最初から作らないことです。情シスが把握している範囲だけでまず着手し、漏れが見つかったら追記します。とくに見落としやすいのは、キャンペーンサイト、退職者が作った小規模ツール、VPN装置、NAS、古いWordPress、使っていないクラウド環境などです。

資産台帳ができると、脆弱性情報（セキュリティアラート）が出たときに「これは当社に関係あるか？」を即答できます。関係判定の速さが、そのままリスク低減の速さになります。

社内の役割分担：少人数でも回るRACI（責任の交通整理）

体制づくりで次に重要なのは、「誰が決めるのか」「誰が作業するのか」を明確にすることです。ここが曖昧だと、脆弱性が見つかっても“様子見”になり、更新期限が切れます。おすすめはRACIの考え方です（難しければ名称は使わなくても構いません）。

• Responsible（実行担当）：パッチ適用、設定変更、依頼の実作業
• Accountable（最終責任）：実施可否や停止リスクを踏まえた最終決裁
• Consulted（相談先）：開発会社、セキュリティベンダー、クラウド担当など
• Informed（共有先）：経営、関連部署、ヘルプデスク

中小企業の現実に合わせるなら、例えば次のように整理すると回りやすくなります。

• 情シス：脆弱性情報の収集、対象判定、進捗管理、証跡保管
• 各システムの業務責任者：停止許容時間の判断、リリース承認
• 開発/保守ベンダー：影響調査、修正、適用作業、復旧手順提示
• 経営層：例外（先送り）を承認する場、予算と優先順位の調整

ここで大事なのは、「緊急時の連絡網」と「最終判断の代理ルール」です。担当者が不在でも止まらないよう、意思決定者の代行（副責任者）を決めておきます。

会議体は最小でよい

毎週の定例会議で重く運用すると長続きしません。おすすめは、通常はチケット/表で回し、重大な脆弱性だけ臨時判断に切り替える方式です。たとえば「緊急（48時間以内）」「高（7日以内）」「中（30日以内）」のように期限を定め、期限を超えそうなものだけ短い判断会を入れます。

脆弱性の見つけ方：情報収集・棚卸し・スキャンの現実的な組み合わせ

脆弱性対応の入口は「気づくこと」です。気づけない脆弱性は、いつまでも放置されます。一方で、やみくもにツールを入れるとアラート過多で疲弊します。情報源を3つに分けて、段階的に整えるのが現実的です。

ベンダー/クラウドからの通知を“見落とさない”

Microsoft 365、Google Workspace、AWS/Azure/GCP、主要なSaaS、ネットワーク機器メーカーなどは、脆弱性やアップデート情報を公式に出します。まずは、利用サービスごとに「通知先メール」「管理者アカウント」「連絡先」を資産台帳に紐づけ、受信箱に埋もれない仕組み（専用メーリングリスト、チケット自動起票など）を作ります。

脆弱性情報の“全体ニュース”を拾う

ゼロデイや広範囲に影響する脆弱性は、業界ニュースとして流れます。情シスが毎日追うのは大変なので、「週1回15分」のチェックでも効果があります。重要なのは、見つけた情報を“当社の資産に当てはめる”導線です。つまり、ニュースを見たら資産台帳で該当製品があるか検索し、あればチケット化します。

スキャン/診断は「対象」と「頻度」を絞る

脆弱性スキャン（自動診断）は有効ですが、最初から全社でやると運用が破綻しがちです。まずはインターネット公開している資産（公開Webサイト、VPN装置、公開APIなど）に絞り、月1などの頻度で回します。誤検知もあるため、結果の一次仕分け（本当に危険か/対応が必要か）を誰がやるかも体制に含めます。

Webアプリの本格的な脆弱性診断（手動診断）は費用がかかりますが、個人情報や決済に関わるサイトは投資価値があります。診断を単発で終わらせず、報告書の指摘を「修正→再診断→完了」のチケットに落とし込むところまでが体制です。

優先順位付けとSLA：パッチ適用を迷わないための基準

脆弱性対応で一番悩むのは「どれからやるか」です。全てを即日対応できない以上、優先順位が必要です。ここで役立つのが、影響度と悪用されやすさで決めるルールです。基準があると、詳しくない人でも判断がブレません。

判断軸の例（簡易でOK）

• 公開範囲：インターネット公開か、社内限定か
• データの重要性：個人情報、機密、決済情報があるか
• 業務影響：止まると売上/生産に影響するか
• 悪用容易性：リモートから攻撃可能か、認証不要か
• 対策の容易性：更新だけで済むか、開発修正が必要か

これらを点数化してもよいですが、まずは3段階（緊急/高/通常）でも十分です。例えば以下のようにSLA（対応期限）を決めます。

• 緊急：インターネット公開で、リモート攻撃や権限奪取につながる可能性が高い → 48時間以内に暫定対策、7日以内に恒久対応
• 高：重要データに触れる、または横展開の起点になり得る → 7日〜14日以内
• 通常：限定環境で影響が小さい、悪用難度が高い → 30日以内（定例メンテで対応）

「更新すると止まる」が最大の壁：メンテナンス枠を先に確保

パッチ適用が先送りになる理由の多くは、技術よりも業務調整です。そこで、月1回でもよいので「メンテナンス枠（この時間は更新が起こり得る）」を社内合意します。枠があるだけで、緊急時の意思決定が早くなります。

また、更新で不具合が出た時のために、最低限の切り戻し手順（バックアップ、復元、設定戻し）を用意します。“戻せる”と分かると、更新の心理的ハードルが下がります。

運用フロー：発見→判断→対応→確認→報告をチケットで回す

体制を絵に描いた餅にしないために、日々の流れを固定化します。おすすめは、メールや口頭ではなくチケット（Backlog、Jira、Redmine、ServiceNow、Excelでも可）で管理することです。担当が変わっても履歴が残り、監査や取引先からの質問にも答えやすくなります。

標準フロー（テンプレ化すると強い）

1. 検知：通知、ニュース、スキャン、診断報告などで脆弱性を把握
2. 対象判定：資産台帳と突合し、該当有無・範囲・所有者を特定
3. リスク評価：公開範囲、重要度、悪用容易性、代替策の有無を整理
4. 対応方針：パッチ適用／設定変更／WAF等で暫定防御／利用停止などを決定
5. 実施：作業手順、作業日、影響、切り戻しを明記して実行
6. 確認：バージョン確認、再スキャン、ログ確認で対策完了を検証
7. 報告・クローズ：いつ何をしたか、証跡（画面/ログ/チケット）を残す

情シスが詳しくない場合、リスク評価や対応方針はベンダーに相談して構いません。ただし、社内として必ず押さえるべきは「期限」「影響」「代替策」「未対応の理由」です。判断材料がチケットに揃っていれば、決裁者も迷いません。

チケットに入れる項目例

• 対象システム、影響範囲（本番/検証、台数、URLなど）
• 脆弱性の概要（何が起こるかを平易に）
• 推奨対応（更新/設定/遮断）と期限（SLA）
• 業務影響（停止時間、周知先）
• 実施結果（対応日、担当、証跡、残課題）

定型化しておくと、「次も同じフォーマットで回る」状態になり、属人化を防げます。

よくある失敗と回避策：例外処理、委託先、クラウド責任分界

脆弱性対応の体制は、作った直後より半年後に崩れやすいです。理由は「例外」が溜まるからです。ここでは、実務でよくある落とし穴と回避策をまとめます。

失敗：古いシステムだけ“例外”になり放置

古いOSやサポート切れのソフトは、脆弱性が出てもパッチが提供されないことがあります。この場合は「対応できない」で終わらせず、代替策（隔離・制限・置き換え計画）をセットで決める必要があります。

• ネットワーク分離（社内でもアクセス元を限定）
• 外部公開の停止、VPN必須化
• WAF/IPS等で既知の攻撃パターンを遮断
• 置き換えのロードマップ（いつまでに更改するか）

例外は必ず「期限付きの例外」にします。例外の承認者（経営/部長）を明確にし、チケットに理由と期限を残します。

失敗：外部委託だからと丸投げして、結局動かない

外部ベンダーに保守を委託していても、緊急パッチは「追加費用」「作業時間」「影響調査」が発生し、判断待ちになることがあります。契約の段階で、脆弱性対応の範囲とSLAを明記できるのが理想です。すでに契約済みなら、運用ルールとして「緊急時の連絡」「見積もりの即日提示」「暫定対策の提案」など、最低限の取り決めを作ります。

失敗：クラウドは安全だと思い、設定の脆弱性を見落とす

AWSやAzureなどのクラウドは堅牢ですが、責任分界（どこまでが事業者、どこからが利用者の責任か）があります。OSやミドルウェアの更新が利用者側で必要な場合もありますし、設定ミス（公開範囲、権限、鍵管理）は典型的な事故要因です。「クラウド＝自動で全部安全」ではない前提で、設定レビューや権限棚卸しを定期化します。

失敗：脆弱性情報が来ても「当社に関係あるか」の判断で止まる

これを防ぐのが資産台帳です。加えて、製品名やバージョンが不明な資産が多いと判断できません。分からないものは「分からない」と台帳に書き、次回のメンテで確認するタスクに落とします。棚卸しは一度で完成させるものではなく、運用で育てるものです。

まとめ

脆弱性対応は、詳しい人が頑張る仕事ではなく、社内の仕組みとして回す仕事です。専門知識が限られていても、資産台帳と役割分担、優先順位、運用フローがあれば、外部の力を借りながら確実にリスクを下げられます。

• 守る範囲を資産台帳で可視化し、通知やニュースを当てはめられるようにする
• 誰が判断し、誰が実行するかを決め、緊急時の代理ルールも用意する
• 優先順位と期限（SLA）を決め、迷わず動ける基準を作る
• 発見→判断→対応→確認→報告をチケットで回し、証跡を残す
• 例外は期限付きにし、置き換え計画や暫定対策までセットで管理する

もし「台帳づくりから手が回らない」「委託先が複数で整理できない」「脆弱性診断やスキャン結果の読み解きが難しい」といった状況であれば、外部の支援を早めに入れるほど立ち上がりが速くなります。