脆弱性診断とは?種類・流れ・実施タイミングと「どこまでやるか」の判断基準を実務目線で解説

WEBサービスに「完全な安全」はありません。だから脆弱性診断は“やるかどうか”ではなく、“どこまでやるか”と“どう使い分けるか”が重要になります。

本記事では、手動・自動の違いやアプリケーション/ネットワーク/AWS診断の整理に加え、“どこから手動に切り替えるか”“どのリスクを優先するか”、実務で迷いがちな判断基準を具体化します。さらに、自動診断だけでリリース、再診断漏れ、AWS設定ミスの見逃しなどのよくある失敗も踏まえ、診断→対処→再診断までの現実的な進め方が分かります。

脆弱性診断の診断箇所

脆弱性診断には「手動」と「自動」の2通りの方法があります。

定型的なチェックは、「手動」よりも「自動」のほうが「早く」「大量に」「安価に」行うことが可能です。

一方、非定形的なチェックは「手動」診断に頼ることになります。

診断内容には次の3種類のものがあります。

・ アプリケーション診断
・ ネットワーク診断/プラットフォーム診断
・ AWS診断

アプリケーション診断

システム自体の脆弱性について診断を行います。SQLインジェクションを引き起こすようなパラメータを使ったログイン試行やURLパラメータの付与など、システムに応じた形で診断を行っていきます。

システム固有のものが多いため、「手動」診断が主となります。価格はチェック対象URLに応じた費用体系となり、高額の費用感となります。

ネットワーク/プラットフォーム診断

サーバ環境の設定やミドルウェアについての診断を行います。ファイアウォールの適用有無や、脆弱性が発見されているバージョンのミドルウェアの利用有無などのチェックが可能です。

システム固有のものが多いため、「手動」診断が主となります。価格はチェック対象URLに応じた費用体系となり、高額の費用感となります。

AWS診断

AWSに特化した診断を行います。セキュリティ上望ましくない設定や推奨設定の未設定などの診断が可能です。

脆弱性診断の流れ

脆弱性診断は診断をして終了ではありません。診断結果を踏まえた対処と確認が必要になります。

まず、診断結果をもとに対処方法を決定する必要があります。リスクが高いものについては、バージョンアップや修正対応などの対処を実施します。リスクが低いものは対応コストを加味して対応有無を決定していきます。

対応方針が決定したら、ミドルウェアのバージョンアップなどの対処を行います。バージョンアップを行うと、システムの動作不具合を引き起こすこともあるので、対処後の動作確認も忘れずに行う必要があります。

全ての診断結果に対する対処が完了したあとは「再診断」を行います。指摘事項がすべて想定通りのステータスとなっていることが確認できたら終了となります。

脆弱性診断のタイミング

脆弱性診断はいつ行えばいいのでしょうか?

まず最初に必要になるのは、新規システムのリリース前です。新規リリースは可能な限りセキュリティリスクを排除した状態で行いたいものです。脆弱性診断をすることで、開発したシステムがセキュアコーディングで守られているか、各種ミドルウェアが脆弱性を抱えたバージョンになっていないかを確認します。「手動のアプリケーション診断」と「自動のネットワーク診断」を組み合わせて利用することが多くあります。

リリース後は定期的に診断を行います。利用するミドルウェアの新たな脆弱性は常に発見されている状況です。有名のものであればあるほど数多くの脆弱性が発見されています。定期的なネットワーク診断を行うことで、新たな脆弱性に対するリスクを洗い出すことが可能です。

システムの大型アップデートを行った場合は、「手動のアプリケーション診断」を再度実行します。

Q. 手動診断と自動診断はどこで切り分けるべきですか?

A. 目安は「ロジックが絡むかどうか」です。静的ページや既知の脆弱性チェックは自動で十分ですが、認証・決済・権限管理など挙動に依存する部分は手動が必須です。リリース前は“自動で網羅→重要機能だけ手動で深掘り”の組み合わせが現実的です。

Q. 自動診断だけで問題ないケースはありますか?

A. 変更頻度が低い静的サイトや、外部公開範囲が限定的で重要なロジックを持たない場合は、自動中心でも運用可能です。ただし、ログインや入力処理がある時点で自動のみはリスクが残ります。

Q. 手動診断はどこまでやるべきですか?

A. 全画面・全パターンを網羅するのは非現実的です。影響度の高い機能(ログイン、権限変更、決済、個人情報操作)に絞り、「悪用されたときの被害が大きい箇所」から優先的に実施します。

Q. アプリケーション診断とネットワーク診断の優先度は?

A. 初回リリース前は両方必要ですが、継続運用ではネットワーク(ミドルウェアの脆弱性)は定期的に、自動中心で回しやすい一方、アプリは大きな変更時に手動で重点的に実施するのが効率的です。

Q. AWS診断で特に注意すべきポイントは?

A. 代表例は、S3の意図しないパブリック公開、IAMの過剰権限付与、Security Groupの過度な開放です。いずれも“設定ミスで即リスク化する”ため、自動チェック+設定レビューの併用が有効です。

Q. 診断後はすべて対応すべきですか?

A. いいえ。実務では「全件対応」はコスト的に難しいため、リスクと影響度で優先順位を付けます。高リスクは即時対応、低リスクは保留(リスク受容)とし、理由を明確に残すことが重要です。

Q. よくある失敗パターンは?

A. ・自動診断だけでリリースし、権限ロジックの不備を見逃す

・修正後の再診断を省略し、監査で指摘される

・AWSの設定(S3公開やIAM権限)を見落とす

いずれも「やったつもり」で終わるケースです。

Q. 脆弱性診断のベストなタイミングは?

A. 新規リリース前は必須です。その後は定期的なネットワーク診断(自動中心)、大規模アップデート時はアプリケーションの手動診断を追加。重要変更のたびに“どこまで再診断するか”を判断する運用が現実的です。

脆弱性診断はシステムが抱える脆弱性の発見に役立てることが可能です。診断対象は複数あるので、タイミングに応じた形で診断を行いましょう。また、診断によって発見されたリスクについて対処を行い再診断を行うところまでをセットで考える必要があります。余裕を持ったスケジュールを組んで臨みたいところです。

おすすめの脆弱性診断

脆弱性診断サービス