ペネトレーションテストの範囲の決め方｜効果的なスコープ設定のポイント

ペネトレーションテストを実施したいけれど、どこまでをテスト対象にすれば良いのか分からない。予算は限られているし、範囲を狭めすぎて重要な脆弱性を見逃してしまったらどうしよう……このような悩みを抱えている情報システム担当者の方は少なくありません。

実は、ペネトレーションテストの費用対効果は**範囲設定（スコープ設定）**で8割決まると言われています。範囲が広すぎると予算が膨らみ経営層の承認が得られず、逆に狭すぎると肝心の脆弱性を見逃してしまうリスクがあります。この記事では、自社に最適なペネトレーションテストの範囲を決めるための具体的な手順と判断基準を、中小企業のIT担当者向けに分かりやすく解説します。

ペネトレーションテストの範囲とは？基本的な考え方

ペネトレーションテストの範囲設定を理解する前に、まず「範囲」とは何を指すのかを明確にしておきましょう。適切な範囲設定ができれば、限られた予算内で最大限のセキュリティ効果を得ることができます。

スコープの3つの要素

ペネトレーションテストの範囲（スコープ）は、次の3つの要素で構成されます。

• 対象システム：どのIT資産をテストするか（Webサイト、サーバー、ネットワーク機器、クラウド環境など）
• テスト手法：どのような攻撃手法を用いるか（外部攻撃、内部脅威、ソーシャルエンジニアリング、物理侵入など）
• 実施期間：どのくらいの期間でテストを行うか（1日〜数週間）

これら3つの要素のバランスを取ることが、効果的なスコープ設定の第一歩です。例えば、対象システムを広げすぎると実施期間が長くなり、それに伴って費用も増加します。IPA（情報処理推進機構）の「ペネトレーションテスト実施ガイドライン」でも、事前のスコープ定義が成功の鍵と明記されています。

範囲設定がなぜ重要か

なぜ範囲設定がこれほど重要なのでしょうか。それは、コストとリスクのバランスを取る必要があるためです。

ペネトレーションテストは、全てのシステムを対象にすれば確かに網羅的ですが、中小企業では予算的に現実的ではありません。一方で、範囲を狭めすぎると重要な脆弱性を見逃すリスクが高まります。例えば、Webサイトのみをテストして満足していたところ、実はVPN接続に深刻な脆弱性があり、後日サイバー攻撃を受けてしまったケースも報告されています。

適切な範囲設定により、以下のメリットが得られます。

• 限られた予算内で最も危険度の高い箇所を優先的にテストできる
• ベンダーとの見積もり交渉がスムーズになる
• テスト結果を経営層に報告しやすくなる
• 翌年度以降の計画的な拡大が可能になる

よくある範囲設定の失敗例

実際の企業では、どのような失敗が起きているのでしょうか。典型的な失敗パターンを3つ紹介します。

失敗例1：全システムを対象にして予算オーバー

「せっかくやるなら全部テストしたい」という考えで、社内の全システムを対象に見積もりを取ったところ、予算が数百万円を超えて経営層から却下されたケース。初回は外部公開システムに絞るべきでした。

失敗例2：Webサイトだけテストして安心

ECサイトのみをテストして「問題なし」と報告したものの、半年後にバックオフィスシステムへの不正アクセスが発覚。社内ネットワークやVPNも範囲に含めるべきでした。

失敗例3：クラウド環境の制約を見落とし

AWSやAzureなどのクラウド環境を対象にしたものの、クラウドベンダーの利用規約でペネトレーションテストに事前申請が必要なことを知らず、テスト直前に延期となったケース。法的制約の確認が不十分でした。

これらの失敗を避けるには、次のセクションで解説する体系的なアプローチが有効です。

自社に最適な範囲を決める4つのステップ

それでは、具体的にどのような手順で範囲を決めれば良いのでしょうか。ここでは、中小企業でも実践しやすい4つのステップを紹介します。

ステップ1：資産の洗い出し

まずは、自社が保有するIT資産を全て書き出しましょう。特に外部に公開されているシステムは攻撃の入口になりやすいため、優先的にリストアップします。

洗い出すべき主な資産は以下の通りです。

• コーポレートサイト・ECサイトなどのWebアプリケーション
• 顧客情報を扱う業務システム
• メールサーバー・ファイルサーバー
• VPN装置・リモートアクセス環境
• クラウドサービス（AWS、Azure、Google Cloudなど）
• 社内Wi-Fi・ゲストWi-Fi

