「守っているつもり」の場所から漏れる――相次ぐ不正アクセスで見直すべき3つの思い込み

AI Librarium 公式note

2026年10月24日 09:16

10月22日、JPCERT/CCからPHPの脆弱性に関する注意喚起が出されました。対象システムでは、速やかな対策と侵害有無の確認が必要です。

本記事では、この脆弱性の技術的な対処とは別に、自社のシステムや委託先、保存データの管理で見落としがないかを、3つの視点から考えます。

10月上旬の月曜日。
経営会議の冒頭で、社長が情報システム部長に尋ねます。

「ニュースで毎日のように報じられている情報漏えい、うちは大丈夫なのか」

「当社の会員アプリは、ログインした本人の情報しか表示しない作りです。管理画面も社内からしか使っていません」

部長は本気でそう答えています。ところが翌週、関係機関の注意喚起を受けてAPIのログを調べると、アプリを経由しない大量のリクエストが見つかります。会員IDを一つずつ書き換えながら、他人の情報を引き出していた痕跡です。

これは架空の場面ですが、今秋相次いだ漏えい事案と、関係機関が公表した手口を重ねると、どの会社でも起こりうる構図です。部長が「守っている」と考えていたのはアプリの画面であって、その裏側のサーバではありませんでした。攻撃者は、守っているつもりの線の内側に、別の入口から入ってきます。

では、相次ぐ不正アクセスを受けて、自社はいま何を点検すべきなのでしょうか。この記事の答えを先に書くと、見直すべきは最新の攻撃手法ではなく、組織が「ここは守れている」「ここは自分の守備範囲ではない」と思い込んでいる場所です。具体的には、次の3つの思い込みです。

「社内向けのシステムだから大丈夫」
「業務委託ではないから、監督は不要」
「念のため、データは残しておく」

私たちAI Librariumは、内部監査やリスク管理の領域で、AIを使った点検の仕組みづくりを支援しています。その立場から、政府や関係機関が10月に相次いで出した注意喚起を読み解き、来週の会議から使える点検の問いに落とし込んでみたいと思います。

漏えいは「攻撃の高度化」より「管理の境目」から起きている

9月から10月にかけて、会員アプリや予約サイト、クラウド基盤への不正アクセスの公表が相次ぎました。冒頭の場面に近いのは、クラウド事業者のIDCフロンティアがランサムウェア攻撃を受けた事案です。同社のクラウドを使っていた鉄道会社などが、自社の会員情報への影響を次々に公表しました。カラオケ大手の第一興商は、委託先の従業員の端末がマルウェアに感染したことを原因に挙げています。

その後、IDCフロンティアは10月14日に、仮想サーバー内の顧客データを外部へ持ち出した痕跡は確認されなかったと発表しました。それでも利用企業は、調査結果が出るまでの間、漏えいの可能性の公表と顧客対応に追われました。さらに10月16日には、ヤマト運輸が後払い決済サービスから約531万件の顧客情報が持ち出されたことを、日本経済新聞社がシステム開発用のクラウドサービスから約183万件の情報が漏えいしたことを、それぞれ発表しています。

こうした状況を受け、内閣官房国家サイバー統括室は10月9日に事業者向けの対応文書を出し、総務省も同日、所管事業者と関係団体に同じ内容を通知しました。国家サイバー統括室は、一連の事案の原因を次の3つに整理しています。

ウェブシステムに係る脆弱性の悪用
サプライチェーンを通じた侵害
堅牢さを欠くデータ管理

注目したいのは、3つとも新しい攻撃技術の名前ではないことです。どれも「どこまでを自社が管理すべき範囲と考えていたか」という、管理の境目の問題です。

攻撃者は、守りの固い正面玄関ではなく、組織の中で「ここは誰の担当でもない」と思われている場所を探します。社内向けの管理画面、委託先のサーバー、使い終わったのに残っているデータ。被害が大きくなった事案の多くは、こうした境目で起きています。

思い込み①「社内向けのシステムだから大丈夫」

点検の打ち合わせで、よく聞く言葉があります。

「それは社内の担当者しか使わない管理画面なので、IDとパスワードで守っています」

問題は、その管理画面がインターネットから届くかどうかです。届くのであれば、使う人が社内の担当者だけでも、攻撃者から見れば公開システムと変わりません。

