組織のセキュリティ対策の最低限：2026年の国内事故から逆算した6つの優先順位

VPN機器、リモートデスクトップの入口、ファイアウォールの管理画面——インターネットから直接届く機器の一覧を作り、機種・バージョン・更新の責任者を書きます。警察庁の統計では、ランサムウェアの感染経路（有効回答92件）のうち61件がVPN機器でした。

最初の一歩：一覧の各機器に「悪用が確認された脆弱性（KEV）が出たら何日以内に塞ぐか」を1つの数字で決める。「順番に当てる」運用のままだと、デジタル庁の事案と同じ構図になります。詳しくは VPN機器が最大の侵入口になっている。

組織には、社員ではない人のアカウント——保守業者、委託先、すでに辞めた人——が必ずあります。これらは作業の都合で広い権限を持たされがちで、しかも誰の管理下にあるかが曖昧です。

最初の一歩：社員以外のアカウントを一覧にし、それぞれに社内の担当者と有効期限を付ける。使う時だけ有効にする、接続元を限る、フィッシングに強い二要素認証を必須にする、を順に進めます。退職時のアカウント停止は、入社手続きと同じ書類に載せてください。

アフラックの事案では、攻撃は通常の利用と同じ形をしていました。1件ずつは正しい照会なら、1件ずつの検査では止まりません。残る手がかりは1時間あたりに何件が出ていったかと、深夜・休日の動きです。

最初の一歩：顧客情報を最も多く返す機能1つに、1アカウントあたり1時間の上限と上限の8割で担当者に届く通知を付ける。ファイルサーバーやクラウドのストレージには、普段の何倍もの一括ダウンロードで通知が飛ぶ設定を入れる。設計の考え方は レート制限と濫用対策。

さくらインターネットの事案では、不正アクセスは約3年前から始まっていました。気づいた時点でその期間のログがなければ、何が起きたかも、何が起きなかったかも言えません。

最初の一歩：認証（成功と失敗）・データの照会と出力・管理操作の3種類だけは、少なくとも12か月残す（決済カード業界の基準 PCI DSS が求める期間を目安に）。容量が足りないなら、Webのアクセスログより先にこの3種類を守ります。

Gyazoの事案で流出したメタデータの中心は、何年も前にアップロードされた画像の付随情報でした。事故の被害の大きさは、その時点で持っていたデータの量で決まります。持っていないデータは漏れません。

最初の一歩：顧客データの種類ごとに「何のために、いつまで持つか」を1行で書く。書けないものは削除か匿名化の候補です。退会・解約した利用者の情報が残り続けていないかも確認してください（さくらインターネットの件では、解約済みでも退会しない限り会員情報が保持されていた）。

Adobe Commerce の件では、修正公開時の公告は「優先度2・悪用は認識していない」で、44日後にCISAが悪用を確認しました。WordPress本体の件では、それが3日でした。

最初の一歩：自社で使っている製品について、KEVへの追加を通知で受け取る仕組みを1つ用意し、追加されたら「更新の順番」を付け直すルールにする。判断の手順は CVSS・EPSS・KEVで優先順位を決める。