インターネットセキュリティ診断の選び方と進め方

インターネットセキュリティ診断（脆弱性診断）を検討しているものの、自社のWebサイトやクラウド、業務システムのどこまでを対象にし、ツール診断・手動診断・ペネトレーションテストをどう選ぶべきか迷いやすい状況があります。判断を先送りにすると、OS更新の未実施など既知の脆弱性が残り、2017年3月に公表された「MS17-010」のように後から説明負担が増える形でリスクが顕在化し得ます。目的と範囲、診断メニューの違い、委託先選定の確認軸まで整理できると、実施タイミングと定期運用の設計に落とし込みやすくなります。以下では、診断方式の判断材料として対象範囲と進め方を示します。

診断の位置付けを知る

インターネットセキュリティ診断とは

インターネットセキュリティ診断（脆弱性診断）は、インターネット経由で到達できる自社のWebサイトや業務システムについて、ネットワーク／OS／ミドルウェア／アプリケーションの観点から脆弱性や設定不備を検査し、診断結果を評価して是正の優先順位まで落とし込む取り組みです。実務では、社内だけで完結させず、第三者である外部専門組織によるセキュリティ第三者チェックとして実施することで、属人的な見落としを減らし、対外的な説明可能性（取引先・監査対応）を高めやすくなります。

で示されている「脆弱性診断士」は、脆弱性の診断と評価を担当し、セキュアプログラミング（安全な実装）ができているか、設定が適切かを検査する役割を担います。これは「穴探し」に留まらず、どの指摘が事業リスクに直結するかを評価して、修正計画に接続することがポイントです。

脆弱性を放置するリスク

脆弱性や設定不備を未修正のまま放置すると、サイバー攻撃だけでなく、内部不正・紛失・外出先業務・シャドーIT・退職社員・SNS経由など、複数の経路で情報漏えいリスクが顕在化しやすくなります。特に「侵入口」はWebアプリの欠陥に限らず、OSの未更新、VPN機器の設定不備、クラウド共有設定の誤りといった運用面の穴から生じることが多いです。

2017年3月にMicrosoft社がセキュリティ更新プログラム「MS17-010」として公表した脆弱性情報が、その後も未更新環境で悪用されている旨が示されており、OSアップデートの未実施が攻撃余地を残す現実があります。こうした「既知の脆弱性の放置」は、事故発生時に「適切な注意を尽くしていない」と評価されやすく、経営上・コンプライアンス上の説明負担も増えます。

また、クラウド利用では「クラウド事業者側の問題」ではなく、利用者側の設定ミスで漏えいが起き得る点が重要です。にあるとおり、クラウドストレージの公開権限を誤り、機密が公開状態になってインターネットから閲覧・ダウンロード可能になるケースや、業務系クラウドの共有設定が非公開になっておらず、ゲスト等の簡易アカウントで意図せず閲覧できるケースが典型です。

脆弱性診断の対象を整理する

Webとアプリケーションの診断対象

Webとアプリケーションの診断は、不特定多数がアクセスするWebサイト、会員制サービス、業務システム、スマートフォンアプリ、公開APIなど「ユーザー入力・認証認可・データ処理」が集中する層を対象にします。ここは個人情報・取引情報に直結しやすく、アプリケーションの欠陥がそのまま漏えいや改ざんにつながるため、診断対象の中心になります。

加えてが示すとおり、Webサイト対策としてはサイトのSSL化、プラットフォームやWebアプリの最新化、CMS利用時のCMS最新化、WAF導入、管理アカウントとパスワードの複雑化、ログ取得と監視といった論点が並びます。脆弱性診断では、これらが「設計・実装・設定」として実装されているかを、画面・API・管理画面等の単位で確認します。

ネットワークとクラウドの診断対象

ネットワーク／インフラ層の診断対象は、OS、ミドルウェア、ルーターやファイアウォール、UTM、VPN機器、クラウド基盤の設定などです。アプリが堅牢でも、境界機器やクラウド設定に弱点があれば、侵入・横展開・データ持ち出しが成立します。

ではネットワーク対策として、Firewall/UTMの導入、ルータ・Firewall・UTM・VPN機器のファームバージョンアップ、VPN機器のID/パスワードの複雑化や多要素認証、ログ取得と閾値設定、NDR導入といった論点が列挙されています。診断では、外部公開されているサーバや通信機器の到達性を前提に、不要ポート、既知脆弱性、設定不備、ログ監視の欠落などを確認します。

