ホームページの脆弱性診断、どこまで依頼する？見積もりの範囲を揃える

ホームページの脆弱性診断を外部に依頼する際、見積もりの範囲を正しく揃えておくことがコストとリスク管理の鍵です。まずは「許可取得」「対象URL・機能」「ログイン権限」「再診断・業務影響」の4点を明確に合意し、契約書に落とし込みましょう。この手順を踏めば、後から追加費用が発生するケースや、テストが業務に支障をきたすリスクを大幅に低減できます。

診断範囲の基本的な合意項目

許可取得の具体的手順

脆弱性診断を実施する前に、まずはサイトの所有者・運営責任者から正式な許可を得る必要があります。許可は口頭ではなく、テストの対象範囲、実施期間、連絡先を明記した書面で交わすことが推奨されます。IPAのガイドラインでは、不要な通信の遮断やテスト範囲の合意が推奨されています。

実務的には、依頼書に「テスト対象URL」「使用するツール」「テスト開始日時・終了日時」「緊急時の連絡体制」などを列挙し、担当者の署名をもらいます。社内では情報システム部門や法務部と連携し、万が一の情報漏洩やサービス停止に備えて、責任範囲を明確にしておくと安心です。

本番と非本番のテスト区別

脆弱性診断は原則として非本番環境（ステージング）で実施するのが安全です。非本番環境では実際のユーザーデータが存在しないため、テスト中にデータが破損したりサービスが停止したりするリスクが低減します。一方、本番環境での診断が必要な場合は、業務影響を最小限に抑えるための時間帯や手法を事前に合意しておくことが必須です。

提供者に対しては、テスト用のコピーサイトを用意できるか、または本番環境で実施する場合の「影響範囲限定モード」や「低負荷スキャン」などのオプションがあるかを確認します。合意書には「非本番での実施が原則」「本番実施は例外的に許可し、事前に業務停止リスクを評価する」旨を明記し、万が一の障害時の対応フローも取り決めておくと安心です。

攻撃手順の除外合意

脆弱性診断の成果物には、発見した脆弱性の概要と修正提案が含まれますが、実際に攻撃を行う手順（エクスプロイトコード）まで提供するかどうかは、依頼時に明確に取り決める必要があります。特に業務に直結するシステムや顧客情報を扱うサイトでは、攻撃手順の提供が逆にリスクとなるケースがあります。

見積もり依頼時に「攻撃手順は提供しない」「脆弱性の影響度と修正方法のみ報告」などの条件を明示し、契約書に「エクスプロイトコードの提供は除外」と記載します。提供者側にとっても、実装が難しいエクスプロイトを作成するコストが増えるため、費用面でも透明性が保たれます。

対象URLと機能の選定方法

全ページ対象か重点対象か

脆弱性診断の対象範囲は、全ページを網羅する「フルスキャン」と、重要機能や顧客向けページに絞る「重点スキャン」に分けられます。全ページ対象にすると費用と期間が増大しますが、見落としリスクが低減します。一方、重点対象は費用を抑えつつ、ビジネスに直結する部分の安全性を確保できます。

自社ではまず、トップページ、商品・サービス紹介ページ、問い合わせ・申し込みフォーム、会員ログインページなど、顧客が直接利用する箇所をリストアップします。その上で、提供者に「これらのURLを優先対象にし、残りはサンプルとして抜粋」するよう依頼し、見積もりに反映させます。必要に応じて、サイトマップやページ遷移図を添付すると、正確な範囲設定が容易になります。

外部サービスのリンク扱い

近年のWebサイトは、広告配信や解析ツール、SNS連携など外部サービスのスクリプトを多数組み込んでいます。これらは脆弱性診断の対象に含めるかどうかで、スコープが大きく変わります。外部スクリプト自体は提供者が管理できないため、診断対象外とするケースもありますが、インジェクションや情報漏洩の入口になる可能性は否定できません。

依頼時には「外部スクリプトは検証対象に含めるか」「含める場合はどのような手法でテストするか」を明示します。例えば、Google AnalyticsやFacebook Pixelは読み込みのみを確認し、コード改変は行わないといった制限を設けることが一般的です。

提供者に対しては、対象外とする場合はその旨を明確に書面で残し、リスク評価を自社で実施する旨を合意します。

動的コンテンツの範囲設定

CMSやECサイトなど、ユーザー入力に応じて生成される動的コンテンツは、SQLインジェクションやクロスサイトスクリプティング（XSS）などの脆弱性が潜在しやすい領域です。これらのページは静的HTMLに比べてテストが複雑になるため、スコープに含めるかどうかを事前に検討する必要があります。

対象の選定では、ログイン、個人情報の入力・出力、管理操作、外部との接続など、扱う情報と操作の重要度を優先して確認します。アクセス数が少ない管理機能も対象から漏らさないようにします。

