改变企业云安全假设的泄露事件
2022年的LastPass泄露事件并不仅仅是关于密码管理器的故事。这是一个关于企业在信任云供应商处理其最敏感数据时，当这种信任被侵犯时会发生什么的故事——这种侵犯并不是由于鲁莽，而是由于外部看不见的实施弱点。
LastPass宣传零知识架构，但实际上该架构并非零知识。2500万用户的加密保险库被提取。该泄露事件于2022年8月首次披露，并在2022年末多次更新，随着范围的扩大。
对于医疗、金融和法律服务等行业——在这些行业中，数据暴露会产生监管责任——LastPass泄露事件并不是一个可以远观的孤立事件。这是一个系统性问题的预览。
重要的实施细节
泄露后的分析揭示了两个关键的实施弱点：
迭代计数不足： LastPass使用PBKDF2进行密钥派生。对于较新的账户，他们使用了100,100次迭代——低于行业推荐的600,000次。对于较旧的账户（在某些情况下为2018年前），迭代计数低至1次迭代。较低的迭代计数使得对加密保险库的暴力攻击在计算上是可行的。获得保险库的攻击者可以系统性地尝试破解主密码。
元数据暴露： 虽然保险库内容是加密的，但元数据却不是。存储在密码管理器中的URL、用户名和服务名称在被提取的数据中是可见的。攻击者可以识别用户拥有账户的服务，从而即使在没有破解保险库加密的情况下也能进行有针对性的网络钓鱼和凭证填充。
对于评估云安全供应商的采购团队来说，LastPass案例表明必须单独回答两个问题：“架构是否为零知识？”和“实施是否正确？”
Okta泄露：同一个月，不同的机制
在2023年10月，Okta披露了一名威胁行为者使用被盗凭证访问了Okta的客户支持系统。该泄露事件暴露了超过600,000条客户支持记录，包括客户在支持互动中上传的文件。
Okta是一个身份安全平台。该泄露事件并不是根本架构的失败——而是供应链访问控制的失败。一名支持工程师的凭证被泄露，攻击者利用合法访问获取敏感数据。
LastPass和Okta的结合展示了企业云供应商面临的两种失败模式：
- 架构失败：零知识声明未真正实施
- 访问控制失败：合法凭证导致未经授权的数据访问
零知识架构解决了第一种失败模式。它并不能保护那些获得合法凭证以访问供应商支持系统的决心攻击者。但它确保即使这样的攻击者也无法访问客户的明文数据——因为供应商的支持系统从未有权访问可解密的数据。
从2022年到2024年，SaaS安全事件增加了300%
AppOmni和云安全联盟的研究跟踪了2022年至2024年间的SaaS泄露事件，发现这一期间影响SaaS平台的安全事件增加了300%。
300%的数字并不代表攻击者的复杂性增加了300%。它代表了SaaS采用的增长与攻击者适应的结合：随着越来越多的企业数据迁移到云平台，攻击者也将资源转向这些平台。攻陷一个SaaS供应商的投资回报率——同时获得数十个或数百个企业客户的数据——远高于针对单个企业的攻击。
对于那些围绕云供应商是安全目标的假设建立供应商安全评估流程的企业来说，2022-2024年的数据需要重新校准。这个假设是错误的。SaaS供应商是优先目标。
LastPass之后的审计清单
对于在LastPass和Okta事件后重新评估云供应商安全的企业，实用的清单如下：
加密实施：
- 请求密钥派生算法、迭代计数和内存参数
- 确认迭代计数符合当前OWASP推荐（PBKDF2-SHA256最低600,000次，或等效的Argon2id参数）
- 验证密钥派生发生在客户端，而不是在供应商服务器上
元数据保护：
- 具体询问存储在明文中的哪些元数据与加密内容一起存储
- 请求数据模型，显示哪些字段是加密的，哪些字段在泄露场景中是可访问的
支持系统访问控制：
- 请求关于支持工程师访问客户数据的文档
- 确认支持系统无法访问客户的明文数据
泄露通知历史：
- 请求披露所有以前的安全事件，包括那些未达到公开披露阈值的事件
- 评估先前披露的透明度和完整性
LastPass泄露事件部分是实施的失败，部分是关于实施透明度的失败。在供应商选择之前提出详细问题的企业会得到允许进行知情风险评估的答案。接受高层声明——“我们加密您的数据”——的企业则承担了在泄露后发现实施细节的风险。
来源：