APIデータ漏えい：ログインは正しい。それでも、そのデータを読んではいけない。

ログインに成功しても、漏えいは起きる

顧客が正しくログインし、APIがセッションを受け入れます。その後の要求で別の顧客のプロフィール、見せてはいけない項目、全顧客の出力が返ります。認証は成功しても、その主体が何を読めるかという判断が破られています。

この独自のAPIデータ漏えいプレイブックは、9段階・36の判断で構成しています。REST、GraphQL、モバイル、提携先、内部APIからの権限外の読み取り、過剰な項目の開示、エクスポート、関連する書き込みを扱います。匿名アクセスや認証情報の盗用もあり得ます。見出しは重要な一場面であり、全事件の説明ではありません。自社の認可モデルと記録方式に合わせて使ってください。

初動、証拠、仕組み、封じ込め、範囲、広がり、修復、連絡、復旧確認の9段階。不明は担当付きの調査として残します。

独自の対応図。必要になった時点で封じ込めを始め、証拠、範囲、連絡は並行します。段階の番号は作業の整理であり、順番待ちの指定ではありません。

ここから始める：最初の1時間

目安	行動	完了を示すもの
0〜5分	案件を作り、対応責任者、API管理者、緊急変更の責任者を決める。	UTCの発見時刻、連絡先、影響操作。
5〜15分	最小限の証拠の保存と、流出操作の制限を並行する。	制限した証拠の参照先、対策と配置時刻。
10〜25分	モバイル、提携先、旧版、直接オリジン、待機中出力の迂回を調べる。	経路の一覧と封じ込め試験。
15〜35分	既存のエッジ、アプリ、認証、データ参照ログを期限前に保全する。	出力明細、保持とサンプリングの欠損。
25〜45分	認証情報、オブジェクト・テナント、項目、一括機能の欠陥を分ける。	再現した仕組みと未検証の仮説。
35〜60分	範囲台帳を始め、個人情報・業務担当を呼び、最初の状況報告を出す。	確定と潜在範囲、担当者、次の更新時刻。

調整の目安であり、緊急措置を遅らせる期限ではありません。証明のために全件取得したり、Bearerトークンをチケットに貼ったり、記事に出てくる企業の本番APIを試したりしません。 合意した計画の下、自社管理の合成アカウントとレコードを使います。IP遮断でグラフが静かになっただけでは、封じ込めの証明になりません。

準備、担当者、判断の規則

操作、版、ホスト名、直接オリジン、管理者、保存先、提携先依存、出力を台帳にします。権限表と拒否試験、緊急制限と代替手段、信頼できる主体・要求・出力オブジェクトを結合できるログを準備します。イベントを省略・抽出するサービスも把握します。

はい： 対応し、他の該当する確認も続けます。
いいえ： 根拠、期間、確認範囲を記録します。
不明： 担当者、次の確認時刻、暫定の制限を決めます。ログ不足を「いいえ」にしません。
対象外： 理由と確認者を残します。

案件ID、操作と版、環境、UTC期間、回答、証拠の参照、対応と結果、担当者、見直し時刻を記録します。生の証拠は非公開で扱います。36項目の判断台帳（CSV）をダウンロード。空欄は案件作業用です。後から表計算に入力する値は、信頼できないテキストとして扱います。

責任	主担当	少人数組織での対応
調整、重大度判断、再開承認	対応責任者	開発責任者や責任を持つ経営者
経路、ジョブ、キャッシュの制限と業務継続	SRE／基盤管理者	ホスティング管理者や事業者
認可と返却処理の説明・修復	API／バックエンド＋AppSec	開発者と独立したセキュリティ確認者
ログ保全、要求の結合、範囲評価	SOC／SIEM＋データ管理者	管理者やMSPとDB・業務データの管理者
セッション、トークン、接続先の秘密情報	IAM／クラウド管理者	ID管理者
義務、通知、二次被害の判断	個人情報／法務、広報、不正対策	専門家の支援を受ける業務担当者

役割は兼務できますが、変更者だけで修復を検証しないようにします。ページのチームタグは検索用であり、対応者全員の一覧ではありません。

この手順の言葉

用語	意味
認証	誰、または何が呼び出しているかを確かめること。
認可	その主体が、この操作で、このオブジェクトと項目を使えるか決めること。
オブジェクト／レコード	プロフィール、請求書、ファイルなどの1件。必ずしも1人ではありません。
テナント	共用サービスの顧客・組織の境界。正当な委任も明示する必要があります。
オブジェクト・項目・機能の認可	どの対象、どの項目、どの操作を許可するかという別々の確認。
相関ID	コンポーネント間の記録を結ぶ、信頼できる要求識別子。
出力と受信	サーバーが出力を記録しても、人が見た・保存したことまでは分かりません。
露出期間	不正な取得が可能だった期間。観測した攻撃期間より長い場合があります。
カナリアリリース	安全性と業務動作を確認してから広げる、限定的な再開。

OWASPはオブジェクトの認可（API1）、項目の認可（API3）、機能の認可（API5）を区別しています。個別に確認します。権限が設計どおりでも一括業務フローに悪用対策が必要な場合があり、自動化された要求を全て認可の欠陥と呼びません。OWASP API6。

0. 初動：流出を止め、対応責任者を決める

判断P01〜P04：初動：流出を止め、対応責任者を決める。はい・いいえの分岐は次の表にもあり、不明は調査として残します。