この段階では、社内の各部署にヒアリングを行い、IT部門が把握していない「シャドーIT」（部署が独自に導入したクラウドサービスなど）も洗い出すことが重要です。NISC（内閣サイバーセキュリティセンター）の調査によれば、中小企業の約40%がシャドーITの存在を把握していないというデータもあります。

ステップ2：リスク評価

次に、洗い出した資産それぞれについて、攻撃された場合の被害想定を行います。これにより、テストの優先順位が明確になります。

評価の際は、以下の3つの観点で点数をつけると判断しやすくなります（各5点満点）。

例えば、顧客の個人情報を扱うECサイトは「機密性5点、完全性5点、可用性5点」で合計15点となり、最優先テスト対象となります。一方、社内の情報共有用Wikiは「機密性2点、完全性3点、可用性2点」で合計7点となり、優先度は下がります。

このリスク評価は、経済産業省の「サイバーセキュリティ経営ガイドライン」でも推奨されている手法です。

ステップ3：予算配分の判断

リスク評価が終わったら、次は予算との兼ね合いを考えます。ペネトレーションテストの一般的な費用相場は以下の通りです。

• Webアプリケーション単体：30万円〜80万円
• ネットワーク診断（10台程度）：50万円〜100万円
• 総合的なテスト（外部＋内部）：150万円〜300万円

予算が限られる場合は、段階的実施も有効な選択肢です。例えば以下のような計画が考えられます。

初年度：外部公開Webサイトのみ（予算50万円）

最も攻撃されやすい部分を先に対策し、成果を経営層に報告。

2年目：ネットワーク境界とVPN接続を追加（予算80万円）

初年度の成果を基に予算を獲得し、範囲を拡大。

3年目：クラウド環境と無線LANを追加（予算100万円）

段階的に網羅性を高めていく戦略。

実際に、ある製造業の中小企業では、この段階的アプローチにより3年間で主要システムの90%以上をカバーすることに成功しています。

ステップ4：法的制約の確認

範囲を決定する前に、必ず法的制約を確認しましょう。特にクラウド環境を対象とする場合、注意が必要です。

主要クラウドベンダーのペネトレーションテストに関するポリシーは以下の通りです。

• AWS：EC2、RDSなど一部サービスは事前申請不要だが、DDoS攻撃シミュレーションは禁止
• Microsoft Azure：エンゲージメント通知を推奨（必須ではない）
• Google Cloud：事前通知は不要だが、利用規約の範囲内で実施

また、社外のデータセンターやホスティング業者を利用している場合も、契約約款でペネトレーションテストが許可されているか確認が必要です。無断で実施すると、不正アクセス禁止法違反に問われる可能性もあります。

さらに、本番環境でのテストは業務への影響を考慮する必要があります。多くの企業では、以下のような対応を取っています。

• テストは業務時間外（夜間・休日）に実施
• 負荷が高いテストは事前に関係部署へ通知
• 万が一の障害に備えて復旧手順を準備

対象別に見る推奨されるテスト範囲の具体例

ここまでの内容を踏まえて、システムの種類別に推奨されるテスト範囲を具体的に見ていきましょう。自社の状況と照らし合わせながら参考にしてください。

Webアプリケーション

外部に公開されているWebサイトやWebアプリケーションは、サイバー攻撃の主要な標的となるため、最優先でテスト範囲に含めるべきです。

特に以下の機能は攻撃者に狙われやすいため、重点的にテストします。

• 認証機能：ログイン画面、パスワードリセット、多要素認証の実装
• 決済機能：クレジットカード情報の取り扱い、決済API連携
• 個人情報入力フォーム：会員登録、問い合わせフォーム、アンケート
• ファイルアップロード機能：画像投稿、資料ダウンロードなど

OWASP（The Open Web Application Security Project）が公開している「OWASP Top 10」では、Webアプリケーションの代表的な脆弱性として、SQLインジェクションやクロスサイトスクリプティング（XSS）、認証の不備などが挙げられています。これらの脆弱性を重点的に検証するのが効果的です。

また、ECサイトを運営している場合は、PCI DSS（クレジットカード情報セキュリティ基準）への準拠も視野に入れる必要があります。

ネットワークインフラ

