請求書サービスの信頼境界

脅威モデリング、SAST、DAST、IAST、SCA、ファジング、ペネトレーションテストは、同じ『セキュリティ検査』として一括りにすると使いどころを誤ります。設計・ソースコード・依存部品・実行中のアプリ・攻撃経路のどこを見るかが異なります。この記事では請求書Webサービスの開発を一件の事例として、検出範囲、証拠の限界、修正後の再検証まで追います。登場するbilling.example、IPアドレス、ログ、ライブラリ名、診断結果はすべて説明用の架空例です。

読み順は、①サービス構成と信頼境界、②設計段階の脅威、③六つの検査手法、④検出結果の突合、⑤修正と再検証、⑥記述演習です。試験の構成図では『何を守るか』『攻撃者は何を操作できるか』『検査対象にその経路が含まれたか』を先に書き出してください。

1. 共通事例：請求書Webサービスの構成と守る情報

billing.exampleは企業向け請求書サービスです。テナント41の利用者Aとテナント42の利用者Bは、各自の請求書をPDFで閲覧し、管理担当者はCSVを取り込みます。APIの請求書IDは整数で、テナントIDもDB内では整数です。推測しにくいIDへ変更するだけで認可の欠落は解消しません。

資産：請求書PDF、顧客名・金額・振込先、利用者のセッション、CSV取込結果、監査ログ。請求書本文と振込先は機密性・完全性の両方を守る。
主体：未ログインの外部利用者、テナント41の利用者A、テナント42の利用者B、取込担当者、運用管理者。認証済みであっても別テナントの請求書を見る権限はない。
処理：ブラウザ→公開API→請求書DB→非公開オブジェクト保管先。CSVはAPIから取込キューを経てワーカーが解析する。
外部部品：CSV解析ライブラリとPDF生成ライブラリ。アプリの自作コードとは別に、実際のビルドに入った版と既知の脆弱性を管理する。

次の構成図は、利用者から届く値をどこで検証し、どの内部資産へ渡すかを見るためのものです。列は信頼する範囲の違いを示し、矢印は要求や処理の方向を示します。

請求書サービスの信頼境界

1. 請求書参照・CSV投稿
2. 請求書と所属を照合
3. 許可後にPDFを取得
4. CSV解析を依頼

矢印は要求や内部処理の向き。公開APIを通る前後と、APIからDB・保存先・取込ワーカーへの境界を調べる架空構成。

図の最初の境界では、ブラウザから送られた請求書IDやCSVを信用しません。APIはサーバ側のセッションからテナント41などの所属を決め、DBでそのテナントの請求書だけを取得します。内部の保管先が非公開でも、APIが別テナントのPDFを代理取得すれば情報は漏れます。取込ワーカーもファイルと付随するメタデータを未信頼入力として扱います。

text

正規の閲覧: A(tenant=41) → GET /api/invoices/8101/pdf
DB: invoice=8101 tenant_id=41 object_key=inv/41/8101.pdf
結果: 200、Aに許可されたPDF

禁止すべき閲覧: A(tenant=41) → GET /api/invoices/9102/pdf
DB: invoice=9102 tenant_id=42 object_key=inv/42/9102.pdf
期待結果: 404、PDFの本文・保存先は返さない

ここでの8101と9102はDBの整数IDです。Aが9102を指定できること自体は避けられない前提で、所有テナントをサーバ側で毎回照合することが必要です。404は他テナントの請求書が存在するかどうかも知らせないための設計例で、運用上の応答方針は要件に合わせて決めます。

2. 脅威モデリング：実装前に何を壊され得るか考える

脅威モデリングは検査ツール名ではなく、対象を分解し、データフローと信頼境界ごとに脅威・対策・検証方法を決める作業です。設計時に行い、CSV取込や外部保存先の追加など構成が変われば更新します。会議で『危険そう』と挙げただけでは完了せず、要求と検証項目へ落とします。

対象と資産を決める。今回は請求書閲覧・CSV取込・PDF保管を対象とし、顧客情報、振込先、可用性、監査記録を守る。
データの入口と信頼境界を描く。ブラウザ→API、API→DB、API→保存先、API→ワーカーで、誰がどの値を確定するか記録する。
攻撃者の能力を置く。未ログイン者、テナント41の正規利用者、取込権限を持つ担当者では操作できる入力と到達先が違う。
脅威を具体的な誤用シナリオにする。Aが請求書IDを9102へ変え、APIがテナント条件なしにDBを読み、BのPDFを返す。
脅威の優先順位を決める。入口への到達可能性、成立条件、業務影響、未確認事項を比べ、判断の前提を残す。
対策、責任者、検証をひも付ける。サーバ側テナント照合、非公開保存先、二テナントの回帰テスト、監査ログを受入条件にする。

2-1. STRIDEは脅威を見落とさないための問い

STRIDEは脅威を六つの観点から考える補助法です。六つ全部が必ず一件の機能で発生するという意味ではありません。各観点を、構成図の主体・処理・保存データへ結び付けます。

