![[アップデート] AWS Continuum のペネトレーションテストでテスト実施前に認証情報のテストと到達ドメインの提案ができるようになりました](https://images.ctfassets.net/ct0aopd36mqt/5HhaOnXgcaK80eorXpnxyD/57c471f47b2f7e9c65e7bc2f185a9184/aws-security-agent.png?w=3840&fm=webp)
[アップデート] AWS Continuum のペネトレーションテストでテスト実施前に認証情報のテストと到達ドメインの提案ができるようになりました
いわさです。
AWS Continuum for penetration testing は、AI エージェントを使って Web アプリケーションにペネトレーションテストを実行できるサービスです。
以前は AWS Security Agent と呼ばれていました。突然サービス名変えたり統合されると困惑しますね。未だに Security Agent って呼んでますよ。私は。
このペネトレーションテストを作成するとき、対象の URL（Target）と、テストはしないけどもアクセスは許可するドメイン（Accessible）を設定する必要があります。
これまでは、認証が必要なアプリの場合はログイン後に到達するドメインを自分で洗い出して Accessible に入れる必要があり、さらにその認証情報が通るかも実際にテストを実行させるまで分からず、テストを実施した後にテストの不足に気がつくことがありました。
最悪実施したテストが無駄に終わることも。一発で 1,000 USD とかいくこともあるので、それを実施した後に「無駄なテストでした」は精神的ダメージが大きそうです。
先日のアップデートで、テスト設定のフェーズで事前に認証情報をテストし、ログイン中に到達したドメインをスコープ候補として提示してくれるようになりました。
これによって、テスト実施前に事前にスコープ候補の漏れや認証情報の誤りなどに気がつくことが出来るようになります。すごい。
今回こちらを確認してみたので紹介します。
検証用のアプリを用意する
まず、認証情報テストの動きを見るために検証用の Web アプリを用意しました。
ログイン後に複数のドメインへ到達する構成にしたかったので、次のようにしています。
secapp.tak1wa.com… ログインフォームとログイン後のダッシュボードapi.tak1wa.com… ダッシュボードが読みに行く JSON APIassets.tak1wa.com… CSS や JavaScript を配信
ログインするとフロントエンドが api.tak1wa.com にアクセスしたり、静的コンテンツとして assets.tak1wa.com を読みに行くなど、まぁよくある構成ですね。
中身はなんでも良いのですが今回は API Gateway + Lambda で、3 つのサブドメインを 1 つの Lambda にまとめています。
組み込みのログイン画面
顧客に何の価値も提供しないダッシュボード
認証情報を追加してテストする
AWS Continuum 側は、事前にテストの実行単位となるエージェントスペースの作成と、検証環境用のtak1wa.com のドメイン検証を済ませてあります。
この手順は以前の記事で紹介しているので、詳細はそちらを参照してください。ここでは割愛します。
ペネトレーションテストの作成ウィザードは 5 ステップあって、今回のアップデートに関係するのは Credentials（認証情報）と Network configuration（ネットワーク設定）の 2 つです。
Penetration test details で Target URL に https://secapp.tak1wa.com を設定したあと、Credentials ステップに進みます。
ここで「Add credential」を押すことで認証情報を登録できます。
今回は検証用アプリなので Input credentials でユーザー名とパスワードを直接入力しました。
Access URL に Target URL を選び、Agent Space login prompt にログインの手順を書きました。
ログインプロンプトは、エージェントにどうやってログイン画面にたどり着き、フォームを埋めて、ログインが成功したことをどう確認するかを伝えるものみたいです。
なお公式ドキュメントには次のように、本番の認証情報は使わないよう注意書きがあります。
エージェントはログインしたユーザーがアクセスできるものを一通りテストするので、本番システムに触れるアカウントは渡さず、非本番環境の代表的な権限のアカウントを使うことが推奨されています。
When AWS Security Agent signs in with your credentials, it tests everything your application exposes to that signed-in user. ... Only provide credentials for applications you are authorized to test.
認証情報やステップを登録した後は、「Save and test」を押すと認証情報のテストが始まります。
ダイアログが表示されてテストログを表示しながら調査の状況がわかるようです。が、私は今回次のようにテストログが確認できませんでした。前のステップで CloudWatch Logs の設定をしていなかったからもしれない...まぁ今回は後続のネットワークスコープ提案はうまくいったのでこのまま行ってみます。
元の Credentials 画面でもテスト状況は確認できます。
Status 列が Starting → In progress と進み、テスト結果は Success・Failed・Timed out のいずれかになります（未テストや編集後は Unverified と表示されます）。
ログインを時間内に完了できないと 15 分でタイムアウトするようです。今回のログインテストはだいたい 2〜3 分で終わりました。
認証情報のテスト中に別のステップに移っても、テストは裏で続きます。
Failed のときは Status をクリックすると理由を確認できるようです。
ユーザー名やパスワードの誤り、あるいはログインプロンプトの手順が実際のログイン画面と合っていない、といったところを見直して、認証情報を編集してまたテストする感じ。
以前は認証が通るかどうかはテストを最後まで実行しないと分からず、ペネトレーションテストの task-hour（テスト中のエージェント稼働時間）を消費しきってようやく気づくというかなりつらい状況だったのですが、今回のアップデートによって認証情報の不備でテスト時間を無駄にせずに済むのはとても良いですね。
到達したドメインがスコープ候補に出てくる
認証情報のテストが終わったら Network configuration ステップに進みます。
ここでは次のように認証情報テスト中に到達したドメインが Suggested として一覧に並んでいました。
ドキュメントや画面情報によると、各ドメインは 3 つのうちどれかに分類されるようです。
- Target … テストで攻撃してよい URL。Penetration test details で入れた URL が該当
- Accessible … アクセスはするが攻撃はしない URL。ホスト型のログインページや CDN などが該当
- Out of scope … 一切アクセスさせない URL
検証アプリではログイン後に api.tak1wa.com と assets.tak1wa.com へ到達するので、この 2 つが候補として出てきました。期待どおりですね。
今回はどちらも最初から Accessible にトグルが入った状態で表示されました。
CSS/JS を配信する assets.tak1wa.com も API の api.tak1wa.com もテスト対象ではないアプリとして解釈されていますが、そこはテスト対象をどうしたいかによって再調整が必要な場合もあります。
候補として出てきたドメインを見て分類するだけなので、ログイン後にアプリがどこへ到達するのかを事前に自分で洗い出す手間はかなり減りますね。
テストが到達しないドメインは、これまで通り「Add domain」で自分で追加する必要があります。
さいごに
本日は AWS Continuum for penetration testing に追加された、認証情報のテストと到達ドメインの提案を確認してみました。
認証情報の不備でテスト 1 回分を無駄にせず、ログイン後の到達先も手動で洗い出さずに済むので、認証付きアプリのスコープ設定がだいぶ楽になりそうです。
認証が必要なアプリを対象にしている方は、ぜひこの機能活用してみてください。