JPCERT/CCが10月8日に出した注意喚起は、まさにこの盲点を指摘しています。報告された手口の一つは、一般公開されているスマートフォンアプリを解析してAPI（システム同士がデータをやり取りする窓口）の入口や鍵を特定し、画面からは本来実行できない内部のAPIを呼び出すというものです。ユーザー権限の書き換えや、不正なアカウントの作成まで行われています。さらに同センターは、BIツール（社内の分析ツール）や従業員向けの管理システムなど、不特定多数のアクセスを想定していないシステムも被害に遭っていると明記しました。

情報通信研究機構（NICT）の分析チームも10月13日、この手口を「A2B攻撃」（App-to-Backend：アプリから裏側のサーバへの攻撃）と名付けて注意喚起を出し、総務省も15日に事業者向けに周知しました。ポイントは、アプリそのものに脆弱性がなくても、裏側のサーバの認証・認可や入力値のチェックに不備があれば攻撃が成立することです。攻撃者は正規のアプリを経由せず、解析で得た仕様をもとにサーバへ直接リクエストを送ってきます。「アプリ側で制御しているから大丈夫」は、もう通用しません。

個人情報保護委員会（PPC）も、同じ型の事例を挙げています。ログインした後、URLの会員IDなどの値を書き換えるだけで、他人のデータを取得できてしまった事例です。原因として、管理対象から漏れているAPIがあったこと、会員IDが連番で推測しやすかったこと、短時間の大量アクセスを制限していなかったことが挙げられています。

10月16日に公表された日本経済新聞社の事案も、入口は顧客向けのサービスではありませんでした。システム開発に使っていたクラウドサービスに、盗まれた認証情報で入られたといいます。開発環境やテスト環境は「本番ではないから」と管理が後回しになりがちです。しかし、そこに個人情報が置かれていれば、漏れたときの重さは本番と変わりません。PPCが今回示した安全管理措置の例示にも、テストデータへの個人データの利用を最小限にすることが含まれています。

ここで経験のある点検担当者が最初に作るのは、「公開しているシステムの一覧」ではありません。「外から届くものの一覧」です。公開のつもりがないものや開発・テスト用の環境ほど、一覧から漏れているからです。

思い込み②「業務委託ではないから、監督は不要」

2つ目の思い込みは、自社のシステムの外側にあります。自社のサーバーをどれだけ固めても、顧客データがどこを通り、どこに置かれているかを把握していなければ、守りようがありません。

PPCが10月7日に改訂した注意喚起資料には、利用していたクラウドサービスから漏えいした事例が載っています。原因の一つは、利用企業がクラウドの利用は業務委託に当たらないと考え、取扱状況を監督していなかったことです。グループの親会社に人事データの管理を任せていた事例でも、子会社が「グループ内だから」と監督していなかった点が問題とされました。PPCは、委託先が親会社であっても通常の外部委託先と同じ基準で監督するよう求めています。

PPCはこうした事例への措置が十分でない場合、安全管理措置や委託先の監督の義務に違反すると判断される可能性があるとまで書いています。「委託契約を結んでいないから対象外」という整理は、もう通用しないと考えたほうがよいでしょう。

国家サイバー統括室の文書も、「委託先企業と共に管理する」という認識を求め、具体的な確認事項を挙げています。再委託先を含めた管理状況の把握、契約での報告義務の規定、業務終了後のデータ削除の徹底、そしてサプライチェーン上の重要な依存関係の把握です。

ここでの処方箋は、委託先台帳を「契約の一覧」から「データの流れの一覧」に作り替えることです。契約の一覧では、メール配信ツールの裏側にあるクラウド基盤は見えません。顧客データがどのサービスを経由し、どこに保存されているかをたどれば、1社が止まると何が止まるかという依存の集中も見えてきます。

思い込み③「念のため、データは残しておく」

3つ目は、技術ではなく習慣の問題です。退会した会員の情報、終了したキャンペーンの応募者リスト、担当者が手元のフォルダに保存した顧客一覧。「いつか使うかもしれない」と残したデータは、漏えいした瞬間に被害の件数へ変わります。

