脆弱性診断の認証後画面はどこまで？権限別に範囲を決める方法

脆弱性診断の対象を画面名だけで決めると、ログイン後の機能、利用者区分、操作経路、テスト用アカウントの条件が抜けやすくなります。同じ画面でも、利用者の権限や利用できる機能が違えば、確認する範囲を分ける必要があります。

結論から言うと、認証後画面は画面数だけでなく、権限・操作経路・テスト用アカウントをそろえて決めます。利用者区分ごとに対象表を作り、どの権限でどの機能を確認するか、対象外にする画面はどれかを明確にします。

発注前に、権限別の対象、テスト用情報、実施条件、報告書で確認する項目を整理しておけば、対象の認識と修正後の確認を関係者で共有しやすくなります。この記事では、認証後画面の範囲を決める表の作り方を説明します。

本記事で分かること

• 権限別に認証後画面を分ける方法
• 操作経路と対象外の残し方
• テスト用アカウントと実施条件
• 報告書・修正・再確認で確認する内容

結論：権限別の対象表を作る（早見表）

認証後画面は、画面数だけでなく、権限・操作経路・テスト用アカウントをそろえて決めます。対象表では、利用者区分、主な機能、管理者、対象可否、対象外の理由を別の欄にします。

認証後の対象を分ける

利用者の権限ごとに対象を確認します。権限の種類、操作経路、対象外の画面を別に整理し、対象ごとに管理者と承諾を得る窓口を確認します。

権限の種類

権限の種類は、一般利用者、管理を担う利用者、社内確認用の利用者など、業務上の役割ごとに整理します。権限名だけでなく、どの画面・機能を利用できるか、誰が管理するかを対象表に記載します。同じ画面でも利用者区分で操作できる内容が異なる場合は、別の行にします。

Webアプリ診断の対象範囲を参照し、画面、利用者区分、認証後の機能、連携先を分けて整理します。対象に含める権限と対象外にする権限を明確にし、対象外の理由と見直す条件を残します。

操作経路

操作経路では、ログイン後にどの画面・機能へ進むか、関連するAPIや外部連携があるかを整理します。画面名の一覧だけでなく、利用者が行う主な操作と、対象に含める理由を記載します。経路の管理者と、対象の承諾を得る窓口も確認します。

経路に変更予定がある場合は、確認する版と変更の連絡先を記録します。対象表に操作経路を入れることで、依頼先と「どの画面を確認するか」だけでなく、「どの条件でその画面に至るか」を共有できます。対象外の経路も理由とともに残します。

対象外の画面

対象外の画面には、今回確認しない画面・機能・権限と、その理由を記載します。管理者の承諾を確認中、別の発注で扱う、今回の目的と関係しないなど、判断の根拠を残します。対象外を空欄にすると、今回確認していない範囲を報告書と照合できません。

対象外にした画面が将来の変更で関係する場合は、見直すきっかけを記録します。権限の追加、画面の変更、連携先の変更があったときに、誰が対象表を更新するかを決めます。対象外を固定せず、条件が変われば再評価できる形にします。

テスト用情報を準備する

テスト用アカウントの用途と期限を分けて管理します。アカウントの発行、データの扱い、実施時間帯を対象表と条件表に対応付け、どの権限で何を確認するかを明確にします。

アカウントの発行

テスト用アカウントは、利用者区分ごとに必要な権限と、利用できる範囲を整理して発行します。実在の利用者情報をそのまま扱う前提にせず、社内の取扱いルールに沿って準備できる情報を確認します。提供方法、利用期限、通常の質問窓口を条件表に記載します。

アカウントを用意できない権限がある場合は、対象外にするのか、別の確認方法を検討するのかを関係者で決めます。アカウントを渡すことだけで完了にせず、どの画面・機能・経路の確認に使うかを対象表に対応付けます。

データの扱い

データの扱いでは、テスト用アカウントで利用できる情報、提供方法、共有範囲、利用期限を整理します。必要な情報だけを必要な担当者へ渡し、対象と関係のない情報を広く共有しません。社内の情報管理のルールと契約上の条件を確認します。

データを用意できない機能がある場合は、対象外として理由を記録します。別の環境で確認する場合は、対象となる版と本番との差を整理します。データの条件が変わった場合は、対象表、実施条件、連絡体制へ影響するかを確認します。

実施時間帯

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

セキュリティ診断の発注ガイドを参考に、対象、承諾、実施条件、成果物、連絡体制をそろえます。対象となる版や権限に変更があれば、対象表と実施条件を更新し、依頼先へ共有します。

報告で確認する範囲

対象権限と確認時点を報告書で照合します。対象の記載、修正担当、再確認条件を対象表と対応付け、どの権限・画面・経路を確認した結果かを追えるようにします。

対象の記載

報告書を受け取ったら、対象にした権限、画面、操作経路、確認した版と時点が対象表と対応しているかを確認します。対象外にした範囲も記載されていれば、今回確認していない領域を関係者で共有できます。対象の認識に差がある場合は、どの条件が違っていたかを整理します。

報告書を保管するだけでなく、対象表のどの行に関する結果かを対応付けます。権限が複数ある場合は、一つの結果としてまとめず、どの権限・機能で確認したかを記録します。追加の確認が必要な場合は、対象と条件を明確にして相談します。

修正担当

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

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

再確認条件

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

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

まとめ

脆弱性診断の認証後画面は、権限、操作経路、テスト用アカウント、対象外を一つの対象表に整理して決めます。報告書では対象権限と確認時点を照合し、修正・再確認の担当と条件を対応付けることで、発注後の判断を進めやすくなります。

認証後画面の対象整理は、Webアプリ診断の対象範囲と、進め方の記事一覧から確認できます。