プラットフォーム診断とは｜対象・費用・進め方を判断できる

プラットフォーム診断（プラットフォーム脆弱性診断）を検討する場面では、Webアプリケーション診断やペネトレーションテストとの役割分担が曖昧なまま、公開資産のどこに手を付けるべきか判断に迷いがちです。対象や進め方を誤ると、VPN等の境界装置やクラウドの設定不備といった「入口・出口」の弱点が残り、パッチ適用や設定是正の優先順位が定まらないまま対応が後手になります。特にペネトレーションテストは依頼から完了まで数カ月かかることがあるため、短期で回すべき点検と中長期で実証すべき検証を分けて考える必要があります。以下では、プラットフォーム診断の判断材料として対象範囲・関連診断との違い・実施の進め方を示します。

プラットフォーム診断とは

診断対象と脆弱性診断の範囲

プラットフォーム診断（プラットフォーム脆弱性診断）は、サーバやネットワーク機器といった基盤（OS・ミドルウェア・ネットワーク）の弱点を洗い出し、侵入の足がかりを減らすための診断です。アプリケーション以前に、土台であるプラットフォーム層に欠陥があると、アプリ側でどれだけ対策していても迂回され得るため、基盤の健全性を独立して確認します。

診断の中心は「既知の脆弱性があるか」だけではなく、設定不備や運用上の穴まで含めて現実的な侵入経路を潰す点にあります。攻撃者は、危険性が高い脆弱性情報が出た直後に検証・攻撃へ進みやすい一方、利用者側はパッチ適用を業務影響の懸念から先送りしがちで、結果として脆弱性が放置されやすいという前提に立ってスコープを組みます。

また、運用面の観点として、侵害時に痕跡が残るポイント（ログ）も「診断で見落としがちな弱点」になり得ます。例えばネットワーク機器ログでは、ファイアウォール／プロキシは出口として「通信先」「不審通信を発した接続元IPアドレス」、DNSは出口として「FQDNの名前解決」、VPNは入口として「接続元IPアドレス」「VPNアカウントの利用状況」を確認する整理が示されています。診断は“欠陥の列挙”で終わらせず、監視・検知の前提（ログが取れる／追える）も含めて基盤の弱点を可視化するのが実務的です。

必要性が高まるリスクと導入目的

プラットフォーム診断の必要性が高まる背景には、ランサムウェア等の攻撃増加だけでなく、攻撃者の行動が「公開資産の穴を見つけたら即座に試す」前提であることがあります。危険度が高い脆弱性が公表されると、攻撃側はすぐ検証し、使えると判断すれば攻撃に踏み込みます。一方で防御側は、パッチ適用が業務不具合を起こす懸念から更新を見送る、重要性を認識していない、といった理由で脆弱性が残りやすいとされています。

導入目的は「見つける」だけではなく、診断結果をもとに優先順位付けと是正計画に落とすことです。特に外部からアクセスするためのネットワーク機器（VPN装置など）は侵入の糸口になりやすく、脆弱性管理の観点で重点対象として扱うべきだと整理されています。

診断対象と診断内容

サーバとネットワーク機器の診断対象

サーバとネットワーク機器に対するプラットフォーム診断では、外部・内部から通信を受け付ける基盤機器の「存在する弱点」と「弱点が残る運用」を点検します。診断は脆弱性スキャナによる検出だけでなく、境界機器や認証の設定が攻撃者に悪用され得る形になっていないか、という観点が重要です。

参照情報では、ネットワーク機器の設定確認として、ルーター／ファイアウォール／VPN機器の設定が変更されていないかを確認し、攻撃者が設定変更を行う目的として次が挙げられています。

このため診断・点検では、機器の設定が想定どおりか（意図しない例外ルールがないか）に加え、変更痕跡と復旧方針まで含めて整理します。不審な設定変更が見つかった場合はバックアップから戻し、戻せない／バックアップの安全性が担保できない場合は初期化を検討する、といった対応方針が示されています。VPN機器で不審な設定変更や不審アカウント追加がある場合は、ファームウェア脆弱性悪用の可能性もあるため、バージョン確認と必要なアップデート、即時アップデートが難しければ一時的な機能停止の検討まで含めます。

