脆弱性診断サービスの比較方法と自動・手動診断の選び方を解説

脆弱性診断サービスの違いと比較軸

自動診断で繰り返し確認する

自動診断は、ツールに設定した対象や検査項目に沿って確認を進める方式です。Webアプリケーションでは、外部からアクセスして応答を調べる検査などがあります。ただし、同じ自動診断でも、ログインできるか、画面の遷移を再現できるか、APIを対象にできるかによって確認範囲は変わります。製品名や検査項目の数だけでなく、自社の機能へ到達するために必要な設定を確かめましょう。

繰り返し実施する前提なら、対象URLやアカウントを誰が登録し、画面の変更後に誰が設定を更新するのかが重要です。初回に設定したままでは、新しく追加した機能が検査対象に含まれていない可能性があります。実施の頻度とあわせて、対象一覧の更新や、認証の失敗に気づくための確認方法も決めてください。

報告書で見たいのは、検出件数だけではありません。巡回できた範囲、認証の成否、検査から外れた機能、実施時のエラーが分かるかを確認します。対象へ到達できなかった場合と、対象を検査して指摘がなかった場合を分けられることが、結果の解釈に役立ちます。自動診断を選ぶときも、運用担当者が結果を読み、必要な追加確認を判断する役割は残ります。

手動診断で業務の前提を確かめる

手動診断は、診断員が対象の仕様や動作を確認しながら検証する方式です。例えば、一般利用者が他の利用者の情報を参照できないか、申請を承認する役割だけが承認操作を実行できるかなど、そのシステムで許される操作の前提を共有して調べてもらう場面があります。こうした前提は画面だけから読み取れないこともあるため、依頼側から仕様や役割を説明する準備が必要です。

ただし、手動診断という名称で、すべての業務機能や操作の組み合わせが自動的に対象になるわけではありません。自動ツールの指摘を人が確認する作業と、機能の仕様を踏まえて検査を設計する作業では、確認する内容が異なります。どの画面、API、権限、業務の流れを診断員が確認するのか、依頼書や見積もりの対象一覧で具体的に揃えましょう。

公開前の重要な機能を重点的に見てもらいたい場合は、その機能を選ぶ理由も伝えます。顧客情報を扱う、権限の変更がある、複数人の承認が必要など、守りたい業務の条件を説明すると、検査範囲の相談がしやすくなります。実際に診断できる範囲や方法は、提供会社と確認して決定してください。

組み合わせる範囲と役割を決める

自動と手動を組み合わせる方式では、それぞれへ何を担当させるかが比較の中心になります。例えば、合意した対象をツールで確認し、重要な権限や業務操作を診断員が検証する設計が考えられます。組み合わせという名称だけで広い範囲を確認できると判断せず、自動で検査する対象、人が検証する対象、今回は対象外とする部分を分けて説明してもらいましょう。

OWASPのWeb Security Testing Guide v4.2の導入でも、複数の検査手法を組み合わせる考え方が示され、自動化したブラックボックス検査だけに依存することの限界が説明されています。手法の名前より、対象に対して何を確かめるかを考えるための参考になります。

提供メニューの実例として、NTTセキュリティ・ジャパンの公式案内には、ツールを使うセルフ脆弱性診断と、ツールに診断員の手動検証を組み合わせるメニューが示されています。これは提供形態の一例です。同じ区分や名称がすべての会社で共通とは限らないため、候補ごとに作業内容を確認する必要があります。

自社で日常的な変化を追い、重要な改修の節目には外部へ重点検査を依頼するなど、時期で役割を分けることも検討できます。その場合も、前回の指摘や対象変更を外部の診断担当者へ引き継ぐ方法を決めておきましょう。複数の方式を導入するだけでなく、結果を同じ対象一覧と修正管理へつなげることが大切です。

提供形態と成果物を同じ軸で比べる

自動・手動という検査方式と、セルフ型・委託型という提供形態は別の軸です。セルフ型では自社の担当者が設定や実施を担うことが多く、委託型では提供会社が合意した範囲を実施します。ただし、委託しても対象の許可、アカウントの準備、業務仕様の説明などは依頼側との協力が必要です。自社に残る作業まで含めて比べてください。

