ペネトレーションテストの進め方と報告書の書き方。スコープ・許可・手順・報告を実務目線で整理する

ペネトレーションテスト（侵入テスト）は、攻撃者の視点で実際にシステムへ侵入を試み、どこまで到達できるか・どんな影響が出るかを検証する評価手法です。脆弱性スキャナが「弱点の候補」を機械的に列挙するのに対し、ペネトレーションテストは「その弱点を本当に悪用できるのか」「悪用するとどこまで深刻な事態に至るのか」を、人の判断と手作業で確かめるところに価値があります。発見された一つの弱点を起点に、権限昇格や横展開を重ねて重要資産まで到達できることを示す。この一連の物語こそが、机上のリスク評価では得られない説得力を生みます。

一方で、ペネトレーションテストは本質的に「攻撃そのもの」です。許可の範囲を一歩でも超えれば、それは検証ではなく不正アクセスになります。価値あるテストにするためには、技術力の前に、スコープと許可の設計、そして結果を意思決定につなげる報告書の質が問われます。この記事では、テストの進め方をスコープ定義・許可取得・実施手順・報告書作成の順に、依頼する側・実施する側の双方の実務目線で整理します。

なお本記事で扱う手順や手法は、自分が管理する環境、または書面で明確に許可された対象に対してのみ用いてください。許可のない調査・攻撃は、後述するとおり法令や利用規約に抵触するおそれがあります。

全体像。4つのフェーズで捉える#

ペネトレーションテストは行き当たりばったりに「攻撃してみる」ものではありません。確立した方法論に沿って段階的に進めることで、抜け漏れを防ぎ、結果の再現性と説明可能性を担保します。代表的な方法論には、コミュニティ標準のPTES（Penetration Testing Execution Standard）や、米国NISTが公開する技術ガイドであるNIST SP 800-115、Webアプリに特化したOWASP Web Security Testing Guide（WSTG）などがあります。

本記事では、これらに共通する流れを実務上の4つのフェーズに整理して扱います。早見表で全体像をつかんでおきましょう。

PTESはこれをさらに細かく7段階（事前準備、情報収集、脅威モデリング、脆弱性分析、悪用、事後活動、報告）に分けています。どの方法論を採るにせよ、「準備で範囲と許可を固め、収集で攻撃面を把握し、検証で影響を確かめ、報告で意思決定につなげる」という骨格は共通です。

NIST SP 800-115「Technical Guide to Information Security Testing and Assessment」は、技術的なセキュリティテストと評価の計画・実施・運用に関する実務的な推奨をまとめた公開ガイドです（2008年9月公開、SP 800-42を置き換え）。テストの種類ごとの長所・短所と、適切な実施方法の指針が整理されています。

フェーズ1。スコープ定義と許可。ここで9割が決まる#

ペネトレーションテストで最も重要なのは、攻撃の技術ではなく、何をどこまで対象にするか（スコープ）と、それが正式に許可されているか（オーソリゼーション）の設計です。ここが曖昧なまま手を動かすと、価値が出ないだけでなく、本番障害や法的トラブルを招きます。

スコープに含めるべき要素#

スコープは「対象資産」だけでなく、「やってよいこと・いけないこと」まで含めて定義します。最低限、次を明文化します。

• 対象（in-scope）: 検証対象のIPアドレス・ドメイン・アプリ・APIを具体的に列挙する。レンジ指定よりも明示列挙が安全です。
• 対象外（out-of-scope）: 触れてはいけない資産を明記する。共有基盤や第三者のサービス、本番の決済系などは特に注意が必要です。
• 許可される手法: たとえば「DoSは禁止」「ソーシャルエンジニアリングは含む／含まない」「物理侵入は対象外」など、手法レベルで合意します。
• テスト環境の種別: 本番か、ステージングか、複製環境か。本番を対象にする場合は影響範囲の合意とロールバック手順が必須です。
• 実施時間帯: 業務影響を避けるための時間帯指定。深夜帯指定や、逆に「監視チームが対応できる日中のみ」といった指定もあります。

