2024云客户的SaaS治理实践.docx

《2024云客户的SaaS治理实践.docx》由会员分享，可在线阅读，更多相关《2024云客户的SaaS治理实践.docx（62页珍藏版）》请在课桌文档上搜索。

1、云客户SaaS治理实践目录1弓I言71.1 范围71.2 适宜读者82 .概述82.1 方法82.2 结构92.3 SaaS生命周期注意事项93 .信息安全政策113.1 信息安全策略113.2 对信息安全政策的审查304 .信息安全组织304.1 内部组织304.2 移动设备和远程办公335 .资产管理345.1 资产责任346 .访问控制366.1 访问控制的业务需求366.2 用户访问管理366.3 系统和应用访问控制387 .加密和密钥管理417.1 SaaS环境中的数据安全417.2 加密SaaS提供商共享的数据427.3 客户管理加密密钥VS供应商管理加密密钥457.4 加密和密钥

2、管理的未来状态458 .操作安全478.1 操作程序和职责478.2 防止恶意软件488.3 备份和高可用498.4 日志和监控508.5 技术漏洞管理518.6 信息系统审计注意事项529 .网络安全管理539.1 SaaS提供商网络控制539.2 SaaS消费者网络控制5310 .供应商关系5410. 1供应商关系中的信息安全5411 .事件管理5811.1 云安全事件管理5811.2 SaaS事件响应责任和程序5811.3 阶段1:准备59U.4阶段2:检测和分析5911.5 阶段3:遏制、根除和恢复6011.6 阶段4:总结改进6012 .合规性6112 .1遵守安全策略和标准6112

3、.2 遵守法律和合同要求6212.3 信息安全审查6213 .CASB的功能和发展方向6314 .结论6415 .参考文献6516 定义6617 .缩略词671.引言在云安全领域，直以来关注的重点几乎都是对基础设施即服务(IaaS)和平台即服务(PaaS)的保护。虽然组织一般只使用2-3个IaaS提供商，但通常会使用数十到数百个SaaS产品。云客户的SaaS治理最佳实践，是SaaS治理实践的基线集合,列举并考虑了SaaS生命周期评估、采用、使用和终止等所有阶段的风险以及处理。随着SaaS的广泛应用，组织为了应对这种新情况，必须更新网络安全覆盖的领域。组织必须更新内部策略，包括关键事项，如服务级

4、别协议、安全和隐私要求以及运营影响分析等。同时，应考虑组织运营安全活动受到的影响，例如职责和任务分配，以及对移动设备和远程办公的影响。信息是一种资产，在SaaS模式下，涉及到外部服务提供商时，必须考虑信息的分类、标记和存储需求。虽然SaaS提供商在共享责任模型中承担了大部分责任，但SaaS客户仍然主要负责数据治理和访问控制。这意味着需要明确谁在什么场景下，拥有什么级别的权限，访问什么数据，尤其是在零信任架构中。组织仍然涉及对加密密钥管理和安全运营活动(如漏洞管理、备份和存储)的关键决策。组织需要确保将SaaS提供商视为第三方风险管理计划的一部分，并相应更新事件响应和业务连续性计划和流程。这一点

5、越来越重要，因为从业务连续性的角度，SaaS通常基于远程环境提供关键功能。SaaS工作模式下，即使责任共担，组织仍然必须满足法规合规避从性和监管要求，以保护其利益相关者及其声誉，并避免潜在的法律后果。SaaS模式改变了组织处理网络安全问题的方式，在云厂商和云客户之间引入了共同责任模型。如果不进行相应调整，可能会造成严重后果，如泄露敏感数据、收入损失、失去客户信任和违反监管要求等。1. 1范围本文件： 提供套用于保护SaaS环境数据的SaaS治理最佳实践基线 根据SaaS采用和使用的生命周期列举并考虑风险 从SaaS客户的角度提供潜在的缓解措施1.2适宜读者 SaaS客户 SaaS云服务提供商

6、SaaS安全解决方案提供商 云安全专业人员 法务 网络安全主管 IT主管 风险经理 IT审计员和合规人员 第三方风险经理2.概述软件即服务（SaaS）用户和客户应评估并减轻使用SaaS服务所带来的信息安全风险。本文档参考MST800-145,将SaaS定义为“通过使用供应商在云基础设施上运行的应用程序向消费者提供的能力”。在这种情况下，消费者不会管理或控制云基础设施、操作系统、关联的存储，甚至单个应用程序，特定配置或设置除外。虽然组织选择的云计算服务和安全领域在不断发展，但有关SaaS治理和安全的指导并不多。同时，组织中的不同部门偶尔还会更多地利用SaaS服务（也称影子IT）为其关键业务流程和