Spoofing（なりすまし）：盗んだセッションでAになりすます。対策は認証・セッション管理。請求書IDのテナント照合とは別の層。
Tampering（改ざん）：取込CSVの振込先を変更し、その値が承認なしに確定する。入力の来歴、承認、更新権限を確認する。
Repudiation（否認）：請求書の閲覧・変更を後から追えない。要求ID、認証済み主体、結果を改ざんされにくい監査ログへ残す。
Information Disclosure（情報漏えい）：Aが9102を指定しBのPDFを受け取る。テナント越境の認可と保存先公開設定が焦点。
Denial of Service（サービス妨害）：巨大・不正なCSVで解析ワーカーのCPUやメモリを占有する。サイズ、実行時間、キュー容量を制御する。
Elevation of Privilege（権限昇格）：取込担当者が管理者専用の承認APIを実行する。役割ごとのサーバ側認可を確認する。

2-2. 脅威を優先順位に変える

STRIDEで列挙した脅威は、攻撃者が入口へ到達できるか、成立に必要な条件は何か、成立時にどの資産へ影響するかを比べて対策順を決めます。ここでは発生可能性と業務影響を高・中・低で仮評価します。点数だけで機械的に決めず、判断の前提と未確認事項を残します。これは設計時の仮説であり、後の検査結果で更新します。

T-01 請求書の越境閲覧：現行設計案はIDだけで請求書を検索し、Aは正規アカウントでIDを変更できる。発生可能性=高、影響=高と仮評価する。顧客情報と振込先が漏れるため、TM-01の認可要件と二テナントの受入テストを最優先にする。IDを知る方法と全参照経路は検査で確かめる。
T-02 CSV取込の資源枯渇：取込担当者の権限と不正CSVが必要で、ワーカーと共有キューを使い切る恐れがある。発生可能性=中、影響=中。TM-03のサイズ・時間・再試行制限を設け、ファジングとキュー監視で他テナントへの影響を確認する。権限が広がれば再評価する。
T-03 監査不能：閲覧結果と要求IDが結び付かなければ、越境閲覧の発見後に範囲を特定しにくい。発生可能性はログ実装を確認するまで未判定、影響=高。TM-04の記録項目と保存期間を決め、正常・拒否の両方で記録を検証する。未判定を低リスクと読み替えない。

T-01に対策を入れた後も、一覧APIや公開されたPDF保存先などに同じ漏えい経路が残ればリスクは下がりません。残る経路、暫定策、担当者、再確認日を記録してから優先度を更新します。業務上リスクを受容する場合は、何が起こり得るかを明示して責任者が判断します。

2-3. 設計上の決定を検証可能な要件にする

TM-01：全ての請求書参照で、認証済みセッションのtenant_idとDBのtenant_idを照合する。URL・ヘッダ・JSONのtenant_idを認可根拠にしない。
TM-02：PDF保存先は公開しない。APIが照合を終えた請求書だけ取得し、一覧・詳細・一括出力でも同じ規則を適用する。
TM-03：CSVの受入サイズ、形式、処理時間を制限する。異常入力は対象ジョブだけ失敗させ、他テナントの取込を止めない。
TM-04：拒否や失敗を要求IDで追えるようにする。監査ログへ請求書本文・セッショントークンを記録しない。

TM-01の確認は『Aの8101は成功』『Aの9102は拒否』『Bの9102は成功』『未ログインは拒否』という少なくとも四つの条件が必要です。正常系一件だけのテストでは、横方向の権限越境を確かめられません。設計にない経路が後から増えたら、モデルとテストを更新します。

脅威モデルには前提も残します。例えば『PDFは非公開保管先にだけ置く』『テナントIDはセッションから取得する』が前提です。新しいCDNや一括ダウンロード機能を足して前提が崩れれば、以前の検証済み印を流用できません。脅威を受容する判断をした場合も、業務影響、代替策、承認者、見直す時期を記録します。

3. どの工程で何を調べるか：七つの手法の役割

脅威モデリングは要求・設計段階、SASTとSCAは実装・ビルド段階、DAST・IAST・ファジングは動く対象を用意した結合・検証段階、ペネトレーションテストは許可された範囲で攻撃経路を確かめる段階が主な使いどころです。各手法は繰り返してよく、リリース後の変更や新しい脆弱性情報でも再実行します。

検査対象が違う四つの自動化手法

代表的な入力と見える範囲の比較。製品の機能や設定で対象は変わる。脅威モデリング・ファジング・ペネトレーションテストは本文で扱う。

図の『見える例』は、その手法だけで脆弱性を確定できるという意味ではありません。SASTの警告には誤検知があり、DAST・IASTは到達した画面や処理に依存します。SCAは部品の既知問題を示しても、製品内でその経路が利用可能かを自動的に証明しません。

3-1. 実施工程と成果物を一行ずつ対応させる

