仕組み：なぜVPNから入られるのか

※侵入の詳しい方法は公表されていないため、
同じような事例で一般的に使われる仕組みとして説明しています。

VPN機器は「玄関」なので、
誰でもインターネットから玄関の前まで来られる場所に置かれています。
攻撃者は、この玄関の機器そのものの欠陥を狙います。

1. 欠陥のある機器を探す：インターネット上のVPN機器を自動で調べ、修正されていない機器を見つける
2. ログイン前の画面に細工した通信を送る：欠陥があると、パスワードの確認を飛ばして中に入れたり、機器の上で好きな命令を実行できたりする
3. 機器の中から「合鍵」を盗む：VPN機器には、ログインした人の情報や接続中の通行証が保存されている。これを盗めば、正規の担当者になりすませる
4. 本物の担当者として中を歩き回る：盗んだアカウントで入るので、システムからは「いつもの担当者が作業している」ようにしか見えない

保守担当者は多くのシステムを触る立場なので、
そのアカウントを使われると、
一気に広い範囲へ手が届いてしまいます。

対策のヒント：守りが固い仕組み

「玄関さえ守れば、中は安全」という考え方をやめ、中に入った後も、
アクセスのたびに「誰が・どの端末から・何をしようとしているか」を確認するやり方があります。
あわせて、アカウントごとの権限を必要な範囲だけに絞っておけば、
1つのアカウントを使われても、何でも見られる状態にはなりません。

エンジニア向けメモ

SSL-VPNなどの境界機器は、インターネットに公開され、
かつ内部への入口になるため、
認証前に悪用できる脆弱性が出ると即座に狙われます。
修正版の適用を最優先にするのは当然として、次の点が効きます。

• 機器のログを外部に転送する：侵入者は機器内のログを消すことが多いため、ログは別の場所に送って保管する
• 特権アカウントを常設しない：保守用の強い権限は、作業のときだけ申請・承認して一時的に付与する（特権ID管理）
• VPNからの移行を検討する：ネットワーク単位ではなく、アプリ単位で毎回認証・認可するゼロトラスト型のアクセス（ZTNA）に寄せる

仕組み：なぜ「命令」として実行されてしまうのか

画像をアップロードすると、サーバーは裏側で、
サイズの変更や文字の読み取りなどの処理をします。
このとき、サーバーの中では「このファイルを、この形式に変換せよ」といった命令文を組み立てて実行しています。

問題は、その命令文の中に、利用者が送ってきたデータを、
そのまま差し込んでしまう作りになっている場合です。

• 本来の命令：「photo.jpg を縮小せよ」
• 細工したデータを送ると：「photo.jpg を縮小せよ。ついでに、この攻撃用のプログラムを実行せよ」

サーバーは、どこまでがデータで、
どこからが命令なのかを区別できず、後半まで実行してしまいます。

サーバーを乗っ取ると、攻撃者はその中を自由に見られます。
サーバーには多くの場合、
データベースに接続するためのIDとパスワードが保存されています。
それを読み取れば、サーバーになりすまして、
顧客のデータベースから情報を引き出せてしまいます。

※データベースに到達した具体的な方法は公表されていないため、
後半は一般的な流れとして説明しています。

仕組み：なぜ「直す前」に狙われるのか

メーカーが修正版を出すと、
同時に「この部分に欠陥がありました」という情報も公開されます。
利用者に早く直してもらうためには必要なことですが、
攻撃者にとっては「ここに穴がある」という地図にもなります。

1. 修正の中身を調べる：修正版と古い版を比べれば、どこを直したかが分かり、攻撃の方法を作れる
2. 直していない相手を探す：インターネット上で、まだ古い版のままの相手を自動で探す
3. 攻撃する：修正版が出てから数日で攻撃が始まることも珍しくない

さらに、売上の分析ツールは、
分析のために顧客データを広く読める権限を持っていることがよくあります。
ツールに入られると、ツール本来の「データを書き出す機能」で、
まとめてダウンロードできてしまいます。

※どの欠陥が使われたかは公表されていないため、
一般的な流れとして説明しています。