7、功能提供支持，并经常在SaaS环境中存储敏感数据。2.1 方法SaaS需要不同的安全治理思维。虽然与其他共享责任框架（即IaaS）的治理有一些相似之处，但SaaS部署和管理需要独特的方法。对SaaS进行适当的安全和治理，尽职调查必须从较高的层次开始，即了解SaaS应用程序的使用和功能，并深入到细节，如系统中存储的数据类型以及谁有权访问。考虑到适当管理SaaS应用程序的使用以及可能部署的无数SaaS应用程序的独特复杂性，组织应首先寻求一个适合组织安全、业务和监管需求的框架（如NlSTCSF）o该框架将帮助组织塑造安全架构所需的人员、流程和技术。遵循广泛采用的安全框架（如NlSTCSF）以及本文档

8、中的最佳实践和建议，将有助于组织建立SaaS治理和安全流程，以降低与SaaS使用相关的风险。2.2 结构本文档定义/SaaS安全性的三个必要组件：流程、平台和应用程序。通过将流程安全性、平台安全性和应用程序安全性结合到一个内聚的策略中，可以实现SaaS的集成安全性。流程安全保护程序活动的完整性，确保流程的输入和愉出不容易受到损害。主要涉及管理方面，包括政策和程序，以确保与组织的流程保持一致。平台安全性涉及平台的安全强度，即SaaS服务的基础依赖性。其中包括SaaS基础设施、操作系统及潜在供应商安全。应用程序安全性处理SaaS应用程序本身的安全性。只有当SaaS应用程序不包含可利用的漏洞，并且实

9、现了符合组织和供应商安全最佳实践以及法规遵从性要求的强化要求时，才能保持安全。在SaaS模型中，有限的控制措施和可见性主要局限于流程和应用程序安全组件。SaaS消费者无法控制SaaS应用程序的平台安全组件或底层供应链。这些情况导致SaaS用户需要在其组织内拥有良好的流程安全性，并确保实现应用程序级的安全控制措施。某些部门特定的安全控制措施通常用于满足隐私、政府或财务合规性。例如FedRAMP、NlST80O-53、HlPAA和PCI-DSS。这些需求通常属于垂直领域，适用于三个SaaS安全领域。2.3 SaaS生命周期注意事项如果管理得当，企业环境中SaaS应用程序的采用和使用通常遵循三个关键

10、生命周期：评估、采用和使用。这些生命周期的常见模式如下。很多组织对SaaS的使用快速有序增长，然而在SaaS应用程序监控方面却是落后的。这样的组织在广泛采用SaaS的同时，实施SaaS安全和治理计划，使用生命周期将是至关重要的。2.3.1 评估评估生命周期发生在采购之前，首先确定可由SaaS应用程序解决的业务需求。在许多组织中，这是在业务范围内的，可能涉及也可能不涉及集中采购的组织。评估生命周期通常由4个步骤组成： 了解用户计划使用的服务 市场研究 试点工作 采购决策如果组织做出了购买决策，那么将开始生命周期中的采用阶段，部署SaaS应用程序。虽然理想情况下，相关安全和合规组织的代表会在评估阶

11、段出席，但这些代表必须参与到采用阶段。当组织构建SaaS安全和治理计划时，这些组织“检查点”是安全团队在SaaS生命周期中的关键集成点。2. 3.2采用几乎所有组织的SaaS生命周期采用阶段都是一致的。它跨越了SaaS应用程序以初始形式（有时可能是一个扩展的试点项目）采购到全面部署和使用增长，直到潜在的终止和退役的整个过程。采用生命周期的长短各不相同，对于大型业务关键型SaaS应用程序，实际上可能是一个稳定的状态，但通常由四个步骤组成： 评估：在评估阶段，云消费者评估SaaS应用程序与需求的匹配度。这通常涉及一个试点或概念验证活动，探索特性、功能和满足业务需求的能力。 采用：生命周期的采用阶段

12、是云消费者开始正式采用SaaS产品并超越试点或概念验证的阶段。这可能涉及将更敏感的数据迁移到SaaS应用程序中，以及将SaaS应用程序推广给其他业务部门使用。 常规使用和扩展：可将常规使用和犷展视为维持阶段。此时，消费者通常将SaaS应用程序用于各种业务功能，并有标准的操作程序供其使用。 终止：生命周期的终止阶段表示云消费者决定不再使用SaaS产品。这可能是由于各种原因，如成本、安全性或可能不再满足业务需求。消费者开始关闭SaaS应用程序的使用，减少敏感数据、账户等。3. 3.3使用SaaS使用生命周期有助于防范日常运营风险和安全问题，如最小权限、身份和访问管理。SaaS使用生命周期由四个步骤

