1. 企业引入大模型的安全顾虑与 Bedrock 的定位先说一个我在和客户交流时经常遇到的场景。很多企业负责人在聊到生成式 AI 时眼神里既有期待又有犹豫。期待的是大模型带来的效率提升犹豫的则是那句反复被提起的疑问“我们的业务数据、Prompt、模型输出结果交给云厂商到底安不安全模型提供商会不会拿我们的数据去做训练内部员工权限怎么管出了问题审计能不能追溯”这些顾虑不是多虑。尤其对于金融、医疗、政企、制造业这类强监管行业数据就是生命线访问控制就是合规底线。一旦数据泄露或者权限失控损失的不只是商业机密还有监管处罚和品牌信用。所以在选型阶段安全能力往往比模型本身的“聪明程度”更先被审视。这也是我写这篇文章的出发点把手上的 Amazon Bedrock 安全实践整理清楚看看它到底凭什么敢说自己适合高数据隔离与访问控制诉求的企业以及从模型隔离到零留存策略的六层管控每一层到底管控了什么、是怎么落地实施的。如果你正在评估或已经准备用 Amazon Bedrock 构建企业级 AI 应用这篇文章能帮你建立一张完整的安全地图。我会把每一层管控的原理、配置要点、实操中的坑都讲透。我之前见过太多团队一上来就急着调 Prompt、跑模型等到安全评审的时候才发现架构里漏了关键一环再回头补成本很高。与其这样不如先把 Bedrock 的安全边界搞清楚再动手搭建应用。2. 六层管控的整体思路从网络到数据的一条安全链我不喜欢把安全能力当成一个名词列表来讲那样看着齐全实际落地的时候根本不知道先做哪个、后做哪个。我更愿意把它理解成一条“链”从请求发出到模型推理再到结果返回中间每一环节都需要有对应的控制点。Amazon Bedrock 的安全设计本质上就是在这条链上布设了六层管控。2.1 六层管控的架构全景我总结下来这六层可以这么划分第一层网络控制层。解决的是“谁能从哪个网络路径访问”的问题。第二层身份与权限层。解决的是“哪个身份能对哪个资源做什么操作”的问题。第三层模型与数据隔离层。解决的是“我的数据在模型推理过程中怎么与其他人隔开”的问题。第四层数据治理与边界层。解决的是“数据在存储和流转过程中如何被限制在指定范围”的问题。第五层审计与可观测层。解决的是“过去发生了什么事、现在正在发生什么事”的问题。第六层数据留存与合规层。解决的是“数据用完存不存、怎么存、合规要求怎么满足”的问题。注意这六层不是孤立的。比如你配置了 VPC PrivateLink但 IAM 策略里没有限制来源 VPC那末网络层就形同虚设你配置了零留存策略但审计日志里把 Prompt 明文记录了下来零留存也就不“零”了。所以一定要串起来看这也是我标题里强调“六层管控”而不是“六个独立开关”的原因。2.2 为什么 Bedrock 把安全做成“平台责任”这里有个很关键的点Bedrock 是全托管的底层基础设施、模型部署、扩缩容这些都在 AWS 的责任边界内客户不需要去维护推理服务器。但这不意味着安全就全部交给 AWS。AWS 的共享责任模型明确表明云本身的安全由 AWS 负责云里面的安全由客户负责。具体到 Bedrock你会发现 AWS 把大量安全能力做成了“可配置的开关”和“可集成的服务”但设不设、怎么设还是握在客户手里。所以你在评估 Bedrock 安全能力时不要只问“它有没有”而要问“它在默认状态下是什么样的、我要花多少成本把它调到符合自己要求的状态”。有些能力默认是开启的比如传输加密有些能力需要额外配置比如 VPC PrivateLink、KMS 客户托管密钥还有些能力甚至要在组织层面做强制策略比如通过 SCPService Control Policy限制某个地区的数据停留范围。理解了这个逻辑你才不会在项目实施时漏配置。3. 第一层到第二层网络准入与身份权限的双重把关这是整套安全体系的入口关卡也是最直观的两层。但我观察到很多团队在这里容易犯两个错误一个是把精力全投在网络上忽略身份权限的精细化另一个是反过来只做 IAM 权限但不管网络路径导致安全策略覆盖面不全。3.1 通过 VPC PrivateLink 让模型调用“私有化”先说网络层。Amazon Bedrock 支持 AWS PrivateLink也就是 VPC 终端节点。启用之后你的应用从 VPC 内网发起模型调用流量根本不会经过公共互联网而是走 AWS 的内部网络到 Bedrock 服务。这就像你小区里有一条业主专属通道不用从外面的大马路绕既快又安全。配置方式并不复杂。在 VPC 控制台创建接口类型终端节点选择服务名称为com.amazonaws.region.bedrock的终端节点服务然后关联到应用所在的子网和安全组。创建完成后你需要在 Bedrock 的 Service Role 或 IAM 策略里把调用来源限制到只接受来自这个 VPC 终端节点的请求。这里有一个非常容易踩的坑只建好了终端节点但 IAM 策略里没有加aws:SourceVpce条件的活。这种情况下相当于你虽然在小区里开了专用通道但小区的门禁没启用外面的人照样能进来。正确做法是在 IAM 策略的 Condition 块中写上aws:SourceVpce: vpce-xxxxx确保只有通过指定 VPC 终端节点的请求才被允许调用模型资源。3.2 网络 ACL 与安全组在 Bedrock 场景里的正确用法聊到网络很多人会惯性想到网络 ACL 和安全组。但在 Bedrock 这种 SaaS 化服务场景下它们的作用对象不太一样。安全组挂在你的 EC2、EKS 节点或 Lambda 上控制的是“谁能访问我的计算资源”。网络 ACL 则作用于子网层面相当于子网的“粗粒度防火墙”。在纯 Bedrock 场景你不太需要给 Bedrock 本身配网络 ACL因为服务端在 AWS 侧但你的应用所在子网以及你通过 VPC 终端节点访问 Bedrock 的那条路径是需要好好设计安全组和网络 ACL 规则的。我见过一个案例某团队把 VPC 终端节点放在了一个网络 ACL 完全放通的子网里安全组也允许了/0访问 Bedrock 端口。表面上一切正常但安全审计时被指出子网暴露面过大。后来他们把网络 ACL 收窄到仅允许应用子网 CIDR 访问终端节点子网同时安全组只放行应用安全组来源。记住一个原则即使是访问托管服务也要把网络路径当作一个“敏感通道”来管最小化源和目的地的范围。3.3 IAM 身份权限的精细化设计第二层身份与权限是 Bedrock 安全体系里颗粒度最细的一层。Bedrock 的资源模型大致包括FoundationModel基础模型、CustomModel定制模型、ProvisionedThroughput预置吞吐、Guardrail护栏、Knowledge Base知识库等。每种资源都有对应的 ARN。你要做的是通过 IAM 策略精确到“哪个用户/角色对哪个模型能执行哪个动作”。举个例子。你有一个内部 AI 助手项目允许研发团队调用 Claude 系列模型但禁止调用某些敏感场景下的定制模型同时你还有一个数据分析团队他们只能调用 Titan 模型做嵌入根本不允许碰文本生成模型。这些诉求都可以通过 IAM 策略实现——在 Action 元素里指定bedrock:InvokeModel或bedrock:InvokeModelWithResponseStream在 Resource 元素里指定具体的模型 ARN再配合 Condition 限制调用来源 VPC、调用者标签等条件。另外Bedrock 配合 IAM 的 Condition Keys 还能做更细的控制。比如aws:RequestTag要求调用时带上特定标签才能执行或者bedrock:GuardrailIdentifier强制某些模型调用必须使用护栏。这些条件键用好了权限控制的精细度会产生质的变化。我这里特别提一下如果你所在团队对“最小权限”有执念那么 Bedrock 这套条件键体系能让你把权限剪得非常精准。3.4 Service Role 与跨账户访问很多企业会采用多账户架构比如开发账户和生产账户隔离。这时候 Bedrock 应用可能需要跨账户访问模型资源或者需要在同一账户内让 Lambda 角色调用 Bedrock。推荐的做法是使用 IAM Role 而不是长期 Access Key并且通过角色信任策略限定只有特定账户、特定服务主体才能扮演这个角色。实际操作中我在生产环境一般这么设计应用侧角色附加一个策略只允许调用 Bedrock 的特定模型 ARN。模型资源侧如果有跨账户场景模型所在账户的 IAM 策略要显式允许接受来自应用账户的角色 ARN。所有角色都启用 MFA 或者用sts:SourceIdentity做二次确认防止角色被冒用。我记得有一次一个客户因为跨账户访问 Bedrock 时把 KMS 密钥的授权给漏了结果模型调用一直报AccessDeniedException。排查了半天才发现KMS Key Policy 里没有添加应用账户的 kms:Decrypt 权限而 Bedrock 在调用模型时需要用 KMS 解密相关数据。所以跨账户访问不是只配 IAM 就完事KMS 侧也必须同步授权。这正好对应了“六层”之间的联动关系。4. 第三层到第四层模型数据隔离与数据边界的纵深防护如果说前两层是“谁可以进门”那第三和第四层就是“进门之后数据在屋里怎么被隔开、怎么不被带出去”。这一部分最容易被低估因为托管的模型服务看起来就是一个 API你很难直观看到数据隔离的机制。但恰恰是这层设计决定了企业数据在模型推理过程中的安全底线。4.1 逻辑多租户下的模型隔离真相Amazon Bedrock 底层采用的是逻辑多租户架构。意思是多个客户共享同一批物理 GPU 或推理基础设施但每个客户的数据在逻辑上是隔离的。AWS 官方承诺客户输入给 Bedrock 的 Prompt 和模型返回的 Completion 不会用于模型训练或模型改进也不会计入训练集。这是零留存策略的基础承诺。但你要区分两个概念逻辑隔离与物理隔离。在默认的按需模式On-Demand下你的数据在推理过程中是和别的客户共享底层基础设施的只是通过软件层面的隔离机制保证互相不可见。如果你所在行业有物理隔离的硬性要求比如某些金融监管要求模型推理必须独占资源那就可以考虑 Provisioned Throughput也就是预置吞吐模式。在这种模式下你会独占一部分推理容量数据隔离的强度更高同时还能获得稳定的延迟表现。我参与过的几个金融客户项目最终都从 On-Demand 迁到了 Provisioned Throughput。原因就是监管审查时光有逻辑隔离还不够客户用自己的 KMS 加密、独占吞吐、配套零留存策略才能把数据安全这块的合规报告写得扎实。4.2 客户托管密钥与推理数据的加密链路加密是数据隔离的基础。Bedrock 对静态数据和传输数据都提供加密能力。默认情况下AWS 用 AWS 托管密钥对数据进行静态加密但如果你是安全敏感型企业强烈建议切换到 Customer Managed KeyCMK也就是你自己控制生命周期的 KMS 密钥。启用过程不复杂在 Bedrock 的设置页面指定一个 KMS Key ID之后所有和该账户模型相关的加密操作都会使用这把客户密钥。这里有一个实操细节一定要记住CMK 一旦启用负责调用 Bedrock 的角色必须有kms:GenerateDataKey和kms:Decrypt权限而密钥策略里也要允许对应的账户/角色使用该密钥。这两处少了任何一个都会导致模型调用直接失败。传输加密方面Bedrock 的 API 端点本身就是 TLS 加密通过 PrivateLink 走内部网络后传输链路上又少了一层公网暴露风险。所以整体的加密态势可以理解为传输中 TLS、静态数据 KMS、推理过程中的隔离三管齐下。但加密不是全部你还需要关注数据在使用过程中的边界。4.3 数据边界把数据流转范围锁进“栅栏”第四层数据治理与边界控制是我个人非常推荐每个 Bedrock 项目都花时间做的一层。AWS 提供了 Data Boundary Policy你可以在 Organization 或账户层级配置数据边界策略规定只能被允许的账号、区域和服务处理你的数据。对于 Bedrock 这种托管模型服务来说数据边界策略能确保你的模型调用不会“跑”到意想不到的账户或者区域去尤其是在多账户架构下非常有用。除了组织级数据边界你还可以通过 S3 Bucket Policy 和 KMS Key Policy 做资源级边界。比如你通过 Bedrock Knowledge Base 连接企业内部的 S3 文档库做 RAG。那这个 S3 桶应该只允许 Bedrock 服务主账号通过指定角色访问并且桶策略里加上条件只允许来自你 VPC 的请求只允许访问特定前缀的对象。这样即使 IAM 权限配置出错S3 桶策略还是会兜底拦住。我还建议把 S3 对象级 ACL 关闭掉统一走 IAM 策略管理权限。之前排查过一个数据访问权限异常的问题发现是历史项目在某个对象上单独设置了 ACL允许了某个不该允许的账户读取。这种“权限访问控制列表”和 IAM 策略混用的场景非常危险因为排错复杂度会急剧上升。Bedrock 相关的数据源我基本都建议屏蔽 S3 ACL只通过桶策略和 IAM 策略来管控访问权限。4.4 Guardrails守住输入输出的“最后防线”数据治理不仅仅是“管住数据去哪”还得“管住模型说什么”。Bedrock Guardrails 是专门干这件事的你可以给模型调用配上护栏对输入 Prompt 和输出 Completion 同时做内容过滤。Guardrails 支持敏感词过滤、PII 实体识别与脱敏、上下文相关的内容抑制等功能。举个例子你可以配置一条护栏要求模型回答时不得返回身份证号、手机号、银行卡号这类敏感信息一旦检测到就自动替换为[PII]占位符或者直接拒绝回答。这对于客服、HR、医疗等场景非常实用。更值得留意的是Guardrails 可以挂在模型调用的参数里也可以强制通过 IAM 策略绑定。如果你希望某个团队的模型请求必须带上特定护栏可以在 IAM 策略里通过bedrock:GuardrailIdentifier条件强制校验。我通常建议安全团队把这个条件加到生产环境角色上防止业务开发时图方便绕过了护栏。5. 从第五层到第六层全链路审计与零留存合规落地前四层解决了“能不能访问”“数据怎么隔离”的问题后两层解决的是“发生了什么”“用完之后怎么办”。这两个问题在真实的客户审厂和合规审计中几乎每次都会被翻来覆去追问。所以这两层做得好不好直接决定了你的安全方案能不能说服审计方。5.1 CloudTrail 与模型调用日志的审计设计Bedrock 会把所有控制面操作记录到 AWS CloudTrail包括模型的创建、删除、配置修改等。数据面操作如InvokeModel、InvokeModelWithResponseStream是否记录则取决于你是否有审计需求以及是否开启模型调用日志Model Invocation Logging。开启模型调用日志后Bedrock 会把模型调用的元数据、输入 Prompt、输出 Completion 记录到你指定的 S3 桶或 CloudWatch Logs。这里要提醒一句如果你同时开了零留存策略和模型调用日志那就产生了矛盾——零留存说的是 AWS 不保存你的 Prompt/Completion但你把它们写进了 S3 日志。所以凡是开模型调用日志的客户我会建议他们先想清楚日志里哪些字段必须保留、哪些字段需要脱敏、数据保留多久、谁有权访问日志桶。一个比较稳妥的方案是只记录元数据如调用者身份、模型 ID、时间戳、Token 消耗而不记录输入输出内容。如果业务上确实需要记录 Prompt 用于溯源那建议加上 PII 脱敏处理后再落盘并且日志桶用独立的 KMS 密钥加密访问权限限制到审计团队。5.2 CloudWatch 监控与异常行为告警除了日志可观测性还体现在指标与告警上。Bedrock 会向 CloudWatch 输出若干关键指标比如Invocations、InvocationErrors、Latency、ThrottledRequests等。你可以基于这些指标设置告警规则。从安全角度我一般会建议客户配置几个固定的告警策略某个模型在非业务时段的调用量异常突增可能意味着凭证泄露后被滥用。连续多次调用返回 AccessDenied 或 ValidationException可能有人在尝试越权访问。Token 消耗速率超过正常基线的两倍以上可能存在异常调用。这些告警别有使用门槛CloudWatch 里配置好阈值就行。但要注意告警必须要有后续响应流程不然只是“亮红灯但没人看”安全能力就打了折扣。5.3 零留存策略的实质与操作要点现在来到很多人关心的重头戏零留存策略Zero Retention。所谓零留存是指 AWS 承诺不会将你在 Bedrock 中的 Prompt 和 Completion 用于任何模型训练或模型改进也不会在模型推理完成后持续保存这些数据。需要注意的是“零留存”不是指推理过程中数据从来没有出现而是指推理完成之后不留存。数据在这个过程中必须经过模型来计算这是任何大模型服务都无法绕开的。客户可以在 Bedrock 控制台或者通过 API 开启零留存策略。开启后AWS 处理完推理请求就会把这些数据从内存和缓存中清除不会持久化。你会看到这是凹进在服务设置里的一个选项需要主动打开。AWS 文档里的措辞是当零留存策略启用后你的内容不会被存储仅用于完成你指定的推理请求。我强烈建议所有对安全敏感的客户都开启这个选项。开启本身不影响模型能力也不会引入额外可用性风险。开了以后你在写数据保护影响评估DPIA或者跟监管沟通时会轻松很多因为“数据不落盘”这个承诺可以直接写进报告里。有一点要补充清楚零留存策略管的是 AWS 侧的留存而你侧边的应用如果自己记了日志或者你在模型调用日志里保存了 Prompt/Completion那这些数据还是会在你的控制范围内留存。所以零留存不是“一键解决所有数据留存问题”它需要配合你侧的日志策略一起设计。5.4 合规认证与数据处理协议最后合规层面。Bedrock 已经通过了多项主流认证包括 SOC 1/2/3、ISO 27001、ISO 27701、HIPAA、PCI DSS 等。如果你的企业需要满足金融、医疗或政府合规要求这些认证报告可以作为评估依据。此外AWS 还提供数据处理协议Data Processing Agreement支持企业在采购时可以要求 AWS 签署 DPA明确数据处理方和处理目的。再加上 Bedrock 的合规白皮书整套材料拿给内部合规团队初筛绝大多数情况下是能通过的。不过我要提醒一下合规认证只是起点不是终点。每个企业的合规要求都有细微差别比如有的客户要求所有数据必须留在特定区域有的客户要求服务账号不能有 root 权限有的客户要求必须定期做权限复查。Bedrock 的很多安全能力只是“提供了可能性”最终怎么落地成符合自身要求的方案还是需要企业自己设计。6. 六层管控的实施顺序与常见安全问题排查讲完六层能力我想结合实施经验聊聊你在真实项目里应该怎么落地以及高频遇到的那些“访问控制异常”“权限已损坏”问题到底该怎么排查。6.1 六层管控应该按什么顺序落地我不建议一次性把六层全铺开那样容易因为配置错误导致整体不可用。更好的做法是分阶段推进。第一阶段先解决“可用性和基座安全”。开通 Bedrock 服务配置 VPC PrivateLink 和基本 IAM 权限让应用能通过私有网络调用模型。同时开启 CloudTrail确保操作有记录。第二阶段推动“数据安全纵深”。切换 KMS 客户托管密钥开启零留存策略配置 Guardrails把知识库连接的 S3 桶策略收窄到最小范围。第三阶段再做“精细化治理与监控告警”。此时业务模型调用已经稳定运行一段时间可以基于实际调用模式设计 IAM 精细化策略、数据边界策略、CloudWatch 告警阈值。这样做的好处是每个阶段的改动都有明确边界出问题容易定位。我见过一些团队上来就把 SCP、数据边界、KMS、Guardrails 一起配齐结果某次策略冲突导致所有模型调用全部失败排查时才发现是数据边界策略和 KMS 策略互相矛盾。分阶段落地能大幅降低这种风险。6.2 常见问题排查实录这里我把实际项目中遇到的高频问题整理成一张速查表你可以直接对照排查。现象可能原因排查步骤模型调用返回 AccessDeniedExceptionIAM 策略未授权或 KMS 密钥策略缺少 Decrypt 权限检查调用者角色附加策略再检查 KMS Key Policy 是否允许该角色使用密钥通过 VPC 内访问超时PrivateLink 终端节点未关联正确的子网/安全组或路由表缺失查看终端节点状态是否为 Available检查安全组是否放行 443 端口确认子网路由调用报错提示 Cross-account access denied跨账户角色信任策略或资源策略未配置检查模型所在账户的 IAM 策略是否显式 Allow 应用账户的 ARN某些请求被 Guardrails 拦截护栏规则过严或包含冲突的过滤规则在 Bedrock 控制台测试护栏查看拦截的具体类别如 PII、敏感词日志里没有模型调用记录未开启 Model Invocation Logging或日志投递权限缺失确认是否开启调用日志检查 S3/CloudWatch Logs 的权限策略模型调用延迟突然升高预置吞吐不足或发生限流观察 CloudWatch 的 ThrottledRequests 指标必要时扩容预置吞吐还有一个非常经典的“假权限损坏”问题。有客户反馈“我明明给角色授权了 Bedrock 的完整权限但调用还是失败是不是 AWS 的访问控制权限已损坏”。结果排查发现他们的 Organization 级 SCP 中有一条策略限制了bedrock:InvokeModel操作SCP 是比 IAM 更上层的过滤器即使 IAM 允许SCP 不允许也没用。所以当你遇到“权限已经给了但还是没权限”的诡异情况时一定要先看 SCP再看 KMS最后才是 IAM。6.3 实操心得安全配置不能只靠控制台“点按钮”最后说一点我的个人实操体会。Bedrock 安全能力的配置虽然可以在控制台完成但在生产环境中我强烈建议用基础设施即代码IaC的方式来管理比如通过 AWS CloudFormation 或 Terraform 编写安全相关资源。这样做有几个明显好处第一配置可审阅、可版本化。任何对策略、密钥、护栏的修改都能历史回溯不会出现“谁偷偷在控制台把 Guardrails 关了”的情况。第二环境可复制。测试环境、预生产环境、生产环境可以用同一套代码部署保证策略一致性。第三审计友好。审计方要求提供安全配置清单时直接把代码库和部署记录拿出来即可。我在项目里会维护一个专门的security/目录把 KMS、IAM、VPC Endpoint、Guardrails、模型调用日志相关配置全部代码化。每个变更必须走 Pull Request 评审安全团队的负责人必须approve才能合并。这个过程虽然初期会慢一些但后期带来的稳定性和合规收益远远超过那点时间成本。7. 写在最后安全能力是“用”出来的不是“配”出来的说了这么多我还是想强调一个观点像 AMAZON BEDROCK 这样的托管大模型服务安全能力再强也不是开箱即用、一劳永逸的。每家企业对“数据隔离”的定义不同对“访问控制”的粒度要求不同对“合规边界”的理解也不同。六层管控框架给你提供了一张地图但路线怎么走还是要踩着自己的业务场景一步步趟出来。我个人在实际项目里最深刻的感受是安全评审不是阻碍上线的绊脚石反而是帮应用兜底的保险丝。多花一点时间在 Bedrock 的网络、权限、加密、留存这四件事上后面应用跑起来你会睡得踏实很多。
