メールマガジン

サイバーセキュリティや
ラックに関する情報をお届けします。

サービス・製品　|　
2026年10月23日2023年1月30日

脆弱性診断（セキュリティ診断）とは？種類・方法・選び方を解説

広報

メルマガ登録する

メルマガ登録する

ランサムウェアや内部不正による情報漏えいなど、企業を狙ったサイバー攻撃は年々深刻化しています。攻撃者の多くは、システムに残された「既知の脆弱性」や「設定不備」を入り口として侵入してきます。

これらを攻撃に使われる前に発見・対処するための取り組みが「脆弱性診断（セキュリティ診断）」です。とはいえ、「プラットフォーム診断やWebアプリケーション診断などの違いがわからない」「ツール診断と手動診断はどう使い分ければよいのか」と迷う担当者も少なくありません。

本記事では、脆弱性診断の目的・種類・実施方法を体系的に整理し、自社に合った診断方法を選ぶための判断ポイントまで解説します。

脆弱性診断（セキュリティ診断）とは
脆弱性診断（セキュリティ診断）の目的と必要性
ペネトレーションテストとの違い
脆弱性診断（セキュリティ診断）の種類
脆弱性診断（セキュリティ診断）の方法
脆弱性診断（セキュリティ診断）の費用・相場
脆弱性診断（セキュリティ診断）サービスを選ぶ際のポイント
脆弱性診断（セキュリティ診断）を実施する流れ
クラウドサービス（AWS／GCP／Azure）の脆弱性診断（セキュリティ診断）機能
自社に合った脆弱性診断（セキュリティ診断）の選び方
脆弱性診断（セキュリティ診断）に関するよくある質問
まとめ：脆弱性診断（セキュリティ診断）は放置せず継続的に実施することが重要

脆弱性診断（セキュリティ診断）とは

脆弱性診断とは、診断対象の情報システムに潜む脆弱性や設定不備を洗い出し、修正・対策を検討するための判断材料を得る評価プロセスです。診断を依頼する企業や組織は、対象となる情報システムのどこに弱点があるのかを把握し、必要な対策を検討できます。

なお「セキュリティ診断」という言葉は、狭義の脆弱性診断のみを指す場合もあれば、セキュリティ全般の評価活動を広く含めて使われる場合もあります。

本記事では原則として、両者を同じ意味として扱います。

「システムにおける脆弱性全体」の中で、「発生の想定される脆弱性」の中に「仕様や要件としてカバーしている脆弱性」、想定から漏れた「想定外の脆弱性」 — システムにおける脆弱性の分類
（出典：デジタル庁『政府情報システムにおける脆弱性診断導入ガイドライン』）

情報セキュリティ上で対策をとるべき問題がないか診断するもの

総務省では、情報セキュリティ対策を「大切な情報が外部に漏れたり、ウイルスに感染してデータが壊されたり、普段使っているサービスが急に使えなくなったりしないように、必要な対策をすること。」と定義しています。^※1

脆弱性診断は、この対策を行うための「現状把握」の役割を担うものです。

独立行政法人情報処理推進機構（以下、IPA）の『中小企業の情報セキュリティ対策ガイドライン』でも、はじめに「情報セキュリティ6か条」を周知したうえで、「より強固にするための方策」として脆弱性診断の実践が推奨されています。^※2

脆弱性診断はあくまで対策のスタート地点であり、発見した脆弱性を適切に修正していくことが本来の目的だと押さえておきましょう。

脆弱性とは

脆弱性とは「ソフトウェア等におけるセキュリティ上の弱点のことで、セキュリティホールとも呼ばれる」とIPAにより定義づけられています。^※3脆弱性があると、外部からの攻撃や内部不正によって、情報漏えいやサービス停止を招き、法的責任など経営に直結する損害につながりかねません。

脆弱性が発生する原因は主に次のとおりです。

プログラムのバグや実装ミス
設計段階でのセキュリティ要件の漏れ
OSやミドルウェアの設定不備
ID・パスワードや権限の運用ルールの甘さ
サーバ室の施錠やバックアップ管理など、物理・運用面の不備

