注文システムのセキュリティテストはどこまで？対象と除外の決め方

注文の仕事と、何を確かめる検査かをそろえる

セキュリティテストは、情報や操作を守るための条件が満たされるか、弱点がないかを確かめる取組です。脆弱性診断は、定めた対象にセキュリティ上の弱点がないか調べる依頼名として使われます。ただし、依頼先や方式で含む作業は変わります。名称だけで「システム全体を、すべての方法で検査する」と読まず、何を何の目的で調べるかを確かめます。

この例で関わるのは社内IT発注担当、営業担当、倉庫担当、開発会社、検査担当です。業務側は注文をどう扱いたいかを、開発会社は画面と処理の関係を、検査担当は調べ方と制約を説明する相談先です。実際にどの担当が了承したかは、この役割の列挙から決まりません。

依頼する対象の紙と、受け取る報告書が、同じ注文の仕事を指しているでしょうか。

「動くか」の確認だけで、権限の確認を済ませない

注文を登録できることと、その役割が扱ってよい注文だけを扱えることは、違う問いです。営業担当と倉庫担当が必要な情報を使えるかに加え、その役割には許されない情報や操作へ届かないかを、合意した要件と検査方法へ結びます。何を許すかが未確定なら、先に業務側へ条件を聞きます。

IPAの製品開発者向けガイドは、検査の目的・範囲・環境・体制・完了基準を計画でそろえ、要件から確認する項目を考える流れを示しています。OWASPのWeb Security Testing Guideも、対象に合わせて方法を選ぶ参考資料で、固定の適合基準ではないと説明しています。資料名を選んだだけで、自社の検査範囲が決まるわけではありません。

業務で誰に何を見せるかをまだ説明できないなら、発注前に閲覧範囲などの要求を決める方法へ戻ります。本稿では、その要求に対応する対象と実施条件を、検査の依頼へ具体化します。

画面・API・役割・データを、同じ注文へ結ぶ

画面のURLだけを並べる前に、営業担当が注文を入力し、倉庫担当が同じ注文の出荷状態を確かめる仕事をたどります。開発会社へ、画面がどの処理を呼び、どの役割・データ・外部連携に関わるかを聞きます。見えている画面だけでなく、必要な裏側の処理も対象の案へ含めるためです。

APIは、画面や別のプログラムから処理を呼び出す窓口です。ここでは「注文登録API」「出荷状態参照API」という説明用の名前を使います。実際の接続先や操作方法を示すものではありません。画面とAPIを同じ対象として調べるか、それぞれ何を確認するかを、開発会社と検査担当へ確認します。

営業の登録から倉庫の確認まで、画面・API・担当・試験注文が対応しているでしょうか。

この節の解説図を原寸で見る

営業担当の注文登録

画面は「注文登録画面」、処理の窓口は「注文登録API」、使う役割は「営業担当」、データは「説明用の試験注文」です。計画上は対象へ含める候補としています。候補に挙げたことは、所有者の許可、試験利用者の準備、検査の実行が済んだという意味ではありません。

開発会社へ、この画面と処理がどの対象版で対応するかを聞きます。業務側へは、同じ試験注文について必要な内容と、役割ごとに許される操作を示してもらいます。検査担当とは、その条件をどの方法で調べ、報告でどう識別するかを合わせてください。

倉庫担当の出荷確認

画面は「出荷確認画面」、処理の窓口は「出荷状態参照API」、使う役割は「倉庫担当」、データは「同じ説明用の試験注文」です。計画上は対象へ含める候補としています。候補に挙げたことは、所有者の許可、試験利用者の準備、検査の実行が済んだという意味ではありません。

開発会社へ、この画面と処理がどの対象版で対応するかを聞きます。業務側へは、同じ試験注文について必要な内容と、役割ごとに許される操作を示してもらいます。検査担当とは、その条件をどの方法で調べ、報告でどう識別するかを合わせてください。

外部配送サービス

接続の候補は「外部配送APIとの接続」、確認先の役割は「外部サービス所有者」です。画面名は未確認で、扱うデータも未確認です。「画面がない」「個人情報を使わない」とは補いません。計画上は所有者の許可確認を待つ保留です。恒久的な対象外や、安全が確認できたという意味ではありません。

自社のシステムが外部サービスへ接続することと、その外部サービス自体を検査してよいことを区別します。どの接続部分を今回扱いたいか、相手のサービスやデータへ影響する可能性があるかを開発会社へ聞き、必要な許可の範囲を所有者へ確認します。

対象の案・許可済み・許可待ちを混ぜない

