ペネトレーションテストとは？脆弱性診断との違いを解説

用語解説

【更新 2026-07-20】本記事を見直し、修正しました。主な修正点：PCI DSSのセグメンテーション制御のテスト頻度について、「少なくとも6か月ごと」はサービスプロバイダ（要件11.4.6）に適用される頻度であり、すべての事業者に適用される要件11.4.5は「少なくとも12か月ごと」であるため、両者を区別して記述を修正しました。あわせて要件11.4の実施頻度（12か月ごと・重大な変更後）を明記しました。

ペネトレーションテスト（侵入テスト）とは、実際の攻撃者と同じ手口を模擬してシステムに侵入を試み、防御機能を回避して目的を達成できるかどうかを検証するセキュリティテストです。「脆弱性が存在しそうか」を洗い出す脆弱性診断とは目的が異なり、「本当に突破できるのか」を実証するところに価値があります。

混同されやすい両者ですが、費用も期間も、そして経営層への説明のしかたも変わります。この記事では一次情報をもとに違いを整理し、発注する側の情シスが事前に決めておくべきことまでを扱います。

この記事でわかること

  • ペネトレーションテストの定義と、脆弱性診断との決定的な違い
  • NIST SP 800-115が示す4段階の進め方
  • 外部／内部、公然／非公然といったテストの型の選び分け
  • 発注前に必ず決めるべき範囲・停止条件・報告の受け取り方
  • 依頼先を選ぶときに使える公的な事業者リスト

ペネトレーションテストとは何か？

米国国立標準技術研究所（NIST）が2008年9月に発行したSP 800-115「Technical Guide to Information Security Testing and Assessment」は、ペネトレーションテストを「評価者が実世界の攻撃を模倣し、アプリケーション・システム・ネットワークのセキュリティ機能を回避する方法を特定するセキュリティテスト」と定義しています。実システム・実データに対して、攻撃者が使うのと同じツールと技術で本物の攻撃を仕掛けることが多い、とも明記されています。

同文書が挙げるペネトレーションテストの意義は、単なる欠陥探しにとどまりません。

  • システムが実際の攻撃パターンにどれだけ耐えられるか
  • 侵害に成功するために攻撃者が必要とする技術水準はどの程度か
  • 脅威を緩和するために追加すべき対策は何か
  • 防御側が攻撃を検知し、適切に対応できるか

4つ目が重要です。ペネトレーションテストは、システムだけでなく自組織の検知・対応体制そのものを試すテストでもあります。SIEMのアラートが上がったか、担当者が気づいたか、エスカレーションが回ったか——ここが評価対象になるのが、機械的なスキャンとの大きな違いです。

技術的な攻撃だけとは限らない

SP 800-115は、ペネトレーションテストがしばしば非技術的な攻撃手法を含むことにも触れています。物理的なセキュリティ管理を突破してネットワークに接続する、機器を持ち出す、あるいはヘルプデスク担当者を装って利用者のパスワードを聞き出すといったソーシャルエンジニアリングです。

物理侵入を含める場合、警備員がテスターの正当性を確認する手段（連絡先や書面）を用意しておくよう同文書は注意を促しています。実際に警備員に取り押さえられるトラブルは海外で報道例があり、机上で軽く扱ってよい論点ではありません。

脆弱性診断とはどう違うのか？

端的にいえば、脆弱性診断は「弱点の網羅的な洗い出し」、ペネトレーションテストは「侵入の可否の実証」です。SP 800-115は「脆弱性スキャナは脆弱性が存在する可能性を確認するだけだが、ペネトレーションテストの攻撃フェーズはそれを悪用して存在を確定させる」と両者を対比しています。

観点 脆弱性診断 ペネトレーションテスト
目的 存在しうる脆弱性・設定不備を網羅的に検出する 特定の攻撃目標が達成可能かを実証する
網羅性 広く浅く（対象全体をスキャン） 狭く深く（侵入経路を掘り下げる）
手段 ツール中心（一部手動） 手動中心。脆弱性の連鎖を組み立てる
成果物 脆弱性一覧と深刻度評価 侵入シナリオ、到達できた資産、検知状況
向く場面 定期的な健康診断、リリース前チェック 対策が一通り入った後の実効性検証

ここで押さえたいのは、SP 800-115が「ほとんどのペネトレーションテストは、単一の脆弱性では得られない以上のアクセスを得るために、1つ以上のシステム上の脆弱性の組み合わせを探す」と述べている点です。個々には「深刻度：中」でしかない不備が、3つ連鎖するとドメイン管理者権限に届く。この連鎖はスキャナのスコアを眺めているだけでは見えません。CVSSスコアだけで優先順位を決める運用の限界を突きつけてくるのが、ペネトレーションテストの報告書です。