要求・設計：脅威モデリングで資産、信頼境界、悪用シナリオ、対策、検証条件を作る。成果物は構成図、TM-01などの要件、担当者。
実装・コードレビュー：SASTで自作コードの危険なデータフローや設定を候補として探す。成果物はソース位置、規則、入力経路、調査結果。
依存部品の採用・ビルド：SCAで直接・推移的依存部品の版と既知問題を照合する。成果物は実際のビルドとの対応、影響判断、更新方針。
結合・検証：DASTで稼働中のHTTP応答、IASTで実行した内部処理、ファジングで異常入力への反応を調べる。成果物は再現条件と到達範囲。
リリース前と大きな変更時：ペネトレーションテストで許可された範囲の攻撃経路を人が組み合わせて確かめる。成果物は証跡、影響、修正提案と残る未検証範囲。
修正後・運用中：元の再現条件と隣接経路を再検証し、回帰テストを継続する。SCAは新しいアドバイザリが出た時にも再評価する。

4. SAST：ソースを読むが、業務上の権限までは推測しにくい

SAST（Static Application Security Testing）はソースコードや中間表現などを実行前に調べる静的検査です。規則と解析能力が合えば、未実行のコードも調べられます。警告は『到達し得る危険な処理』の候補であり、実際の攻撃成功や利用者影響は別に確認します。

CSV取込のプレビュー機能では、利用者から受け取ったファイル名を保管先のパスへ連結していました。次は概念的な修正前コードで、実在する製品の実装ではありません。

text

// 修正前の概念例。request.body.fileName は未信頼入力。
const path = join(uploadRoot, request.body.fileName);
const preview = readFile(path);

SAST-12: source=request.body.fileName
         sink=readFile(path)
         rule=path-traversal-candidate
         location=import-preview:42

SAST-12はファイル名からreadFileまでの経路を示します。joinを呼んだだけでは親ディレクトリへの移動を防げません。ただし、上流で必ずサーバ生成の値に置き換わる実装なら誤検知もあり得ます。レビューでは入力の生成元、正規化と境界検査、実際の呼出し条件、ファイルを読む権限を確認します。

4-1. source、伝播、sinkを報告書で読む

sourceは外部から制御できる値の入口、sinkはその値が危険な操作に届く位置です。この例のsourceはfileName、sinkはreadFileです。途中の変換が値の安全性を本当に保証するかを追います。文字列連結を一箇所止めても、別のプレビューAPIが同じ保存先を読めば経路は残ります。

静的解析には単純なパターン検査から、関数間のデータフローを追うものまであります。対応していない言語・フレームワーク、動的な呼出し、ライブラリ内部、実行時の権限情報は見落とし得ます。逆に、テストでまだ実行していない分岐を早く指摘できるのが利点です。

修正位置：利用者のfileNameをパスに使わず、サーバが採番した取込IDと所属テナントでDBの保存キーを取得する。保存キーの参照権限もAPIで確認する。
元のSAST結果の再評価：同じ規則・対象ブランチで警告が消えるか見る。警告が消えたことと実際に越境できないことは別なので、パストラバーサルを含む異常入力でも検証する。
見落とし：Aの請求書IDをBのIDへ変えたときに閲覧できる設計上の認可欠落は、コードの危険な関数がなくても成立する。一般的なSAST規則だけに検出を任せない。

SASTの対象外に生成コード、別リポジトリのサービス、実際の本番設定があれば結果はその範囲に限られます。ツールの対応言語、解析したコミット、除外パス、誤検知の判断理由を記録します。『警告ゼロ』は安全性の証明ではありません。

SAST-12を誤検知として閉じるなら、『入力はサーバ生成IDに置換される』という具体的な経路とテストを残します。『今回は再現しなかった』だけでは、SASTが示した別条件の経路を否定できません。誤検知の扱いと、実際に直すべき欠陥の優先度を分けて管理します。

5. DAST：動くWebを外から試し、到達範囲を明示する

DAST（Dynamic Application Security Testing）は稼働中のアプリへHTTPなどで要求を送り、応答から弱点を探す動的検査です。ソースがなくても動作を観測できますが、ログイン情報、対象URL、権限、API定義、実行可能な状態がなければ、その経路は調べられません。破壊的な入力や大量要求は検証環境・対象範囲・実施時間を決めてから行います。

受動的な観測は通常の通信からヘッダやCookie設定を調べます。能動的な検査はパラメータを変えたり特殊な入力を送ったりするため、データ更新や大量要求の影響を考えます。APIが画面操作だけでは呼ばれない場合は、API定義や記録済み通信を対象に加えます。管理画面や別テナントの権限も、許可された試験アカウントで範囲を明示します。

5-1. 未ログインのスキャンが通過しない画面

text

14:00 DAST unauth GET /api/invoices/8101/pdf -> 401
14:02 DAST unauth GET /api/invoices/9102/pdf -> 401
scan_summary: requests=2, authenticated_routes=0
reported_high_findings=0

この結果から分かるのは、未ログインの二つの要求が401になったことだけです。認証済みのAがBの9102を見られるかは試していません。検出件数が0でも、認証済み経路の認可が正常だとは言えません。スキャナへA・Bのテスト用セッションとAPI定義を渡し、ログイン維持と実際の到達状況を確認します。

