01
RCEで実行環境を侵害
公開WebアプリにRCE（リモートコード実行）の脆弱性があると仮定。サーバー上で不正なコードを実行され、アプリの実行権限を悪用される状態です。
ATTACK × ARCHITECTURE / 攻撃と構造対策
侵入の先を、
設計で変える。
攻撃を受けたとき、何が漏れ、何が止まるのか。
情報・権限・接続を分けて、
一つの侵入から広がる被害を小さくする。
01 / 事例から、攻撃の広がりを考える
入口は一つでも、
被害は一つとは限らない。
公表された事実
タイムズカー
タイムズカー
2026年9月、不正アクセスによる会員情報と本人確認書類の画像の漏えいが公表されました。詳しい侵入手法は公表資料では明らかにされていません。
出典：タイムズカーのお知らせ ／ パーク24の公表資料
では、どんなつながりがあると、情報と画像をまとめて取られるのか。次の構成を仮定して、攻撃が広がる順番を見てみます。
仮定の攻撃シナリオ｜タイムズカーの実際の侵入経路・内部構成を示すものではありません。
01公開Webアプリ
02サービスアカウント
03DB ＋ 画像オブジェクト
到達範囲：RCEにより侵害されたWebアプリの実行環境
02
認証情報を悪用し横展開
アプリのサービスアカウント（処理用アカウント）の認証情報を悪用。DB接続情報や画像取得権限を使い、別のデータストアへアクセスを広げます。
03
一括取得し、会員IDで突合
広い読み取り権限でDBレコードと画像オブジェクトを一括取得。会員IDなどで突合し、氏名・住所・本人確認画像が結び付いた情報を持ち出します。
技術的には、何を仮定している？
RCEから、実行環境に設定されたアプリの接続情報へアクセスできる構成を仮定しています。そのサービスアカウントに、広いDB読み取り権限・画像取得権限が付与されている想定です。ここでの横展開は、その既存権限を使って別のデータストアへ到達することを指します。新たな権限昇格や特定のCVEを前提にはしていません。これは仮定のシナリオであり、タイムズカーで確認された手法ではありません。
一般的な攻撃手法の技術参考：MITRE ATT&CK T1190（公開アプリの脆弱性悪用） ／ T1552.001（ファイル内の認証情報）。タイムズカーの侵入経路を裏付ける資料ではありません。
02 / 情報を分ける。開ける鍵も分ける。
メールを送るために、
住所まで読める必要はない。
SQLデータベースの行やJSONに集約した情報をデータ分離し、用途別のサービスアカウントに最小権限を適用。トークナイゼーションで識別子を置き換え、必要な処理だけが情報を照合できる構造にします。
用途ごとの処理を選ぶ
用途別サービスアカウント・最小権限
照合API・用途別の認可token vaultを別保護・用途別に照合を認可
氏名DB
氏名
データストア別のトークン
連絡先DB
メールアドレス
データストア別のトークン
住所・生年月日DB
住所・生年月日
データストア別のトークン
本人確認画像 / R2
書類の画像
データストア別のトークン
データ分離とトークナイゼーションを組み合わせ、用途別サービスアカウントに最小権限を付与。対応表（token vault）と暗号鍵を別に保護し、照合APIの認可ポリシーで取得範囲を制限します。
設計例です。住所と生年月日をさらに分けるかなど、実際の分離単位は業務とリスクに合わせます。本人確認画像には個人情報そのものが含まれます。画像や単独の情報が漏れても安全、という意味ではありません。
SQL・JSON・R2は、どう使い分ける？
SQLのデータベースは会員情報などを管理し、JSONは情報を表す形式です。R2は画像やファイルを保存するオブジェクトストレージで、SQLの置き換えではありません。構造化データは用途ごとのDB、本人確認画像はR2などへ分ける構成が考えられます。
トークナイゼーションは、識別子を別のトークンに置き換える設計です。この例ではデータストアごとに異なるトークンを使い、対応表（token vault）を経由しなければ直接突合しにくくします。匿名化を保証するものではなく、同じトークンを全保存先で共用すると、それ自体が突合の手がかりになります。
用途別サービスアカウントと最小権限を設定し、照合APIは認可ポリシーで利用者・用途・取得対象を制限。token vaultと暗号鍵は別に保護します。非公開ストレージや短時間だけ有効なアクセス、保存期間の制限も組み合わせます。全保存先を読める共通資格情報や、全情報を返す照合APIが残れば、分離の効果は失われます。バックアップ・ログに残る情報も検証対象です。
技術参考：Cloudflare R2のAPIトークンと権限スコープ。対象バケットと操作権限を制限できます。
03 / 事業を動かす中心を守る
外側が破られても、
基幹まで直通にしない。
事業を止める影響が大きいシステムを特定し、ネットワークセグメンテーションで領域を分離。API単位の認可と管理経路の分離を組み合わせ、公開Webから基幹への到達範囲を絞ります。
公開Web外部からアクセスされる領域
用途限定APIAPI単位の認可・通信制限
基幹システム例：受注・決済・サービス提供
管理経路を分離
個別認証・必要時だけ許可
個別認証・必要時だけ許可
ネットワークセグメンテーションは、システムを通信制御できる領域に分けることです。公開Webのサービスアカウントには基幹DBの直接接続や管理操作を許可せず、用途限定APIだけを経由させます。APIの設置だけで安全になるわけではなく、認可ポリシー・ネットワーク制御・管理経路を合わせて検証します。
SYNAPSE / 構造を、攻撃で確かめる
図の上で終わらせない。
隔離環境で攻撃を再現し、被害がどこまで届くかを確かめる。企業価値への影響が大きい場所から、構造を改善します。
TEST 01 / 情報の分離
メール送信の権限で、
住所まで読めないか。
TEST 02 / 照合の制限
画像を読まれたら、
会員情報まで結びつかないか。
TEST 03 / 基幹への到達
公開Webが侵害されたら、
基幹を操作・停止できないか。
