相次ぐ漏えい、情シスは何をする？ 10月の115件を入口で分けて見えた役割

情シスが、すべての漏えいを止めることはできません。

ただ、10月に公表された漏えいを入口で分けてみると、情シスが持ち主になれる所は、思ったより少なく、はっきりしていました。何のデータをどこへ預けたかの台帳と、社内のアカウントと認証情報、そして漏えいが分かってからの最初の72時間です。

2026年10月1日から29日までに、当サイトが事故として記録した国内の漏えい・不正アクセス・ランサムウェアの公表は115件ありました。1日に約4件のペースです。「毎日のように」という実感は、数字で見ても大げさではありません。

115件を入口で分けると

分け方は単純です。各社の公表に書かれた入口と原因を読み、1件ずつ7つの型に分けました。システムの障害や、PHPの脆弱性に備えた予防の停止、海外の会社の件、同じ件の2本目の記事は数えていません。委託先の事故を委託先と委託した会社の両方が公表した場合は、別々に1件と数えています。

割合は入口が分かる62件に占める割合で、四捨五入しているため、足すと100%になりません。社内の扱いの1件は、使うことを禁じていた外部の生成AIに、従業員などの情報を上げたと報じられた件です（パナソニックの子会社の件の記事）。まず目に入るのは、入口を明かしていない公表の多さでしょう。53件、全体の46%です。

入口が分かる62件に絞ると、30件は自社の外、つまり委託先や使っているクラウド・SaaSの側から漏れていました。情シスの持ち場である社内のアカウントからは、6件にとどまります。

いちばん多いのは、自社の外からの漏えい

委託先からの漏えいは、自社のサーバーをどれだけ固めても防げません。10月は、その形がいくつも重なりました。

メール配信のユミルリンクは10月26日の第二報で、配信サービス「Cuenote FC」の49システムから、延べ5,162万8,280件の情報が漏えいしたと公表しています。原因はライブラリの脆弱性でした。1社の配信サービスに、利用する多くの会社の配信先のリストが載っていたわけです（ユミルリンクの件の記事）。

クラウドの事業者が入られた例もあります。IDCフロンティアの入口は、利用者が使う「IDCFクラウドポータル」の認証システムでした。そこで使っていたオープンソースソフトウェアの脆弱性を突かれたと、10月27日の第7報で明かしています。続くランサムウェアで、495の企業や自治体の仮想サーバーが止まりました（IDCFクラウドの件の記事）。宅配の「銀のさら」などを営むライドオンエクスプレスホールディングスも、データの保管を委託していたサーバーの運営会社がランサムウェアの攻撃を受け、データの取り出しや復元が難しくなったと公表しました。漏えいの可能性があるのは最大約650万件で、確定した件数ではないとしています。

いちばん考えさせられたのは、大阪大学の公表です。大学がシステムの運用を委託していた日本電気（NEC）の業務に、大学に報告されていない協力会社が関わっていました。NECは契約に基づかずに個人情報を含むファイルをクラウドストレージで共有し、作業が終わったら消すはずのファイルも残していたといいます。そのファイルが第三者にダウンロードされ、対象は7万7,851人にのぼりました。

委託先の、さらに先まで目が届いていたか。正直なところ、多くの会社にとって耳の痛い話です。

では、委託先の事故は情シスの仕事なのでしょうか。契約を結んだのは総務や購買、事業部門かもしれません。それでも、情シスが持ち主になったほうがよい理由があります。

まず、何のデータを、どのシステムに、どの形で預けたかを、技術の言葉で説明できるのは、たいてい情シスです。配信サービスに渡した項目、連携に使う鍵、委託先のアカウントの権限。事故の連絡が来たとき、最初に聞かれるのはここです。ベネフィット・ワンの委託先の件では、会員の情報とは別に、決済システムとの連携に使う認証関連情報の一部も漏れたおそれがあり、同社は10月26日にその認証情報を変えています。

しかも、報告の義務は委託した側にも残ります。個人情報保護委員会のガイドラインは、個人データの扱いを委託している場合、原則として委託元と委託先の双方が報告の義務を負うとしています。連名でも報告できます。委託先が委託元に事故を知らせたときは、委託先の報告の義務は免除されます。知らせを受けた会社の側が、報告の主体になりうるわけです。

ガイドラインは再委託にも触れていて、委託元は再委託の相手や業務の内容、扱い方について、委託先から事前に報告を受けるか承認することが「望ましい」としています。大阪大学の件と並べて読むと、この一文の重さが分かります。

台帳は、高い製品を入れなくても始められます。次のシートの「委託先の一覧」に、預けているデータと再委託の有無を書くだけでも、事故の連絡が来たときの照合表になります。

社内のアカウントは、情シスの持ち場

数は6件と少ないのに、ここで起きた漏えいは言い訳がききません。持ち主がはっきり情シスだからです。

日本経済新聞社は10月16日、システム開発に使うクラウドサービスが不正アクセスを受け、約183万件の個人情報が漏えいしたと公表しました。クラウドサービスに入るための認証情報が「何らかの手段で窃取」され、10月7日の未明から朝にかけて入られたといいます。デジタルアーツも10月21日、クラウドサービスの運用に使う認証情報を第三者に取られ、運用の環境に入られたと公表しています。対象はi-FILTER@Cloudなど6つのサービスでした。

