为什么写

去年，一家位于深圳的金融科技公司在进行系统升级时，运维工程师在配置云存储服务时做了一个小小的疏忽——将一个本该设为私有的存储桶设置为了公开访问。这个看似微不足道的错误，让公司数百万条用户数据在互联网上暴露了整整三周才被发现。暴露的数据包括用户的实名认证信息、银行卡绑定记录、交易流水和风险评级报告。

发现问题的是一位安全研究人员，他在进行常规的互联网空间探测时找到了这个公开的存储桶。通过搜索完整的内容，他基本可以确定该存储桶归属于这家金融科技公司。好在这位研究人员第一时间联系了公司并协助完成了数据保护，没有造成二次传播。但这件事给公司带来的声誉冲击和监管风险是巨大的。

带来哪些隐患

云服务配置错误已经成为企业数据泄露的头号原因之一。根据多家安全机构的数据统计，在近两年发生的云数据泄露事件中，有四到五成是由配置错误而非黑客攻击导致的。

配置错误的成因往往非常简单。可能是因为运维人员遗漏了某个设置项，可能是使用了自动部署脚本但脚本中的配置是开发环境版本，也可能是团队在匆忙中将默认的私有设置改成了公开。这些错误在发生时完全是无意的，但后果却可能是灾难性的。有数据显示，一个公开的云存储桶被扫描引擎发现只需要几十分钟，数据就会被各类爬虫和自动化工具索引。

权限模型的理解不足也是一个普遍问题。不同的云服务提供商有不同的权限模型，有些是桶级别权限，有些是对象级别权限，有些还有不同的层级策略。很多企业的运维人员并没有完全理解这些权限模型的差异和组合效果，在配置时采用"大而化之"的方式，容易留下安全隐患。

多环境配置混淆的问题同样值得关注。很多企业在开发、测试、生产环境之间缺乏严格的隔离机制，开发环境和测试环境的安全要求通常低于生产环境。如果配置不当，测试环境的访问权限或者安全策略被应用到了生产环境，就会造成安全降级。甚至有些企业在测试环境中使用了真实的用户数据，一旦测试环境泄露，生产数据的保护措施全部白费。

自动化的安全扫描和审计并没有跟上。很多企业把云服务部署好了之后就认为万事大吉，缺乏持续的配置审计和自动化扫描。实际上，云环境的配置是动态变化的，今天可能是一个安全的状态，明天一次系统升级或者配置变更就可能引入新的风险。如果没有持续的监控，这些风险可能长期潜伏。

给我们什么提醒

云服务的便利性和复杂性是一枚硬币的两面，企业在享受便利的同时必须对复杂性保持敬畏。

基础设施即代码的理念应当贯穿云服务管理的始终。手动在云控制台上点击配置是不可靠的，任何配置变更都应当通过版本控制的脚本执行。这样不仅可追溯，还可以进行代码审查，避免人为操作失误。每一次配置变更都要走审批流程，不能由一个人独立完成。

安全扫描工具要部署到位。针对云存储桶的公开访问权限，市场上有很多自动化扫描工具可以检测。企业应当部署这些工具，定期对云上资产进行全面的安全扫描。同时，善用云服务商自身提供的安全检查和配置建议功能，这些工具虽然基础但非常实用。

环境隔离必须严格执行。开发、测试、生产环境之间要有严格的网络隔离和账号隔离。敏感数据只能在生产环境中出现，测试环境应当使用脱敏后的模拟数据，绝对不能因为省事就把生产数据用于测试。每个环境要有独立的访问凭证，不能一套凭证走天下。

应急预案要跟上。如果万一发生配置错误导致数据泄露，企业应当在第一时间进行数据保护，评估泄露的影响范围，通知受影响的用户并报告监管部门。响应速度直接决定了事件的严重程度和后续的监管处罚力度。

企业启示

在全面上云的时代，数据安全的责任边界需要重新被定义。北京企密安信息安全技术有限公司认为，云服务提供了弹性、高效的基础设施，但它不承诺企业的数据安全——安全依然是每一家企业自己的责任。上云不是把安全问题甩给云厂商，而是意味着企业需要用新的方法和技术手段来保护自己的数据资产。