ペネトレーションテストとは？脆弱性診断との違い・種類・実施方法をNIST・NCSC資料から解説

ペネトレーションテスト（侵入テスト）は、攻撃者が使う手法や考え方を模して、実際のシステムにどこまで侵入できるか、侵入後にどの資産まで到達できるかを許可された範囲で検証するセキュリティテストです。

米国NISTは、ペネトレーションテストを「実際の攻撃を模倣し、アプリケーション、システム、ネットワークのセキュリティ機能を回避できる経路を特定するテスト」と整理しています。英国NCSCも、攻撃者と同様のツールや技術を使ってセキュリティを突破しようとすることで、ITシステムの安全性について保証を得る方法と定義しています。

一方、ペネトレーションテストは、脆弱性を網羅的に探すための代替手段ではありません。NCSCは、脆弱性評価・管理プロセスが機能しているかを検証する手段として位置付けており、日常的な脆弱性管理と組み合わせる考え方を示しています。

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

NIST SP 800-53 Rev.5のCA-8では、ペネトレーションテストについて、攻撃者が悪用できる脆弱性を特定し、システムが攻撃へどの程度耐えられるかを確認する専門的な評価としています。自動化された脆弱性スキャンを超え、ネットワーク、OS、アプリケーションなどの専門知識を持つ担当者が、攻撃者の行動を模して検証します。

NIST SP 800-115でも、単一の脆弱性だけではなく、複数のシステムや複数の弱点を組み合わせた場合に、どこまでアクセスを拡大できるかを見る点がペネトレーションテストの特徴として示されています。

たとえば、インターネット公開されたVPNやWebアプリケーションに弱点があったとしても、企業が知りたいのは「脆弱性が1件ある」という事実だけとは限りません。

• その弱点から本当に内部へ到達できるか
• 一般ユーザー権限から管理者権限へ拡大できるか
• ネットワーク分離が横展開を止められるか
• 重要サーバーや機密データまで到達できるか
• EDR、SIEM、SOCが攻撃行動を検知できるか

こうした「攻撃経路」と「実際の影響」を確かめるのがペネトレーションテストです。

関連：ペネトレーションテストと脆弱性診断の違い｜目的・手法・頻度・使い分けを比較

ペネトレーションテストと脆弱性診断の違い

脆弱性診断とペネトレーションテストは、どちらもシステムの弱点を調べますが、目的が異なります。

オーストラリア政府のInformation Security Manual（ISM）は、脆弱性スキャンを「既知の脆弱性を自動的に確認する活動」、脆弱性評価を「システムアーキテクチャのレビューや詳細なハンズオン評価」、ペネトレーションテストを「重要なシステムやデータの侵害など、特定の目標を達成できるか実環境に近いシナリオで検証する活動」と整理しています。

比較項目	脆弱性診断・脆弱性評価	ペネトレーションテスト
主な目的	脆弱性や設定不備を広く発見する	脆弱性を悪用した場合の侵入可能性・影響を確認する
基本的な問い	「どこに弱点があるか」	「攻撃者は何を達成できるか」
手法	自動スキャン、設定確認、手動診断など	攻撃シナリオ、手動検証、複数の弱点の組み合わせ
網羅性	対象範囲の弱点を広く洗い出しやすい	限られた期間・シナリオで深く検証する
実施頻度	継続・定期実施に向く	リスクや変更に応じて定期・節目で実施
主な成果物	脆弱性一覧、重要度、修正案	攻撃経路、到達可能な資産、影響、改善策
置き換え可能か	ペンテストの代替ではない	脆弱性管理の代替ではない

NCSCは、ペネトレーションテストを脆弱性発見の「主要な方法」として使うべきではないと明記しています。テスト時点で問題が見つからなくても、翌日に新しい脆弱性が公開される可能性があります。

既存の脆弱性診断については、脆弱性診断とは？目的や種類、実施頻度をUS・UK公的機関の推奨から解説で整理しています。

ペネトレーションテストの主な種類

ペネトレーションテストは、対象、攻撃者に与える情報、検証したいシナリオによって設計が変わります。

外部からのペネトレーションテスト

