AWS や Azure、Google Cloud といったクラウド上で自社のシステムを運用する企業にとって、攻撃者の視点で侵入可否を確かめるペネトレーションテストは有効な備えの一つです。一方でクラウドは自社だけの環境ではなく、クラウド事業者の基盤の上で動いています。
そのため「自社のシステムとはいえ、勝手にペネトレーションテストを実施してよいのか」「どこまでが自社でテストしてよい範囲なのか」という、オンプレミスにはなかった疑問が先に立ちます。
実際、クラウド事業者は事前申請の要否や禁止行為を定めており、これを把握しないままテストを進めると、規約違反やアカウント停止のリスクがあります。クラウドならではの検査対象（権限設定や公開ストレージなど）も、通常のネットワーク診断とは勘所が異なります。
本記事では、クラウドのペネトレーションテストを実施・依頼する前に押さえておきたい、AWS・Azure・Google Cloud のポリシー、脆弱性診断との違い、責任共有モデルとクラウド特有の検査対象、進め方と費用相場、依頼先の選び方までを整理します。自社で実施すべきか、どの診断サービスに依頼すべきかを判断するための材料としてご活用ください。
目次
一括ダウンロードする
AWS・Azure・Google Cloudのペネトレーションテストポリシー（事前申請・禁止行為）
クラウドのペネトレーションテストで最初に確認すべきは、利用しているクラウド事業者が定めるポリシーです。クラウドは事業者の基盤の上で動くため、何をしてよく、何が禁止され、事前申請が要るかは事業者ごとに決められています。ここでは主要3社の方針を整理します。
AWSのポリシー（事前承認不要の対象・禁止行為・シミュレートイベント申請）
AWS は、あらかじめ定めた「許可されたサービス」については、事前の承認なしにセキュリティ評価やペネトレーションテストを実施できるとしています。対象には Amazon EC2・RDS・CloudFront・API Gateway・AWS Lambda・Amazon ECS・AWS Fargate などの主要な計算・データベース・配信・コンテナ・サーバレス系サービスが含まれます。
一方で、AWS のインフラストラクチャや AWS サービス自体を対象とした評価は許可されていません。許可リストに載っていない自社利用サービスをテストしたい場合は、AWS サポートまたはアカウント担当者への連絡が必要です。
AWS のお客様は、[Permitted Services] (許可されたサービス) の下の次のセクションに記載されているサービスについて、事前の承認なしに AWS インフラストラクチャのセキュリティ評価またはペネトレーションテストを実行できます。（中略）Command and Control (C2) を含むすべてのセキュリティテストには、事前の承認が必要です。
出典：ペネトレーションテスト｜AWS クラウドセキュリティ（Amazon Web Services）
禁止される行為として、サービス拒否（DoS）・分散型サービス拒否（DDoS）やそのシミュレーション、各種フラッディング、Amazon S3 バケット乗っ取り、サブドメイン乗っ取り、Route 53 を経由した DNS 関連の攻撃などが挙げられています。ただし DoS・DDoS については、別途「DDoS シミュレーションテストポリシー」の対象として扱われます。
また、Red/Blue/Purple Team テストやシミュレートされたフィッシング・マルウェアテストなどの「シミュレートされたイベント」は、開始日の2週間前までに申請し審査を受ける必要があります。
Azure・Google Cloudのポリシー
Microsoft Azure も、2017年6月15日時点で Azure リソースに対するペネトレーションテストに事前承認を求めない方針に変わりました。ただし、公開されている契約規則（ROE：Rules of Engagement）に従うことが条件です。
アプリケーションの侵入テストは、アプリケーションをAzureで実行する上で重要な部分です。 これを行うためにMicrosoftの事前承認は必要ありませんが、公開されたルールに従う必要があります。
出典：侵入テスト｜Microsoft Learn（Azure セキュリティの基礎）
Azure で特徴的なのは DoS・DDoS の扱いです。Microsoft は「DDoS 攻撃は、あらゆる状況で厳しく禁止されています」と明記し、DDoS をテストしたい場合は、MazeBolt・Red Button・RedWolf といった承認済みの DDoS シミュレーションパートナーを利用するよう案内しています。
所有していないテナントやデータへのアクセス、自分のものではない資格情報の取得、過剰なトラフィックを生む自動テストなども禁止されています。診断ベンダーに委託する場合も、リソース所有者の書面による承認があれば、第三者（マネージドセキュリティサービス事業者やコンサルティング会社など）による実施が認められています。
Google Cloud は、AWS・Azure のような詳細な専用ポリシーページは設けておらず、公式の Cloud Security FAQ で「自分のプロジェクトを対象にペネトレーションテストを行う場合、Google への事前連絡は不要」との見解を示しています。
ただし、利用規約（Terms of Service）と利用規定（Acceptable Use Policy）に従い、テストが自分のプロジェクトだけに影響し、他の顧客に影響を及ぼさないようにすることが前提です。
If you plan to evaluate the security of your Cloud Platform infrastructure with penetration testing, you are not required to contact us. You will have to abide by the Cloud Platform Acceptable Use Policy and Terms of Service, and ensure that your tests only affect your projects (and not other customers’ applications).
出典：Cloud Security FAQ（Penetration testing）｜Google Cloud
Google Cloud には DoS 攻撃などを名指しで列挙した専用の禁止リストはなく、サービスへの不正アクセスや妨害を禁じる利用規定の一般条項が該当します。脆弱性を発見した場合は、脆弱性報奨金制度（Vulnerability Reward Program）への報告が案内されています。
3社の方針を横断で整理すると、以下のようになります。いずれも規約は更新されるため、実施前には必ず各社の最新の公式情報を確認してください。
| クラウド事業者 | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| 自プロジェクトの事前申請 | 許可されたサービスは不要（対象外サービスは要連絡） | 不要（契約規則ROE準拠が条件） | 不要（自プロジェクト内に限る） |
| DoS・DDoSの扱い | 原則禁止。DDoSシミュレーションは別ポリシーで申請 | 全状況で禁止。承認済みパートナー経由のみ | 利用規定の妨害禁止条項が該当 |
| 第三者への委託 | 契約した第三者による実施が可能 | リソース所有者の書面承認があれば可能 | 自プロジェクト内であれば可能 |
| 事前申請が必要な行為 | Red/Blue/Purple Teamや模擬フィッシング等のシミュレートイベント（2週間前申請） | 事前承認は不要だが公開ルール順守が必須 | 利用規約・利用規定の順守、他顧客に影響を与えないこと |
※各社公式ポリシーに基づく整理（2026年11月時点）。規約は変更される場合があるため、実施前に最新の公式情報を確認してください。
特に DoS・DDoS の扱いは3社で異なります。「クラウドなら事業者ごとに確認を」で済ませず、自社が使うクラウドのルールを個別に確認することが、トラブルを避ける第一歩です。
出典・参考資料（3件）
クラウドペネトレーションテストとは
ここからは、クラウドのペネトレーションテストが何を目的とした手法なのかを整理します。
ペネトレーションテストとは、攻撃者が実際に使う手口を想定し、システムへ侵入できるか、侵入後にどこまで到達できるかを検証する手法です。クラウドペネトレーションテストは、その対象を AWS・Azure・Google Cloud などのクラウド上で動くシステムに広げたものを指します。
重要なのは、単に脆弱性の有無を調べるのではなく、「攻撃者が設定した目標（たとえば特定のデータの窃取や管理者権限の奪取）に本当に到達できるか」という観点で検証する点です。
クラウド環境では、過剰な権限を持つIAMユーザーの悪用、公開設定のまま放置されたストレージ、インスタンスのメタデータ取得を足がかりにした権限昇格など、クラウド固有の経路をたどって侵入が試みられます。こうした経路を攻撃者の視点でたどり、実際にどこまで被害が及ぶかを明らかにするのがクラウドペネトレーションテストの役割です。
クラウドへの移行が進み、権限設定や公開範囲の誤りを起点とした情報漏えいが現実の脅威となる中で、設定の点検だけでは拾いきれない「実際に侵入されるか」を確かめる手段として、導入を検討する企業が増えています。本番システムの公開前や大きな構成変更の後、あるいは取引先からセキュリティ水準の説明を求められた場面などが、実施を検討するきっかけになります。
脆弱性診断・通常のペネトレーションテストとの違い
ここでは、混同されやすい「脆弱性診断」と「ペネトレーションテスト」、そしてクラウドならではの観点を整理します。発注時にどちらを選ぶべきか迷ったときの判断材料にしてください。
脆弱性診断は、システムに存在する弱点を網羅的に洗い出す「チェック」に近い手法です。既知の脆弱性や設定の不備を幅広く点検し、どこにリスクがあるかを一覧化します。一方のペネトレーションテストは、洗い出した弱点のうち実際に悪用できるものを使い、攻撃者として侵入できるかを確かめる「演習」に近い手法です。目的が「弱点の網羅」なのか「侵入可否と影響の実証」なのかが、両者の根本的な違いです。
クラウドペネトレーションテストは、このペネトレーションテストの考え方を、クラウド特有の構成（権限設計・ストレージの公開範囲・サーバレスなど）に適用したものと位置づけられます。3者の違いを整理すると以下のとおりです。
| 手法 | 脆弱性診断 | 通常のペネトレーションテスト | クラウドペネトレーションテスト |
|---|---|---|---|
| 主な目的 | 弱点を網羅的に洗い出す（チェック） | 攻撃者視点で侵入可否と影響を実証（演習） | クラウド構成を悪用した侵入可否を実証 |
| 進め方 | ツールと手動で既知の脆弱性・設定不備を点検 | 目標を設定し、攻撃シナリオで到達可否を検証 | 権限設定・公開ストレージ等クラウド固有の経路を検証（事業者ポリシー順守） |
| 費用の目安 | 数十万円〜200万円程度 | 200万円以上（範囲による） | 対象範囲・手動比率で変動 |
| 期間の目安 | 2〜4週間程度 | 数週間〜数か月 | 範囲により数週間〜 |
| 向いている場面 | 現状のリスクを一覧で把握したいとき | 実際に侵入されるか・被害範囲を確かめたいとき | クラウド上のシステムの実践的な防御力を確かめたいとき |
※一般的な手法の傾向を整理したものです。実際の診断範囲・手法は各サービスの内容をご確認ください。
まず弱点の全体像を把握したい段階なら脆弱性診断、そのうえで「実際に侵入されるのか」を確かめたい段階ならペネトレーションテストを選ぶ、という使い分けが基本です。段階的に両方を実施するケースもあります。
脆弱性診断とペネトレーションテストの違いだけをさらに詳しく確かめたい場合は、目的・費用・選び方の観点で両者を比較した記事も参考になります。
責任共有モデルとクラウド特有の検査対象・狙われやすい脆弱性
ここからは、クラウドで「どこまでが自社のテスト範囲か」を決める責任共有モデルと、クラウドで実際に狙われやすい弱点、検査対象、参照される基準を解説します。
責任共有モデル｜どこまでが自社のテスト範囲か
クラウドのセキュリティは、クラウド事業者と利用者が責任を分担する「責任共有モデル」で成り立っています。AWS はこれを「クラウドのセキュリティ（事業者の責任）」と「クラウドにおけるセキュリティ（利用者の責任）」として説明しています。
AWS には、AWS クラウドで提供されるすべてのサービスを実行するインフラストラクチャを保護する責任があります。（中略）お客様の責任は、選択した AWS クラウドのサービスに応じて異なります。
出典：責任共有モデル｜Amazon Web Services (AWS)
Microsoft もオンプレミスではスタック全体を自社が所有するのに対し、クラウドでは一部の責任が事業者へ移ると説明し、データとIDについてはどの提供形態でも利用者が責任を持つとしています。Google Cloud は責任共有モデルを説明したうえで、事業者が利用者と一体となって安全性を高める「shared fate（運命共有）」という独自の考え方を打ち出しています。
ペネトレーションテストで自社がテストできるのは、原則としてこの「利用者の責任範囲」です。たとえば仮想マシン（IaaS）ではゲストOSや権限設定まで利用者の責任ですが、事業者が管理する基盤そのものはテスト対象外です。どこまでが自社の範囲かは利用するサービスによって変わるため、事前の切り分けが欠かせません。
各社とも、この責任分担は契約や規約の最終確認を前提としたガバナンス上の整理である点に留意してください。
出典・参考資料（3件）
クラウドで狙われやすい脆弱性・設定不備
クラウドペネトレーションテストで重点的に確認されるのは、クラウド固有の設定に起因する弱点です。代表的なものとして、次のような点が挙げられます。
- IAM（権限管理）の過剰な権限: 必要以上の権限を持つユーザーやロールが、侵入後の権限昇格や横展開の足がかりになります
- 公開設定のストレージ: 誤って外部に公開されたオブジェクトストレージ（Amazon S3 など）からの情報漏えい
- インスタンスメタデータの悪用: サーバの脆弱性を足がかりにメタデータへアクセスし、一時的な認証情報を奪取する手口
- 緩いネットワーク設定: セキュリティグループやファイアウォールで通信元を広く許可しすぎている構成
- サーバレス・コンテナの設定ミス: 関数やコンテナの権限・環境変数の扱いに起因するリスク
これらは単体では小さな設定ミスに見えても、組み合わされることで侵入経路になります。攻撃者視点で経路全体をたどるペネトレーションテストは、こうした連鎖的なリスクを可視化するのに適しています。
こうした設定不備そのものを継続的に洗い出す手段としては、侵入可否を試すペネトレーションテストとは別に、クラウドの脆弱性診断や設定診断（CSPM）という選択肢もあります。対象範囲や費用の違いは次の記事で整理しています。
主な検査対象領域
先に挙げた弱点を、診断では次の領域に分けて体系的に確認します。個々の設定ミスを単体で見るのではなく、領域ごとに漏れなくカバーする観点です。検査サービスによって範囲は異なりますが、見積りや範囲確定の際の目安になります。
- 認証・認可（IAM の権限設計、多要素認証の有無）
- ネットワーク構成（セキュリティグループ、公開範囲、通信経路）
- データストレージ（オブジェクトストレージ・データベースの公開範囲や暗号化）
- サーバレス・コンテナ環境（関数やコンテナの権限・設定）
- クラウドサービス間の連携（サービス連携時の権限の受け渡し）
- 監査・ログ（攻撃を検知・追跡できるログ設計になっているか）
準拠すべきガイドライン・基準
クラウドのセキュリティ評価では、国際的に参照されるいくつかの枠組みが、検査の観点や設定基準のよりどころになります。依頼先を選ぶ際、これらへの対応をうたっているかも一つの目安になります。
- OWASP Cloud-Native Application Security Top 10: クラウドネイティブ環境で起こりやすいリスクを10分類で整理した枠組み（設定ミス・権限・CI/CD・ログ不足など）。確立した業界標準というより、クラウドネイティブ領域の代表的なリスク整理として参照されます
- CIS Benchmarks: 各種製品・クラウドの設定を安全に固めるための推奨設定集。AWS・Azure・Google Cloud それぞれに Foundations Benchmark があります
- MITRE ATT&CK for Cloud: 攻撃者の戦術・手法を体系化したナレッジベース。クラウド（IaaS・SaaS など）を対象にしたマトリックスがあり、攻撃シナリオの設計に使われます
- CSA Cloud Controls Matrix（CCM）: クラウド向けの管理策フレームワークで、17ドメイン・197の管理目標で構成され、どのアクターがどの統制を担うかの指針を示します
出典・参考資料（4件）
クラウドペネトレーションテストの進め方と報告書・納品物
ここでは、実際にクラウドペネトレーションテストを進める流れと、成果物として受け取る報告書のイメージを解説します。
実施の流れ（フェーズ）
一般的なクラウドペネトレーションテストは、おおむね次の流れで進みます。まず対象範囲と目標（ゴール）を決める計画段階があり、ここでクラウド事業者のポリシー確認や、必要な場合の事前申請も行います。次に対象環境の情報収集を行い、権限設定や公開範囲などの弱点を洗い出します。続いて、見つかった弱点を悪用して実際に侵入を試み、設定した目標へ到達できるかを検証します。
最後に、検出した問題と再現手順、リスク評価、改善策をまとめて報告します。
クラウド経由の内部侵入シナリオ例
クラウドペネトレーションテストでは、具体的な攻撃シナリオを設定して検証します。たとえば、公開されているWebアプリケーションやAPIの脆弱性を入口に侵入し、サーバのインスタンスメタデータから一時的な認証情報を取得する、といった入口の確認から始めます。
そこから、過剰な権限を持つロールを悪用して他のリソースへ横展開し、最終的に機密データの格納先まで到達できるか、という一連の経路を確かめます。
こうしたシナリオは、攻撃者の戦術を体系化した MITRE ATT&CK などを参照して組み立てられます。
報告書に含まれる内容・報告会
報告書には一般に、検出した脆弱性の一覧、侵入の再現手順、リスクの深刻度評価、具体的な改善提案が含まれます。経営層向けに全体像を要約した総括（エグゼクティブサマリー）を備える場合も多く、現場の改修と社内説明の両方に使えます。
多くのサービスでは報告書の納品に加えて、結果を説明し質疑に応じる報告会も用意されています。報告書の粒度や報告会の有無は依頼先によって差があるため、見積り時に確認しておくとよいでしょう。
クラウドペネトレーションテストの費用相場・期間の目安
ここでは、予算化や社内の上申に役立つよう、費用相場と期間の目安を整理します。金額は対象範囲やシナリオの数によって変わるため、幅のある目安として捉えてください。
一般的な傾向として、弱点を洗い出す脆弱性診断は数十万円〜200万円程度、2〜4週間ほどが一つの目安とされます。これに対し、攻撃者視点で侵入可否を検証するペネトレーションテストは、範囲やシナリオの複雑さに応じて200万円以上、期間も数週間〜数か月に及ぶことがあります。
実際、専門ベンダーの公式情報では、情報システムを対象とするペネトレーションテストを700万〜1,000万円程度（税抜、標準シナリオ）や800万円〜（税別）とするものもあります。これらは受託型の専門ベンダーが示す値で、後述の各サービスの出典で確認できます。
同じ「ペネトレーションテスト」でも金額に大きな幅があるのは、対象範囲の広さ、手動診断の比率、攻防演習（TLPT）まで行うかといった内容の違いによるものです。クラウド環境単体に絞った診断であれば、範囲次第でこれより抑えられる場合もあります。
費用は「対象とするクラウドアカウントや範囲の広さ」「設定するシナリオの数」「ツール中心か手動中心か」で決まります。自動スキャン主体のツール型であれば月額数万円台から始められるものもあり、まずは設定不備の点検から着手し、重要なシステムに絞って手動のペネトレーションテストを行う、という段階的な進め方も現実的です。
ここで注意したいのは、ツール型の「月額数万円台」と、受託型ペネトレーションテストの「1回あたり数百万円〜」は料金の性質が異なる点です。前者は継続的にスキャンを回すサブスクリプション、後者は対象を決めて専門家が手作業で侵入を試す単発のプロジェクトです。性質が異なるため、金額の大小だけで比較せず、目的に応じて使い分ける費用と捉えてください。
中堅・中小企業であれば、いきなり数百万円規模の受託型に進むのではなく、まずツール型で設定不備を点検し、対象を絞って手動診断を加える進め方が、予算と効果のバランスを取りやすい選択肢です。正確な金額は、範囲を決めたうえで複数社から見積りを取って比較することをおすすめします。
ペネトレーションテストの費用を対象別・規模別にもう少し具体的に把握したい、見積りの取り方まで知りたいという場合は、費用相場をまとめた次の記事が判断材料になります。
クラウドペネトレーションテストの依頼先の選び方
ここからは、自社に合う依頼先を選ぶための観点を整理します。価格だけでなく、診断の質や自社環境との相性を見極めることが、投資に見合う結果を得る鍵になります。
依頼先を見極める主な観点
依頼先を比較する際は、次の観点を確認すると判断しやすくなります。
- クラウドへの専門性: 自社が使うクラウド（AWS・Azure・Google Cloud）の診断実績があるか。クラウド固有の経路に精通していないと、設定不備の表面的な指摘にとどまりやすくなります
- 準拠する基準: OWASP や CIS Benchmarks、MITRE ATT&CK など、どの枠組みに沿って検査するかが明示されているか
- 情報セキュリティサービス基準への適合: 経済産業省の情報セキュリティサービス基準に適合しているかは、診断品質の一つの目安になります
- 報告書の質と報告会: 再現手順や改善提案まで具体的に示されるか、結果を説明する報告会があるか
- 手動診断の比率: ツールによる自動スキャンだけでなく、専門家の手動検証がどこまで含まれるか。巧妙な経路は手動でないと見つけにくい場合があります
自動スキャン中心のツール型は、継続的に設定不備を点検し、コストを抑えて広く確認したい場合に向きます。一方、重要システムの実践的な侵入可否を確かめたい場合は、手動診断を主体とする専門ベンダーが適しています。目的に応じて使い分けるか、組み合わせるとよいでしょう。
クラウドソーシング型という選択肢
依頼先の形態として、特定のベンダーに委託する方式のほかに、認定された多数のホワイトハッカーがプラットフォームを通じて診断に参加する「クラウドソーシング型（クラウドソースペネトレーションテスト）」もあります。多様な視点で検証できる点が特徴で、国内でもこうしたプラットフォームを活用したサービスが提供されています。継続的に幅広く検証したい場合の選択肢として検討できます。
AI活用など最新動向と内製の可否
近年は、AIエージェントにペネトレーションテストの一部を担わせる取り組みも登場しています。AIが攻撃シナリオの探索や検証を支援することで、効率化が期待される一方、クラウド事業者のポリシー順守や、診断中の情報が外部へ流出しないための通信制御など、実運用には固有の課題もあります。国内でも、AIを用いたペネトレーションテストツールをクラウドへ適用する技術検証が事業者から公開されています。
この効率化の一方で、AIによる診断では結果の精度をどう担保するかも実運用上の論点になります。この点について、AI解析と専門家確認を組み合わせた診断を手がける企業は、次のように説明しています。
精度については、ハルシネーションが心配だというお声もいただきますが、ハルシネーションを完全に防ぐとAIの強みが損なわれてしまいますので、そこは防ぎきることはしていません。その代わり、ハルシネーションが起きた可能性がある箇所については明確に示すようにしていて、最終的に人の目で見て正しいかどうかを承認するフローを取っています。
AIを活用した侵入テストが今後どこへ向かうのかについては、提供企業から次のような見通しも示されています。
AIコーディングが当たり前になるほど、「AIが書いたコードも含めて、日常的に検証できる仕組み」が重要になります。その文脈で、AIエージェントがハッカーをエミュレーションして侵入テストを行い、ログや証跡を残す“AIペンテスト”の方向性も出てきています。これが進むと、コストや時間の都合で「リリース前に1回」が限界だった侵入テストを、ビルドパイプラインに組み込み、毎日回す世界が見えてきます。
内製については、設定不備を点検するツール（CSPM など）であれば自社で継続的に回すことも可能です。ただし、攻撃者視点で侵入可否を検証するペネトレーションテストは、専門的な知見と事業者ポリシーの正確な理解が求められるため、重要なシステムでは外部の専門家に委託するのが一般的です。
ツールによる日常的な点検と、専門家による定期的なペネトレーションテストを組み合わせる形が、多くの企業にとって無理のない進め方になります。
一括ダウンロードする
クラウドのセキュリティ対策に役立つ診断サービス
ここでは、クラウドの設定点検やペネトレーションテストに対応する診断サービスを紹介します。自社で設定を継続的に点検したい場合に向くツール型と、専門家による手動診断を依頼できる受託型があり、目的に応じて選べます。
クラウド対応に絞らず、脆弱性診断サービス全体を診断方法・費用相場・選び方の観点で広く見比べたい方は、カテゴリの比較記事もご覧ください。
各サービスの対応範囲や料金を比較すると、以下のとおりです。
| サービス名 | Aikido Security | CoWorker 脆弱性診断サービス | GMOサイバーセキュリティ byイエラエ | NRIセキュア セキュリティ診断 | ラック 脆弱性診断・セキュリティ診断 |
|---|---|---|---|---|---|
| 診断方式 | ツール型（自動スキャン） | AI自動解析＋専門家確認 | 手動主体＋ツール型ASM | 手動主体（ツール併用） | 手動主体（ツール併用） |
| クラウド設定診断（CSPM） | ● | ×対象はWeb・API・ソースコード | ● | ● | ● |
| ペネトレーションテスト | △製品ラインに搭載、日本窓口の範囲は要確認 | ● | ● | ● | ● |
| 料金の目安 | 月額5万円台〜 （参考・年間契約） | 公式では通常50万円〜 （診断範囲に応じたプラン） | 手動診断は個別見積 ネットde診断ASM 月額4万円〜 | ペネトレーションテスト 800万円〜（税別） | ペネトレーションテスト 700万〜1,000万円（税抜） |
| 詳細情報 | 公式資料を見る | 公式資料を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る |
Aikido Security（株式会社AndGo）
Aikido Security は、ソースコード・依存ライブラリ・クラウド設定・コンテナ・稼働中のWebアプリケーションを1つの管理画面で検査できるSaaSです。日本では株式会社AndGoが販売窓口となり提供しています。人が診断して報告書を納品する受託型ではなく、自動スキャンを継続的に利用する形態で、クラウドの設定点検を自社で回したい企業に向いています。
クラウド設定管理（CSPM）は AWS・Azure・Google Cloud などに対応し、外部から侵入されうる設定の不備を検知します。あわせてソースコード診断（SAST・SCA）や稼働中アプリの動的診断（DAST）にも対応し、検出したアラートを自動で整理して対応すべきものを絞り込めるため、運用負荷を抑えやすい点が特徴です。
ISO 27001・SOC 2 の認証取得・維持に向けた監査用レポートの出力にも対応しています。ただし、AIを活用したペネトレーションテストは開発元のグローバルな製品ラインに含まれますが、日本窓口での提供範囲は問い合わせでの確認が必要です。
料金は、日本窓口のAndGoによると参考価格で月額5万円台から（年間契約・利用者10人までの場合）とされ、最新の料金は問い合わせでの確認が案内されています。
CoWorker 脆弱性診断サービス（CoWorker株式会社）
自社開発のAI「Red Agent」による自動解析と、社内のセキュリティ専門家による最終確認を組み合わせた脆弱性診断サービスです。公式のメニューは、ソースコードをAIが解析する「ソースコードAI診断」、稼働中のWebアプリ・APIを対象とする「動的脆弱性診断」、そして各診断の結果をもとに実際の攻撃を想定して検証する「実践攻撃シミュレーション診断（ペネトレーションテスト）」の3つで構成されます。
AIによる自動解析で診断の時間を抑えつつ、専門家が仕上げに確認する流れのため、スピードと精度の両立を図りやすいのが特徴です。ソースコードAI診断は本番環境に影響を与えずに実施できる点も示されています。
料金は、公式サイトでは通常50万円からと案内されています。ソースコードのAI診断のみのプランから、Webアプリ・APIの動的診断まで含むプランまで、診断範囲に応じた構成が用意されており、正式な金額は見積りでの確認が確実です。
出典・参考資料（1件）
GMOサイバーセキュリティ byイエラエ（GMOサイバーセキュリティ byイエラエ株式会社）
国内のホワイトハッカーを多数擁するサイバーセキュリティの専門企業で、専門家による手動主体の脆弱性診断・ペネトレーションテストを中核に据えています。診断メニューにはクラウド診断（AWS・Azure・Google Cloud 等）が含まれ、Webアプリケーションやネットワーク、ブロックチェーンなど幅広い対象をカバーします。
ペネトレーションテストでは、攻撃シナリオを設定してその実現性を確かめる方式を採り、ASVS や OWASP Top 10 などの国際基準への対応をうたっています。AIアプリケーションやAIエージェントを対象とした診断メニューも用意されており、新しい技術領域にも対応を広げています。手動診断の比率を重視する体制のため、ツールでは見つけにくい巧妙な経路の検証を求める場合に適しています。
料金は対象や範囲に応じた個別見積りです。
NRIセキュア セキュリティ診断（ＮＲＩセキュアテクノロジーズ株式会社）
野村総合研究所グループのセキュリティ専業会社が提供する、専門家による手動主体の診断・ペネトレーションテストです。Webアプリケーション診断やプラットフォーム診断に加え、クラウド設定を評価する「クラウド設定評価サービス（CSPM）」、攻撃者視点のペネトレーションテスト、レッドチームオペレーションまで、幅広い診断メニューを備えています。
診断は、専門トレーニング修了者や国際資格の保有者による手作業を主体とし、ツールは補助的に用いる方式です。金融機関や大手企業での診断実績を公式に挙げており、高い水準の診断を求める企業に向きます。料金はメニューにより個別見積りで、ペネトレーションテストサービスは公式に800万円から（税別）と示されています。
出典・参考資料（1件）
ラック 脆弱性診断・セキュリティ診断サービス（株式会社ラック）
1995年から診断サービスを提供してきた株式会社ラックのセキュリティ診断です。弱点を網羅的に洗い出す脆弱性診断と、攻撃者視点で侵入後の影響範囲まで確かめるペネトレーションテストを区別して提供し、クラウド・SaaS の設定診断から情報システムペネトレーションテスト、脅威ベースのペネトレーションテスト（TLPT）まで幅広く対応します。
セキュリティ監視センター「JSOC」やインシデント対応を行うサイバー救急センターを自社で持ち、診断・監視・緊急対応を同じベンダーで組み合わせられる点が強みです。情報システムペネトレーションテストは、標準的なマルウェア感染シナリオで700万〜1,000万円程度（税抜）が公式に示されており、範囲やシナリオに応じて変動します。
Web診断は短期・小規模向けの簡易プランから、対象や深さに応じた選択肢が用意されています。
出典・参考資料（1件）
まとめ
クラウドのペネトレーションテストは、通常のペネトレーションテストや脆弱性診断とは異なり、クラウド事業者のポリシーと責任共有モデルを踏まえて進める必要があります。AWS・Azure・Google Cloud はいずれも自プロジェクトのテストに事前承認を求めない方向ですが、DoS・DDoS の扱いや禁止行為は事業者ごとに異なるため、実施前の確認が欠かせません。
自社の設定を継続的に点検したいならツール型、重要システムの実践的な侵入可否を確かめたいなら手動主体の受託型、という使い分けが基本です。まずは対象範囲を決め、クラウドへの専門性・準拠基準・報告書の質を軸に複数のサービスを比較することから始めてください。各サービスの資料を取り寄せて、費用や対応範囲を具体的に見比べるのが近道です。
一括ダウンロードする
クラウドペネトレーションテストに関するよくある質問（FAQ）
Q. クラウドペネトレーションテストとは何ですか？
A. クラウドペネトレーションテストとは、攻撃者が実際に使う手口を想定し、AWS・Azure・Google Cloud などのクラウド上で動くシステムに侵入できるか、侵入後にどこまで到達できるかを検証する手法です。
単に脆弱性の有無を調べるのではなく、IAM の過剰な権限や公開設定のストレージといったクラウド固有の経路をたどり、攻撃者が設定した目標（データの窃取や管理者権限の奪取など）に本当に到達できるかを確かめる点に特徴があります。
Q. クラウドペネトレーションテストにクラウド事業者の事前申請は必要ですか？
A. クラウドペネトレーションテストの事前申請の要否は、利用するクラウド事業者によって異なり、AWS・Azure・Google Cloud はいずれも自社プロジェクトを対象としたテストに原則として事前承認を求めていません。
ただし条件があり、AWS は「許可されたサービス」以外や、Red/Blue/Purple Team・模擬フィッシングなどの「シミュレートされたイベント」は開始2週間前までの申請が必要です。Azure は事前承認は不要でも公開された契約規則（ROE）の順守が条件で、Google Cloud は利用規約・利用規定に従い自社プロジェクト内に影響をとどめることが前提です。
規約は更新されるため、実施前に必ず各社の最新の公式情報を確認してください。
Q. クラウドペネトレーションテストでDoS・DDoSのテストはできますか？
A. DoS・DDoS のテストができるかは、クラウド事業者ごとに扱いが大きく異なり、通常のペネトレーションテストの範囲とは別枠で扱われます。AWS は原則禁止としたうえで、DDoS のシミュレーションは別途「DDoS シミュレーションテストポリシー」の対象として申請が必要です。
Azure は DDoS 攻撃をあらゆる状況で厳しく禁止し、承認済みの DDoS シミュレーションパートナー経由でのみ実施できます。Google Cloud は専用の禁止リストこそないものの、サービスへの妨害を禁じる利用規定の一般条項が該当します。実施を検討する場合は、自社が使うクラウドのルールを個別に確認してください。
Q. クラウドペネトレーションテストは脆弱性診断で代替できますか？
A. クラウドペネトレーションテストは脆弱性診断では完全には代替できず、両者は目的が異なるため使い分けるのが基本です。脆弱性診断は既知の弱点や設定不備を網羅的に洗い出す「チェック」に近い手法で、現状のリスクを一覧で把握したいときに向きます。これに対しペネトレーションテストは、洗い出した弱点のうち実際に悪用できるものを使って侵入可否と被害範囲を確かめる「演習」に近い手法です。
まず弱点の全体像を把握したい段階なら脆弱性診断、そのうえで「実際に侵入されるのか」を確かめたい段階ならペネトレーションテスト、と段階的に両方を実施するケースもあります。
Q. クラウドペネトレーションテストは自社で内製できますか？
A. 設定不備を点検するツール（CSPM など）であれば自社で継続的に内製できますが、攻撃者視点で侵入可否を検証するペネトレーションテストは外部の専門家に委託するのが一般的です。ペネトレーションテストは専門的な知見と事業者ポリシーの正確な理解が求められるため、重要なシステムでは委託が無難です。
ツールによる日常的な点検と、専門家による定期的なペネトレーションテストを組み合わせるのが、現実的な落としどころといえます。
Q. クラウドペネトレーションテストの費用相場はどのくらいですか？
A. クラウドペネトレーションテストの費用は対象範囲やシナリオの複雑さによって変わり、攻撃者視点で侵入可否を検証するペネトレーションテストは200万円以上、専門ベンダーの公式情報では700万〜1,000万円程度（税抜）や800万円〜（税別）とするものもあります。弱点を洗い出す脆弱性診断は数十万円〜200万円程度、期間は2〜4週間ほどが一つの目安です。
一方、自動スキャン主体のツール型であれば月額数万円台から始められるものもあり、まずは設定不備の点検から着手して重要なシステムに絞って手動のペネトレーションテストを行う段階的な進め方も現実的です。正確な金額は、範囲を決めたうえで複数社から見積りを取って比較することをおすすめします。
Q. クラウドペネトレーションテストはAWS・Azure・Google Cloudのどれでも実施できますか？
A. クラウドペネトレーションテストは、AWS・Azure・Google Cloud のいずれでも実施できます。本記事で紹介した診断サービスの多くも主要3クラウドに対応しています。
ただし、事前申請や禁止行為のルール、責任共有モデルで定まる利用者のテスト範囲は事業者ごとに異なります。自社が使うクラウドの診断実績がある依頼先を選ぶと、クラウド固有の経路まで踏み込んだ検証を受けやすくなります。
脆弱性・セキュリティ診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、クラウド診断・ペネトレーションテストに対応する脆弱性・セキュリティ診断サービスの最新資料を無料で一括請求できます。対応範囲・料金・報告書の内容などを、比較に必要な情報としてまとめて把握できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