表は典型的な役割分担を考えるための例です。セルフ型でも支援が付く場合があり、委託型にも自動中心のメニューがあります。候補ごとに実際の責任分担へ書き換えて使いましょう。報告書のサンプルを確認するときは、指摘の重大度だけでなく、影響する対象、確認できた事実、対応の考え方、未確認の部分が読み取れるかを見ます。

料金を比べる前にも、対象の数え方や手動検証の内容、結果説明、再診断がどこまで含まれるかを揃える必要があります。画面数や実行回数の表示だけでは作業範囲を比較しにくいためです。診断会社そのものを選ぶ際の確認項目は、脆弱性診断会社の比較と依頼先選びで整理しています。本記事では、自社で運用する部分と委託する部分の線引きを先に決めましょう。

受付開始に向けた準備は、無料の会員登録から進められます。診断の新規受付は現在準備中です。

脆弱性診断サービスを選ぶ手順

診断の目的と対象を一枚にまとめる

最初に、今回の診断を何の判断に使うかを決めます。公開前の確認、重要な機能変更に伴う点検、運用中の定期確認、取引先へ説明するための資料など、目的によって必要な対象や成果物は変わります。「脆弱性を探してほしい」という依頼に加えて、診断後に誰が何を判断するのかを一文で書くと、方式を選ぶ基準になります。

次に、対象を一覧にします。Webサイトのドメインだけでなく、ログイン画面、利用者向け機能、管理画面、外部から使うAPIなどを整理してください。Webアプリケーションの診断と、サーバーやミドルウェアなどを調べるプラットフォーム診断では、対象となる層が異なります。名称の似たサービスを比べる際も、どの層まで含むかを確認しましょう。

方式を考えるための仮定の例として、企業向けの申請システムを取り上げます。一般利用者が申請を登録し、承認担当者が確認し、管理者が利用者の権限を設定するシステムです。公開案内のページだけを調べても、申請情報の閲覧範囲や承認処理を確かめたことにはなりません。この例なら、案内ページと認証後の申請機能を別々に対象一覧へ記載し、後者の業務操作をどの方式で調べるか相談します。

対象一覧には、今回含めたい機能、外したい機能、判断に迷っている機能の三つの区分を用意すると便利です。対象外を曖昧にせず残すことで、追加の診断が必要になった場合にも話をつなげられます。対象を絞る場合は、その理由と、残った部分をいつ確認するかも社内で共有してください。

認証と権限の検査範囲を揃える

ログインが必要なシステムでは、認証できることと、ログイン後に正しい権限で操作できることを分けて考えます。例えば、一般利用者と管理者では利用できる機能が異なり、同じ一般利用者同士でも自分の申請と他人の申請で閲覧範囲が変わる場合があります。どの利用者として、誰の情報に、どの操作を行うかを整理してください。

先ほどの申請システムなら、一般利用者が自分の申請を編集する、承認担当者が担当分を承認する、管理者が役割を変更する、といった正規の操作を説明します。あわせて、一般利用者による他人の申請閲覧や、承認権限を持たない人による承認など、制限すべき操作も伝えます。ここで挙げるのは診断範囲を相談するための例であり、実際の検査手順と実施可否は診断担当者と合意します。

必要なアカウントの種類や数、テスト用データ、認証に使う多要素認証や接続元制限も事前に確認します。アカウントを一つ渡せば権限の違いまで検査できるとは限りません。診断期間中にログインできなかった場合の連絡先、アカウントのロック解除、実施後の停止や削除も分担しておきましょう。認証情報の受け渡しには、提供会社が指定する安全な方法を使ってください。

実施条件と責任分担をすり合わせる

方式が候補に挙がったら、環境、日時、許可の範囲を揃えて実施可否を確認します。本番と検証環境のどちらを使うか、外部サービスとの連携を含むか、メール送信や決済などを伴う操作をどう扱うかを相談してください。外部の基盤を利用している場合は、契約や利用条件に従った事前確認も必要です。依頼側が操作を許可できる範囲を明確にして進めましょう。