また「スキャン」は、攻撃者が行う存在確認・弱点探索・侵入未遂・マルウェア感染未遂・ブルートフォース未遂などを含むと整理されています。診断を設計する際は、監視側が「スキャン」を誤検知しないようにするだけでなく、スキャンと実侵害の境界が曖昧になり得る前提で、ログと遮断・通報の運用もセットで見直します。

クラウド環境の構成と診断の考え方

クラウド環境のプラットフォーム診断は、物理機器の安全性ではなく、利用者側の構成・権限・公開設定に起因するリスクを中心に扱います。特に参照情報では、クラウドサービス利用時の情報漏えいは「サービス側の問題」ではなく利用者側のセキュリティの問題（設定不備・人的ミス）によって生じることがある、と明示されています。

このためクラウド診断では、OSやミドルウェアのパッチ適用状況に加え、IAM（権限管理）の過剰付与、ストレージ公開範囲、セキュリティグループ等の通信制御が「最小権限・最小公開」になっているかを精査します。人的ミスが起きる前提で、適宜監査（定期的な棚卸し・設定レビュー）を組み込む考え方が実務に合致します。

クラウド責任共有モデルで切り分ける、診断対象になる設定と対象外になりやすい領域

クラウド責任共有モデルでは、診断対象は「利用者が管理責任を負うレイヤー」に切り分けて設計します。物理データセンターやハードウェア、基盤サービスの一部はクラウド事業者側の責任範囲になりやすい一方、利用者側は構成・権限・公開範囲の責任を負うため、診断の主戦場になります。

診断の実務では、この分界を前提に「設定上の不備を作らない」ためのチェックリスト化と、定期監査の運用設計まで落とし込むことがポイントです。

診断方法と関連診断の違い

Webアプリケーション診断との違い

プラットフォーム診断とWebアプリケーション診断は、主に検査する層が異なります。プラットフォーム診断はネットワーク・OS・ミドルウェアといった土台の弱点を対象にし、Webアプリケーション診断はアプリ固有の実装欠陥（入力処理・認可・セッション管理など）を対象にします。

また、実務で診断を担う人材像として、参照情報では「脆弱性診断士」はネットワーク、OS、ミドルウェア、アプリケーションがセキュアに作られているかを検査し、診断結果の評価も行う、と整理されています。つまり両者は分断された別世界ではなく、診断結果の評価（どこを優先して直すか）では横断的な理解が必要です。

プラットフォーム診断とWebアプリケーション診断は、どちらか一方で十分という関係ではなく、担当分けや外部委託も含めて、両方の結果を突き合わせて対策の優先度を決めるのが現実的です。

ペネトレーションテストとの役割分担

プラットフォーム診断は、既知の脆弱性や設定不備を広く洗い出す「網羅的な点検」に寄ります。一方、ペネトレーションテスト（侵入テスト）は、攻撃者視点で疑似攻撃を行い「実際に侵入できるか」「どの程度の業務影響が出るか」を検証する手法です。

参照情報でも、ペネトレーションテストは自組織の弱点を把握するシンプルで効率的な方法である一方、業務影響の考慮や範囲設定の調整、事前準備が必要で、依頼から完了まで数カ月かかることがある点が注意事項として示されています。したがって、短いサイクルで全体の衛生状態を上げる用途はプラットフォーム診断、重要拠点の耐性を実証する用途はペネトレーションテスト、のように目的を分けるのが適切です。

公開資産が多い会社はどこまでをプラットフォーム診断に含め、どこからASMやペネトレーションテストに分けるか

公開資産が多い場合、プラットフォーム診断だけで全体最適を狙うと、そもそもの資産把握漏れや例外設定の取りこぼしが起きやすくなります。参照情報でも、攻撃者は脆弱性が放置されている現実を前提に行動し、入口になりやすいネットワーク機器（VPN等）を狙うこと、また「システム管理者が把握していない外部から内部に接続可能な経路（VPNなど）が存在しないか確認し、存在した場合はログで痕跡確認し、痕跡有無に関わらず即時遮断が望ましい」といった観点が示されています。

この前提に立つと、役割分担は「棚卸し（ASM）」「広い衛生点検（プラットフォーム診断）」「重要拠点の実証（ペネトレーションテスト）」に分けるのが合理的です。

プラットフォーム診断の進め方

事前準備から報告書提出までの流れ

プラットフォーム診断は、計画と合意形成が品質と安全性を左右します。稼働中の本番環境にスキャン等を行うため、事前準備でスコープ・実施条件・緊急時判断を固めてから実施し、結果を評価して是正計画に落とします。

