2022 年 SaaS 安全调查7 大焦点

受访人统计

大多数受访者(71%)来自美洲，另外17%来自亚洲，13%来自欧洲、中东和非洲。在这些参与者中，49%影响决策过程，39%管理决策过程本身。该报告调查了来自不同行业的组织，如电信(25%)、金融(22%)和政府(9%)。

虽然这项调查有很多值得借鉴的地方，但以下是我们排在前7位的焦点。

1：SaaS 错误配置导致安全事件

自 2019 年以来，SaaS 错误配置已成为组织最关心的问题，至少有 43% 的组织报告他们已经处理过由 SaaS 错误配置引起的一个或多个安全事件。然而，由于许多其他组织表示他们不知道自己是否经历过安全事件，因此与 SaaS 配置错误相关的事件的数量可能高达 63%。与 IaaS 错误配置导致的 17% 的安全事件相比，这些数字令人震惊。

图 1. 公司因 SaaS 配置错误而遭遇安全事件

2：缺乏可见性和过多的访问部门被认为是导致SaaS错误配置的主要原因

那么，这些SaaS错误配置的原因究竟是什么呢?虽然有几个因素需要考虑，但受访者将其归结为两个主要原因——有太多的部门可以访问SaaS安全设置(35%)，以及对SaaS安全设置的变化缺乏可见性(34%)。这是两个相关的问题，考虑到在采用SaaS应用程序时缺乏可见性是最重要的问题，而且组织中平均有多个部门可以访问安全设置，因此这两个问题都不足为奇。缺乏可见性的主要原因之一是，有太多部门可以访问安全设置，而其中许多部门没有接受过适当的培训，也没有关注安全性。

图 2. SaaS 配置错误的主要原因

3：对业务关键SaaS应用程序的投资正在超过SaaS安全工具和人员

众所周知，企业正在采用更多的应用程序——仅过去一年就有 81% 的受访者表示他们增加了对业务关键型 SaaS 应用程序的投资。另一方面，SaaS安全性方面在安全工具(73%)和人员(55%)上的投入较低。这种不一致意味着现有安全团队在监控SaaS安全性方面的负担越来越重。

图 3. 公司对 SaaS 应用、安全工具和员工的投资

4：手动检测和修复 SaaS 错误配置使组织暴露在外

46% 手动监控其 SaaS 安全性的组织每月只进行一次或更少的检查，而 5% 根本不进行检查。发现错误配置后，安全团队需要额外的时间来解决它。大约四分之一的组织在手动修复时需要一周或更长时间来解决错误配置。这个漫长的时间使组织容易受到攻击。

图 4. 公司手动检查其 SaaS 错误配置的频率

图 5. 公司手动修复 SaaS 错误配置需要的时间

5：使用 SSPM 可以缩短检测和修复 SaaS 错误配置的时间

另外，已经实施 SSPM 的组织可以更快、更准确地检测和修复他们的 SaaS 错误配置。这些组织中的大多数 (78%) 使用 SSPM 每周或更多次检查其 SaaS 安全配置。在解决错误配置方面，81% 的使用 SSPM 的组织能够在一天到一周内解决它。

图 6. SaaS 安全配置检查的频率

图 7. 修复 SaaS 错误配置的时间长度

6：第三方应用程序访问是最受关注的问题

第三方应用程序，也称为无代码或低代码平台，可以提高生产力，实现混合工作，并且对于构建和扩展公司的工作流程至关重要。但是，许多用户快速连接第三方应用程序而不考虑这些应用程序请求的权限。一旦被接受，授予这些第三方应用程序的权限和后续访问可能是无害的，也可能是恶意的。如果没有对 SaaS 到 SaaS 供应链的可见性，员工将连接到其组织的关键业务应用程序，安全团队对许多潜在威胁视而不见。随着组织继续采用 SaaS 应用程序，他们最关心的问题之一是缺乏可见性，尤其是第三方应用程序访问核心 SaaS 堆栈的可见性 (56%)。

图 8. 公司在采用 SaaS 应用程序时最关心的问题

7：提前规划和实施 SSPM

尽管该类别在两年前就被引入市场，但它正在迅速成熟。在评估四种云安全解决方案时，SSPM 的平均评级为“有些熟悉”。此外，62% 的受访者表示他们已经在使用 SSPM 或计划在未来 24 个月内实施。

图 9. 目前使用或计划使用 SSPM 的公司

结论

《2022 年 SaaS 安全调查报告》提供了有关组织如何使用和保护其 SaaS 应用程序的见解。毫无疑问，随着公司继续采用更多的业务关键型 SaaS 应用程序，风险也越来越大。为了直面这一挑战，公司应该开始通过两个最佳实践来保护自己：

第一个是让安全团队能够全面了解所有 SaaS 应用程序的安全设置，包括第三方应用程序访问和用户权限，这反过来又允许部门保持其访问权限，而不会有进行不当更改而使组织易受攻击的风险。

其次，公司应该利用自动化工具（例如 SSPM）来持续检测和快速修复 SaaS 安全错误配置。这些自动化工具允许安全团队近乎实时地识别和修复问题，从而减少组织易受攻击的总体时间或防止问题一起发生。

这两个实践都为他们的安全团队提供了支持，同时不会阻止部门继续他们的工作。