LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

ペネトレーションテストとは——脆弱性診断と何が違うのか

ペネトレーションテストとは、実際の攻撃者と同じ視点でシステムに対して疑似的な侵入を試み、攻撃が成立するかどうかをリスクベースで確認するセキュリティ評価手法を指します。単に脆弱性の存在を列挙するのではなく、「実際にその脆弱性を悪用すればどこまで侵害が進むか」を検証することが目的です。IPA（情報処理推進機構）が公表した「情報セキュリティ10大脅威 2025」^*1では、「システムの脆弱性を突いた攻撃」が組織向け脅威の第3位に選出されており、脆弱性を放置するリスクの深刻さが改めて示されています。

「疑似攻撃で侵害可否を確認」——ペネトレーションテストの本質

ペネトレーションテストの本質は「この脆弱性を悪用すれば、攻撃者はどこまで侵入できるか」を実証することにあります。テスト担当者は攻撃者と同じ手順を踏み、偵察・脆弱性の特定・エクスプロイト（攻撃コードの実行）・権限昇格・横展開と段階を追って侵入を試みます。

テストは定められたスコープ（対象範囲）の中で実施され、事前に免責契約を締結したうえで進めます。侵入が成功した場合は「どの脆弱性を起点に」「どの経路を辿って」「どのシステムまで到達できたか」を報告書にまとめます。この実証的なアプローチが、ペネトレーションテストを単なる脆弱性リストとは異なるものにしています。

脆弱性診断との違い——網羅的スキャンと目的志向シナリオの対比

脆弱性診断とペネトレーションテストは、しばしば混同されますが目的が異なります。総務省のサイバーセキュリティ関連資料^*2では、脆弱性診断を「Webアプリケーションやプラットフォームなどシステムに脆弱性を発見するために行う検査」、ペネトレーションテストを「攻撃者と同じ視点で攻撃を行い、実際に攻撃が成功するかをリスクベースで確認する検査」と区別しています。

脆弱性診断が「どこに問題があるか」を洗い出すのに対し、ペネトレーションテストは「その問題を実際に悪用されたらどうなるか」を確かめます。両者は排他的ではなく、まず脆弱性診断で全体を把握したうえで、重要システムにペネトレーションテストを実施するという順序が実務でよく用いられます。

ペネトレーションテストの種類——アプローチ別・対象範囲別

ペネトレーションテストには複数の分類軸があります。外注先を選定したり見積もりを依頼したりする際に、どの種別を求めているかを明確にしておくことが費用交渉や品質確保につながります。

ブラックボックス・ホワイトボックス・Gray-box（部分情報共有型）——情報共有度による3分類

テスト対象に関する事前情報の共有度によって、3種類に分類されます。OWASP（Open Web Application Security Project）のWeb Security Testing Guide（WSTG）^*3では、ペネトレーションテストの実施フレームワークの中でこれらのアプローチの違いが整理されています。

コスト面では、ブラックボックスが情報収集に工数を要するため相対的に高くなる傾向があります。ホワイトボックスは検証範囲が広いため同様に高コストになりやすい一方、Gray-box（部分情報共有型）は両者の中間として採用されるケースが多く見られます。

対象範囲別の4種——外部・内部・Webアプリ・クラウド

ペネトレーションテストはテスト対象の種類によっても分類されます。外注の際にはどの範囲を対象とするかを明確にすることが、適切な見積もりを得るために欠かせません。

• 外部ネットワークペネトレーションテスト：インターネットから到達できる外部公開サーバー・ファイアウォール・VPNエンドポイント等を対象とします。外部攻撃者が最初に接触するポイントの耐性を確認します。
• 内部ネットワークペネトレーションテスト：社内ネットワーク・Active Directory・内部システムを対象とします。侵入後の横展開リスクや権限昇格の可否を検証します。
• Webアプリケーションペネトレーションテスト：WebサービスやAPIを対象とし、SQLインジェクション・XSS（クロスサイトスクリプティング）・認証不備・アクセス制御の欠陥等を実際に悪用できるかを確認します。OWASPのWSTGが標準的なテスト手法として広く参照されています。
• クラウド環境ペネトレーションテスト：AWS・Azure・GCPなどのクラウド基盤上の設定不備・IAMポリシーの過剰権限・ストレージの公開設定ミス等を対象とします。クラウドプロバイダーの利用規約に従った実施が必要です。

