Tamnoon 如何用 Amazon Bedrock 构建 AI 驱动的云安全修复平台 Tami

关键的云暴露问题堆积的速度远超安全团队的修复能力。云原生应用保护平台（CNAPP）、云服务提供商和态势扫描器产生的发现数量远超任何团队的分诊能力，风险在检测与修复之间的鸿沟中不断累积。大多数发现无人处理，并非因为它们难以修复。而是需要有人调查上下文、确定负责人、确认修复不会影响生产，然后以超出人员配置的速度完成修复。

在本文中，我们分享 Tamnoon 如何在 Amazon Bedrock 上构建 Tami——一个代理式云修复编排器，来弥合这一鸿沟。Tami 自主调查从 CNAPP 和云原生来源摄入的发现，并评估修复是否安全。然后，在变更触及客户云的任何地方，它都会在护栏和治理下生成并编排修复方案。该方法在 90 天内将关键云暴露减少了超过 90%，且零生产问题。

关于 Tamnoon

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，并带有刻意保守的倾向。当存疑时，它会降级处理。
• 修复智能体仅对安全智能体判定为安全的发现启动。它会推理排序、依赖关系和条件，然后生成一份修复计划，其中每一步都遵循备份、修复和验证的结构，并包含回滚指导。
• 代码生成智能体将计划步骤转化为可执行的修复操作，但仅在输入护栏筛查相关性和提示注入之后。每个产物都要经过一个自动的生成与审查循环，其中必须由单独的审查智能体批准输出。

为什么选择 Amazon Bedrock

当 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 都会分配一个修复置信度指标（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 则驱动收集发现结果、分析它们并执行修复的事件驱动工作。一组 AWS 消息传递和工作流服务，包括 Amazon EventBridge、Amazon Simple Queue Service（Amazon SQS）和 AWS Step Functions，协调这些步骤，以便大量发现结果能够可靠且并行地处理，不会因单条坏记录而阻塞其余部分。

AI 层运行在 Amazon Bedrock 上。Amazon Bedrock AgentCore 是一个可使用任何框架或模型大规模构建、连接和优化代理的平台，它为 Tamnoon 的代理提供了一种受治理的方式来采取行动，而不是开放式访问。随后，Amazon Bedrock Guardrails 会在任何内容继续推进之前审查请求和生成的代码。支持服务处理平台其余部分：用于状态管理的托管数据库和缓存、用于 playbook 和工件的 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 的自主性位于纵深防御安全架构之内，其中每一层都假设前一层可能遗漏某些东西。

它在任何修复方案起草之前就已开始。在独立的安全评估——聚焦于范围并刻意偏向谨慎——得出结论认为该变更可以安全实施之前，不会编写任何修复方案。在此基础上，平台在读取与写入之间划定了严格界限。调查步骤被验证为严格只读，因此理解问题的工作永远不会改变问题本身。只有修复路径被允许更改任何内容，而它所做的每一项更改都带有自己的备份、验证和回滚步骤。

这种纪律通过持续的自我批判得到强化。每个生成步骤都配有一个反思步骤，检查输出并将其批判反馈到重新生成中，因此系统始终在审查自己的工作，而不是直接信任它。这些建议也始终扎根于现实。Agent 输出会根据自动化结果、用户反馈以及来自真实已修复告警的训练数据进行验证，当模型无法自行得出准确结果时，会引入人工介入。

最终的保障在于执行时刻。AI 从不持有云凭证。相反，执行通过短期、租户范围的凭证在客户控制的信任下进行代理，运行在与规划工作的 Agent 相隔离的隔离环境中。包裹这一切的是人工治理：修复通过带有完整审计追踪的审批工作流进行，每一项 AI 能力在到达客户之前都会在内部得到验证。

数据安全与合规

Tami 需要推理敏感客户数据：告警负载、资源标识符、错误配置以及修复上下文。这些数据必须留在 AWS 信任边界内，以最小权限运行，并保持可审计。标准化采用 Amazon Bedrock 使这一切成为可能。

敏感内容留在 AWS 内部