仕組み：Webシステムの穴から、どうやって中まで入るのか

※侵入の詳しい方法は公表されていないため、
同じような事例で一般的に使われる仕組みとして説明しています。

Webシステムは、利用者が入力した内容を受け取って、
データベースに問い合わせたり、ファイルを保存したりしています。
代表的な穴が、入力欄に、
データベースへの命令文を紛れ込ませる手口です。
システムがそれを区別せずにデータベースへ渡してしまうと、
「この人の情報を見せて」という問い合わせが、
「全員の情報を見せて」に書き換わってしまいます。

ほかにも、画像の代わりに攻撃用のプログラムをアップロードして実行させる、
システムに組み込んだ古い部品の欠陥を突く、
といった入り口がよく使われます。

一度Webサーバーを操れるようになると、
サーバーが持っているデータベースや、
ファイルの保管場所に入るための鍵を盗めます。
サーバーは本来、本人確認書類の画像などを扱うための鍵を持っているので、
それを使えば中のデータに手が届いてしまうのです。

仕組み：なぜゼロデイは防げないのか

「ゼロデイ」とは、メーカーがまだ欠陥に気づいておらず、
修正版が出るまでの日数が「0日」の状態の欠陥のことです。
攻撃者だけが先に欠陥を見つけているため、修正版も、
攻撃を見分けるルールもまだありません。
正しく運用していても、侵入そのものは防ぎようがないのです。

だからこそ、入られた後の守りが重要になります。
パスワードが元に戻せない形で保存されていれば、仮に盗まれても、
元のパスワードを知るのは非常に難しくなります。

対策のヒント：守りが固い仕組み

• 修正版が出たら、すぐに適用する：特に、インターネットから届く場所にあるソフトは最優先で
• 部品から顧客データへ、直接手が届かないようにする：外からのデータを扱う部品と、顧客データを置く場所を分け、それぞれの権限を絞る
• パスワードは元に戻せない形で保存し、データは暗号化する
• いらないデータは持たない：退会者のデータや、削除された画像の情報を持ち続けた事例は、「持たないデータは漏れない」という教訓そのものです

エンジニア向けメモ

画像処理サーバー：画像や動画の変換は、
外部コマンドや変換ライブラリを呼び出す実装が多く、
過去にも画像処理ライブラリで深刻なコマンド実行の脆弱性が見つかっています（2016年のImageTragickなど）。
コマンドはシェル経由で文字列として組み立てず、引数を配列で渡す。
変換処理は外部への通信を制限した隔離環境で動かし、
そこにはデータベースの認証情報を置かない。
Exifなどの位置情報は、
保存前に取り除くかどうかを方針として決めておく、
といった設計が有効です。

社内ツール：BIツールのような社内ツールは、
インターネットから直接到達できる場所に置かず、
社内の認証基盤の背後に置きます。
分析用の接続は、本番ではなく読み取り専用の複製に向け、
個人情報の列は伏せる。
大量の書き出しには上限と通知を設けておくと、
一括ダウンロードの段階で止められる可能性があります。

Webシステム：SQLは必ずプレースホルダで組み立てる。
ストレージへのアクセスは、サーバーに長期の鍵を置くのではなく、
権限を絞った一時的な認証情報で行う。
保管期間を過ぎたデータは自動で削除する仕組みにしておく、
といった対策が基本です。

メールのパスワード保存：今回の原因は公表されていませんが、
一般論として、メールの世界には「サーバーが元のパスワードを知っていないと使えない」古い認証方式があります（POP3のAPOPや、CRAM-MD5など）。
こうした方式との互換性のために、
パスワードを元に戻せる形で持たざるを得ない、
というのが業界の構造的な課題です。
古い認証方式を廃止し、
暗号化された通信の上での認証やアプリ専用パスワードに移行することが、
根本的な対策になります。

仕組み：パスワードは、どうやって盗まれるのか

※不正ログインに使われた情報の入手方法は公表されていないため、
一般的な仕組みとして説明しています。

不正ログインに使われるIDとパスワードは、多くの場合、
次のような方法で手に入れられています。

