2023年，人工智能领域的一个重磅新闻引起了全世界的关注——微软AI研究团队的一个存储资源因为安全配置失误，把38TB的内部数据暴露在了公共互联网上，任何人都可以随意访问和下载。这起事件是由一家名为Wiz的网络安全公司的研究人员在例行的云安全扫描中发现的。研究人员发现了一个属于微软的Azure云存储账户中的一个存储资源，配置的SAS共享访问令牌的权限策略存在过度授权的问题。SAS令牌是Azure云存储提供的一种授权机制，允许用户生成一个临时的、带特定权限范围的访问链接，分享给其他人访问存储中的数据。正常配置下，这个令牌应该设置有效期截止、访问范围尽可能窄、用途尽可能明确，并且生成后应该通过受控渠道分发给指定的人员。
但微软AI团队在这方面的配置出了大问题。SAS令牌被配置成了全局有效，也就是说这个令牌可以访问整个存储账户里的全部资源，而不是仅限于某个特定的文件夹。而且令牌没有设置有效期终止时间，意味着这个令牌一旦生成，在管理员手动撤销之前都一直有效。更严重的是，这个令牌被人传到了一个对公网开放的GitHub仓库中——大概是一位开发者为了方便分享数据链接，直接把包含完整SAS令牌的URL地址放到了GitHub的一个公开代码仓库里。从此，任何人只要看到这个GitHub页面，都可以使用这个令牌链接直接浏览和下载微软存储账户中的全部数据。这些数据包括了微软AI研究团队在过去几年积累的AI训练数据、模型权重、内部系统的备份数据、微软员工的Teams聊天记录和工作消息，甚至还有微软一些服务的密码、密钥和其他敏感的访问凭证。总容量高达38TB。
Wiz的安全研究人员发现这个配置错误后按照负责任的披露流程联系了微软。微软方面反应很快，立刻撤销了泄露的SAS令牌并关闭了公共访问，但这38TB数据的暴露持续了多长时间呢？安全研究人员初步估算这个令牌出现在GitHub上至少已经几个月了。几个月的时间里，不知道有多少人——自动化的爬虫、竞争对手的情报搜集人员、安全研究人员或者普通的互联网用户——可能都已经访问过、下载过、利用过这些数据了。更让人担心的是，数据中包含了微软内部员工的聊天记录和系统访问凭证。如果这些内部聊天记录涉及产品研发的未公开发布的信息或者团队内部对于某项技术的评估意见，泄露之后的竞争后果是非常严重的。而系统密钥和密码的泄露直接威胁到微软其他云服务和内部系统的安全，微软必须在获取完整泄露清单后逐一更换和修补。
从泄密链路上看，这就是一起典型的"人制造了漏洞"的事件。开发者或运维人员在配置Azure云存储时生成了一条全局权限且没有有效期的SAS令牌，然后这个包含完整令牌的URL被发布到了一个公开的GitHub仓库中，令牌的信息就暴露在了全世界互联网用户的检索范围中，跟水泼出去一样再难收回。网上的自动化爬虫和搜索引擎会对GitHub上的各种URL进行解析抓取，不需要什么高级黑客技术，只要你的URL暴露在公网上，你就不再拥有控制它的能力。
这个案例给我们的核心警示非常明确。云计算时代，错误配置就是灾难。SAS令牌、访问密钥、临时授权链接这些机制本身是为了方便数据共享和协作而设计的，但任何便利性都需要跟安全性做平衡。理论上SAS令牌正确的用法应该是：限制到最窄的访问范围、设置尽可能短的有效期、通过私密的受控渠道分配给指定的接收者、在分发完成后及时撤销，并且定期审计所有活跃的SAS令牌。但微软这次一个都没做到。这也说明安全规范在大型云服务提供商内部也未必能从上到下贯彻到位。任何一家公司的安全防御体系，都要靠制度来保证执行，而不能指望每个工程师都自觉地遵守安全通用做法。就连微软这样在全球安全领域投入很大的公司都会在内部犯这么基础的配置错误，其他企业在盲目上云、用公有云存储服务的时候更要打起十二分的精神。要用制度的手段在云环境中嵌入安全自动化检测能力，比如对每个新创建的SAS令牌自动检查其权限范围是否符合最小化原则、是否有合理的过期时间、是否出现在公开仓库中。安全意识再强的工程师也有疏忽的时候，只有自动化的安全扫描和策略强制才是保护数据安全的长久之计。38TB数据的教训用给我们每个人上了一课：云计算带来的便利和灵活，必须以扎扎实实的安全配置作为前提才能成立。