クラウドは「設定上の不備を作らない」ことが中心課題です。クラウドストレージ公開権限のミス、共有設定の誤り、URLリンクが分かれば第三者でも閲覧できる状態などは、人的ミスとして起き得る前提で、適宜監査する運用が求められます。

公開資産が把握できていない会社はどこから診断対象に含めるべきか

公開資産が棚卸しできていない場合は、最初に「外部から見える母集団」を確定しないと、診断範囲が空洞化します。にもあるとおり、まずはネットワーク環境にどの端末が存在し、どのIPアドレスが稼働しているのかを一覧化して、脆弱性がある端末（PC、サーバ）がどれだけあるかを探るアプローチが重要です。

効率化の観点では、で例示されている正規のIPスキャニングツールであるAdvanced IP Scanner（アドバンストIPスキャナー）等を用いて稼働IPを把握し、ポートスキャン等で利用サービスを洗い出したうえで、対象ごとに診断計画へ落とし込みます。ここで重要なのは、発見した資産の「所有部署・責任者」を確定し、不要なら閉鎖、必要なら診断対象として登録する運用に接続することです。

診断手法の違いを比べる

ツール診断と手動診断の違い

脆弱性診断は、大きくツールによる自動化と、専門家による手動検証に分かれます。でも「ツールで対応できるものがあればツール対応をするのも効果が高い」とされており、作業量の削減や定常運用に向きます。

一方で、手動診断は、仕様や権限設計、業務ロジックを踏まえて疑似攻撃し、誤検知を潰しながら「実害に直結する不備」を特定するのが強みです。の「脆弱性診断士」の説明のとおり、ネットワーク、OS、ミドルウェア、アプリが適切に実装・設定されているか検査し、結果を評価する役割があり、手動診断はこの評価プロセスと相性が良いです。

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

脆弱性診断は「弱点の洗い出しと評価」が中心ですが、ペネトレーション（侵入）テストは、のとおり攻撃者の視点で侵入できるか試すことで、防御策の有効性をチェックする手法です。結果として、同じ対象でも「網羅性」重視か「侵入シナリオ」重視かで設計が変わります。

ペネトレーションテストは業務影響を考慮する必要があり、診断範囲設定を中心に管理者との調整や疑似攻撃の事前準備が必要で、依頼から完了まで数カ月かかるのが一般的で、即時実施できるものではないとされています。このため、まず脆弱性診断で基本的な穴（既知脆弱性や設定不備）を潰し、そのうえで侵入耐性を評価する順序が実務的です。

Web公開前・大規模改修後・事故後で診断メニューをどう切り替えるか

診断メニューは、開発フェーズとインシデント状況で切り替えるべきです。にあるとおり、ツールによる自動化は作業量削減に効く一方、手動検証は深い仕様不備に効くため、目的を揃えることが重要です。

また、のネットワーク対策にあるように、事故局面ではVPN機器のID/パスワード強度、多要素認証、ファーム更新、ログ取得と閾値設定といった「侵入口になりやすい論点」を並行して点検し、診断結果の是正を運用へ戻すことが重要です。

セキュリティ診断の進め方

事前整理から診断実施までの流れ

セキュリティ診断は、範囲定義と事前調整が品質とスピードを左右します。ペネトレーションテストは範囲設定や事前準備が必要とされており、脆弱性診断でも同様に「どこまで・何を・どの条件で」実施するかを合意することが前提になります。

診断結果の読み方と是正対応

診断報告書は「指摘の列挙」ではなく、是正に落とすための材料として読み解く必要があります。の「脆弱性診断士」が診断結果の評価を担うとされているとおり、技術的な深刻度だけでなく、業務影響・悪用容易性・露出範囲（外部公開か、認証後か）を踏まえて優先順位を決めます。

また、誤検知の扱いは実務負荷に直結します。ではトリアージ（選別）データの可視化ツール例が示されていますが、ここで重要なのは「本当に修正すべきもの」を潰し込み、改修計画に載せることです。

修正後は、再発防止の観点で「修正したはず」の確認が重要です。再診断（修正確認）は、ツールでの再スキャンに加え、重要指摘は手動で再現不能になっているかを確認し、運用（ログ監視、閾値設定、EDRやSOC等）へ戻します。

情シス・開発・法務で事前にそろえる資料は何か

