用 Bedrock Agent 编排云安全修复

严重的云安全暴露问题不断积压，速度远超安全团队的修复能力。云原生应用保护平台（CNAPP）、云服务商和安全态势扫描工具产生的发现项，多到任何团队都无法逐一完成分诊，而风险就在发现问题与修复问题之间的空档中不断累积。大多数发现项一直无人处理，并不是因为它们难以修复，而是因为需要有人调查上下文、确定负责人、确认修复不会影响生产环境，然后以超过现有人力承载能力的规模完成这些工作。

本文将介绍 Tamnoon 如何基于 Amazon Bedrock 构建具备智能体能力的云修复编排器 Tami，以弥合这一缺口。Tami 会自主调查从 CNAPP 和云原生来源接入的发现项，并评估修复是否安全。随后，它会生成并编排修复操作，只要变更涉及客户的云环境，就会施加护栏和治理控制。这种方法在 90 天内将严重的云安全暴露问题减少了 90% 以上，且未引发任何生产环境问题。

Tamnoon 是一个由 AI 驱动的云安全修复平台，与 CNAPP 配合使用。其 AI 助手 Tami 帮助云安全专家调查、确定优先级，并安全地修复客户在 AWS、Azure、Google Cloud 及其他云服务商环境中的配置错误和问题。

Tamnoon 与团队已经在使用的 CNAPP 和云原生工具集成，将这些工具的发现项转化为经过验证、可安全用于生产环境的修复方案。调查、优先级排序和修复规划等大部分工作，都在对运行中的环境执行任何操作之前完成，这正是大规模自动化修复值得信赖的原因。

云安全修复面临的挑战

安全工程师可能需要花费数小时调查单个发现项。而它往往与其他数十条告警有着相同的根本原因。

告警数量超出人力承载能力：CNAPP 和扫描工具会产生数千个发现项。团队无法对所有发现项完成分诊，因此严重的安全暴露问题迟迟得不到解决，风险在数月间不断累积。

调查工作依赖人工且重复性高：每个发现项都需要收集上下文，包括资源由谁负责、哪些资源或服务依赖它，以及修复是否安全。这会耗费资深工程师数小时的时间，而且积压队列中的每一项都要重复这一过程。

担心影响生产环境，阻碍自动化：团队对自动修复犹豫不决，因为他们不能冒生产环境停机的风险。如果无法确信修复是安全的，工作就无法推进。

优先级排序被动：如果无法将相关发现项聚类，或评估修复置信度，团队就只能按顺序逐条处理告警，而无法优先解决那些能一次消除多个问题的根本原因。

Tamnoon 的解决方案覆盖从发现项接入到修复验证的完整流程。平台将这些挑战视为相互关联的问题，而不是彼此孤立的问题。

Tamnoon 帮助你完成从最初发现问题到执行修复的全过程。平台从 CNAPP、云安全态势管理（CSPM）服务商和其他安全工具接入发现项，并将其规范化为统一的数据结构。随后，平台为这些发现项补充资产和安全暴露上下文，并确定优先级。接下来，智能体层通过一组专门的 AI 智能体接手处理。每个智能体都运行在 AWS 上的事件驱动无服务器架构中，因此各个阶段都能独立扩展，并在发生故障时保持安全。

基于 Amazon Bedrock 的智能体架构

平台将工作委派给四个专门的智能体，每个智能体负责修复流程中的一个独立阶段：

调查智能体利用基于数百万个真实客户云环境的训练来确定上下文，并通过以大语言模型（LLM）作为评判者的验证层筛查这些上下文。它围绕修复目标、操作范围以及各云服务商特有的验证要求进行推理，生成只读调查步骤和完整的调查计划。

安全评分智能体为每项资产构建证据链，将自动验证结果与分析人员的调查结果结合起来。它以刻意保守的判断倾向，将每个发现项的修复操作分类为 SAFE、RISKY 或 AWAITING DATA。只要存在疑虑，就会降低安全评级。

修复智能体只会针对安全智能体判定为安全的发现项启动。它会推理操作顺序、依赖关系和执行条件，然后生成修复计划。计划中的每一步都遵循备份、修复和验证的结构，并包含回滚指导。

代码生成智能体将计划步骤转化为可执行的修复操作，但前提是先通过输入护栏对相关性和提示注入的检查。每个生成产物都会经过自动化的生成与审查循环，其中必须由独立的审查智能体批准输出。