独自の判断図。該当する問いを全て確認します。他の確認を飛ばす経路ではありません。

判断	はい	いいえ	証拠／不明を解くもの	主担当
P01. 権限のないデータアクセスが今も続いているか？	該当操作を制限し、直ちに封じ込めを検証する。	直近の要求と、過去の露出も調べる。	アプリイベント、応答の最小サンプル、利用者からの報告。	対応責任者＋SRE
P02. 管理下のテストデータで報告を再現できるか？	最小限の証拠と要求の相関IDを保存する。	未解決のまま追跡し、秘匿化した証拠を求める。	自社のテストアカウント2件、期待する権限、ビルド。	AppSec＋API管理者
P03. 機微な項目や複数テナントに届く可能性があるか？	重大度を上げ、個人情報担当とデータ管理者を呼ぶ。	確認したデータを記録し、範囲が変われば見直す。	データ分類、操作と保存先の対応、権限モデル。	データ管理者＋個人情報担当
P04. 対応責任者と変更の実施責任者が決まっているか？	時系列を作り、次の報告時刻を決める。	調整が止まる前に両者を任命する。	案件ID、連絡先、変更権限、サービス依存関係。	対応責任者

具体的な操作手順

UTCで案件を開始します。報告者、ホスト名、API操作、要求ID、最初に観測した時刻を記録します。発見時刻と、露出が始まった可能性のある時刻を分けます。
同じデータを返す操作と、それに依存する業務をAPI管理者に確認します。狭い制限で流出が止まるならそれを選び、止まらなければ広い停止を判断します。
自社が管理する2つのアカウントと合成レコードで、利用者・テナント境界を越える最小限の証拠を得ます。可能なら影響を受けたビルドと同じ検証環境を使います。本番確認にはサービス管理者の許可と範囲を限定した計画が必要です。
要求の構造、返された項目名、ビルドとポリシーの版、期待値と実測値をアクセス制限した証拠保管先に残します。通常のチケットにはトークンや個人情報の実値を載せません。

できたことの確認： 担当者が、止めた操作、業務への影響、初期重大度の根拠を示せます。再現が終わるまで緊急の封じ込めを待たせません。

1. 証拠：露出していた期間を組み立てる

判断P05〜P08：証拠：露出していた期間を組み立てる。はい・いいえの分岐は次の表にもあり、不明は調査として残します。

独自の判断図。該当する問いを全て確認します。他の確認を飛ばす経路ではありません。

判断	はい	いいえ	証拠／不明を解くもの	主担当
P05. 調査期間全体のゲートウェイとアプリのログがあるか？	原本、完全性ハッシュ、保持条件を保存する。	残る証拠を確保し、見えない期間を記録する。	UTC期間、サンプリング、保持期間、出力のハッシュ。	SOC＋SRE
P06. 呼び出し元と返したオブジェクトを結び付けられるか？	信頼できる主体、要求ID、オブジェクト監査を結合する。	ゲートウェイ件数だけではレコードを確定できないと記録する。	検証済み主体ID、相関ID、オブジェクト・テナントID。	SOC＋API管理者
P07. 問題を導入した最初のリリースや設定変更が分かるか？	余裕を含む調査開始時刻を、その変更から設定する。	根拠のある最も早い露出可能時点まで広げる。	配置履歴、ポリシー変更、過去の試験結果。	開発＋SOC
P08. 応答がキャッシュ、エクスポート、非同期配信されたか？	キャッシュとジョブの証拠を保存し、配信経路を追う。	確認した代替経路を記録する。	CDN設定、ジョブID、保存先の参照・ダウンロードログ。	SRE＋データ管理者

具体的な操作手順

CDN・WAF・ゲートウェイ、アプリ、認証、DB監査、配置と設定変更の記録を、ローテーションや再配置で失う前に出力します。封じ込めと並行します。
各記録の時刻帯、時計のずれ、取り込み遅延、サンプリング、保持期間、欠損を記録します。出力のハッシュを取り、アクセスを制限し、収集・移管者を残します。
許可されたテスト要求をエッジからバックエンドまで追います。要求IDの生成箇所と認証主体の決定箇所を確認します。利用者が自由に送れるヘッダーは、主体の証明にはなりません。
露出を導入した配置や権限変更を探します。ログ保持より古ければ、その期間は観測不能とします。アラートの発生時刻は、漏えい開始の証明にはなりません。
応答本文の全面ログ取得は避けます。操作ID、認可結果、仮名化した識別子、項目分類、件数を優先し、必要な生のサンプルは別に制限して保管します。

できたことの確認： 証拠一覧と説明可能な調査期間があり、再構成できない区間も明記されています。

2. 仕組み：どの権限境界が破られたか

判断P09〜P12：仕組み：どの権限境界が破られたか。はい・いいえの分岐は次の表にもあり、不明は調査として残します。

独自の判断図。該当する問いを全て確認します。他の確認を飛ばす経路ではありません。

