

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AWS セキュリティエージェントと AI によるペネトレーションテストのセキュリティ上の考慮事項
<a name="security-guidance"></a>

AWS セキュリティエージェントは、すべての環境の開発ライフサイクルを通じてアプリケーションをプロアクティブに保護するフロンティアエージェントです。要件に合わせてカスタマイズされた自動セキュリティレビューを実施し、セキュリティチームがレビュー中に自動的に検証される標準を一元的に定義します。セキュリティエージェントは、アプリケーションに合わせてカスタマイズされたオンデマンドのペネトレーションテストを実行し、検証済みのセキュリティリスクを検出して報告します。このアプローチは、包括的なセキュリティカバレッジを提供しながら、開発速度に合わせてアプリケーション全体にセキュリティの専門知識を拡張します。セキュリティを設計からデプロイまで統合することで、脆弱性を早期かつ大規模に防止できます。

セキュリティチームは、承認された認可ライブラリ、ログ記録標準、データアクセスポリシーという組織のセキュリティ要件を AWS コンソールで一度定義します。AWS セキュリティエージェントは、開発中にこれらのセキュリティ要件を自動的に適用し、アーキテクチャドキュメントとコードを標準に照らして評価し、違反を検出したときに特定のガイダンスを提供します。これにより、チーム間で一貫したセキュリティ適用が提供され、開発速度に合わせてレビューがスケーリングされます。

デプロイの検証のために、AWS セキュリティエージェントは侵入テストを定期的にボトルネックからオンデマンド機能に変換します。セキュリティチームは、ターゲット URLs、認証の詳細、ソースコード、ドキュメントを提供します。AWS セキュリティエージェントは、アプリケーションの深い理解を深め、高度な攻撃チェーンを実行して脆弱性を検出および検証し、チームが必要に応じてテストできるようにします。

## 主な機能
<a name="_key_capabilities"></a>

AWS セキュリティエージェントは、開発ライフサイクル全体にわたる包括的なセキュリティ機能を提供します。

## セキュリティレビューの設計
<a name="_design_security_review"></a>

AWS セキュリティエージェントは、設計ドキュメントに関するオンデマンドのセキュリティフィードバックを提供し、コードが記述される前に組織のセキュリティ要件への準拠を評価します。セキュリティチームは、ウェブアプリケーションを介して設計ドキュメントをアップロードします。このアプリケーションでは、エージェントはセキュリティ要件と照らし合わせてそれらを分析し、修復ガイダンスを使用して検出結果を表示します。これにより、数時間にわたる手動レビューが集中分析に迅速化され、修復が最も効率的である場合にチームがセキュリティ上の懸念に対処できるようになります。

## コードセキュリティレビュー
<a name="_code_security_review"></a>

AWS セキュリティエージェントは、プルリクエストまたはアップロードされたコードを分析して、組織のセキュリティ要件や、入力検証の欠落や SQL インジェクションリスクなどの一般的なセキュリティ上の問題がないかを確認します。エージェントは、コードリポジトリプラットフォーム内で直接修復ガイダンスを提供します。セキュリティチームは、重要な問題の監視を維持しながら、モニタリングするリポジトリを設定し、すべてのコードベースで評価をスケーリングします。

## オンデマンドのペネトレーションテスト
<a name="_on_demand_penetration_testing"></a>

AWS セキュリティエージェントは、カスタマイズされた複数ステップの攻撃シナリオを通じて検証されたセキュリティの脆弱性を検出してレポートするオンデマンドの侵入テストを提供します。AWS セキュリティエージェントは、提供されたドキュメントと認証情報からアプリケーションコンテキストを開発する特殊な AI エージェントをデプロイし、高度な攻撃チェーンを実行して、従来のツールが見逃す複雑な脆弱性を特定します。影響分析、再現可能な攻撃パス、ready-to-implementコード修正を含む検出結果を文書化し、ペネトレーションテストを数週間から数時間に高速化し、アプリケーションポートフォリオ全体で検証をスケーリングします。

## よくある質問
<a name="_faqs"></a>

### セキュリティとコントロール
<a name="_security_control"></a>

#### AWS セキュリティエージェントは、システムへのアクセスをどのように認証および維持しますか?
<a name="_how_does_aws_security_agent_authenticate_and_maintain_access_to_systems"></a>