特にVPN機器等の境界装置は、脆弱性だけでなく不審な設定変更や不審アカウント追加が侵害の兆候になり得るため、診断計画に「設定バックアップの有無」「戻せない場合の初期化方針」まで含めておくと、実行性が上がります。

報告書の見方と対策の優先順位

報告書は、単に検出事項を並べた一覧ではなく、改修の順序を決めるための材料として読みます。特に「業務影響が怖いからパッチを当てない」という状況があると、攻撃者にとって成功率が高い前提になってしまうため、優先順位付けは“後回しの合理化”ではなく“先に潰すものを決める”作業として扱います。

ここでの「専門語補足」として、CVSS（共通脆弱性評価システム）は脆弱性の深刻度を比較する枠組みですが、実務では到達可能性（外部公開か／認証要否）と資産重要度（重要データがあるか）を重ねて判断するのが現実的です。

診断前に社内でそろえる資料は何か｜IP一覧・構成図・変更予定・停止可否の整理手順

診断前にそろえる資料は、スコープ漏れや誤スキャンを防ぐためだけでなく、診断後の是正を進めるための「意思決定の材料」でもあります。特に外部から内部に接続可能な経路（VPNなど）を管理者が把握していない状態は重大なリスクになり得るため、経路の棚卸しも資料化します。

ログ管理の仕組みとして、参照情報ではZabbix等を用いたログ管理システムが有名とされていますが、ここでは製品選定よりも「必要なログが欠落していないか」を先に点検するのが重要です。

診断でつまずきやすい会社の共通点｜資産台帳不足・窓口不在・例外設定の放置

プラットフォーム診断が進まない組織では、診断技術以前に「前提情報と責任体制」が欠けていることが多いです。参照情報でも、脆弱性情報の収集やパッチ適用を後回しにしがちで、それが攻撃者の的になり得ること、またネットワーク機器が侵入の糸口になりやすいことが指摘されています。

こうした前提課題を潰すことが、診断結果を“報告書で終わらせない”ための実務上の近道です。

費用と選定の判断軸

費用構成と診断期間の目安

費用と期間は、対象資産の数だけでなく、手動精査の深さ、内部からの検証有無、報告会・再診断の範囲で大きく変わります。ただし参照情報で明示された数値の根拠はないため、ここでは金額の断定は避け、見積条件として何が効くかを具体化します。

参照情報では、ペネトレーションテストは調整・事前準備を含め、依頼から完了まで数カ月かかり即時実施できない場合があるとされています。プラットフォーム診断は一般にペネトレーションテストより短期で回しやすいものの、境界装置や重要拠点で手動確認を厚くすると、関係者調整や検証工数が増える点は同様です。

費用を抑えるスコープ設計の考え方

費用を抑えるには、機器を均等に扱うのではなく、攻撃者の“入口になりやすい場所”と、被害が大きい資産に絞って段階化します。参照情報でも、外部からアクセスするためのネットワーク機器が侵入の糸口になりやすいこと、またVPN機器では不審設定変更や不審アカウント追加があれば脆弱性悪用の可能性があるため、ファームウェアバージョン確認やアップデート、即時アップデートできない場合の一時停止検討まで必要になり得ることが示されています。

このとき、予備機のアップデート漏れが侵入口になり得るという指摘も踏まえ、段階設計でも「切替に使う機器」は軽視しない方針にします。

サービス選定で見る基準と提供形態

サービス選定では、対象技術への対応力だけでなく、「結果の評価」と「運用への落とし込み」まで支援できるかが差になります。参照情報の脆弱性診断士の整理では、診断だけでなく診断結果の評価も担い、パケットレベル解析、ペネトレーションテストやツールの知識、脅威情報の知識などが求められています。これは、単にスキャナ結果を納品するだけでは実務の意思決定に足りないことを示唆します。

見積もり比較で金額差が出る内訳｜対象台数・ポート範囲・手動確認の有無をどう読むか

見積差は、診断の“深さ”をどこまで含めるかで生じます。参照情報でも、脆弱性情報の収集→技術調査→影響範囲特定→原因除去または緩和策の確定、という一連の「脆弱性分析」作業が示されており、ここまで支援するかどうかで工数は大きく変わります。

内訳を揃えて比較することで、「安いが意思決定に足りない納品」や「必要な深度に届かないスコープ」を避けられます。