判断	はい	いいえ	証拠／不明を解くもの	主担当
P09. 別の所有者やテナントのオブジェクトを取得できるか？	オブジェクト認可と同等の全経路を調べる。	項目、機能、一括操作を別に検証する。	管理下のアカウント、所有関係、委任の規則。	AppSec＋バックエンド管理者
P10. 許可されたオブジェクトに見せてはいけない項目があるか？	返却項目を許可したものに限定する。	呼び出し元の役割ごとの項目許可リストを残す。	応答スキーマ、機微性、役割別の試験。	バックエンド＋データ管理者
P11. 一般利用者が特権機能や一括操作を呼べるか？	出力、検索、バッチ、管理操作を制限する。	別メソッド、GraphQL、ジョブの取得も調べる。	機能の権限、役割表、操作の一覧。	AppSec＋API管理者
P12. 認証情報の悪用や匿名アクセスも関わるか？	認証側を封じ込めるか、不要な匿名アクセスを止める。	認証が正しくても認可の修復を続ける。	トークン検証、主体・発行者・対象、匿名操作の方針。	IAM＋AppSec

具体的な操作手順

期待する権限を 主体→操作→オブジェクト→項目→テナント→条件 として書きます。正当な委任、サポート担当、サービス主体も含めます。テナントが違うだけで不正と決めません。
オブジェクトの所有権、項目の可視性、特権機能を別々に検証します。ログイン成功が示すのは認証の結果であり、返される全レコードの閲覧権限ではありません。
ゲートウェイ、バックエンド、DB照会のどこで認可しているか追います。モバイル画面でボタンを隠したり、ゲートウェイでトークンを確認したりしても、バックエンドの認可は必要です。
モバイル・提携先向けの操作、旧版、直接接続できるオリジン、GraphQLのノードとリゾルバー、バッチ、一覧・検索、非同期出力を棚卸しします。最初のRESTパス以外も確認します。
盗用が疑われればトークン検証と実際の操作を調べます。認証成功だけでは、盗まれたアカウントと、正規利用者による別の欠陥の悪用を区別できません。

できたことの確認： 再現した仕組みと未検証の仮説を分けています。見出しは対応場面を表すもので、全てのAPI漏えいにログインが必要だという主張ではありません。

3. 封じ込め：データへの全経路を閉じる

判断P13〜P16：封じ込め：データへの全経路を閉じる。はい・いいえの分岐は次の表にもあり、不明は調査として残します。

独自の判断図。該当する問いを全て確認します。他の確認を飛ばす経路ではありません。

判断	はい	いいえ	証拠／不明を解くもの	主担当
P13. 緊急対策で再現した不正アクセスを拒否できるか？	本文とバックエンドで確認し、監視する。	該当機能を停止するか、制限を強める。	管理下の拒否試験、ゲートウェイとアプリの証拠。	SRE＋AppSec
P14. 旧版、直接オリジン、提携先経路が迂回路になるか？	そこにも制限をかけるか経路を閉じる。	全経路の一覧に確認結果を残す。	DNSと経路、API版、オリジンへの接続制御。	SRE＋API管理者
P15. 既存セッション、出力ジョブ、リンクからまだ取得できるか？	関連アクセスを失効し、未配信出力を止める。	セッション、ジョブ、リンクの確認を残す。	セッション試験、キュー、署名付きURL・キャッシュ。	IAM＋アプリ管理者
P16. 制限で重要業務が停止するおそれがあるか？	合意した代替手段に切り替え、影響を伝える。	対策を適用し、戻しの責任者も決める。	依存関係、代替の試験、変更記録。	業務責任者＋対応責任者

具体的な操作手順

実際に取得を止める層を選びます。該当出力の停止、問題の操作の拒否、サーバー側認可の追加、狭い対策で止まらない場合のサービス停止です。実施時刻と版を記録します。
レート制限やボット対策は、根本の権限境界を直す間の負荷・自動化対策です。遅い不正取得を正当化するものではなく、IPの遮断だけでも十分ではありません。
オリジンと別のAPI版の迂回も閉じます。実行待ちジョブ、生成済みファイル、署名付きURL、キャッシュを確認します。対象キャッシュを削除し、キーや公開範囲を修正します。元のAPI修復だけで以前の出力が無効になるとは限りません。
認証情報やセッションが悪用された場合は、発行元とアプリ両方の失効手段を使い、対象リソース側で効いたことを確認します。自己完結型のアクセストークンは、リソースが失効や拒否を強制しなければ有効期限まで受理されることがあります。
自社管理のレコードだけで、関連する全入口から再試験します。最初の経路の403だけでなく、実際に本文が漏れないことを保存します。漏えいを黙って戻さないロールバック計画を用意します。

できたことの確認： 影響経路、既存アクセス、待機中の出力で同じ不正取得が失敗し、止めた業務の代替手段も確認できています。

4. 範囲：データ、レコード、人を分けて数える

判断P17〜P20：範囲：データ、レコード、人を分けて数える。はい・いいえの分岐は次の表にもあり、不明は調査として残します。

独自の判断図。該当する問いを全て確認します。他の確認を飛ばす経路ではありません。

判断	はい	いいえ	証拠／不明を解くもの	主担当
P17. 疑わしい応答で実際に出力したオブジェクトが分かるか？	不正と確認した要求内で重複を除く。	可能性のある範囲とし、正確な取得件数とは言わない。	オブジェクト監査、要求の分類、最小限の応答証拠。	SOC＋データ管理者
P18. 1要求が複数レコードや機微な項目を返し得るか？	一覧、バッチ、出力をレコード・項目単位に展開する。	本当に1要求1オブジェクトか確認する。	ページング、出力明細、スキーマ、返却件数。	API管理者＋データ管理者
P19. レコードを重複のない対象者に対応付けられるか？	安全に名寄せし、照合規則を残す。	レコード件数と未解決の人数を分けて報告する。	当時の登録情報、データ系譜、重複レコード。	データ管理者＋個人情報担当
P20. パスワード、秘密情報、高リスクの個人情報を含むか？	項目別の保護措置と通知判断を開始する。	実際に確認した項目分類を記録する。	当時のスキーマ、保存形式、限定サンプル。	個人情報担当＋IAM＋データ管理者