もっと身近な例もあります。講談社BECKでは、従業員1人のメールアカウントが入られ、外部に多数の不審なメールが送られました。そのアカウントは、合併の前の会社で使っていたものです。

開発用のクラウドの鍵、運用のための共通のアカウント、合併や退職で使わなくなったメール。どれも、ふだんの棚卸しから漏れやすい所です。特権を持つアカウントと、開発で使う認証情報の一覧を作り、多要素認証が付いているかを見る。情シスにしかできない仕事でしょう。

公開しているサイトと、会員のアカウント

公開しているサイトやアプリの不備は18件、会員のアカウントの乗っ取りや大量のアクセスは6件でした。こちらは、持ち主が事業部門や開発の部門、委託先であることが多い型です。

グリーンモンスターは10月23日、FXのデモトレードのアプリ「FXなび」で、約619万件のユーザー情報などが取得されたおそれがあると公表しました。原因はアプリのAPIの機能だったとしています。日本郵政の「ゆうID」では、外部で漏えいしたIDとパスワードのリストを使ったなりすましで、249件に不正にログインされた可能性があり、同社は二段階認証を必須にすると案内しました。

情シスが自分で直す場面は、多くありません。それでも役割はあります。会社が外に公開しているサイトや管理画面、APIの一覧を持ち、持ち主の部署を書いておくこと。そして脆弱性の知らせを受け取り、持ち主に届ける窓口になることです。10月のPHPの脆弱性「php2shell」のように、自社のどこで使っているかを急いで探す場面では、この一覧が頼りになります（php2shellの記事）。ラックが国内のWebの漏えい119件を分析した結果も、接続先のAPIと認証の点検を勧めていました（ラックの分析の記事）。

会員のアカウントの件は、社員が仕事のアドレスで登録したサービスでも起こりえます。社員のパスワードの使い回しを止めるのも、情シスの仕事の延長です。

半分近くは、入口が分からない

46%の公表は、入口を明かしていません。調査中のまま第一報を出し、原因が分かる前に報じられる。今の公表の多くは、この形です。

これは、他社の公表から学べることに限りがある、ということでもあります。入口が分からなければ、自社の同じ所を点検しようがありません。

だから、他社の続報を待つより、自社で気づく仕組みを先に持つほうが効きます。どのログを、どこに、何日残しているか。漏れたかどうかを、どのログで調べるのか。漏えいに気づくきっかけと、その後に起きることは、漏れたとなぜ分かるのかの記事で詳しく書きました。

どこまでが情シスか

線引きを決めておかないと、事故の日に情シスが全部を抱えます。逆に、判断まで情シスがすると、あとで「だれが決めたのか」が問われます。

情シスは「判断の材料を出す側」で、報告するかどうか、公表するかどうかは、法務と経営が決めます。情シスが1〜2人の会社なら、法務の役を総務が兼ねることもあるでしょう。その場合も、だれが判断するかの欄だけは空けておかないほうが安心です。

うちの会社は、どの型からいちばん漏れやすいのか。会員向けのサービスを持つ会社なら公開しているサイトと会員のアカウント、配信や物流を外に任せている会社なら委託先、開発の部門がある会社なら社内の認証情報が、先に見る所になります。漏れて困るものの順番は漏えいして困るもの50のランキングに、閉じたネットワークやIP制限で守っていれば十分なのかは過去の事例から考えた特集にまとめました。

分かってから72時間の動き

個人情報保護委員会への報告には、期限があります。ガイドラインは、起点を「いずれかの部署が当該事態を知った時点」とし、速報の「速やか」の目安を「概ね3～5日以内」としています。確報は30日以内で、不正の目的のおそれがある場合は60日以内です。

意外に見落とされるのが、この起点です。委託先から総務の担当者にメールが届いた時点で、会社としては「知った」ことになりえます。情シスが知ったのがその2日後なら、速報までの日数はもう半分ほどしか残っていません。

最初の72時間を「速報の材料をそろえる時間」と考えておくと、動きやすくなります。情シスが受け持つのは、切り離しとログの保全、入られた所と範囲の見立て、広がりを止める作業の3つ。気づいてから最初の1時間の動きは、ランサムウェアに感染したら最初の1時間に書きました。報告書の形は、事故の前に用意しておけます。

今週・今月・今期にやること

全部を一度に始める必要はありません。期間ごとに、手の届くものから進めると続きます。

1. 今週は、顧客や会員の個人データを預けている委託先とサービスを、上位10社まで書き出します。預けている項目と、事故のときの連絡先も並べておきます。
2. 同じく今週、特権を持つアカウントと、開発や運用で使うクラウドの認証情報の一覧を作り、多要素認証の有無を確認します。
3. 今月中に、委託契約の事故の連絡と再委託の決まりを、法務と一緒に読み直します。連絡の期限が書かれていない契約は、次の更新で足す候補にします。
4. 同じく今月、会社が公開しているサイトと管理画面、APIの一覧に、持ち主の部署を書き込みます。
5. 今期のうちに、合併や退職、古いドメインで使わなくなったアカウントを止め、ログを何日残しているかを確認します。漏えいの連絡が来た想定で72時間の動きを机の上で1回なぞると、表の空欄が見つかります。

漏えいのニュースが続くと、全部に備えたくなります。けれど10月の115件が示しているのは、守る場所を広げることより、持ち主の決まっていない場所を減らすことなのかもしれません。あなたの会社の台帳で、まだ持ち主の欄が空いているのは、どこでしょうか。