2022年SaaS安全调查报告与CSA合作，研究了当今企业中CISO和安全专业人员眼中的SaaS安全状态。该报告收集了340名CSA成员的匿名回复，不仅考察了SaaS安全中不断增长的风险，还考察了不同组织目前如何努力确保自身安全。
人口统计学
大多数受访者（71%）位于美洲，另有17%来自亚洲，13%来自欧洲、中东和非洲。在这些参与者中，49%的人会影响决策过程，而39%的人会自行运行决策过程。这项调查调查了来自不同行业的组织，如电信（25%）、金融（22%）和政府（9%）。
虽然这项调查有很多收获，但这些是我们的前七名。
1：SaaS配置错误导致安全事件
自2019年以来，SaaS错误配置已成为各组织最为关注的问题，至少有43%的组织报告说，他们已经处理过一次或多次由SaaS错误配置引起的安全事件。然而，由于许多其他组织表示，他们不知道自己是否经历过安全事件，因此与SaaS配置错误相关的事件的数量可能是as high as 63%。与IaaS错误配置导致的17%的安全事件相比，这些数字是惊人的。
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错误配置的时间长度
单击此处安排15分钟演示Adaptive Shield SSPM如何帮助您
6：第三方应用程序访问是首要问题
第三方应用程序，也称为无代码或低代码平台，可以提高生产力，实现混合工作，在构建和扩展公司的工作流程方面至关重要。然而，许多用户快速连接第三方应用程序，而不考虑这些应用程序请求的权限。一旦被接受，授予这些第三方应用程序的权限和后续访问权限可能是无害的，或与可执行文件一样恶意。如果不了解SaaS到SaaS供应链，员工就会连接到组织的关键业务应用程序，安全团队对许多潜在威胁视而不见。随着组织继续采用SaaS应用程序，他们最关心的问题之一是缺乏可见性，尤其是第三方应用程序对核心SaaS堆栈的访问（56%）。
图8：公司在采用SaaS应用程序时最关心的问题
提前规划和实施SSPM
尽管这一类别在两年前被引入市场，但它正在迅速成熟。在评估四种云安全解决方案时，SSPM的平均评分为“有些熟悉”此外，62%的受访者表示，他们已经在使用SSPM或计划在未来24个月内实施SSPM。
图9：当前使用或计划使用SSPM的公司
结论
《2022年SaaS安全调查报告》深入了解了企业如何使用和保护其SaaS应用程序。毫无疑问，随着公司继续采用更多业务关键型SaaS应用程序，风险也越来越大。要正面面对这一挑战，公司应开始通过两种最佳做法来确保自己的安全：
首先是使安全团队能够全面了解所有SaaS应用程序安全设置，包括第三方应用程序访问和用户权限，这反过来又允许各部门保持其访问权限，而不会有做出不当更改的风险，从而使组织易受攻击。
其次，公司应该利用自动化工具，如SSPM，持续监控并快速纠正SaaS安全错误配置。这些自动化工具使安全团队能够近实时地识别和修复问题，减少组织易受攻击的总时间，或防止问题一起发生。
这两项更改都为其安全团队提供了支持，同时不会阻止各部门继续其工作。