具体的な操作手順

到達できた可能性のある範囲、不正応答で観測した範囲、固有レコード、固有の対象者 の4つを別々に管理します。項目と変更・削除も記録します。それぞれ意味が違います。
不正と確認した要求から始めます。同じアカウントに正当な操作が混じることもあります。要求IDをオブジェクト出力やエクスポート明細に結び付け、取得試行とサーバーが実際に出力したものを分けます。
ページング、バッチとGraphQL応答、再試行、過去版、キャッシュヒットを扱います。応答バイト数はレコード数ではありません。200でも本文がエラーの場合があり、HTTP成功だけでは漏えいの証明になりません。
現在のDBだけでなく、露出当時のスキーマと権限を使います。レコードから人への対応付けは制限したデータ管理手順で行い、全顧客データを案件チケットに複製しません。
限界を説明します。サーバーの出力は、人が見たことやその後の悪用を証明しません。オブジェクトログがなければ不確実であり、ゼロ件ではありません。推定方法、前提、更新履歴を残します。

できたことの確認： 各数字に単位、期間、証拠、重複除去の規則、確度があります。生の行数から法的な期限を推定しません。

5. 広がり：読み取り以外の影響を確認する

判断P21〜P24：広がり：読み取り以外の影響を確認する。はい・いいえの分岐は次の表にもあり、不明は調査として残します。

独自の判断図。該当する問いを全て確認します。他の確認を飛ばす経路ではありません。

判断	はい	いいえ	証拠／不明を解くもの	主担当
P21. 同じ欠陥でデータを変更・削除できるか？	書き込み、権限、返金、アカウント変更を調べる。	読み取り限定という結論を試験済み操作に限定する。	変更監査、変更前後の値、DB履歴。	開発＋SOC
P22. 漏れた秘密情報で別システムに入れるか？	その認証情報を封じ込め、利用履歴を調べる。	確認した秘密情報と連携の種類を残す。	返却項目、鍵の台帳、接続先の監査。	IAM＋クラウド管理者
P23. アカウント、トークン、連携、出力が新規作成されたか？	不正な接続や未配信出力を記録し、除去する。	作成・変更ログと記録範囲を確認する。	アカウント監査、アプリ権限、ジョブ、Webhook変更。	IAM＋API管理者
P24. 顧客や提携先に詐欺や二次フィッシングが見えるか？	保護措置と確認済み経路での連絡を調整する。	発生なしと断定せず、悪用の兆候を監視する。	サポート報告、不正利用イベント、提携先の通知。	不正対策＋広報

具体的な操作手順

連絡先変更、復旧手続き、返金、ポイント移動、新しい権限、証拠削除などを読み取りと分けて調べます。読み取りの再現試験を、本物の顧客データの変更に拡大しません。
応答に秘密情報や認証情報があれば、クラウド鍵漏えいへ進みます。顧客の認証情報盗用は顧客アカウント乗っ取り、従業員のID侵害はアカウント侵害と並行します。
バックグラウンド出力、サービス用トークン、委任アプリ、Webhookを追います。最初の主体を止めても、生成済みファイルや新しい連携が消えるわけではありません。
サポートと不正対策に、制限した識別子で関連報告を集めてもらいます。顧客には確認できる連絡経路を示し、漏えいした情報を使う説得力のある偽連絡を社内にも警告します。

できたことの確認： データの完全性、別システムへの接続、不正利用にそれぞれ担当者と根拠付きの状況があり、単なる「漏えい」にまとめられていません。

6. 修復：認可の境界を試験で証明する

判断P25〜P28：修復：認可の境界を試験で証明する。はい・いいえの分岐は次の表にもあり、不明は調査として残します。

独自の判断図。該当する問いを全て確認します。他の確認を飛ばす経路ではありません。

判断	はい	いいえ	証拠／不明を解くもの	主担当
P25. 影響を受けた全操作のサーバー側で原因を直したか？	コードとポリシーを査読し、拒否試験を行う。	該当機能の制限を続ける。	修正レビュー、経路一覧、差分、配置ID。	開発＋AppSec
P26. 独立した試験で別利用者・別テナントの取得を拒否するか？	再開判定の証拠として結果を残す。	リリースを止め、失敗した境界を調べる。	合成アカウント、役割・テナント表、実測結果。	独立した試験者＋AppSec
P27. 項目、機能、バッチ、キャッシュ、ジョブも試験したか？	同じ許可・拒否の組合せを全経路に適用する。	完了とする前に不足するケースを追加する。	応答スキーマ、リゾルバー・ジョブ試験、キャッシュ。	QA＋API管理者
P28. 同じ動きを証拠付きで検知できるか？	合成アラートを発火し、案件に必要な証拠を確認する。	不足ログを追加し、担当者に通知する。	テスト要求、ログ結合、通知到達、対応手順。	SOC＋SRE

具体的な操作手順