対象へ含めたいという案、所有者が許可した範囲、今回実施しないと合意した範囲を分けます。まだ確認できない項目を、黙って対象一覧から消さないようにします。検査担当が触れてよい場所を明確にし、報告を読む人にも、確かめていない範囲が分かるようにするためです。

対象候補と、所有者への許可確認を待つ部分を、同じ図で読み分けられるでしょうか。

この節の解説図を原寸で見る

営業担当の注文登録について、所有者へ確かめる

この対象の所有者の許可は未確認です。自社の画面や処理という説明だけで許可済みにせず、管理する担当へ、どの版・環境・操作を誰が検査してよいかを確認します。外部の接続先や共有の基盤へ影響するなら、その境界も説明してもらいます。

倉庫担当の出荷確認について、所有者へ確かめる

この対象の所有者の許可は未確認です。自社の画面や処理という説明だけで許可済みにせず、管理する担当へ、どの版・環境・操作を誰が検査してよいかを確認します。外部の接続先や共有の基盤へ影響するなら、その境界も説明してもらいます。

外部配送サービスについて、所有者へ確かめる

この対象の所有者の許可は未確認です。外部配送サービスの所有者へ、検査の可否、必要な申請、対象とする接続部分、使える試験環境やデータの条件を確認します。回答が得られない間、その部分へ実検査を広げません。許可待ちを「検査していないから安全」と読まないようにします。

今回実施しない範囲も、理由と残る確認を残す

範囲を絞る場合は、対象名だけでなく、なぜ今回は扱わないか、何が未確認のままか、誰が次の扱いを判断するかを残します。必要なら、別の検査や確認へつなぐ窓口を決めます。今回の検査範囲から外れたことを、その機能が不要、存在しない、安全という判断へ変えません。

外部サービスを実際には呼ばずに試す案がある場合も、何を代替し、何が実サービスとの違いとして残るかを技術側へ説明してもらいます。代替先があると推測して図へ追加したり、代替先での結果をそのまま外部サービス全体の結果へ広げたりしないでください。

版・環境・アカウント・実施条件を一緒に確認する

対象が決まっても、どの場所で、どの権限を使い、いつ何を行うかが違えば、結果の意味が変わります。検査前に開発会社・管理する担当・検査担当が条件を読み合わせ、実行してよい範囲と、中止が必要になった場合の連絡・戻し方を合わせます。

一つの検査計画に、試験場所・利用者の権限・実施時間・中止連絡が結び付いているでしょうか。

この節の解説図を原寸で見る

対象の版と、試す環境・本番との差をそろえる

この例の対象版、試験環境、本番との差は、いずれも未確認です。検証用の環境を使うなら、機能や設定、データ、外部接続のどこが本番と違うかを開発会社へ聞きます。環境名が「検証」だから結果を本番へ当てはめてよい、とは扱いません。

本番での検査を検討する場合は、対象の所有者と検査担当が、業務への影響と実施条件を個別に決めます。本稿は本番の注文登録、配送への送信、設定変更や検査ツールの実行を指示する手順ではありません。実施方法は、許可された対象と目的に合わせて専門の担当が具体化します。

役割ごとの試験利用者と、環境の対応を確認する

営業担当の注文登録の試験アカウントの準備と、本番に対応する試験環境かどうかは、いずれも未確認です。使ってよい役割とデータ、その利用者で何を調べるかを、対象の管理担当と検査担当へ聞きます。準備できた状態や、本番と同等の状態を推測で補いません。

倉庫担当の出荷確認の試験アカウントの準備と、本番に対応する試験環境かどうかは、いずれも未確認です。使ってよい役割とデータ、その利用者で何を調べるかを、対象の管理担当と検査担当へ聞きます。準備できた状態や、本番と同等の状態を推測で補いません。

外部配送サービスの試験アカウントの準備と、本番に対応する試験環境かどうかは、いずれも未確認です。使ってよい役割とデータ、その利用者で何を調べるかを、対象の管理担当と検査担当へ聞きます。準備できた状態や、本番と同等の状態を推測で補いません。

試験用データでも、実在の顧客情報を複写する必要があるかは別に検討します。説明用の注文で目的に合うか、扱える情報と共有先はどこまでかを決めます。試験アカウントの秘密値を対象一覧や記事へ書き込む必要はありません。利用条件と、管理・受渡しの方法を合わせます。

時間・禁止操作・中止連絡を、実行前に具体化する