当 Tamnoon 团队着手构建 Tami 时，基础模型（FM）平台的选择将决定后续工作的整体方向。Tamnoon 的修复智能体并不都执行同一种工作。有些需要进行深入的调查推理，以理解安全发现项的根本原因；有些负责大批量验证，快速、低成本地检查提出的修复方案；还有一些负责审查生成的代码，在每项任务中权衡质量与成本。为每类工作匹配合适的模型，同时避免为每个模型分别拼接一套集成，是一项核心要求。

正是这一要求，让 Amazon Bedrock 成为顺理成章的选择。通过单一 API，每个智能体都可以调用最适合其任务的基础模型。能力最强的模型处理最困难的推理任务，效率更高的模型承担重复性强、吞吐量高的工作，侧重审查的模型则优化输出质量与成本之间的权衡。由于只需要一套集成，随着模型生态的发展，团队可以替换或升级模型，而无须每次都重新改造架构的底层连接。

规模扩大后的运维开销，是决策中的另一个因素。随着请求量增长，Tamnoon 希望避免自行构建和维护将流量分配到各区域可用容量的逻辑。Amazon Bedrock 跨区域推理会自动处理这一过程。它会在指定的地理边界内，将推理请求自动路由到最合适的 AWS 区域，在维持吞吐量的同时，无须编写任何自定义路由代码。

最后一个考虑因素是安全性，而对于一家云安全公司来说，这是不可妥协的要求。使用 Bedrock 时，推理在 Tamnoon 自己的 AWS 环境中运行，权限范围由 AWS Identity and Access Management（IAM）限定。敏感客户数据始终不会离开信任边界。这让团队确信，支撑 Tami 的平台符合 Tamnoon 对自身服务所要求的同等标准。

Tamnoon 如何与 CNAPP 和云安全工具集成

Tamnoon 位于安全团队现有检测工具的下游。Wiz、CrowdStrike、Palo Alto Cortex、Upwind、SentinelOne、Orca 和 Cyera 等 CNAPP，以及 AWS Security Hub 和 Amazon GuardDuty 等云原生服务，是判断环境中存在哪些问题的权威来源。Tamnoon 通过基于 API 的集成连接这些工具，并将发现项规范化为通用格式，因此无论配置错误来自 Wiz 还是 GuardDuty，都会以相同的形式呈现。检测工具仍然是基础，Tamnoon 则提供后续的端到端修复。

对于处理的每个发现项，Tami 都会赋予一个修复置信度指标（Remediation Confidence Indicator，RCI），取值为 SAFE、RISKY 或 AWAITING DATA。这个评级告诉团队哪些操作可以自动执行，哪些需要先由人工审查。

图 1：Tamnoon 的实际运行情况

Tamnoon 的 AWS 架构

Tamnoon 完全运行在自己的 AWS 账户内，各环境相互隔离。用户通过基于 Amazon API Gateway 构建的单一安全入口访问平台，由 AWS Certificate Manager 管理加密，Amazon Cognito 负责登录。该入口后面的所有组件都运行在跨多个可用区的私有网络中，因此核心平台始终不会直接暴露在互联网上。

在这个环境中，Tamnoon 结合了两类计算资源。Amazon Elastic Kubernetes Service（Amazon EKS）运行支撑仪表板的常驻服务，AWS Lambda 则负责收集发现项、分析发现项和执行修复等事件驱动工作。Amazon EventBridge、Amazon Simple Queue Service（Amazon SQS）和 AWS Step Functions 等一组 AWS 消息传递与工作流服务负责协调这些步骤，使大量发现项能够可靠地并行处理，且不会因某一条异常记录而阻塞其余处理。

AI 层运行在 Amazon Bedrock 上。Amazon Bedrock AgentCore 是一个支持使用任意框架或模型大规模构建、连接和优化智能体的平台，它为 Tamnoon 的智能体提供了受治理约束的行动方式，而不是不受限制的访问权限。随后，Amazon Bedrock Guardrails 会在流程继续推进之前，审查请求和生成的代码。配套服务负责平台的其余部分：托管数据库和缓存用于保存状态，Amazon Simple Storage Service（Amazon S3）用于存储操作手册和产物，AWS Secrets Manager 用于管理凭证，确保敏感密钥始终不会出现在应用代码中。