社内ネットワークの境界部分とVPN接続は、外部からの侵入経路として狙われやすい箇所です。

テスト範囲に含めるべき主な対象は以下の通りです。

• ファイアウォール・UTM装置の設定
• VPN装置の認証強度とパッチ適用状況
• DMZ（非武装地帯）に配置されたサーバー
• リモートデスクトップ接続の設定

特に近年は、テレワークの普及によりVPN装置が攻撃の標的となるケースが増加しています。2023年のJPCERT/CCの報告では、VPN装置の脆弱性を悪用した攻撃が前年比で約2倍に増加したとされています。

また、社内ネットワークのセグメント分離が適切に行われているかも確認ポイントです。例えば、ゲスト用Wi-Fiと業務用ネットワークが同じセグメントにあると、攻撃者が容易に社内システムにアクセスできてしまいます。

クラウド環境

AWSやAzure、Google Cloudなどのクラウド環境を利用している場合、設定ミスと権限管理が主なテスト対象となります。

具体的には以下の項目を確認します。

• IAM（Identity and Access Management）設定：過剰な権限付与がないか
• S3バケット等のストレージ：公開設定の誤りがないか
• セキュリティグループ設定：不要なポートが開放されていないか
• ログ・監視設定：CloudTrailやCloudWatchが適切に設定されているか

クラウド環境では、従来のオンプレミス環境とは異なる脆弱性が生じやすいことに注意が必要です。例えば、「デフォルト設定のまま運用している」「アクセスキーをGitHubに誤ってアップロード」といったミスが実際の情報漏洩事故につながっています。

Gartnerの調査によれば、2025年までにクラウドセキュリティ侵害の95%以上が顧客側の設定ミスに起因すると予測されており、クラウド環境の診断の重要性が高まっています。

無線LAN環境

オフィスや店舗で提供しているゲストWi-Fiは、見落とされがちですが重要なテスト対象です。

チェックすべきポイントは以下の通りです。

• 暗号化方式（WPA2以上を使用しているか）
• ゲストネットワークと業務ネットワークの分離
• SSID（ネットワーク名）のステルス設定
• MACアドレスフィルタリングの有無

特に飲食店や小売店など、顧客向けに無料Wi-Fiを提供している場合、そのWi-Fiから社内の業務システムにアクセスできてしまう設定ミスが散見されます。実際に、ある小売チェーンでは、ゲストWi-Fi経由で社内の在庫管理システムに不正アクセスされる事件が発生しています。

また、無線LANの物理的なセキュリティも重要です。オフィスの外からでも電波が届く場合、駐車場から攻撃を仕掛けられるリスクがあります。ペネトレーションテストでは、建物外からのアクセス可能性も検証します。

範囲設定で失敗しないための注意点

最後に、実際にベンダーにテストを依頼する際の注意点と、テスト後の活用方法について解説します。これらを押さえておくことで、より効果的なペネトレーションテストが実現できます。

ベンダーへの伝え方

ベンダーに見積もりを依頼する際、曖昧な指示は避け、具体的に範囲を伝えることが重要です。

良い伝え方の例を以下に示します。

NG例：「うちのシステム全体を見てもらいたい」

これでは範囲が不明確で、ベンダーも正確な見積もりが出せません。

OK例：「公開Webサイトのログイン機能と決済機能、および社内ネットワークへのVPN接続を対象に、外部からの侵入テストを希望します。テスト期間は3日間を想定しています」

対象システム、テスト手法、期間が明確に伝わります。

さらに、以下の情報も併せて提供すると、より精度の高い提案が期待できます。

• 対象システムの規模（URLやIPアドレスの数、ネットワーク機器の台数など）
• 使用している技術（プログラミング言語、フレームワーク、OSなど）
• 過去に実施したセキュリティ対策の内容
• 特に懸念している脅威（例：ランサムウェア、情報漏洩など）

複数のベンダーから相見積もりを取る場合は、同じ条件で比較できるよう、全てのベンダーに同じ情報を提供することをおすすめします。

除外すべき対象の明確化

テスト範囲を決める際には、逆に**「何をテストしないか」**も明確にしておく必要があります。

除外すべき代表的な対象は以下の通りです。

• 本番データベース：データ破損リスクを避けるため、テスト環境で実施
• 他社が運用するシステム：クラウドサービスの基盤部分など
• 業務への影響が大きい時間帯：システム負荷が高いテストは夜間・休日に限定
• 法的に問題がある手法：DoS攻撃、物理侵入（事前許可なし）など