データの選択・返却箇所で認可を直します。所有権、テナント、委任を信頼できるサーバーの情報から導きます。利用者が送るテナントIDや、推測しにくいIDだけを認可の代わりにしません。
役割と操作ごとに返却項目を明示します。個別取得、一覧、検索、出力の作成と取得、変更、項目の書き込み、バッチ、GraphQLのリゾルバーを対象にします。
合成データの表で試験します。自分のレコードは許可、別顧客と別テナントは拒否、承認済み委任は許可、一般利用者の一括出力は拒否、承認済み担当者は許可、認証必須の操作で匿名と期限切れ・失効済みアクセスは拒否。本文、HTTP状態、データ変更、副作用も見ます。
旧版、直接オリジン、データが入ったキャッシュでも繰り返します。全員拒否で直ったように見えないよう、正当な利用の成功も確認します。まず検証環境を使い、本番確認は自社の合成レコードに限定します。
修正者以外が査読し、回帰試験を追加します。テスト用しきい値を明示した合成操作で検知を試し、本物の一括ダウンロードは発生させません。

できたことの確認： 配置済みビルドに対する再現可能な許可・拒否の結果があり、SOCが対応するイベントを探せます。

7. 連絡：証拠が支える範囲を伝える

判断P29〜P32：連絡：証拠が支える範囲を伝える。はい・いいえの分岐は次の表にもあり、不明は調査として残します。

独自の判断図。該当する問いを全て確認します。他の確認を飛ばす経路ではありません。

判断	はい	いいえ	証拠／不明を解くもの	主担当
P29. 報告、契約、本人通知の義務が関わるか？	法務が管轄、発動条件、期限を今から判断する。	判断を記録し、事実が変われば再評価する。	データ分類、契約、管轄、認知した時刻。	法務／個人情報担当
P30. 確定事実、推定、不明を分けているか？	全ての状況報告でその区分を使う。	公表前に事実台帳を突き合わせる。	版管理した範囲台帳、証拠参照、承認記録。	対応責任者＋個人情報担当
P31. 相手が直ちに行うべき保護措置があるか？	確認済みの経路で具体的な行動を伝える。	必要のない対応を作らず、分かった影響を説明する。	認証情報・データの影響、不正利用評価、正式窓口。	広報＋IAM
P32. 委託先が証拠を持つか、同じサービスを共有するか？	ログ保全、範囲、封じ込めの証明を求める。	委託先依存がない理由を記録する。	ホスティング・API契約、支援案件、データフロー。	委託先担当＋個人情報担当

具体的な操作手順

個人情報・法務担当は最終件数の確定前、初動で参加します。報告と通知は事実、管轄、契約に依存し、この手順に共通の期限はありません。関わる期限と判断者を非公開の台帳で管理します。
発見時刻、露出期間、操作と項目、確定・潜在範囲、封じ込め結果、未解決を版管理します。一般向け報告に個人レコードや悪用の詳細を載せません。
組織が行った対策と相手が取る行動を説明します。データの漏えいだけで、パスワード変更が欠陥を直すかのように説明しません。パスワード自体が露出した場合は別の保護判断が必要です。
既存の連絡先から委託先を確認します。「修正済み」「アクセスの証拠なし」だけでなく根拠を求めます。各組織の責任を残したまま通知を調整します。

できたことの確認： 全ての説明が同じ範囲の事実を使い、確認者と次の更新時刻があり、不明点が見えるままです。

8. 復旧：段階的に再開し、証拠で完了する

判断P33〜P36：復旧：段階的に再開し、証拠で完了する。はい・いいえの分岐は次の表にもあり、不明は調査として残します。

独自の判断図。該当する問いを全て確認します。他の確認を飛ばす経路ではありません。

判断	はい	いいえ	証拠／不明を解くもの	主担当
P33. 封じ込め、修復、範囲の判定をレビューしたか？	戻しの担当者を付け、限定再開を承認する。	該当機能を制限し、残る作業を割り当てる。	判定表、残余リスク、業務側の承認。	対応責任者＋業務責任者
P34. 限定公開で安全性とサービスの両方が合格したか？	該当操作を観測しながら徐々に広げる。	拡大を止め、安全な制限に戻す。	拒否・許可試験、エラー率、遅延、サポート。	SRE＋QA
P35. 既存セッション、ジョブ、旧経路、キャッシュも新方針に従うか？	アクセス経路ごとの再開後の検証を記録する。	失敗した経路を封じ込め、調査を再開する。	リソース試験、キャッシュ・ジョブ確認、版一覧。	API管理者＋AppSec
P36. 未解決、監視、改善作業に担当者がいるか？	見直し日と証拠に基づく完了条件を記録する。	案件を閉じる前に責任者を割り当てる。	監視期間、リスク受容、チケット担当、証拠保持。	対応責任者

具体的な操作手順

開発が修復、独立試験者が認可、SOCが可視性と封じ込め、業務側がサービス計画と残余リスクを確認します。少人数なら役割を明示して判定します。
小さな許可済み集団や限定した操作から再開します。合成データの許可・拒否試験を繰り返し、不正取得の動きと正常性を監視し、安全な制限に戻す条件を決めます。
既存セッション、ジョブ、キャッシュ、直接オリジン、旧版を再確認します。新しいログインを待つだけでは、発行済みアクセスを検証できません。
リスクに応じた観測期間と見直し頻度を合意します。何時間静かなら根絶とする、という共通の基準はありません。夜間の対応者と再封じ込め条件を決めます。
事実台帳、通知、証拠保持、残るリスク判断を記録して対応案件を閉じます。API台帳、認可試験、データ最小化、ログ整備は別の追跡可能な改善案件として残します。