インターネット側から到達できるVPN、ファイアウォール、Webアプリケーション、API、公開サーバーなどを対象にします。

CISAもRemote Penetration Testについて、攻撃者がネットワークへ不正アクセスする際の手法を模し、境界防御をテストするサービスと説明しています。

確認対象には、外部公開サービス、認証、設定不備、既知の脆弱性、侵入後に到達できるネットワークなどが含まれます。

内部からのペネトレーションテスト

NIST SP 800-53は、ペネトレーションテストを内部・外部の双方から実施できるとしています。

内部テストでは、攻撃者がすでに従業員端末や一般ユーザーアカウントを侵害した状態を想定し、

• 権限昇格できるか
• 他の端末やサーバーへ横展開できるか
• Active Directoryなどの認証基盤へ到達できるか
• 管理ネットワークが分離されているか
• 重要データへアクセスできるか

などを検証します。

境界防御だけではなく、侵入後の被害半径を確認したい場合に使います。

Webアプリケーション・APIを対象としたテスト

WebアプリケーションやAPIでは、認証・認可、入力値処理、セッション、業務ロジック、ファイル処理、バックエンドとの連携などを対象にします。

自動スキャナーだけでは判断しにくい「一般ユーザーが別ユーザーのデータへ到達できるか」「複数の機能を組み合わせると権限外の処理が可能か」といった問題は、手動検証を含むテストが適しています。

Open boxとClosed box

英国NCSCは、テスト担当者へ事前にどの程度情報を渡すかという観点から、次の2つを示しています。

方式	内容
Transparent / Open box	システム構成など対象の情報を十分に共有してテストする
Opaque / Closed box	対象内部の情報をほとんど共有せず、外部攻撃者に近い条件でテストする

Open boxは限られた期間で広く確認しやすく、Closed boxは未知の外部攻撃者に近い条件を再現できます。ただしNCSCは、Closed boxでは情報が少ないため、テスト期間内に脆弱性を発見できずに終わる場合があるとしています。

実務では両者の中間条件で実施するケースもあります。名称よりも、「テスターに何の情報・認証情報・構成情報を渡すか」を契約時に明確にする方が実施結果へ直結します。

シナリオ型テスト

NCSCは、紛失した端末、不正な端末の社内接続、DMZ上のホスト侵害など、特定の前提から攻撃経路を検証するシナリオ型テストを例示しています。

「VPNアカウントを1つ奪われたら何が起きるか」「インターネット公開サーバーが侵害されたら基幹系へ到達できるか」など、自社のインシデントや脅威モデルに合わせて設計できます。

ペネトレーションテストの実施方法

NCSCは、典型的なペネトレーションテストを「Initial engagement、Scoping、Testing、Reporting、Follow up」の流れで整理しています。NISTも、テスト前分析、潜在的な脆弱性の特定、悪用可能性の検証、Rules of Engagement（実施ルール）の合意を挙げています。

1. 目的を決める

最初に「何を知るためのテストか」を決めます。

目的が曖昧なまま「全部攻撃してください」と依頼すると、限られた期間を有効に使えません。

たとえば、

• インターネットから社内ネットワークへ侵入できるか
• VPN侵害後に重要サーバーへ横展開できるか
• Webアプリケーションから顧客データへ到達できるか
• EDRやSOCが一連の攻撃を検知できるか

など、確認したいリスクを明文化します。

2. スコープとRules of Engagementを決める

対象IPアドレス、ドメイン、アプリケーション、クラウド環境、テストアカウント、実施時間、禁止行為、連絡先などを決めます。

NCSCは、スコープ策定にリスクオーナー、対象システムを理解する技術担当者、ペネトレーションテスト担当者を参加させるよう示しています。

本番サービスを対象にする場合は特に、

• サービス停止につながる操作を許可するか
• 個人情報や本番データへ到達した場合にどこでテストを止めるか
• 外部クラウドや委託先環境を対象に含められるか
• インシデントと誤認しないため誰へ連絡するか
• 重大な脆弱性を発見した場合に即時報告するか

を事前に決めます。

NCSCは、ペネトレーションテストでは予期しないシステム反応を完全には排除できないと説明しています。