Rules of Engagement（ROE）と許可書面#

スコープと並んで欠かせないのが、Rules of Engagement（交戦規定）です。これは「誰が・いつ・何を・どこまで・どう報告するか」を定めた合意で、緊急連絡先、テスト中に重大な脆弱性や進行中の侵害を見つけた場合のエスカレーション手順、証跡の取り扱い、データの持ち出し可否などを含みます。

そして、これらを反映した許可書面（authorization、いわゆる「Get Out of Jail Free Letter」と呼ばれる正式な許可状）を、対象資産の正当な権限保持者の署名付きで取得します。クラウド利用時は、クラウド事業者側のテストポリシーの確認も必要です。サブドメインや外部SaaSが対象に紛れ込むと、自社の許可だけでは足りないケースがあるためです。

依頼する側にとっても、スコープと許可の設計はテストの費用対効果を左右します。狙いを「外部公開資産の侵入可否」に絞るのか、「侵入後にどこまで横展開できるか」まで見るのかで、必要な工数も得られる知見も大きく変わるからです。

フェーズ2。情報収集と偵察#

許可が固まったら、対象の攻撃面（attack surface）を把握する情報収集に入ります。ここでの目的は、闇雲に攻撃を始めることではなく、「どこに弱点がありそうか」の仮説を立てるための材料を集めることです。

情報収集は大きく、対象に直接アクセスしない受動的（パッシブ）な収集と、対象に問い合わせる能動的（アクティブ）な収集に分かれます。パッシブな収集は公開情報の調査（OSINT）が中心で、DNS情報、公開されている技術スタック、漏えい情報の有無などを確認します。アクティブな収集では、ポートスキャンやサービスの列挙（enumeration）で、稼働中のサービス・バージョン・公開されているエンドポイントを把握します。

ここで重要なのは、アクティブな収集はすでに「対象への接触」であり、スコープと許可の範囲内で行うという点です。スキャン対象がスコープ外のホストに及んでいないか、レンジ指定が広すぎないかを必ず確認します。情報収集（偵察・OSINT）の具体的な進め方は

フェーズ3。検証。脆弱性分析から悪用、事後活動まで#

集めた情報をもとに、弱点を特定し、実際に悪用できるかを検証します。このフェーズはさらに、脆弱性の分析、悪用の試行、悪用後の事後活動（権限昇格・横展開）に分かれます。

脆弱性分析と悪用の試行#

まず、収集した攻撃面に対して、既知の脆弱性や設定不備、認証・認可の欠陥などの候補を洗い出します。脆弱性スキャナの結果はあくまで「候補」であり、誤検知（false positive）が混じります。ペネトレーションテストの肝は、この候補を人手で検証し、本当に悪用できるものだけを「確からしい指摘」に昇格させることです。

悪用の試行では、検証で確認した弱点を実際に突いて、認証回避やデータ取得などが可能かを確かめます。ここで必ず守るべきは、本番環境では破壊的な操作（データ削除、可用性を損なうDoS等）を避け、ROEで合意した範囲を超えないことです。証跡として、再現に必要な最小限のリクエスト・レスポンスやスクリーンショットを記録します。後述する報告書の「再現手順」の元になるため、何を・どの順で行ったかを淡々と残すことが大切です。

事後活動（Post-exploitation）#

侵入できた場合、その影響範囲を示すために権限昇格や横展開（lateral movement）を検証します。「一つの弱点から、最終的に重要資産へ到達できる」という連鎖を示せると、ビジネス上のリスクが具体的に伝わります。ただしここでも、取得したデータの取り扱いや到達範囲はROEの合意に従い、必要以上に深追いしないこと、そして検証後に作成したアカウントやアップロードしたファイルなどの痕跡を撤去（クリーンアップ）することが実務上の礼儀でありルールです。

深刻度はどう付けるか#