在客户侧，AWS Cloud 边界左侧的所有内容，都是客户接入 Tamnoon 的资源和系统。客户可以关联自己的 AWS、Azure 和 Google Cloud 账户，接入产生安全发现的安全工具，并连接希望接收处理结果的目标系统，例如 Slack、Jira、ServiceNow 和 GitHub。

图 2：Tamnoon 的 AWS 架构

Tamnoon 如何保持生产环境零事故

对于 Tamnoon 的客户而言，生产环境零事故已经成为现实，而这绝非偶然。Tamnoon 的自主能力建立在纵深防御的安全架构之中，每一层都假定前一层可能有所遗漏。

这一机制在起草任何修复方案之前就已启动。只有独立的安全评估认定变更可以安全实施后，系统才会编写修复方案。该评估重点关注变更范围，并有意采取审慎立场。此后，平台会严格划分读取与写入操作。调查步骤会经过验证，确保其严格只读，因此理解问题的过程绝不会改变环境。只有修复流程被允许执行变更，而且每项变更都附带各自的备份、验证和回滚步骤。

持续的自我审查进一步强化了这种严谨性。每个生成步骤都配有一个反思步骤，用于检查输出，并将审查意见反馈到重新生成过程，因此系统会持续审查自己的工作，而不会直接信任生成结果。这些建议也始终以实际情况为依据。智能体输出会结合自动化执行结果、用户反馈，以及来自真实已修复告警的训练数据进行验证；当模型无法自行得出准确结果时，就会引入人工参与。

最后一道保障位于执行时刻。AI 从不持有云凭证。执行操作通过短期有效、限定租户范围的凭证代理完成，其信任关系由客户控制，并在隔离环境中运行，与负责规划工作的智能体分离。贯穿所有这些环节的是人工治理：修复操作必须经过审批流程，并保留完整的审计记录；每项 AI 能力在交付客户之前，都必须先在内部得到验证。

数据安全与合规

Tami 会基于敏感的客户数据进行推理，包括告警载荷、资源标识符、错误配置和修复上下文。这些数据必须始终留在 AWS 信任边界内，以最小权限处理，并保持可审计性。统一采用 Amazon Bedrock，使这些要求得以实现。

敏感内容始终留在 AWS 内部

每个 Tami 工作负载都通过 ChatBedrockConverse 接口调用 Amazon Bedrock 上的 Anthropic Claude，而不是调用第三方 LLM 端点。仅这一项选择，就将整个 AI 供应链纳入一个 AWS 原生服务之下，并切实影响了客户数据的处理方式。推理完全在 Tamnoon 自己的 AWS 账户内、美国商业区域中运行，因此数据始终不会离开 AWS。有关各区域模型可用性的信息，请参阅《Amazon Bedrock 各 AWS 区域支持的模型》。由于 Bedrock 不保留提示词或模型生成结果，也不使用它们进行训练，客户数据从一开始就不会流向外部供应商。

即使工作负载规模扩大，这一边界也依然有效。Bedrock 跨区域推理会自动将请求路由到美国地理边界内的区域，从而提高应用可用的吞吐量。其背后的计算环境也保持私有。每个服务都以 AWS Lambda 函数的形式运行，连接到虚拟私有云（VPC），部署在私有子网中，配置明确的安全组，不开放公网入站访问，并严格控制出站访问。

对进入模型的内容实施防护

载荷可能包含敏感信息，因此 Tami 会对每个请求和响应应用 Amazon Bedrock Guardrails。策略在 Bedrock 层执行，这意味着它统一覆盖全部三个服务，任何单个函数的提示词逻辑都无法绕过它。这个统一的策略执行点同时承担多项职责。

首先，它保护敏感数据。个人身份信息（PII）和疑似密钥的内容在被持久化存储或展示之前就会被掩码处理，因此敏感信息不会残留在不该出现的位置。它还防范提示词注入，这一点尤为关键，因为 Tami 会基于不可信的安全发现进行推理，而未经授权的用户可能影响这些发现的内容。在护栏层进行过滤，可以阻止恶意构造的载荷劫持模型或窃取上下文。最后，禁止话题和内容过滤器将模型输出严格限定在安全修复范围内。每次护栏干预都会被记录，并与 AWS CloudTrail 日志一同为企业客户提供清晰的治理证据链。

最小权限访问