• 使い回しを狙う：別のサービスから漏れたIDとパスワードの一覧を使い、同じ組み合わせでログインを試す
• だまして入力させる：本物そっくりのログイン画面に誘導し、入力させる（フィッシング）
• パソコンから抜き取る：担当者のパソコンにウイルスを仕込み、ブラウザに保存されたパスワードを盗む
• 総当たりで試す：推測しやすいパスワードを、片っ端から試す

管理画面がインターネットから誰でもアクセスできる場所にあり、
パスワードだけでログインできる作りだと、
どれか一つの方法で手に入れたパスワードで、
そのまま入れてしまいます。
そして、管理画面はシステム全体を操作できる「マスターキー」です。
同じサーバーに5社のデータが同居していたため、
1つのマスターキーで全社分に手が届いてしまいました。

対策のヒント：守りが固い仕組み

管理画面のような重要な入口は、
パスワードだけで入れないようにするのが基本です。
スマホへの通知や物理的なセキュリティキーを組み合わせれば、
パスワードが盗まれても、それだけではログインできません。
さらに、管理画面を社外から自由に入れる場所に置かないこと、
利用企業ごとにデータを分けておくことも大切です。

エンジニア向けメモ

複数の顧客企業が1つの環境を共有するマルチテナント型のサービスでは、
管理者権限が奪われると、全テナントに被害が及びます。

• 管理画面の到達性を絞る：アクセス元を限定し、社内の認証基盤（SSO）経由でのみ入れるようにする
• フィッシングに強い認証にする：SMSや認証アプリのコードは、偽サイトで中継されると突破されることがある。管理者には、FIDO2などのセキュリティキーやパスキーが望ましい
• テナントを分離する：データベースを分ける、行単位のアクセス制御をかけるなどして、1社の権限で他社のデータが見えない構造にする
• 管理操作を監視する：深夜・休日の管理ログインや、大量のデータ参照を検知して通知する

考えられる手口（推測）

ID・パスワードが漏れていないのに、
なぜこれほどの情報が引き出せたのでしょうか。
手口は公表されていませんが、考えられるのが、
冒頭で紹介した「部屋ごとの鍵がない」タイプの欠陥です。

• 自分の契約を見る：…/keiyaku?id=A0001 → 自分の情報（正常）
• 番号を1つ変える：…/keiyaku?id=A0002 → 他人の情報が出てしまう

一度ログインすれば、
あとは番号を変えた問い合わせをプログラムで大量に送るだけで、
他人の情報を次々と引き出せます。
440万人分のパスワードを集めるのは現実的ではないので、
「パスワードの使い回し」よりも、
こうした確認抜けのほうが説明しやすい、というのが推測の理由です。

対策のヒント：守りが固い仕組み

• データを返すたびに、「本人の依頼か」を確かめる
• 推測しにくい番号を使う：番号を順に変えるだけでは、他人のデータにたどり着けないようにする
• 回数制限と異常検知を入れる：1人が短時間に大量の問い合わせをしたら、途中で止める

エンジニア向けメモ

この種の欠陥はIDOR（Insecure Direct Object Reference）と呼ばれ、
OWASP API Security Top 10では「オブジェクト単位の認可の不備（BOLA）」として最上位に挙げられています。

• 認可を一か所で強制する：各APIの実装者に任せず、「このユーザーはこのデータにアクセスできるか」を判定する共通の仕組みを通す
• 認可のテストを自動化する：「他人のIDを指定したら拒否されること」を、すべてのAPIのテストに含める
• セキュリティ監視でAPIの異常を見る：1つのセッションが多数の異なる契約を参照する、といった振る舞いを検知する。今回のように性能監視でしか気づけない状態は、検知の設計が抜けているサインです

仕組み：なぜ他人の画面が表示されたのか

アクセスが集中すると、
サーバーは同じページを何度も作り直すことになり、重くなります。
そこで、一度作ったページのコピーを一時保存しておき、
次の人にはそのコピーを渡す仕組みを使います。
お店で、よく出る商品を作り置きしておくようなものです。

