AWS のセキュリティテスト — 事前申請が不要な範囲と必要な範囲

AWS 上のシステムに脆弱性診断やペネトレーションテストを行うとき、どこまでが事前申請なしでよく、どこからが申請を要するのかは迷いやすい点です。本記事では AWS 公式のポリシーページを2026年8月4日に確認した内容として整理します。ポリシーは改定されるため、実施前には必ず公式の最新版をご自身で確認してください。

「申請不要」とは何が申請不要なのか

公式ページの冒頭には、AWS の利用者は「Permitted Services」として列挙されたサービスについては、事前承認なしに自身の AWS インフラのセキュリティ評価やペネトレーションテストを実施できるという趣旨の記載があります。かつて必要だった申請フォームの提出が、対象サービスについては不要になっている、という位置づけです。

ただし、この「不要」は無条件ではありません。確認時点のページには、少なくとも次の3つの制約が併記されていました。

• 対象は自分の資産だけ。 「Customers are not permitted to conduct any security assessments of AWS infrastructure or the AWS services themselves.」と明記されており、AWS のインフラや AWS サービスそのものへの評価は認められていません。
• C2（Command and Control）を含むテストは事前承認が必要。 「All security testing that includes Command and Control (C2) requires prior approval.」と記載されています。
• 禁止行為は別枠で列挙されている。 対象サービスであっても、後述の禁止行為に該当する操作は行えません。

事前承認なしで評価できると記載されているサービス

確認時点で「Permitted Services」として列挙されていたのは次のとおりです（ページの記載順）。

このリストに載っていないサービスについては、「Customers seeking to test non approved services will need to work directly with AWS Support or your account representative.」と記載されています。つまり一覧に無いものは、AWS Support またはアカウント担当と直接調整するという扱いです。リストは追加・変更されるため、実施前に必ず現物を確認してください。

禁止行為として列挙されているもの

確認時点で「Prohibited Activities」として挙げられていた項目です。

• DNS zone walking via Amazon Route 53 Hosted Zones
• DNS hijacking via Route 53
• DNS Pharming via Route 53
• Denial of Service (DoS), Distributed Denial of Service (DDoS)
• Simulated DoS, Simulated DDoS（DDoS Simulation Testing policy の対象）
• Port flooding
• Protocol flooding
• Request flooding (login request flooding, API request flooding)
• S3 bucket takeover
• Subdomain Takeover

あわせて「Prohibited Services for Outbound Penetration Testing」として Amazon API Gateway と Amazon Bedrock AgentCore の2つが挙げられていました。同じ API Gateway が「評価してよいサービス」にも「外向きテストの禁止サービス」にも出てくるので、混同しないよう注意してください。

関連して、ポリシーには次のような線引きも書かれていました。

• バナーグラビングのようにソフトウェア名とバージョンを取得して既知の脆弱版リストと照合するだけのツールは、このポリシー違反ではないとされています。
• リモートやローカルの exploit の過程でプロセスがクラッシュすること自体は違反ではないとされていますが、そのツールがプロトコル氾濫やリクエスト氾濫を行うことは認められていません。
• それ以外の方法で DoS 状態を作り出す・存在を確認する・実演するツールは明確に禁止とされています。
• DoS 機能を持つツールは、その機能を無効化・解除できることが求められ、できない場合は評価のどの場面でも使用できないとされています。

事前に申請（フォーム提出）が必要と記載されているもの

「Other Simulated Events」の節では、次のものについて Simulated Events フォームの提出が必要と記載されていました。

提出時には、実施日・関係するアカウントID・対象資産・連絡先（電話番号を含む）・計画の詳細を記載するよう求められています。受領確認は2営業日以内に自動応答ではない形で返ってくるとされ、「All Simulated Event requests must be submitted to AWS at least two (2) weeks in advance of the start date.」すなわち開始日の2週間前までの提出が求められています。承認後は追加の手続きは不要で、申告した期間の終わりまでテストを実施してよい、と記載されています。

申請先はメールではなく Support コンソールのフォームです。確認時点のリンク先は次のとおりでした。

• Simulated Events フォーム： https://console.aws.amazon.com/support/contacts#/simulated-events
• AWS 中国（寧夏・北京）リージョン向け： https://console.amazonaws.cn/support/contacts#/simulated-events
• Stress Test policy： https://aws.amazon.com/ec2/testing/
• DDoS Simulation Testing policy： https://aws.amazon.com/security/ddos-simulation-testing/

実施側が負う責任として書かれていること

• テストは AWS カスタマーアグリーメントの条件に従うこと。
• 対象のサービス・帯域・毎分リクエスト数・インスタンスタイプの範囲に限定されること。
• AWS のツールやサービス自体に起因する脆弱性を発見した場合は、テスト完了から24時間以内に AWS Security へ連絡すること。連絡先として aws-security@amazon.com が示されています。
• テストや評価活動によって AWS または他の AWS 利用者に生じた損害について、実施者が責任を負うこと。
• AWS がテストに関連する不正利用報告（abuse report）を受け取った場合、それは実施者に転送されます。回答時には、第三者の報告者に共有できる形で用途と連絡先を提示するよう求められています。
• AWS サービスのリセラーは、自社の顧客のセキュリティテスト活動について責任を負うとされています。

実施前のチェックリスト

本記事の内容を根拠に本番環境へテストを打たないでください。そのうえで、公式ページを読む際の観点として次を挙げておきます。

1. 対象サービスが、現時点の Permitted Services に載っているか。
2. テスト対象が自分（自社）の資産に限定されているか。マルチテナントの相乗り先や、他社が管理する資産が混ざっていないか。
3. 使うツールに DoS 相当の機能が含まれていないか。含まれる場合、その機能を確実に無効化できるか。
4. C2・フィッシング模擬・マルウェア検証・負荷試験が計画に含まれていないか。含まれるなら、2週間前までのフォーム提出が必要と記載されている。
5. 社内の承認、対象システムの所有者からの合意、実施記録の残し方が整っているか（これは AWS のポリシーとは別に必要です）。