PPCは今回の注意喚起で、個人情報保護法22条を改めて示しました。利用する必要がなくなった個人データは遅滞なく消去するよう努める、という規定です。不要なデータを消していなかったために漏えいが深刻化した事例にも接しているとして、保管している個人データの必要性を、法令上の根拠とともに確認するよう求めています。従業員が個人のフォルダに業務データを保存していたため、本来消すべき古いデータまで漏えいした事例も紹介されています。

10月16日に発表されたヤマト運輸の事案では、持ち出された購入者情報の対象期間が2018年10月から2026年9月まで、約8年分に及びました。決済サービスには支払い管理のために一定期間持つ必要のある情報もあり、保存期間が適切だったかどうかは外からは判断できません。ただ、自社に置き換えて「何年分を、何のために持っているのか」を問い直すきっかけにはなります。

点検の現場では、次の一言が分かれ目になります。

「このデータを持っている理由を、一行で書けますか」

書けないデータは、漏れたときに顧客にも当局にも説明できません。逆に言えば、保存の根拠を一行で書く作業そのものが、消してよいデータを見つける最短の方法になります。攻撃を防ぐ対策と違って、データを減らす対策は確実に効きます。持っていないものは、漏れないからです。

来週の会議で使える、9つの点検の問い

3つの思い込みを、そのまま会議で使える問いにすると次のようになります。「はい」と即答できない問いが、自社の境目です。

最後の問いは、国家サイバー統括室が今回とくに推奨している点です。侵入が複数確認されている状況を踏まえ、不審な通信や大量アクセスの痕跡がないか、アクセスログ等を点検・分析するよう求めています。NICTもA2B攻撃について、2026年8月以降のアクセスログ・APIログ・認証ログを優先して確認するよう求めています。冒頭の部長の答えも、ログで確かめた結果でなければ、根拠のある「大丈夫」にはなりません。

AIは攻撃を速くしたが、入口は変えていない

今回の一連の事案は「AIハッキング」という言葉とともに報じられることが多くあります。JPCERT/CCは10月15日、攻撃者が使ったとみられるインフラの調査結果を公表し、攻撃者がAIを使って既知の脆弱性のスキャンやAPI経由の攻撃を行っていたことを確認したといいます。公開されているスマートフォンアプリを解析し、アプリが使うAPIを特定した痕跡も見つかっています。AIが攻撃の準備と探索を速めていることは、もはや推測ではありません。

それでも、ここまで見てきた入口は、管理画面、API、開発環境、委託先、残ったデータという昔からある場所です。AIが変えたのは攻撃の速さと量であり、守るべき場所ではありません。だからこそ、守る側に必要なのは新しい魔法ではなく、境目の点検を一度きりで終わらせず、繰り返し回せる仕組みにすることだと考えています。

そのうえで、点検の側でもAIは役に立ちます。私たちが内部監査やリスク管理の支援の中で取り組みを進めているのは、次のような使い方です。

政府や関係機関の注意喚起を、出典付きの点検項目に分解して管理する

委託先からの回答書や契約書を読み込み、報告義務や削除条項の抜けを洗い出す

大量のログから、注意喚起で示されたパターンに近いアクセスを一次的に拾い出す

いずれも、AIが判断を下すのではありません。人が判断すべき箇所を絞り込む、という位置づけです。要件が変われば点検項目を差し替えます。PPCは安全管理措置のガイドラインの「手法の例示」を見直しており、内容の確定は来年4月の予定だといいます。点検の基準は、これからも動き続けます。

「守っている」と思う線を、引き直す

冒頭の部長に足りなかったのは、技術の知識ではありません。「守っている」と考えていた線が、アプリの画面の手前に引かれていたことです。社内向けのシステムや開発環境、委託ではないクラウドやグループ会社、念のため残したデータ。どれも「守れている」か「自分の担当ではない」と思われていた場所であり、今秋の漏えいの多くはそこから起きています。

まずは上の9つの問いを、次の経営会議か部門の定例で一度だけ読み上げてみてください。即答できなかった問いが、自社の線を引き直すべき場所です。

その線を引き直す作業や、点検を繰り返し回せる仕組みづくりについて、同じ課題に向き合っている方と意見を交わせればうれしく思います。私たちも引き続き、内部監査・リスク管理とAIの現場から得た知見を発信していきます。