侵入テストで起きやすい「始めてから分かる」問題
ペネトレーションテストでは、テストそのものの技術だけでなく、認証情報と対象範囲（スコープ）の設定精度が結果を大きく左右します。
ところが従来は、テストを実行してから次のような問題が判明することがありました。
- 登録したログイン認証情報ではアプリケーションにログインできない
- ログイン後に遷移する別ドメインがテスト対象から漏れている
- 対象URLの追加や認証情報の修正によって、テストをやり直す必要がある
- 手動でURLを洗い出すため、準備に時間がかかる
AWSは、侵入テスト向けエージェント「AWS Continuum」に、テスト開始前の認証情報検証と、ログイン時に到達可能なドメインの提案機能を追加しました。これにより、実際のテストを始める前に、認証とスコープの妥当性を確認しやすくなります。
AWS Continuumの新機能で何が変わるのか
AWS Continuumでは、ペネトレーションテストの設定時にログイン認証情報を登録できます。今回の機能では、登録した認証情報を使って、エージェントが実際のユーザーと同じようにアプリケーションへのログインを試行します。
ログイン処理の過程で到達したドメインは、テスト対象URLの候補として提示されます。利用者は、提案されたドメインを確認したうえで、スコープに含める対象を判断できます。
重要なのは、ドメイン情報が認証テストの結果にかかわらず返される点です。認証テストが成功した場合だけでなく、失敗した場合やタイムアウトした場合でも、ログイン処理中に確認された到達可能なドメインが提示されます。
これにより、少なくとも次の確認を本番のテスト実行前に行えます。
- 認証情報でアプリケーションにアクセスできるか
- ログイン処理中にどのドメインへ到達するか
- 必要なドメインがテスト対象のスコープに含まれているか
- 想定外のドメインが候補として検出されていないか
手動でスコープを設定する場合との違い
手動設定では、設計書、環境情報、ブラウザーの開発者ツール、既存のテスト記録などをもとに対象URLを整理します。しかし、現実のアプリケーションでは、ログイン後に別のサブドメインや認証基盤、APIエンドポイントへ遷移することがあります。
特に、次のような構成では対象の洗い出しが難しくなります。
- フロントエンドとAPIが異なるドメインに分かれている
- 認証サービスを別ドメインで運用している
- シングルサインオンによって複数のサービスを経由する
- リダイレクト後に管理画面やユーザー専用画面へ遷移する
- 開発環境、ステージング環境、本番環境でURL構成が異なる
AWS Continuumのドメイン提案は、こうした手動確認を置き換えるというより、実際のログインフローを起点にした補助的な発見手段として有効です。人が把握している構成と、実際のアクセス経路を突き合わせることで、スコープ設定の抜けを見つけやすくなります。
実務で期待できるメリット
テストサイクルの短縮
認証失敗をテスト完了後に知ると、原因調査、認証情報の修正、再実行という追加の工程が発生します。事前に認証情報を試せれば、テストを開始する前に設定ミスを修正できます。
スコープ漏れの早期発見
URLを手作業で列挙するだけでは、ログイン後に初めて到達するドメインを見落とす可能性があります。ログイン処理時の到達先を候補として得られるため、対象範囲を見直すきっかけになります。
DevSecOpsへの組み込みやすさ
開発やリリースのたびにアプリケーション構成が変わる環境では、過去に作成したスコープがそのまま使えるとは限りません。テスト開始前の認証・ドメイン確認を標準手順に組み込めば、設定確認を属人的な作業にしにくくなります。
テスト対象に対する説明責任の向上
どの認証情報を使い、どのドメインを対象にするのかを事前に確認できるため、開発チーム、セキュリティチーム、サービス管理者の間で認識を合わせやすくなります。
検出結果をそのまま採用してはいけない理由
ドメインが提案されたからといって、すべてを自動的にテスト対象へ追加するのは適切ではありません。検出結果は、あくまでログイン処理中に到達したドメインの候補です。対象に含めるかどうかは、所有関係やテスト許可の範囲を踏まえて人が判断する必要があります。
確認すべきポイントは次のとおりです。
- ドメインが自社または契約上テスト許可を得ている範囲に属するか
- 本番、ステージング、開発など、意図した環境のドメインか
- 外部の認証サービスやSaaSが含まれていないか
- リダイレクト先がテスト対象として許可されているか
- APIや管理画面など、対象に含めるべきエンドポイントが漏れていないか
- 提案されたドメインが一時的な遷移先や不要なリソースではないか
特に外部サービスのドメインが含まれる場合は、契約や利用規約、事前承認の有無を確認せずにテストへ含めるべきではありません。自動検出はスコープ承認の代替ではなく、確認対象を増やすための支援機能と位置付けるのが安全です。
認証情報を扱う際の実務上の注意
侵入テスト用の認証情報には、通常の開発用アカウントとは異なる管理が必要です。テスト専用アカウントを用意し、必要最小限の権限だけを付与することで、万一の誤操作や情報露出の影響を抑えられます。
運用時には、少なくとも次の事項をチーム内で決めておくとよいでしょう。
- テスト専用のユーザーと権限を用意する
- 本番データへのアクセス範囲を最小限にする
- 多要素認証やIP制限など、ログイン条件との互換性を事前に確認する
- 認証情報をチケット、チャット、ソースコードに平文で記録しない
- テスト終了後の認証情報の無効化やローテーションを計画する
- テスト結果やログに認証情報やセッション情報が残らないように管理する
今回の機能は認証情報の事前検証を可能にしますが、認証情報の保存方法、保持期間、暗号化、アクセス制御などの運用設計まで自動的に解決するものではありません。利用組織のセキュリティポリシーと、AWS Continuumの仕様に沿って管理する必要があります。
導入時に使える確認フロー
新しいアプリケーションや環境でペネトレーションテストを実行する場合は、次のような流れが実務的です。
- テストの目的、対象環境、許可されたドメインを整理する
- テスト専用の認証情報を準備し、必要な権限だけを付与する
- AWS Continuumのテスト設定に認証情報を登録する
- テスト開始前に認証テストの結果と提案されたドメインを確認する
- 提案された各ドメインの所有者、環境、テスト許可を確認する
- 不足している対象や不要な対象をスコープから見直す
- 変更内容を記録し、関係者の承認を得る
- 設定が確定してから本番のペネトレーションテストを実行する
認証テストが失敗した場合は、単に認証情報を入れ直すだけでなく、アプリケーション側のログイン仕様も確認します。たとえば、ログイン後に追加の認証操作が必要な場合や、特定のネットワーク条件が必要な場合は、認証情報そのものが正しくてもテストエージェントから利用できないことがあります。
まとめ
AWS Continuumへの今回の機能追加は、ペネトレーションテストを「実行して結果を待つ」だけの作業から、開始前に認証とスコープを検証する作業へ近づけるものです。
認証失敗やドメイン漏れを早期に発見できれば、テストのやり直しを減らし、限られたセキュリティ検証の時間を有効に使えます。一方で、提案されたドメインを無条件に採用するのではなく、テスト許可、環境、外部サービスとの関係を人が確認することが欠かせません。
DevSecOpsの運用では、事前の認証確認とスコープレビューをチェックリスト化し、アプリケーションの変更や環境追加のたびに実施することが重要です。AWS Continuumの新機能は、その確認を効率化するための実用的な一手といえます。
出典： AWS What’s New