診断の対象と範囲の決め方

脆弱性診断を依頼する前に決めることは、対象の範囲と環境、許可と連絡体制、方式と基準、報告書の形式と再診断の条件、受け取った後の直す順番の五つです。後の項目ほど前の答えに依存するので、この順番で決めます。この節は最初の「対象の範囲と環境」を扱い、許可と連絡体制は次の節 3.3 で扱います。診断は所有者または管理者の許可を得た対象にだけ行います。

対象の一覧に書くこと見出しのリンクをコピー

診断する対象を一覧にします。一覧が見積もりの前提になり、報告書を本番に当てはめられるかを決めます。

1. URL、ホスト、API。 画面の URL だけでなく、画面から呼ばれる API、管理画面、バッチや外部連携の入口も書きます。書いていないものは検査されません。
2. アカウントの種別。 未ログイン、一般利用者、管理者など、検査に使う権限の種別ごとに試験用のアカウントを用意します。認可の不備は、権限の違うアカウントを比べないと見つかりません。
3. 扱うデータ。 個人情報や決済に触れる機能に印を付けます。範囲を絞るときの優先順位と、直す順番の判断に使います。
4. 範囲外の対象。 第三者のサービス、共有基盤、検査しない機能を明示します。クラウドや外部サービスを含む場合は、その事業者が定める事前申請の要否を確かめます。

本番か検証環境かの判断見出しのリンクをコピー

環境は次の分岐で決めます。

範囲を絞るときは、外部に公開しているもの、個人情報や決済を扱うもの、大きく変更したものの順に残します。実施条件を計画で固めてから検査に進む流れは NIST SP 800-115 と同じです。

範囲が決まった後に決めること見出しのリンクをコピー

範囲と環境が決まった後、次の順に決めます。

1. 許可と連絡体制を文書にする。 所有者の承認、実施期間、実施元 IP アドレス、停止手順、連絡先を 1 枚の文書にまとめます（3.3）。

2. 方式と基準を決める。 方式は、ツールによる自動検査、人手による手動検査、その組み合わせのいずれかです。

   方式	向く対象	留意点
   ツール（自動）	画面数が多い、定期的に繰り返す	認可やビジネスロジックの不備は見つけにくい
   手動	認証・認可・決済など業務固有の処理	範囲を絞らないと期間と費用が伸びる
   組み合わせ	初回の診断、リリース前	両者の分担を書面で分ける

   初回は組み合わせ、2 回目以降は自動検査に変更箇所の手動検査を足す形が、費用と見落としの釣り合いを取りやすい選び方です。検査項目は IPA「安全なウェブサイトの作り方」（改訂第 7 版）第 1 章の 11 種類の脆弱性を土台にし、業務固有の処理を足します。深刻度は CVSS か依頼側の基準かを先に決めます。依頼先は、IPA の「情報セキュリティサービス基準適合サービスリスト」に脆弱性診断サービスとして載っているかを 1 つの目安にできます（掲載は品質の保証ではありません）。

3. 報告書の形式と再診断の条件を決める。 報告書に含める項目（検出箇所、再現条件、深刻度、根拠、対策の方向）、納品形式、報告会の有無を決めます。再現条件がない報告書では、修正担当が直せたかどうかを確かめられません。修正後の再診断は、回数、期限、対象（検出箇所のみか全体か）を契約前に合意します。決めずに始めると、再診断が追加費用になるか、修正の確認が取れないまま終わります。

4. 受け取った後の直す順番を決める。 順番は、深刻度、攻撃の成立しやすさ（認証なしで届くか）、影響範囲（個人情報や決済に触れるか）の三つで決めます（2.3）。項番は優先順位ではないので、報告書の並び順のまま直しません。直し方は原因そのものをなくす根本的な解決を基本にし、すぐに直せない項目は WAF や設定変更で影響を抑えたうえで修正予定日を記録します（IPA「安全なウェブサイトの作り方」と同じ考え方です）。低い項目も放置すると次回の診断に同じ項目が並ぶので、項目ごとに担当者と期限を決めます。

依頼前の確認の一覧見出しのリンクをコピー

• 対象の一覧（URL、ホスト、API、アカウント種別）と範囲外の対象が書かれている
• 本番か検証環境かが決まり、検証環境なら本番との差分、本番なら外部連携の扱いが書かれている
• 所有者の承認と連絡先、停止手順、遮断の例外設定が 1 枚の文書にある
• 方式、基準、深刻度の付け方が決まっている
• 報告書の項目と再診断の条件が契約に含まれている
• 受け取った後に判断する人と、直す順番の基準が決まっている