随着越来越多的企业迁移到云中，保护敏感数据变得前所未有的重要。云计算虽然提供了灵活性和可扩展性，但也为一系列安全风险打开了大门。
从简单的配置错误到复杂的内部威胁，云安全漏洞已使公司损失了巨额资金，并泄露了数百万用户的私人信息。在本文中，我们探讨了 10 起备受瞩目的云安全故障，每起故障都为企业提供了重要教训，让他们认识到强大的安全实践的重要性。这些真实事件为依赖云服务的企业提供了警示，提供了关键的要点，以帮助防止下一次重大漏洞。
以下是哪里出了问题、可以采取哪些不同的措施以及公司如何加强对不断变化的云安全威胁的防御。
1.Dropbox（2012年）
事件：一名黑客通过第三方漏洞获取了 Dropbox 用户凭证并访问了用户的云存储文件，导致数百万个账户暴露。
回应：Dropbox 调查发现，从其他网站窃取的用户名和密码被用于登录“少数”Dropbox 帐户。该公司联系了这些用户，并表示愿意帮助他们保护自己的帐户。
时任 Dropbox 工程副总裁的 Aditya Agarwal 表示：“一个被盗的密码还被用来访问员工 Dropbox 帐户，其中包含一份带有用户电子邮件地址的项目文档。我们认为这种不当访问是导致垃圾邮件的原因。”他补充说，Dropbox 正在实施额外的控制措施，以确保不再发生此类问题。
这家云存储公司选择引入双因素身份验证 (2FA) 并加强安全监控，以防止未来发生违规行为。后来，在 2016 年，有消息称此次违规影响了超过 6800 万个用户帐户。Dropbox 提醒自 2012 年以来未更改密码的用户进行更改，以防万一。
教训：强大的多因素身份验证 (MFA) 和监控异常登录活动的重要性。
2. Snapchat（2014年）
事件：Snapchat 的云基础设施因处理用户数据的方式存在漏洞而受到攻击。黑客利用云系统泄露了数百万张照片。
回应：在这次通常被称为“Snappening”的数据泄露事件中，Snapchat 本身并没有直接受到黑客攻击。相反，存储 Snapchat 照片的第三方应用程序受到了攻击。该公司的一位发言人表示：“Snapchat 用户因使用第三方应用程序发送和接收 Snap 照片而成为受害者。
我们明确禁止第三方应用程序访问我们的服务，因为它们会危及用户的安全。” Snapchat 警告用户不要使用第三方应用程序，并改进了其安全政策，以帮助防止未经授权的访问。
教训：对云存储中的用户数据和图像处理采取适当的安全措施可以防止大量数据泄露。
3.Uber（2016年）
事件：黑客入侵 Uber 的云存储，窃取了 5700 万用户和司机的个人数据。Uber 最初未报告此次入侵事件。
回应： Uber 高管最终在 2017 年对此次入侵事件发表了评论，但只是在事件公开之后。这家运输公司证实有 5700 万个账户遭到入侵，包括用户和司机的姓名、电子邮件地址和电话号码。Uber 当时并没有报告此次入侵事件，而是以漏洞赏金为幌子向黑客支付了 10 万美元，要求他们删除数据并保持沉默。
2017 年 11 月，在数据泄露事件发生后出任 Uber 首席执行官的达拉·科斯罗萨西 (Dara Khosrowshahi) 承认 Uber 未能尽早披露该事件。他表示：“这一切都不应该发生，我不会为此找借口。我们正在改变经营方式。我们正在采取措施确保我们今后做正确的事情。”
乔·沙利文 (Joe Sullivan) 是 Uber 入侵期间的首席安全官，后来他被解雇，并被指控掩盖入侵事件。检察官指控他通过错误地将入侵归类为漏洞赏金支付来妨碍司法公正。在 2022 年的审判中，沙利文为自己的行为辩护，称：“我当时遵循了 Uber 的流程。”
然而，他被判犯有妨碍司法公正罪，这是安全主管首次因处理数据泄露不当而被定罪。在这起丑闻之后，Uber 加强了安全政策，并因未能披露泄露事件而达成 1.48 亿美元的和解。
教训：定期监控和保护云存储，实施严格的访问控制，并确保适当的事件响应协议。
4.AWS S3 漏洞（2017 年）
事件：由于公司错误地将 AWS S3 存储桶置于公开可访问状态，导致大规模数据泄露。这暴露了客户信息、内部业务文档和私人通信等敏感数据。
回应：AWS强调，此次漏洞并非由于 AWS 本身的漏洞造成，而是由于客户配置不当，无意中导致其 S3 存储桶可供公众访问。
该云计算提供商发布声明澄清这些漏洞是用户错误造成的，并解释道：“Amazon S3 默认是安全的，存储桶访问由客户控制。我们为客户提供明确的指导和工具，以便他们安全地配置资源。”
AWS 继续推出额外的安全功能和增强功能来帮助客户保护他们的数据。
次年，AWS CISO Stephen Schmidt (AWS CISO) 在 AWS re:Invent 2017 上解决了这些问题。他说：“我们今天看到的头号安全风险仍然是配置错误。我们强烈建议客户利用加密、IAM 策略和访问控制功能来防止意外暴露。”
教训：始终谨慎配置访问权限并定期审核云存储是否存在安全风险。
5.Accenture（2017年）
事件：由于安全配置薄弱，埃森哲意外暴露了其内部云数据库，其中包含敏感的客户信息，包括密码。
回应：发现后，埃森哲立即保护了被泄露的数据，并表示：“我们的客户不会面临任何风险——没有任何有效凭证、PII 或其他敏感信息受到泄露。”
它进一步澄清说，泄露的信息并未授予客户端系统的访问权限，并且与生产数据或应用程序无关。
教训：始终加密敏感数据并谨慎管理对基于云的基础设施的访问。
6.GitHub（2018）
事件：GitHub 遭受了一次大规模 DDoS 攻击，该攻击利用了云的扩展能力。这次攻击使 GitHub 的基础设施不堪重负，但该事件表明云服务既可以支持大规模攻击，也可以缓解大规模攻击。
响应：这次 DDoS 攻击是当时有记录以来规模最大的攻击之一，峰值达到每秒 1.35 兆兆位 (Tbps)。这是一次 memcached 放大攻击，利用不安全的 memcached 服务器向 GitHub 的基础设施注入大量流量。
在成功缓解攻击后，GitHub 的工程团队发布了一篇博客文章，详细介绍了此次事件。文章称：“在 UTC 时间 17:21 至 17:30 之间，GitHub 受到了创纪录的 DDoS 大流量攻击。我们短暂地经历了间歇性可用性，但我们的系统自动缓解了攻击。我们根据之前的攻击模拟了我们的 DDoS 响应能力，并立即将流量路由到我们的 DDoS 缓解提供商。”
GitHub 工程师 Sam Kottler 补充道：“这是我们和全世界当时所见过的最大规模的 DDoS 攻击。基于云的缓解策略有助于吸收大量涌入的流量。”
教训：云服务具有极强的可扩展性，但即使在云环境中，也必须制定 DDoS 缓解策略。
7.Capital One（2019）
事件：错误配置的 AWS S3 存储桶泄露了超过 1 亿客户的敏感数据。一名前 AWS 员工利用该漏洞访问了个人信息、信用评分和银行详细信息。
回复： 2019 年 7 月 29 日，Capital One 宣布，2019 年 7 月 19 日，其确定一名外部个人在未经授权的情况下访问了与申请其信用卡产品的人员以及 Capital One 信用卡客户有关的某些类型的个人信息。
第一资本银行表示，它立即修复了被利用的配置漏洞，并迅速与联邦执法部门展开合作。负责此次入侵的个人已被联邦调查局逮捕，第一资本银行为受影响的用户提供免费的信用监控和身份保护。
课程：云服务中正确的配置管理和访问控制的重要性。
8.微软（2019年）
事件： 2019 年，由于云存储设置错误，微软泄露了数百万条客户支持记录。这些数据存储在 Azure Blob Storage 中，研究人员发现，由于安全配置不当，这些记录（包括客户支持单和其他敏感信息）可以公开访问。
回应：微软迅速保护了被泄露的数据，并承认第三方供应商应对此错误负责。他们澄清说，这些数据并未被恶意行为者访问，而是由于配置错误而公开可见。微软通过加强云存储的安全协议，努力防止未来发生类似事件。
教训：此事件凸显了正确配置云存储和实施适当访问控制的重要性。定期的安全审核和监控对于识别和修复漏洞至关重要，以免漏洞被利用。
9.Facebook（2019年）
事件：Facebook通过不安全的云存储暴露了超过5.4亿条记录，其中包括用户评论、点赞、反应等数据，容易受到外部访问。
回应：在发现泄露事件后，Facebook 承认第三方开发者应对不安全的存储负责。Facebook 澄清说，这些数据并非直接从其自身系统泄露，而是由于应用程序开发者使用 Facebook 的 API 收集用户数据时采取了不当的安全措施。
据报道，Facebook 已努力通知第三方开发者并鼓励他们修复安全漏洞。它还限制了允许应用程序收集此类数据的 API 的访问，使得未来因配置错误而发生数据泄露的几率更小。
课程：确保正确配置云存储并实施加密以保护静态数据。
10.Slack（2020）
事件：一名员工的 API 令牌被公开后，Slack 的云基础设施遭到入侵。这导致未经授权的用户访问敏感的公司数据。
回应： Slack 承认了此次入侵，并向客户详细说明了如何处理该事件。该公司强调，此次事件影响范围有限，并未导致其基础设施受到更大范围的破坏。
该公司在一篇博客文章中表示：“我们已确定该事件是由暴露的 API 令牌引起的。它允许未经授权访问我们系统的某些部分。该问题已完全解决，暴露的令牌已失效。”
该公司还强调，此次泄密事件并未泄露任何敏感用户数据（例如私人消息或账户凭证）。
Slack 更新了其 API 令牌管理的安全实践，鼓励组织使用更安全的方法来处理 API 令牌，并采用额外的身份验证措施来防止将来发生事故。
教训：定期监控和轮换 API 令牌和密钥，以减轻滥用的风险。