13、组成：资格：该个人或非个人实体是否应该成为服务的用户？ 服务开通：需要做什么才能将此人添加到服务中，以及他们的权限是什么？ 监控：此人对SaaS的使用是否符合组织的预期，有无异常使用？ 服务撤销：如何将此人从服务中删除？SaaS使用生命周期描述了组织如何使用CSP和SaaS服务。了解和监控SaaS的整个使用生命周期非常重要。否则很容易将所有精力都集中在优化生命周期的一个阶段，如初始化阶段，而对企业更轻松或更迅速地实现预期结果却没有帮助。4. 信息安全政策SaaS客户应制定SaaS安全战略，并构建反映该战略的安全架构。一个强大的安全架构应该包括指导SaaS应用程序部署和维护的安全策略。4.1 信

14、息安全策略应制定有关管理SaaS服务的评估、采用、使用和终止的政策。请参阅上述常见SaaS生命周期的描述，并确保组织为每个生命周期阶段制定了全面的策略并评估控制措施。4.1.1 评估任何决策都应该以企业架构（architecture）的需求和流程为指导，应符合适宜环境的总体企业架构（评估产品、服务和工具及其解决的需求）.这可以防止不必要的产品、服务和工具重复。如果确定了需求，则可以开始评估产品、服务和工具。SaaS服务的初始评估通常会让业务、法律和安全利益相关者了解交易的风险并进行相应的处理。关键问题是“这是否与我们的风险状况和企业架构匹配？”4.1.1.1 确定可接受风险评估SaaS服务时，

15、第一步是确定哪些风险与客户的风险偏好一致。SaaS应用程序可以托管在私有、混合或公有云环境中，应用程序运行在应用程序级别的专用或共享资源上（单实例、多租户）。与任何云产品、服务或工具一样，必须理解共享责任模型。根据根0/1EC27001,应使用风险管理方法管理信息安全。SaaS客户应首先确定SaaS服务给组织带来的可接受风险，这构成了评估阶段的基线。可以使用不同的方法管理风险，包括国际风险管理标准ISO31000。确立背景（5.3）监测与审杳(56)沟通和协商(52)风险评估（5.4）风险识别（5.4.2）风险分析（54.3）风险评价（5.4.4）风险处理（5.5）厚即脸醐融一球雌如果了解组织

16、的风险状况，SaaS客户应该能够确定SaaS服务与组织风险管理要求的符合度。可以通过了解SaaS服务的使用情境，并考虑以下因素确定SaaS服务的风险状况：数据：业务流程将存储哪些数据或需要将哪些数据提供给SaaS应用程序？直接成本（通知受影响个人的成本、股票下跌时股东的损失、竞争对手的大量涌入导致的客户流失、利润损失）和间接成本（声誉损害和错过的期货销售、网络保险成本增加、关键员工的解雇）是什么，如果存储在此SaaS应用程序中的数据的机密性或完整性受到损害，则会给业务带来隐形成本（引导员工做出响应的成本，违规整改的成本）？流程： 此服务是否会影响核心或关键业务流程？ 如果使用SaaS服务，需要

17、修改哪些组织策略和流程？需求：哪些业务需求、法律和法规与此服务相关？在此阶段，应评估以下方面对SaaS客户风险状况的影响： SaaS提供商 SaaS服务 SaaS提供商的供应商,SaaS服务的使用 SaaS客户对相关SaaS提供商应用持续监控和态势管理以缓解风险的能力最常见的风险分析方法是经典的ClA分类： 保密性 完整性 可用性有了CIA,应用程序和数据库将根据您的要求进行风险评分。一旦建立了风险足迹，您就可以开始计算SaaS应用程序带来的风险。计算风险的方法有很多，开发风险分析框架取决于组织需要和行业类型。虽然可以将风险管理相关的活动转移到CSP（云服务提供商），但是SaaS客户本身并不能