誰が見ても同じ内容のページなら、これで問題ありません。
ところが、マイページや購入画面は、一人ひとり内容が違います。

1. Aさんがマイページを開く → サーバーがAさん用のページを作り、そのコピーを一時保存する
2. 直後にBさんがマイページを開く → サーバーは「同じページのコピーがある」と判断し、AさんのページをBさんに渡してしまう

作り置きしてはいけない「個別の注文品」まで作り置きしてしまった、
というのが今回の事故の仕組みです。

対策のヒント：守りが固い仕組み

設定の変更も、プログラムの変更と同じようにほかの人の確認を通し、
ごく一部の利用者で試してから全体に広げるやり方があります。
問題が起きても、影響を小さいうちに食い止められます。

エンジニア向けメモ

• 個人ページはキャッシュさせない：ログイン後のページには「Cache-Control: private」や「no-store」を付け、Cookieを発行する応答を共有キャッシュに載せない
• キャッシュ対象は「許可リスト」で決める：キャッシュしてよいパスを明示的に列挙し、それ以外はキャッシュしない設定を既定にする
• 設定もコードとして管理する：CDNの設定をコードで管理してレビューを通し、検証環境で「ログイン済みのページがキャッシュに載らないこと」をテストしてから反映する

仕組み：「情報を外に送り続けるプログラム」とは

※不正なプログラムが仕込まれた経緯は公表されていないため、
一般的な仕組みとして説明しています。

攻撃者は、サーバーの欠陥や盗んだ管理者のアカウントを使って、
サーバーの中のプログラムを書き換えます。
狙われやすいのは、購入者が住所やカード番号を入力する、
注文や決済の処理です。

書き換えられたプログラムは、ふだんどおり注文を受け付けながら、
裏で入力された情報のコピーを、
攻撃者のサーバーにも送るようになります。
購入者は普通に買い物ができ、商品も届きます。
店舗から見ても、注文は正常に処理されています。
誰も異変に気づかないまま情報だけが流れ続けるため、
発覚までに長い時間がかかりやすいのです。

対策のヒント：守りが固い仕組み

外部のサービスを使う以上、
預け先が被害を受けるリスクはゼロにはできません。
だからこそ、預けるデータを必要最小限にし、
大事なデータとは分けておくことが大切です。
たとえばカード番号は、自社のサーバーを通さずに、
決済専門の会社の画面で直接入力してもらう方法があります。

エンジニア向けメモ

• ファイルの改ざんを検知する：本番サーバーのプログラムが、正規のリリース以外の経路で変更されたら通知する。そもそも本番環境を、リリース以外では書き換えられない構成にする
• 外への通信を制限する：決済処理を担うサーバーから、許可していない宛先への通信を遮断すれば、情報を外に送る処理が動いても届かない
• ブラウザ側の改ざんにも備える：決済ページに読み込むスクリプトを、コンテンツセキュリティポリシー（CSP）などで制限する
• カード情報を持たない：国内のクレジットカード・セキュリティガイドラインでも、加盟店はカード情報を自社で保存・処理・通過させない「非保持化」が基本とされている

仕組み：アプリの「裏口」を直接呼び出す

スマホアプリは、画面の裏で、
会社のサーバーにある窓口（API）とやり取りをしています。
アプリは誰でもダウンロードできるので、攻撃者はアプリを分解して、
中に書かれている窓口の住所や、接続に使う鍵を探します。
その中に、画面からは使えない管理用の窓口が含まれていることがあります。

サーバー側が「アプリの画面から呼ばれるはずだから大丈夫」と考えて、
その窓口で本人確認や権限の確認をしていなければ、
攻撃者は窓口を直接呼び出して、
大量の会員情報を引き出せてしまいます。

エンジニア向けメモ

アプリに埋め込んだAPIキーは、
配布した時点で秘密ではありません。
キーは「どのアプリからの通信か」の識別には使えても、
認可の代わりにはなりません。
管理用のAPIは利用者向けのAPIとは別の経路に分け、
すべての呼び出しでサーバー側の認証・認可を通すことが前提です。