API脆弱性診断の見積条件｜費用を比べる前に確認すること

API脆弱性診断の見積書を比べるとき、エンドポイントの数だけでは条件をそろえられません。認証方式、利用者の権限、外部連携、試験データ、実施環境が異なれば、確認する範囲と準備の前提が変わります。

結論から言うと、API診断の見積は、エンドポイント・認証・外部連携・試験環境が一致してから比較します。各見積書の費目を、API対象表、実施条件表、報告・再確認表の同じ欄へ写し、前提差を質問として残します。

この記事では、APIの対象条件、実施制約、見積書を同じ条件に直す手順を整理します。見積書の合計より先に、どのAPIと利用条件を対象にする依頼なのかを社内でそろえましょう。

本記事で分かること

• エンドポイント・認証・連携のそろえ方
• 試験データと実施環境の整理
• 見積書をAPI対象表へ写す順番
• 条件差を社内で説明する方法

結論：APIの見積条件をそろえる（早見表）

API診断の見積は、エンドポイント・認証・外部連携・試験環境が一致してから比較します。API対象表と実施条件表を先に作り、各見積書に書かれた内容を同じ順番で照合します。

API対象をそろえる

エンドポイント数のほか、権限と連携先を確認します。各見積書に渡すAPI対象表には、エンドポイント、認証・権限、外部連携、対象外にする範囲を分けて記載します。

エンドポイント

エンドポイントは、名称だけでなく、どの業務機能や画面と関係するかを記載します。申込み、管理、外部連携などの役割を添えると、開発担当と事業担当が同じ対象を確認しやすくなります。対象に含める理由、管理者、確認する環境を対応付けます。

一覧にあるAPIを一括に対象とせず、今回の目的に関係するもの、管理者の確認が必要なもの、対象外にするものに分けます。変更予定があるAPIは、確認する版と変更の連絡先を残します。対象の数ではなく、確認する条件を明確にすることが発注準備の中心です。

認証と権限

認証と権限は、APIを呼び出す主体、利用者区分、主な業務機能を対応付けて整理します。同じAPIでも、権限や利用する機能が異なる場合は、確認の条件が変わります。テスト用の情報を準備する際は、どの権限でどの範囲を確認するかを条件表に記載します。

Webアプリ診断の費用構造を参照し、画面・機能・認証後の範囲を同じ仕様表にそろえます。認証情報を用意できない範囲がある場合は、対象外にする理由と見直す条件を残します。権限の条件が違う見積書を同じ前提で比べません。

外部連携

外部連携があるAPIは、連携先の管理者、利用目的、自社が承諾を得られる範囲を確認します。外部サービスを利用しているだけの場合は、自社だけで対象に含めません。誰が対象可否を判断し、どこへ確認するかをAPI対象表に残します。

連携先を対象外にする場合も、アプリケーション側で関係する範囲を整理します。対象外という結論だけでなく、今回確認するAPIと連携先の境界を記載すると、依頼先と見積条件を共有しやすくなります。連携の変更予定がある場合は、対象を見直す条件も残します。

実施制約をそろえる

試験データ、実施時間、変更凍結を比較条件に含めます。API対象表だけでは分からない準備と運用上の制約を条件表にし、すべての依頼先に同じ情報を伝えます。

テスト用データ

テスト用データは、確認したいAPIと利用者区分に合わせて準備します。実在の利用者情報をそのまま扱う前提にせず、社内の取扱いルールに沿って利用できる情報と、確認が必要な情報を分けます。提供方法、利用期限、通常の質問窓口を条件表に記載します。

データを用意できないAPIや権限がある場合は、対象外にするのか、別の環境で確認するのかを関係者で決めます。情報の提供だけで完了にせず、どのエンドポイント・権限・機能の確認に使うかをAPI対象表に対応付けます。

実施時間帯

実施時間帯は、通常の利用状況、連携先の都合、保守やリリースの予定を踏まえて整理します。いつでも実施できると仮定せず、避ける時間帯、確認可能な環境、通常時と判断時の連絡先を依頼条件に記載します。時間帯と対象環境の条件を同じ表で確認します。

本番に近い環境を使う場合は、利用できる操作と運用上の制約を確認します。別の環境を使う場合も、対象となる版と本番との差を記録します。実施時点の前提を残せば、報告書で対象環境を照合する際にも条件を確認できます。

連絡と変更管理

対象APIや連携先に変更予定がある場合は、変更を避ける期間と、変更が必要になった場合の連絡方法を決めます。変更を完全に止められない場合も、どの変更を共有するか、誰が対象への影響を判断するかを条件表に記載します。

脆弱性診断の費用構造を参照し、対象、実施制約、成果物、再確認を同じ比較表で確認します。連絡・変更管理の条件を先にそろえることで、見積書の差分をAPIの対象と実施時点に結び付けて説明できます。

見積書を同じ条件に直して比べる

見積書に書かれた対象と条件を、社内のAPI対象表・実施条件表・報告条件表の同じ欄へ写します。各社の記載順が違っていても、比較表の順番を変えずに前提差を質問します。

対象を同じ表へ写す

最初に、各見積書に書かれたエンドポイント、認証・権限、外部連携、対象外をAPI対象表へ写します。一行に複数の条件が書かれている場合も、対象の軸ごとに分けます。含まれるか分からないAPIや連携先は、同じ条件として扱わず質問事項にします。

API対象表の各行に、業務上の役割、管理者、確認する環境、承諾範囲を対応付けます。これにより、見積書の表現が異なっていても、同じ範囲を扱っているかを確認できます。変更予定がある場合は、対象表と見積書の前提を更新します。

条件差を質問する

試験データ、実施環境、時間帯、変更管理、報告書、再確認の条件に差がある場合は、比較表の該当欄ごとに質問します。質問は、どの前提で回答されているかを確認するために行います。回答を受けたら、API対象表と条件表の関係する行を更新します。

追加情報を渡す場合は、すべての依頼先に同じ情報を共有します。片方だけに詳細なAPI対象表を渡すと、比較表の前提が変わります。質問と回答の履歴を残すことで、社内説明で条件差と判断理由を追いやすくなります。

社内説明に残す

社内説明には、対象API、認証・権限、外部連携、実施制約、報告、再確認、未確認事項、判断した担当を記載します。見積書の合計を中心にせず、どの依頼がどの条件を含むかをAPI対象表から説明します。対象外と確認中の範囲も共有します。

セキュリティ診断の発注ガイドを参考に、目的、対象、期限、社内の担当をそろえます。判断後に条件が変わった場合は、何が変わり、誰が影響を確認したかを記録します。比較表を更新すれば、次の見積依頼にも同じ条件を使えます。

まとめ

API脆弱性診断の見積は、エンドポイント、認証、外部連携、試験環境、実施制約を同じAPI対象表・条件表でそろえて比べます。見積書の費目を対象・実施・報告・再確認の欄へ写し、条件差を質問として残すことで、社内の判断を共有しやすくなります。

APIの見積条件は、Webアプリ診断の費用構造と、費用の記事一覧から確認できます。