ペネトレーションテストは、実行時にユーザーのシステムに認証できる AWS セキュリティエージェントの唯一の機能です。AWS セキュリティエージェントは、ペンテストを開始する前に、静的なユーザー名とパスワード認証情報 (Secrets Manager に保存) または認証情報ベンダー (Lambda 関数として) の形式の認証情報を構成として受け入れます。これらの認証情報は、ペンテストのライフサイクルを通じてユーザーのシステム/アプリケーションの通常の機能を実行するために使用されます。ペンテストの目的で、適切な範囲のアクセス許可を持つ新しい認証情報を作成することをお勧めします。

#### ユーザーは、意図しないシステムへの影響を防ぐためにテストの範囲と深さを制御できますか?
<a name="_can_users_control_the_scope_and_depth_of_testing_to_prevent_unintended_system_impacts"></a>

AWS セキュリティエージェントを使用すると、お客様はエンドポイントで調査する脆弱性の特定のカテゴリを選択できます。ユーザーはout-of-scopeURLs を指定して、AWS セキュリティエージェントがそれらのターゲットに対して侵入テストを実行できないようにすることができます。https://docs.aws.amazon.com/securityagent/latest/userguide/perform-penetration-test.html

#### AWS セキュリティエージェント自体がセキュリティリスクをもたらす可能性がありますか?
<a name="_can_aws_security_agent_itself_pose_a_security_risk"></a>

AWS セキュリティエージェントは、セキュリティリスクを検出するように指示されますが、意図的に影響を最小限に抑えたペイロード (SQL インジェクション攻撃が検出されたときにテーブルを削除するのではなく、SQL バージョンを抽出するなど) を使用するように指示されます。AWS セキュリティエージェントは、ターゲットアプリケーションに対して過剰な負荷を発生させるなどのリスクのある動作を防ぐために、決定的なガードレールに制限されています。ガードレールが導入されている間は、意図しないビジネスロジックインタラクションや明白でないビジネスロジックインタラクションが発生する可能性があるため、本番稼働前の環境に対して侵入テストを行うことを常にお勧めします。

#### AWS セキュリティエージェントはどのようなデータを収集し、どこに保存しますか?
<a name="_what_data_does_aws_security_agent_collect_and_where_is_it_stored"></a>

