こんにちは、テクニカルサポート課の坂本（@t_sakam）です。先日、re:Invent 2025 で発表された「AWS Security Agent」のペネトレーションテスト（ペンテスト）機能について、「【AWS Security Agent】ペンテストのススメ」というタイトルで社内勉強会を開催しました。今回は、その際に実際に紹介した内容をブログにまとめています。
※ AWS Security Agent はパブリックプレビューとして案内されており、執筆時点では米国東部（バージニア北部、us-east-1）リージョンで利用可能です。
はじめに
今回の検証では、公開 Web アプリケーションとして WordPress 環境、閉域アプリケーションとして OWASP Juice Shop 環境の 2 つを用意し、AWS Security Agent によるペンテストを実施しました。あわせて、AWS WAF 導入前後で結果がどのように変化するのかも比較しています。
WordPress は公開 Web アプリケーションに対する検証例として、OWASP Juice Shop は閉域アプリケーションに対する検証例として選定しました。特に OWASP Juice Shop については、社内アプリケーションの開発段階や検証環境に近い前提でも AWS Security Agent を活用できるかを確認したかったことに加え、意図的に多数の脆弱性を含むアプリケーションであるため、安全に試しやすいよう VPC 内で完結する閉域構成としています。
このブログでは、AWS Security Agent のペンテスト機能がどのような前提で利用できるのか、公開構成と閉域構成でどのように検証できるのか、そして AWS WAF による防御とアプリケーション自体の修正をどのように捉えるべきかを確認していきます。
利用にあたっての注意点も冒頭にまとめていますので、よろしければ併せてご確認ください。
- はじめに
- AWS Security Agent とは
- ペンテストとは？
- Security Agent のペンテスト機能の注意点
- 検証の前提と構成について
- 検証環境の構成
- AWS WAF 有無の検証結果
- まとめ
AWS Security Agent とは
AWS Security Agent は、設計レビュー、コードレビュー、ペンテストを通じて、アプリケーション開発におけるセキュリティ確認を支援するサービスです。今回の記事では、その中でもペンテスト機能に焦点を当てます。
発表時に以下の速報ブログも書いていますので、先に確認いただけると概要をつかんでいただきやすいかと思います。速報ブログでは、AWS マネジメントコンソール側と Security Agent の Web アプリ側の両方で設定が必要になる点にも触れています。
ペンテストとは？
ペネトレーションテスト（ペンテスト）とは、端的に言うと、攻撃者の視点で実際の攻撃シナリオを模し、悪用可能な弱点がないかを確認するセキュリティテストです。
Security Agent のペンテスト機能の注意点
注意点① 専門家によるペンテストを置き換えるものではない
AWS Security Agent のペンテスト機能は、開発ライフサイクルの中でオンデマンドにセキュリティ検証を行うための機能です。
AWS の公式ドキュメントでも、専門家によるペンテストを完全に置き換えるものではなく、セキュリティレビューのワークフローに組み込んで活用する補完的な機能として位置づけられています。
AWS Security Agent は、専門家によるペンテストサービスではなく、セキュリティレビューのワークフローに組み込んで活用することが推奨されています。（日本語訳）
引用: Security Considerations for AWS Security Agent and AI assisted penetration testing
注意点② アプリケーションの状態が変わる可能性がある
AWS Security Agent は Kali Linux ディストリビューションに含まれる包括的なペンテストツール群を利用しており、アプリケーションの状態、データ、システム設定を変更する可能性があります。
AWS Security Agent は Kali Linux ディストリビューションに含まれる包括的なペンテストツール群を利用します。これらのツールはセキュリティ上の脆弱性を特定するためのものであり、アプリケーションの状態、データ、システム設定を変更する可能性があります。（日本語訳）
引用: Security best practices for AWS Security Agent
そのため、ペンテストは公開環境、閉域環境を問わず、本番環境ではなく、本番相当の non-production 環境で実施するのが望ましいです。
ペンテストは、本番環境を模した non-production 環境に対して実施することがベストプラクティスです。（日本語訳）
引用: Security best practices for AWS Security Agent
最初に素の状態の WordPress 環境に実行した際は、コメント欄を閉じていなかったため、Security Agent が 130 個以上のコメントを書き込んでいることが確認できました。
注意点③ ペンテスト実行ごとに結果が変動しうる
AI エージェントが自律的に考えながらペンテストを実行するため、毎回まったく同じテストが行われるわけではありません。
今回の検証でも、Discovered Endpoints（検出されたエンドポイント）の数や Findings（検出結果）の内訳には差が見られました。
AWS Security Agent は動的にアプリケーションを探索しながら評価を進めるため、実行ごとに発見されるエンドポイントや攻撃経路が変動する場合があります。そのため、単発の結果だけで断定せず、必要に応じて複数回の再実行や個別確認を前提に解釈する必要があります。
AWS Security Agent は、AI エージェントを使用してセキュリティ分析を実行します。AI システムは非決定論的な性質を持つため、侵入テストの実行結果は、実行ごとに異なる場合があります。（日本語訳）
引用: Security best practices for AWS Security Agent
WAF で対策を講じた後の再テストでは、WAF の存在を踏まえたうえで、更に別のテストを試しているように見受けられました。
検証の前提と構成について
今回の検証条件を、先にまとめておきます。今回は、認証情報や追加リソースを付与せず、シンプルにアプリケーションの URL を指定してペンテストを実行しています。
・対象 URL は、所有確認済みのドメイン配下のみを指定して実行
・OWASP Juice Shop は閉域構成のため、VPC 設定を付与して実行
・認証情報は付与せず、未認証で到達可能な範囲を対象に実施
・GitHub リポジトリ、設計資料、S3、アップロードファイルなどの追加リソースは付与していない
検証環境の構成
今回は、初回は AWS WAF なしの状態でペンテストを実行し、その後に AWS WAF を導入して再検証しました。
WAF が万能ではないことは前提としつつ、今回の検証では、AWS Security Agent の結果が AWS WAF 導入前後でどのように変化するかを比較し、周辺レイヤーで抑止しやすい問題と、アプリケーション側での見直しが必要な問題の切り分けを確認しました。
構成① WordPress 環境（公開構成）
ポイント：CloudFront の VPC オリジンを用いて、公開入口を CloudFront に集約した構成
WordPress 環境では、実運用に近い公開 Web アプリケーションを想定し、Amazon CloudFront を外部公開の入口として利用しました。
オリジンには CloudFront の VPC オリジンを用いて、プライベートサブネット上の Internal Application Load Balancer（Internal ALB）を接続しています。公開 URL でアクセスできる一方で、アプリケーション本体を直接インターネットへ公開しない構成です。
CloudFront の VPC オリジンは、CloudFront を単一の公開エントリポイントにしつつ、プライベートサブネット上の ALB、NLB、EC2 をオリジンとして利用できる仕組みで、今回のようにアプリケーション本体を直接インターネットへ公開したくない場合の有力な構成選択肢だと考えています。
他も基本的に Multi-AZ の構成を意識しましたが、テスト環境のため、RDS は Single-AZ としています。
CloudFront の VPC オリジンを使用すると、プライベートサブネット内の Application Load Balancer、Network Load Balancer、または EC2 インスタンスをオリジンとして設定できます。（日本語訳）
引用: VPC オリジンを使用したアクセス制限 - Amazon CloudFront
今回 WordPress 環境を題材に選んだのは、公開 Web アプリケーションに対して AWS Security Agent と AWS WAF をどのように組み合わせて考えるかを説明しやすかったためです。特に、不要機能の無効化や特定 URI への制御といった、比較的シンプルな対策で効果を確認しやすい点は、実務に持ち帰る際の判断材料としても扱いやすいと考えました。
構成② OWASP Juice Shop（閉域構成）
ポイント：VPC 設定を付与することで、閉域アプリケーションにも適用可能
OWASP Juice Shop は、学習や演習向けに意図的な脆弱性を多数含むことが知られているアプリケーションです。今回は公開インターネットには出さず、VPC 内で完結する閉域構成で検証しました。
今回、OWASP Juice Shop を閉域構成にしたのは、社内アプリケーションや開発段階の Web アプリケーションに近い条件で検証したかったためです。あわせて、OWASP Juice Shop は意図的に多数の脆弱性を含むため、実際に外部から攻撃可能な状態に置くことは避け、安全に試しやすい構成とする観点でも閉域化を選びました。社内勉強会でも、公開サービス向けの診断だけでなく、閉域の検証環境に対する事前確認の選択肢として紹介したいと考えていました。
今回のターゲットドメインは、このブログ上では、例示用の予約ドメインである example.com 配下の juiceshop.lab.example.com を実際にテストで指定した URL と想定して説明します。今回の検証では、対象 URL を指定するだけのシンプルな条件でペンテストを実行していますが、事前に DNS 検証（もしくは HTTP ルート検証）が必要です。
AWS Security Agent でペンテストを有効化するには、ターゲットドメインの所有確認が必要です。今回は juiceshop.lab.example.com をターゲットドメインとして登録し、DNS 検証を行いました。
アプリケーションに対してペネトレーションテストを実行するには、まずターゲットドメインを追加し、その所有権を確認する必要があります。AWS Security Agent は、所有権が確認されたドメインに対してのみペネトレーションテストを実行します。
注
アプリケーションが使用する可能性のある関連ドメインの検証は不要です。ペネトレーションテストを実際に実行するドメインのみを検証すれば十分です。（日本語訳）
引用: Enable an application domain for penetration testing - AWS Security Agent
AWS マネジメントコンソール側のエージェントスペースでの設定では、OWASP Juice Shop 向けに VPC、セキュリティグループ、サブネットをあらかじめ登録しました。公式ドキュメントでも、エージェントスペース側では [VPC]、[Subnets]、[Security groups] を登録する流れになっています。また、[Enable penetration test] では、高可用性のため複数 AZ にまたがる複数サブネットを選択するように案内されています。今回はここで 4 つのサブネットを登録しました。
高可用性を確保するには、複数のアベイラビリティゾーンから複数のサブネットを選択してください。（日本語訳）
引用: Enable penetration test - AWS Security Agent
一方で、Security Agent の Web アプリ側で個別のペンテストに [VPC Resources] を設定する画面では、少なくとも今回確認した UI では 1 つの [Subnet] しか選択できませんでした。（プルダウンでは、先ほど指定した 4 つのサブネットが表示されるのですが、選択は 1 つしかできない。）
※ この挙動については、プレビュー中の一時的な UI 上の制約なのか、あるいは AWS マネジメントコンソール側で登録したサブネットの中から Web アプリ側でさらに選択する仕様なのか、今回の検証時点では判断できませんでした。
ペンテストを実行する 1 つ以上のサブネットを選択します。選択するサブネットは、対象アプリケーションにネットワーク到達性があるものにしてください。ペンテストは、これらのサブネットにデプロイされたリソースから実行されます。（日本語訳）
引用: Create a penetration test - AWS Security Agent
今後 UI や仕様が変わる可能性はありますが、今回の画面上の挙動と、後述する AWS WAF の観測結果を見る限り、少なくとも今回の実行では、Web アプリ側のペンテスト設定画面で選択した 1 つのサブネットを起点に通信していました。
WAF の観測結果とあわせてみても、少なくとも今回の検証では、Security Agent の Web アプリ側で選択した 1 つのサブネットを起点に閉域アプリケーションへ到達していたと考えています。
また、ペンテスト開始後の画面では、テスト実行環境のセットアップが先行して実行されていました。タスクログには、「Connecting to pentest test environment container（ペネトレーションテスト環境のコンテナへの接続）」といった記録も表示されており、テスト実行環境やネットワーク設定が順次準備されている様子を確認できました。
AWS WAF 有無の検証結果
検証結果① WordPress
WordPress 環境では、初回および再検証の過程で、XML-RPC 機能を起点とする SSRF（サーバーサイドリクエストフォージェリ）が重大な問題として検知されました。
WordPress の XML-RPC 機能とは？
・XML-RPC は、WordPress を外部から操作するための API（xmlrpc.php）
・SSRF は、サーバーに意図しない宛先へ通信させる脆弱性
・pingback は XML-RPC の一機能で、相手サイトへ「リンクしたよ」と通知する仕組み
・このとき、自分の WordPress サーバーが相手のサーバーへ通信するため、この機能が悪用されると、意図しない宛先へ通信させられることがある（SSRF につながることがある）
AWS WAF でカスタムルールを追加
今回の検証では、WordPress 環境に対して、xmlrpc.php へのアクセスを対象とする AWS WAF のカスタムルールを追加しました。具体的には、URI パスに xmlrpc.php を含むリクエストを Block する設定としています。WordPress の XML-RPC は環境によっては不要である一方、悪用の起点として扱われることがあるため、利用していない場合は遮断する判断が取りやすい部分です。
今回は、問題となった機能や URI が比較的明確だったため、まずは不要機能の無効化やカスタムルールによるピンポイントな制御を優先しました。社内勉強会でも、特定の危険な機能やエンドポイントがはっきりしている場合は、まずシンプルな対策で抑止できないかを確認し、そのうえで必要に応じてマネージドルールも検討する、という考え方を共有しました。
xmlrpc.php を含むリクエストを Block する設定とした複数回の再検証を行う中では、Medium や Low の指摘が出る回もあり、検出内容には揺れがありました。上記の XML-RPC 向けカスタムルールの他にも、WordPress 側で利用していない機能を無効化したり、AWS WAF のルール追加によって段階的に対策を行いました。
その後、最終的な再検証では、いったん検出された内容も最終的には問題がないと Security Agent が判断し（False Positive（偽陽性））、Confirmed Findings（確認済みの検出結果）は 0 件となりました。念のため、再度ペンテストを実行しましたが、その際も 0 件となりました。
もちろん、これだけでアプリケーションの安全性を完全に保証できるわけではありませんが、不要機能の無効化と AWS WAF のルール追加によって、少なくとも主要な攻撃面に対する抑止効果は確認できました。
WordPress 環境では比較的早い段階で結果が収束したため、以降は、より多くの問題が残り、レポート内容や AWS WAF の効き方を比較しやすかった OWASP Juice Shop の結果を中心に見ていきます。
検証結果② OWASP Juice Shop
OWASP Juice Shop についても、AWS WAF の導入前後で数回にわたってペンテストを実行しました。
導入前の結果では、Critical 3 件、High 5 件、Medium 5 件の、合計 13 件の確認済みの検出結果が報告されました。
レポート本文でも、SQL インジェクション（入力経由で SQL クエリを注入し、想定外のデータ取得や更新を引き起こす問題）、JWT の署名検証不備（改ざんされたトークンを受け入れてしまう問題）、IDOR（識別子の改変によって他ユーザーのデータへ不正にアクセスできる認可不備）など、アプリケーションの根幹に関わる重大な問題が報告されており、意図的に脆弱性を含むアプリケーションであることがよく分かる結果でした。
「検出結果」画面を確認すると、Critical から Medium まで複数の問題が一覧化されており、その中には認可不備の典型例として分かりやすい IDOR も含まれていました。
IDOR（Insecure Direct Object Reference）とは？
・他人のデータやリソースを、ID だけ変えて参照できてしまう脆弱性
例：https://example.com/user_id/1001
URL の 1001 を 1002 に変えたら他人のプロフィールや注文が見えてしまう
・原因は、その ID のデータにアクセスしてよい本人かどうかをサーバー側で確認していないこと
・ログインしているだけでは不十分で、そのデータへの権限確認が必要
・IDOR は「認可不備」なので、SSRF や SQLi よりも AWS WAF での一般的な防御が難しく、基本は設計や実装の修正が必要
・Security Agent の出番（設計レビューで設計を見直す、コードレビューでコードを修正する）
「検出結果」画面
IDOR の検出結果では、認証自体は通過していても、対象リソースの所有者確認が不十分なため、他ユーザーのアドレス情報を書き換えられる可能性があると指摘されていました。
AWS WAF でマネージドルールを追加
OWASP Juice Shop 環境では、指摘が多かったため、再検証にあたりカスタムルールではなく AWS WAF のマネージドルールを追加しました。今回追加したのは、AWSManagedRulesCommonRuleSet、AWSManagedRulesKnownBadInputsRuleSet、AWSManagedRulesSQLiRuleSet、AWSManagedRulesLinuxRuleSet、AWSManagedRulesAdminProtectionRuleSet の 5 つです。今回は、既知の攻撃パターンに対するベースライン防御をいくつか追加したうえで、結果がどのように変化するかを再確認しました。
それぞれの大まかな役割は次のとおりです。
・AWSManagedRulesCommonRuleSet
一般的な Web 攻撃パターンに対するベースライン保護
・AWSManagedRulesKnownBadInputsRuleSet
既知の不正入力や、探索・悪用に関連するリクエストパターンへの対策
・AWSManagedRulesSQLiRuleSet
SQL インジェクション関連のリクエストパターンへの対策
・AWSManagedRulesLinuxRuleSet
Linux 固有の脆弱性悪用パターン、特に Local File Inclusion（LFI）系のリクエストパターンへの対策。本来は AWSManagedRulesUnixRuleSet と組み合わせて使用することが推奨される
・AWSManagedRulesAdminProtectionRuleSet
一般的な管理ページ向け URI パスへのアクセス抑止
※ 今回追加したルールセットの選定は、比較しやすい初期セットとしての意味合いが強く、特定のアプリケーション特性に合わせて最適化しているものではありません。実務で利用する際は、対象アプリケーションの機能や想定する攻撃パターンを踏まえて、カスタムルールとマネージドルールの使い分けや、適用するルールグループの選定を行う必要があります。
AWS Managed Rules は、アプリケーションの脆弱性やその他の望ましくないトラフィックからの保護を提供する、管理されたルールグループです。（日本語訳）
引用: AWS Managed Rules for AWS WAF
その後、AWS WAF を適用して再検証したところ、Critical 2 件、High 3 件、Medium 6 件の、合計 11 件の確認済みの検出結果が報告されました。
件数や内訳には変化が見られ、AWS WAF で抑止しやすい攻撃パターンに対しては防御効果が確認できました。
また、AWS WAF のダッシュボードでは、マネージドルールによって大量のリクエストがブロックされていることを確認できました。
AWSManagedRulesCommonRuleSet だけでも 1,000 リクエスト以上をブロックしていましたが、残りのマネージドルールでも同様に大量のリクエストがブロックされていました。
さらに、AWS WAF のログエクスプローラーでは、送信元が Security Agent の Web アプリで指定したサブネットのプライベート IP アドレス帯となっているアクセスが確認できました。閉域構成の OWASP Juice Shop に対して、指定した VPC 設定を利用した通信が行われていたと言えるかと思います。
今回の再検証では、想定どおり、既知の攻撃パターンに対しては AWS WAF による抑止効果が見られた一方で、認可不備やアプリケーション実装に起因する問題は残存しました。今回の結果からも、WAF のような周辺レイヤーで抑止しやすい問題と、設計・実装での修正が必要な問題は分けて考える必要があることを確認できました。そうした意味でも、Security Agent がペンテストにとどまらず、設計レビューやコードレビューまで含めて活用できるのは大きく、検出だけで終わらせず、設計・実装の改善につなげていける点に価値があると感じました。
まとめ
今回の検証を通じて、AWS Security Agent のペンテスト機能は、公開 Web アプリケーションだけでなく、VPC 内の閉域環境にあるアプリケーションに対しても適用できることを確認できました。特に OWASP Juice Shop を用いた検証では、閉域構成のアプリケーションに対してもペンテストを実行できることが確認でき、社内アプリケーションや開発段階の検証環境でも活用しやすいことが分かりました。
今回の収穫は、AWS WAF が万能かどうかを確認したことではなく、AWS Security Agent を用いることで、公開構成と閉域構成の両方において、周辺レイヤーで抑止しやすい問題と、設計・実装で見直すべき問題をどのように切り分けられるかを具体的に観測できた点にあります。
WordPress 環境では、不要機能の無効化や AWS WAF のカスタムルール追加によって、最終的に確認済みの検出結果を 0 件まで減らすことができました。一方で OWASP Juice Shop では、AWS WAF のマネージドルールを適用することで一部の攻撃パターンに対する防御効果は確認できたものの、認可不備やアプリケーション実装に起因する問題は残り続けました。
AWS Security Agent は、専門家によるペンテストを置き換えるものではありませんが、設計レビュー、コードレビュー、ペンテストを開発ライフサイクル全体で組み合わせ、継続的にセキュリティ確認を行うための有力な選択肢になるのではないかと思いました。
AI 開発時代における AWS Security Agent の重要性
AI を活用した開発によって、短いサイクルでアプリケーションが作られていく場面は今後さらに増えていくと考えられます。一方で、開発スピードが上がるほど、設計や実装の段階で見落とされるセキュリティ上の問題も増える可能性があります。
そのような中で、AWS Security Agent のように、設計レビュー、コードレビュー、ペネトレーションテストを通じて継続的にセキュリティ確認を支援してくれる仕組みは、今後ますます重要になっていくのではないでしょうか。
特に、公開アプリケーションだけでなく、VPC 内の閉域環境にも適用できる点は、社内アプリケーションや開発段階の検証環境においても活用しやすく、実運用に入る前から継続的にセキュリティ確認を行うための選択肢として有用だと感じました。
【AWS Security Agent】ペンテストのススメ
AWS Security Agent はプレビュー期間中は無料ですので、気になっていた方は、まずは安全に試しやすい閉域環境で試してみてはいかがでしょうか？