情報システムにおける脆弱性の発生部位
（出典：デジタル庁『政府情報システムにおける脆弱性診断導入ガイドライン』）

脆弱性診断（セキュリティ診断）の目的と必要性

企業が利用・提供する業務システムやWebサービスには、脆弱性や設定不備など、さまざまな弱点が生じる可能性があります。

脆弱性診断は、診断対象範囲内の弱点を確認し、修正や対策の優先順位を判断するための手段です。診断そのものがリスクを下げるのではなく、発見した脆弱性を修正し、多層的に防御することでリスク低減につながることを押さえておきましょう。

IPAは脆弱性検査の目的を「ソフトウェアやシステムにある脆弱性を低減させること」にあるとしつつも、「利用シーンによって目的が異なる」ことにも言及しています。^※4ここでは代表的な2つの利用シーンを取り上げます。

セキュリティインシデントの発生・被害を低減する

脆弱性診断を実施することによって、脆弱性を悪用したセキュリティインシデントの発生・被害を抑えやすくなります。既知の脆弱性を特定し危険性を把握することで、あらかじめ対策を練られるためです。

IPAは「自社が運用しているシステムが攻撃されるリスクを低減する」効果が期待できると説明しています。また、自社がソフトウェアをリリースする場合、「当該ソフトウェアの脆弱性を狙った攻撃による被害をあらかじめ低減する」効果が期待できることにも言及しています。^※4

では、脆弱性を放置するとどうなるのでしょうか。脆弱性や設定不備が残るシステムが攻撃対象になると、攻撃者がそれらを悪用して侵害を試み、データの改ざんや破壊、機密情報の漏えい、マルウェア感染などを引き起こす可能性があります。

その結果、企業や組織は次のような損害を被る可能性があります。

ステークホルダー（顧客、取引先、株主など）からの信頼低下
システム停止による売上減少
トラブル対応や復旧に必要なリソースやコストの発生
損害賠償や法的責任など、経営に直結する損害

事態を回避するためにも、まずは脆弱性診断を行い、弱点となり得る脆弱性の有無を網羅的に検査することで、取り組むべき対策が可視化され、セキュリティインシデントの予防につながります。

セキュリティ対策のコストを低減する

脆弱性の修正に必要な費用は、問題の内容や発見時期、影響範囲によって異なるため、リリース前後で一概に比較できません。リリース前に脆弱性診断を行えば、診断と修正に必要な期間や費用を、開発計画や予算に組み込みやすくなります。

一方、リリース後に想定外の脆弱性が見つかると、修正が完了するまでサービスを一時的に非公開にしたり、以前のバージョンへ戻したりするなど、緊急対応が必要になる場合があります。その結果、計画外の作業や追加費用が発生する可能性があります。

リリース前の脆弱性診断は、修正費用そのものを削るより、リリース後に想定外の脆弱性が発覚した際に生じる追加対応コストを避けるための備えです。新システムのリリース前や、システム改修時のリリース前に診断しておくことで、想定外の負担を減らせます。

さらに、脆弱性を放置したことで攻撃されてしまった場合は、被害対応、原因調査、顧客対応、再発防止に多くの人員と費用を投じる必要が生じます。これらのコストを低減できる点で、脆弱性診断は有用です。

セキュリティ診断（脆弱性診断・検査）をセキュリティ対策にどう活かす？

ペネトレーションテストとの違い

ここまで脆弱性診断（セキュリティ診断）の目的と必要性を見てきましたが、これと混同されやすいのがペネトレーションテストです。どちらもセキュリティ対策の一環ですが、目的とアプローチに明確な違いがあります。

脆弱性診断は「診断対象範囲内にある設定不備や脆弱性を、あらかじめ定めた診断項目に沿って網羅的に洗い出す」もの、ペネトレーションテストは「現実的な攻撃シナリオを用いて、攻撃者の目的達成の可否を実証する」ものです。

脆弱性診断でいう「網羅的」とは、診断対象として定めた範囲について、設定不備や脆弱性を所定の診断項目に沿って確認することを指します。

