培训课程
实现有效的云风险管理
在过去的20年里，云技术已经跃居技术世界的前沿。很难找到没有以某种形式实施云技术的企业。现在的注意力已经转移到如何优化云资源以有效降低风险。由于对云服务提供商 (CSP) 的依赖、复杂的技术、超出客户物理控制的数据驻留以及对客户预期依赖的许多控制缺乏透明度，将数据迁移到云会带来各种不同类型的风险。
自云技术出现以来，其实施发生了很大变化。CSP已经创建了许多云产品的变体，以至于很难提供目前可用的所有实施方法的详尽列表。
美国国家标准与技术研究院 (NIST) 特别出版物 (SP) 800-145 “NIST云计算定义”将云计算定义为：“一种对可提供交互的共享配置资源池实现无处不在、方便、按需网络访问的模型，这些资源（例如网络，服务器，存储，应用，服务）可以以最少的管理工作或服务快速配置和发布。”
NIST“云计算定义”还描述了云计算的基本特征，包括按需自助服务、广泛的网络访问、资源池、快速弹性和可测量的服务。
除了基本特征之外，还有各种云部署模型，包括：
公有云——基础设施由多个租户共享，云对公众开放。任何人都可以通过订阅来使用公共云。
私有云——基础设施仅供单个组织专用。云可能由组织运营，也可能不由组织运营。
社区云——类似的消费者可以协作以为共享基础设施而设计社区云的形式建立云（例如，政府组织可以形成一个云供其专有使用）。
混合云——这是两种不同部署模型的混合。
此外，还有以下服务模式：
基础设施即服务(IaaS)——客户订阅CSP提供的计算、网络或存储资源。
平台即服务(PaaS)——除了IaaS中描述的构建块外，客户还订阅了工具、库、服务和编程语言来运行应用程序。
软件即服务(SaaS)——客户使用应用程序，包括底层基础设施和提供商提供的服务。
云实施有许多变体，它们会利用部署和服务模型的所有可能的排列组合。
图片来源于公共图片库
信息技术是一个瞬息万变的领域。象云这样的新技术对技术风险格局的影响从未如此深远。
为了更有效地降低这种风险，重要的是要了解哪些云计算因素极大地影响了风险状况：
第三方的角色——外包多年来在信息技术领域发挥了重要作用。第三方风险管理对于技术风险专业人士来说并不是什么新鲜事。然而，CSP所发挥的作用已经变得更大、更深入。根据使用的部署模型，此角色可能会有所不同。如果一个组织正在使用公有云模型，第三方所扮演的角色与其他模型相比要大得多，因为云完全由第三方拥有和运营，而在私有云模型中，客户组织有可能拥有所有权和负责运营。同样，使用SaaS服务模型时，客户对供应商的依赖更大，因为基础设施和应用程序由第三方提供，而IaaS模型规定只有基础设施由CSP提供。不同的云服务模式安排可能导致的复杂关系将第三方风险管理置于云技术的不同基础上。
技术——虽然虚拟化技术不是一个新概念，但在云环境中广泛使用虚拟化会带来新技术风险。新的硬件和软件元素，例如使用管理程序、使用管理平面来配置底层硬件、软件定义的网络、无服务器计算和/或基础设施即代码 (IAC) 引入了新的风险，这些风险必须在整体风险评估中加以考虑。
对控制的共同所有权——虽然使用第三方供应商在技术领域并不新鲜，但从风险角度来看，云技术的不同之处在于控制操作的集成程度（图 1）。
例如，考虑备份和恢复控制。大多数CSP提供多种选项来在PaaS部署期间存储云客户的数据。可能存在客户不利用CSP的备份服务并因此负责创建备份的情况，在这种情况下，提供商负责计算资源的冗余，而客户负责其他一切。或者，客户可以选择以成本代价由CSP执行备份服务。在这种情况下，客户负责确定备份要求和恢复点目标 (RPO)，而云提供商负责管理备份例程、备份安全和备份测试。因此，客户可以使用各种备份和恢复选项。客户和供应商的责任因情况而异。
在某些控制——例如身份和访问管理相关控制或加密相关控制的情况下，客户和供应商的责任如此交织在一起，以至于一刀切的方法不起作用，因此难以评估和分析控制的有效性，进而分析风险。
虽然使用第三方供应商在技术领域并不新鲜，但从风险角度来看，使云技术与众不同的是控制操作中的集成程度。
分包商——大多数CSP大量使用其他分包商的服务。监控分包商的使用使事情进一步复杂化。想象一个 SaaS 提供商托管数据并利用某个CSP的计算服务，但使用另一个不同的CSP备份数据。对客户而言，这会产生多重控制权，每个控制权由不同的供应商运营，责任模式不明确。
数据位置——数据的位置在云环境中是不确定的。事实上，“云”的概念间接地暗示了这一点。在某些国家，存在与数据位置相关的法律和法规要求。在这种情况下，云的本质加剧了合规噩梦。一些CSP允许组织选择存储数据的位置。然而，还有更多的并发症。例如，一些PaaS服务使用临时数据存储，而CSP可能无法确保该位置，因为云服务旨在利用计算和存储资源来满足任何位置的处理要求。
云提供商教育客户的能力和意愿——大多数CSP都对遵守安全要求感兴趣，精通不同地区的监管和法律要求，并渴望支持客户的经济利益。然而，这并非普遍适用。较小的CSP可能不了解更复杂的法律和监管要求。他们可能对某些敏感行业的广泛保证要求不感兴趣。有时，客户会花费大量时间向较小的参与者解释控制要求。更大的CSP也只愿意在一定程度上保持透明。一些 CSP可能会因复杂的服务水平协议 (SLA) 和审计权要求而阻碍客户。可以理解的是，CSP受经济利益驱动，不倾向于定制大型客户群的保证请求，这使得风险分析和评估具有挑战性。
最终，与其他新技术倡议相比，云技术需要对控制环境和风险管理方法进行更深入的分析。
图片来源于公共图片库
为了应对云实施带来的挑战，技术风险专业人员必须改变他们处理技术风险的方法，并考虑以下因素：
心态——这个建议可能会有点令人惊讶和有点争议。云实施已成为现实，云技术的好处已超过其感知风险。CSP还接受了更强的安全控制和更好的风险管理流程更具有经济意义。技术风险专业人士必须承认，当数据迁移到云端时，他们对控制环境的可见性将无法达到同等水平，客户必须依靠供应商来保护他们的数据。风险专业人员应投入更多精力来定制自己的控制措施并开发全面的评估技术，以确保合理的可见性。 技术风险专业人士必须接受这个事实，当数据迁移到云端时，他们对控制环境的可见性将无法达到之前的同等水平。
风险专业人员培训——云是不同技术的复杂组合，并且在不断变化。当风险专业人员在云基础知识方面未接受过充分培训时，他们倾向于将本地思维方式应用于云，从而导致不适当的风险管理方法。对风险专业人员的培训应超越大型CSP提供的标准培训。此类培训应由云专家、CSP和风险专业人员共同设计，以确保涵盖所有基础。
检查点设计——一旦应用程序或服务迁移到云端，就很难弥补任何差距。在应用程序或服务迁移到云之前，应该有一组最少的控制列表。例如，如果应用程序存储和处理机密数据，那么最好在将应用程序载入云之前与云提供商确认适当的加密控制级别。客户将依赖CSP的密钥还是使用自己的密钥进行加密？这些问题应该在服务迁移到云之前得到解答。此类检查点应内置到云管理流程中，以保障应用程序只有在确保了适当的控制集合到位后才能迁移到云中。
控制目录的定制——许多风险专业人员错误地使用相同的控制目录进行云实施。虽然控件的基本性质没有改变，但控件的操作方式已经改变。例如，考虑一个用于每年测试一次本地应用程序以实现灾难恢复 (DR) 目的的控件。虽然应用程序在被载入云后的PaaS或IaaS环境中仍然可以进行测试，但可能需要将控件分解为多个子控件，以清楚地阐明在没有云供应商参与的情况下用户可测试的内容，以及控制的哪一部分将与云供应商已发布的DR报告集成。
供应商关系——归根结底，并非一切都可以通过SLA或审计条款来确定。与供应商建立良好的关系对于风险管理专业人员来说非常重要。供应商和客户都应将整个风险管理活动视为互利行为。与供应商定期会面、交流理想和相互信任有助于快速加强控制环境。
评估第三方合规性报告——许多CSP，尤其是大型提供商，为证明控制的有效性成为了第三方保证。利用合规性报告深入了解CSP的控制环境非常重要。这些报告可能包括SOC2报告、渗透测试报告、支付卡行业数据安全标准 (PCI DSS) 报告、云计算合规标准目录 (C5) 报告或国际标准化组织 (ISO) 标准ISO 27001认证。每个报告或证明都有不同的重点。了解报告涵盖的范围也很重要。例如，如果数据位于印度中部的数据中心，而CSP发布的SOC2报告未涵盖该数据中心，那么出于保证目的，人们可能不想依赖此类SOC2报告。此外，这些报告可能会定期发布或更新。了解和跟踪报告发布和修改的频率非常重要。最重要的是，客户应将其自己的控制目录与此类报告所涵盖的控制进行映射，以确保覆盖范围是足够的。
随着技术风险职能部门对云风险的深入挖掘，在实施中可能需要进行其他更改。
幸运的是，有各种出版物可提供指南，包括云安全联盟(CSA)云控制矩阵版本42。它由197个控制目标组成，分为17个领域。它不仅包括由于实施云技术而包含的新控制，而且还显示了CSP和云客户之间的责任分工；它还提供实施和审计指南。NIST的网络安全框架1.1版，包括基于现有标准、指南和实践的自愿指导，以帮助组织更好地管理和降低网络安全风险。
由于云实施与本地实施存在一些差别，因此应定制识别、评估和分析技术风险的方法。云技术的影响可能因组织而异，具体取决于云模型和部署方法。 技术风险职能部门不仅应该改变思维方式来评估与云技术相关的风险，还应该在更细粒度的层面上改变控制框架，以确保充分解决和减轻与云相关的风险。