ログインに成功した設定でも、走査途中でセッションが切れれば後続の要求は401だけになります。スキャン開始時の認証成功、途中の再認証、最終的に触れたURL・メソッド・応答コードを確認してください。『認証あり』という設定名ではカバレッジを証明できません。

5-2. 役割とテナントを変えた検証

次はA・Bの試験用請求書IDを明示し、役割を入れ替える認可テストをDASTの実行に組み込んだ架空ログです。汎用スキャナへ二つのログイン情報を渡すだけで、このテナント間の関係を自動的に理解するとは限りません。

text

14:10 A tenant=41 GET /api/invoices/8101/pdf -> 200
14:11 A tenant=41 GET /api/invoices/9102/pdf -> 200
  req_id=req-1411 [異常]
14:12 B tenant=42 GET /api/invoices/9102/pdf -> 200
  req_id=req-1412
14:13 unauth      GET /api/invoices/9102/pdf -> 401

14:11 response_sha256:
  9715838223e367c983dcc75346692f97ae358519d790e875957071ca3e710ffb
14:12 response_sha256:
  9715838223e367c983dcc75346692f97ae358519d790e875957071ca3e710ffb

14:11にAが9102へ到達し、B自身への14:12応答と同じ架空の本文ハッシュが得られました。これは少なくとも検証環境でのテナント越境閲覧を裏付けます。HTTP 200だけではエラーページを返した可能性が残るため、許可された試験データの内容・Content-Type・ハッシュを確認しています。この二要求だけで過去の実被害や全請求書の漏えい範囲は確定しません。

これはBOLA（Broken Object Level Authorization）、すなわちオブジェクト単位の認可欠落の例です。テナント41の正規利用者が、IDという未信頼入力を9102に変えられることが成立条件です。APIがセッションの所属とDBの請求書所属を照合せずにPDFを返す位置で、信頼境界を越えています。

到達確認：AとBの認証情報、セッション期限、検査したURL、HTTPメソッド、取込・一覧・PDFなどの対象機能を残す。ログイン画面だけ走査していないか調べる。
安全な検査：検証環境の試験用請求書を使い、本文や個人情報を報告書へ複製しない。ハッシュと請求書ID、要求IDで再現可能にする。
限界：DASTは観測した環境と状態での挙動を示す。未実行の管理画面、バックエンドのコード経路、別のテナント構成やビルドの安全性までは示さない。

6. IAST：実行した処理の内側を計測する

IAST（Interactive Application Security Testing）は計測機能を稼働中アプリに組み込み、機能テストやDASTが実際に通した処理を内部から観測する方式です。入力の伝播先、実行された関数、DB呼出しなどを特定しやすくなります。計測対象の言語・プロセスに対応せず、テストで未実行の分岐は観測できません。製品ごとの検出規則と性能影響も確認します。

次の架空の計測ログでは、14:11のDAST要求と同じ要求IDを使います。HTTP応答だけでは見えなかったDB条件を確認するための例です。

text

request_id=req-1411 actor=A session_tenant=41
route=GET /api/invoices/9102/pdf
IAST span=db.query table=invoices
  predicate=id=9102
  tenant_predicate=absent
  returned_tenant=42
IAST span=object_store.read key=inv/42/9102.pdf

計測ログは、請求書をIDだけで取得し、テナント条件を付けないままBのPDFを読んだことを示します。HTTP応答の証跡と要求IDを突き合わせると、認可欠落の発生位置を絞れます。ただし計測結果に`tenant_predicate=absent`と出たことだけでは、別の層で妥当な認可があった可能性を完全には排除できません。コード、設計、再現要求を照合します。

IASTを入れたがCSV取込のテストが一度も実行されなければ、取込ワーカーの検査は済んでいません。APIとワーカーが別プロセスなら両方が計測対象か確認します。カバレッジは『どの処理を実行したか』の目安であって、通過した全ての脆弱性を発見した保証ではありません。

IASTの証跡は、テスト要求ID、計測したプロセスとビルド、通過したルート・関数、警告の根拠を組にして読みます。計測エージェントが無効化されたビルドや、非同期ワーカーへ要求IDが渡らない構成では、HTTP側と内部処理の相関が途切れます。性能影響が大きければ検証環境で対象を絞るなど、結果と運用条件を合わせて記録します。

7. SCA：依存部品の既知問題と、実際に使う版を照合する

SCA（Software Composition Analysis）は自作コード以外のライブラリやその推移的な依存部品を棚卸しし、公開済みの脆弱性情報などと照合します。ロックファイルだけ、コンテナだけ、実行成果物だけなど、何を入力にしたかで見える範囲が違います。既知問題の一致は調査の開始点であり、このサービスで悪用可能と確定した意味ではありません。

次は架空の依存部品と架空の通知です。`csv-reader-example`と`ADV-EXAMPLE-001`は実在の脆弱性番号ではありません。

text

build_id=example-build-1
lockfile: csv-reader-example 3.2.0 (direct)
artifact: csv-reader-example 3.2.0 (included)
SCA finding: ADV-EXAMPLE-001, affected <3.2.1
reported_fix=3.2.1, status=review-needed