ガイドラインとの関係

政府ガイドラインと脆弱性診断の位置づけ

政府や公的機関のガイドラインは、個別ツール名よりも、体制・運用・継続改善（PDCA）として脆弱性管理を求める傾向があります。参照情報でも「脆弱性管理状況の把握」として、機器やOS等に脆弱性がないか、管理する仕組みが整っているかを確認し、脆弱性が判明したらできるだけ早くパッチ適用や緩和策を実施することが示されています。

その意味で、プラットフォーム診断は単発のイベントではなく、資産管理で整理したIT資産に対して脆弱性情報収集と対応を回す運用（脆弱性管理）を、客観的に点検する手段として位置づけるのが実務的です。特に、外部からアクセスするネットワーク機器が侵入の糸口になりやすいという指摘を踏まえると、境界領域を中心に診断を計画し、継続的な管理に接続することがガイドライン的要請に沿います。

情報セキュリティ基準を確認する観点

情報セキュリティ基準を確認する際は、単に「基準に合っているか」ではなく、運用で崩れやすいポイント（設定ミス、更新先送り、例外設定の残存）を基準と突き合わせて点検します。参照情報には、クラウドでは利用者側の設定不備が情報漏えいを引き起こすこと、また人的ミスが起きる前提で適宜監査していくのがよいことが示されています。

PCI DSS等の特定規格に関する頻度要件など、参照情報に根拠のない数値はここでは断定せず、採用する基準に応じて診断頻度や範囲を決める、という整理に留めます。

よくある質問

クラウド利用中心でも診断は必要ですか？

クラウド利用中心でもプラットフォーム診断は必要です。理由は、参照情報で示されているとおり、クラウドで起きる情報漏えいは「サービス側の問題」ではなく、利用者側の設定不備で発生することがあるためです。

人的ミスが起きる前提で適宜監査する、という考え方に沿って、クラウドの構成監査を診断の一部として組み込むのが現実的です。

小規模なシステムでも効果はありますか？

小規模でも効果はあります。攻撃者は、脆弱性が放置されている環境が広く存在することを前提に、危険性が高い脆弱性情報を得たらすぐ検証して活用しようとする、と参照情報で整理されています。規模が小さくても、外部公開がある限り、その“効率の良い標的探索”に含まれます。

また、防御側はパッチ適用を業務不具合の懸念で敢えてしない、重要性を認識していない、といった事情で更新が止まりやすい点も指摘されています。小規模環境では特に、人手不足でこの状態に陥りやすいため、プラットフォーム診断で「どこが止まっているか」「入口になり得る機器はどれか」を可視化する効果が出やすいです。

ツール診断と専門家の診断は何が違いますか？

ツール診断は既知パターンの網羅に強く、専門家診断は文脈（構成・運用・痕跡）を踏まえた評価と精査に強い、という違いがあります。参照情報の「脆弱性診断士」の整理でも、診断結果の評価を担い、パケットレベル解析、ペネトレーションテストやツールの知識、脅威情報の知識などが求められるとされています。

コスト最適化の観点では、定期的なツール診断で広く状態を把握し、境界装置や重要資産など影響が大きい範囲は専門家の手動精査を組み合わせる設計が取りやすいです。

プラットフォーム診断への対応で次にすべきこと

プラットフォーム診断は、サーバ／ネットワーク機器／クラウドの「脆弱性」だけでなく、設定不備やログ取得を含む運用上の穴まで可視化し、是正の優先順位と計画に落とすための点検として整理できます。判断の軸は、外部から到達可能な境界装置（VPN等）や公開サーバを中心に、到達可能性と資産重要度を重ねて優先度を決められるかどうかです。ペネトレーションテストは依頼から完了まで数カ月かかることがあるため、短期で回す衛生点検（プラットフォーム診断）と、重要拠点の実証（ペネトレーションテスト）を分けて計画するのが現実的です。次アクションとしては、まず対象IP一覧や構成図、変更予定、停止可否、入口・出口ログ（VPN／ファイアウォール／プロキシ／DNS）の有無を社内で揃え、スコープと実施条件の合意形成を進めます。個別環境のリスク評価や停止判断は影響が大きいため、必要に応じて専門家に相談しつつ、報告書を是正計画に接続する運用まで含めて設計してください。

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

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

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

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

運営会社情報ページへ