システムを構成するサーバやアプリケーションのすべてを調べ尽くす意味ではありません。実際に、どこを診断するかは診断の種別（プラットフォーム診断、ネットワーク診断、Webアプリケーション診断、スマートフォンアプリケーション診断など）によって分かれます。一方、ペネトレーションテストは、現実的な攻撃シナリオを用いること、攻撃者の目的達成の可否を実証すること、の2点を構成要素とするテストです。

両者は優劣を比較するものではなく、確認したい内容や目的に応じて使い分ける、または組み合わせる手法です。

観点	脆弱性診断	ペネトレーションテスト
目的	診断対象範囲内にある設定不備や脆弱性の洗い出し	現実的な攻撃シナリオによる、攻撃者の目的達成可否の実証
範囲	診断対象範囲内を、あらかじめ定めた診断項目に沿って確認する	特定のシナリオ・経路を深く
アウトプット	脆弱性一覧・リスク評価・推奨する対策	検出した問題点・リスク評価・対策提案（目的達成可否の実証を含む）
実施頻度	定期的・継続的に、新システムのリリース前、システム改修時のリリース前	定期的に、または重要システムの変更時に
向いている用途	日常的なリスク管理、リリース前の確認	高度な脅威への耐性評価、重要システムの実戦的な検証

「まず脆弱性診断で全体を可視化し、特に重要なシステムや変化点に対してはペネトレーションテストで深掘りする」という併用が、コストと効果のバランスの取れた進め方です。

脆弱性診断とペネトレーションテストの使い分け

関連サービス

ペネトレーションテストについて

脆弱性診断（セキュリティ診断）の種類

脆弱性診断は診断する対象によって複数の種類に分類されます。診断対象が異なれば、必要なスキル・ツール・所要期間も変わるため、自社で何を診断したいのかを最初に明確にすることが重要です。

診断種別ごとに、実施する内容と、低減できるリスクは次のとおりです。

診断種別	主な診断内容	低減できるリスク
プラットフォーム診断	サーバやネットワーク機器に疑似攻撃の通信を行い、設定やソフトウェアの状態を確認する	不正アクセス、情報漏えい、サービス停止
Webアプリケーション診断	画面遷移時に発生するHTTPリクエストに攻撃シグネチャを含めて送信し、その応答から脆弱性を確認する	情報漏えい、データ改ざん、不正操作
スマートフォンアプリケーション診断	アプリ本体・通信・外部サービス連携を解析し、脆弱性を確認する	重要情報の漏えい、通信内容の盗聴、アプリの不正利用
その他	制御システム・IoT機器・物理環境・組織や人を対象に確認する	制御停止、不正侵入、認証情報の窃取

①プラットフォーム診断

プラットフォーム診断は「サーバやネットワーク機器等に対して行う脆弱性診断」とデジタル庁によって示され、具体的にはファイアウォール、ロードバランサ、リバースプロキシ、仮想化インフラ、サーバOS（ゲストOS）、サーバミドルウェア、VPNなどを診断対象として挙げています。ネットワークスキャンを用いたり、各機器の設定を確認したりして、脆弱性を検知します。

サーバやネットワーク機器は世界中で使用されているため、毎日のように新たな脆弱性が発見され、JVN（Japan Vulnerability Notes）^※5などのサイトに公表されます。このような最新情報の収集や、新たな攻撃の可能性を防ぐため使用していないポートは閉じられているかといったチェックも行います。

脆弱性の種別	概要
不要ポートの解放	ポートスキャンにより通信可能なポートを確認する。結果として、外部からの接続を意図していないオープンポートや、第三者に仕掛けられたバックドア等の不審なサービスが検出される。
脆弱なソフトウェアの利用	上記で検知したオープンポートに接続を試み、サーバから取得したバナー情報に基づき、ポートを待ち受けているOSやミドルウェアの情報を推定する。結果として、既知の脆弱性を含むバージョンのソフトウェアの利用等が検出される。
設定の不備	主にツールに搭載されたシグネチャに基づき、サーバの設定不備を確認する。結果として、推測可能なパスワード（システムの初期パスワード等）や意図しない情報の公開等の問題が検出される。
プロトコル固有の脆弱性	主にツールに搭載されたシグネチャに基づき、プロトコル固有の脆弱性を確認する。結果として、DNS、FTP、SSH、POP、SMTP、TELNET、SSL/TLS等のプロトコルを扱うソフトウェアの脆弱性や、脆弱なアルゴリズムの利用等が検出される。