每个 Tami 工作负载都通过 ChatBedrockConverse 接口调用 Amazon Bedrock 上的 Anthropic Claude，而不是调用第三方 LLM 端点。这一选择将整个 AI 供应链置于一个 AWS 原生服务之下，对客户数据的处理方式产生了实际影响。推理完全在 Tamnoon 自己的 AWS 账户内、在美国商业区域中运行，因此数据永远不会离开 AWS。有关各区域模型可用性的信息，请参阅 Amazon Bedrock 中按 AWS 区域支持的模型。由于 Bedrock 不会保留或基于提示或补全进行训练，客户数据从一开始就不会到达外部供应商。

即使工作负载扩展，这一边界依然保持。Bedrock 跨区域推理自动将请求路由到美国地理边界内的区域，提高应用程序可用的吞吐量。其背后的计算也保持私有。每个服务都作为附加到虚拟私有云（VPC）的 AWS Lambda 函数运行，位于带有显式安全组的私有子网中，无公共入口，出口受到严格控制。

守护到达模型的内容

负载可能携带敏感细节，因此 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，可归因到调用角色，而温度设为零的确定性解码则确保评分和规划在每次运行之间保持一致。故障处理也以同样的严谨性进行管理。每个服务都有一个带重驱动的输入队列、一个错误处理函数、一个死信队列，以及针对超时和 DLQ 深度的 CloudWatch 告警，并接入值班人员。故障被遏制且可观测，绝不会被静默丢弃。

结果与影响

Tami 已分析了 Tamnoon 客户群中超过 1400 万条云告警，这一数字记录在 Tamnoon 的 2026 年云修复状况报告 中。Tami 所做的决策反映了从这些真实环境中学习到的模式。

对于典型客户而言，结果很快就会显现，通常在 90 天内。

压缩和零问题数据来自 Tamnoon 的研究。这一模式是一致的，显示出更少的未解决暴露、远更少的手动工作，以及修复本身未造成任何停机。

结论

构建一个能够对云发现进行推理的 agent 是简单的部分。构建一个你信任其能在生产环境中采取行动的 agent 才是困难的部分。Amazon Bedrock 是一项完全托管的服务，提供对高性能基础模型的访问，以及通过单一 API 构建 agentic 应用的工具：编排、工具使用和护栏。这种组合在这里很重要，原因很具体：对生产云基础设施采取行动既需要强大的推理能力，也需要严格的安全边界。

四件事使之成为可能：

• 你的暴露真正得到关闭：Tamnoon 在实时云基础设施上运行，而不是在工单或工作流自动化上。积压减少而不是横向增长。
• 自主性可扩展且无生产风险：每个提议的操作都带有置信度评级。SAFE 操作可自动执行，而 AWAITING DATA 或 RISKY 操作则会引入 Tamnoon 的嵌入式云工程师。
• 运行在你已购买的堆栈上：Tamnoon 在流行的 CNAPP 和云安全工具之上运行。你已付费的每个检测工具都开始产生回报，因为其发现最终得到关闭。
• 团队能力可扩展而无需扩编：快速、安全地采用前沿 AI 意味着每位分析师关闭更多暴露，而无需增加人员。

后续步骤

要开始使用类似架构，请考虑以下内容：

• 探索 Amazon Bedrock 及其可用的模型。
• 查看 Amazon Bedrock 文档 以规划你的架构。
• 预约演示，与 Tamnoon 一起了解你在未来 90 天内可以关闭多少关键云暴露。

关于作者

Ishara Premadasa

Ishara 是 AWS Startups 团队的一名解决方案架构师，她帮助初创客户在 AWS 上以合适的架构构建和扩展。她专注于 AI/ML、数据智能和分析，帮助初创企业构建强大的数据基础，并将生成式 AI 解决方案投入生产。工作之余，Ishara 喜欢户外活动，热爱旅行、阅读和烘焙。

Adi Milner

Adi 是 Tamnoon 的工程主管，领导工程和产品团队构建 AI 驱动的云安全和修复解决方案。他在软件工程和技术领导方面拥有超过 20 年的经验，工作涵盖云基础设施、分布式系统、开发者平台和 agentic AI。他热衷于将 AI 应用于复杂的工程和安全问题，并构建能为客户带来可衡量价值的产品。

Maya Levine

Maya 是 Tamnoon 的产品主管兼技术产品营销主管。Maya 此前在 Sysdig 领导产品管理，在此之前曾在 Check Point Software Technologies 担任安全工程、云技术营销和网络安全布道师等职务。她经常在 AWS re:Invent 和 RSAC 等会议上演讲，热衷于构建安全团队信任其代为行动的 AI 产品。