3. 既存の脆弱性情報を整理する

ペネトレーションテスト前に、資産情報や既存の脆弱性診断結果を整理します。

NCSCは、現在の脆弱性評価結果がある場合、スコープ策定時にテスターへ共有し、その正確性や完全性を検証できるようテストを設計する考え方を示しています。

ペネトレーションテストの時間を、既知CVEの洗い出しだけに使わず、「その弱点を組み合わせると実際に何が起こるか」の確認へ振り分けられます。

4. 許可されたシナリオで検証する

テスターは、合意した範囲で攻撃者の行動を模し、侵入可能性や権限拡大、横展開、重要資産への到達可否などを確認します。

本番システムを破壊したり、必要以上のデータを取得したりすることが目的ではありません。どこまで到達できた時点で「影響を確認できた」と判断するかを事前に決めておきます。

5. 結果を報告し、リスクを評価する

NCSCは、テスト報告書に、

• 発見したセキュリティ上の問題
• 各問題が組織・システムへ与えるリスク
• 修正方法
• 組織内の脆弱性評価の正確性に関する見解
• 脆弱性評価プロセスの改善案

を含めるよう示しています。

単独のCVSSスコアだけではなく、「この弱点からどのシステムへ到達できたか」「どの権限を取得できたか」を合わせて対応優先度を決めます。

6. 修正し、必要に応じて再テストする

報告書を受け取った時点で終了ではありません。

修正担当者、期限、暫定対策、受容するリスクを決め、重大な問題は再テストで修正を確認します。

NCSCは、リスク評価と修正判断をテスト会社へ丸ごと委ねるのではなく、組織自身が事業影響を踏まえて判断する必要があるとしています。

ペネトレーションテストはいつ実施するのか

実施頻度に、すべての企業へ共通する一律の回数はありません。

NIST SP 800-53のCA-8は、ペネトレーションテストの頻度と対象を組織が定義する形式です。一方、オーストラリア政府のISMは、同フレームワークの対象システムについて、導入前、重大な変更前、さらにその後少なくとも6カ月ごとの脆弱性評価・ペネトレーションテストを管理策として示しています。

これは日本企業へそのまま適用される法的義務ではありませんが、「年1回だから実施する」だけではなく、システムの変更とリスクを起点に実施時期を決める参考になります。

実務では次のタイミングを検討します。

• 新しい外部公開サービスの本番稼働前
• 認証基盤やネットワーク構成を大きく変更した後
• クラウド移行・データセンター移行後
• M&Aやグループ統合でネットワークを接続する前後
• 重要なWebアプリケーションを大規模改修した後
• インシデント後に再発防止策の有効性を確認するとき
• 定期的なリスク評価で攻撃経路の再確認が必要になったとき

脆弱性スキャンは、これより高い頻度で継続する必要があります。NISTのRA-5も、脆弱性の監視・スキャンを組織が定めた頻度で実施し、新しい脆弱性が対象へ影響する可能性がある場合にも確認する考え方を示しています。

実際のインシデントから見るペネトレーションテストの役割

セキュリティ対策Labで扱った国内事例にも、単一の脆弱性だけではなく「侵入後にどこまで到達できるか」を考える必要がある事案があります。

デジタル庁GSSではVPN侵入後に保守運用アカウントが利用された

2026年のデジタル庁GSSへの不正アクセスでは、VPN機器の脆弱性が侵入経路として悪用され、その後、保守運用担当者のアカウントを利用した大量のファイルアクセスが確認されました。悪用されたVPN脆弱性は当初CVSS「Medium」と評価されていました。

デジタル庁 GSSへの不正アクセス、保守運用アカウントの権限とゼロトラスト設計を検証

この事案について、事前のペネトレーションテストで被害を防げたと断定することはできません。ただし、VPN侵害を前提に「どこまで横展開できるか」「保守アカウントでどの範囲へアクセスできるか」をシナリオテストすることは、入口の脆弱性とは別の防御課題を確認する方法になります。

SQLインジェクションでデータベースが改ざんされた事例

「くすりのしおり」では、Webサイトの脆弱性を原因とするSQLインジェクション攻撃で、データベースの改ざんが確認されました。