複数の種別を組み合わせた「総合ペネトレーションテスト」を実施することもあります。ただし範囲が広がるほど工数と費用が増加するため、リスクの高い箇所に絞ったスコープ設計が重要です。

ペネトレーションテスト外注の費用相場と費用決定因子

ペネトレーションテストの外注費用は、対象システムの規模・種別・テストアプローチ・委託先の専門性によって大きく異なります。以下の費用レンジはベンダーのサービス一覧や市場情報をもとにした参考値であり、一次資料による確定値ではありません。実際の発注にあたっては複数社から見積もりを取り、スコープを明確にしたうえで比較することをお勧めします。

費用レンジの目安と費用決定因子（市場参考値・一次資料ではない）

費用を決定する主な因子は次の通りです。スコープを整理するうえでの参考としてご参照ください。

市場では、Webアプリケーションペネトレーションテストを中心とした中規模案件で数十万円〜数百万円程度の費用感が流通していますが、これはあくまで市場参考値です。システムの複雑度・要求品質・委託先の専門性によって実際の費用は異なります。

費用を抑えるためのスコープ設計

外注費用を適切に管理するには、テスト対象を「リスクの高い箇所」に絞ることが大切です。全システムを一度に対象にするのではなく、優先度付けをすることで費用対効果を高められます。

• 外部公開システムから着手する：インターネットに直接公開されているサーバー・APIが最もリスクが高く、攻撃者に最初に狙われます。まずここから始めることで費用を絞れます。
• IPアドレス・URLを事前に確定する：対象を明確にするほど見積もりの精度が上がり、後から追加になる費用を防げます。
• 再テストのスコープを限定する：修正後の再確認は全体ではなく修正箇所だけに絞ることで追加費用を抑えられます。

委託先を選ぶ5つの確認軸

ペネトレーションテストは、テスト担当者の技術力と倫理観に依存する部分が大きいサービスです。委託先を選定する際には以下の5軸で評価することをお勧めします。

技術・資格・実績・報告書品質・コミュニケーション体制

① 担当エンジニアの保有資格・専門性

ペネトレーションテストの分野では国際的な資格が委託先評価の参考になります。代表的なものとして、CEH（Certified Ethical Hacker）、OSCP（Offensive Security Certified Professional）、GPEN（GIAC Penetration Tester）などがあります。特にOSCPは実技試験を含む資格として技術力の証明として評価されます。担当者の保有資格や実務経験年数を確認しましょう。

② 同業種・同規模のシステムへの実績

業種や技術スタックが自社と近い実績があるかどうかを確認します。Webアプリ専門のベンダーに内部ネットワークのテストを依頼するなど、専門外を任せることはリスクになります。守秘義務があるため実績の詳細を公開できないことも多いですが、業種・対象種別・規模感だけでも確認することをお勧めします。

③ 報告書のサンプル確認

報告書のサンプルを事前に提示してもらうことを強くお勧めします。優れた報告書は「侵害経路の再現手順」「リスク評価（深刻度・影響・再現性）」「修正優先度の明示」「経営層向けのエグゼクティブサマリー」を含んでいます。技術担当者だけでなく経営層が読んで意思決定できる内容かどうかが重要です。

④ コミュニケーション体制と免責事項の整備

テスト実施中に予期しないシステム障害が発生した場合の対応プロセスを事前に確認します。テスト中は攻撃的な操作が行われるため、異常発生時の連絡体制・停止判断の権限・業務影響の最小化手順をあらかじめ契約書に明記することが必要です。

⑤ スコープ外への不拡大の徹底

合意したスコープ外のシステムへ意図的・無意図的に侵入しないことを保証する体制があるかを確認します。テスト終了後の情報の取り扱い（発見した認証情報・内部情報の廃棄手順）についても契約段階で合意しておくことが大切です。

外注前に整えるスコープ設計と報告書の活用

ペネトレーションテストを外注する際に、発注側が整えておくべき準備があります。準備不足のまま依頼すると費用が増大したり、期待した成果が得られなかったりするリスクがあります。

テスト範囲の明確化——スコープ設計が成否を左右する