特に本番環境では、サービスへの負荷、監視通知、データの作成や変更などについて確認が必要です。止めてほしい状況、実施を一時中断する連絡方法、通常と異なる挙動に気づいたときの連絡先を決めます。診断方式の比較とあわせて、対象システムの担当者が診断時間帯にどの程度対応できるかも考えてください。

候補へ送る確認表は、次の項目を共通にすると回答を比べやすくなります。分からない欄は空欄のままにせず、相談したい項目として示しましょう。

• 目的と対象：今回の判断目的、対象URL・API・機能、含めない範囲
• 検査の方式：ツールで実施する範囲、診断員が検証する範囲、対象へ到達するための準備
• 認証とデータ：利用者の役割、必要なアカウント、テスト用データの作成と後片付け
• 実施の条件：環境、日時、影響を避けたい処理、中断条件、緊急連絡先
• 成果物と支援：結果を受け取る形式、説明の有無、修正後の確認範囲と期限

自動中心のセルフ型を選ぶ場合も、この確認は必要です。実行ボタンを押す担当者と、実施を許可する担当者、検査エラーを確認する担当者、修正を担当する人を分けて整理します。自社で運用しきれない作業がある場合は、支援付きのメニューや実施委託を検討する材料になります。

報告から修正と再診断までを計画する

診断結果は、受け取った後に対応へつながる形かを確認します。指摘の重大度、影響する機能、確認した条件、対応の方向性を読み取れるかを報告書のサンプルで確かめましょう。自社で再現しにくい指摘について質問できるか、開発会社や保守担当者へ説明を引き継げるかも検討します。実際の報告書には機密情報が含まれるため、共有先と保管方法も決めてください。

指摘が出たときの判断は、検出した順番だけで決めないようにします。提供会社の評価を確認したうえで、自社が扱う情報、利用者への影響、業務上の重要性を踏まえて対応順を整理します。修正を担当する部署や開発会社がまだ決まっていなければ、診断前に相談しておくと、その後の対応を進めやすくなります。

修正後の確認では、どの指摘を再診断するか、申請期限や追加条件があるか、修正により関連する機能も変わった場合にどこまで調べるかを確認します。単にツールを再実行することと、特定の指摘への対策を確かめることは、目的や範囲が一致するとは限りません。再診断の結果を受け取った後に、残っている指摘や対象外の部分を誰が管理するかも決めましょう。

指摘がなかった場合にも、確認できた対象と対象外の範囲は記録しておきます。診断は合意した時点と条件のもとで行う確認であり、その後の機能追加や設定変更まで含めて安全性を保証するものではありません。定期確認を計画する際は、変更した機能と前回の検査対象を照合し、必要に応じて手動検証などの追加を相談してください。

脆弱性診断サービスは確認範囲で選ぶ

脆弱性診断サービスは、自動か手動かという区分に加えて、自社の対象に到達できるか、重要な業務操作や権限を確かめるか、修正後まで対応を続けられるかで選びましょう。方式の名前が同じでも、対象外となる機能や依頼側に残る作業が違えば、必要な準備も変わります。まず目的と対象を一枚にまとめ、各社に同じ確認項目を示すことが比較の出発点です。

頻繁な変更を繰り返し確認したい場合は、設定の更新と結果確認を自社で続けられるかを検討します。複数の権限や重要な業務処理を持つ場合は、人が検証する範囲を具体的に相談してください。両者を組み合わせる場合は、範囲の分担と結果の引き継ぎを明確にします。検査で分かった事実と未確認の部分を区別し、次の対応を決められることを重視しましょう。

セキュリティーナビの診断会社検索・比較・紹介機能と、会員向け無料Webサイト診断の新規依頼受付は、現在準備中です。会員登録とサイトの所有確認は進められます。会員向け診断と、専門会社へ依頼する診断では確認範囲が異なるため、本記事で整理した条件をもとに、自社の目的に必要な範囲を確認してください。