システムにおける脆弱性の分類
（出典：デジタル社会推進実践ガイドブック DS-221 表 2-1 プラットフォーム診断で検出される脆弱性）

ラックの脆弱性診断サービスでも、診断対象に応じて種類を分類して提供しています。自社のどのシステムを診断すべきか判断に迷う場合は、専門家に相談することで適切な診断範囲を整理できます。

関連サービス

プラットフォーム診断

②Webアプリケーション診断

Webアプリケーションとは「Webブラウザを利用して、Webサーバに接続することで、動作するアプリケーションソフトのこと」と総務省は定義しています。デジタル庁によると、Webアプリケーション診断は、Webアプリケーションやアプリミドルウェアといったソフトウェアの脆弱性を診断することを意味します。対象のWebアプリ（Web APIを含む）に対して疑似的な攻撃のリクエストを行うことにより、情報漏えいやサイト改ざんなどにつながる脆弱性の有無を確認するものです。

近年特に普及が進むアプリケーションはユーザニーズに応えるために複雑化しており、サイバー攻撃の対象になりやすい傾向があります。具体的には以下のような攻撃手法が多く見られます。

SQLインジェクション
OSコマンド・インジェクション
ディレクトリ・トラバーサル
セッション管理の不備
クロスサイト・スクリプティング（XSS）
クロスサイト・リクエスト・フォージェリ（CSRF）
HTTPヘッダ・インジェクション
メールヘッダ・インジェクション
クリックジャッキング
バッファオーバーフロー
アクセス制御や認可制御の欠落

（参考：安全なウェブサイトの作り方 | 情報セキュリティ | IPA 独立行政法人情報処理推進機構）

これらの攻撃の余地がないか確認し、事前に対処するためにWebアプリケーション診断を実施します。

関連サービス

Webアプリケーション診断ハイブリッド

③スマートフォンアプリケーション診断

スマートフォンアプリケーション診断は、AndroidやiOSなどで動作するアプリケーションに、セキュリティ上の問題がないかを確認する診断です。

診断対象にはアプリ本体に加え、アプリとサーバとの間の通信等も含まれます。診断手法にはアプリ本体をツールで自動解析するものや、リバースエンジニアリングを用いるもの、アプリとサーバ間の通信内容に着目し脆弱性を探索するものなどがあります。

スマートフォンアプリにおける脆弱性の発生箇所
（出典：デジタル庁『政府情報システムにおける脆弱性診断導入ガイドライン』）

スマートフォンアプリケーションに迫る脅威とセキュリティ

関連サービス

④その他

このほか、制御システムやIoT機器など、一般的な情報システムとは異なる環境を対象とする脆弱性診断もあります。

また、広義のセキュリティ診断には、サーバ室への入退室管理などの物理環境や、標的型攻撃メール訓練などを通じて組織・従業員の対応状況を確認する評価も含まれます。これらは、情報システムの脆弱性を確認する診断とは対象や手法が異なるため、目的に応じて選ぶ必要があります。

脆弱性診断（セキュリティ診断）の方法

脆弱性診断の実施方法は、「診断の進め方（ツール／手動／併用）」と「診断の経路（リモート／オンサイト）」の2軸で整理すると理解しやすくなります。

進め方の軸では、自動検知ツールを用いる「ツール診断」、専門家が手作業で深掘りする「手動診断」、両者を組み合わせる「併用」があります。経路の軸では、インターネット経由で診断する「リモート診断」と、現地でネットワーク内部から診断する「オンサイト診断」があります。

ツール診断と手動診断は、単純な優劣で選ぶものではありません。診断対象、確認したい脆弱性、システムの重要度、期間や予算などに応じて使い分けます。

