梦想国际云安全与企业数据保护AI

梦想国际云安全：云平台默认配置已经越来越安全以后，为什么企业自己的权限关系反而变得更重要？

这几年一个明显的变化是：新建一个对象存储桶，默认不公开；新建一个数据库实例，默认不对公网开放；控制台会在你要放开某条策略时多弹一次确认。云平台把“出厂状态不安全”这一类问题吃掉了一大半。但云上的安全事件并没有随之消失，只是入口换了地方——从“忘了关的默认配置”，挪到了“企业自己一步一步配出来的权限关系”。

先说清楚这个变化本身。早期公有云的很多问题属于默认值问题：对象存储默认可公开读、安全组默认放开、审计日志默认不开。这类问题的共同点是好识别、好扫描，一条规则就能查出来，所以工具、厂商和合规基线在过去几年集中把它解决掉了。今天多数主流云平台的默认基线，已经比不少企业自建机房的默认状态更严格。这是一个真实的进步，不该被淡化。

问题在于，权限关系不是“出厂配置”，它是企业自己长出来的。一个角色最初只需要读一个目录，半年后为了配合一次数据迁移加了写权限，迁移结束没人回收；一个服务账号为了排障临时挂上了近似管理员的策略，故障恢复后被记成“以后再收”；一个跨账号信任关系为了让测试环境能读一份生产样本而建立，而测试环境的准入标准比生产低一截。这些都不是厂商能替你判断的，因为从平台视角看，每一步都是合法的、被授权的、有操作记录的正常变更。

这里最容易看漏的是权限的传递性。很多团队检查权限时看的是“这个人身上挂了哪些策略”，但真正决定他能碰到什么的，是直接策略、角色链、资源侧策略、用户组继承和跨账号信任叠加之后的有效权限。一个用户的直接策略可能非常干净，却因为属于某个组、组能扮演某个角色、那个角色又在另一个账号里被资源策略信任，最后拿到了远超预期的访问面。只看一层，永远看不出这个问题；而攻击者在拿到一个凭据之后，恰恰是顺着这条链往前走的。

多云会把这件事再放大一层。同一个人在不同云平台、不同 SaaS 里往往有不同的账号标识和不同的权限模型，某个平台里的“只读”在另一个平台里可能包含导出能力。如果没有一个统一视角把这些身份归拢到同一个人身上，任何一次离职、转岗或者账号被冒用的影响评估都会漏项。这也是为什么身份治理和云权限治理越来越难分开谈。

梦想国际在做云权限分析时的思路是：让模型负责把有效权限展开、把变更历史和真实调用记录关联起来、按“被冒用后的可达范围”排序，输出一份带证据的候选清单。但回收动作本身必须由人确认。原因很实际——权限回收错了会直接打断业务，而模型看不到“这条权限下周有一次季度结算要用”这类上下文。自动化负责发现、关联和排序，审批边界留给人，这是我们认为在云权限治理里比较稳的分工。同时要提醒一句：执行这些分析的安全自动化本身通常也持有相当高的读取权限，它自己也应该被纳入权限治理的范围，而不是站在治理之外。

落地顺序上，比较务实的做法是从边界最硬的地方往里做：先把跨环境、跨账号的信任关系理清楚，再处理仍在使用的长期静态密钥，然后是临时提权的到期机制，最后才是大规模的最小权限收敛。反过来做——一上来就全量收敛——通常会在第一周被业务投诉打回。

所以云平台默认配置越安全，企业越应该把检查重心从“有没有漏配”转向“权限关系画成图之后是什么形状”。前者是能被工具一次性解决的问题，后者是需要长期维护的组织问题。

文件链接只有公司员工能打开以后，为什么数据安全团队仍然需要知道“哪些员工”？

“仅限公司员工可访问”这个设置解决的是“链接被转发到公司外面”这一类问题，它确实有用。但它把一个范围问题换成了另一个范围问题：从“全互联网可见”缩到了“全公司可见”。对一份本来只该给三个人看的方案来说，全公司和全互联网的差别，很多时候只是扩散速度不同。

内部共享背后的默认心理是“都是同事”。这条假设在十个人的团队里成立，在几千人的组织里不成立。风险并不在于同事有恶意，而在于三件具体的事：第一，人员会流动，今天的同事下个季度可能已经去了业务上直接竞争的岗位；第二，账号会被冒用，一个被钓走的普通员工账号会立刻继承“全公司可见”的全部内容，攻击者不需要提权就能拿到一大片；第三，内容会被再分发，一条内部链接被贴进一个几百人的项目群，可触达范围就又扩大了一次，而原始文档的权限设置一次都没有被改动过。

这里需要把两个常被混用的概念分开。最小权限管的是权限强度——能读还是能改、能不能删、能不能导出；按需知情（need-to-know）管的是权限范围——这个人当前的工作到底需要看哪些数据。两者是一对，缺一个都会留下空档：只做最小权限，可能得到一群“只能读、但能读全部”的账号；只做按需知情，可能得到“范围很准、但每个人都是管理员”的结构。访问权不应该由“这个人是否可信”决定，而应该由“当前这项工作是否需要”决定。

过度授权通常是这样悄悄发生的：某人为了一次跨部门评审，把一个文件夹设成“组织内所有人可查看”，因为逐个加人太慢，而评审第二天就开；评审结束后没有人记得改回来；三个月后，另一个同事在这个文件夹里新建了一份包含客户名单的表格，新文件按继承规则拿到了父目录的共享设置。整个过程里没有任何一步是攻击，也没有任何一步会触发告警，但结果是一份客户名单对全体员工可见。第一眼看这个共享完全正常——它确实“仅限内部”。

