API脆弱性診断の範囲｜発注前に整理する認証・連携・エンドポイント

API脆弱性診断の見積を依頼するとき、エンドポイントの数だけを伝えれば範囲が決まるように感じることがあります。しかし、同じエンドポイントでも認証方式、利用者の権限、外部連携、試験データの条件が異なれば、確認する前提が変わります。

結論から言うと、API診断はエンドポイント数だけでなく、認証方式・権限・外部連携・試験データをそろえて範囲を決めます。URL一覧を対象表の出発点にしつつ、呼び出す主体と利用条件を別の列で記録します。

発注前に対象と実施制約を整理しておけば、テスト用情報を準備する担当、変更を避ける期間、報告後に修正を担う担当を決めやすくなります。この記事では、APIを見積条件に落とし込むための整理方法を説明します。

本記事で分かること

• API診断で整理する対象単位
• 認証・権限・外部連携の確認方法
• 試験データと実施環境の条件
• 報告・修正・再確認を対応付ける方法

結論：APIの利用条件まで対象表に入れる（早見表）

API診断は、エンドポイント数だけでなく、認証方式・権限・外部連携・試験データをそろえて範囲を決めます。対象表では、エンドポイントの名称、関係する利用者、管理者、対象外にする理由を分けて記載します。

対象の単位をそろえる

URL一覧だけでなく、呼び出し主体と権限を記録します。対象にするAPIごとに、関係する業務機能、利用者、管理者、外部連携の有無を整理し、対象外の範囲も明記します。

エンドポイント

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

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

認証と権限

APIを呼び出す主体と、利用者区分・権限を対応付けます。同じAPIでも、利用する権限や業務上の役割が異なる場合は、確認できる条件が変わります。テスト用の情報を準備する際は、どの権限で何を確認するか、提供方法と利用条件を整理します。

認証情報を用意できない範囲がある場合は、対象外にする理由と、別の確認方法を検討する担当を残します。実在の利用者情報をそのまま扱う前提にせず、社内の取扱いルールに沿って準備できる情報を確認します。Webアプリ診断の対象範囲も参照し、認証後の機能とAPIの関係を対象表に記載します。

外部連携

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

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

実施条件を決める

試験データと実施環境を分け、業務影響を避ける条件を合意します。実施に使う情報、確認できる時間帯、変更を避ける期間、連絡窓口を条件表へまとめます。

テスト用データ

試験データは、確認したい機能と利用者区分に合わせて準備します。実在の利用者情報をそのまま提供するのではなく、社内の取扱いルールに沿って利用できる情報と、確認が必要な情報を分けます。データを用意する担当、提供方法、利用期限、通常の質問窓口を整理します。

データを用意できない機能がある場合は、対象外にするのか、別の環境で確認するのかを関係者で判断します。情報の提供だけを完了条件にせず、どのAPI・権限・機能の確認に使うデータかを対象表に対応付けます。利用条件が変わった場合は、依頼先へ共有する方法も決めます。

実施時間帯

実施時間帯は、通常の利用状況、連携先の都合、保守やリリースの予定を踏まえて決めます。いつでも確認できると仮定せず、避ける時間帯や確認可能な環境を依頼書に記載します。実施中に問い合わせが必要な場合の窓口も、時間帯と合わせて確認します。

本番に近い環境を使うかどうかは、対象機能、利用状況、運用上の制約を踏まえて関係者で判断します。環境名だけではなく、どの版とデータを対象にするかを記録します。条件を明記すれば、報告書を受け取る際にも対象時点の前提を確認できます。

変更凍結

APIや連携先に変更予定がある場合は、診断中に変更を避ける期間と、変更が必要になった場合の連絡方法を決めます。変更を止められない場合も、どの変更を共有するか、誰が対象への影響を判断するかを記載します。変更を発見した担当が一人で判断しない連絡体制にします。

セキュリティ診断の発注ガイドを参考に、対象、承諾、実施制約、成果物を同じ仕様表にそろえます。対象や版に変更があれば、当初の見積条件と照合し、追加確認が必要かを関係者で判断します。

報告・修正の条件を決める

指摘の対象APIと修正担当を対応表で確認します。報告書の対象記載、修正を担う担当、再確認する範囲を発注時の対象表と照合し、次の変更管理へつなげます。

報告書の対象記載

報告書を受け取ったら、対象にしたAPI、認証・権限の条件、外部連携、確認した環境と時点が対象表と対応しているかを確認します。対象外にした範囲も記載されていれば、今回確認していないAPIや連携先を関係者で共有できます。

対象の認識に違いがある場合は、どのエンドポイント、環境、権限の前提が異なっていたかを整理します。報告書を保管するだけでなく、対象表のどの行に関する結果かを対応付けます。追加の確認が必要な場合は、対象と条件を明確にして相談します。

修正担当

修正が必要になった場合は、API、アプリケーション、外部連携、運用設定のどこを誰が担当するかを分けます。一つの指摘に複数の担当が関わる場合は、作業の窓口と完了を確認する担当を決めます。修正予定が別のリリースに入る場合は、対象表と変更予定を更新します。

修正内容を共有するときは、開発担当だけでなく、利用者や業務への影響を確認する担当にも伝えます。診断結果をそのまま作業依頼に置き換えず、自社の変更管理の方法に沿って、対象、担当、確認する範囲を整理します。

再確認範囲

再確認では、どのAPI、権限、環境、版を対象にするかを決めます。修正が外部連携や認証に関係する場合は、関連する機能と利用者区分も含めて対象を確認します。追加の変更があれば、当初の対象との違いを記録します。

手動診断とツール診断の違いを参照し、方式の名称だけでなく、再確認で何を確認するかを仕様にします。対象、条件、結果の受け方を対応付けることで、修正後の調整と次の発注準備を進めやすくなります。

まとめ

API脆弱性診断では、エンドポイント、認証、権限、外部連携、試験データを一つの対象表に整理します。実施環境と変更凍結の条件、報告後の修正・再確認の担当まで決めると、対象の認識と見積条件をそろえやすくなります。

APIの対象整理は、Webアプリ診断の対象範囲と、お役立ち記事一覧から確認できます。