Webアプリケーション診断などでは、ツールによる効率的な確認と、専門家による手動確認を組み合わせる方法があります。一方、限定した範囲を短期間で確認する場合などは、ツールを中心としたサービスが選ばれることもあります。

IPAの『安全なウェブサイトの作り方』^※6など、業界標準に準拠することを表明した診断サービスも増えており、選定時の参考になります。それぞれの特徴を順に見ていきましょう。

ツール診断

ツール診断は自動検知ツールなどを用いて、システム全体の脆弱性を診断する方法です。手動では膨大な時間や手間がかかる作業を、短時間かつ低コストで実施できることがメリットです。

一方で標準的な検査項目のメニューに沿ってツールで機械的に検査するため、対象によっては検知できない箇所が発生する可能性もあります。近年はAIで自動検査の範囲を広げた製品も増えました。ツールによって検知できる範囲が変わるため、この点は診断サービスを選ぶうえでの判断材料になります。

ただし、デジタル庁は「診断サービスの選定においては、ツールによる自動的な診断のみでは不十分であり、専門家による手動による診断との併用が不可欠である。また、手動の診断においても、事前に定義された脆弱性を網羅的に検出することに加え、専門家の知見に基づきリスクベースで追加の脆弱性検出を試みるサービスを併用することが必要である」と政府情報システムにおける脆弱性診断導入ガイドラインで指摘しています。

効率の観点では有用であるとしたうえで、ツール診断は仕様に起因する脆弱性全般の検出が難しい、実装上の問題として対象のWebアプリケーションの内部実装に対する深い洞察を要する脆弱性や、一般的な実装の不備による脆弱性においても、一定の制限を迂回しなければ攻撃できないものが見落とされやすいと、同ガイドライン内で追記しています。

手動診断（マニュアル診断）

手動診断（マニュアル診断）はセキュリティの専門家などに依頼し、人の手で脆弱性を診断する方法です。

ツールのように機械的に実施するのではなく人の手や知見を用いて実施するため、様々な顧客のシステム環境の一つひとつに柔軟に対応し、くまなく脆弱性診断が行えることがメリットです。また検査漏れや見落としなどが生じにくいことも特徴とされます。

ただしツール診断と比較すると作業時間やコストが多くかかってしまうため、予算や要件に応じてツール診断との併用も検討すると良いでしょう。

リモート診断

リモート診断はインターネットを経由して遠隔地から対象機器やアプリケーションの脆弱性を診断する方法です。インターネット上に公開されたアプリケーションや、公開セグメント上のサーバなどの脆弱性や通信制限が適切か否かなどを診断します。

リモート診断は次に紹介するオンサイト診断よりもコストを抑えられることがメリットです。しかしインターネット上に公開されていない機器を診断することはできないため、診断対象は制限されます。

オンサイト診断

オンサイト診断は、診断を実施するエンジニアが顧客のオフィスやデータセンターなどへ出向き、内部ネットワークから脆弱性を診断する方法です。インターネット上に公開していない機器を診断する際に用いられることが多く、ネットワーク分離が実施されている環境ではオンサイトでしか診断できないケースもあります。

一方、エンジニアの移動や現地作業が必要になるため、リモート診断よりも費用がかかり、日程調整も必要です。

脆弱性診断（セキュリティ診断）の費用・相場

脆弱性診断の費用は、診断の種類、対象範囲、規模、診断手法、サポート内容などによって異なります。そのため、すべての診断サービスに共通する一律の相場を示すことは困難です。実際の費用は、診断対象や規模、診断項目などによって異なります。

費用を左右する主な要因は、次のとおりです。

診断の種類
プラットフォーム、Webアプリケーション、スマートフォンアプリケーションなど
診断対象の規模
IPアドレス数、サーバ数、画面遷移数、Web APIなどのリクエスト数
診断手法と診断項目
ツール診断のみか、専門家による手動診断を組み合わせるか、どこまでの項目を確認するか
実施経路
リモート診断か、エンジニアの派遣を伴うオンサイト診断か
診断後のサポート
報告会、対策相談、改修後の再診断などが含まれるか