順序としては、脆弱性診断で明らかな穴を塞ぎ、パッチ適用や権限設計が一定水準に達してからペネトレーションテストに進むのが合理的です。穴だらけの状態で侵入テストを依頼しても、「入れました」という当たり前の結論に高い費用を払うことになります。

どのように進むのか？（4段階の進め方）

SP 800-115は、ペネトレーションテストを計画（Planning）／探索（Discovery）／攻撃（Attack）／報告（Reporting）の4段階として図示しています。

1. 計画フェーズ

実際の攻撃はまだ行いません。ここで評価計画、いわゆるROE（Rules of Engagement／実施ルール）を策定します。対象範囲、実施期間、禁止事項、緊急連絡先を文書化する工程で、発注側の情シスが最も深く関与すべき段階です。

2. 探索フェーズ

2つの部分に分かれます。前半は情報収集とスキャンで、ポート・サービスの特定、DNSやWHOISからのホスト名・IPアドレスの収集、公開Webサイトからの従業員名や連絡先の収集、バナー情報からのバージョン特定などを行います。後半は脆弱性分析で、検出したサービスやOSをNVD（National Vulnerability Database）などの脆弱性データベースや、テスター自身の知見と突き合わせます。

同文書は、手動のプロセスは自動スキャナより大幅に遅い一方で、スキャナが見逃す新しい／目立たない脆弱性を見つけられると述べています。ペネトレーションテストが人件費型のサービスになる理由がここにあります。

3. 攻撃フェーズ

テストの中核です。探索フェーズで特定した脆弱性を実際に悪用し、存在を確認します。SP 800-115が挙げる、悪用されやすい脆弱性の類型は次のとおりです。

  • 設定不備：とくに安全でないデフォルト設定は容易に悪用される
  • カーネルの欠陥：システム全体のセキュリティモデルが危険にさらされる
  • バッファオーバーフロー：入力長の検査不足により任意コードが実行される
  • 入力検証の不足：SQLインジェクションなどの原因になる
  • シンボリックリンク／ファイルディスクリプタの悪用
  • 競合状態（レースコンディション）
  • 不適切なファイル・ディレクトリ権限

攻撃が成功しても、いきなり最大権限が取れるとは限りません。多くの場合はネットワークについての新たな情報が得られるだけで、テスターはそこから権限昇格を試み、ラテラルムーブメント（横展開）で別のシステムへと足場を広げていきます。だからこそ攻撃フェーズから探索フェーズへは矢印が戻り、ループ構造になっています。

4. 報告フェーズ

報告は最後にまとめて行うものではなく、他の3フェーズと同時並行で進みます。探索・攻撃の各フェーズでは記録が残され、管理者や管理層への定期報告が行われます。最終的に、特定した脆弱性、リスク評価、緩和策の指針をまとめた報告書が作成されます。

テストにはどんな型があるのか？

SP 800-115は視点の違いで2軸を提示しています。発注時に「どの型で頼むか」を決める必要があるため、押さえておくと会話が早くなります。

外部テストと内部テスト

外部テストは組織の外側、インターネット側から実施します。内部テストは社内ネットワークに接続した状態から実施し、内部犯行や、フィッシングで端末1台を奪われた後の被害範囲を評価します。同文書は、両方を実施する場合は通常は外部テストを先に行うとしています。

侵入されること自体を前提に置くなら、内部テストの価値は高いといえます。「1台やられたら全社が落ちるのか、その部門で止まるのか」を数字で示せるからです。

公然（Overt）と非公然（Covert）

公然テストは、IT部門の了解と協力のもとで実施します。非公然テストは、組織内のごく限られた人しか実施を知らない状態で行い、防御側の検知・対応能力を実地で測ります。いわゆるレッドチーム演習に近い形式です。

非公然テストは得るものが大きい反面、運用への影響と社内の心理的負荷も大きくなります。SOCやCSIRTを立ち上げたばかりの組織がいきなり非公然でやると、単に「検知できませんでした」という結果と、担当者の疲弊だけが残ることがあります。まずは公然テストで手順を確認し、成熟してから非公然に進むほうが健全です。

与える情報量による分類

テスターに事前情報をどこまで渡すかによる区別もあります。SP 800-115は、外部からの攻撃者を模擬する場合、テスターには対象環境についての実質的な情報を与えず、公開情報から自力で調べさせるシナリオを説明しています。実務では情報を与えない形をブラックボックス、設計書やアカウントを渡す形をホワイトボックスと呼び分けることが一般的です。

限られた予算で深い検証を求めるなら、情報を渡すほうが効率的です。偵察に費やす工数を、攻撃の掘り下げに回せるからです。

情シスは発注時に何を決めるべきか？