版の確認：ロックファイルだけでなく、実際に配布した成果物・コンテナに同じ部品があるかを調べる。直接依存か推移的依存かを記録する。
利用経路の確認：取込ワーカーがその解析機能を呼ぶか、外部利用者がCSVを直接送れるか、取込担当者権限が必要かを分ける。『呼び出しが見つからない』も未調査の動的読込みがあれば断定しない。
優先度：通知の条件、版、公開範囲、入力制御、業務影響、利用中の防御策を確認する。重大度スコア一つで全サービスの順番を機械的に決めない。
対策：安全な版へ更新し、ロックファイルと成果物の版、CSV取込の正常・異常入力を再検査する。更新不能なら機能停止や入力制限などの暫定策と期限を決める。

SCAは未知の脆弱性や自作コードの認可欠落を通常は見つけません。反対にSASTが自作コードを調べても、依存部品の既知問題を網羅したことにはなりません。SBOMは部品の一覧と追跡に役立ちますが、一覧を作っただけで診断や修正が完了するわけではありません。

通知は後日公開・更新されるため、リリース時にSCAの結果が0件でも運用中の再照合が必要です。部品を更新できない理由があれば、公開入口を制限するなどの暫定策、担当者、期限、再評価条件を残します。『使っていない』と判断する場合も、配布成果物への混入と動的な読込みを確認した根拠が要ります。

8. ファジング：異常入力を大量に与え、再現可能な失敗を残す

ファジングは大量の予期しない入力を自動生成・変異させ、クラッシュ、ハング、資源枯渇、想定外応答などを探す方法です。この事例ではCSV解析ワーカーを対象にし、正常なCSVをシードとして引用符の欠落、長い列、深い入れ子相当の入力を加えます。認可の設計を理解してAとBの関係を推論する手法ではありません。

text

fuzz_target=csv-import-parser build_id=example-build-1
seed=valid-invoice.csv, malformed-quote.csv
limits=1MiB/input, 2s/case, 256MiB/worker
case=seed42-0017 input_id=example-input-42
observed=worker_timeout, queue_retry=3
coverage=parser_error_branch, minimized_case=42bytes

このログからは、特定の入力でワーカーがタイムアウトし、キューが三回再試行したことが分かります。実際に他テナントの処理を止めたか、機密情報が出たかは別のキューメトリクスや応答で確かめます。単一の500応答を見てリモートコード実行と断定しません。入力を最小化し、シード、乱数種、ビルド、制限値、スタックトレースを保存して再現します。

8-1. 入力の作り方と失敗の判定を決める

ランダムな文字列だけでは、CSVの先頭で弾かれて重要な解析処理まで届かない場合があります。正常な請求書CSVをシードにして列数、引用符、改行、文字コード、ファイルサイズを少しずつ変えると、より深い分岐を通せます。カバレッジ誘導型なら新しいコード経路を通った入力を残しますが、カバレッジの高さだけで安全性は保証されません。

失敗の判定にはクラッシュだけでなく、制限時間超過、異常なメモリ増加、予期しない500、別テナントのジョブ遅延、取込結果の破損を含めます。ただし意図した入力拒否の400を脆弱性と扱わず、仕様と再現条件を照合します。問題入力を最小化しないまま大量のログだけ残すと、修正後に同じ原因を確認しにくくなります。

検査対象：CSVパーサ単体ならHTTP認証・アップロード権限・ワーカーのキュー処理を含まない。API全体の試験ではセッション、サイズ制限、非同期処理の結果まで別に見る。
攻撃成立条件：外部利用者がCSVを送れるか、取込担当者しか送れないかで攻撃可能性は変わる。処理時間・メモリ・同時実行数を制限し、失敗したジョブを隔離する。
修正後：最小化した入力を回帰テストへ固定し、タイムアウト・再試行・他テナントのジョブ進行を確認する。クラッシュが消えても、入力拒否や結果データの破損がないか調べる。

9. ペネトレーションテスト：許可された範囲で攻撃経路を組み立てる

ペネトレーションテストは、合意した対象・期間・手法の範囲で、攻撃者の視点から複数の弱点や設定を組み合わせ、実際にどこまで到達できるかを人が確かめる検査です。DASTの自動走査と重なる操作もありますが、業務上の権限、設計上の前提、攻撃経路、影響の確認を人が組み立てます。期間内の対象で見つからなかったことは、システム全体に欠陥がない証明ではありません。

9-1. 開始前に範囲と停止条件を決める

対象：検証環境billing.exampleの請求書API、CSV取込、試験用テナント41・42。管理者の本番データと第三者のサービスは対象外。
許可：実施者、時間帯、許可する操作と禁止する操作、要求速度、テストアカウント、証跡の保管方法、緊急連絡先を合意する。
停止条件：本番利用者に影響が出る、想定外の個人情報が見える、キュー滞留やサービス停止の兆候が出る場合は停止し、連絡して範囲を見直す。
成果物：攻撃前提、再現手順、要求・応答ID、到達した情報の範囲、原因の推定と限界、修正後の再試験条件を記録する。

