AWSペネトレーションテストとは、クラウドサービスのAWS（Amazon Web Services）上で動くシステムに攻撃者と同じ手口で侵入を試み、悪用できる弱点が実在するかを確かめるセキュリティ検証を指します。AWSのようなクラウドは、サービスを柔軟に組み合わせられる反面、権限や公開範囲の設定一つで侵入の糸口が生まれやすく、自社で機器を管理していた従来の環境とは違う注意が必要です。この記事では、AWSペネトレーションテストの定義やAWS特有の侵入経路の例をもとに、確認しておくべきルールやテストを委託する診断会社を見極める視点までを解説します。
AWSペネトレーションテストが対象にするのは、AWS上で動くWebアプリやAPI（システム同士をつなぐ接点）、ネットワーク、権限を管理するIAMなどのクラウド構成です。土台にあるペネトレーションテスト（侵入テスト）とは、実在の攻撃手法を再現して弱点を悪用できるか試し、被害がどこまで及ぶかを見極める手法を指します。弱点を見つけて終わりにせず、それが攻撃の起点として本当に成立するのかまで踏み込むところに、この検証の核があります。
たとえば、ファイルを保管するS3というサービス（※）で、保存場所（バケット）が誰でも閲覧できる公開設定になっていると、診断ツールは「公開されている」と検出します。
なお、現在のS3では、新規バケットに対して「パブリックアクセスのブロック」がデフォルトで有効です。こうした全公開状態は、初期設定を意図的に、あるいは誤って上書きした結果として生じるケースが大半です。
これに対してペネトレーションテストでは、その公開バケットから機密データを実際に読み出せるか、さらにそこを足がかりに別のリソースへ手が届くかまでを試します。検出にとどまらず悪用の実証まで行うところが、両者を分ける境目になります。以下では、脆弱性診断との具体的な違いと、自社に向くのはどちらかという判断の軸を順に見ていきます。
両者は目的も手法も成果物も異なります。AWS環境に当てはめて並べると、次のとおりです。
| 観点 | 脆弱性診断 | AWSペネトレーションテスト |
|---|---|---|
| 目的 | 既知の弱点を広く洗い出す | 侵入や悪用が実際に可能かを確かめる |
| 主な手法 | ツール中心で一部手動 | 手動中心で攻撃シナリオに沿って実施 |
| AWSでの着眼点 | 公開資産や構成の網羅的なチェック | 権限昇格や横展開、設定悪用の連鎖まで |
| 典型的な検出例 | IAMに過剰権限が付いている、ポートが開いている | 過剰権限のロールを奪って別リソースまで横展開できた |
| 成果物 | 弱点の一覧と基本的な改善案 | 攻撃経路と影響範囲、優先度付きの改善案 |
| 実施頻度・タイミング | 定期的・継続的に実施しやすい | リリースや構成変更の節目など、要所で実施することが多い |
診断は「どこに穴がありそうか」を網羅的に押さえる検査、ペネトレーションテストは「その穴から実際に入れるか」を追う検証だと考えると区別しやすくなります。
どちらが自社に向くかは、目的と段階で考え、整理するのがポイントです。自社のAWS環境にどのような弱点が潜んでいるかを、まず幅広く把握したい段階では、網羅性と実施のしやすさに優れた脆弱性診断が向いています。
一方、洗い出した弱点が本当に悪用され得るのか、悪用された場合にどこまで被害が広がるのかを見極めたい段階では、ペネトレーションテストが適しています。
脆弱性診断とペネトレーションテストとの違い、そもそもペネトレーションテストとはどういうものかについては以下の記事で詳しく解説していますので、参考にしてください。
まず全体のリスクを把握したい段階なら、脆弱性診断からの着手が現実的です。広くツールで網をかけ、優先して直すべき箇所のあたりをつける用途に向きます。
IAMの権限設計が複雑になってきた、S3やデータベースの公開範囲に不安がある、クラウド移行後の設定妥当性を実戦的に確かめたい。こうした状況ではペネトレーションテストが効きます。取引先や監査から実践的な検証を求められたケースも同様です。両者は排他ではなく、診断で広く把握したうえでテストを行い深掘りするという順序が、費用対効果の面でも理にかなっています。
※参考：Amazon Web Services│クラウドオブジェクトストレージ
AWS環境で被害につながる弱点の多くは、ソフトウェアのバグよりも設定や権限の不備から生まれます。その背景を解く鍵が、責任共有モデルという考え方です。AWSと利用者の責任がどこで分かれるのか、そしてその境界からどんな設定不備が生まれやすいのかを、順を追って解説していきます。
責任共有モデルとは、クラウドのセキュリティ責任をAWSと利用者で分担する考え方のことです。物理的なインフラやハードウェア、基盤となるソフトウェアの保護はAWSが担います。一方、OSやアプリケーションの管理、ネットワークやアクセス権限の設定、データの保護は利用者の責任です（※）。
ただし、境界は利用するサービスの種類によって変動します。Amazon EC2のようなIaaSでは、ゲストOSの更新やパッチ、アプリケーションの管理まで利用者が担います。一方、S3のように抽象化されたサービスでは、OSやプラットフォームの運用はAWS側が受け持ち、利用者の責任はデータの管理（暗号化を含む）やIAMによる権限設定が役割です。いずれの場合も、権限と公開範囲の設定が利用者の責任として残る点は共通しています。
この線引きが示すのは、攻撃者が狙う余地が主に利用者側の設定に生まれるという事実です。AWSの基盤そのものが堅牢に守られていても、利用者が公開範囲や権限を誤れば、そこが侵入口に変わります。AWSのペネトレーションテストが利用者側の設定と権限を重点的に確かめるのも、この構造ゆえです。
AWSで被害につながる弱点は、ソフトウェアの欠陥よりも「権限を渡しすぎる」「公開範囲を絞りきれない」という運用の判断ミスから生まれやすいところに特徴があります。たとえばIAMで必要以上の権限を残せば、侵入されたあとの被害がそのまま広がります。S3で公開設定を一段緩めれば、本来は社内限定の情報が外から読める状態になります。
やっかいなのは、AWSではIAMや各サービスの設定が密に連動する点です。オンプレミスなら一つのファイアウォール設定ミスで止まる話が、AWSでは権限とネットワークと公開範囲がつながり、一つの不備が次の不備を呼び込みます。だからこそ、個別の弱点を点で見るのではなく、設定どうしのつながりまで踏み込んで確かめる必要が出てきます。どのサービスで何を見るかは、のちほど対象ごとに掘り下げます。
※参考：Amazon Web Services│「責任共有モデル」. AWS クラウドセキュリティ
設定不備がなぜ危ないのかは、実際の侵入経路をたどると見えてきます。AWS環境では、一見すると小さな弱点が次の弱点を呼び込み、被害が連鎖して広がります。ここからは、公開Webの弱点を起点にIAMの認証情報が奪われる流れと、単発では軽い弱点が連鎖して重大化する仕組みを、具体的にお伝えしていきます。
起点になるのは、SSRFという脆弱性です。SSRF（サーバーサイドリクエストフォージェリ）とは、攻撃者がWebアプリを踏み台にして、本来は外部から到達できない内部リソースへリクエストを送らせる弱点を指します。
AWSでこのSSRFが危険になるのは、仮想サーバーのEC2（※1）にIMDSという仕組みがあるためです。IMDS（インスタンスメタデータサービス）は、「169.254.169.254」という特別なアドレスで提供され、EC2に割り当てられたIAMの一時的な認証情報を返します。SSRFを悪用してこのアドレスへアクセスさせると、攻撃者はその認証情報を盗み出せてしまいます。なお、合言葉となるトークンを必須とするIMDSv2へ切り替えると、多くのSSRF経由のアクセスを防げるとAWSは説明しています（※2）。さらに、新規に起動するインスタンスでIMDSv2を必須に設定しておけば、この経路をあらかじめ塞げます。
奪われた認証情報の権限が広ければ、攻撃者はそのまま別のリソースへ移動し、被害は当初のWebアプリをはるかに超えて拡大します。公開Webの小さな不備が、クラウド全体への侵入口に変わるわけです。
個々の弱点を単体で見ると、深刻度がそれほど高くないと判断されがちです。深刻度を測る代表的なものさしに、CVSS（共通脆弱性評価システム）があります。これは弱点の深刻さを0.0から10.0の数値で表す国際的な指標で、特定の製品ベンダーに依存しない共通基準として、FIRSTという団体が管理しています（※3）。ただし、CVSSが中程度の弱点でも、ほかの弱点と組み合わさると実際の危険度は一変します。
実際にAWSは、自動ペネトレーションテストの解説のなかで、情報漏えいの弱点と権限昇格を組み合わせて機密リソースへ到達する連鎖を例に挙げています（※4）。単体では見過ごされやすい弱点が、つながることで重大なリスクへ育ちます。
弱点を一覧で潰すだけでは、この連鎖を取りこぼしかねません。攻撃者の視点で経路を追うペネトレーションテストが効くのは、連鎖そのものを可視化できるからです。
※1 参考：Amazon Web Services│安全でサイズ変更可能なクラウドコンピューティング – Amazon EC2 –
※2 参考：Amazon Web Services│「EC2 インスタンスメタデータサービスの拡張により、オープンなファイアウォール、リバースプロキシ、SSRFの脆弱性に対する防御を強化しました」. AWS セキュリティブログ
※3 参考：IPA│「共通脆弱性評価システムCVSS v3概説」. 情報処理推進機構
※4 参考：Amazon Web Services│「AWS Security Agent 徹底解説: 自動ペネトレーションテストのためのマルチエージェントアーキテクチャ」. AWS ブログ
AWSでテストを行うときは、公式ポリシーの順守が前提になります。ここを誤解したまま進めると、利用規約違反や他の利用者への影響を招きかねません。古い情報も残るため、最新の公式ページで確かめておくのが安全です。ここから、事前承認なしに実施できる範囲と申請が必要な行為を押さえたうえで、禁止されている行為と利用者が負う責任についてご紹介します。
自分のAWSアカウントのリソースに対するペネトレーションテストは、AWSの事前承認なしで実施できます（※1、※2）。仮想サーバーやデータベース、通信を制御する仕組みなど、公式ポリシーに許可サービスとして挙げられた対象（EC2、WAF、ELB、RDS、CloudFront、API Gateway、Lambdaなど）が中心です。許可サービスはAppSyncやElastic Container Service、Fargateなどへ広がっており、随時更新されるため、実施前に最新の一覧を確かめておくと確実です。許可されるのは自アカウントのリソースに限られ、AWSの基盤そのものや他者のリソースへの評価は認められていません。
ただし、すべての行為が無申請で許されるわけではありません。サービスを停止させるDoSやDDoSを模したシミュレーションは別ポリシーの対象で、専用フォームからの事前申請を要します。
このポリシーでは、対象をAWS Shield Advancedに登録した自社保有のリソースなどに限ること、AWSが承認したDDoSテストパートナーが実施すること、規定の通信量の上限を超えないことなどが条件とされています。これらの条件を満たす承認済みパートナーによる実施であれば、AWSへの個別の事前承認は不要です。
一方、規定の上限を超えるテストや、承認パートナー以外が実施する場合は、例外として専用フォームから、遅くともテスト開始日の2週間前までに申請する必要があります（※3）。自アカウントの許可サービスへの通常のテストか、申請が要るシミュレートイベントかを、計画段階で見分けておきます。
承認の有無とは別に、明確に禁止されている行為があります。DNSの仕組みを悪用する攻撃や、通信を大量に送りつけて相手をあふれさせるフラッディング、ログインやAPIへ要求を集中させる行為、S3バケットやサブドメインの乗っ取りなどが該当します。他の利用者や共有基盤に影響を及ぼすため、テストの名目でも実施できません。
利用者側にも果たすべき責任があります。テストに使うツールが意図せずサービス停止を引き起こさないよう、事前に設定を確かめておく点です。外部の診断会社へ委託する場合も、ポリシーに反しない方法で実施されるよう発注側が確認する責任を負います（※4）。ルールの順守が、AWSと自社の双方を守る土台になります。
※1 参考：Amazon Web Services│「侵入テスト」. AWS クラウドセキュリティ
※2 参考：Amazon Web Services│「AWS リソースでペネトレーションテストを実行する」. AWS re:Post
※3 参考：Amazon Web Services│「DDoS シミュレーションテストポリシー」. AWS クラウドセキュリティ
※4 参考：Amazon Web Services│「侵入テスト」. AWS クラウドセキュリティ
実施できる範囲を押さえたら、次は対象ごとに「何を見るか」について確認しましょう。AWSのペネトレーションテストでは、対象を一律に扱わず、サービスごとに着眼点を変えることが重要です。代表的な対象と確認内容を並べると、次のようになります。
| 対象サービス | 主に確認する内容 |
|---|---|
| IAM（権限管理） | 過剰な権限、ロール設計、権限昇格の経路、認証情報を起点にした横展開の可否 |
| S3（データ保管） | 公開設定、アクセス制御、機密データが外部から読めないか |
| Security Group（通信制御） | 不要なポート開放、管理用ポートの露出 |
| EC2とIMDS | 公開ポート、IMDSv2への移行状況、SSRF経由の認証情報奪取 |
| API GatewayとALB | 認可不備、トークン管理、想定外のアクセス可否 |
| WAFとCloudFront | 防御設定の妥当性、配信経路の制御、オリジンへの直接アクセスなど迂回の余地 |
| Lambdaとコンテナ | 実行ロールの権限、イメージ管理、環境変数やコードへのシークレット埋め込み、周辺構成の不備 |
どこまでを対象に含めるかは、自社のリスクと運用状況によって変わります。相談の段階で対象範囲を切り分けておくと、無駄のないテスト計画につながります。
AWSペネトレーションテストの進め方は、おおむね6つの段階を踏みます。汎用的な流れに、AWS固有の準備を重ねていくのがポイントです。
まず最初に、目的と対象範囲を定めます。このとき、どのアカウントのどのリージョン（地域ごとのデータセンター群）を対象にするかを切り分けておくと、後の混乱を避けられます。次のヒアリングでは、対象URLやIP、AWSの構成情報、実施を避けたい時間帯などを共有します。システムの内部情報を渡したうえで深く掘り下げるホワイトボックス方式なら、IAMの読み取り権限や構成情報を提供すると精度が上がります。
続いてテスト計画を定め、影響を抑える実施方針まで詰めます。本番環境を対象にするなら、通信を制御するSecurity GroupやWeb防御を担うWAFの一時的な調整、除外対象の取り決めが欠かせません。
あわせて、計画段階ではAWSポリシーへの適合も確認します。テスト内容が許可サービスの範囲に収まるか、DoS／DDoSのように例外申請や専用フォームが必要な行為を含まないかを、この時点で切り分けておくと安全です。加えて、テスト中はGuardDutyなどの検知機能がアラートを上げるため、監視担当と事前に共有しておくと、無用な混乱を防げます。
そのうえでテストを実施し、外部公開資産やアプリ、API、権限、構成を攻撃者視点で確かめます。最後に報告と改善案の提示を受け、必要に応じて修正後の再テストで対策の有効性を見届けます。問題を並べて終わりにせず、優先度と改善策まで示されるかどうかが、報告書の価値を左右します。
近年、AIを使った自動ペネトレーションテストが登場し、検証の一部を自動化する動きが出てきました。手動テストの頻度やコストを補う用途として注目される一方で、AIによる自動診断には見過ごせない限界があり、専門家による手動テストを置き換えられるものではありません。ここでは、その代表例であるAWS Security Agentを取り上げながら、自動化に頼りきることのリスクをお伝えします。
AWSは2026年3月31日に、AWS Security AgentによるオンデマンドのAI型ペネトレーションテストを一般提供として開始しました（※）。脆弱性の検出から検証までを自動で回し、手動テストより低コストで高頻度に実施できるとされています。
ここで押さえておきたいのは、この機能が想定する役割です。この機能を使えば、定期実施というボトルネックから脱し、開発の速度に合わせて高頻度に検証を回せます。ただし、向くのはテストとテストの合間に生じる空白期間を縮める用途であり、これだけで深いリスク評価まで完結するわけではありません。自動化はあくまで土台を支える仕組みであり、その上に人の判断を重ねて初めて、実用的なセキュリティ検証になります。
自動診断が得意とするのは、機械的に検出しやすい既知のパターンや、あらかじめ与えた条件の範囲での検証です。近年のAIエージェントは、弱点どうしの連鎖や文脈を踏まえた検出まで担うとされ、急速に進歩しています。もっとも、公表されている性能はベンダー自身の評価によるところが大きく、あらゆる環境で同じ精度が保証されるわけではありません。
一方で、業務ロジックの裏を突く攻撃や、複数の弱点を組み合わせて初めて成立する侵入経路、その企業固有の運用に潜む盲点までは捉えきれません。AWS環境で深刻化しやすいのは、まさにこうした文脈依存の連鎖であり、設定と権限のつながりを人の目で追って初めて見える危険が少なくありません。
加えて、どのリスクを許容し、何を最優先で直すのかという、ビジネス上の影響を踏まえた優先順位づけは、自動化だけで完結しにくい領域です。検出結果を自動で悪用検証するツールも登場していますが、その結果を自社の事業文脈に当てはめて最終的に判断するのは人の役割です。攻撃者の意図を読み、被害の広がりまで見極める総合判断は、経験を積んだ技術者の手動テストに依拠します。自動診断を入り口としつつ、重要なシステムの最終的な安全性は、AWSに精通した専門家の手動テストで担保するのが現実的です。だからこそ、どの会社に検証を託すかが重要になります。
※参考：Amazon Web Services│「AWS Security Agent のオンデマンドペネトレーションテストの一般提供を開始」. AWS ブログ
ペネトレーションテストを外部の専門業者へ委託するなら、価格や実績の多寡だけで選ぶのは避けたいところです。AWSならではの観点で見極めると、ミスマッチを防げます。
まず確かめたいのが、AWSの構成や権限設計まで踏み込んで診られるかどうかです。Webアプリの表面的な部分だけでなく、IAMやSecurity Group、IMDSといったAWS固有の論点を扱えるかが分かれ目になります。次に見ておきたいのが、AWSの許可ポリシーに沿った実施経験があるかどうかです。禁止行為や申請の要否を正しく押さえている会社なら、トラブルの芽を事前に摘めます。あわせて、実施者の技術的な裏づけも確認しておくと選定の精度が上がります。テスターの保有資格やAWSに関する診断実績が分かりやすい判断材料です。
本番環境で影響を抑えながら実施した実績があるかも見ておきたい点です。可用性を保つ進め方を設計できるかは、運用中のシステムを預けるうえで欠かせません。あわせて、弱点の列挙で終わらず改善案まで示すか、再テストに対応するか、対象範囲を柔軟に調整できるかも確かめておくと安心できます。報告書については、改善案に加えて再現手順やPoC（実証コード）が示されるか、対策の優先度がコストや影響とともに整理されているかまで見ておくと、受け取った後の対応がスムーズになります。
AWSペネトレーションテストは、攻撃者が実際にたどる経路をなぞり、弱点が本当に悪用できるのかを見極める検証でした。脆弱性診断が弱点の一覧を示すのに対し、テストは侵入経路と被害範囲まで踏み込みます。AWSでは責任共有モデルのもとで利用者側の設定が狙われやすく、SSRFからIMDS経由でIAMの認証情報が奪われるような、クラウド固有の連鎖が現実のリスクになります。
実施にあたっては、自アカウントのリソースは原則として事前承認なしで行える一方、DDoSシミュレーションのように申請を要する行為や、明確な禁止行為があることを忘れてはなりません。自動テストという新しい選択肢も視野に入れつつ、まずは自社に必要なのが診断なのかテストなのかを切り分け、対象範囲を相談の段階で見定めるところから始めると進めやすくなります。