許可された実施時間帯、中止時の連絡先、禁止する操作は、いずれも未確認です。検査担当と管理する担当へ、実施してよい時間、予想外の影響を見た場合の連絡・中断の判断、データや外部送信をどう扱うかを聞きます。停止・復旧の手順が関係するなら、その担当と使ってよい方法も確認します。

報告書は、対象と未確認の範囲から読む

報告書を受け取ったら、指摘件数より先に、どの対象を、どの版・環境・権限で、どんな方法で確かめたかを読みます。依頼時の対象一覧と照らし合わせ、予定した範囲と実際の範囲、実施できなかった部分を分けます。ツールを動かした記録だけで、画面・API・権限・外部接続をすべて確かめたとは判断できません。

依頼時に挙げた画面とAPIは、報告書のどの対象に対応しているでしょうか。

営業担当の注文登録の結果を読む

この対象の実際の検査結果と、発見事項の件数は、いずれも未確認です。結果の記録が不明なことを「指摘0件」「検査済み」「安全」へ変えません。実行された場合は、対象・条件・方法・確認できた範囲と、実際の結果を結び付けます。

倉庫担当の出荷確認の結果を読む

この対象の実際の検査結果と、発見事項の件数は、いずれも未確認です。結果の記録が不明なことを「指摘0件」「検査済み」「安全」へ変えません。実行された場合は、対象・条件・方法・確認できた範囲と、実際の結果を結び付けます。

外部配送サービスの結果を読む

この対象の実際の検査結果と、発見事項の件数は、いずれも未確認です。結果の記録が不明なことを「指摘0件」「検査済み」「安全」へ変えません。実行された場合は、対象・条件・方法・確認できた範囲と、実際の結果を結び付けます。

指摘は、直す人が対象と影響を追える形で受け取る

発見事項がある場合は、対象の画面・API・役割、確認した条件、根拠、業務への影響、対策の方向を読めるようにします。詳しい再現情報や機密性のある証拠は、扱える担当と共有方法をそろえます。公開記事へ攻撃の手順や実顧客データを載せる必要はありません。

報告を受けて取りまとめる担当は未確認です。検査担当から結果を受け、開発会社へ技術的な確認を返し、業務への影響を判断する窓口を社内で決めます。報告書に書かれた担当候補を、了承済みの担当としません。

この例の受入判断も未確認です。検査の結果、未確認の範囲、対策と再確認の予定を対応させ、判断する担当へ渡します。指摘件数だけで、業務全体の受入や本番公開の判断が自動的に終わるわけではありません。

回答と修正を、対象一覧と必要な再確認へ反映する

修正後は、報告書で問題が確認された対象と条件を、変更された版に対応させます。どの画面・API・役割・設定を直し、関係する範囲はどこかを開発会社へ説明してもらい、必要な再確認を検査担当と決めます。修正したという連絡と、再確認で解消を確かめた結果を分けます。

指摘された対象が、どの修正と、どの再確認へつながるでしょうか。

営業の注文登録、倉庫の出荷確認、外部配送の三対象とも、再確認の結果は未確認です。再確認の条件も未確認です。対象版、環境と権限、何を確かめれば解消と読めるか、結果の返し先を合わせます。追加の確認の範囲や時期・依頼の扱いも、関係者で決めます。

許可の回答が届いた場合は、その回答がどの対象・環境・操作に適用されるかを確認して対象一覧を更新します。外部配送の一部の接続が許可されたことを、外部サービス全体の検査許可へ広げません。必要な実施条件をそろえ、実際に確認した結果を得てから、報告書の対象と対応させます。

IPAは問題の詳細と修正内容を記録し、同様の問題や変更が影響する範囲を確かめる考え方を示しています。毎回無条件に全体を再検査するという意味ではなく、何が変わり、前の結果をどこまで使えるかを説明できるようにします。全体の試験目的や開始条件は、試験を始める前の計画をそろえる方法とも対応させてください。

まとめ：一つの注文から、検査の対象と境界を相談する

セキュリティテストを依頼する際は、一つの注文の仕事から、画面・API・役割・データ・外部連携を対象の案へ結びます。候補に挙げたこと、所有者が許可したこと、実際に検査したことを分け、試す版・環境・利用者・実施条件もそろえます。

まず営業の注文登録から倉庫の確認までを、開発会社へ見せられるでしょうか。

元の架空メモの注意は「全行は架空の対象候補であり、検査実行・発見・修正・再診断・安全認定の実績ではない。proposed_in_scope false は外部所有者の許可未確認に伴う計画上の保留で、恒久的な対象外や安全確認ではない。」です。報告を受け取った後も、対象の案と実施結果、残る確認と判断を対応させて扱います。