9-2. 情報収集から報告までの実施順序

9-1で合意した範囲を起点に、攻撃経路を確かめる手順を組み立てます。ここでは検証環境、試験用テナント41・42、請求書APIを対象にします。テストの目的は、到達できる入口と権限の境界を確かめ、成立した事実と未検証範囲を報告できる状態にすることです。

情報収集：仕様、画面操作、API定義、許可された通信記録から請求書の一覧・詳細・PDF・一括出力の入口、HTTPメソッド、認証方式を把握する。画面に現れないAPIも、合意済みの範囲なら調べる。
攻撃仮説：Aが取得した請求書IDをBの9102へ変えると、どの経路で所属照合が抜けそうかを考える。IDの変更だけで結果が変わるかを、AとBの試験データで比較する計画を立てる。
検証：まずA→8101とB→9102の正常な応答を基準に取り、次にA→9102を低い要求速度で試す。HTTP 200だけで判断せず、試験用PDFの内容・ハッシュ、要求ID、応答種別を突き合わせる。
影響確認：許可された試験用請求書だけで到達を示し、DBの所属条件やPDF保存先など原因候補を調べる。追加取得が必要なら事前合意を見直し、顧客の実データへ探索を広げない。
報告：環境・ビルド・使用権限・再現手順・証拠・影響・原因の確度・未検証経路を分けて記す。修正後に同じ権限と条件で再試験できるよう、正常系と拒否系を受入条件に残す。

情報収集で入口を見落とすと、その後の検証範囲も狭くなります。反対に、試していない入口の安全性は報告からは判断できません。診断で得た事実、コード確認からの推定、まだ確かめていない点を区別します。

9-3. テナント越境を一つの経路として証明する

次の図は、ペネトレーションテストでAの正規セッションからBの試験用PDFへ到達した順序です。各段階の証拠と、その位置で必要な防御を対応させます。

請求書ID変更から別テナントPDFまで

1. Aとしてログイン：証跡 session_tenant=41／防御・対処認証と所属を確定
2. IDを9102へ変更：証跡 GET /invoices/9102/pdf／防御・対処 IDを未信頼入力と扱う
3. 所属条件なし：証跡 DBはtenant=42を返す／防御・対処 tenant_idで絞り込む
4. BのPDFを取得：証跡応答ハッシュ一致／防御・対処 PDF保管先も非公開

架空の検証環境。正規のAがIDを変え、認可条件の欠落を通り、Bの試験用PDFへ到達する。

図の到達には、Aの有効なセッション、Bの請求書IDを指定できる入力、請求書単位の認可欠落が必要です。保管先を直接公開している場合はAPI修正後も別経路が残るため、保存先のアクセス設定を別に確かめます。試験用PDF以外のデータを広く取得して影響を誇張せず、過去の実アクセスは監査ログで調査します。

ペネトレーションテストの報告が『9102への200』だけなら不十分です。どの主体のセッションか、9102が誰の請求書か、本文をどう確認したか、どのビルドで行ったかを示します。逆に、検査期間に到達しなかったCSV取込経路について安全と書かず、未検証範囲に残します。

10. 検出結果を一件の修正課題へ束ねる

同じ請求書越境を脅威モデリング、DAST、IAST、ペネトレーションテストが別々に指摘しても、四つの独立した欠陥とは限りません。原因、到達経路、修正箇所で束ね、各手法の証拠を残します。一方、SASTのファイルパス問題とSCAのCSV解析部品は別の原因なので、同じチケットに混ぜて修正漏れを作らないようにします。

text

FIND-01: invoice cross-tenant read
  threat=TM-01; DAST=req-1411; IAST=req-1411
  manual=test-A-to-B; owner=API-team; build_id=example-build-1
  cause=invoice query lacks tenant_id predicate
  impact=tenant42 test PDF readable by tenant41 user
  status=confirmed-in-test; past-production-impact=unknown
FIND-02: import preview path traversal candidate
  evidence=SAST-12; status=needs-manual-validation
FIND-03: csv-reader-example advisory candidate
  evidence=ADV-EXAMPLE-001; status=version-and-reachability-review

FIND-01では検証環境での閲覧を確認できましたが、本番で過去に誰が閲覧したかは未判定です。FIND-02は静的な候補、FIND-03は架空の既知問題との照合結果です。『検出』『再現』『影響確認』『修正済み』を一つのステータスにまとめないことが、科目Bのログ問題でも重要です。

優先順位：テナント越境のように試験環境で機密データへ到達した事象は、影響範囲の確認と遮断を急ぐ。SAST・SCAの候補も放置せず、成立条件を期限付きで調べる。
証拠の保管：要求ID、時刻、ビルド、環境、主体、検査設定、ログの採取元を残す。顧客のPDF本文やセッショントークンを報告書へ転載しない。
担当分担：設計者は要件、API担当は認可条件、保存先担当は公開設定、QAは回帰条件、セキュリティ担当は再現性と残る経路を確認する。

