脆弱性対応の社内ルールを整備する方法

なぜ「脆弱性対応の社内ルール」が必要なのか

「脆弱性（ぜいじゃくせい）」は、システムやソフトウェアの“弱点”のことです。ここが悪用されると、情報漏えい・改ざん・業務停止などにつながります。多くの企業で起きがちなのが、担当者が善意で対応しているものの、判断基準や役割分担が曖昧なまま、場当たり的にパッチ適用や設定変更をしてしまう状態です。これだと、対応が遅れるだけでなく、急いでアップデートした結果の障害や、例外対応の積み重なりで「どの端末が安全か分からない」状況を招きます。

社内ルール整備の目的は「完璧なセキュリティ」ではなく、まずは対応の再現性（誰がやっても同じレベルで進む）を作ることです。特に、開発の専門知識がない情シス・総務・管理部門でも運用できる形に落とし込むと、担当者の交代や外部委託の切り替えがあっても破綻しにくくなります。

脆弱性対応は、インシデント対応（事故が起きた後の対応）と混同されがちですが、ルール整備の中心は「事故になる前に潰す」ことです。具体的には、脆弱性情報の収集→影響判定→優先度付け→対応（更新・緩和策）→確認→記録→振り返り、という一連の流れを、会社の事情（業務時間、停止できないシステム、外注先、監査）に合わせて決めます。

また、クラウド利用やSaaS活用が進むほど、「自社で全部直す」ではなく、「ベンダーが直す」「設定で避ける」「利用停止する」など選択肢が増えます。だからこそ、誰が何を決めるか（意思決定の線引き）が重要になります。

ルール整備の全体像：5つの柱で考える

脆弱性対応の社内ルールは、分厚い規程を作るより、運用が回る“最小セット”から始めるのが現実的です。ポイントは、次の5つの柱を欠かさないことです。

• 対象の棚卸し：どの資産（端末・サーバ・ネットワーク機器・クラウド・SaaS）が対象か
• 情報の入口：脆弱性情報をどこから入手し、誰が見るか
• 評価と優先度：自社への影響をどう判断し、いつまでにやるか
• 対応手段：パッチ適用・設定変更・回避策・機能停止・利用停止・代替など
• 記録と監査性：やったことを残し、再発防止・説明責任に耐える形にする

よくある失敗は、「情報収集」だけを頑張ってしまい、チケットが溜まり続けることです。逆に、評価や優先度の基準があると、重要なものから着実に潰せます。ルールは“判断を早くするための道具”と捉えると、作るべき内容が見えてきます。

もう一つ大事なのが、対象範囲を明確にすることです。たとえば「社内PCだけ」なのか「製造ラインの端末も含む」のか「ECサイトのサーバも含む」のかで、必要な体制も停止許容時間も変わります。最初は「インターネットに直接つながるもの」「個人情報に触れるもの」など、リスクが高い領域から始め、徐々に広げると運用が定着しやすいです。

この5つの柱を、A4数枚の運用ルール（手順書）にまとめ、月次で改善するだけでも、対応品質は大きく上がります。

まず作るべき「役割分担」と意思決定フロー（RACIの考え方）

脆弱性対応のボトルネックは、技術よりも「誰が決めるか」です。そこで有効なのが、役割を4分類する考え方です。一般にRACIと呼ばれますが、難しく考えず、次のように整理すると運用しやすくなります。

• 実行者：アップデート適用、設定変更、手順実施をする
• 責任者：期限や品質に責任を持ち、最終的に完了判断をする
• 相談先：判断が必要なときに助言する（外部ベンダー、開発会社、SOCなど）
• 報告先：状況を知っておく必要がある（管理職、経営層、監査、関係部門）

情シスが1〜2名の中小企業では、「実行者＝責任者」になりがちです。その場合でも、最低限「報告先」と「相談先」を決めると、孤立を防げます。大企業でも、開発部門・運用部門・セキュリティ部門・購買・法務などが絡み、決裁が遅れて放置されるケースが起きます。期限を守るために、例外時の決裁ルート（緊急承認）もルールに含めましょう。

意思決定フローは、次の3段階で作ると簡単です。

1. 分類：対象は「業務端末」「社内サーバ」「公開サーバ」「クラウド/SaaS」「ネットワーク機器」などどれか
2. 影響：止められるか（停止可否）、顧客影響、個人情報の有無、外部公開の有無
3. 決裁：誰がOKを出すか（責任者）と、相談先はどこか

