为什么需要重新思考SaaS安全

SaaS改变了一切。从协作工具到关键业务应用，SaaS已成为组织消费技术的默认方式。但随着这一巨大转变，出现了一个大问题：安全性未能跟上。

大多数第三方风险管理（TPRM）计划关注的是供应商的整体组织安全性（如SOC 2报告和ISO认证）。它们并未真正评估每个SaaS应用程序内部的实际安全能力，也未指导企业如何利用这些能力。这意味着企业最终会拥有数百个在纸面上看起来合规，但在实践中却存在真实安全漏洞的应用程序。

摩根大通最近给供应商的公开信正好强调了这个问题。他们指出了SaaS安全控制缺乏一致性的问题，并敦促行业改进。没有明确的基线，企业、SaaS供应商和安全团队都只能自行填补空白，导致大量重复劳动和不必要的风险。

SSCF v1.0的推出

这正是SaaS安全能力框架（SSCF）v1.0的用武之地。

该项目由MongoDB和GuidePoint Security的安全负责人推动，他们亲自领导了开发工作。与此同时，云安全联盟（CSA）共同领导，发挥了其最擅长的作用：汇集行业利益相关者，应用其在构建云控制矩阵（CCM v4）等标准方面的深厚经验，并通过结构化的研究生命周期指导工作。CSA确保SaaS提供商、SaaS客户、审计师和咨询公司都有发言权，因此该框架反映了实际需求。

结果如何？一个实用的、面向客户的安全能力框架，可供SaaS供应商采用，为SaaS客户和供应商提供安全审查和实践的一致性，帮助降低潜在的安全风险。

GuidePoint Security高级云实践总监Jonathan Villa表示：“SSCF v1.0解决了SaaS安全中长期存在的挑战：缺乏一致且可操作的控制措施。通过关注供应商和客户都可以实施的实用解决方案，该框架弥合了高级别合规性与实际安全需求之间的差距。在GuidePoint Security，我们很自豪能与云安全联盟和行业同行合作，创建了简化所有人SaaS安全性的方案。”

MongoDB安全工程高级总监Boris Sieklik补充道：“SSCF提供了我们这样的SaaS客户一直缺失的东西：一套清晰、标准化的可配置控制措施，使评估、采用和安全操作SaaS应用程序变得更加容易。”

以下是SSCF旨在实现的目标：

• 对于TPRM团队：提供一致的基线，使供应商风险评估更快、更直接。
• 对于SaaS供应商：通过将响应与单一、广泛认可的标准对齐，减少重复问卷和不同评估的负担。
• 对于SaaS安全工程师：提供实用的检查清单，以加强SaaS采用和日常安全操作。

v1.0包含的内容

SSCF v1.0在六个关键安全领域布局了控制措施，这些领域采纳自CSA的CCM v4：

• 变更控制与配置管理（CCC）
• 数据安全与隐私生命周期管理（DSP）
• 身份与访问管理（IAM）
• 互操作性与可移植性（IPY）
• 日志记录与监控（LOG）
• 安全事件管理、电子发现与云取证（SEF）

这些领域并不取代SOC 2或ISO 27001等框架，而是将这些高级别要求转化为客户实际可以配置和依赖的有形SaaS安全功能。例如日志交付、SSO强制执行、安全配置指南和事件通知，所有这些都是客户安全运行SaaS日常真正需要的。

为何重要

SSCF的核心是减少摩擦。企业在其SaaS组合中获得更一致的安全功能，并能在高度多样化的SaaS环境中创建一致的实施基线。供应商确切知道将需要哪些安全控制。通过摆脱一次性评估并转向共同基线，每个人都节省了时间。

最重要的是，它建立了信任。在SaaS如今已成为关键任务的世界里，这种信任是安全采用和风险盲区之间的区别。

Valence Security联合创始人兼CTO Shlomi Matichin表示：“在SSCF被广泛采用的世界里，组织将能够安全、大规模地消费SaaS，而不会产生安全运营成本。随着代理AI的快速采用加速了SaaS采用和数据移动，SSCF的重要性倍增。”

下一步计划

SSCF v1.0仅仅是个开始。项目的下一阶段已经启动，重点是使框架更具可操作性：

• 实施和审计指南，帮助组织将控制措施付诸实践，并让审计师知道如何有效评估这些控制措施。
• 评估和认证方案，衡量这些控制措施的实际效果。

这些将共同帮助SaaS提供商和客户超越检查清单，实现真正可衡量的安全改进。

CSA很自豪能与MongoDB、GuidePoint Security以及包括Grip Security、Obsidian Security、Valence Security、GitLab、Siemens、Kaufman Rossin、AppOmni、Band of Coders等在内的广泛领先贡献者社区合作，使SSCF v1.0成为现实。这第一个版本为更一致、更安全、更可信的SaaS生态系统奠定了基础。工作不会止步于此，最好的还在后头。