はじめに

以前、AWS Security Agent（以下、Security Agent）のコードレビューで使用するカスタムセキュリティ要件に関するクセ強仕様を記事にまとめました。

今回は、Security Agentの別機能であるペネトレーションテストについて、主にネットワーク観点での仕様・注意点をまとめました。

本記事は、2026年10月14日の情報に基づいて記載しています。
Security Agentの仕様がアップデートされて、記事の内容が古くなる可能性がありますので、予めご了承ください。

ターゲットドメイン

ターゲットドメインは、ペネトレーションテストを実行するアプリケーションのドメインです。
ペネトレーションテストを実施するには、対象のドメインの所有権があることを証明する必要があります。（もし所有権チェックが無ければ、外部公開された第三者のアプリに勝手にペネトレを仕掛けることが出来てしまうため）

この所有権のチェックには以下の3通りの方式があります

チェック方式	内容
DNS_TXT	対象ドメインを管理するDNSサーバーに、AWS指定のTXTレコードを追加
HTTP_ROUTE	ドメイン上の特定のURLに、AWS指定の検証ファイルをホストすることで、ドメインの所有権を検証
PRIVATE_VPC	プライベートVPC侵入テストにのみ使用可能。ドメインがプライベート CIDR 範囲内の IP に解決されることを確認

DNS_TXT方式は、AWS Certificate ManagerのDNS検証に似ていますね。
DNS_TXT方式とHTTP_ROUTE方式は、いずれもAWSのマネージドネットワークから対象DNSサーバー、対象URLにアクセス出来る必要があります。（つまりパブリックアクセス可能である必要があります）

つまり、実質、DNS_TXT方式とHTTP_ROUTE方式はパブリックドメイン専用で、プライベートドメインの場合はPRIVATE_VPC方式一択となります。

パブリックドメインをペネトレーションテストする際、テスト実施者がDNSサーバー管理者・Webサーバー管理者を兼任していない場合、事前にそれらの管理者に協力していただく必要があります。

ターゲットドメインのサブドメインはテスト対象に指定できるのか？

例えば、ターゲットドメインとして example.com を検証したとします。
この場合、 api.example.com のようなサブドメインもテスト対象に指定できるのでしょうか。

これについては、ターゲットドメインの認証方式によって異なります。

DNS TXT または HTTP ルート検証で検証した場合は、サブドメインも追加検証なしでテスト対象として指定可能です。ただし、Private VPC方式の場合は、検証したドメインと完全一致したドメインのみ、テスト対象として指定可能です。（つまり、サブドメインもテストしたい場合、サブドメインも検証する必要がある）

When you verify a domain using DNS TXT or HTTP route verification, sub-domains of that domain are automatically covered. For example, verifying example.com allows you to test api.example.com or billing.example.com without additional verification. For Private VPC verification, the target endpoint domain name must match the full domain name configured for verification.

出典: Enable an application domain for penetration testing（AWS公式ドキュメント）

なお、ペネトレーションテスト作成画面のTipには以下のように記載されており、サブドメインもターゲットURLに明示的に追加することが推奨されています。

For best results, include all domains that are part of your application's user flow, including subdomains for APIs, authentication services, and content delivery. Sub-domains of a verified parent domain do not require separate verification.

出典: Create a penetration test（AWS公式ドキュメント）

ターゲットURL/除外URL

ターゲットURLは、その名の通りペネトレーションテストのターゲットとなるURLです。
除外URLは、ペネトレーションテストのターゲットから除外するURLです。

ターゲットURLの配下パスはテスト対象に含まれるのか？

例えば、ターゲットURLに https://example.com/ を指定したとします。
この場合、 https://example.com/aaa のような配下パスはテスト対象に含まれるのでしょうか。

こちらは、ターゲットドメインの認証方式に関係なく、対象に含まれるようです。（除外URLに指定したURLは除く）

公式ドキュメントに以下のように記述されています。

AWS Security Agent will do a breadth-first exploration of the target application(s) and attempt to exercise it normally before attempting any exploits. This allows it to build a working understanding of the application at runtime and discover critical application logic and endpoints.

出典: Security Considerations for AWS Security Agent（AWS公式ドキュメント）

したがって、example.comをターゲットに指定した場合、以下のいずれもテスト対象に含まれるようです。

example.com/aaa
example.com/bbb
example.com/aaa/bbb/ccc

ただし、 テスト中に全パスを網羅することが保証されているわけではありません。 AIエージェントの確率論的な動作の性質上、すべてのエンドポイントを発見・テストすることは保証されません。

Given its stochastic nature, AWS Security Agent is not guaranteed to discover and test all critical applications and endpoints for any target application.

出典: Security Considerations for AWS Security Agent（AWS公式ドキュメント）

除外URLに指定したパスの配下パスは除外に含まれるのか？

例えば、除外URLに https://example.com/aaa を指定したとします。
この場合、 https://example.com/aaa/bbb のような配下パスは除外対象に含まれるのでしょうか。

こちらは、ターゲットドメインの認証方式に関係なく、対象に含まれるようです。

公式ドキュメントに以下のように記述されています。

Specify URL paths that should not be tested during the penetration test. AWS Security Agent excludes the specified path and all paths nested beneath it. For example, if you add https://example.com/admin as an out-of-scope URL, https://example.com/admin/tools is also out-of-scope.