18、将其责任外包给CSP。SaaS客户必须始终记住，风险所有者有责任承担使用SaaS服务的风险。虽然服务提供商和消费者之间有责任分担，并且存在服务级别协议（SLA）之类的协议，但消费者最终仍然拥有风险。3.L1.2安全和隐私要求一旦确定了风险水平基线，许多云服务客户就会参与安全和隐私尽职调查。云服务客户通常会向云提供商发送评估问卷或信息请求（RFI）以供填写。这些调查问卷询问客户希望看到的CSP实施的内部安全控制措施，通常解决有关安全和隐私的监管要求问题。CSASTAR共识评估调查问卷等自我评估计划或第三方评估（如S0C2或FedRAMP）,有助于CSP向潜在客户告知SaaS提供商的安全能力和现有

19、做法。自我评估或第三方报告还询问云提供商使用和披露个人信息的情况，或个人信息将在何处处理。这些项目还询问云提供商是否将信息用于自己的目的或将其披露给第三方（例如，向第三方广告商披露）。注意数据的位置也很重要，因为可能存在数据主权要求。第三方评估的一些关键领域包括： 认证和标准 数据保护 访问控制 可审计性 灾难恢复和业务连续性 法律和隐私 漏洞和漏洞利用3.1.1.3 沟通要求这些问卷或报告中的应答允许客户进一步完善其风险评估，并反馈到云交易的签约阶段。许多云客户为了加强其风险评估和尽职调查流程，并作为供应商管理的一部分，创建了标准的数据安全和隐私计划或条款，并包含在云合同中。这些附表或条款的

20、目的是多方面的，可能会产生严重后果。一个目的是解决监管问题，例如保证数据满足特定地区的监管要求。另一个是创建使云供应商遵守合理的安全标准的机制。这些附表或条款还可以约定事件响应义务，并转移因云供应商造成的数据泄露或隐私侵犯的损失风险。还可以要求在特定时间以特定方式响应数据泄露等问题，包括审计权，以及执行定期监测和控制活动的权利。此外，必须了解CSP和消费者之间执行或管理合同的相关司法管辖区和监管框架。例如：如果您正在寻找一个SaaS平台存储或处理员工或客户Pll（个人可识别信息），并且在GDPR的适用范围，那么需要查看CSP是否存储欧盟/欧洲经济区或提供充分保护的国家的数据。如果没有，您需要了

21、解适用的法律框架，并根据欧盟法院（CJEU）发布的SChremSII判决，确保客户服务提供商有足够的保护和补充技术控制保护数据。总体目标是通过合同与云服务提供商无缝衔接，并尽可能降低客户的风险。供应商管理计划中的签约流程有时会进一步细化，允许客户在与云服务提供商谈判期间针对某些条款预先建立“后备”措施。这可能包括在终止合同时如何传输数据和其他事项（例如，防止供应商锁定）。客户的法务团队和安全团队通常都会参与这些条款的谈判。3.1.1.4 内审客户应制定SaaS安全战略，并构建反映该战略的安全架构。SaaS客户应该记住他们负责的云共享责任模型的部分。也就是说，SaaS客户最终负责SaaS平台在设

22、计限制内（即客户权限和责任范围内）的安全配置、管理和使用。威胁建模和威胁分析是开发SaaS安全策略的关键。云安全联盟发布了云威胁建模,“提供关键指导，帮助确定威胁建模安全目标，设定评估范围，分解系统，识别威胁，识别设计漏洞，制定缓解和控制措施，以及措施的实施和沟通”。SaaS客户为了应对使用SaaS平台的有效风险管理和安全控制要求，应制定一个多管齐下的安全战略，该战略适用于在此过程早期确定的SaaS应用程序的风险级别和分类。该策略可能包括以下要素： 了解可应用于SaaS平台的云客户适用的安全控制措施和配置（SSO、MFA,角色分配、团队/组隔离、导出日志或与安全监控解决方案集成、IP限制等），

23、并加以应用 定期审查SaaS的使用情况和适用性 针对在SaaS应用程序或平台之外管理或部署的业务逻辑或流程进行渗透测试 对SaaS应用程序的配置进行持续的安全态势监控，并与组织特定的已批准/预期配置比较 持续监控SaaS应用程序生成的审计、事件或其他更改/活动Fl志，理想的情况是能够将这些日志与其他SaaS和非SaaS应用程序关联 持续监控对SaaS应用程序中关键数据和/或流程的访问3.1.1.5 服务条款未能就事件响应以及安全和法律评估权进行强有力的谈判也可能带来风险。如果SaaS提供商违约并且影响到客户，但没有履行合同约定的违约通知和补救义务，则SaaS客户可能无法降低其法律风险并遵守监管

