AWS認定資格 WEB問題集＆徹底解説CloudOpsエンジニア アソシエイト（SOA）

会員登録/ログイン

1. サービス概要

AWS Security Agentは、Webアプリケーションのセキュリティを設計段階から稼働後まで検証する、生成AIベースのセキュリティエージェントです。 2025年12月にプレビューとして発表され、中核機能であるオンデマンドのペネトレーションテストが2026年3月31日に一般提供（GA）となりました。

2026年6月17日に発表されたAWS Continuumに統合され、現在は「AWS Continuum（旧AWS Security Agent）」として提供されています。 ペネトレーションテストはContinuumのペネトレーションテスト機能（GA）に、コードのセキュリティレビューはコードスキャン機能（プレビュー）に引き継がれ、設計ドキュメントにもとづく脅威モデリングもプレビューで提供されています。 SOA-C03の試験ガイドv1.1では「AWS Security Agent」の名称で、セキュリティ検出結果のレポートと修復（タスク4.2）に掲載されています。 稼働中のリソースを継続監視するGuardDuty・Inspector・Security Hubと違い、リリース前後のアプリケーションそのものを攻撃者の視点で検証する点が特徴です。

2. 主な特徴と機能

2.1 オンデマンドのペネトレーションテスト（GA）

対象アプリケーションの攻撃対象領域を洗い出し、認証、認可、インジェクションなど複数のリスク分類ごとに専門のエージェントが多段階の攻撃シナリオを実行します。 疑わしい脆弱性は実際に悪用を試みて確認し、関連する発見を攻撃経路としてつなげるため、誤検知の少ない結果が得られます。 公開エンドポイントだけでなく、VPC内のプライベートなエンドポイント、他のクラウドやオンプレミスのアプリケーションも対象にできます。

2.2 コンテキストを使った精度向上

ソースコード、OpenAPI仕様、アーキテクチャ文書、要件定義書、脅威モデルなどを与えると、アプリケーション固有の文脈を踏まえた攻撃計画を立てられます。 一般ユーザー・特権ユーザーなど複数の役割の認証情報を設定し、ログインが必要な画面やAPIも検証できます。

2.3 検出結果と修復

各検出結果には、CVSSスコア、アプリケーション固有の重大度、再現手順、ビジネスへの影響、修復のガイダンスが付きます。 GitHubと連携していれば、修正コードのプルリクエストを生成させることもできます。修正後は、該当する検出結果だけを再検証して「まだ悪用可能」か「解決済み」かを確認できます。

2.4 設計・コードのセキュリティレビュー（プレビュー）

設計ドキュメントを、組織のセキュリティ要件に照らしてレビューし、要件ごとに準拠・非準拠・情報不足などで判定します。 また、GitHubのプルリクエストを分析し、SQLインジェクションやクロスサイトスクリプティングなどの典型的な脆弱性や、自社要件への違反をコメントで指摘します。 セキュリティ要件には、業界標準にもとづくAWSマネージドの要件と、組織が独自に定義するカスタム要件があります。

3. アーキテクチャおよび技術要素

1. 管理者がコンソールでエージェントスペースを作成する。アプリケーションやプロジェクトごとに1つ作るのが推奨で、テスト範囲・設定・専用のWebアプリケーションを持つ。
2. セキュリティ要件（AWSマネージド／カスタム）を有効化し、GitHubリポジトリや設計ドキュメントを接続する。
3. ペネトレーションテストの対象ドメインについて、DNSのTXTレコードまたは検証用ファイルで所有権を確認する（ドメインごとに1回）。
4. プライベートなアプリケーションを対象にする場合は、VPCを指定してテストを実行させる。
5. アプリケーションへのログイン情報は、静的な認証情報のほか、AWS Secrets ManagerやLambdaから動的に取得させることもできる。
6. テストを実行すると、タスクの実行ログ、検出結果、レポート（PDFで出力可能）が作成され、修正後は個別に再検証する。

4. セキュリティと認証・認可

• ドメイン所有権の確認: 第三者のサイトを誤って攻撃しないよう、テスト対象ドメインの所有権確認が必須。
• Webアプリケーションへのアクセス: IAM Identity CenterによるSSO、またはアカウント内のIAMプリンシパルだけに限るIAMのみのアクセスを選べる。
• 役割分担: 管理者がコンソールでエージェントスペース・要件・テスト範囲を設定し、AppSecチームや開発者はWebアプリケーションでその範囲内のレビューやテストを実行する。
• 認証情報の保護: テスト用のログイン情報はSecrets Managerなどで管理し、権限を絞って付与する。
• データ保護: 顧客データはAWS KMSで暗号化され、モデルの学習や第三者への共有には使われない。テストのログは顧客アカウントのCloudWatchに保存される。
• 監査: API操作はCloudTrailで記録する。

5. 料金形態

料金はペネトレーションテストのタスク時間に対する従量課金です。並列に動いたタスクの時間が合算されるため、課金対象の時間はテストの経過時間より長くなるのが一般的です。

• 単価: 1タスク時間あたり50米ドル。秒単位で計測され、前払いや最低料金はない。脆弱性の種類による単価の違いはない。
• 再検証: 1件の検出結果につき最初の3回までの再検証は無料。
• 予算の上限: テストごとに最大タスク時間を設定でき、上限に達すると発見済みの結果を残して停止する。
• 無料トライアル: ペネトレーションテストの新規利用者は2か月間、月ごとの上限内で無料で試せる。
• プレビュー機能: 設計レビューやコードレビューなどプレビュー中の機能は、所定の上限内で課金されない。

6. よくあるアーキテクチャ・設計パターン

• 外部委託のボトルネック解消: 専門業者への設計レビューとペネトレーションテストの順番待ちをなくし、リリースのたびにオンデマンドでテストする。
• 既存サービスとの役割分担: GuardDutyで脅威を検知、Inspectorで既知の脆弱性（CVE）をスキャン、Security Hubで検出結果を集約・準拠状況を確認し、Security Agentでアプリケーション固有の悪用可能な脆弱性を検証する。
• シフトレフト: 設計段階で要件への準拠をレビューし、プルリクエストでコードの問題を指摘して、稼働前に問題を減らす。
• 修正と再検証のループ: 検出結果から修正のプルリクエストを作り、マージ後に該当する検出結果だけを再検証して解決を確認する。
• プライベートアプリの検証: 社内向けのアプリケーションをVPC指定でテストする。

7. 設定・デプロイ手順（ハンズオン例）

1. コンソールでセットアップを開始し、最初のエージェントスペースを作成する。Webアプリケーションのアクセス方式（IAM Identity Center／IAMのみ）を選ぶ。
2. セキュリティ要件を確認し、必要に応じて「機密データは保管時にカスタマーマネージドキーで暗号化する」などのカスタム要件を追加する。
3. GitHubリポジトリを接続し、OpenAPI仕様や設計ドキュメントを登録する。
4. テスト対象のドメインを登録し、DNSのTXTレコードで所有権を確認する。
5. テスト用アカウントの認証情報をSecrets Managerに保存して指定し、最大タスク時間を設定してテストを開始する。
6. 検出結果のCVSSスコアと再現手順を確認し、修正のプルリクエストを生成してレビュー・マージする。
7. 修正をデプロイしたら該当する検出結果を再検証し、結果をレポートとして出力する。

8. 試験で問われやすいポイント