特に重要なのは、本番環境への影響を最小化することです。多くのベンダーは、テスト前にリスク分析を行い、業務停止のリスクがある場合は代替手段を提案してくれます。契約時には「万が一システムに障害が発生した場合の責任範囲」も明確にしておきましょう。

また、グループ会社や関連会社のシステムが接続されている場合、それらも範囲に含めるかどうかを事前に決定し、必要に応じて関係各社の許可を得ておく必要があります。

追加費用が発生するケース

契約後に想定外の追加費用が発生しないよう、事前に確認しておくべきポイントがあります。

追加費用が発生しやすいケースは以下の通りです。

• 重大な脆弱性が発見された場合の再テスト：対策後の検証に追加料金がかかることがある
• 想定より多くの脆弱性が見つかった場合：報告書作成に追加工数が必要
• テスト範囲の変更：契約後にシステムが追加された場合
• 緊急対応：テスト中に本番障害が発生し、復旧対応が必要になった場合

これらを避けるには、契約時に以下の点を確認しましょう。

• 再テストの費用は含まれているか（多くの場合、1回目は無料のことが多い）
• 報告書の修正・追加対応の範囲はどこまでか
• 範囲変更時の単価設定はどうなっているか

優良なベンダーであれば、これらの条件を契約書に明記してくれます。不明瞭な場合は、遠慮せず質問することが大切です。

年次更新時の見直し

ペネトレーションテストは、一度実施すれば終わりではありません。システム変更を反映した定期的な見直しが必要です。

年次更新時に見直すべきポイントは以下の通りです。

• 新規導入システムの追加：前年度から新しく稼働したシステムがあれば範囲に含める
• 前回の対策状況の確認：修正した脆弱性が本当に解消されているか再検証
• 脅威の変化への対応：新たに出現した攻撃手法（ゼロデイ脆弱性など）を考慮
• 法規制の変化：個人情報保護法改正など、コンプライアンス要件の変更

理想的には、以下のようなサイクルでテストを実施します。

1. 年1回の定期テスト（既存システムの再検証）
2. システム更改時のテスト（大規模リニューアル時）
3. インシデント発生時のテスト（類似攻撃への対策確認）

また、前回のテスト結果と比較することで、セキュリティ対策の改善度合いを経営層に報告できます。「昨年度は高リスク脆弱性が5件あったが、今年度は0件に改善」といった定量的な報告は、予算獲得にも有効です。

さらに、業界のベンチマークと比較することで、自社のセキュリティレベルを客観的に評価できます。多くのベンダーは、業界別の平均的な脆弱性検出数などのデータを持っているため、参考情報として提供してもらうと良いでしょう。

まとめ

この記事では、ペネトレーションテストの効果的な範囲設定について解説しました。重要なポイントは以下の3つです。

• 範囲設定は「リスクの高い箇所から段階的に」が基本原則：全てを一度にテストする必要はなく、優先順位をつけて計画的に実施することが、中小企業には現実的で効果的です。初年度は外部公開システムに絞り、次年度以降に内部ネットワークやクラウド環境へと拡大していく戦略が成功しやすいパターンです。
• 4つのステップで自社に最適な範囲を決定：資産の洗い出し→リスク評価→予算配分→法的制約の確認という流れで検討することで、費用対効果の高いテスト範囲を設定できます。特にリスク評価では、機密性・完全性・可用性の3つの観点で点数化すると、客観的な優先順位付けが可能になります。
• ベンダーとの協議とテスト後の継続的改善が成功の鍵：曖昧な指示ではなく具体的な範囲を伝えること、除外対象も明確にすること、そして年次での見直しを行うことが、長期的なセキュリティ向上につながります。不明点は遠慮なくベンダーに質問し、双方の認識を合わせることが重要です。

範囲設定に迷った場合は、まず外部公開しているWebサイトやWebアプリケーションから始めることをおすすめします。そこで得られた知見と成果を基に、次年度以降の計画を立てることで、段階的に網羅性を高めていくことができます。

次のステップとしては、信頼できるペネトレーションテストベンダーに相談し、自社の状況に合わせた具体的な提案を受けることをおすすめします。多くのベンダーは初回相談を無料で行っているため、まずは気軽に問い合わせてみてはいかがでしょうか。