部門横断で必要資料を揃えると、範囲外対応ややり直しを減らせます。技術面は情シス・開発が中心ですが、契約・許諾・責任分界は法務が支える構図になります。

価格と委託先を見極める

セキュリティ診断の価格とコスト要因

費用は、対象範囲（外部公開サーバ／通信機器／Web／クラウド）、手法（ツール／手動）、認証有無、環境数などで変動します。ここで注意すべきは、が示す「第三者チェック」の観点です。外部専門組織に依頼する場合、単なるツール実行費だけでなく、診断結果の評価・説明・再診断といった工数が費用に反映されます。

また、の対策一覧にあるように、対象はWeb（SSL化、CMS最新化、WAF等）だけでなく、ネットワーク（Firewall/UTM、VPNの多要素認証、ファーム更新）やクラウド（設定不備の監査、SSO、CASB/SASE等）まで広がります。見積もり時点で「どの層まで含めるか」を明確にしないと、後から範囲追加になりやすいです。

複数の事業者について「無償」や受付時間（例：平日9:00～18:00、24時間等）と「要事前相談／要事前契約」などの条件が一覧化されています。これは一般に、初期相談や窓口対応は無償でも、個別環境の診断そのものは別途見積もりになることが多いため、無償の範囲（相談・一次切り分け）と有償の範囲（診断・報告・再診断）を分けて確認するのが安全です。

診断サービス選定の確認軸

選定は価格だけでなく、診断の網羅性・報告書の使いやすさ・運用への接続で判断します。にあるとおり、脆弱性診断士はネットワーク、OS、ミドルウェア、アプリの検査と評価を担うため、委託先にも「検査」だけでなく「評価と是正支援」ができる体制があるかを確認すると実務上の失敗が減ります。

安い見積もりで起きやすい範囲外対応の追加費用と失敗パターン

安い見積もりの失敗は「範囲の狭さ」と「評価の浅さ」が原因になりがちです。にもあるとおり、クラウドは利用者側の設定不備で漏えいが起き得るため、価格だけで選ぶと、クラウド共有設定やゲストアクセスの監査が対象外になり、重大リスクが残ることがあります。

見積もり段階で、対象層（Web／ネットワーク／クラウド）、認証要否、再診断の回数、成果物の粒度（評価・優先順位付けまで含むか）を契約条項として具体化することが重要です。

定期診断と基準を押さえる

定期的な脆弱性診断の実施頻度

定期診断は、脆弱性の新規発見と設定変更に追随するために必要です。OSを最新の状態にする、期限切れOSは見直す、ウイルス対策のパターンファイル最新化、EDRとSOC活用、ログ取得と閾値設定、ランサムウェア対策用バックアップ（オフライン／クラウド）など、運用で継続的に手当てすべき論点が列挙されています。診断は、これらの対策が「実装・設定・運用」になっているかを定期的に点検する機会になります。

頻度は「年1回」などの固定ではなく、公開範囲と変更頻度で決めるのが安全です。たとえば、外部公開範囲が広く、VPN機器やクラウド設定変更が多い場合は、定常スキャン（ツール）と、重要変更時の手動診断を組み合わせる設計が現実的です。

国内ガイドラインでの位置付け

国内ガイドラインでも、脆弱性対策と継続的点検は重要視されています。内部不正や情報漏えい（紛失、外出先業務、シャドーIT、退職社員、SNS経由）といった論点が並び、サイバー攻撃対策だけでなく、組織的・人的リスクも含めて網羅的にチェックする重要性が示されています。

そのため、脆弱性診断を「年次イベント」にせず、Web・ネットワーク・クラウドの技術点検に加え、ログ取得や監視の運用、ID管理（SSO等）、クラウド共有の監査といった統制面に接続して説明できる形にしておくと、ガイドライン対応や取引先説明に耐えやすくなります。

OWASPなど基準対応の見方

OWASP Top 10やASVSのような基準は、アプリケーション層の代表的なリスクを体系化したものとして有用ですが、実務では「基準に書いてあるか」だけでなく、にあるようなネットワーク／OS／ミドルウェア／クラウド設定まで含めた第三者チェックになっているかを合わせて確認することが重要です。

の「脆弱性診断士」の任用前提スキルとして、OS・ネットワーク・アプリ・データベースの脆弱性知識、パケットレベル解析能力、ペネトレーションテストやツール知識などが挙げられています。委託先を評価する際は、こうしたスキルセットに裏付けられた診断設計（どの層をどう検査し、結果をどう評価するか）が提示されているかを確認すると、基準準拠が形骸化しにくくなります。