24、义务。不同区域的法律和通知义务可能也有所不同；因此，在采购和合同阶段聘请专业的网络律师非常重要。要考虑的合同控制：服务级别管理 服务提供商SLA与组织的SLA要求（应解决资源和支持方面的问题） 业务连续性承诺：组织的RP0、RTO与MTPD 事件处理和升级备份的可用性法律问题 法律和监管要求 CSP和SaaS服务的管辖权、法律要求 赔偿：管辖权迁移、并购通知：安全、隐私、法规遵从性变更和事件终止权利和流程 数据可移植性（如果要迁移到其他平台，则需要考虑数据导出问题） 数据删除、时间表和成功删除的书面通知 外包协议终止时的退出策略3.1.1.6 受影响的数据使用云的一个重大风险是，失去对已传输到

25、云的数据的绝对控制，以及外包给云的网络可用性。例如，在更传统的IT环境中，组织有能力评估和调整其系统，使其符合适用的法规和标准。这可能包括基于组织或其客户所在地的数据驻留要求。由于许多SaaS提供商使用位于多个司法管辖区的基础设施服务，因此在不考虑这些要求的情况下使用SaaS服务可能会增加法规遵从性风险。SaaS客户应该能够回答以下问题： SaaS提供商在哪些司法管辖区运营？ 适用哪些监管要求？ 哪些数据将传输到SaaS服务？ SaaS服务可以访问哪些数据？ 对SaaS服务的数据依赖程度如何？ 服务提供商的法律义务是什么？例如，支付提供商为了遵守反洗钱（AML）要求需要根据法律义务保留一些数据

26、。 如果政府或军事实体请求访问数据，SaaS提供商会怎么做？例如，如果SaaS应用程序中只存储非敏感数据，而不是敏感数据（例如社会保障号码或金融账户数据），则可能需要较少的供应商审查。控制措施： 保密要求取决于数据价值 数据分类要求（如HlPAA、PCD 数据和元数据控制：所有权、处理、许可 数据位置和主权 可用性要求和数据迁移3.1.1.7 隐私在使用SaaS提供商时，客户必须确保他们了解在该提供商中存储的数据对隐私合规的影响。SaaS客户应该了解供应商是否允许使用他们存储在SaaS应用程序中的数据（例如机器学习、匿名数据集评估等）。如果允许使用，则需要满足SaaS客户的监管和审计要求。不断

27、变化的监管环境本身增加了与隐私相关的法规遵从性或数据驻留违规的风险，使一些客户和某些类型数据的SaaS应用程序的部署变得复杂。国外对美国SaaS提供商存储欧洲公民数据的担忧增加了这种潜在风险。控制：SaaS客户的角色与SaaS服务的角色？控制者（客户或员工的PII）处理者（控制者提供的PIl） 隐私政策：SaaS提供商对其服务数据的权利 违约义务和责任 PH数据清单、可见性 数据主体的“同意”管理3.1.1.8 进行详细风险评估的步骤1 .识别资产2 .识别威胁3 .识别脆弱性4 .制定衡量标准5 .考虑历史漏洞数据6 .计算成本7 .执行风险到资产的动态跟踪3.1.1.9 识别风险识别可能阻

28、碍业务目标的风险领域： 数据、财务信息、知识产权/竞争优势的丢失 监管和法律规定 企业声誉 威胁、漏洞、攻击 事件管理 技术复杂性：人员专业知识财务承诺 第三方供应商 第三方审计、S0C2报告、STAR注册表等 人为失误3.1.1.10 评估风险 定性/定量风险评估 治理风除合规性(GRC) 风险容忍度/偏好3.1.1.11 管理风险 根据风险容忍度实施物理、技术、管理控制措施 将风险转移给第三方 接受风险3.1.1.12 检查监管 内部、外部审计 风险分析要识别风险，必须对SaaS服务和CSP进行详细的风险评估公司资产在上云之前，应进行风险评估。风险评估的详细程度将因环境而异。例如，客户可能

29、会决定在一个有限的用例（即沙箱、开发软件、测试CSP功能、控制等）下开始使用CSP。在这种情况下,可以进行“最小风险评估”。如果CSP的工具和特性满足CSC的业务目标，那么应该在应用正式上线之前进行更详细的风险评估。在决定进行SaaS风险评估时，应该仔细检查三个方面：a）SaaS提供商；b）SaaS提供商的管理实践：C）SaaS应用程序的技术安全考虑事项。此表列出了需要考虑的值得关注的问题。供应商实践应用程序CSP拥有哪些认证文件？CSP采用哪些控制措施从逻辑上限制进出不同区域的数据？应用程序/特权账户是否被集中管理（例如，通过IAM、RBAC或账户管理工具CSP是否经过第三方评估或审计？CS