できたことの確認： 再開が安全性と業務の両面から記録された判断であり、再発時に止める責任者がいます。

ハンティング：範囲を限定した出発点

次のクエリは説明用で、実ワークスペースでは実行していません。Defender XDRの高度なハンティングではなく、Azure Monitor Logsまたはマッピング済みのSplunkログを使います。全ての置換箇所、案件期間、権限、サンプリングを確認し、運用前に合成要求で検証してください。Microsoft：APIMリソースログ。

1. KQL：1つのAPIの要求時系列

ApiManagementGatewayLogsの文書化された列を使います。リソース固有形式の診断ログを事前に有効にする必要があります。APIMのUserIdはAPIMの利用者IDで、空欄だったりアプリの利用者と異なったりします。ApimSubscriptionIdはAPIサブスクリプション、表のTenantIdはLog AnalyticsワークスペースのIDであり、影響を受けた顧客テナントではありません。検証済みのアプリ主体と置き換えません。出力はクエリ文字列と本文を省きますが、識別子も機微になり得ます。直近250件だけを表示します。

// Illustrative; not executed against a live workspace. Azure Monitor Logs, not Defender XDR.
// Resource-specific ApiManagementGatewayLogs must already be enabled; replace both identifiers.
// UserId is an APIM user identifier, not proof of the application's authenticated principal.
let Start = ago(24h);
let End = now();
let TargetResource = "REPLACE_WITH_APIM_RESOURCE_ID";
let TargetApi = "REPLACE_WITH_API_ID";
ApiManagementGatewayLogs
| where TimeGenerated between (Start .. End)
| where _ResourceId =~ TargetResource and ApiId == TargetApi
| extend Path = tostring(parse_url(Url).Path)
| project TimeGenerated, CorrelationId, OperationId, Method, Path,
          ResponseCode, ResponseSize, CallerIpAddress, UserId, ApimSubscriptionId, Cache, Region
| order by TimeGenerated desc
| take 250

2. KQL：多数の個別レコードのパスを読む主体

先頭と末尾を限定した/v1/customers/{id}を、自社の単一オブジェクト用の経路に変更します。本文も閲覧権限も確認しません。dcountは概算で、15分に20個という値は調査候補用の例であり、共通の正常基準ではありません。正規の連携、サポート、NATや共用契約、再試行も確認します。送信元別の集計では分散した操作が分かれるため、主体単位や長い期間でも比較します。一覧、/me、GraphQL、符号化されたID、出力ジョブはアプリを理解した別の処理が必要です。候補は100組までです。

// Illustrative; not executed against a live workspace. Azure Monitor Logs.
// Adapt this SINGLE-OBJECT route to your API. Lists, GraphQL and exports need application audit.
// dcount is approximate; thresholds identify review candidates, not proven data theft.
let Start = ago(24h);
let End = now();
let TargetResource = "REPLACE_WITH_APIM_RESOURCE_ID";
let TargetApi = "REPLACE_WITH_API_ID";
let ReviewThreshold = 20;
ApiManagementGatewayLogs
| where TimeGenerated between (Start .. End)
| where _ResourceId =~ TargetResource and ApiId == TargetApi
| where Method == "GET" and ResponseCode between (200 .. 299)
| extend ObjectId = extract(@"^/v1/customers/([^/]+)$", 1, tostring(parse_url(Url).Path))
| where isnotempty(ObjectId)
| summarize Requests = count(), ApproxObjects = dcount(ObjectId),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by bin(TimeGenerated, 15m), UserId, ApimSubscriptionId, CallerIpAddress
| where ApproxObjects >= ReviewThreshold
| order by ApproxObjects desc
| take 100

3. KQL：不正と確認した要求に含まれる観測済みオブジェクト

ApiObjectAccess_CLは提案するカスタム表であり、AzureやDefenderの組み込み表ではありません。 先に収集処理と次の契約を実装します。実際のサーバー応答に含めたオブジェクトごとに1行を出し、観測可能なバッチや出力の各項目も含めます。親の一覧IDだけでは足りません。大きい出力は、過剰なインライン記録の代わりに、制限したジョブとオブジェクトの明細を使って同等の結合をします。後からクエリを変えても、過去の不足ログは復元できません。

カスタム列	型	必要な意味
TimeGenerated	datetime	出力イベントのUTC時刻。
ApiId	string	アプリ側の安定したAPI識別子。
CorrelationId	string	信頼できるエンドツーエンドの要求ID。
ObjectTenantId	string	データ所有者の安定した名前空間。単一テナントでも定義する。
ObjectId	string	そのテナント内の安定した仮名識別子。トークンや個人情報の実値ではない。
ObjectEmitted	bool	アプリが出力を記録した場合はtrue。試行だけならfalse。
ResponseCode	int	このイベントに対応する最終HTTP状態。

権限方針と調査により、別途不正と確認した要求IDから始めます。その分類台帳は非公開で保存します。クエリは、指定要求と期間内のテナント・オブジェクトの組を正確に重複除去します。事件全体の推計や人数ではありません。ゼロは条件に合う記録がないことを示し、ログ不足、未置換、取り込み遅延、期間の誤りでも起きます。