整个平台的访问都通过各服务专属的 IAM 执行角色进行，因此每个函数只能访问其所需资源，不会获得额外权限。Tami 对 Amazon Bedrock 的访问最能体现这一原则。它唯一的 Bedrock 权限是 bedrock:InvokeModel，且仅限于指定的推理配置文件和基础模型 ARN。它没有管理、训练或导出模型的能力。

同样的原则也适用于其他所有依赖项。对 AWS Secrets Manager 的访问仅限于函数实际使用的两个密钥，SQS 访问仅限于函数自己的输入队列，对 Amazon CloudWatch 的写入则按命名空间限制。整个设计中不存在权限宽泛、包揽一切的角色。函数仅附加 AWSLambdaBasicExecutionRole 和 AWSLambdaVPCAccessExecutionRole 这两项托管策略，不会附加权限范围更广的策略。

多租户隔离与治理

租户隔离是一项基础要求，从第一次调用开始就得到强制执行。服务间调用通过 Cognito 使用 OAuth2 客户端凭证，权限范围按应用划分；每次只处理一条 SQS 消息，并附带其租户上下文。因此，单次调用始终只会接触一个租户的数据。

这类保障很大程度上来自将整个平台作为代码管理。IAM 策略、网络部署位置、模型 ID 和告警配置都保存在受版本控制的 AWS CloudFormation 和 SAM 模板中，因此每项权限和每个模型版本都可以在源代码管理系统中接受审查，也不会因手动修改控制台配置而产生配置漂移。尤其是模型版本，会固定到带日期的标识符，例如 claude-sonnet-4-5-20250929。这意味着模型变更始终是一次明确且经过审查的代码变更，而不是悄然发生的升级。

这种透明性也贯穿运行阶段。每次推理调用都会记录到 AWS CloudTrail，并可追溯到发起调用的角色；将 temperature 设为零的确定性解码，则确保不同运行之间的评分和规划保持一致。故障处理也受到同样严格的治理。每个服务都配有支持重新投递的输入队列、错误处理函数、死信队列，以及监控超时和死信队列（DLQ）消息积压数量的 CloudWatch 告警，并将这些告警接入值班响应机制。故障会被限制在可控范围内，并且可观测，绝不会被悄无声息地丢弃。

Tami 已分析 Tamnoon 客户环境中的超过 1,400 万条云告警，这一数字记录在 Tamnoon 的《2026 年云修复现状》报告中。Tami 做出的决策体现了从这些真实环境中学到的规律。

对于典型客户，成效通常很快就会显现，一般在 90 天内。

有关压缩幅度和零事故的数字来自 Tamnoon 的研究。呈现出的趋势是一致的：尚未消除的安全暴露更少、人工工作量大幅下降，而且修复操作本身不会造成停机。

构建一个能够对云安全发现进行推理的智能体，相对容易。构建一个值得信赖、能够在生产环境中采取行动的智能体，才是难点。Amazon Bedrock 是一项全托管服务，通过单一 API 提供高性能基础模型的访问能力，以及构建智能体应用所需的工具，包括编排、工具使用和护栏。这种组合在这里尤为关键，原因很明确：对生产环境的云基础设施执行操作，既需要强大的推理能力，也需要严格的安全边界。

以下四点让这一切成为可能：

• 安全暴露得到切实消除： Tamnoon 直接操作运行中的云基础设施，而不只是处理工单或自动化工作流。积压问题会真正减少，而不是被转移到其他地方。
• 自主能力可以扩展，同时不引入生产风险： 每项拟议操作都附带置信度评级。SAFE 操作可以自动执行，而 AWAITING DATA 或 RISKY 操作则会引入 Tamnoon 团队中参与服务的云工程师。

基于你已采购的技术栈运行：Tamnoon 可在主流 CNAPP 和云安全工具之上运行。你已经付费购买的每一款检测工具都开始发挥价值，因为它们发现的安全问题终于得到了解决。

无需扩充团队，即可提升处理能力：快速、安全地采用前沿 AI，让每位分析师能够解决更多安全暴露问题，无需增加人员。

要开始构建类似的架构，可以考虑以下步骤：

了解 Amazon Bedrock 及其提供的模型。

查阅 Amazon Bedrock 文档，规划你的架构。

预约 Tamnoon 演示，了解你在未来 90 天内能够解决多少关键云安全暴露问题。