落地时有一个反直觉的点：一刀切禁止内部共享几乎一定会失败。人们会改用邮件附件、私人网盘、截图，甚至把内容复制粘贴进聊天记录，结果是数据离开了有审计能力的平台，安全团队反而更看不见。比较务实的顺序是：先做数据分类，把“受限”以上的内容识别出来；再针对这部分内容关掉“组织内所有人可见”这一档，其余内容保持原有便利；然后给共享加默认有效期，让权限自己过期，而不是等人想起来回收；最后对存量共享做一次盘点，重点看创建时间超过半年、且实际访问者数量远大于创建者预期的那些。

模型在这里适合承担的工作是排序：把“共享范围”和“内容敏感度”两个维度对上，找出范围最宽而内容最敏感的那一批，再结合最近是否真的有人访问过，给出建议收敛的候选清单。但是否收敛、收敛到谁，必须由数据责任人确认。安全团队不掌握业务上下文，贸然回收一个正在被外部审计使用的目录，造成的代价可能比风险本身更大。这里的边界很清楚：模型给候选和证据，人给决定。

所以数据安全团队仍然需要知道“哪些员工”。不是因为不信任员工，而是因为“哪些人能看到这份数据”这个问题的答案，本身就是这份数据风险画像的一部分。链接是否仅限内部，只是这张画像里的第一格，后面还有好几格是空的。

Confidential Computing已经能够保护部分使用中数据以后，为什么它仍然不能替企业解决错误权限问题？

机密计算这两年从研究话题变成了云上可以真实选用的能力，尤其在把敏感数据交给云端 AI 推理这类场景里被反复讨论。它确实补上了一个长期存在的空白：数据在被处理的那一刻，传统加密是关掉的。也正因为它解决的问题非常具体，才容易被读成一句“上了机密计算数据就安全了”。这句话不成立，原因不在技术强弱，而在威胁模型对不上。

先把三种状态摆在一起看。静态数据靠存储加密和密钥管理，传输中数据靠 TLS 和证书校验，这两段的做法业界已经相当成熟。真正长期空着的是第三段：数据被加载进内存、正在被 CPU 计算的时候，它必须是明文的，否则算不出结果。这段时间里，能读到内存的角色——宿主机操作系统、虚拟机管理程序、同一台物理机上的其他租户——理论上都在数据的信任边界之内，而这恰恰是很多企业把敏感数据搬上云时最难说服自己的一点。

技术上，可信执行环境把一段计算放进由 CPU 保护的隔离区，隔离区内的内存内容对宿主机操作系统、虚拟机管理程序和同机其他租户不可见；远程证明则让数据所有者在把数据送进去之前，先验证对面运行的确实是自己预期的代码和环境版本。这两件事加起来，回答的是一个很明确的问题：我把数据交给云上的计算过程时，云平台自己能不能看到它。这是一个真实的、以前没有好答案的问题，现在有了部分答案。

边界在哪里，用一个场景就能说清楚。假设一家企业把客户数据放进机密计算环境做模型推理，隔离区配置正确，远程证明也通过了。然后有人在配置调用权限时，把调用这个推理服务的角色误设成了所有业务账号都能扮演。接下来发生的事情，TEE 一步都拦不住：请求来自被正确授权的身份，数据在隔离区里被正常解密、正常计算，结果被正常返回给调用方。从硬件视角看，这是一次完全合规的使用。权限配错这个问题，机密计算不解决，因为它根本不在这个问题的作用域里。

顺着这条线，还有几件事同样不在它的覆盖范围内，值得逐条列清楚：

• 身份与认证：谁能拿到进入隔离区的凭据，仍然由身份系统决定。凭据被钓走，隔离不起作用。
• 应用安全：隔离区里跑的代码如果自身有逻辑缺陷，把数据返回给不该拿的调用方，硬件不会阻止它——那是被授权的正常输出。
• 数据治理：哪些数据可以进入这个计算、保留多久、结果能否落盘再共享，这些都是治理决策，不是硬件特性。
• 密钥管理：密钥的托管、轮换和恢复流程如果失控，证明链条再完整也撑不住。
• 输出侧风险：隔离区保护的是过程，不是结果。计算结果一旦离开隔离区，就回到普通的数据保护规则里，该分类分类，该管共享管共享。

那么正确的用法是什么？把它当成一层，而不是一个结论。评估顺序上，先确认这个工作负载的威胁模型里，“云平台或同宿主租户窥探内存”是不是一个你真正关心的风险——对很多内部系统来说并不是，把预算花在这里性价比不高；如果确实是（比如处理跨境敏感数据，或者需要向监管方、客户证明平台方在技术上无法读取），再评估它带来的性能开销与运维复杂度是否可接受；最后，把身份、权限、审计这三件事按原样做完，不因为上了 TEE 就降低任何一项的要求。

云端 AI 推理是目前机密计算被讨论最多的场景，因为送进模型的提示词和输入数据往往包含企业最敏感的内容。梦想国际在这类架构评审里的做法是：让模型帮助梳理数据流向、标出每一段处于哪种状态、指出哪一段的保护手段和数据敏感级不匹配，形成一张可以讨论的结构图；但“这条数据流是否可接受”的判断，由安全架构师和数据责任人共同确认。证据不足时，专业的结论有时就是“这一段的保护边界目前无法确认”，而不是给一个听上去让人安心的答案。

一句话总结：机密计算把加密的覆盖范围从两态扩到了三态，这是实打实的进展。但它扩的是“保护范围”，不是“判断能力”。谁该访问这份数据，仍然要企业自己回答。