ペネトレーションテストとは？脆弱性診断との違い・費用相場を解説
ペネトレーションテストとは、攻撃者の視点で実際にシステムへの侵入を試み、脆弱性の有無だけでなく侵入後の被害範囲まで検証するセキュリティ診断手法です。脆弱性診断と何が違うのか、費用相場はどの程度かといった疑問を持つ情報システム担当者は少なくありません。本記事では、ペネトレーションテストの種類・実施フロー・費用相場の中央値・業界別の活用ポイント・法務上の注意点・よくある失敗パターンまで、導入を検討するうえで押さえておきたい内容を解説します。
おすすめ記事
目次
開く
閉じる
開く
閉じる
ペネトレーションテストとは？脆弱性診断との違い
ペネトレーションテストとは、攻撃者の視点でシステムへの侵入を実際に試み、脆弱性の有無に加えて侵入後の被害範囲まで検証するセキュリティ診断手法である。
企業のセキュリティ対策を検討する際、「脆弱性診断」と「ペネトレーションテスト」は似た文脈で語られることが多いが、目的とアプローチは異なる。脆弱性診断はシステムに存在する既知の脆弱性を網羅的にスキャンし、リスクの棚卸しを行う手法である。一方、ペネトレーションテストは特定のシナリオ（例：外部からの不正アクセス、内部関係者による情報持ち出し）を想定し、実際にどこまで侵入・突破できるかを人の手で検証する。IPA（情報処理推進機構）が毎年公表している情報セキュリティ10大脅威でも、外部からの不正アクセスや標的型攻撃による情報漏えいは継続的にランクインしており、脆弱性の存在を確認するだけでなく、実際の攻撃シナリオに対する耐性を評価する必要性が指摘されている。
両者は代替関係ではなく補完関係にある。まず脆弱性診断でリスクの全体像を把握し、重要度の高いシステムに対してペネトレーションテストで実際の突破可能性を検証する、という組み合わせが多くの企業で採用されている。
| 比較項目 | 脆弱性診断 | ペネトレーションテスト |
|---|---|---|
| 目的 | 既知の脆弱性を網羅的に洗い出す | 実際に侵入・突破できるかを検証する |
| アプローチ | 自動スキャンツール中心 | 診断員による手動攻撃シミュレーション中心 |
| 評価範囲 | 脆弱性の有無・種類 | 侵入後の被害範囲・影響度まで |
| 実施頻度の目安 | 定期的（四半期〜年次など） | 重要システムの改修時・年次など節目で実施 |
| 向いている場面 | 広範囲のリスクを短期間で把握したい | 特定システムの実際の防御力を検証したい |
ペネトレーションテストの種類・タイプ分類
ペネトレーションテストは「診断員がどこまで内部情報を知った状態で実施するか」という手法軸と、「何を対象にするか」という対象軸の2方向で分類される。
手法軸では、内部情報を一切与えずに外部からの攻撃者と同じ条件でテストするブラックボックス、ネットワーク構成や一部の認証情報など限定的な情報を与えるグレーボックス、ソースコードやシステム構成図まで開示してテストするホワイトボックスの3分類が代表的である。ブラックボックスは実際の攻撃者に近い視点で防御力を検証できる一方、時間内に発見できる問題が限定される場合がある。ホワイトボックスは内部構造まで踏み込んだ精緻な検証が可能だが、実際の外部攻撃者が持ちえない情報を前提とするため、現実の脅威シナリオとはズレが生じる場合もある。
対象軸では、Webアプリケーションの入力フォームや認証機能を狙うWebアプリ診断、社内ネットワークやサーバーの設定不備を狙うネットワーク診断、従業員を標的にしたなりすましメールや電話でパスワードや内部情報を引き出すソーシャルエンジニアリング診断、クラウド環境の権限設定やアクセス制御を検証するクラウド環境診断などがある。自社がどの領域にリスクを抱えているかによって、優先して実施すべき対象は変わる。
| 分類軸 | タイプ | 向いている企業・目的 |
|---|---|---|
| 手法（情報開示レベル） | ブラックボックス | 実際の攻撃者視点で防御力を検証したい企業 |
| 手法（情報開示レベル） | グレーボックス | 効率と実践性のバランスを取りたい企業 |
| 手法（情報開示レベル） | ホワイトボックス | 内部構造まで踏み込んで精緻に検証したい企業 |
| 対象 | Webアプリ診断 | 自社サービス・ECサイト等を運営する企業 |
| 対象 | ネットワーク診断 | 社内サーバー・ネットワーク機器を多く保有する企業 |
| 対象 | ソーシャルエンジニアリング診断 | 従業員経由の情報漏えいリスクを確認したい企業 |
| 対象 | クラウド環境診断 | AWS・Azure等のクラウド基盤を利用する企業 |
ペネトレーションテストの主な手法・実施フロー
ペネトレーションテストは、事前準備から報告書作成までを段階的に進め、攻撃者視点で侵入可否と被害範囲を検証する調査手法である。
実施フローの全体像
ペネトレーションテストは、いきなり攻撃を試みるわけではなく、以下のような段階を踏んで実施される。各段階での合意形成が、テスト対象への影響を管理するうえでの前提となる。
- 事前準備（スコープ・許可範囲の合意）：診断対象の範囲、実施期間、使用してよい手法、緊急時の連絡体制などを発注側と診断側で文書化して合意する。この合意がないまま実施すると、業務システムへの想定外の影響や、社内での認識齟齬につながる恐れがある。
- 情報収集：対象システムの公開情報、使用技術、ネットワーク構成などを調査し、攻撃の起点となりうる要素を洗い出す。
- 脆弱性探索：収集した情報をもとに、設定不備や既知の脆弱性など、侵入の手がかりとなりうる箇所を特定する。
- 侵入試行：特定した脆弱性を実際に用いて、システムへの侵入が可能かどうかを検証する。
- 権限昇格・被害範囲検証：侵入に成功した場合、どこまで権限を拡大できるか、どの範囲のデータ・システムに影響が及ぶかを確認する。
- 報告書作成：発見した脆弱性の内容、リスクの度合い、対応の優先順位、改善策を整理し、経営層・現場双方が理解できる形式でまとめる。
代表的な攻撃手法の概念
ペネトレーションテストで用いられる手法は多岐にわたるが、代表的な考え方を概念レベルで紹介する。実行手順の詳細は悪用防止の観点から本記事では扱わない。
- SQLインジェクション：入力フォームなどを通じて、想定外のデータベース操作を引き起こそうとする手法の総称。入力値の検証・サニタイズが不十分なシステムで問題になりやすい。
- 認証回避：ログイン機能やアクセス制御の不備を突いて、正規の認証を経ずにシステムへアクセスできる状態がないかを確認する手法。
- 権限昇格：一般利用者の権限で侵入した後、管理者権限など、より高い権限を取得できる不備がないかを検証する手法。
これらはいずれも、システムの設計・実装上の不備を悪用した場合に発生しうるリスクを事前に把握するための検証項目であり、診断結果に応じて優先順位をつけた改善対応が求められる。
実施体制：社内実施と外部委託の違い
ペネトレーションテストの実施体制には、社内の情報システム部門が行う方法と、専門会社へ委託する方法がある。社内実施は情報の取り扱いを内部に留められる一方、最新の攻撃手法や診断ツールへの習熟には継続的な投資が必要になる。
専門会社への委託により、専門知見と最新の攻撃手法への対応力を確保できるという点は、体制構築の負担を抑えたい企業にとって検討材料になりやすい。診断範囲の設計から報告書の作成、改善策の提案までを一括して依頼できるBPOサービスを活用する企業も増えている。自社の体制やリソースを踏まえ、社内実施・外部委託・両者の併用のいずれが適するかを見極めることが実務上の出発点になる。
ペネトレーションテストの費用相場・期間【中央値提示】
ペネトレーションテストの費用は診断対象の規模と手法により幅があり、業界の実勢価格帯としては数十万円から数百万円程度が目安とされる。
ペネトレーションテストの費用について、国や公的機関による統一的な費用統計は現時点で存在しない。以下は編集部が業界の一般的な相場感を調査した「業界の実勢価格帯（編集部調査）」であり、実際の費用は診断会社・診断範囲・手法によって変動する点に留意されたい。
| 診断対象規模 | 費用レンジ（中央値目安） | 特徴 |
|---|---|---|
| 小規模Webサイト（Webアプリ診断） | 中央値目安50万〜100万円程度 | 特定のWebアプリケーションを対象とした診断 |
| 中規模システム（プラットフォーム診断） | 中央値目安50万〜150万円程度 | サーバー・ネットワーク基盤を含む診断 |
| 大規模ネットワーク（シナリオ型ペネトレーションテスト） | 中央値目安100万〜300万円程度 | 攻撃者視点でのシナリオに基づく本格的な侵入試行 |
実施期間の目安
実施期間についても、診断実施のみであれば2週間から1ヶ月程度、報告書の納品まで含めると1〜1.5ヶ月程度が中央値目安とされることが多い。診断範囲が広い場合や、複数のシステムを対象とする場合は、この期間より長くなる傾向がある。
費用に影響する主な要因
- 診断範囲：対象となるシステム・アプリケーションの数や規模が広いほど、調査・検証にかかる工数が増える。
- 手法：自動診断ツールを主体とするか、専門技術者による手動検証を重視するかによって、必要な工数と費用が変わる。
- 報告書の詳細度：技術的な詳細に加え、経営層向けのサマリーや改善提案まで含めるかどうかで作業量が変わる。
- 再診断の有無：改善後に再度診断を実施して修正状況を確認する場合、追加の費用が発生する。
上記の費用感はあくまで業界の一般的な相場感であり、公的機関による費用統計は現時点で存在しない。診断対象の規模・手法によって費用は大きく変動するため、複数社から見積りを取得し、診断範囲や報告書の内容を比較したうえで判断することが重要になる。
業界別のペネトレーションテスト活用
ペネトレーションテストは業種ごとに診断範囲や準拠すべき基準が異なり、金融業・医療機関・ECサイト運営では特有の観点が求められる。
金融・医療・EC分野は、いずれも個人情報や決済情報など機密性の高いデータを扱うため、業界特有のガイドラインや基準への対応がペネトレーションテストの設計に影響する。以下、代表的な3業種における診断範囲の違いを整理する。
金融業：FISC基準とオンラインバンキングのAPIセキュリティ
金融機関では、金融情報システムセンター（FISC）が公表する「金融機関等のシステム監査基準」「金融機関等コンピュータシステムの安全対策基準」などが、システムの安全対策を検討する際の参照先として広く用いられている。オンラインバンキングやモバイルバンキングではAPI連携が増えており、認証・認可の不備、トークン漏えい、レート制限の不足など、APIレイヤーの脆弱性を対象にした診断が重視される傾向がある。基幹系システムと対外接続システムを分離した診断範囲の設計や、不正送金を想定したシナリオベースの診断が検討される場合が多い。
医療機関：電子カルテと個人情報保護
医療機関では、電子カルテシステムに患者の病歴・診療情報といった要配慮個人情報が集約されるため、個人情報の保護に関する法律（個人情報保護法）に基づく厳格な管理が求められる。厚生労働省は「医療情報システムの安全管理に関するガイドライン」を公表しており、電子カルテや医療情報システムを扱う事業者は、このガイドラインを踏まえたセキュリティ対策の実施が期待されている。診断対象には電子カルテ本体だけでなく、地域医療連携システムや外部ベンダーとのデータ連携経路も含めて検討する必要がある。医療機器がネットワークに接続されている場合は、可用性への影響を避けるため診断範囲や実施方法をより慎重に合意する必要がある。
ECサイト運営：決済情報とPCI DSS
クレジットカード情報を取り扱うECサイトでは、国際的なセキュリティ基準であるPCI DSS（Payment Card Industry Data Security Standard）への対応が実務上の前提となる場合が多い。PCI DSSでは、要件の一つとして定期的な脆弱性診断・ペネトレーションテストの実施が求められており、決済処理を担うシステムやカード情報を保持・処理・伝送する範囲（CDE：カード会員データ環境）を明確にした診断設計が必要になる。ECサイトの場合、フロントエンドの入力フォームからバックエンドの決済連携APIまで、データの流れに沿った診断範囲の合意が実効性を左右する。
| 業種 | 主な準拠基準・ガイドライン | 診断範囲の特徴 |
|---|---|---|
| 金融業 | FISC安全対策基準等 | オンラインバンキングAPI、不正送金シナリオ |
| 医療機関 | 個人情報保護法、厚労省医療情報システム安全管理ガイドライン | 電子カルテ、地域連携システム、医療機器ネットワーク |
| ECサイト運営 | PCI DSS | カード会員データ環境（CDE）、決済連携API |
ペネトレーションテスト導入時の法務論点
ペネトレーションテストの実施には、不正アクセス行為の禁止等に関する法律（不正アクセス禁止法）との関係整理や個人情報保護法対応、委託先との契約内容の精査が欠かせない。
不正アクセス禁止法との関係
ペネトレーションテストは、対象システムへの侵入を模擬的に試みる性質を持つため、実施許諾がない状態で行うと不正アクセス行為の禁止等に関する法律（不正アクセス禁止法）に抵触するおそれがある。発注者からの明確な許諾がなければ、診断行為そのものが法的リスクを帯びる点が問題となる。このリスクを避けるため、診断対象範囲・実施期間・許可する攻撃手法・禁止事項を明記したスコープ合意書（RoE：Rules of Engagement）と、実施許諾書を事前に取り交わすことが重要になる。RoEが不十分だと、想定外のシステムへのアクセスや、担当者間の認識齟齬によるトラブルにつながりやすい。
個人情報保護法上の取扱い
診断対象システムに顧客の個人データが含まれる場合、診断会社への情報提供や診断中のログ取得は個人情報保護法上の「委託」に該当しうる。委託にあたる場合、委託元は個人情報保護法が求める委託先の監督義務を負い、委託先の安全管理体制やアクセス制御の状況を確認する必要がある。この監督が不十分だと、診断過程で取得・保管された個人データが漏えいした際に委託元の管理責任が問われる可能性がある。個人情報保護委員会のガイドラインでは、委託先の選定基準や契約内容に安全管理措置を含めることが求められており、診断会社との契約でもこの点を反映させることが望ましい。
委託先との契約における留意点
診断会社との契約では、秘密保持契約（NDA）の締結に加え、診断中に取得した脆弱性情報・システム構成情報・報告書の管理方法を明確にする必要がある。これらの情報が外部に流出すると、攻撃者にとって有用な攻撃情報源となるため、情報漏えい時の影響は通常の業務委託より大きくなりやすい。契約書には、損害賠償の範囲（システム停止時の補償の有無・上限額）、報告書の保管期間・廃棄方法、再委託の可否についての条項を含めることが、トラブル防止の観点から重要になる。
ペネトレーションテストでよくある失敗パターン3つ
ペネトレーションテストの失敗は、スコープ合意の不足・報告書の放置・診断会社選定の甘さという3つのパターンに集約される傾向がある。
パターン1：診断範囲の合意不足による本番環境への影響
診断範囲（スコープ）の合意が曖昧なまま実施すると、本番環境に想定外の負荷がかかり、システム停止やサービス停止につながる事例が指摘されている。特に稼働中の基幹システムや決済システムを対象にする場合、診断による負荷がそのまま業務影響に直結しやすい。
回避策：事前に対象システム・実施時間帯・禁止する攻撃手法（DoS系の手法を含めるか等）を明記したRoEを診断会社と合意し、本番環境への影響が懸念される場合は検証環境での実施や実施時間帯の調整を検討する。
パターン2：報告書の指摘事項が改修に反映されない
診断を実施して報告書を受け取った時点で対応が完了したと捉え、指摘された脆弱性の改修が後回しになるケースが見られる。診断はあくまで現状把握の手段であり、報告書の指摘事項が放置されると発見された脆弱性が攻撃者にとって有効な侵入経路として残り続ける。
回避策：報告書の指摘事項に優先度（緊急度・影響度）をつけて改修計画に落とし込み、改修後に再診断（リテスト）を行って修正が有効かを確認する運用をあらかじめ想定しておく。
パターン3：診断会社の実績・手法を確認しない選定
価格や納期だけで診断会社を選定し、実績や診断手法を十分に確認しないまま発注すると、自動診断ツールの実行結果をまとめただけの形式的な診断で終わり、実効性の低い結果しか得られない場合がある。手動診断の比重や診断員のスキルレベルによって、発見できる脆弱性の深さは大きく異なる。
回避策：診断会社の過去の診断実績・対応可能な診断手法（手動診断の有無）・診断員の資格や経験を事前に確認し、報告書のサンプルを提示してもらって指摘内容の具体性や再現手順の記載レベルを比較検討する。
よくある質問（FAQ）
Q1. ペネトレーションテストと脆弱性診断はどちらを受けるべきか
A. 目的が異なるため、両方を段階的に組み合わせるのが基本である。脆弱性診断は既知の脆弱性を網羅的に検出する「健康診断」に近く、コストを抑えて広く浅く現状を把握できる。一方ペネトレーションテストは、検出された脆弱性が実際に悪用可能か、侵入後にどこまで被害が広がるかを検証する「実地訓練」に近い。予算が限られる場合はまず脆弱性診断で全体を把握し、重要システムや個人情報を扱う領域に絞ってペネトレーションテストを実施する順序が現実的である。
Q2. ペネトレーションテストの実施頻度はどのくらいが目安か
A. 年1回を基本とし、システムに大きな変更があった際に追加で実施するのが目安である。新規サービスの公開、大規模な機能追加、インフラ構成の変更、他社との合併・統合などのタイミングでは、変更部分を対象にしたテストを別途行うことが望ましい。金融・医療など規制業種では、監督官庁のガイドラインや契約先からの要求で頻度が定められている場合があるため、自社の業種特有の要件を先に確認する必要がある。
Q3. 中小企業でもペネトレーションテストは必要か
A. 企業規模ではなく、扱う情報の重要度と攻撃を受けた際の影響範囲で判断すべきである。中小企業であっても、顧客の個人情報や取引先の機密情報を扱うシステムを持つ場合、攻撃者から見れば十分な標的になる。近年はサプライチェーンの一部として中小企業が攻撃の入り口にされる事例も指摘されており、規模の小さいシステムから低コストで診断範囲を限定して始める方法もある。全システムを一度に対象にする必要はなく、優先度の高い範囲から段階的に取り組む考え方が現実的である。
Q4. ペネトレーションテストで本番環境に障害は起きないか
A. 事前にスコープと実施条件を合意しておけば、障害のリスクは大幅に抑えられる。実施前には対象範囲・攻撃手法の範囲・実施時間帯・緊急停止の連絡体制を診断会社と取り決め、業務への影響が大きいテストは本番環境ではなく検証環境で行う選択肢もある。合意なく本番環境で無制限に攻撃手法を試すことは避けるべきであり、契約書や実施計画書にスコープを明記したうえで開始することが不可欠である。
Q5. ペネトレーションテストの結果はどのように活用すればよいか
A. 報告書を受け取って終わりにせず、リスクの高い項目から改修計画に落とし込むことが重要である。報告書には検出された脆弱性の深刻度や再現手順が記載されるため、深刻度の高いものから対応期限を設定し、改修後は再テストで修正が有効か確認する。加えて、テストで判明した課題を社内のセキュリティポリシーや開発プロセスの見直しに反映させることで、同種の問題の再発を防ぐことができる。
Q6. ペネトレーションテストの依頼先はどう選べばよいか（社内実施と外部委託の違い）
A. 専門人材やツールを継続的に確保できるかどうかで判断するのが基本である。社内実施は自社システムへの理解が深く機動的に動ける一方、攻撃者視点の専門知識や最新の攻撃手法への追随が課題になりやすい。外部委託は専門性と客観性を確保しやすいが、委託先の実績・診断範囲の網羅性・報告書の実効性・改修支援の有無を事前に確認する必要がある。委託先を選ぶ際は、見積もり時にスコープの合意内容と報告書のサンプルを確認することが失敗を避ける近道である。
まとめ｜今日からできる3つのこと
- 自社システムの診断対象範囲（Webアプリ／ネットワーク／クラウド等）を棚卸しする
- 業種特有の規制要件（金融・医療・EC等）を確認し、必要な診断スコープを整理する
- 診断会社選定時はスコープ合意・報告書の実効性・事後の改修支援体制を確認する
ペネトレーションテストは、一度実施すれば終わりという性質のものではない。システムの変化や新たな攻撃手法の登場に合わせて、診断対象と実施体制を見直し続けることが本質的な備えになる。まずは自社の診断対象範囲を洗い出し、業種特有の規制要件を踏まえたスコープを整理するところから始めれば、次に取るべき行動は自然に見えてくる。診断会社との連携体制を整えながら、無理のない範囲で継続的な取り組みへとつなげていくことが望ましい。
参考文献
- 独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威」（各年版、IPA公式サイト参照）
- 独立行政法人情報処理推進機構（IPA）「安全なウェブサイトの作り方」（IPA公式サイト参照）
- 経済産業省・独立行政法人情報処理推進機構（IPA）「サイバーセキュリティ経営ガイドライン」（経済産業省公式サイト参照）
- 厚生労働省「医療情報システムの安全管理に関するガイドライン」（厚生労働省公式サイト参照）
- 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」（個人情報保護委員会公式サイト参照）
- 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」等の監督指針（金融庁公式サイト参照）
- 総務省「サイバーセキュリティ関連の政策・ガイドライン」（総務省公式サイト参照）
この記事に興味を持った方におすすめ
