VPN機器が最大の侵入口になっている——デジタル庁GSS事案から考えるリモートアクセスの守り方

最初に必要なのは一覧です。機種・型番・ファームウェアのバージョン・設置場所・更新の責任者を、VPN機器だけでなくリモートデスクトップの入口やファイアウォールの管理画面も含めて書き出します。「導入した業者に任せている」機器ほど、誰も最新の状態を知らないことが多い。把握していない機器は、更新されない機器です。棚卸しの考え方は セキュリティの棚卸しチェックリスト にまとめています。

ベンダーの脆弱性情報に加えて、実際に悪用が確認された脆弱性の一覧（CISA KEV）を追います。KEVに載った脆弱性は「いつか狙われるかもしれない」ではなく「すでに狙われている」ものです。深刻度の数字だけで順番を決めない考え方は CVSS・EPSS・KEVで優先順位を決める、実際の対応手順は 脆弱性対応の実務手順 を参照してください。

脆弱性を突かれた可能性がある機器では、パッチを当てても、それ以前に盗まれた認証情報は有効なままです。その機器に保存されていた、または経由したアカウントのパスワード・証明書・鍵を入れ替え、身に覚えのないアカウントや設定変更がないかを確認します。「塞いだ」と「追い出した」は別の作業です。

デジタル庁の事案で大量のファイルへのアクセスに使われたのは保守運用担当者のアカウントでした。同庁の発表はこのアカウントの権限範囲には触れていませんが、一般に保守用のアカウントは、作業の都合で広い権限を持たされがちです。必要な範囲だけに絞る・使う時だけ有効にする・接続元を限定する・多要素認証を必須にする——入口を破られても、1つのアカウントで届く範囲が狭ければ被害は小さく済みます。保守・委託先の経路が狙われる構図は、委託事業者のリモート保守用VPN機器が入口になった 大阪急性期・総合医療センターの事案（2022） でも調査委員会が指摘しています。

デジタル庁が異常に気づいたきっかけは大量のファイルへのアクセスでした。侵入そのものは防げなかったものの、検知が働いたから範囲を確定し、遮断できたとも言えます。ファイルサーバーやクラウドストレージで、短時間の大量ダウンロード・深夜の一括アクセス・普段使わないアカウントの利用を通知する設定は、高価な製品がなくても始められます。検知の考え方は IoA（攻撃の兆候） と EDR の解説も参考になります。

更新を追い続ける人も予算もないなら、その機器を置き続けること自体がリスクです。代わりの方法（インターネットに入口を出さない接続方式や、事業者が更新を担うサービスへの移行）は、それ自体が万能ではありませんが、「更新の責任を誰が負うか」を明確にできる点で検討する価値があります。