ペネトレーションテストの成否は、テスターの腕前と同じくらい発注側の準備で決まります。SP 800-115は「ペネトレーションテストは非常に価値がある一方で、労力を要し、対象システムへのリスクを最小化するには高度な専門性が必要」であり、「テストの過程でシステムが損傷したり動作不能になったりする可能性がある」と率直に警告しています。経験豊富なテスターでもこのリスクは完全には排除できない、とも書かれています。

そのうえで、実施は「慎重な検討、通知、計画のうえで初めて行うべき」とされています。最低限、次の項目は契約前に文書で固めておきたいところです。

  • 目標（ゴール）：「侵入できるか」ではなく「顧客データベースに到達できるか」「基幹システムの管理者権限を取れるか」まで具体化する
  • 対象範囲：IPレンジ、ドメイン、対象外システム。クラウド利用時は事業者側のテスト実施ポリシーの確認が必要
  • 実施時期と時間帯：業務ピークや決算期を外す
  • 停止条件（ストップ条件）：どういう事象が起きたら即座に中断し、誰に連絡するか
  • 社内の周知範囲：公然か非公然か。非公然なら、テストであることを証明できる責任者を決めておく
  • 報告書の粒度：経営層向けサマリーと技術者向け詳細の両方を求めるか

とくに停止条件は軽視されがちです。「本番環境で試すのか」「取得したデータをどう扱い、いつ破棄するのか」まで詰めておかないと、テスト自体がインシデントになりかねません。

現場目線の所感

ペネトレーションテストで一番つらいのは、報告書が出た後です。「ここから入られて、ここまで到達されました」という事実は経営層に響きやすく、予算が付くきっかけにもなります。しかし同時に、指摘された穴を塞ぐ作業は通常業務の上に積み上がります。既存システムの構成変更が絡めば、業務部門との調整も必要になる。テストを実施する前に、修正のための工数と予算をあらかじめ確保しておくことを強くおすすめします。

もう一つ、報告書の「検知できたかどうか」の記述は、実は最も価値が高い部分だと感じています。脆弱性は塞げば終わりますが、検知できなかったという事実は運用の問題であり、ログ設計やアラートのしきい値といった継続的な改善に直結するからです。ここを読み飛ばして脆弱性一覧だけ潰すのは、もったいない使い方です。

なお、テストは実施した時点のスナップショットにすぎません。翌週に新しいサーバが立ち、翌月に新しいSaaSが契約されれば、攻撃対象領域は変わります。年1回のテストで安心するのではなく、日々の資産管理やパッチ適用と組み合わせて初めて意味を持ちます。

依頼先はどう選べばよいか？

ペネトレーションテストは、攻撃と同じ行為を自組織に許可して行わせるサービスです。事業者の技術力と倫理・情報管理体制の両方を確認する必要があります。

選定の出発点として使えるのが、IPAが公開している情報セキュリティサービス基準適合サービスリストです。一定の基準に適合していると確認されたサービスが分野別に掲載されており、脆弱性診断サービスと、その付帯サービスとしてのペネトレーションテスト（侵入試験）サービスが整理されています。まずここで候補を絞り、実績や報告書のサンプルを確認するのが手堅い進め方です。

そもそも自社がテストを実施すべき状況にあるか迷う場合は、中小企業の情報セキュリティ対策ガイドラインで足元の対策状況を点検し、基礎的な対策が入っているかを先に確認してください。侵入テストは、基礎対策が済んだ組織が次に打つ手です。

業界によっては実施が要件化されている点も押さえておきましょう。クレジットカード業界のセキュリティ基準であるPCI DSS（v4.x）は、要件11.4で外部および内部のペネトレーションテストを少なくとも12か月ごと、および重大なインフラ・アプリケーションの変更後に実施し、検出された悪用可能な脆弱性を修正して再テストすることを求めています。加えて、ネットワーク分離（セグメンテーション）の制御については、すべての事業者が少なくとも12か月ごと（要件11.4.5）、サービスプロバイダは少なくとも6か月ごと（要件11.4.6）、いずれも分離方式の変更後にもテストを行うことが定められています。カード情報を扱う環境を持つ組織は、自社が事業者・サービスプロバイダのどちらに当たるかを含め、適用要件を確認してください。

まとめ

  • 脆弱性診断は「弱点の洗い出し」、ペネトレーションテストは「侵入できるかの実証」。目的が違うので、基礎対策と診断を済ませてから侵入テストに進むのが合理的です。
  • 計画・探索・攻撃・報告の4段階で進み、攻撃から探索へ戻るループで足場を広げていきます。報告は他フェーズと並行して行われます。
  • 成否は発注側の準備で決まる。目標・範囲・停止条件・周知範囲を文書化し、指摘を直すための工数と予算をあらかじめ確保しておきましょう。

関連記事

出典

タイトルとURLをコピーしました