为什么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的联合创始人兼首席技术官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生态系统奠定了基础。工作不会止步于此。最好的还在后头。