出典: Create a penetration test（AWS公式ドキュメント）

したがって、example.com/aaaを除外URLに指定した場合、以下のいずれも除外対象に含まれるようです。

example.com/aaa
example.com/aaa/bbb
example.com/aaa/ccc/ddd

ただし、パスプレフィックスの一致ではなく、パス階層としてのネストが条件なので、例えば以下のURLは除外されないようです。

example.com/aaabbb → 除外されない

外部リンク/外部API

アプリケーションによっては、外部リンクが貼られていたり、外部APIを呼び出すものもあるかと思います。

ターゲットのWebページから辿れる外部リンクはテスト対象に含まれるのか？

例えば、example.comをターゲットに指定したとします。
example.comのWebページ上にexternal.comへのリンクが存在している場合、external.comもテスト対象に含まれるのでしょうか。

外部リンク先は対象に含まれません。ターゲットURL以外へのアクセスはネットワークレベルでブロックされます。（Accessible URLに指定したURLは除く）

AWS Security Agentには、ターゲットURLおよびAccessible URLsに指定されていないエンドポイントへのアクセスをネットワークレベルでブロックする機能が存在するようです。

All network dependencies required for testing must be specified as either target URLs or accessible URLs. The network blocks access to any unspecified endpoints.

出典: Security best practices for AWS Security Agent（AWS公式ドキュメント）

Requests to URLs outside of the target and accessible URLs will be blocked by the network.

出典: Security Considerations for AWS Security Agent（AWS公式ドキュメント）

したがって、example.comをターゲットに指定した場合、example.comのWebページ上にexternal.comへのリンクが存在していても、ネットワークレベルでブロックされ、アクセスすることは出来ません。
なお、external.comがAccessible URLsに含まれている場合、アクセス自体は可能ですが、脆弱性テストの対象にはなりません。（ログインやナビゲーション等の目的でのみ利用されます）

Accessible URLsの用途

Accessible URLsは、テスト対象ではないがテスト実行に必要なサービス（認証プロバイダー、CDN等）を指定するためのものです。

A URL the penetration test can access but must not attack. Use this for a hosted login page, a content delivery network (CDN), or another supporting service your application depends on.

出典: Create a penetration test（AWS公式ドキュメント）

Accessible URLsのセキュリティへの影響

Accessible URLsに指定したドメインに対しては、テスト中に認証情報を含むデータが送信される可能性があります。

AWS Security Agent is not instructed to perform security testing on accessible URLs. By specifying accessible URLs, you indicate trust in these dependencies. Penetration test data, including credentials, may be transmitted to these accessible URL endpoints during testing."

出典: Security best practices for AWS Security Agent（AWS公式ドキュメント）

ターゲットのWebページからアクセスする外部APIはテスト対象に含まれるのか？

外部APIも外部リンク同様、ターゲットURLに含まれないURLはアクセス対象外となります。

ただし、CloudFront → API Gateway → Lambda → 外部API のような仕組みだと、結果的に外部APIが呼ばれてしまう可能性があります。

この構成では、example.com にアクセスすると、CloudFront → API Gateway経由でバックエンドのLambdaが呼び出されます。そして、そのLambdaが外部API external.api を呼び出し、結果を返却します。

この場合、Security Agentが認識しているURLはあくまで example.com で、 external.api は隠ぺいされているので、Security Agentは example.com にリクエストを送ってしまい、結果的に外部APIが呼ばれる可能性があります。

対象アプリのアーキテクチャも理解したうえで適切にターゲットURL、除外URL、Accessible URLsを設定しましょう。

ポート番号

ポート番号については、以前はHTTP/HTTPS通信のデフォルトである80/443ポートにしか対応していなかったようですが、2026年10月14日現在では、それ以外のポート番号にも対応しています。
デフォルト以外のポートを指定したい場合、ターゲットドメインの指定で、 https://example.com:8443 のようにポート番号を指定します。

2026年10月14日現在では、日本語版の公式ドキュメントには上記に関する記載が無く、英語版にしないと確認ができません。

出典: Create a penetration test（AWS公式ドキュメント）

■ 英語のドキュメント

■ 日本語のドキュメント

プロキシ

Security Agentは、明示的プロキシを通過できません。
Security Agentの設定項目にプロキシの設定はなく、認識させることが出来ません。
更に、明示的プロキシの場合、HTTPS通信ではCONNECTメソッドでプロキシに接続しますが、Security AgentはCONNECTメソッドにも対応していません。

ただし、透過型プロキシであれば通過可能です。透過型プロキシであれば、Security Agentがプロキシの存在を認識する必要がありませんし、CONNECTメソッドも必要ないためです。

上記については、AWSサポートにも確認済みです。

プロキシについては、以下のサイトの解説が分かりやすかったです。

おわりに

以上、Security Agentのペネトレーションテストに関する、ネットワーク系の仕様・注意点でした。
ペネトレーションテストは1タスク時間あたり50USDと結構なコストですので、適切な事前準備とURL設定を行い、「設定ミスで上手くいかなかった」という事が無いようにしたいものです。

これからペネトレーションテストを試そうとしている方に、本記事が少しでも参考になれば幸いです。