自社で使用しているCMSやフレームワークのバージョン情報、カスタムプラグインの有無をリスト化し、提供者に対して「動的ページはテスト対象とする範囲を明示」や「主要な入力フォームは必ずテスト対象」と指示します。また、APIエンドポイントがある場合は、認証が必要なものと公開APIを区別し、テスト範囲を具体的に指定すると、見積もりのブレを防げます。

ログイン権限とテスト環境の取り扱い

管理者権限と一般ユーザー権限

Webサイトに管理者用のバックオフィスやCMS管理画面がある場合、一般ユーザーと管理者の権限は大きく異なります。管理者権限はシステム全体に影響を与える操作が可能であるため、脆弱性が見つかれば被害規模が拡大します。一方、一般ユーザー権限は限定的な操作に留まりますが、特権昇格の経路になることもあります。

診断依頼時には、まず「管理者アカウントのテストは実施しない」「一般ユーザーアカウントでのテストのみ」など、権限別の範囲を明確にします。もし管理者権限のテストが必要な場合は、専用のテスト用アカウントを作成し、実際の運用アカウントとは分離して管理します。その旨を契約書に記載し、テスト後はアカウントを速やかに削除・無効化する手順も合意しておくと安全です。

テスト用アカウントの作成指針

テスト用アカウントは、検証したい機能に必要な権限を持たせることが推奨されますが、最小権限の原則に沿い、過剰な権限付与は避けるべきです。ただし、テスト中に不正利用されないよう、パスワードは強固に設定し、アクセスは限定されたIPアドレスからのみ許可するなどの制御が必要です。

診断に使うアカウントは、確認する役割と必要な権限を合意して発行します。一般利用者と管理者の境界を調べる場合も、許可された対象と期間を明示し、終了後の無効化を確認します。

具体的には、テスト開始前に情報システム部門と協議し、テスト用のユーザーID・パスワードを発行します。その際、アカウントの有効期間を「テスト期間中のみ」に設定し、ログ取得を有効化します。提供者には「このアカウントでのみテストを実施する」旨を伝え、テスト完了後はアカウントを無効化・削除し、ログをレビューして不審な操作がなかったか確認します。

テスト環境の構築と管理

本番環境と構成が近いテスト環境を用意すると、診断結果の実装性が高まりますが、完全に同等になるとは限らない点に留意が必要です。サーバー構成、ミドルウェアのバージョン、データベースのスキーマなどを同期させることが重要です。一方、テスト環境が本番と乖離していると、診断結果が実際のリスクを正確に反映しない可能性があります。

テスト環境を構築する際は、まず本番環境の構成情報を取得し、仮想マシンやコンテナで同一設定を再現します。データは個人情報を除いたマスク済みのサンプルデータを使用し、外部への通信はファイアウォールで遮断します。提供者には「本番と同一構成のテスト環境で実施」旨を伝え、環境構築の手順書やアクセス情報を事前に共有すると、スムーズに診断が開始できます。

再診断と業務影響の評価ポイント

再診断のタイミングと条件

脆弱性が修正されたことを確認するために、再診断（リテスト）は必須です。修正が不完全だったり、新たな問題が生じるケースもあるため、一定期間後に再度スキャンを実施します。IPAのガイドラインでも、修正後の検証を行うことで、継続的な安全性が確保できると述べられています。

再診断の実施時期や費用は、契約条件により異なるため、見積もり段階で「再診断の実施条件」や「費用体系」について確認し、契約書に明記することが重要です。また、再診断の結果が合格基準を満たさない場合の追加対応フローも事前に合意しておくと、トラブルを防げます。

業務停止リスクの評価方法

脆弱性診断はシステムに負荷をかけるため、特に本番環境で実施する場合は業務停止リスクを事前に評価する必要があります。テスト中にサーバーが過負荷になったり、データベースがロックされたりすると、顧客へのサービス提供が中断される可能性があります。

リスク評価の手順としては、まずテスト実施時間帯を業務閑散期に設定し、負荷テストのシナリオを限定的にすることが有効です。提供者に対しては「同時接続数の上限」「スキャン速度の制御」などのパラメータを提示し、合意書に「業務影響が出た場合の緊急停止手順」を明記します。

さらに、テスト前にバックアップを取得し、万が一の障害時に速やかに復旧できる体制を整えておくことが重要です。

成果物と報告書の内容確認

診断が完了すると、脆弱性一覧、リスク評価、修正優先度、具体的な対策案が記載された報告書が提供されます。この報告書は、経営層への説明資料や、開発チームへの実装指示書として活用できます。報告書は、確認した対象、再現条件、業務への影響、対応案、未確認の範囲を区別してもらい、自社の担当が修正の優先順を決められる形で受け取ります。

受領した報告書は、まず脆弱性の深刻度（CVSSスコアなど）と業務への影響度を照らし合わせて優先順位を付けます。その上で、社内の担当者に「修正期限」「担当者」「検証方法」を明示したタスクシートを作成し、進捗管理ツールに登録します。

報告書の内容に不明点がある場合は、提供者に対して「具体的な再現手順」や「推奨ツールの設定例」を追加で依頼し、実装前に十分な確認を行いましょう。