検出した指摘には深刻度を付けます。属人的な「高・中・低」だけでは依頼側が優先順位を判断しづらいため、CVSS（共通脆弱性評価システム）のような共通の物差しを併用すると、指摘間の比較や経年での追跡がしやすくなります。ただしCVSSの基本値は「その脆弱性単体の技術的深刻度」を表すもので、実際の対応優先度は、その資産の重要性・到達経路の現実性・既存の緩和策といった環境要因で上下します。スコアを機械的に並べるのではなく、「この環境で、攻撃者がどれだけ容易に・どれだけ深刻な影響を起こせるか」という文脈を添えて伝えることが、報告の価値を決めます。

フェーズ4。報告書の書き方。意思決定につなげる二層構成#

ペネトレーションテストの成果物は「攻撃の記録」ではなく「次の一手を決められる報告書」です。どれだけ高度な侵入に成功しても、報告書が読み手に伝わらなければ、リスクは減りません。報告書は、読み手の異なる二つの層を意識して構成します。

エグゼクティブサマリ（経営・意思決定者向け）#

技術用語を避け、ビジネスへの影響と全体評価を簡潔にまとめます。具体的には、テストの目的と範囲、総合的なリスク評価、見つかった問題の深刻度別の件数、そして「もしこのまま放置すると何が起きうるか」を平易な言葉で示します。CVSSスコアの羅列ではなく、「外部から認証を回避し、顧客情報の閲覧に至る経路が確認された」といった、影響を物語る一文が意思決定を動かします。

技術詳細（開発・運用者向け）#

修正にあたる担当者が、指摘を再現し、原因を理解し、対策できるだけの情報を載せます。各指摘について次をセットで書くのが基本です。

報告書の落とし穴は、「指摘の列挙」で終わってしまうことです。読み手が知りたいのは「どれから直すべきか」です。深刻度・修正コスト・到達経路の現実性をふまえた優先順位の提案まで踏み込むと、報告書は一気に実務の道具になります。逆に、確証のない指摘（誤検知の可能性が残るもの）は「要確認」と明記し、断定を避けるのが誠実です。

OWASP Web Security Testing Guide（WSTG）は、Webアプリケーションのセキュリティテストの体系的な手順をまとめた無償のガイドです（安定版は2020年12月公開のv4.2）。テスト項目ごとの観点と手法が整理されており、Webを対象とする検証や、報告書の対策の参照先として有用です。

依頼する側が押さえる進め方#

ここまで実施側を中心に述べましたが、外部にテストを依頼する側にも押さえどころがあります。良いテストは、依頼の質に強く依存するからです。

• 目的を言語化する: 「とりあえず脆弱性を見てほしい」ではなく、「公開Webから顧客DBに到達できないか」「新規リリース機能の認可不備」など、検証したい仮説を具体化します。目的が絞れるほど、限られた工数で深い検証ができます。
• 環境と許可を整える: 本番を対象にするのか、複製環境を用意するのか。社内の関係部署やクラウド事業者の許可・ポリシーを事前に確認します。
• 報告の形式を合意する: エグゼクティブサマリの要否、深刻度の基準（CVSSの版を含む）、再報告（再テスト）の有無を事前にすり合わせます。
• 結果を運用に乗せる: 報告書は受け取って終わりではありません。指摘を脆弱性管理のプロセスに乗せ、修正の期限・担当・再検証までを追跡してはじめて、テストの投資が回収されます。

最後の「運用に乗せる」が、実は最も価値を左右します。深刻度の高い指摘を放置すれば、テスト費用はリスクを可視化しただけで終わってしまいます。指摘を継続的な脆弱性管理のサイクル（特定・評価・修正・再検証）に組み込むことを前提に、テストを計画してください。

よくある質問#

まとめ#

ペネトレーションテストは、攻撃者の視点でリスクを「物語」として可視化し、防御の意思決定につなげる強力な手法です。その価値は、派手な侵入の成否ではなく、スコープと許可の設計、そして読み手を動かす報告書の質で決まります。そして大前提として、すべては許可された対象の中で行われなければなりません。攻撃を理解する目的は、あくまで自分たちのシステムを守ること。許可と法令を守りながら、テストの結果を継続的な改善のサイクルへとつなげていきましょう。