11. 修正後の再検証：警告消失より先に経路を確かめる

FIND-01の修正では、URLの請求書IDを受け取っても、所属テナントは署名済み・サーバ管理のセッションから取得します。DBの検索条件に請求書IDとテナントIDを同時に指定し、取得できた請求書だけで非公開PDFを読みます。フロント画面でボタンを隠すだけでは、APIへの直接要求を止められません。

text

// 修正後の概念例。両IDはDB内では整数。
const tenantId = session.tenantId; // サーバ側で確定
const invoiceId = parseInteger(pathParam.invoiceId);
const row = db.getInvoice({ id: invoiceId, tenantId });
if (!row) return http404();
return privateStore.read(row.objectKey);

SELECT object_key FROM invoices
 WHERE id = :invoiceId AND tenant_id = :tenantId;

クエリの条件にtenant_idを足しても、一覧・詳細・一括出力・PDF直リンクの別経路が旧処理を使えば越境が残ります。保存先が公開されていないこと、請求書を参照する全APIで同じ認可が働くこと、管理者の例外権限が仕様どおりであることを別々に確認します。

修正から再開判断までの証拠

1. 影響を抑える：対応該当APIの制限／確認する証跡遮断・利用ログ
2. 認可を修正：対応所属条件を追加／確認する証跡差分とコード審査
3. 経路を再試験：対応 A・Bで再実行／確認する証跡応答と監査ログ
4. 監視して再開：対応例外経路も確認／確認する証跡到達・拒否の継続

検証で見つけた越境閲覧に対し、入口の封じ込め、修正、同じ条件と隣接条件での再試験、運用監視をつなぐ。

図の再試験では、問題を再現したA→9102だけでなく、A→8101とB→9102の正常系も確かめます。拒否だけを見て正規利用者の請求書閲覧が壊れていないかを見落とさないためです。過去のアクセスログで被害範囲を調べる作業は、修正後のテストとは別に進めます。

11-1. 修正したビルドで取る回帰テストの証跡

text

build_id=example-build-2
A tenant=41 GET /api/invoices/8101/pdf -> 200
A tenant=41 GET /api/invoices/9102/pdf -> 404
B tenant=42 GET /api/invoices/9102/pdf -> 200
unauth      GET /api/invoices/9102/pdf -> 401
object_store public_read=false
retest: list/detail/export/pdf paths checked
audit: req-1411-pattern denied, no PDF body logged

この証跡は修正後ビルドでの対象条件が期待どおりになったことを示します。前のビルドのスキャナ結果やコード差分だけでは修正を証明できません。権限を変えた要求、別メソッド、キャッシュ、保存先の直接URLも含めて、実際のデプロイ構成で検証します。

11-2. 各手法の再実行で見ること

脅威モデリング：新しい請求書経路や外部保存先が図・TM-01の対象に入ったか更新する。旧モデルの完了印を流用しない。
SAST：修正コードと対象範囲を再走査し、SAST-12の原因が除かれたかコードで確認する。警告が消えた理由が除外設定変更だけではないか調べる。
SCA：更新後のロックファイルと配布成果物の版を照合し、既知問題の再評価とCSV正常処理を確認する。新たな依存問題も見る。
DAST・IAST：修正後ビルドでA/Bの同じ要求と別経路を実行し、HTTP応答とDB条件を要求IDで突き合わせる。認証切れで未到達になっていないか確認する。
ファジング：保存した最小化入力と元のシードを再実行し、ワーカーのタイムアウト、ジョブ再試行、正常CSVへの影響を見る。
ペネトレーションテスト：元の攻撃経路を同じ権限で再実行し、隣接する一覧・一括出力・PDF保存先の迂回路も試す。再試験で使った権限と範囲を記録する。

再開は『全スキャナの重大警告が0件』という数だけで決めません。FIND-01の経路遮断、保存先の非公開、正規請求書の閲覧、CSV処理の健全性、未解決の候補の扱い、監査ログの継続を責任者が確認します。後日新しい部品の通知や経路変更があれば、同じ証拠を再利用せず評価をやり直します。

12. 科目B（午後）の記述演習

各問では、検査が見た範囲と、そこから判断できないことを分けて答えてください。条件に書かれていない本番被害や全経路の安全性を推測で補わない練習です。

演習1：設計段階での脅威をどう検査へ落とすか

条件：AとBは別テナントで、URLの請求書IDを利用者が変更できます。設計レビューでは『APIがIDだけでDBを読む可能性』が挙がりました。問い：脅威、実装要件、受入テストを答える。

解答：AがBのIDを指定し、APIが所属を確認せずBのPDFを返す情報漏えいです。請求書を読む全経路でサーバ側セッションのtenant_idとDBのtenant_idを照合します。A→8101とB→9102の許可、A→9102と未ログインの拒否を、APIと保存先まで確認します。

誤答の理由：『請求書IDを推測しにくくする』だけでは、IDが漏れたときの認可欠落が残ります。『SASTを実行する』だけでは、業務上の所属規則が実装されたか確認できません。

演習2：DASTの検出0件をどう読むか