たとえば「公開Webに影響する緊急の脆弱性」は、情シスの判断だけで深夜対応が必要になることもあります。その際、事前に「緊急時は責任者が暫定対応し、翌営業日に報告・承認を得る」と決めておくと、スピードと統制の両立ができます。

併せて、連絡手段（Teams/Slack/メール）と連絡先リスト、休日夜間の連絡ルールも定義しましょう。“連絡がつかない”が最大の遅延要因になりやすいからです。

脆弱性情報の収集と「自社影響の判断」：見落としを減らす仕組み

脆弱性情報は、ニュースやSNSだけに頼ると偏ります。一方で、すべてを追うのも現実的ではありません。ポイントは、自社が使っている製品・サービスに紐づいた情報を、定期的に拾うことです。

情報源は次のように分けると管理しやすくなります。

• ベンダー公式：Microsoft、Apple、Google、Ciscoなどのセキュリティアドバイザリ
• 公的な情報：国内の脆弱性情報提供サイト、注意喚起
• 運用ツール：EDR/AV、資産管理、脆弱性スキャナ、クラウドのセキュリティ通知
• 委託先：保守ベンダー、開発会社、MSPからの月次レポート

そして最も重要なのが「自社影響の判断」です。専門知識がない場合、次の4問で一次判断すると精度が上がります。

1. それは自社に存在する？（資産台帳・ソフト一覧にあるか）
2. 外部に公開されている？（インターネットから到達可能か）
3. 悪用が現実的？（攻撃が自動化されている、既に悪用が報告されている等）
4. 守るべき情報に触れる？（個人情報、取引先情報、認証情報、機密資料）

この4問で「存在する」かつ「外部公開」または「悪用が現実的」なら、優先度は高くなります。逆に、社内の隔離された端末で、かつ利用頻度が低いものなら、計画メンテナンスに回す判断もできます。

ここで資産台帳がないと詰みます。完璧な台帳がなくても、まずは「公開資産」「サーバ」「全社配布PC」「ネットワーク機器」「主要SaaS」だけでもリスト化してください。“何があるか分からない”状態は、脆弱性対応の最大リスクです。

可能であれば、脆弱性管理ツールや端末管理（MDM）を導入し、「どの端末がどのバージョンか」を自動で取れる状態に近づけると、判断と対応が一気に早くなります。

優先度とSLA（いつまでにやるか）を決める：現場が迷わない基準

脆弱性対応を継続するには、期限（SLA）を決める必要があります。期限がないと、日々の業務に押されて先送りになり、気づいたときには「未対応が山積み」になります。重要なのは、技術指標だけでなく、業務の重要度や停止許容時間も織り込むことです。

以下は、専門知識がなくても運用できる、シンプルな優先度例です（自社用に調整してください）。

期限とセットで「例外ルール」も必須です。例えば、パッチを当てると業務アプリが動かないことがあります。その場合、未適用のまま放置するのではなく、代替策（緩和策）を選ぶのがルールです。緩和策の例は、機能の無効化、アクセス制限、WAF/IPSでの遮断、ネットワーク分離、対象端末の利用停止などです。

また、SaaSの場合は自社でパッチ適用できないことも多いです。その際は「ベンダー側の対応状況を確認し、設定でリスクを下げる」ルールにします。例えば、管理者権限の棚卸し、多要素認証の強制、不要な連携アプリの停止、ログ監視強化などです。

優先度を決める会議体は、毎回全員集合にすると回りません。週1回15分の定例（情シス＋必要時に開発・ベンダー）と、緊急時の臨時判断（責任者が即断）を併用すると、スピードを落とさず統制できます。

社内ルールのテンプレ：手順・記録・例外処理まで一枚に落とす

ルールを文書化する際は、「規程」よりも「運用手順＋チェック項目」が効果的です。特に、担当者が変わっても回るように、読むだけで手が動くレベルの具体性を目指します。ここでは、そのまま社内ルールに転記しやすい構成を紹介します。

運用手順（最低限）

1. 検知：脆弱性情報を受領（誰が、どこから、いつ確認）
2. 紐付け：対象資産を特定（台帳、端末管理、クラウド一覧）
3. 一次評価：外部公開の有無、悪用状況、守る情報、業務影響
4. 優先度決定：緊急/高/中/低、対応期限（SLA）
5. 対応方針：パッチ適用/設定変更/緩和策/利用停止/ベンダー対応待ち
6. 実施：検証→本番適用（可能なら段階的に）
7. 確認：適用確認、再起動要否、サービス正常性、監視アラート
8. 記録：チケット更新、証跡（日時、担当、対象、結果）
9. 振り返り：月次で未対応・例外を棚卸しし、台帳と手順を改善