// Illustrative; not executed against a live workspace. CUSTOM application table, not a built-in schema.
// Requires one event per object emitted; the contract is defined in the playbook.
// Include only request IDs independently confirmed unauthorized; do not classify by account alone.
let Start = ago(24h);
let End = now();
let TargetApi = "REPLACE_WITH_API_ID";
let CaseRequestIds = dynamic(["REPLACE_WITH_CONFIRMED_UNAUTHORIZED_REQUEST_ID"]);
ApiObjectAccess_CL
| where TimeGenerated between (Start .. End)
| where ApiId == TargetApi and CorrelationId in (CaseRequestIds)
| where ObjectEmitted == true and ResponseCode between (200 .. 299)
| where isnotempty(ObjectTenantId) and isnotempty(ObjectId)
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by ObjectTenantId, ObjectId
| summarize ExactObservedObjects = count(),
            FirstSeen = min(FirstSeen), LastSeen = max(LastSeen)

4. Splunk：個別レコードの取得先の広がり

共通のsourcetypeがあるとは仮定せず、次をマッピングします。api_idはAPI識別子、http_methodはメソッド、statusはHTTP状態、uri_pathはクエリを除くパス、userは得られる場合の検証済みアプリ主体、srcは信頼できる送信元です。任意の転送ヘッダーを信用しません。未対応の主体と送信元は[unmapped]に残るため、そのまとまりで帰属を判断できません。正当な委任・一括処理も調べます。Splunk statsリファレンス。

index="REPLACE_WITH_API_LOG_INDEX" sourcetype="REPLACE_WITH_API_SOURCETYPE" earliest=-24h latest=now
api_id="REPLACE_WITH_API_ID" http_method=GET status>=200 status<300
| rex field=uri_path "^/v1/customers/(?<object_id>[^/?]+)$"
| search object_id=*
| eval user=coalesce(user,"[unmapped]"), src=coalesce(src,"[unmapped]"), event_time=_time
| bin _time span=15m
| stats count AS requests dc(object_id) AS distinct_objects min(event_time) AS first_seen max(event_time) AS last_seen BY _time user src api_id
| where distinct_objects>=20
| sort 100 - distinct_objects

クエリをダウンロード: 1. KQL · 2. KQL · 3. KQL · 4. SPL.

封じ込め後の確認： 対策時刻から時系列を再実行し、以前に再現した動きについてアプリとオブジェクトの証拠を調べます。パスの抽出失敗、空の結果、要求減少は修復の証明ではありません。同じオブジェクトが複数区間に出るため、各区間の概算を足し合わせません。

コピーして使えるテンプレート

一般の連絡に顧客データ、トークン値、悪用できる要求のサンプルを含めません。角括弧を確認済みの事実に置き換え、不明は残します。

社内向けの状況報告

案件：[ID]｜更新：[UTC時刻]｜責任者：[氏名]
影響API・操作・版：[詳細]
発見時刻：[時刻]。露出の可能性がある期間：[開始・終了／不明]
確認した仕組み：[根拠付きの事実]。未確認：[問い]
封じ込め：[対策、時刻、結果、確認中の代替経路]
範囲：[観測応答／固有レコード／固有人数。それぞれ確度付き]
見えない部分：[ログ、サンプリング、欠損期間]
業務影響と代替：[詳細]
担当と次の作業：[氏名・作業]
次の更新：[UTC時刻]

API・ホスティング事業者への依頼

件名：APIの証拠保全と封じ込めの確認依頼 – [案件ID]
[UTC期間]の既存ゲートウェイ、アプリ、認証、オブジェクト参照、配置、
出力ジョブ、キャッシュの記録を、保持・サンプリング設定と共に保全してください。
証拠の共有には[承認済みの安全な経路]を使ってください。
影響を受ける操作、版、オリジン経路、保存先を特定してください。
失敗した認可制御と、まだ確認していない点を説明してください。
対策時刻と、代替経路、既存セッション、出力待ち、キャッシュに対する
管理下の試験結果を提示してください。
到達可能だったデータと、観測した返却レコードを分け、項目分類、
重複除去の方法、ログの欠損を報告してください。
担当窓口、次の更新、独立確認を含む修復計画を確認してください。
生のトークンや顧客データを通常のメールで送らないでください。

個人情報・法務担当が確認する本人通知案

[日付]に、[サービス]で[証拠で確認した内容]を確認しました。
対象期間は[確認した期間／調査中]です。
関わる情報は[確認済みの分類]です。[確定事項]を確認しており、
[範囲や不明点]については引き続き調査しています。
当社は[効果を確認した具体的な封じ込め・修復]を実施しました。
お願いする対応：[本件に即した行動／対応不要ならその説明]。
お問い合わせは[既知の正式窓口]をご利用ください。本件に言及し、
パスワード、支払い、確認コードを求める突然の連絡にご注意ください。
次の更新は[時刻・日付]までに[正式な経路]でお知らせします。

再開と完了の記録

案件・ビルド・対策の版：[ID]
開発側の確認：[担当者、証拠、時刻]
独立した許可・拒否試験：[担当者、試験表、結果、時刻]
確認範囲：[版、オリジン、項目、機能、ジョブ、セッション、キャッシュ]
範囲・通知状況と未解決の限界：[事実、担当者]
限定再開の対象と正常性確認：[計画・結果]
安全な制限に戻す手順：[条件、措置、担当者]
監視と時間外対応：[期間、アラート、連絡先]
残余リスクの判断：[責任者、理由、見直し日]
再開承認：[安全性・業務の責任者、時刻]
証拠保持と改善案件：[保管先、担当者、期限]

