--- title: "ペネトレーションテストとは？種類・手法・手順と実施前に必要な許可【2026年版】" url: "https://www.issoh.co.jp/column/details/1410/" published: 2023-09-21 updated: 2026-10-11 categories: ["セキュリティ"] publisher: "株式会社一創" --- # ペネトレーションテストとは？種類・手法・手順と実施前に必要な許可【2026年版】 ペネトレーションテスト（侵入テスト、ペンテスト）は、攻撃者と同じ手口でシステムへの侵入を試み、防御が機能するかを確かめる検査です。英語の penetrate は「貫通する・入り込む」という意味で、弱点の一覧を作る脆弱性診断とは違い、「どこから入られ、どこまで到達されるか」を経路として示します。この記事では種類と手法、NIST SP 800-115とPTESに沿った実施手順、工程ごとのツールを整理したうえで、見落とされやすい「実施前に誰の許可が要るか」（不正アクセス禁止法とAWS・Azure・Google Cloudの規約）と、PCI DSSが求める実施頻度と、金融庁がTLPTを促している対象までを一次情報で確認します。 ## まとめ：ペネトレーションテストの要点 - ペネトレーションテストは、攻撃目標（例：顧客DBへの到達）を決めて侵入経路を実証する検査。弱点を広く洗い出す脆弱性診断とは目的が違う。 - 工程はNIST SP 800-115の4段階（計画・発見・攻撃・報告）が基本形。PTESは同じ流れを7フェーズに細分化している。 - 許可が最重要。不正アクセス禁止法で違法にならない条件は「アクセス管理者の承諾」で、発注者がサーバーの管理者でなければ発注者の同意だけでは足りない。 - クラウドはAWS・Azure・Google Cloudとも自社リソースへの通常のテストなら事前申請は不要だが（AWSは模擬フィッシング等を除く）、DoSなど禁止行為が各社の規約で決まっている。 - カード情報を扱う環境はPCI DSS v4.0.1で12か月に1回以上と重要な変更後の実施が必須。金融機関には金融庁がTLPTを促している。 ## ペネトレーションテストの意味と目的 経済産業省の[情報セキュリティサービス基準](https://www.meti.go.jp/policy/netsecurity/shinsatouroku/touroku.html)（第4.1版、2025年4月1日施行）は、ペネトレーションテスト（侵入試験）サービスを、攻撃者が実際の侵入に使う手法と同様の手法でセキュリティ機能を回避し、攻撃目的を達成できるかを試験して助言するサービスとして定めています。同基準では脆弱性診断サービスの要件を満たしたうえで追加の技術要件を課す区分で、IPAの[情報セキュリティサービス基準適合サービスリスト](https://www.ipa.go.jp/security/service%5Flist.html)でも「脆弱性診断サービスのオプションサービス」と注記されています。 目的は、個々の脆弱性の深刻度ではなく組織としての実害を測ることです。たとえば「公開Webサーバーの脆弱性から社内ネットワークに入り、顧客データベースまで到達できるか」という目標を置き、到達できたならその経路と、途中で検知されたかどうかを報告します。CVSSで「中」程度の脆弱性でも、複数を組み合わせると重大な到達経路になることがあり、それを示せるのがペネトレーションテストの価値です。 ## 脆弱性診断・TLPTとの違い ### 脆弱性診断との違いは「網羅」か「到達の実証」か | 観点 | 脆弱性診断 | ペネトレーションテスト | | ---- | --------- | -------------- | | 目的 | 弱点を漏れなく検出 | 攻撃目標への到達を実証 | | 範囲 | 対象全体を広く | 目標までの経路を深く | | 到達目標 | 設定しない | 設定する | | 成果物 | 脆弱性一覧と深刻度 | 侵入経路・到達点・検知の有無 | 脆弱性診断で見つかった弱点を塞いでいない段階でペネトレーションテストを発注しても、既知の穴から入られて終わり、費用に見合う発見が出にくくなります。順番は「診断で既知の弱点を潰す→重要システムで侵入を試す」です。費用や頻度を含む使い分けは[ペネトレーションテストと脆弱性診断の違い｜目的・費用・使い分けを発注前に整理](/column/details/13440/)で、診断側の種類と進め方は[脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](/column/details/13101/)で扱っています。 ### TLPT（脅威ベースのペネトレーションテスト）との違いはスコープと通知 TLPT（Threat-Led Penetration Testing）は、自組織を狙う攻撃者の戦術を分析して再現し、防御だけでなく検知・対応の速さまで検証するテストです。金融庁の[金融分野におけるITレジリエンスに関する分析レポート](https://www.fsa.go.jp/news/r6/sonota/20250630-2/20250630.html)（2025年6月）は、TLPTでは脆弱性診断やペネトレーションテストと異なり特定のシステム単体に絞らず組織全体をスコープにすること、本番環境で実施すること、監視を担うブルーチーム（通常はCSIRTやSOC）には知らせずに行うことを推奨しています。同レポートは、ブルーチームに事前に情報を開示して実施した例を「リアルタイムの検知・対応能力の評価ができていない」不十分な事例として挙げています。 つまり一般的なペネトレーションテストは「特定システムに侵入できるか」、TLPTは「組織が実際の攻撃を検知して止められるか」を問います。ブルーチームの体制づくりは[CSIRT（シーサート）とは？情報セキュリティ体制での役割18種とSOC・PSIRTとの違い・構築手順](/column/details/10174/)が参考になります。 ## ペネトレーションテストの種類（攻撃対象別） | 種類 | 対象 | 確かめること | | ------------- | --------------- | ------------- | | 外部 | インターネット公開資産 | 外から社内への侵入可否 | | 内部 | 社内ネットワーク・端末 | 侵入後の横展開と権限昇格 | | Webアプリケーション | Webアプリ・API | 認証回避・データ窃取 | | クラウド | IaaS・PaaSの設定と権限 | IAMの過剰権限・設定不備 | | ソーシャルエンジニアリング | 従業員・業務プロセス | 標的型メール等での突破 | 内部ペネトレーションテスト（内部ペンテスト）は「社員の端末が1台乗っ取られた」状態から始め、Active Directoryの権限やファイルサーバーにどこまで届くかを見ます。ランサムウェア被害は侵入後の横展開で拡大することがあるため、外部テストだけでは被害規模を測れません。Webアプリケーションのテストでは、WAFが攻撃リクエストを止めるか・検知ログに残るかも確認対象になりますが、クラウド上のWAFを試す場合は後述の規約でフラッディングが禁止されている点に注意が必要です。WAFの検証では、遮断（403等）されたかだけでなく、検知のみモードで素通りしていないか、ログに攻撃種別が記録されたかを、許可済みの対象で確認します。 ## ペネトレーションテストの手法（事前情報の与え方による3分類） | 手法 | テスターに渡す情報 | 想定する攻撃者 | | -------- | ------------------- | --------------- | | ブラックボックス | 対象ドメイン程度 | 外部の攻撃者 | | グレーボックス | 一般ユーザーのアカウント・構成図の一部 | 取引先・認証情報を盗んだ攻撃者 | | ホワイトボックス | 設計書・ソースコード・管理者情報 | 内部不正・最悪ケース | テスト期間は日数で契約されるため、ブラックボックスでは情報収集に日数の多くを使い、侵入後の検証まで進めないまま終わることがあります。認証後の機能や内部の権限設計を見たいならグレーボックスを選び、ブラックボックスは「外部から何が見えているか」自体を知りたい場合に限るのが実務的です。ホワイトボックスはソースコードを読むため発見数は増えますが、脆弱性診断やコードレビューとの重複が大きくなります。 ## ペネトレーションテストの手順（NIST SP 800-115とPTES） ### NIST SP 800-115の4段階：計画・発見・攻撃・報告 米国立標準技術研究所の[NIST SP 800-115](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf)（2008年9月公表、2026年10月時点で改訂版なし）は、ペネトレーションテストを Planning（計画）・Discovery（発見）・Attack（攻撃）・Reporting（報告）の4段階に分けています。同文書の図5-1では、攻撃で得た情報をもとに発見段階へ戻る「Additional Discovery」のループがあり、報告は他の3段階と並行して進むものとして描かれています。 - 計画：対象範囲、到達目標、禁止行為、実施時間帯を合意し書面にする - 発見：ポートスキャンやサービスの特定、公開情報の収集で攻撃面を洗い出す - 攻撃：脆弱性を悪用して侵入し、権限昇格や横展開で目標を目指す。新たに見えた資産は発見段階に戻して調べる - 報告：侵入経路、到達点、再現手順、修正の優先順位をまとめる ### PTESの7フェーズとNISTの4段階の対応 民間の実務者がまとめた[PTES（Penetration Testing Execution Standard）](http://www.pentest-standard.org/index.php/Main%5FPage)は、同じ流れを7つのフェーズに細分化しています。攻撃前の脅威モデリング（Threat Modeling）と、侵入後の権限昇格・横展開（Post Exploitation）を独立したフェーズにしている点がNISTとの違いです。 | PTESのフェーズ | 内容 | NIST SP 800-115（筆者の対応付け） | | --------------------------- | ---------------- | ------------------------ | | Pre-engagement Interactions | 範囲・目標・許可の合意 | Planning | | Intelligence Gathering | 公開情報・スキャンによる情報収集 | Discovery | | Threat Modeling | 狙われる資産と攻撃者像の整理 | Discovery | | Vulnerability Analysis | 悪用できる脆弱性の特定 | Discovery | | Exploitation | 脆弱性を突いた侵入 | Attack | | Post Exploitation | 権限昇格・横展開・データ到達 | Attack | | Reporting | 経路・影響・対策の報告 | Reporting | 発注時に見積書の工程がこのどれに当たるかを照らすと、「情報収集だけで終わるプラン」か「Post Exploitationまで含むプラン」かを見分けられます。脅威モデリングの進め方は[脅威モデリングとは？STRIDEでの脅威抽出手順とツール選定を実装目線で解説](/tech/details/16226/)、Exploitationで使われる攻撃コードの仕組みは[exploitとは？脆弱性を悪用する攻撃コードの仕組み・種類・防御を実装者向けに解説](/tech/details/15280/)で扱っています。 ## ペネトレーションテストのツール（工程別） | ツール | 主に使う工程 | 用途 | 2026年10月時点の版 | | -------------------- | -------- | --------------- | ---------------- | | Nmap | 発見 | ポート・サービス・OSの特定 | 7.991（2026年8月6日） | | Burp Suite | 脆弱性分析・攻撃 | Web通信の傍受と改ざん | 2026.9系 | | Metasploit Framework | 攻撃・権限昇格 | 既知脆弱性の悪用モジュール実行 | 6.5系（6.5.7） | | Kali Linux | 全工程 | 上記を同梱した検証用OS | 2026.2 | 版は[Nmapの変更履歴](https://nmap.org/changelog.html)、[Burp Suiteのリリース一覧](https://portswigger.net/burp/releases)、[Kali Linuxのリリース一覧](https://www.kali.org/releases/)で確認しました。発見段階の典型的な操作は、Nmapでの開いているポートと稼働サービスの特定です。Nmapプロジェクトは練習用ホスト [scanme.nmap.org](http://scanme.nmap.org/) を用意し、「このマシンをNmapや他のポートスキャナーでスキャンしてよい」と許可を明示しています（1日数回までが目安）。許可のないホストへ同じコマンドを打たないでください。 ``` # 上位100ポートを対象に、稼働サービスと版を特定する nmap -sV --top-ports 100 scanme.nmap.org # 結果をXMLで保存し、報告書の証跡にする nmap -sV --top-ports 100 -oX scanme.xml scanme.nmap.org ``` ツールを揃えた検証環境はKali Linuxが定番で、導入方法は[Kali Linuxとは？できること・インストール方法と危険性【2026.2対応】](/tech/details/9369/)にまとめています。LLMに工程の一部を任せるツールも登場しており、[PentestGPTとは？v1.0の構成・導入手順と同名別製品の見分け方](/tech/details/11015/)や、AWSのマネージド型である[AWS Security Agentの料金｜$50/task-hourの課金単位とペネトレーションテストの実行手順](/tech/details/10822/)がその例です。手を動かして学ぶなら、合法な演習環境を提供する[TryHackMeとは？AttackBoxとVPN接続・料金の実額を実装視点で解説](/tech/details/17587/)から始めるのが安全です。 ## 実施前に必要な許可（不正アクセス禁止法とクラウド規約） ### 不正アクセス禁止法で問われるのは「アクセス管理者」の承諾 [不正アクセス行為の禁止等に関する法律](https://laws.e-gov.go.jp/law/411AC0000000128)第2条4項は、他人のIDを入力したり、アクセス制御を回避する指令を入力したりして利用制限を外す行為を「不正アクセス行為」と定め、アクセス管理者がする場合と、アクセス管理者（ID入力型では利用権者も）の承諾を得てする場合を除外しています。違反すると第11条により3年以下の拘禁刑または100万円以下の罰金です（懲役が拘禁刑に変わった[刑法改正は2025年6月1日施行](https://www.moj.go.jp/kyousei1/kyousei05%5F00164.html)）。 ここで見落とされやすいのが、承諾すべき人が「発注者」ではなく「そのコンピューターの動作を管理する者」である点です。自社システムでも、レンタルサーバー、SaaS、共同利用システム、委託先が運用する環境に載っていれば、管理者は事業者側にいることがあります。発注者の社内稟議だけで進めず、対象ごとに管理者が誰かを特定し、その承諾を書面で取ってください。なお、負荷をかけて業務を止めた場合は、不正アクセス禁止法とは別に[刑法](https://laws.e-gov.go.jp/law/140AC0000000045)第234条の2（電子計算機損壊等業務妨害、5年以下の拘禁刑または100万円以下の罰金）が問題になり得るため、DoSや負荷試験はRoEで明示的に除外します。 ### 書面で合意する項目（RoE） 許可の範囲は、作業規則（RoE：Rules of Engagement）として書面にします。最低限、次の項目が空欄のまま着手しないことです。 ``` 対象 : 203.0.113.10 ／ app.example.com（これ以外は対象外） 期間・時間帯 : 2026-11-04 〜 2026-11-15、平日 10:00-18:00 到達目標 : 顧客DBのテーブル一覧の取得まで（データ本体は持ち出さない） 禁止行為 : DoS・負荷試験、本番データの改ざん・削除、対象外ホストへの横展開 SE攻撃 : 標的型メール訓練は実施しない 承諾者 : アクセス管理者（ホスティング事業者を含む）の署名 緊急連絡先 : 停止判断者の氏名と電話番号（24時間） 取得データ : 報告書提出後30日以内に消去し、消去証明を提出 ``` ### クラウド事業者ごとの事前申請と禁止行為 | 事業者 | 自社リソースの事前申請 | 主な禁止行為・条件 | | --------------- | ------------- | -------------------------------------------- | | AWS | 許可サービスなら不要 | C2・模擬フィッシング等は事前申請、DoS・フラッディング禁止 | | Microsoft Azure | 不要 | DoS、自分以外のデータへのアクセス、Microsoftサービスを使ったフィッシング禁止 | | Google Cloud | 不要（自プロジェクトのみ） | 他の利用者への影響禁止、AUP準拠 | [AWSのペネトレーションテスト方針](https://aws.amazon.com/security/penetration-testing/)は「Permitted Services」に挙げたサービスについて事前承認なしでのテストを認める一方、C2（Command and Control）を含むテストや隠密のレッドチーム演習、模擬フィッシング、マルウェアテスト、iPerfによる計測は「Simulated Events」フォームでの事前申請が必要です。また、DoS/DDoS、ポート・プロトコル・リクエストのフラッディング、Route 53のゾーンウォーキング、S3バケットやサブドメインの乗っ取りを禁止しています。[Azureの説明](https://learn.microsoft.com/en-us/azure/security/fundamentals/pen-testing)は事前承認不要としつつ、[Microsoft Cloudの統一ルール（Rules of Engagement）](https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement)への準拠を求めます。[Google Cloud](https://support.google.com/cloud/answer/6262505?hl=en)は自分のプロジェクトだけに影響するテストなら連絡不要とし、[利用規定（AUP）](https://cloud.google.com/terms/aup)で他の利用者のサービスを妨げる行為を禁じています。どの事業者でも、許されるのは「自分の契約するリソース」までで、クラウド基盤そのものは対象外です。 ## 実施が求められる場面と頻度（PCI DSS・金融庁） ### PCI DSS v4.0.1 要件11.4：12か月に1回以上と重要な変更後 カード会員データを扱う事業者が準拠するPCI DSSは、要件11.4.2（内部）と11.4.3（外部）で、ペネトレーションテストを少なくとも12か月に1回、かつ重要なインフラやアプリケーションの更新・変更の後に実施するよう求めています（[PCI SSCの自己問診票SAQ D（加盟店向け・v4.0版。v4.0.1で要件の追加・削除なし）](https://www.pcisecuritystandards.org/documents/PCI-DSS-v4-0-SAQ-D-Merchant.pdf)）。カード環境をネットワーク分離で範囲外にしている場合は、分離が効いているかのテストも12か月に1回以上（要件11.4.5）、サービスプロバイダーは6か月に1回以上（要件11.4.6、[サービスプロバイダー向けSAQ D](https://www.pcisecuritystandards.org/documents/PCI-DSS-v4-0-SAQ-D-Service-Provider.pdf)）が必要です。v4.0は2024年12月31日で廃止され、現在はv4.0.1が有効版です。 ### 金融庁が金融機関に促すTLPTの実施対象 金融庁は2024年10月に「金融分野におけるサイバーセキュリティに関するガイドライン」を策定し、前述の2025年6月のレポートで、TLPTは大手金融機関、金融市場インフラ、特定社会基盤事業者、地域社会・経済に重要な役割を果たす金融機関などで実施することが望ましいとしています。2024年度には地域金融機関を対象にしたTLPTの実証事業も行われました。 ## 自社で実施するか外部に委託するかの判断 自社のエンジニアだけで実施してよいのは、自社が管理者である検証環境と、自社契約のクラウドリソースに限るのが安全な線です。本番システムや委託先の管理する環境が含まれるなら、承諾の取り付け、障害時の停止判断、報告書の第三者性まで含めて外部の専門事業者に依頼します。事業者選びでは、IPAの適合サービスリストでペネトレーションテスト欄に星印が付いているかが、審査登録機関の審査で経産省基準への適合が認められ、登録されている目安になります。 逆に、ペネトレーションテストを選ぶべきでない場面もあります。脆弱性診断を一度も受けていない、パッチ適用の運用が回っていない、あるいはシステムがまだ開発途中で仕様が固まっていない段階では、侵入の実証より先に網羅的な診断やDASTで既知の弱点を減らす方が費用対効果は高くなります（[DASTとは？SASTとの違い・ZAPでのCI/CD組み込みと導入判断を実装視点で解説](/tech/details/15882/)）。診断から侵入テストまでを段階的に組みたい場合は、弊社の[脆弱性診断・セキュリティ診断の支援](/service/system/vulnerability/)でも範囲設計から相談を受けています。 ## よくある質問 ### 侵入テストとペネトレーションテストは同じものですか？ 同じものです。経済産業省の情報セキュリティサービス基準も「ペネトレーションテスト（侵入試験）」と併記しており、ペンテストも略称です。 ### ペネトレーションテストのフレームワークには何がありますか？ 工程の標準としてはNIST SP 800-115（4段階）とPTES（7フェーズ）が代表的です。Webアプリケーションの検査項目は[OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/)を参照するのが一般的です。 ### ペネトレーションテストの費用はどれくらいですか？ 対象範囲・日数・手法で決まるため、多くの事業者が個別見積もりです。費用が動く要因と相場の読み方は[ペネトレーションテストと脆弱性診断の違い｜目的・費用・使い分けを発注前に整理](/column/details/13440/)で解説しています。 ### ペネトレーションテストは自社だけで実施できますか？ 自社が管理者である環境なら可能です。ただし本番環境や他社が管理するサーバーを含む場合は、アクセス管理者の書面承諾と停止体制が必要で、外部委託の方が確実です。 ### AWS上のシステムをテストするときは申請が必要ですか？ AWSが許可サービスとして挙げるサービス上の自社リソースなら事前承認は不要です。C2を含むテスト、隠密のレッドチーム演習、模擬フィッシング、マルウェアテストはSimulated Eventsフォームでの事前申請が必要で、DoSやフラッディングは禁止されています。 ## 関連記事 - [ペネトレーションテストと脆弱性診断の違い｜目的・費用・使い分けを発注前に整理](/column/details/13440/) - [脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](/column/details/13101/) - [Kali Linuxとは？できること・インストール方法と危険性【2026.2対応】](/tech/details/9369/) - [脆弱性対応の自動化｜ASM・BAS・ASVの使い分けと限界](/column/details/2372/) - [AIレッドチーミングとは？生成AIの脆弱性を洗い出す実施手順とツール選定【2026年時点】](/tech/details/16071/) --- 出典: [ペネトレーションテストとは？種類・手法・手順と実施前に必要な許可【2026年版】]()（株式会社一創）