デジタル庁のガイドラインでは、プラットフォーム診断はIPアドレス数、Webアプリケーション診断は診断対象となるリクエスト数などが、費用を見積もる際の主な単位として示されています。^※10

一般に診断対象が増えるほど費用も増える傾向がありますが、価格だけを理由に対象範囲を狭めるのは適切ではありません。例えば決済システムや個人情報を扱うなど情報の重要度のほか、外部への公開状況やシステムの構成・変更箇所などを踏まえ、優先的に確認すべき範囲を決める必要があります。

診断範囲の設定に迷う場合は、システム構成、扱う情報、外部公開の有無、直近の変更内容などを整理し、診断ベンダへ相談しましょう。見積もりの前提と診断対象を明確にすることで、必要な範囲に対して過不足の少ない提案を受けやすくなります。

脆弱性診断（セキュリティ診断）サービスを選ぶ際のポイント

数多くのセキュリティベンダが存在する中で、自社に最適な依頼先を見極めるための比較基準を解説します。

診断の範囲と深度が自社の要件と合うか

ここで確認したいのは、自社が守りたい対象に対して、診断の範囲（どこまで診るか）と深度（どこまで精密に診るか）が見合っているかという点です。

まず、システムの性質によって必要な深度は変わります。決済や個人情報を扱うシステム、複雑な認証・認可を持つWebアプリケーションでは、ツールに加えて専門家が仕様や挙動を確認する精度の高い診断が求められます。一方、重要情報を扱わないコーポレートサイトなどでは、ツールによる網羅的な確認に簡易的な手動確認を組み合わせる程度で足りる場合もあるでしょう。過剰な診断は費用の無駄になり、逆に軽すぎる診断は重要な問題を見逃します。自社のどのシステムに、どの程度の精度が必要かを事前に整理しておくことがポイントです。

範囲については、Webアプリケーション診断であれば、ログイン、決済、個人情報を扱う画面など、守るべき機能が対象に含まれているかを確認します。新規追加・変更された外部公開画面やWeb APIも、対象から漏れていないか確認しましょう。プラットフォーム診断であれば、対象となるIPアドレス、サーバ、ネットワーク機器、ポートの範囲を確認します。

サービス名称が同じでも、診断の対象や項目、精度は異なる場合があるため、見積書や提案書に、対象範囲と診断手法が具体的に記載されているかを確認してください。

専門家による手動診断が含まれているか

ツール診断と手動診断のどちらが含まれるかは、サービスによって異なります。診断対象の重要度に応じて、必要な手法が備わっているかを確認しましょう。

ツールによる自動診断は、あらかじめ定めた診断項目を短期間で効率的に確認できる手段です。一方で、システム固有の仕様や業務ロジックに起因する問題は検出できない場合があり、実際には悪用できない問題を脆弱性として報告する誤検出が生じることもあります。

ツールのみのサービスを選ぶ場合は、検出結果をどの程度精査してもらえるのか、誤検出の確認や問い合わせに対応してもらえるのかを確認しておくと安心です。

診断実績が豊富で信頼できるか

会社の規模や知名度だけでなく、実際の脆弱性診断における過去の実績を確認してください。

同業他社や似たような規模のシステムでの診断実績があるベンダであれば、業界特有の仕様やシステム構成にも明るく、スムーズに検査を進めてもらいやすくなります。

Webサイトの導入事例などをチェックし、自社の要件に近い実績があるかを確認するのも良い方法です。

対策や改善提案までサポートしてくれるか

脆弱性が見つかった後、それをどう直せば良いかという「具体的な解決策」を提示してくれるかが重要です。結果報告だけであったり、専門用語ばかりの難解なレポートを渡されたりしても、開発担当者が理解できなければ対策が止まってしまいます。