例：正しいアカウントと、忘れられた旧API

実在企業の事件ではない架空の訓練例です。以下の件数も全て仮定です。 顧客ポータルの現行APIは所有権を確認しますが、古いモバイル用の操作は確認しません。正規の試用アカウントから他人のプロフィールを取得できます。08:10 UTC、研究者から秘匿化したサンプルが届きます。

段階	チームが確認したこと
初動	AppSecが自社の2つのテストアカウントで再現し、責任者が旧操作を制限して業務担当に伝えます。
証拠	問題の配置は5日前ですが、使えるアプリログは2日分だけです。それ以前の3日間は不明です。
封じ込め	直接オリジンの試験が最初のエッジ対策を迂回します。バックエンドも制限し、露出した生成済み出力を除去します。両経路の拒否試験が通ります。
範囲	別途不正と確認した12要求で、7件の固有の顧客レコードを出力しています。データ管理者が6人に対応付けます。1人に2レコードがあり、再試行は重複計上しません。
限界	他のレコードにも到達できた可能性があります。古い期間に証拠がないため、7件を事件全体の総数とはしません。書き込みが観測されないという説明も、確認した操作と期間に限定します。
修復	旧版と現行版にサーバー側の所有権と項目の確認を追加します。別の試験者が委任、出力、キャッシュ、拒否ケースを調べ、合成アラートも確認します。
復旧	個人情報担当が欠損を含めて通知を判断します。限定再開で安全性と正常性を確認し、旧版の廃止責任者と日付を決めます。

得られるのは、説明可能な範囲と、試験済みの権限境界です。全員のパスワードを変えるだけでは、所有権確認の欠落は直りません。

当サイトの分析	この手順との関係	残すべき不確実性
ローソンID：アプリのデータ返却の仕組み	オブジェクトと項目、一括読み取りの調査、レコード単位の範囲確認。	分析は複数の可能性を区別しており、特定の認可欠陥が確定したという意味ではありません。
ソースネクスト：会員情報取得API	API操作、露出期間、認証情報の項目、事件の件数。	APIの悪用だけで、アクセスの取得方法や失敗した認可は分かりません。
佐川急便：荷物の追跡照会	公開照会の範囲、バックエンドへの到達、依存するAPIサービス。	追跡サービスの侵害は、オブジェクト認可の欠陥や特定のAPI攻撃の証明ではありません。

出典、分析上の対応付け、更新履歴

独自の再利用可能な手順であり、ベンダー認定の手順書でも、リンクした事件を当サイトが直接調査した報告でもありません。OWASPのリスク説明を権限境界の整理に使い、判断表、構成、例、図は独自に作りました。一次技術資料は2026年10月16日に確認しています。

OWASP API1：オブジェクトの認可とAPI3：項目の認可。
OWASP API5：機能の認可とAPI6：機微な業務フロー。
OWASP API9：API台帳の管理：版と配置の確認。
OWASP Logging Cheat Sheet：証拠の計画と機微情報の記録回避。
Microsoft：ApiManagementGatewayLogsのスキーマとAPIM監視の設定。
Splunk：stats：マッピング後の集計。
MITRE ATT&CK T1078：Valid Accountsはアカウント悪用を確認した場合、T1213：Data from Information Repositoriesは該当する保存先からの収集を説明する場合に対応付けられます。分析上の整理であり、欠陥、攻撃者、持ち出しの証明ではありません。OWASPの分類とATT&CKの技法は目的が違います。

2026年10月16日： 英日初版。36項目の判断台帳、独自の図、4つのクエリ、関連分析へのリンクを追加しました。クエリの列は資料で確認しましたが、実際のAzure／Splunkテナント、本番API、顧客データを使う実行試験はしていません。個別APIの試験、ログ収集の実装、案件ごとの法務確認は利用組織で行ってください。

APIデータ漏えい：ログインは正しい。それでも、そのデータを読んではいけない。

30秒でわかる要点

ログインに成功しても、漏えいは起きる

ここから始める：最初の1時間

準備、担当者、判断の規則

この手順の言葉

0. 初動：流出を止め、対応責任者を決める

具体的な操作手順

1. 証拠：露出していた期間を組み立てる

具体的な操作手順

2. 仕組み：どの権限境界が破られたか

具体的な操作手順

3. 封じ込め：データへの全経路を閉じる

具体的な操作手順

4. 範囲：データ、レコード、人を分けて数える

具体的な操作手順

5. 広がり：読み取り以外の影響を確認する

具体的な操作手順

6. 修復：認可の境界を試験で証明する

具体的な操作手順

7. 連絡：証拠が支える範囲を伝える

具体的な操作手順

8. 復旧：段階的に再開し、証拠で完了する

具体的な操作手順

ハンティング：範囲を限定した出発点

1. KQL：1つのAPIの要求時系列

2. KQL：多数の個別レコードのパスを読む主体

3. KQL：不正と確認した要求に含まれる観測済みオブジェクト

4. Splunk：個別レコードの取得先の広がり

コピーして使えるテンプレート

社内向けの状況報告

API・ホスティング事業者への依頼

個人情報・法務担当が確認する本人通知案

再開と完了の記録

例：正しいアカウントと、忘れられた旧API

関連する事件：原因を決め付けずに使う

出典、分析上の対応付け、更新履歴