よくある質問

セキュリティ診断と脆弱性診断には違いがありますか？

セキュリティ診断は広い概念で、技術的な脆弱性の検査だけでなく、人的・組織的リスクの点検まで含めて扱われることがあります。にも、サイバー被害だけでなく、内部からの情報漏えいや組織的・人的なセキュリティリスクを回避する意味で、会社組織を網羅的にチェックする全体的な診断の重要性が示されています。

一方、脆弱性診断は、ネットワーク／OS／ミドルウェア／アプリケーションやクラウド設定の不備など、技術的な弱点を検査・評価して是正につなげる手法として整理すると、実務上のスコープが明確になります。

自社でツール診断を行うのはどこまで有効ですか？

自社でのツール診断は、のとおりツールによる自動化で作業量を削減でき、短サイクルの一次スクリーニングに有効です。たとえば、稼働IPの把握やポートの洗い出し、既知脆弱性パターンの検知などはツールで効率化しやすい領域です。

ただし、誤検知のトリアージや、認証・認可や業務ロジックの欠陥の評価は、人の判断が不可欠になりやすいです。の「脆弱性診断士」が診断結果の評価を担うとされているとおり、重要システムは外部の第三者チェック（専門組織）と併用し、評価と是正計画までを一連で回すのが安全です。

診断の際にサービス停止が必要になることはありますか？

原則として、診断は稼働中のシステムに疑似アクセスして挙動を確認するため、必ずしも全面停止が前提ではありません。ただし、がペネトレーションテストの注意点として「業務への影響を考慮する必要がある」としているとおり、疑似攻撃やスキャンは負荷や誤検知アラートを誘発することがあります。

そのため、診断条件（時間帯、負荷制限、一次停止手順）を事前合意し、ログ取得と閾値設定など監視体制を整えたうえで実施するのが実務的です。

診断対象から外してよいシステムはありますか？

インターネットに直接・間接に接続される限り、完全に除外してよい領域は原則ないと考えるのが安全です。にもあるとおり、まずは侵入された環境で「どれくらいの端末が存在するか」「どのIPが稼働しているか」を把握して一覧化することが重要で、放置資産や未把握資産があるほど診断の抜け漏れが増えます。

一方で、優先順位付けは可能です。外部公開範囲、境界機器（VPN等）の有無、クラウド共有設定の有無、ログ取得と閾値設定の整備状況など、にあるリスク要因を軸に、ツール診断で広く薄く点検する領域と、手動診断で深掘りする領域を分けて設計するのが現実的です。

インターネットセキュリティ診断への対応で次にすべきこと

インターネットセキュリティ診断（脆弱性診断）は、Web／ネットワーク／クラウドまで対象を分解し、ツール診断・手動診断・必要に応じたペネトレーションテストを目的別に組み合わせることで、是正の優先順位付けに接続しやすくなります。既知の脆弱性を残したままにすると、2017年3月に公表された「MS17-010」のように、後から「更新・点検ができていたか」を問われる局面で説明負担が増え得ます。判断の軸は、外部公開範囲の棚卸し（稼働IP・公開機器・クラウド共有設定）と、報告書で「再現手順・影響範囲・前提条件・暫定緩和策」が読み取れるかに置くのが実務的です。次のアクションとしては、まず対象資産の母集団と責任者を確定し、診断の許諾範囲や成果物の扱いを法務とすり合わせたうえで、第三者チェックとしての体制と評価・是正支援まで含む委託先かを確認します。個別環境の要件や契約条件は事情で変わるため、最終判断は情シス・開発・法務と、必要に応じて外部専門組織へ相談して進めるのが安全です。

Baseconnect株式会社
サイト運営会社

本メディアは、「企業が経営リスクを正しく知り、素早く動けるように」という想いから、Baseconnect株式会社が運営しています。

当社は、日本最大級の法人データベース「Musubu」において国内1200万件超の企業情報を掲げ、企業の変化の兆しを捉える情報基盤を整備しています。

加えて、与信管理・コンプライアンスチェック・法人確認を支援する「Riskdog」では、年間20億件のリスク情報をAI処理、日々4000以上のニュース媒体を自動取得、1.8億件のデータベース等を活用し、取引先の倒産・不正等の兆候の早期把握を支援しています。

運営会社情報ページへ