30、P是否可以提供SOCII类（时间段）报告（或同等类型的报告）？CSP提供了哪些备份/恢复服务（例如，应用程序、数据、虚拟机）？是否存在安全通道（例如，用于口令、证书、数据的安全传输）？CSC数据是否与CSP起存储在本地，或者CSP是否与第三方供应商签订了合同（用于基础设施托管服务）？CSP的突发事件管理流程是什么？事件如何分类？是否使用SS0SAMLMFA进行安全认证？供应商实践应用程序在故障排除、维护等方面，CSC可获得何种程度的支援？虚拟机镜像、服务器和数据库是否定期打补丁?CSP的防病毒管理流程是什么？应用程序/存储账户是否面向公众（开放权限）？CSP的SLA/OLA是什么？如何管理、存

31、储加密密钥等?谁有访问权限？应用程序/软件是否获得了云许可？CSP是否提供了支持SaaS的所有第三方供应商列表？如果是，CSP是否进行背景调查并签署保密协议？为客户提供了哪些日志记录工具？SIEM事件威胁检测工具？软件/数据是否符合任何监管/隐私要求？CSP能够遵守哪些标准和监管要求？CSP基于什么标准（即ISO、NIST、CIS、PCI、HlPAA、GDPR）进行基线控制？CSP提供了哪些IDS/IPS工具？应用程序的开发/维护需要哪些软件开发过程/工具（如DevSecOps%GitHub.、SDLC）?CSP使用了哪些工具/应用程序来支持此项工作？CSP的底层架构是利用行业最佳实践或标准来

32、设计或开发的吗？CSP是否提供虚拟机加固后的镜像?它们是如何管理/执行的？支持此应用程序需要哪些API?CSP能提供哪些帮助？CSP是否利用/提供云资源的自动化工具、脚本（如vm、IaC.自动修复）？CSP是否提供控制措施以防止未经授权的数据泄露？CSP是否支持应用程序的脆弱性/渗透测试（如有必要）？需要说明的是，上述风险评估具体针对的是SaaS提供商及其SaaS应用程序的底层架构和实现的安全性。它不能替代对SaaS客户实施和使用SaaS应用程序的持续安全监控和风险审查。为了正确地管理SaaS风险，必须通过不同的视角来理解和看待。只有这样，才能在一定程度上保证SaaS风险己经得到适当的识别、评

33、估和缓解。风险评估不应被视为“一次性完成”的工作。云风险不是固定的，因此应该定期评估，并且当有重大变化时也要评估。SaaS客户需要了解他们的解决方案的需求，然后确保SaaS提供商能够理解并满足这些需求。假设SaaS提供商无法满足客户的需求，SaaS客户有责任采取补偿措施缩小差距或选择不使用相关提供商的服务。3.1.1.13 云提供商审查最佳实践 将第三方技术服务视为组织中的一种资产 建立一种基于风险的第三方评估方法 根据整个组织的关键利益相关者的要求制定第三方评估 确保业务负责人参与 定期审查风险最高的供应商 发布授权供应商/应用程序列表 在没有商业理由和批准的情况下，要求仅使用认可的供应商/

34、应用程序 考虑在整个组织中使用预先批准的供应商 鼓励或强制使用合规的供应商3.1.1.14 制定政策和程序为了安全地部署和使用SaaS应用程序，SaaS客户必须制定内部策略和流程，以持续评估和监控其SaaS应用程序的实施和使用情况。如本节前面所述，定期对SaaS提供商的技术、实践和认证进行风险审查和评估；对于SaaS客户来说，针对配置和SaaS应用程序的实际使用情况制定监控和评估方法同样重要，甚至更为重要。这些政策至少应包括： 账户管理程序 集中式身份管理程序 数据和系统访问要求，例如：批准重要访问的授权，并要求对这些账户进行进一步的身份验证 针对服务滥用的可接受使用政策 在业务流程上下文中集

35、成用户生命周期 数据分类和标签 集成到现有的服务水平、事件管理和漏洞管理流程中 与现有的管理机制集成、按要求创建和提升，即变更控制与其他安全计划一样，不能把对SaaS应用配置、数据分类和数据访问的监控看作一次性的事情。SaaS比其他云技术的迭代更新更加快速，并且可以快速重新配置。SaaS客户管理员只需一个不经意的命令或按钮点击，就可以大大改变SaaS应用的安全态势，这进一步强调了对持续监控计划的需求。3.1.1.15 配置和安全态势管理必须对关键SaaS应用程序（根据系统中存储的数据的敏感性，或如果受到损害，可能造成的业务中断）进行持续监控。这种监控能力，最好是自动化的，应该经常运行，并能够在