くすりのしおり、SQLインジェクションによるサイバー攻撃の調査結果と再発防止策を発表

Webアプリケーションの入力処理の弱点は脆弱性診断で発見対象になります。さらにペネトレーションテストでは、発見した弱点から実際にどのデータや権限へ到達できるかを、許可された範囲で確認できます。

ここでも、公開情報だけから「ペネトレーションテストを実施していれば防げた」とは判断できません。事例から読み取れるのは、外部公開Webシステムの弱点を本番事故の前に確認する仕組みが必要という点です。

PPCは既知脆弱性放置や弱い認証を繰り返し指摘

個人情報保護委員会が2026年度第1四半期に行った監督では、VPN機器やECサイト関連アプリケーションの既知脆弱性放置、弱いパスワード、データベースのアクセス制御不備、RDPやポートの不適切な外部公開などが確認されました。

個人情報保護委員会、第1四半期に141件を指導　ランサムウェア15件、VPN脆弱性放置や弱い認証を問題視

こうした既知脆弱性や基本的な設定不備は、本来、継続的な資産管理・脆弱性スキャン・パッチ管理で対応する領域です。

ペネトレーションテストだけを年1回実施しても、日常の脆弱性管理を置き換えることはできません。

ペネトレーションテストで確認できないこと

ペネトレーションテストには限界があります。

NCSCは、ペネトレーションテストで保証できるのは、テストした対象が「テストした時点」で既知の問題に対してどうだったかという範囲に限られると説明しています。

主な制約は次のとおりです。

• テスト期間外に公開された脆弱性は評価できない
• スコープ外の資産は評価されない
• Closed boxでは時間内に弱点を発見できない場合がある
• テスターのスキルや経験によって結果が変わる
• 本番影響を避けるため試せない攻撃がある
• サプライチェーンや委託先など、契約上テストできない領域がある
• 「侵入できなかった」ことは将来も侵入されないことを保証しない

NCSCは、日常的な脆弱性評価を止めてペネトレーションテストだけに切り替えるべきではないとしています。

ペネトレーションテストを依頼するときの確認項目

情報システム部門やCSIRTが発注前に確認したい項目は次のとおりです。

• テストで答えたいリスクが明確か
• 対象IP、ドメイン、アプリ、クラウド、拠点を棚卸しできているか
• Open boxかClosed boxか、提供情報を決めているか
• 外部侵入、内部侵害、Webアプリなど想定シナリオが決まっているか
• 本番停止につながる操作の可否を決めているか
• 個人情報・機密データへ到達した場合の停止条件があるか
• 24時間連絡できる技術窓口を決めているか
• テスターに対象技術の経験があるか
• 報告書に攻撃経路、影響、修正案が含まれるか
• 修正後の再テスト条件が契約に含まれるか
• 診断結果を脆弱性管理へ戻す担当者と期限が決まっているか

NCSCは2026年7月、重要インフラ分野のペネトレーションテスターへのヒアリングを基に、ネットワーク分離、ログ監視、Secure by Designが攻撃者の横展開を難しくすると整理しています。テストの目的は「侵入された・されなかった」で終わることではなく、防御設計のどこを直すべきかを明らかにすることです。

まとめ

ペネトレーションテストは、脆弱性を広く列挙するための検査ではなく、攻撃者の視点で侵入経路と実際の影響を確かめる評価です。

企業では、継続的な脆弱性スキャン・脆弱性診断を基礎にし、その結果や自社の脅威シナリオを使ってペネトレーションテストの対象を決める運用が適しています。

発注時には「どの製品をテストするか」だけではなく、「どの侵害シナリオを検証し、どの状態まで到達したらリスクを確認できたと判断するか」を先に定義します。

出典

• SP 800-115, Technical Guide to Information Security Testing and Assessment – NIST
• SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations – NIST
• Penetration testing – UK National Cyber Security Centre
• Building more resilient CNI: what industry pen testers told us – UK National Cyber Security Centre
• Guidelines for security assurance – Australian Signals Directorate / Australian Cyber Security Centre
• Services – StopRansomware.gov / CISA
• Cyber Hygiene Services – CISA