脆弱性の深刻度が「中」なら、更新は来月でもよいのでしょうか。デジタル庁のガバメントソリューションサービス（GSS）で公表された不正アクセスは、数字だけで対応順位を決める難しさを示しています。
まず見るべきなのは、点数に加えて「外部から届く場所か」「侵入されると何にアクセスできるか」「悪用が確認されているか」です。インターネットに接するVPN機器なら、日常的に使うPCの更新と同じ順番でよいか、立ち止まって確認する必要があります。
この記事ではGSSの公式説明をもとに、企業や法人の担当者が脆弱性情報を受け取ってから、対応完了を確認するまでの進め方を整理します。
2026年11月3日までに確認した公表資料に基づく技術解説です。一般的な対策例は、当該組織の未公表構成を示すものではありません。
GSSの事案で分かっていること
デジタル庁の9月12日更新のQ&Aでは、VPN機器の既知の脆弱性が悪用され、修正適用前に不正アクセスを受けたと説明しています。当初の深刻度評価は「中」でした。保守運用担当者のアカウントによる大量のファイルアクセスを検知したことが、調査のきっかけです。［1］
製品名、CVE番号、具体的な攻撃手法は非公表です。特定のVPN製品を原因とする説明や、MFAが未導入だったという推測はできません。また、「中だったため放置した」とも説明されていません。［1］
CVSSは深刻度のものさし。自社の対応順は、もう一段判断する
CVSSは、脆弱性の技術的な深刻度を評価する共通の仕組みです。通常目にする基本スコアだけでは、自社での公開状態や業務の重要性まですべて反映されるわけではありません。FIRSTの資料でも、脅威や利用環境などの情報を組み合わせて評価する仕組みが説明されています。［2］
たとえば、同じ製品の同じ脆弱性でも、外部から利用できる環境と、該当機能を停止している環境では、対応の考え方が変わります。さらに、止まると業務全体へ影響する設備なら、更新までの間の接続制限も検討したいところです。
これは「高スコアを後回しにしてよい」という話ではありません。深刻度が高いものへの対応を進めながら、低めの評価でも危険な入口になっているものを見落とさないための考え方です。
脆弱性情報を見たら、四つの質問で対象を絞る
| 確認する順番 | 担当者が見るもの |
|---|---|
| 1．自社にあるか | 製品名だけでなく型番、バージョン、利用機能。 |
| 2．どこから届くか | インターネット公開、接続元制限、保守用経路。 |
| 3．悪用の状況はどうか | メーカーの告知、JPCERT/CCの注意喚起、KEV。 |
| 4．侵害されたら何が起きるか | 到達できるサーバー、使える権限、止まる業務。 |
最初の対象判定では、似た製品名や番号違いに注意します。修正版へ更新済みでも、再起動や設定変更が必要な場合があるので、製品の手順を確認してください。
外部に公開しているか分からないときは、ネットワーク担当や保守会社へ問い合わせます。機器の管理画面が外部へ出ていることと、VPN接続用の機能を公開することも分けて把握します。
KEVは「悪用された実績」を知る材料。載っていなければ安全ではない
CVEは脆弱性を識別する番号、CVSSは深刻度の評価、CISAのKEVは実際の悪用が確認された脆弱性のカタログです。KEVは対応の優先順位を考える材料になりますが、未掲載を安全の証明には使えません。［3］
今回のGSS事案はCVEが非公表なので、「KEVに載っていた脆弱性を放置した」とは書けません。自組織の機器でCVEが分かる場合に、メーカー情報や注意喚起と合わせて使う判断材料です。
すぐ更新できない場合は、期限付きの暫定策を決める
VPN機器は、更新すると拠点間通信や在宅勤務が一時的に使えなくなる場合があります。影響を恐れて先延ばしにするのではなく、更新に必要な作業と、それまでの防御を分けます。
暫定策には、メーカーが案内する該当機能の停止、外部公開の制限、利用経路の限定などがあります。ただし、その脆弱性に効くと確認できるものを選んでください。IP制限やMFAを追加すれば、どの脆弱性でも防げるわけではありません。
| 記録する項目 | 記入例 |
|---|---|
| 対象 | 機器名、バージョン、CVE、公開している機能。 |
| 判断 | 外部公開あり、重要業務への経路あり、メーカーが緊急対応を推奨。 |
| 暫定策 | 保守窓口と確認した対応、適用日時、制限される業務。 |
| 本対応 | 更新日、担当者、作業失敗時の連絡先と判断者。 |
| 完了条件 | 修正版確認、必要な再起動、正常動作、侵害の兆候の確認。 |
表の内容は運用例です。決まった日数をすべての脆弱性に当てはめず、悪用状況と機器の役割に応じて、判断者が期限を設定します。期限を過ぎる場合は、担当者だけで抱えず再承認を受けます。
パッチが入ったことと、侵入されていないことは別です
修正プログラムは脆弱性の解消に必要ですが、すでに盗まれた認証情報や作成された不正アカウントまで自動で元に戻すとは限りません。攻撃が疑われる場合は、単に更新して通常運用へ戻す前に、専門家と確認する必要があります。
自分の環境で点検するなら、管理者の追加、普段と異なる接続元、大量ダウンロード、設定変更などのログを確認します。対象となるログと保持期間は製品・サービスによって異なるため、平時に取得場所を把握しておくと対応しやすくなります。
侵害の疑いがある機器を、自己判断で初期化すると調査に必要な情報を失うおそれがあります。遮断、証拠保全、調査の順序は専門家や保守会社と相談してください。
点検の実例：「中」のVPNと「高」の業務ソフトが同時に見つかったら
仮に、外部接続に使うVPN機器の脆弱性が「中」、内部の業務ソフトが「高」だったとします。この二つを点数だけで並べず、両方の対象判定をしたうえで、悪用情報と公開状態を確認します。これは判断の練習用の例で、GSSの機器構成ではありません。
VPNに実際の悪用情報があり、自社も該当する機能を外部公開しているなら、接続制限や修正を急ぐ判断につながります。一方、業務ソフト側が認証なしで誰からでも到達できる場所にあるなら、そちらも至急の対応が必要になる可能性があります。製品の区分だけで優先度を固定しないことが大切です。
対象バージョンが確認できない場合は「影響なし」として消さず、「保守会社へ照会中」と記録します。回答の期限を入れ、確認が返ってこない場合に誰へ相談するかも決めます。不明な機器が一覧に残り続ける状態を避けてください。
委託しているVPNも、自社の一覧へ入れる
保守会社が設置した機器については、更新を任せているつもりでも、契約の範囲に含まれていない場合があります。機器の所有者と、脆弱性対応の担当者は別に確認します。メーカーの緊急告知を受け取る人、更新の承認者、実作業の担当者をつなげておきます。
作業後には、日時と結果だけでなく、修正後のバージョン、再起動の実施、必要な通信の確認結果も受け取ります。報告に「対応済み」とだけ書かれているなら、何を確認して完了としたかを追加で尋ねると、管理が具体的になります。
よくある疑問
CVSSが高い順に並べる運用は間違い？
最初の整理として役立ちます。ただし、外部公開の有無や実際の悪用を加味して、対応順位を見直します。スコアの並べ替えだけで完了にしないことが大切です。
VPNを廃止すれば今回の教訓への対応は終わる？
代替サービスにも認証、公開範囲、更新の管理が必要です。製品を置き換える際も、誰が脆弱性を把握し、誰が対応するかを決めてください。
「ゼロトラスト」なら更新は不要？
不要にはなりません。アクセス制御の考え方や製品名だけで、使っている機器の脆弱性が解消されるわけではありません。
次の更新一覧には、公開状態と担当者の列を追加する
脆弱性一覧を作るなら、CVEとCVSSの隣に「自社での利用」「外部公開」「悪用情報」「担当者」「期限」を並べます。情報の収集から実際の修正までをつなげることで、日々の更新確認を、被害を防ぐ判断に変えられます。