36、重大变更后临时运行；理想情况下，它们还应该能够在沙箱或预生产环境中运行，以便在生产SaaS环境中运行之前验证配置更改。SaaS客户对关键SaaS应用程序的态势管理至少应该考虑：系统设置的配置基线，特别是与以下内容相关的设置： 身份 身份验证和系统访问，包括MFA、SSo和地理位置或IP限制 密码策略 会话控制 平台提供的数据防泄露和审计功能 平台提供的加密和自带密钥功能已安装和批准的第三方插件、集成以及OAUth或与其他云之间的连接 将用户分配给SaaS应用程序中的角色、配置文件、组、团队和SaaS应用程序中可以授予额外访问权限或功能的任何实体 配置访问授权元素和对用户的有效访问 可能显示敏感

37、或特权操作的管理操作和授权日志 跨关键SaaS应用程序或环境的操作相关性 用户对关键类型的数据或记录的访问，以及确定读取（机密性）和写入（完整性） 离职程序本节中的配置管理指的是配置控制。在NIST800-53,CM-2中规定，“基线配置作为未来构建、发布或系统变更的基础，包括安全和隐私控制实现、操作过程、关于系统组件的信息、网络拓扑结构和组件在系统架构中的逻辑位置。”维护基线配置需要在组织系统变化时创建新的基线。系统的基线配置反映了当前的企业架构。”云的好处之一是促进了软件开发人员快速开发新功能、应用程序和服务。在目前主要SaaS应用程序中，通常包括创建和部署控制关键业务流程的少量或无代码应

38、用程序。具有权限的用户可以快速部署和调整这些集成、工作流和应用程序。因此，这些权限对业务的潜在影响甚至更大，能够监控和提醒这些功能的错误配置或使用是很重要的。此外，SaaS应用程序的快速配置能力和许多SaaS平台上云应用程序市场的普及，可以允许用户使用第三方（不是由SaaS客户或SaaS提供商开发的）应用程序快速扩展SaaS平台。虽然SaaS应用程序功能强大，但也会引入供应商风险评估和采购程序中的漏洞。因此，安全组织必须具备监控和告警功能，用于检测第三方应用程序与已批准的SaaS平台的未经授权的连接，这一点至关重要。举一个例子，需要将营销自动化平台（MAP）与客户关系管理平台（CRM）集成，从

39、而将MAP数据提供给CRM。在此场景中，需要考虑并跟踪数据流动的位置，是从MAP到CRM?还是从CRM到MAP?在这种情况下，数据流将是从MAP到CRM。然后需要检查CRM是否有预先审核过的市场集成。通常情况下，市场集成更安全。在此之后，将检查最佳实践指南，或者联系支持人员以获得那些最佳实践（如果无法自助获取的话）。最后，需要分析如何确保最少特权并遵守数据最小化原则。此外，理解如何删除连接也是必要的。再看另一个示例，用户将其谷歌账户与第三方应用程序集成。用户主要查看第三方应用程序将获得哪些权限和范围，以及应用程序能够代表用户执行哪些操作，然后根据组织的风险偏好做出判断，用户可能需要在这方面获得

40、安全专家的支持，还可能想知道如何撤销第三方访问权限。在开发安全态势管理策略和规则时，SaaS客户可以利用行业最佳实践（例如:微软365的ClS基准）,与制定了基线安全策略的SaaS安全态势管理供应商合作，或者在内部努力确定适合组织的最佳实践和需求。通常，可以将这些方式结合起来制定最全面的政策。3.1.1.16 数据安全SaaS客户应该监控存储在SaaS应用程序中的敏感数据的访问，其方式与监控系统配置和安全状况类似。同样，由于SaaS应用程序固有的灵活性和可配置性，用户对数据的访问可能会快速变化。因此，与SaaS安全监控的其他部分一样，关键是将对数据的监控访问视为一个连续的过程，而不是一个时间点

