在2019冠状病毒病(COVID-19)大流行最严重期间，组织实施的混合工作模式促使许多澳门赌场官方下载加速转向基于云的服务，以提高弹性和效率. 在其不断发展的过程中, 软件即服务(SaaS)为组织提供了有效管理所需的工具, 沟通, 和协作, 无论组织或其员工在哪里. 此外, 它不需要客户在物理基础设施上投资, 平台管理, 打补丁, 或监视. 然而, 对于SaaS客户和提供商来说，这些好处与显著的风险因素和挑战相关.
SaaS客户挑战
云计算不再被认为是一种新兴的颠覆性技术, 而是一种主流趋势，多年来已经变得更加成熟. 然而，新的基于云的服务，如SaaS，由于其众多的好处而蓬勃发展. SaaS是一种软件分发模型，其中提供商负责托管应用程序并提供安全性, 开发和维护客户. 采用SaaS对于澳门赌场官方下载的成功已经变得越来越重要, 尽管它要求组织释放对数据的一些控制, 应用程序管理和定制. 因此, 黑客关注的焦点已经从一般意义上的云转移到驻留在云和云中的新兴工具和技术上, 更具体地说, 在SaaS. 因此，SaaS客户面临着几个显著的挑战.
数据丢失
在使用SaaS时，组织对其数据的控制和可见性较少. 因此，数据意外删除或泄露的风险较大. 如果这种风险成为现实, 它可能导致敏感数据的永久丢失，通常会引发严重的财务问题, 法律和声誉影响. 成本可能包括补偿受影响的员工或客户, 执行事件响应计划, 从备份中恢复数据, 调查数据泄露事件, 投资新的安全措施, 重获客户信任, 支付法律费用, 包括对不遵守欧盟通用数据保护条例(GDPR)的罚款. 违反GDPR的组织将被处以高达其全球年营业额4%或2000万欧元的罚款, 取较大的.1 在所有情况下, 敏感数据泄露, 无论是有意还是无意, 受影响的个人可以采取法律行动要求赔偿. 在某些情况下，数据丢失的后果可能会威胁到组织的生存. 像这样, SaaS提供商必须识别相关威胁并减少其攻击面.
未经授权的访问
当使用SaaS时，组织面临用户帐户接管的风险增加. 这种风险部分与SaaS暴露在互联网上有关. 地理限制在SaaS服务中并不常见, 使暴力破解和其他基于凭证的攻击可以从任何地方发起. 攻击者也有机会访问通过暗网获得的用户凭证，并使用这些凭证进行账户接管. 身份验证和授权是SaaS应用程序安全性的关键方面. 改进身份和访问管理, 组织应该评估将SaaS平台集成到其澳门赌场官方下载单点登录(SSO)解决方案中的可能性，并实施多因素身份验证(MFA)。. SSO也是一种有效的方法，可以对SaaS工具进行编目，并提供对其使用情况的详细了解.
不安全的应用程序编程接口
一些SaaS工具的应用程序编程接口(api)可能缺乏适当的基于角色的访问控制机制，并且存在可利用的漏洞. 不安全或缺少访问控制机制以及API端点中的漏洞会导致对敏感数据的未经授权访问. 为了降低这种风险, 组织必须按照最佳实践保护其通信端点, 包括漏洞管理和限制API访问, 基于需要知道和最少特权原则.
它的影子
影子IT指的是系统, 设备, 应用程序, 以及员工或部门在不知情的情况下访问和使用的服务, 明确的批准, 或对IT的监督, 信息安全, 以及法律团队. SaaS服务的消费化是影子IT的主要驱动力. 具有Internet访问权限的用户可以轻松获取和使用SaaS工具. 组织部门, 包括法律, 采购, IT, 信息安全, 隐私团队通常没有机会在使用SaaS工具之前对其进行审查. 从遵从性和安全性的角度来看，这种方法使组织容易遭受巨大的风险, 包括数据暴露, 恶意软件和生产力损失. 因此, 组织应该采用有效的技术解决方案，防止安装和使用未经批准的SaaS工具，以缩小合规性和安全风险方面的差距.
脆弱性管理
客户组织要执行有效的漏洞管理，就得听凭SaaS提供商的摆布. 即使SaaS工具中的一个漏洞也为攻击者提供了访问组织数据的入口点.
即使SaaS工具中的一个漏洞也为攻击者提供了访问组织数据的入口点.
为了进行适当的漏洞管理，SaaS提供商必须执行一些尽职调查活动, 包括:
- 为开发人员和其他IT人员实施安全培训，以减少新的安全缺陷的数量
- 在开发生命周期的早期引入安全性，以在设计上确保安全性和私密性
- 制定一个全面和持续的漏洞管理计划来识别, 评估, 报告漏洞并确定其优先级
- 定义安全度量来识别和可视化漏洞趋势
- 及时解决已发现的漏洞
第三方风险管理
在组织的内部操作和流程中涉及第三方供应商会带来安全风险. 因此, 组织必须实施第三方评估程序来评估和监控第三方风险. 第三方安全评估问卷是一个强大的工具，旨在帮助组织收集有关第三方的数据和其他相关安全信息, 最好是在建立业务关系之前. 然而, 许多SaaS提供商不愿意回答关于他们当前安全状况的冗长问卷. 而不是, 他们可能会分享他们的SOC审核报告和国际标准化组织(ISO)认证, 它们提供了一些关于供应商安全状态的信息, 但缺乏必要的细节，如业务连续性或灾难恢复计划的有效性, 采用的加密协议, 数据备份计划, 安全软件开发生命周期(SDLC)等等. 使用SaaS服务的组织通常必须满足于比内部管理的应用程序可用的更不详细的风险信息. 这导致SaaS客户无法彻底了解SaaS环境和整个组织中的风险.
风险缓解
SaaS提供商不太可能改变他们的环境和业务流程来满足单个客户的需求和标准. 这种方法让客户去寻找其他管理风险的方法. 在SaaS提供商中识别的风险通常必须通过客户组织中的补偿控制来减轻, 如:
- 将SaaS平台集成到组织的SSO解决方案中，并为所有登录执行MFA
- 实现基于角色的访问控制(RBAC)机制(如果平台支持)
- 在SaaS平台之外存储数据备份
- 定期对员工进行安全培训
- 限制对用于与SaaS提供商交换数据的公司api的访问
事件的可见性
SaaS提供商不太可能将基础设施和应用程序级别的安全事件日志发送给客户的安全信息和事件管理(SIEM)解决方案, 导致客户的安全运营团队缺乏重要信息. 这降低了识别和管理潜在安全事件的能力. 例如, 很难知道是否以及何时针对SaaS客户用户帐户实施了暴力破解密码重放攻击. 此类攻击可能导致未被发现的数据泄露, 导致组织被认为对数据泄露负有责任，并且没有将事件报告给适当的各方(例如).g.(员工、客户、主管部门).
风险文化
对于客户来说，理解SaaS提供商风险文化的基本性质可能是一项挑战. 审计, 认证, 调查问卷, 而其他材料则描绘了供应商安全状况的狭隘图景. 此外, SaaS提供商不太可能与客户分享他们的风险记录, 因为这会暴露SaaS提供商安全状况的过多细节. 此外，由于资源有限，SaaS提供商不太可能进行详细的客户审计. 尽管有外部审计和完成的调查问卷, SaaS提供商的风险文化通常是一个封闭的书.
共同责任
一些SaaS客户对客户和提供者之间的责任共享模型缺乏基本的理解. 并非所有SAAS提供商都发布共享责任矩阵, 补充用户实体控件(CUEC)或其他有用的工件. 而一些SaaS提供商与他们的客户共享CUEC信息或共享责任信息, 许多人没有, 让客户自己判断关键责任在哪里. 如果供应商传达的责任模型不够清晰, 在签订合同之前，客户组织与供应商联系并明确同意此事是至关重要的. 缺乏CUEC和其他信息, SaaS客户必须进行详细的风险分析，以识别和逆向工程责任矩阵.
第四方数据访问
SaaS解决方案的一个常见副作用是与其他外部方共享数据. 特定的第四方访问可能是合法和必要的. 然而, 在许多情况下，第四方访问是由于配置错误或粗心或意外的数据访问造成的, 使组织暴露于大规模的数据泄露. 因此, 组织必须采用零信任方法，并持续监控集成到其SaaS环境中的所有第四方应用程序. 作为他们评估的一部分, 组织应该要求供应商指定他们外包的服务，并确定所涉及的第四方. SaaS提供商通常不愿意提供有关其第三方的信息, 导致更多围绕风险的模糊性.
灾难恢复
单个SaaS提供商的弹性在很大程度上是不可预测的. 一些SaaS提供商可能拥有高质量的服务, 经过测试的业务连续性和灾难恢复计划, 而其他人可能不会. 再一次。, SaaS提供商通常不提供这些细节, 让客户对其关键SaaS提供商的弹性一无所知.
SaaS提供商面临的挑战
许多SaaS平台存储了几乎可以从任何设备访问的大量个人数据, 将关键数据置于危险之中. 因此, SaaS提供商在满足客户期望和保持交付产品和服务的效率方面面临着独特的挑战.
的证明
SaaS提供商需要在外部证明与获得它们的成本和时间之间找到适当的平衡. 客户通常对提供商的关键信息安全和隐私控制(如访问管理)的有效性感兴趣, 变更管理, 系统开发, 备份管理, 加密, 物理安全, 员工资格及培训, 以及业务连续性管理/灾难恢复计划. 彻底和高效的SaaS提供商识别并提交证明(例如.g.(SOC 1、SOC 2、ISO认证)对客户最有意义的认证.
安全程序细节的披露
SaaS提供商经常面临的挑战是，如何在向客户透露太少和太多的信息之间找到适当的平衡.e.(安全策略、程序、标准、业务连续性计划、控制和风险). 共享过多的信息可能会使攻击者危及SaaS环境. 另一方面, sharing too little information may not be enough for customers to assess the security posture of the provider; consequently, 他们可能不想建立业务关系. SaaS提供商应该执行风险评估, 客户请求的基准和成本效益分析，以定义信息共享的适当平衡.
效率与安全
SaaS提供商一直在努力实现经济扩展和减轻与多租户环境相关的风险因素之间的适当平衡. 正确地实现多租户可能很复杂，而且成本很高. 一些SaaS组织的高级管理层可能不完全支持多层控制的实现，以防止跨客户数据泄漏. 获得高级管理层的支持, SaaS提供商需要对其环境进行详细的风险分析，以量化最主要的风险因素. 如果高级管理层不听, 可能有必要引入外部专家来识别和解释最主要的风险因素.
可配置性
SaaS提供商必须开发一个健壮的平台，为客户提供丰富的可配置性和灵活性, 以减少未来对定制的需求. 定制会增加复杂性, 这使得确保SaaS平台中没有可利用的缺陷变得更具挑战性.
定制会增加复杂性, 这使得确保SaaS平台中没有可利用的缺陷变得更具挑战性.
第三方风险管理
对于在SaaS中存储个人信息或个人身份信息(PII)的组织, 他们的问卷可能包含数百个问题, 特别是当他们使用标准化信息收集(SIG)问卷时. SaaS提供商应该开发一种有效的方法，以避免在通过客户的第三方风险管理程序响应客户请求时提供过多的信息. 一种有效的方法可能包括展示可用的安全证明(例如.g., ISO 27001认证, SOC 1或SOC 2报告)，并响应剩余的请求, 或者准备正式的安全状态声明，并将其提供给客户. 这种方法大大减少了提供者的工作负载，并且缩短了客户的时间，因为他们不必等待很长时间才能从提供者接收基本的安全信息.
共同责任
定义客户和提供商的责任之间的界限对于减少将漏洞引入SaaS基础设施的风险至关重要. SaaS提供商必须定义和概述共享责任模型，并确定哪一方负责个人安全, 隐私, 经营活动, 确保问责及全面保护敏感资料.
结论
随着SaaS模型的不断扩展, 组织必须通过构建健全的SaaS策略来采取必要的安全措施, 发展和更新他们的风险偏好声明, 建立事件响应计划, 并通过结构化的第三方风险管理程序进行彻底的尽职调查，以了解每个供应商的安全状况. 这些活动使组织能够了解其完整的安全状态, 包括与每个SaaS提供商开展业务相关的已知风险. 另一方面, SaaS提供商必须考虑标准化他们的安全流程, 定义明确的责任模型, 对客户保持透明, 并努力不断改善他们的安全状况. 任何不足都会导致存在未被发现的风险.
尾注
1 布朗,R.; “违反欧盟隐私法的罚款飙升七倍，达到1美元.20亿美元，大型科技公司首当其冲CNBC, 2022年1月17日
Ejona prei, CISM, CRISC, ITIL v4
是一名信息安全专家，也是科技和安全行业性别平等和多元化的倡导者. 她是戴姆勒和宝马合资澳门赌场官方下载FREE NOW的首席安全风险经理.
彼得H. 格雷戈里, CISA, CISM, CRISC, CDPSE, CCSK, CISSP, DRCE
是一位职业网络安全和隐私领域的领导者，也是众多网络安全和隐私书籍的作者. 可以联系到他 www.peterhgregory.com.