記録（チケット）に必ず残す項目

• 対象：システム名、端末名、IP/URL、製品名・バージョン
• 概要：脆弱性の内容（自社向けに一文で）、悪用の有無
• 影響：外部公開、守る情報、業務影響、停止許容
• 判断：優先度と期限、決裁者、相談先コメント
• 対応：実施した内容（パッチ番号、設定変更、遮断ルール等）
• 結果：動作確認、影響有無、残課題
• 例外：未適用理由、緩和策、次回見直し日

この記録があると、監査や取引先からのセキュリティ質問票にも強くなります。「うちはちゃんとやっています」を口頭で説明するより、いつ・何を・どこまでやったかを提示できることが信頼につながります。

例外処理（現場が困るポイントを先に潰す）

例外処理がないルールは、現場で必ず破綻します。例えば「パッチを当てると会計ソフトが動かない」「工場の端末は止められない」「外注が触ると保証が切れる」などです。例外時は、次のいずれかを必ず選ぶ、と決めましょう。

• 緩和策を実施：アクセス制限、ネットワーク分離、監視強化、機能停止
• リスク受容の承認：責任者が期限付きで承認し、次回更改で解消計画
• 代替：製品入れ替え、SaaSへ移行、環境刷新

ここで重要なのは、例外を「グレーの放置」にしないことです。例外は“期限付きの宿題”として見える化し、月次で棚卸しします。

運用を回すコツ：小さく始めて、月次で改善する

ルールは作って終わりではなく、運用で育てます。特に、専門知識がない組織では、最初から完璧を目指すと挫折しやすいです。おすすめは、対象範囲を絞って「回る形」を作り、毎月改善する進め方です。

例えば最初の1〜2か月は、次の範囲に限定します。

• 公開Webサイト：CMS、プラグイン、サーバOS、WAF設定
• 全社PC：OS更新、ブラウザ、Office、VPNクライアント
• 認証基盤：IdP、メール、クラウド管理者アカウント

この範囲だけでも、脆弱性対応の効果は大きいです。特にブラウザやVPNの更新は、攻撃者が狙いやすい入口になりがちなので、“まずは入口を固める”という意味で費用対効果が高いです。

運用の定例は、次の3点に絞ると短時間で回せます。

1. 今月の未対応：期限超過があるか、理由は何か
2. 例外の棚卸し：緩和策は効いているか、解消計画は進んでいるか
3. 台帳の更新：新規導入・廃止・外注変更を反映したか

さらに、可能ならKPIも最小限で設定します。例えば「緊急の脆弱性のSLA達成率」「未対応件数」「例外の件数と平均滞留日数」などです。数値で見えると、経営や他部門の協力（停止時間の確保、予算、ツール導入）が得やすくなります。

最後に、よくある落とし穴として「更新作業の属人化」があります。ベンダー任せ・特定担当者任せだと、退職や異動で止まります。手順の標準化、権限管理、パスワード・認証情報の管理（共有方法）まで含めて、運用が“人に依存しない”形に近づけましょう。

まとめ

脆弱性対応の社内ルール整備は、難しい技術文書を作ることではなく、「誰が・何を見て・どう判断し・いつまでに・どう実施し・どう記録するか」を決めることです。ポイントは次の通りです。

• 対象の棚卸しがないと、対応のしようがありません。まずは公開資産と全社端末からでもリスト化します。
• 役割分担と意思決定フローを決めると、緊急時でも止まりません。相談先・報告先もセットで定義します。
• 優先度とSLAを作ると、先送りを防げます。例外は放置せず、緩和策か期限付き承認にします。
• 記録（チケット）の項目を固定化すると、監査・取引先対応・引き継ぎが楽になります。
• 小さく始めて月次で改善すれば、専門知識がなくても運用が定着します。

「うちの規模だと難しい」「何から手を付けるべきか分からない」という場合でも、最小セットのルールと台帳づくりから始めれば、脆弱性対応は確実に前進します。社内の現実（停止できない業務、外注、予算、監査）に合わせて、無理なく回る形に落とし込みましょう。