41、的操作。作为任数据安全和访问监控解决方案的部分，SaaS客户都应该定期（或使用自动化平台特性）对数据按敏感级别、数据类型等进行分类。这种分类，无论是在外部系统中维护还是在SaaS平台本身上维护，对于设计数据安全策略并根据该策略监控实际状态至关重要。关于数据安全的其他注意事项，可能可以作为安全态势监测的一部分进行监测，但仍应明确定义，包括： 配置（和用户访问）数据导出功能和数据备份功能 资产、所有权和责任清单 限制内部和外部共享和监控系统配置以匹配安全策略 密码控制和要求，并对系统进行监控，以确保其配置符合预期另一类可以应用于SaaS应用程序的安全解决方案是数据防泄露（DLP）解决方案。DLP解

42、决方案通常与数据的访问路径一致，或者作为内置的SaaS应用程序功能，DLP提供更高级别的信息保护。DLP可以防止某些类型的文件的转移或泄露。DLP解决方案也与数据分类有关系。首先，需要对数据和文档进行分类，以便DLP解决方案能够理解分类并进行相应的监控（例如，PU.PCDoDLP运行主要基于关键字、短语和元数据。在DLP逻辑匹配时，它可以执行一个或多个操作，如通知用户、提醒管理员、阻止传输、删除附件和文档、编辑敏感数据，并保留数据副本以供检查/取证目的。SaaS提供商通常为其客户提供自动化处理的机制或APL当使用大量SaaS系统时，客户将选择与SaaS平台集成的DLP解决方案，以实现无缝管理。

43、3.1.1.17 用户意识和培训 为安全使用此服务制定最佳实践指南 强制执行数据分类和标记 用户了解此服务的安全事件并知道如何报告它们 在可行的情况下添加指导策略（例如，用户得到访问某个类别的授权服务的提示，或者记录使用替代选项的理由） 为坦诚的报告事件营造良好氛围3.1.1.18 内部威胁 离职员工可以将SaaS数据分享给他们的个人账户，导致公司数据的泄露 员工在内部过度暴露敏感数据（财务和工程可以相互使用彼此的信息） 敏感数据分享给错误的第三方 未落实职责分离 平台配置不当导致数据泄露（例如，包含敏感数据的S3存储桶被公开暴露） 员工允许从系统中获取大量数据，这可能会导致他们在辞职时泄露或

44、带走这些数据3.1.1.19 外部威胁 第三方合作者可以永远访问你的公司数据 您的供应商与他们的供应商共享公司数据，这些供应商从未通过第三方风险评估 使用公司数据的第三方合作者使用个人账户，而且通常没有设置多因素身份验证 第三方供应商或其分包商/供应商不受监管实体保护数据的约束3.1.2用法 可接受使用政策 管理 治理3.1.2.1 定期检查服务/供应商 监控存档版本发生变更的服务条款和条件 安全保证的有效性 持续的安全性能 CSP供应商管理具有挑战性3.1.2.2 告警 监控可疑的登录和数据访问 监控服务的使用情况和滥用情况 监控SLA符合性 监控登录和访问中的任何异常 监控任何有风险的组织

45、范围内的设置变化 监控异常数据访问服务条款和条件可能会随时发生变化，导致失去控制。因此，需要使用自动化工具持续监控服务的属性。很有必要监控配置更改并告警。3.1.2.3 使用情况可见性 带有登录用户名和用户位置的身份验证日志 访问日志 审计日志 账户配置和撤消配置日志3.1.2.4 持续评估并减少攻击面 监控服务的基本属性，进行完整性检查 审查控制以减少攻击向量 监控潜在的内部故障点3.1.2.5 配置管理监控配置更改，并在必要时发出告警3.1.2.6 数据 监控对敏感数据、系统和字段的访问 监控管理行为 启用审计 监控备份的有效性确保执行数据备份，更重要的是，通过备份还原来测试备份数据的可用

46、性。3.L3终止SaaS使用的终止需要统筹和有计划的执行SaaS服务最重要但经常被忽视的风险之一在于CSP提供的合同传统上，组织与法律部门合作，协商服务提供商的合同条款，使其不那么“对供应商友好”，并通过让服务提供商承担财务责任减轻由服务提供商造成的任何损失。但云提供商不愿意提供通常的赔偿、责任限制或其他条款，尤其是与隐私和数据安全有关的条款。CSP提出的最普遍的理由是，这些额外的责任和义务会威胁到价格较低的云计算模式，而且，由于CSP不知道他们的客户在云上存储了什么，他们不需要承担隔离和保护客户数据的责任。然而，CSP必须为客户提供实现这一目标的方法。云协议中的不利条款可能会增加云客户的风险。云客户还可能希望通过合同来限制CSP用于存储或处理客户数据的分包商。如果没有这些限制，客户可能会发现它的数据实际上是从主CSP中流