条件：DASTは未ログインで請求書APIを2件試し、両方401、重大な検出0件と報告しました。問い：何が確認でき、追加で何を試すか。

解答：未ログインの二要求が拒否されたことだけが確認できます。AとBのテスト用セッションを使い、各自の請求書と他テナントの請求書を試します。認証が継続し、対象URL・メソッドへ実際に到達したことをスキャン記録で確認します。

誤答の理由：『検出0件なので認可は安全』は、認証済み経路を走査していない条件を無視しています。

演習3：DAST・IASTの証拠を合わせる

条件：A→9102がHTTP 200で、試験用BのPDFハッシュと一致しました。IASTでは同じ要求IDにtenant_id条件のないDB検索と、BのPDF読取が記録されています。問い：どこまで確認でき、何を追加調査するか。

解答：検証環境のそのビルド・権限で、AがBの試験用PDFへ到達したことを確認できます。APIの認可条件、一覧・一括出力・保存先の別経路、実際に配布されたビルド、過去のアクセスログを調べます。過去の本番被害の有無は、この検証ログだけでは確定しません。

誤答の理由：『IASTが警告しただけなので誤検知』はHTTP応答と本文ハッシュを無視しています。『全顧客が漏えいした』は過去のアクセス証拠を欠きます。

演習4：SCAの一致と悪用可能性

条件：SCAはCSV解析部品3.2.0が架空の通知ADV-EXAMPLE-001に一致すると示しました。ロックファイルには部品がありますが、配布成果物と利用経路は未確認です。問い：直ちに確定できることと調査・対策を答える。

解答：入力したロックファイル上の版が通知の対象条件に一致したことまでです。成果物の版、取込ワーカーの呼出し、CSV投稿権限、通知の成立条件を確かめます。影響があれば安全な版へ更新し、実際の成果物と取込の正常・異常入力で再検証します。

誤答の理由：『SCAで一致したので外部から攻撃成功』は到達経路を調べていません。『アプリのコードは問題ないので無視』は依存部品のリスクを見落とします。

演習5：ファジングでタイムアウトを見つけた

条件：不正なCSV一件で取込ワーカーが2秒の制限を超え、キューが三回再試行しました。取込APIは担当者だけが利用できます。問い：確認できる事実、残る判断、修正後のテストを答える。

解答：特定入力でワーカーがタイムアウトし、再試行した事実です。担当者権限が必要という入口条件と、他ジョブへの影響を調べます。入力を最小化して再現条件を固定し、解析処理の修正、サイズ・時間・再試行制御、正常CSVと他テナントの処理継続を確認します。

誤答の理由：『500やタイムアウトは直ちに情報漏えい』は証拠のない影響を加えています。『担当者だけなので対策不要』は権限侵害や誤投入時の可用性を無視しています。

演習6：ペネトレーションテストの範囲

条件：検証環境の請求書APIに対し、二つの試験用テナントと低い要求速度が許可されています。テスタはA→BのPDF閲覧を再現しました。問い：報告に必要な証拠と、範囲外についての記述を答える。

解答：使用権限、環境・ビルド、請求書IDと所属、要求・応答ID、本文を最小限で確認した方法、原因候補と修正後の再試験条件を記録します。CSV取込や本番の全データは未検証と明記します。影響範囲の調査が必要なら、合意した手順で追加作業を計画します。

誤答の理由：『一つ越境したので全データを取得してよい』は許可範囲を越えます。『他は問題なし』は試していない経路の安全性を断定します。

演習7：修正後に404だけ返ればよいか

条件：APIのDB検索にtenant_id条件を追加しました。A→9102は404になりましたが、A→8101、B→9102、一覧、一括出力、保存先の直接公開は未確認です。問い：再開前に何を確かめるか。

解答：A・B各自の正規閲覧が200で成功すること、他テナントと未ログインが拒否されること、一覧・詳細・一括出力・PDF取得の全経路で所属条件が働くこと、保管先が非公開であることを修正後ビルドで確かめます。監査ログと過去のアクセスも調べ、責任者が残るリスクを判断します。

誤答の理由：『A→9102が404だから修正完了』は、正規利用の破損や別経路での迂回を検証していません。

演習8：脅威の対策順をどう決めるか

条件：Aは請求書IDを変更できます。現行設計案はIDだけで検索し、所属照合の追加を検討中です。一方、CSV取込は担当者限定ですが、異常入力によるキュー滞留が懸念されています。問い：二つの脅威をどう比較し、何を未確認として残すか。

解答：入口に到達できる主体、成立に必要な条件、機密性・可用性への影響を比べます。請求書越境は顧客情報の漏えいにつながるため、所属照合と二テナントの試験を先に計画します。CSVは担当者権限と共有キューへの影響を調べ、制限と隔離を設計します。各入口の実装状況と利用権限が未確認なら、評価を更新する条件として残します。

誤答の理由：『CSVは担当者限定なので無視』は権限侵害や誤投入を考慮していません。『発生可能性を未判定のまま低とする』は検査前の不確実性を隠します。