検出された問題ごとに、危険度、影響、確認方法、推奨する対策が示されていれば、開発・運用担当者が修正の優先順位を判断しやすくなります。ソースコードを用いたホワイトボックス診断やコードレビューを契約する場合は、問題のある実装箇所について、より具体的な指摘を受けられることがあります。通常のブラックボックス型の脆弱性診断で、ソースコード上の修正箇所まで提示されるとは限りません。

診断はあくまで手段であり、脆弱性を修正してはじめて安全が確保されることを忘れないでください。

確認ポイント	チェックする具体的な内容
範囲と深度	重要な機能（ログイン、決済など）に加え、新規追加・変更された公開画面やAPIが対象に含まれているか
手動診断の有無	ツールだけではカバーできない高度なロジック検査が可能か
実績と信頼性	同じ業界や同規模のシステムでの実績はあるか
サポートの手厚さ	修正方法の具体提示や、改修後の再診断オプションはあるか

脆弱性診断（セキュリティ診断）を実施する流れ

脆弱性診断は、一般に「範囲の明確化」「スケジュール調整・実施」「レポートの確認」「対策の実施」の順で進みます。ただし、具体的な工程は診断の種類やサービス内容によって異なります。

ステップ	実施する主な内容	企業側で準備・対応すること
手順1：範囲の明確化	対象の決定、手法の選定、見積もり	システム構成図や画面一覧の提供
手順2：スケジュール調整・実施	日程の確定、実際の疑似攻撃テスト	テスト環境の提供、アクセス制限の解除
手順3：レポートの確認	診断結果の報告、危険度・対策の共有	報告会の実施、開発チームへの共有
手順4：対策の実施	脆弱性の修正作業、安全性の再確認	プログラム改修作業、再診断の依頼

最初に診断範囲を明確にすることで、依頼側と診断ベンダの認識のずれや、想定外の追加対応が生じる可能性を抑えられます。診断を検証環境と本番環境のどちらで実施するかは、診断目的、環境の再現性、サービスへの影響などを踏まえ、診断ベンダと事前に協議します。

診断後は、報告された危険度に加え、悪用される可能性、影響範囲、システムの重要度などを踏まえて、修正の優先順位を決めます。修正後は、必要に応じて再診断を依頼し、問題が解消されたかを確認しましょう。

クラウドサービス（AWS／GCP／Azure）の脆弱性診断（セキュリティ診断）機能

クラウドサービスの利用が広がるなかで、主要クラウドベンダもセキュリティ診断機能を標準的に提供するようになっています。

クラウド環境を利用する企業にとっては、まずこれらの機能を活用しつつ、外部の専門サービスによる脆弱性診断と組み合わせることが現実的な選択肢となります。

Amazon Web Services（AWS）：「Amazon Inspector」を提供し、ソフトウェア脆弱性や、意図せず外部から到達可能になっているネットワーク構成を検出できます。^※7
Google Cloud：「Security Command Center」により、保有アセット・潜在リスク・実害につながり得るリスクを一元的にモニタリングできます。^※8
Microsoft Azure：「Microsoft Defender for Cloud」が、セキュリティ状態をスコア化して可視化し、構成不備や脅威を継続的に検出します。^※9

これらのクラウドネイティブな機能は、主に「自社管理下のクラウドリソースに対するハイジーン（衛生）管理」に強みがあります。一方で、Webアプリのロジック脆弱性やビジネスインパクトを踏まえた評価には、専門家による脆弱性診断との組み合わせが有効です。

自社に合った脆弱性診断（セキュリティ診断）の選び方

ここまで見てきたとおり、脆弱性診断には複数の種類や方法があり、それぞれにメリット・デメリットがあります。自社にとって最適な診断方法を決めるためには、次の5つの観点を順に整理することをお勧めします。

1.診断対象を特定する
（例：Webサイト、社内ネットワーク、業務アプリ、IoT 等）
2.診断目的を明確化する
（例：リリース前の安全性確認、年次の網羅的チェック、特定脅威への耐性評価等）
3.求めるアウトプットを定義する
（例：脆弱性一覧、リスク評価書、経営層向けレポート、是正計画案等）
4.予算・期間を整理する
5.ツール／手動／併用、リモート／オンサイトの組み合わせを選定する