AWS セキュリティエージェントを使用すると、ユーザーはアーティファクトをアップロードして、テスト対象のアプリケーションに関するコンテキストを提供できます。データ保護の詳細については、「」を参照してください[AWS セキュリティエージェントのデータ保護](data-protection.md)。AWS セキュリティエージェントは、推論リクエストを処理するために、地理的に最適なリージョンを自動的に選択します。これにより、利用可能なコンピューティングリソース、モデルの可用性を最大化し、最高のカスタマーエクスペリエンスを実現します。データはリクエストが発生したリージョンにのみ保存されますが、入力プロンプトと出力結果はそのリージョン外で処理される場合があります。すべてのデータは Amazon の安全なネットワーク経由で暗号化されて送信されます。詳細については、[「クロスリージョン推論](https://docs.aws.amazon.com/securityagent/latest/userguide/security-best-practices.html#_cross_region_inference)」を参照してください。

#### エンドポイントに対する不正なテストをブロックするには、どのようなコントロールがありますか?
<a name="_what_controls_are_present_to_block_unauthorized_testing_against_an_endpoint"></a>

ペンテストのターゲット URLsとして指定されたエンドポイントには、所有権の尺度として DNS 検証または HTTP 検証が必要です。AWS セキュリティエージェントは、エンドポイントの DNS に TXT レコードを追加するか、所有権の証明として HTTP Route 戻り検証文字列を公開するようにお客様に求めます。所有権の証明を証明した後でのみ、ユーザーはペンテストに進むことができます。ターゲット外の URLs およびアクセス可能な URLsへのリクエストは、ネットワークによってブロックされます。

お客様は、侵入テスト活動の影響を受ける可能性のあるすべてのシステムをテストするための適切な認可があることを確認する責任があります。AWS セキュリティエージェントのすべての使用は、AWS 適正使用ポリシー (https://aws.amazon.com/aup/) に準拠する必要があります。

#### AWS セキュリティエージェントを使用して不正使用をブロックして報告するにはどうすればよいですか?
<a name="_how_do_users_block_and_report_any_abuse_using_aws_security_agent"></a>

AWS セキュリティエージェントは、リクエストを継続的にモニタリングし、ターゲット URLsの外部にある URLs。AWS セキュリティエージェントを使用してサードパーティーエンドポイントで不正なテストを実行しようとするなど、不正使用が検出された場合、アカウントで進行中のペストはすべて終了します。お客様は、AWS サポートまたは AWS アカウントチームに連絡してサポートを受けることができます。

#### AWS セキュリティエージェントはペンテストワークフローを置き換えることができますか?
<a name="_can_aws_security_agent_replace_pen_testing_workflow"></a>

AWS セキュリティエージェントは専門的な侵入テストサービスではなく、AWS セキュリティエージェントをセキュリティレビューワークフローに統合することをお勧めします。AWS セキュリティエージェントは、ペンテストの専門家とやり取りするのが時期尚早、非実用的、または頻繁に再評価する必要がある場合に、ソフトウェアライフサイクルの開発段階で、ペネトレーションテストへのアクセシビリティをオンデマンドで提供できます。セキュリティプロフェッショナルは、AWS セキュリティエージェントからの検出結果を確認して、検証、説明、新しい新しい検出結果の拡張を行うことができます (存在する場合）。

#### ユーザーは、異なるチームメンバーにロールベースのアクセスコントロール (RBAC) を設定できますか?
<a name="_can_users_set_up_role_based_access_control_rbac_for_different_team_members"></a>

はい。AWS Security Agent は AWS IAM Identity Center と統合されているため、管理者は AWS Security Agent ウェブアプリケーションにアクセスできるチームメンバーを管理できます。これにより、ユーザーは設計レビューとペンテストを作成、管理、表示できます。

### 機能のテスト
<a name="_testing_capabilities"></a>

#### AWS Security Agent はどのような種類の脆弱性を検出できますか?
<a name="_what_types_of_vulnerabilities_can_aws_security_agent_detect"></a>

AWS セキュリティエージェントは、ウェブアプリケーションの OWASP トップ 10 の脆弱性を検出します。AWS セキュリティエージェントは、以下に概説するテストに含めたり除外したりできる特定のリスクタイプを提供します。検出結果は、これらのリスクカテゴリ内、またはこれらのリスクカテゴリの組み合わせからのリードに従うことで検出された新しい検出結果から発生する可能性があります。
+  [任意のファイルのアップロード](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) 
  + 任意ファイルアップロードは、アプリケーションとユーザーの安全を維持するために、アプリケーションが偽ファイルや悪意のあるファイルを回避できることを確認します。
+  [コードインジェクション](https://owasp.org/www-community/attacks/Code_Injection) 
  + Code Injection は、アプリケーションによって解釈/実行されるコードの挿入で構成される攻撃タイプの一般的な用語です。
+  [コマンドインジェクション](https://owasp.org/www-community/attacks/Command_Injection) 
  + コマンドインジェクションは、脆弱なアプリケーションを介してホストオペレーティングシステムで任意のコマンドを実行することを目標とする攻撃です。
+  [クロスサイトスクリプティング](https://owasp.org/www-community/attacks/xss/) (XSS)
  + クロスサイトスクリプティング (XSS) 攻撃は、悪意のあるスクリプトが無害で信頼できるウェブサイトに挿入されるインジェクションの一種です。
+  [安全でない直接オブジェクトのリファレンス](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References) 
  + 安全でないダイレクトオブジェクトリファレンス (IDOR) は、ユーザーが指定した入力に基づいてアプリケーションがオブジェクトに直接アクセスする場合に発生します。
+  [JSON ウェブトークンの脆弱性](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/10-Testing_JSON_Web_Tokens) 
  + JWTsは、アプリケーションと基盤となるライブラリの両方で、脆弱性の一般的な原因です。
+  [ローカルファイルの包含](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_Local_File_Inclusion) 
  + ファイル包含の脆弱性により、攻撃者はファイルを含めることができ、通常はターゲットアプリケーションに実装されている「動的ファイル包含」メカニズムを悪用します。
+  [パストラバーサル](https://owasp.org/www-community/attacks/Path_Traversal) 
  + パストラバーサル攻撃 (ディレクトリトラバーサルとも呼ばれます) は、ウェブルートフォルダの外部に保存されているファイルとディレクトリへのアクセスを目的としています。
+  [特権エスカレーション](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/03-Testing_for_Privilege_Escalation) 
  + 特権エスカレーションは、ユーザーが通常許可されているよりも多くのリソースや機能にアクセスでき、そのような昇格や変更がアプリケーションで防止されるべきだった場合に発生します。
+  [サーバー側のリクエスト偽造](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery) (SSRF)
  + サーバー側のリクエスト偽造 (SSRF) は、攻撃者がサーバー上の機能を悪用して内部リソースを読み取りまたは更新する可能性がある場合に発生します。
+  [サーバー側のテンプレートインジェクション](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/07-Input_Validation_Testing/18-Testing_for_Server_Side_Template_Injection) 
  + サーバー側のテンプレート挿入の脆弱性 (SSTI) は、ユーザー入力が安全でない方法でテンプレートに埋め込まれ、サーバーでリモートコードが実行された場合に発生します。
+  [SQL インジェクション](https://owasp.org/www-community/attacks/SQL_Injection) 
  + SQL インジェクション攻撃は、クライアントからアプリケーションへの入力データを介した SQL クエリの挿入または「挿入」で構成されます。
+  [XML 外部エンティティ](https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing) 
  + XML 外部エンティティ攻撃は、XML 入力を解析するアプリケーションに対する攻撃の一種です。この攻撃は、外部エンティティへの参照を含む XML 入力が弱い設定の XML パーサーによって処理された場合に発生します。

#### AWS セキュリティエージェントはどのような認証方法をサポートしていますか?
<a name="_what_authentication_methods_does_aws_security_agent_support"></a>

AWS セキュリティエージェントは、OAuth や JWT などの一般的な認証方法をサポートしています。詳細については、[ のドキュメント](https://docs.aws.amazon.com/securityagent/latest/userguide/provide-testing-credentials.html)を参照してください。

#### AWS セキュリティエージェントはレート制限とサービス拒否 (DOS) 防止をどのように処理しますか?
<a name="_how_does_aws_security_agent_handle_rate_limiting_and_denial_of_service_dos_prevention"></a>

AWS セキュリティエージェントには、DOS を含むテスト対象のエンドポイントの中断や削除を防ぐためのガードレールがあります。予期しないトラフィックパターンを検出して処理するための内部速度制御があります。

#### AWS セキュリティエージェントは REST API と GraphQL APIs の両方をテストできますか?
<a name="_can_aws_security_agent_test_both_rest_and_graphql_apis"></a>

はい、AWS セキュリティエージェントは API エンドポイントをテストできます。AWS セキュリティエージェントがテスト対象の各 API の形状と機能をより適切に把握できるように、API ドキュメントを**追加の学習リソース**として提供することをお勧めします。

#### AWS セキュリティエージェントがすべての重要なアプリケーションロジックとエンドポイントをカバーしていることをユーザーが確認するにはどうすればよいですか?
<a name="_how_can_users_verify_that_aws_security_agent_has_covered_all_critical_application_logic_and_endpoints"></a>

AWS セキュリティエージェントは、ターゲットアプリケーション (複数可) を広範に最初に探索し、エクスプロイトを試みる前に正常に実行しようとします。これにより、実行時にアプリケーションに対する実用的な理解を構築し、重要なアプリケーションロジックとエンドポイントを検出できます。その確率的性質を考慮すると、AWS セキュリティエージェントは、ターゲットアプリケーションのすべての重要なアプリケーションとエンドポイントを検出してテストする保証はありません。AWS Security Agent ウェブアプリケーションは、検出されたすべてのエンドポイントと、侵入テストログで実行されたアクションを可視化します。

### 精度と信頼性
<a name="_accuracy_reliability"></a>

#### AWS セキュリティエージェントは、報告する前に検出結果をどのように検証しますか?
<a name="_how_does_aws_security_agent_validate_findings_before_reporting"></a>

AWS セキュリティエージェントは、決定論的な検証機能を使用して、報告された結果を検証します。決定論的検証を使用できないリスクタイプでは、AWS セキュリティエージェントは検出結果の有効性を信頼するために検出結果ステップを個別にリプレイします。AWS セキュリティエージェントは、信頼度の高い検出結果または中程度の検出結果のみをレポートし、デフォルトで未検証の検出結果を非表示にします。

#### AWS Security Agent はカスタムアプリケーションロジックに適応できますか?
<a name="_can_aws_security_agent_adapt_to_custom_application_logic"></a>

AWS セキュリティエージェントは、オプションでソースコード、脅威モデル、設計ドキュメント、API ドキュメントを**追加の学習リソース**として受け入れ、ペンテストのライフサイクルで使用されるターゲットアプリケーションのユーザー主導のコンテキストを取得します。

#### ユーザーは実行前に AWS セキュリティエージェントのテスト方法を確認できますか?
<a name="_can_users_review_aws_security_agent_testing_methodology_before_execution"></a>

現在、AWS セキュリティエージェントの一連のアクションをプレビューする方法はありません。AWS セキュリティエージェントプランは、ターゲットアプリケーションの探索に基づいて本質的に動的です。お客様は、侵入テストログを監視することで、AWS セキュリティエージェントをリアルタイムで監視できます。ログに無効または望ましくない軌跡が表示されている場合、お客様は進行中のペネテストの実行を停止できます。

### 統合とデプロイ
<a name="_integration_deployment"></a>

#### AWS セキュリティエージェントは、セキュリティツール (SIEM、脆弱性管理) または CI/CD パイプラインと統合されていますか?
<a name="_does_aws_security_agent_integrate_with_security_tools_siem_vulnerability_management_or_cicd_pipelines"></a>

AWS セキュリティエージェントは、既存のセキュリティツールや CI/CD パイプラインと統合されません。

#### AWS セキュリティエージェントは環境固有の設定をどのように処理しますか?
<a name="_how_does_aws_security_agent_handle_environment_specific_configurations"></a>

AWS セキュリティエージェントは、特定の IAM ロール、VPCs 内、お客様が指定したアプリケーション関連の認証情報、およびターゲットアプリケーションのソースコード参照として Github ソースリポジトリを使用して実行するように設定できます。

#### AWS セキュリティエージェントはエアギャップまたは隔離された環境で実行できますか?
<a name="_can_aws_security_agent_run_in_air_gapped_or_isolated_environments"></a>

 [AWS セキュリティエージェントは、アウトバウンドインターネットアクセスを持たないものを含め、VPCs への接続を持つように設定できます](connect-agent-vpc.md)。

#### 複数のチームメンバーが同時にテストを実行できますか?
<a name="_can_multiple_team_members_run_tests_simultaneously"></a>

AWS セキュリティエージェントは、テストを開始するユーザーに関係なく、アカウントごとに 5 回の同時ペテスト実行をサポートします。お客様は、最大 100 のエージェントスペースと 1,000 の Pentest プロジェクトを作成できます。

### 運用上の影響
<a name="_operational_impact"></a>

#### テストされたシステムのパフォーマンスにはどのような影響がありますか?
<a name="_whats_the_performance_impact_on_tested_systems"></a>

AWS セキュリティエージェントには、テスト対象のエンドポイントの中断や削除を防ぐためのガードレールがあります。これには、AWS セキュリティエージェントがエンドポイントに対して実行できる呼び出しの数の速度制御が含まれます。システムまたはテスト対象のエンドポイントでは、ペンテストアクティビティが原因でトラフィックが増加し、潜在的なモニタリングアラートがトリガーされることを想定する必要があります。AWS セキュリティエージェントまたはペンテストアクティビティは、本番稼働前の環境でのみ実行することをお勧めします。

#### ユーザーは AWS セキュリティエージェントをスケジュールまたはスロットリングできますか?
<a name="_can_users_schedule_or_throttle_aws_security_agent"></a>

AWS セキュリティエージェントには、パブリック APIsやペンテストの実行をスケジュールする機能はありません。また、AWS セキュリティエージェントは、ペンテスト実行の開始時にターゲットエンドポイントへのリクエストの同時実行制御を提供しません。AWS セキュリティエージェントがターゲットエンドポイントで問題を引き起こしている場合、お客様は進行中のペンテスト (複数可) を停止できます。

#### 完全なセキュリティ評価の一般的な期間はどれくらいですか?
<a name="_whats_the_typical_duration_for_a_complete_security_assessment"></a>

各ペンテストのランタイムは、ターゲットアプリケーションの幅と、評価するように設定されているリスクタイプによって異なります。ほとんどのペンテストの実行は 16 時間以内に完了します。