スコープ設計とは「何を対象にするか・何を対象外にするか」を明確にすることです。これはペネトレーションテストにおいて最初に合意すべき最重要事項です。スコープが曖昧なまま進めると、想定外のシステムに影響が及ぶリスクや、実際のリスクを見落とす可能性があります。

スコープ設計で明確にすべき主な項目は次の通りです。

• 対象IPアドレス・ドメイン・URLのリスト：テスト対象を具体的に列挙します。
• 対象外の明示：本番データを保有するDBへの書き込み、DDoS攻撃シミュレーション、第三者所有のサーバーなど、テストしてはいけない範囲を明示します。
• 実施時間帯の制限：業務時間外のみとするか、業務時間中も含めるかを決めます。業務システムへの影響を避けるため夜間・休日に限定するケースが多くあります。
• 使用するアカウントの権限レベル：Gray-box（部分情報共有型）の場合、どの権限レベルのアカウントを渡すかを決めます。

OWASPのWSTGやNIST SP 800-115「Technical Guide to Information Security Testing and Assessment」^*4では、テストの計画・スコープ定義・実施フェーズに関するフレームワークが整理されており、外注先との合意事項の参考として活用できます。

報告書の読み方——リスク評価と優先対応の整理

ペネトレーションテストの最終成果物は報告書です。報告書を受け取った後、どのように読んで対応優先度をつけるかが実務上の課題になります。

一般的な報告書は「エグゼクティブサマリー（経営層向け）」と「技術的詳細（開発者・セキュリティ担当者向け）」の2部構成になっています。技術的詳細には通常、各脆弱性のリスク評価（Critical/High/Medium/Lowなどの深刻度）・再現手順・推奨対策が記載されます。

対応優先度の整理には次の視点が役立ちます。

• 侵害経路の深刻度：「外部から認証なしで管理者権限が取得できる」といった侵害経路は最優先で対処します。
• 影響を受けるデータの種類：個人情報・機密情報・決済情報に関わる経路は、深刻度評価とは別に優先度を上げて判断します。
• 修正の容易さと効果：設定変更だけで対処できる項目は早期対応が可能です。アーキテクチャ変更が必要な項目はロードマップに組み込みます。

報告書受領後に疑問点や追加確認が生じることは多くあります。委託先に質問できる体制が整っているかを契約段階で確認しておくことが、報告書の内容を十分に活用するうえで重要です。

なお、ペネトレーションテストは一度実施すれば終わりではありません。システムへの変更・新機能追加・クラウド環境の更新のたびに新たなリスクが生まれます。重要システムでは年1回程度の定期実施や、大規模リリース前の都度実施が推奨されます。

まとめ——ペネトレーションテスト外注判断の3つの軸

本稿では、ペネトレーションテストの定義・脆弱性診断との違い・種別・外注費用の考え方・委託先の選定基準・スコープ設計と報告書の活用について整理しました。要点を3つに集約すると次の通りです。

第一に、ペネトレーションテストは「疑似攻撃で侵害の成立可否を確かめる」手法です。脆弱性の洗い出しを目的とする脆弱性診断とは目的が異なります。両者を組み合わせることで、網羅的なリスク把握と深い侵害経路検証の両方が可能になります。

第二に、テスト種別（ブラックボックス・ホワイトボックス・Gray-box（部分情報共有型））と対象範囲（外部・内部・Webアプリ・クラウド）を組み合わせて最適なスコープを決めることが、費用対効果を高めるうえで大切です。外注費用は対象規模・手法・委託先の専門性によって異なるため、複数社への見積もり依頼とスコープの明確化が基本になります。

第三に、委託先の技術力・資格・報告書品質・コミュニケーション体制を事前に確認し、スコープ外への不拡大と情報管理を契約で明確にすることが、ペネトレーションテストを適切かつ有効に活用するための前提です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA（独立行政法人情報処理推進機構）「情報セキュリティ10大脅威 2025」（2025年）
2. *2　出典：総務省「国民のためのサイバーセキュリティサイト：脆弱性診断・ペネトレーションテスト実施」
3. *3　出典：OWASP「Web Security Testing Guide（WSTG）」
4. *4　出典：NIST「SP 800-115 Technical Guide to Information Security Testing and Assessment」（2008年）

Tweet