亚马逊AWS官方博客
AWS Security Agent 渗透测试实操
摘要：AWS Security Agent 提供按需渗透测试（On-demand Penetration Testing）功能，通过 AI 智能体对运行中的 Web 应用进行多步骤攻击链测试，发现和验证安全漏洞。本文通过一个完整的实操案例，演示如何配置 AWS Security Agent、创建渗透测试并查看发现结果，覆盖整个流程的每一步操作和参数说明。
一、传统渗透测试的痛点
渗透测试的价值毋庸置疑，但传统方式存在几个现实问题：周期长（通常 2-6 周）、费用高（数万到数十万美元）、频率低（一年一两次）、覆盖面窄（仅能覆盖少数关键应用）。开发团队以周甚至天为单位迭代发布，安全测试的节奏难以匹配。
AWS Security Agent 的渗透测试功能将这一流程转变为按需操作——配置好目标 URL 和认证信息，即可启动测试，典型测试在 12 小时左右完成并输出经过验证的漏洞报告。它的定位不是替代专业渗透测试团队，而是让安全测试能够跟上开发节奏，覆盖到此前无法顾及的应用。
二、AWS Security Agent 简介
AWS Security Agent 是 AWS 推出的一类前沿智能体（Frontier Agent），能够从设计到部署的全生命周期主动保护应用安全。它提供三个核心功能：
| 功能 | 阶段 | 说明 | 状态 |
| 设计安全审查（Design Security Review） | 设计阶段 | 上传架构设计文档，根据组织安全需求评估设计方案，在编写代码之前发现架构层面的安全风险 | Preview |
| 代码安全审查（Code Security Review） | 开发阶段 | 自动分析 GitHub Pull Request 中的代码变更，检查是否违反安全需求或存在常见漏洞，直接在 PR 中提供修复指导 | Preview |
| 按需渗透测试（On-demand Penetration Testing） | 部署阶段 | 部署专业 AI 智能体对运行中的 Web 应用和 API 进行渗透测试，通过多步骤攻击链发现和验证漏洞 | GA（2026.3.31） |
三个功能覆盖了从设计到部署的完整安全验证闭环。渗透测试支持跨 AWS、本地数据中心、混合云、多云和 SaaS 环境的测试，不限于 AWS 上的应用。
渗透测试基于 OWASP Top 10 for Web Applications 标准，覆盖 SQL Injection、XSS、Command Injection、SSRF、IDOR、Privilege Escalation 等 13 种风险类型。漏洞严重程度使用 CVSS（Common Vulnerability Scoring System，通用漏洞评分系统）评估。
本文聚焦渗透测试功能，通过一个完整的实操案例，演示从搭建测试环境到拿到漏洞发现的全流程。
渗透测试的目标是运行中的 Web 应用和 API。根据域名管理方式的不同，目标域名分为以下几类：
| 域名类型 | 说明 | 验证方式 |
| Amazon Route 53 域名（同账号） | 域名在同一 AWS 账号的 Route 53 中管理 | 一键验证（自动创建 DNS 记录） |
| Custom domain | 域名在其他 DNS 提供商管理 | DNS TXT 记录 或 HTTP Route 验证 |
| VPC 私有域名 | 应用部署在 VPC 私有子网中，无公网访问 | 通过 VPC 配置接入，验证可在渗透测试启动时自动完成 |
本文的测试目标是一个 Custom domain 类型的公网 Web 应用，使用 DNS TXT 记录完成域名验证。
三、测试环境搭建
我们使用 OWASP Juice Shop 作为测试目标——这是一个故意包含大量安全漏洞的开源 Web 应用，非常适合安全测试。
测试环境部署在 AWS 上，架构为 Amazon CloudFront → Application Load Balancer → Amazon ECS Fargate（私有子网），镜像存储在 Amazon ECR 中，通过 VPC Endpoint 拉取，不需要 NAT Gateway。ALB 安全组仅允许 CloudFront 流量访问，并通过自定义 Header 做 Origin 验证，确保流量只能从 CloudFront 进入。
[图1 靶机环境架构图] |
整套环境通过 AWS CloudFormation 部署，模板和部署手册已开源：github.com/very99/juiceshop-cloudformation
四、配置 AWS Security Agent
4.1 创建 Agent Space
AWS Security Agent 的所有操作都在 Agent Space 中进行。Agent Space 是一个工作空间，代表一个需要保护的应用或项目。
在 AWS Management Console 中搜索 Security Agent，点击 Set up Security Agent：
[图2 配置Agent Spaces] |
注意，在账号中第一次配置，显示“Set up AWS Security Agent”：
[图3 Set up AWS Security Agent] |
选择User access configuration，访问方式是账号级别的一次性选择，在首次 setup 时决定，适用于所有 Agent Space：
| 访问方式 | 适用场景 | 说明 |
| AWS IAM Identity Center（SSO） | 团队使用 | 支持精细的用户权限管理，可按 Agent Space 分配访问权限 |
| IAM-only | 个人测试 | 通过管理员链接访问 Web Application，配置简单 |
⚠️ 注意：
选了 IAM-only 后无法再切换为 IAM Identity Center。如果未来可能需要 SSO，建议一开始就选 IAM Identity Center。
[图4 User access configuration] |
其他选项保持默认：
[图5 其他选项保持默认] |
点击” Set up AWS Security Agent”保存。
[图6 Agent Spaces创建完成] |
创建完成后，Agent Space 页面会显示三个功能模块。可以看到Design review和Code review还是Preview。
4.2 域名验证
渗透测试要求先验证目标域名的所有权（Domain Ownership Verification）。这是一项安全机制，确保只有域名所有者才能对其发起渗透测试。
在 Agent Space 的 Penetration test 标签页中，点击 Add domain，输入目标域名，选择验证方式：
[图7 添加对象域名] |
| 验证方式 | 操作 | 适用场景 |
| DNS TXT Record | 在 DNS 中添加一条 TXT 记录 | 任意 DNS 提供商 |
| HTTP Route | 在 Web 服务器上放置验证文件 | 有服务器文件管理权限 |
| Amazon Route 53 一键验证 | 自动创建 DNS 记录 | 域名在同账号 Route 53 管理 |
*域名在同账号 Route 53 管理时，可点击One-click verification自动配置完成验证。
[图8] |
[图9 域名验证方式] |
本文以 DNS TXT Record 为例。添加域名后，Console 会生成一条 TXT 记录(这里使用任意域名演示)：
[图10 自动生成TXT记录] |
需要在 DNS 提供商中添加两个值：
| 字段 | 来源 | 注意事项 |
| TXT 记录名（Name） | 从 Console 的 DNS Record Name / Route Path 列复制 | 以 Console 显示的为准 |
| TXT 记录值（Content） | 从 Console 的 Verification token 列复制 | 完整复制，不要遗漏字符 |
⚠️ 注意：
DNS 记录名由 AWS Security Agent 自动生成，格式可能和你预期的不同。务必从 Console 复制，不要手动拼写。
添加 DNS 记录后，回到 Console 点击 Verify。验证通过后状态变为 Verified：
[图11 验证通过] |
Target Domains添加完成。
[图12 在Agent Spaces里添加域名] |
验证domain ownership，确认状态为Verified
[图13 确认域名可被测试] |
保持“Configure resources and access – optional”默认选项。
[图14 其他选项保持默认] |
Save。Penetration testing状态为Ready
[图15 Penetration testing状态变为Ready] |
至此，在Agent Spaces里面配置Penetration test configurations完成。
五、创建渗透测试
域名验证通过后，点击 Agent Space 页面的 Start in web app ，
[图16 点击Start in web app] |
打开操作页面
[图17 操作界面] |
点击“创建渗透测试”，开始配置job。
5.1 渗透测试详细信息
[图18 定义测试范围] |
5.2 其他配置型（可选）
| 配置项 | 说明 | 建议 |
| 渗透测试名称 | 标识本次测试，最多 100 字符 | 包含日期和目标，如 JuiceShop-Pentest-20260411 |
| 目标 URL | 要测试的应用地址，必须包含 https:// 前缀，且域名已通过验证 |
从已验证域名列表中选择 |
| 排除风险类型 | 不想测试的漏洞类型（如 XXE） | 首次测试建议不排除，全量覆盖 |
| 超出范围的 URL | 不希望被测试的路径，如 /admin/delete |
排除可能造成破坏性操作的路径 |
| 可访问的 URL | Agent 需要访问但不进行安全测试的第三方域名（如 Okta 登录页） | 仅在应用依赖第三方服务时配置 |
| 自定义 HTTP 标头 | 给 Agent 出站请求添加自定义 Header | 一般不需要 |
如果目标应用部署在 VPC 私有子网中且没有公网访问入口，需要在这里配置 VPC、子网和安全组，让 AWS Security Agent 通过 ENI（弹性网络接口）接入你的 VPC。
如果目标应用通过公网可访问（如本文通过 Amazon CloudFront 暴露），跳过此步。
5.3 步骤 3：身份验证资源（可选）
给 Agent 提供登录凭证，让它能测试需要登录才能访问的功能。不配置的话，Agent 只能测试无需登录的公开页面。
| 认证方式 | 适用场景 | 说明 |
| 输入凭证 | 开发测试环境 | 直接填用户名/密码，支持 TOTP 2FA |
| AWS Secrets Manager | 生产环境 | 从 Secrets Manager 安全获取凭证 |
| AWS Lambda Function | 复杂认证系统 | 动态生成凭证，函数须在 30 秒内返回 |
| IAM Role Assumption | Amazon Cognito / IAM 认证 | 通过 assume Role 获取临时凭证 |
对于复杂的登录流程（多步骤 SSO、非标准表单），可以在 Agent login prompt 中用自然语言描述登录步骤，Agent 会按照指令操作。
[图19 可选登录后测试] |
本文实验测试公开页面。
5.4 其他学习资源（可选）
上传应用的上下文材料——源代码、API 文档（OpenAPI/Swagger）、架构图、威胁模型等。Agent 分析这些材料后能更深入地理解应用的业务逻辑，生成更有针对性的测试用例。
[图20 可添加学习材料] |
支持三种来源：上传文件、GitHub 存储库、Amazon S3 链接。
[图21 支持3种方式上传材料] |
配置完成后，点击 创建渗透测试 保存配置。
六、监控测试进度
测试启动后，页面顶部显示 4 个阶段的进度：
| 阶段 | 说明 |
| 预检（Preflight） | 初始设置和连接检查，确认目标可达 |
| 静态分析（Static analysis） | 代码和配置分析（如果提供了源代码） |
| 渗透测试（Pentests） | 运行时测试，Agent 执行多步骤攻击链 |
| 正在完成（Finalizing） | 最终验证和报告生成 |
页面有三个标签页：渗透测试运行概述（运行摘要和发现的端点）、渗透测试日志（Agent 执行的所有操作详情）、调查发现（发现的漏洞列表）。
典型运行时间：包含所有风险类型时约 12 小时。可以随时点击右上角 停止运行 终止测试。
[图22] |
[图23 测试进行中] |
七、查看测试结果
测试完成后，在调查发现标签页查看结果。
[图24] |
执行的渗透性测试操作：
[图25] |
调查发现结果：
[图26] |
每个发现包含以下信息：
| 字段 | 说明 |
| 置信度（Confidence） | Agent 对该发现的置信度：High / Medium / Low。High 表示经过确定性验证器验证 |
| 严重程度（Severity） | Critical（红）/ High（红）/ Medium（橙）/ Low（黄）/ Informational（蓝） |
| 风险类型（Risk type） | 漏洞类别，如 SQL Injection、XSS、IDOR 等 |
| 重现步骤 | 复现漏洞的技术步骤，包括 HTTP 请求/响应示例 |
⚠️ 注意：
低置信度和误报的发现默认隐藏。可以通过关闭 Hide False Positives 开关查看全部发现。
7.1 发现详情
点击SQL Injection Authentication Bypass on Login Endpoint查看详情，包含漏洞描述、风险推理（CVSS 评分分解）、重现步骤和修复建议：
[图27] |
[图28] |
CVSS 评分帮助你判断漏洞的实际风险。重点关注：Attack Vector 为 Network（远程可利用）、Attack Complexity 为 Low（容易利用）、且 Confidentiality/Integrity Impact 为 High 的发现——这些是最需要优先修复的。
点击SQL Injection Authentication Bypass on Login Endpoint的日志SQL INJECTION查看详情：
[图29] |
日志任务：
[图30] |
Summary of Actions and Findings：
[图31] |
八、总结
通过这次实操，我们走完了 AWS Security Agent 渗透测试的完整流程：搭建测试环境 → 创建 Agent Space → 域名验证 → 配置并运行渗透测试 → 查看发现结果。几个实际使用中的体会：
| 方面 | 体会 |
| 上手难度 | 配置过程比较直观，4 步向导覆盖了所有配置项。域名验证的 DNS 记录名需要从 Console 复制，不要自己拼 |
| 测试时间 | 全量风险类型约 12 小时，可以通过排除不相关的风险类型缩短 |
| 结果质量 | 默认只展示高置信度和中置信度的发现，减少了误报干扰。每个发现都有可复现的攻击路径 |
| 适用场景 | 适合在开发迭代中做持续安全测试，作为专业渗透测试的补充而非替代 |
目前渗透测试功能在 6 个 AWS Region 可用：US East (N. Virginia)、US West (Oregon)、Europe (Ireland)、Europe (Frankfurt)、Asia Pacific (Sydney)、Asia Pacific (Tokyo)。
本文使用的测试环境 CloudFormation 模板已开源：github.com/very99/juiceshop-cloudformation
➡️ 下一步行动：
相关产品：
- Amazon IAM — 身份管理和访问权限
- Amazon Route 53 — 全球域名系统（DNS）
- Amazon VPC — 隔离云网络
- Amazon CloudFront — 全球内容分发网络
- Amazon CloudFormation — 基础设施即代码服务
相关文章：
- （上篇）基于 AWS Bedrock AgentCore 构建企业级航空客服智能体 —— 基于AIDLC方法从需求分析到生产部署的完整实践
- （下篇）Solutions Memory：让 AI Agent 从成功案例中持续学习 —— 双 Memory 架构实践
- 用 Kiro构建 AI：基于 AWS 基础设施快速构建企业级 Agentic AI 平台
- 从代码到分子系列：一场由 AI 驱动的 EGFR 抑制剂发现之旅 — 深度融合 AWS Bedrock与 Claude Code/Claude Agent Skills，生命健康行业的科学活动探微
- 制造业智能化转型新引擎：基于AWS Bedrock AgentCore构建生产管理智能体系统
8.1 参考链接
- What is AWS Security Agent
- Create a penetration test
- Review findings from a penetration test
- Security best practices
- GA Announcement Blog
*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。
本篇作者
AWS 架构师中心：云端创新的引领者探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用
|
 |
