診断で確認できる内容
外部からはHTTPS、レスポンスヘッダー、公開ページの異常、露出ファイルなどを観察します。内部権限があれば製品の正確な版、権限、更新状態、バックアップ、設定、ログを確認できます。独自開発のソースレビューや認証後の機能検査は、別の作業として範囲を定義します。
診断前に合意する項目
- 対象ドメイン・IP・画面と、対象外のシステム。
- 閲覧のみか、スキャンや再現確認を含むか。
- 実施日時、アクセス頻度、停止条件と連絡先。
- 第三者サービスや共用サーバーの利用条件。
- データの取り扱い、成果物、改善後の再確認。
公開サイトでも、脆弱性を再現する入力や大量リクエストを自由に送ってよいわけではありません。検査の許可は、ドメイン所有者だけでなく利用サービスの条件にも合わせます。
診断の進め方
構成と業務影響を整理し、合意した検査を実施します。自動検出は誤検知や見逃しがあるため、人が根拠を確認します。結果は「検出」「該当確認済み」「未確認」を区別し、緊急事項は最終レポートを待たず共有する連絡手順を設けます。
報告書で確認する内容
問題の位置、観察した根拠、想定影響、成立条件、優先度、改善案、未検査の範囲を記載します。再現用の秘密情報を報告書に直接埋めず、必要なら安全な経路で別管理します。
対策と再診断まで計画する
診断だけでは設定もコードも修正されません。更新、権限整理、構成変更を担当者へ割り当て、改善後に同じ観点で確認します。診断日以降に追加された製品や新しい脆弱性もあるため、継続保守と役割を分けて考えます。
診断項目を業務上の懸念へ結び付ける
問い合わせ内容を保存するサイトなら、フォームの入力処理だけでなく、保存先、管理者の閲覧権限、バックアップ、ログへの記録範囲も確認します。会員機能があるなら、他人の情報を見られないか、利用者区分ごとの権限制御をどう検査するかを合意します。画面数だけでは必要な検査量は判断できません。外部からのバージョン推定で問題候補が出た場合は、内部の実構成を照合します。詳細な再現確認が本番へ影響するなら、検証先や代替の証拠を検討します。検査方法を勝手に拡張せず、追加で必要な範囲を相談します。
成果物を受け取った後の進め方
指摘ごとに担当者と対応期限を決め、「修正」「暫定措置」「受容」「追加調査」に分類します。受容する場合も理由と承認者を残します。修正後に同じ観点で再確認し、業務機能への副作用がないかを確認します。診断時点の結果であることを前提に、構成変更後の再評価も計画します。
管理画面の権限を渡さずに診断できますか？
外部から確認できる範囲では可能です。ただし正確な構成、ユーザー権限、内部設定、バックアップの実態などは判断が限られます。分からない点を未確認として報告する条件を合意します。
診断で問題がなければ侵入テストも不要ですか？
目的と対象が異なります。標準構成の点検で足りるか、認証後機能や独自コードの検査が必要かは、扱う情報、取引先要件、リスクに応じて判断します。