とはいえ、これらを正しく判断するには専門知識が求められ、社内だけで完結させるのは難しい場面も多いでしょう。判断に迷う場合は、診断実績の豊富な専門ベンダへ早めに相談することが結果的に時間とコストの削減につながります。

ラックの脆弱性診断（セキュリティ診断）サービス

ラックは、お客様の現状の課題やセキュリティ要件、予算を踏まえ最適な脆弱性診断の組み合わせを提案します。診断種別や手法を柔軟に組み合わせることで、安全性に関わる診断を漏れなく、かつ環境に合わせて柔軟に実施することが可能です。

1995年にセキュリティ診断サービスの提供を開始して以来、官公庁・金融・通信・製造などあらゆる業種で診断実績を積み重ねています。

セキュリティ監視・運用サービスの拠点であるJSOC（Japan Security Operation Center）、自社研究開発部門の「サイバー・グリッド・ジャパン」などで最新の脅威にも対応できる高度な技術とノウハウを蓄積しています。

具体的なサービスの流れや費用については、『ラックのセキュリティ診断（脆弱性診断・検査）について』ページでご確認ください。

脆弱性診断（セキュリティ診断）に関するよくある質問

脆弱性診断を検討する際に生じやすい疑問について、頻度・期間・無料ツールの3つに分けて回答します。

脆弱性診断（セキュリティ診断）はどのくらいの頻度で実施すべきですか？

脆弱性診断の頻度に、すべてのシステム共通の基準はありません。システムの重要度や公開状況、変更頻度、扱う情報などを踏まえて決めます。

実際にラックへ寄せられる依頼で多いのは、「機能追加や改修時」と「年に1回の定期診断」です。改修時の診断は公開前の安全性確認、年1回の定期診断は監査対応やセキュリティ品質の維持を主な目的としています。加えて、外部公開範囲を変更したときも、新たな脆弱性が生じやすいため診断を検討しましょう。

なお、定期診断だけで新たに公表される脆弱性へすべて対応できるわけではありません。脆弱性情報の収集や修正プログラムの適用を含む、継続的な脆弱性管理が重要です。

脆弱性診断（セキュリティ診断）にかかる期間はどのくらいですか？

期間は診断の種類や対象範囲、手法によって異なりますが、目安として、ツール中心の簡易な診断なら数営業日、手動診断を含む本格的な診断なら数週間程度が一般的です。実際にラックのWebアプリケーション診断では、ツールによる診断で最短2営業日、手動診断を組み合わせたメニューで最短4営業日から対応しています。

対象となるIPアドレス数や画面遷移数、Web APIなどのリクエスト数が多いほど、診断や結果の精査にかかる期間は長くなりがちです。手動で確認する範囲や、オンサイト作業の有無も影響します。

見積もり時には、事前準備から報告書の提出までにかかる期間を確認しましょう。問題が見つかった場合に備え、修正と再診断の期間も含めてスケジュールを組むことが大切です。

無料ツールだけで脆弱性診断（セキュリティ診断）は十分ですか？

無料ツールだけで十分かどうかは、診断の目的や対象システムによって異なります。無料ツールは、対象を限定したセルフチェックや、既知の脆弱性を効率的に確認する用途では役立ちます。一方、ツールごとに診断対象や検出項目が異なり、すべての脆弱性を確認できるわけではありません。重要なシステムでは、無料か有料かだけで判断せず、必要な診断項目を確認できるか、結果を適切に評価できる体制があるかを検討しましょう。

ツール診断は、あらかじめ設定された診断項目を効率的に確認できます。一方、Webアプリケーション固有の認証・認可、複数の操作を組み合わせた業務ロジック、特殊な利用手順に起因する問題などは、検出できない場合があります。

個人情報や決済情報を扱うシステム、複雑な認証・認可を備えるWebアプリケーションなどでは、ツールによる診断結果の精査や、専門家による手動確認を組み合わせる方法があります。ツールを自社で使用する場合は、利用規約や対象システムへの診断権限を確認し、診断によるサービスへの影響も考慮したうえで実施しましょう。