为什么需要SaaS治理计划
转载自 云计算D1net 原创 Chris Hughes
已经授权和未授权的SaaS解决方案的广泛应用带来了重大的安全风险。现在是企业制定管理这些风险的策略的时候了。
SaaS的采用量如今远远超过IaaS。尽管如此,很多企业通常只专注于基础设施安全。他们还应该考虑SaaS治理计划,实施安全措施,以降低与SaaS使用相关的风险。该计划包括合规性框架、文件/尽职调查以及持续监测和降低风险的技术措施。
围绕云采用的大部分安全讨论都集中在IaaS和PaaS提供商上,例如AWS、Microsoft Azure和Google Cloud等公司,这是有充分理由的。很多企业经历了IaaS采用的巨大增长,并看到了大量与IaaS错误配置相关的安全漏洞事件。
然而,SaaS实施不力和安全性差所带来的风险却被忽视了。根据调研机构Gartner公司的预测,SaaS仍将是最大的公有云细分市场,该预测是在新冠疫情发生之前做出,这表明已经出现了前所未有的SaaS发展热潮。此外,企业通常倾向于仅使用少数IaaS提供商的产品,例如三大云计算服务提供商(CSP),同时还使用更多SaaS产品。Blissfully公司在2020年进行的一项研究发现,大型企业使用多达288种不同的SaaS应用程序,中小型企业(SMB)使用的应用程序超过100种。
虽然一些企业可能开始完善其IaaS安全性,但对于更广泛和多样化的SaaS环境而言,情况可能并非如此。这一现实也使得SaaS提供商的影子IT使用情况比IaaS提供商更普遍,因为市场上有大量SaaS产品,而且可以轻松地使用它们,通常只需支付费用就可以实施。
Zylo公司进行的一项研究发现,企业平均每月添加了10种SaaS产品,而IT团队仅能直接管理其中的25%。这意味着没有进行管理的SaaS产品将面临很多风险。尽管SaaS使用量呈指数级增长,但AppOmni公司的一项研究发现,只有32%的受访者使用工具来确保SaaS中的数据安全。
尽管SaaS被广泛采用,但为什么企业仍然几乎只关注IaaS安全问题?其中一些原因是由于误解了责任共担模型并假设在SaaS环境中云计算服务商负责所有事情。另一个原因是,安全团队只是在努力跟上企业的云计算使用率以及广泛的高调IaaS数据泄露的影响。
主要的IaaS供应商提供明确的认证和学习路径,确保专业人士可以学习如何保护他们的平台并证明这一点。而SaaS供应商并不提供相同的服务。作为安全专业人员,必须继续发展,直到SaaS产品的安全发展成熟,可以开始缓解未解决的风险。
管理SaaS风险的方法
为SaaS使用实施安全性应该是数据驱动的。这意味着要查看SaaS产品可以访问的内部数据、企业内部的访问级别,以及如果这些数据被无意中暴露或恶意泄露,可能产生的安全和监管后果。这对于在家远程工作的员工来说尤其如此,因为他们可以通过自己的设备从任何地方访问数据。
该流程的第一步是捕获企业员工正在使用的SaaS。根据企业的成熟度和技术架构,这可能是人工实施的库存管理流程,也可能需要云访问安全代理(CASB)等技术工具,这有助于识别影子SaaS的使用。
当企业开始对其SaaS使用进行严格的安全检查时,他们往往会采取两种方法:一种侧重于安全框架,如SOC2、PCI和FedRAMP以及文档审查。另一种侧重于技术评估、强化和持续监控。
框架、文档和报告
当企业开始为其审查SaaS产品时(最好是在购买和实施之前),它往往会涉及流行的框架,例如SOC2、CSACCM和STAR/CAIQ或FedRAMP。
SOC2越来越成为SaaS提供商的主要选择,因为它有助于验证企业与安全性、可用性、机密性、完整性和隐私相关的内部控制。另一个主要的选择是云安全联盟(CSA)的共识评估倡议问卷(CAIQ),它记录了XaaS产品中存在哪些控制措施,并与云安全联盟(CSA)的云控制矩阵(CCM)(一种特定于云计算的安全控制框架)相关联。在公共部门方面,美国联邦风险和授权管理计划(FedRAMP)被广泛用作授权云计算服务产品(CSO)供政府使用的一种方式,并使用NIST800-53安全控制。
企业通常会这样做,并且应该要求获得这些认证,因为它们通常包括第三方评估组织(3PAO)流程,其中第三方验证SaaS组织及其产品是否满足特定级别的安全要求。这为企业提供了一定程度的保证,即SaaS产品并非完全不安全,并且企业正在围绕其自己的基础设施以及如何处理和存储客户数据实施基本的安全措施。
选择使用哪种框架在很大程度上取决于企业运营所在的行业以及SaaS供应商的成熟度。考虑这些框架可能会耗费大量时间和资源,而初创SaaS供应商通常不会追求认证,直到他们发展成熟,并且客户要求获得认证。还有一个现实是,由于市场上SaaS产品的数量呈指数级增长,一些主要的合规性计划根本没有跟上发展步伐,例如FedRAMP。
如果SaaS供应商没有认证或审核,或者即使他们有认证或审核,并且企业将为他们使用的数据高度敏感,企业可能希望深入了解他们的文档和其他标准,以检查其适用性。这可能包括内部或外部渗透测试的结果,以及围绕架构、身份验证、加密等方面的讨论。这些附加活动有助于为企业提供与使用特定SaaS产品的风险相关的保证级别。
SaaS覆盖范围/功能
虽然框架在审查SaaS产品方面是一个很好的开端,但它只是一个开始。企业还应该考虑技术控制、配置和监控作为SaaS治理策略的一部分。每个SaaS产品都有很多独特的功能、配置和设置,从安全角度来看,企业员工并不熟悉这些功能、配置和设置。
进入SaaS安全状况管理(SSPM)工具,该工具可监控企业的SaaS应用程序的安全状况。AppOmni和Obsidian是最流行的一些SSPM工具。还有一些供应商提供一些领先的SaaS产品,例如Box、GitHub、Salesforce和Slack。
他们精心设计了安全配置、安全扫描、最佳实践和建议,以帮助企业加强其SaaS使用。其中许多产品尽可能利用行业资源,例如SaaS产品的CIS基准,包括Microsoft 365和Google Workspace,这两者都可能包含敏感数据。
这些强化工作有助于保护企业免受常见的安全问题的影响,例如帐户泄露、不安全的配置、合规性和访问管理。他们还可以帮助进行事件响应。这非常有价值,因为企业的员工可能并不具备采用SaaS应用程序所需的特定安全洞察力和专业知识。SSPM供应商不断为其覆盖范围添加更多SaaS产品,并且根据企业的规模,可以帮助制定他们的产品路线图,以涵盖在企业中广泛使用的SaaS。
除了技术安全问题外,企业还必须关注SaaS范式中的合规性。共同责任模型在这里仍然适用。
AppOmni等平台可以帮助自动执行与PCI、HIPAA、GDPR和NIST等广泛适用的框架相关的关键合规性控制。对于企业来说,在可能有数百个SaaS应用程序中保持对这些框架的持续合规性是站不住脚的,而这正是增强这些努力的技术解决方案真正发挥作用的地方。
(来源:企业网D1Net)