《2017云计算关键领域安全指南V4.0版.docx》由会员分享，可在线阅读，更多相关《2017云计算关键领域安全指南V4.0版.docx（173页珍藏版）》请在课桌文档上搜索。
1、CSA云计算关键领域安全指南V4.0目录D1:云计算概念和体系架构8D2:治理与企业风险管理30D3:法律问题，合同和电子举证40D4:合规和审计管理55D5：信息治理62D6：管理平面和业务连续性69D7：基础设施安全80D8：虚拟化和容器96D9：事件响应107D10:应用安全114D11：数据安全和加密125D12：身份、授权和访问管理137D13：安全即服务148D14:相关技术154D1:云计算概念和体系架构1-1简介本域为云计算安全指南的其它所有部分介绍一个概念性的框架。它描述和定义了云计算，设置了我们的基本术语，并详细描述了文档其余部分中使用的总体逻辑和架构框架。看待云计算有很多
2、不同的方式:它可以是一项技术、一系列的技术、一种运作模式、一种商业模式，这儿仅仅举了几个例子。从本质上来说，这是一场颠覆性的变革。它发展地非常非常快，而且没有放缓的迹象。虽然我们在本指南的第一个版本中包含的参考模型依旧比较准确，但是它们显然已经不再那么完整了。即使这样更新后也不可能解释未来几年的每一个可能的变化。云计算为敏捷、弹性和经济带来了巨大的潜在收益。组织可以运转地更快（因为他们不需要购买和拨备硬件，所有的都是软件定义的），减少停机时间（由于固有的弹性和其他云特性），并且节省资金（由于资本支出减少，需求和能力匹配）。自云服务提供商有重大的经济激励措施来保护消费者以来，我们也看到了安全收益
3、。然而，这些收益是在您理解并采用原生云模型，并调整您的架构和控制，以适应云平台的特性和功能的基础上才会出现。其实，使用现有的应用或资产，并在不进行任何更改的情况下将其移动到云服务提供商，往往会降低敏捷性、弹性，甚至是安全性，同时还增加了成本。该领域的目的是建立基础，以使文档的其余部分及其建议都基于此。其意图是为信息安全专家提供一种通用语言和对云计算的理解，并开始强调云计算和传统计算之间的区别，以及帮助引导信息安全专家采用原生云方法，从而带来更好的安全性（以及其他收益），而不是产生更多的风险。这个领域包括了4部分： 定义云计算 云逻辑模型 云概念、架构和参考模型 云安全性和合规管理范围、职责和模
4、型云安全联盟并没有着手创建一个全新的分类法或参考模型。我们的目标是对现有的模型进行提取和协调一一最值得注意的是NIST的特种文献800-145,ISO/IEC17788andISO/IEC17789一一关注与信息安全专家最相关的是什么。1.2概览1.Ll定义云计算云计算是一种新的运作模式和一组用于管理计算资源共享池的技术。云计算是一种颠覆性的技术，它可以增强协作、提高敏捷性、可扩展性以及可用性，还可以通过优化资源分配、提高计算效率来降低成本。云计算模式构想了一个全新的世界，组件可以迅速调配、置备、部署和回收，还可以迅速地扩充或缩减，以提供按需的、类似于效用计算的分配和消费模式。NIST将云计算
5、定义为：云计算是一个模式，它是一种无处不在的、便捷的、按需的，基于网络访问的，共享使用的，可配置的计算资源（如:网络、服务器、存储、应用和服务）可以通过最少的管理工作或与服务提供商的互动来快速置备并发布。ISO/IEC的定义非常相似：通过自服务置备和按需管理，实现网络可访问、可扩展的、弹性的共享物理或虚拟资源池的范式。描述云的一种（稍微）简单的方法是，它需要一组资源，比如处理器和内存，并将它们放到一个大的池中（在这种情况下，使用虚拟化）。消费者需要从池中获得需要的东西，比如8CPUs和16GB的内存，而云将这些资源分配给客户端，然后客户端连接到网络并在网络上使用这些资源。当客户端完成时，他们可
6、以将资源放回池中供其他人使用。云可以由几乎任何计算资源组成，从计算（如处理器和内存）到网络、存储以及更高级别资源（如数据库和应用程序）。例如，在数百个其他组织共享的服务中订阅500名员工的客户关系管理应用，与在云主机中启动100台远程服务器是一样的。定义:云用户是请求和使用资源的人或组织，云提供商是分发它的人或组织。我们有时还会使用术语“客户”和“消费者”来指代云用户，用服务或简单的云来描述云提供商。NIST500-292使用“cloudactor这个术语，并增加了云代理、运营商和审计人员的角色。ISO/IEC17788使用术语云服务用户、云服务合作伙伴和云服务提供商。创建云的关键技术是抽象和
7、调配。我们从底层的物理基础设施中抽象出资源来创建我们的池，并使用调配（和自动化）来协调从池分割和分发各种资源到用户。正如您将看到的，这两种技术创造了我们用来定义“d。Ud的所有基本特征。这就是云计算和传统的虚拟化之间的区别;虚拟化技术将资源抽象化，但是它通常缺乏将它们组合在一起并按需分发给用户的调配，而是依赖于手动流程。云是多租户的。多个不同的消费者共享同一个资源池,但彼此相互隔离和孤立。隔离允许云提供商将资源分配到不同的组,孤立确保他们不能看到或修改对方的资产。多租户不仅应用在不同的组织;它还用于在单个业务或组织中分配不同单元之间的资源。1.L2定义模型云安全联盟（CSA）使用NISTmod
8、elforcloudcomputing作为定义云计算的标准。CSA还支持更深入的ISO/IECmodel,并作为参考模型。在这个领域中，我们将引用两者。NlST出版物是被普遍接受的，所以，我们选择与NISTWorkingDefinitionofCloudComputing（NIST800-145）保持一致，这样我们能够集中精力到用例上，而不是细微的语法定义差别上，同时能保证一致性并获得广泛的共识。值得注意的是，本指南的目的是使其具有广泛的易用性、适用于全球范围内的组织。虽然NlST是美国政府机构，选择此参考模型不应该被解释为是对其它观点或地域的排斥。在NIST对云计算的定义中，包括了五个基本特
9、征、三个云服务模型、以及四个云部署模型。下图对它们进行了形象的汇总，后面会有详细描述。BroadNetwork AccessRapidElasticityMeasuredServiceOn-DemandSelf-ServiceEssentialCharacteristicsResourcePoolingSaaS(Software as a Service)PaaS(Platform as a Service)IaaS(Infrastucture as a Service)ServiceModelsDevelopmentModelsPublicPrivateHybridCommunity1.1.
10、2.1 基本特征以下特性使云成为了云。如果具备以下特征，我们就把它看作是云计算。如果它缺少其中任何一个,它很可能不是一个云。正如上面所讨论的，资源池是最基本的特性。云提供商对资源进行抽象，并将其聚集到一个池中，其中的一部分可以分配给不同的用户（通常是基于策略）。用户自己可以按需自动配置资源，他们自己管理自己的资源，而无需与服务提供商的服务人员互动。广泛的网络访问意味着所有的资源都可以通过网络获得，而不需要直接的实体接取；网络并不是服务的必须部分。快速弹性允许用户从池中按需使用资源（置备和释放），通常完全自动。这使他们更紧密地匹配资源消耗需求（例如,需求增加时添加虚拟服务器,然后当需求终止时释放
11、它们）。提供可测量的服务，以确保用户只使用他们所分配的东西，如果有必要的话，还可以对他们收取费用。这就是“效用计算这个术语的由来，因为计算资源现在可以像水和电一样消耗，客户只需要支付他们所使用的东西。ISO/IEC17788列出了六个关键特性，其中前五个特性与NlST的特征相同。唯一的补充是多租户，这与资源池是不同的。1.1.2.2 服务模型NIST定义了三个服务模型，它们描述了云服务的不同基础类别： 服务即软件（SaaS）是由服务商管理和托管的完整应用软件。用户可以通过Web浏览器、移动应用或轻量级客户端应用来访问它。 平台即服务（PaaS）抽象并提供开发或应用平台,如数据库、应用平台（如运
12、行Python.PHP或其它代码的地方）,文件存储和协作,甚至专有的应用处理（例如机器学习、大数据处理或直接APl访问完整的SaaS应用的特性）。关键的区别在于，使用PaaS,您不需要管理底层的服务器、网络或其他基础设施。 基础设施即服务（IaaS）提供了基础性的计算资源，如计算、网络或存储。我们有时称它们为“SPI模型。ISO/IEC使用了一个更加复杂的定义，它使用了一个与SPI模型（软件、基础设施和平台功能类型）密切相关的云功能类型。然后，它扩展到更细粒度的云服务类别，比如计算即服务、存储即服务，甚至还包括laaS/PaaS/SaaSo这些类别具有一定的渗透性:一些云服务跨越了这些模型，而
13、另一些则不完全属于单一的服务模式。实际上，没有理由尝试把所有的东西都分配到这三大类中，甚至是ISO/IEC模型中更细粒度的类别。这仅仅是一个有用的描述工具，而不是一个严格的框架。这两种方法都是同样有效的，但是由于NIST的模型更加简洁，并且目前使用得更广泛，所CSA研究中主要使用的定义。1.1.2.3 部署模型NIST和ISO/IEC都使用相同的4个云部署模型。下面描述这些技术是如何部署和使用的，它们适用于整个服务模型的范围： 公共云。云基础设施提供服务给一般公众或某个大型行业团体。并由销售云计算服务的组织所有。 私有云。云基础设施专为一个单一的组织运作。它可以由该组织或某个第三方管理并可以位
14、于组织内部或外部。 社区云。云基础设施由若干个组织共享，支持某个特定有共同关注点的社区。（例如使命、安全要求、政策或合规性考虑等）。它可以由该组织或某个第三方管理并可以位于组织内部或外部。 混合云。云基础设施由两个或多个云（私有、社区、或公共）组成，以独立实体存在，但是通过标准的或专有的技术绑定在一起，这些技术促进了数据和应用的可移植性（例如：云间的负载平衡）。混合通常用于描述非云化数据中心与云服务提供商的互联。部署模型是基于云用户定义的，即使用云的用户。如下图所示，拥有和管理云的组织即使在单个部署模型中也会有所不同。CSA云计算关键领域安全指南v4.0InfrastructureManage
15、dBy,InfrastructureManagedBy2InfrastructureLocated3AccessibleandConsumedBy4PublicThirdPanyProviderThirdPartyProviderOff-PrefniseUntrustedPrivate/CommunityOrganizationThirdPanyProviderXOrganizationThirdPartyProviderx-1On-PremiseOff-PremiseTrustedHybridBothOrganization&ThirdPartyProviderBothOrganizatio
16、n&ThirdPartyProviderBothQn-Premise&Off-PremiseTrusted&Untrusted1.1.3参考和架布丽现在，在构建云服务方面，有很多不断发展的技术，使得任何单一的引用或架构模型从一开始就过时了。本节的目标是提供一些基础知识，帮助信息安全专家做出明智的决策，以及了解更复杂和新兴模型的基线。对于一个深入的参考架构模型，我们再次推荐ISO/IEC17789和NIST500-292,这是NlST定义模型的补充。看待云计算的一种方式是将其视为一个堆栈，SaaS是位于PaaS之上，PaaS位于IaaS之上。这并不是所有（甚至大多数）实际部署的代表，而是作为开始
17、讨论的有用参考。PresentationModalityPresentationPlatformDataAPIsApplicationsMetadataIntegration & MiddlewareContentUW(s B SBBS (S e SB Jw-d) SeBd MJS ese(-nrnseJJU-) Sa基础设施即服务物理设施和硬件基础设施构成IaaS的基础。利用云计算，我们将这些资源抽象并集中在一起，但是在最基本的层面上，我们总是需要物理硬件、网络和存储来进行构建。这些资源通过抽象和调配进行汇集。抽象通常通过虚拟化，将资源从物理约束中解放，生成池。然后，一组核心连接和交付工具（
18、编排）将这些抽象资源组合在一起，创建池，并自动化将他们交付给用户。所有这些都是通过应用程序编程接口（APIs）实现的。APIs通常是云中组件的底层通信方法，其中一些（或完全不同的集合）公开给云用户，以管理他们的资源和配置。目前大多数云APIS都使用RESTfRepresentationaIStateTransfer）,它在HTTP协议上运行，非常适合于Internet服务。在大多数情况下，这些APIs都是可以远程访问的，并被封装到基于web的用户界面中。这种结合是云管理层面，因为用户使用它来管理和配置云资源，比如启动虚拟机（实例）或配置虚拟网络。从安全的角度来看，这既是与保护物理基础设施最大的
19、区别（因为您不能依赖物理访问作为控制），也是在设计云安全程序时，需要最优先考虑的问题。如果攻击者进入您的管理平面，他们可能获得您的整个云部署的远程访问完整权限。因此IaaS由设备、硬件、抽象层、编排（核心连接和交付）层组成，将抽象资源绑定在一起，通过APIs远程管理资源并将它们交付给用户。下面是一个IaaS平台的简单架构示例:Outside WorldoeiStorage PoolComputePool这是一个非常简单的图表，展示了用于编排的计算和存储控制器，用于抽象的管理程序，以及计算和存储池之间的关系。它省略了许多组件，例如网络管理器。一系列物理服务器每个运行两个组件：虚拟机管理程序和管理
20、/编排软件，以连接服务器并将它们连接到计算控制器。用户请求一个特定大小的实例（虚拟服务器），而云控制器确定哪个服务器具有容量，并分配请求的大小的实例。控制器随后通过请求存储控制器的存储来创建一个虚拟硬盘驱动器，该存储控制器从存储池中分配存储，并通过网络将其连接到适当的主机服务器和实例（用于存储通信的专用网络）。网络，包括虚拟网络接口和地址，也被分配并连接到必要的虚拟网络。然后，控制器将服务器映像的副本发送到虚拟机中，启动它，并配置它：随着虚拟网络和存储都配置好之后，这就将创建一个在虚拟机中运行的实例。一旦整个过程完成，元数据和连接信息就由云控制器代理，并提供给用户，用户现在就可以连接到实例并登
21、录。平台即服务在所有的服务模型中，PaaS是最难以确定的，因为PaaS产品的范围广泛，并且构建PaaS服务的方法很多。PaaS增加了与应用程序开发框架、中间件功能以及数据库、消息传递和队列等功能的集成层。这些服务允许开发人员在平台上构建应用程序，并使用程序支持的编程语言和工具。在现实世界中经常见到的一个选择，在我们的模型中也可以看到，就是在IaaS的基础上构建一个平台。在IaaS上构建了集成层和中间件，然后将其汇集在一起，进行编排，并使用APIs作为PaaS暴露给用户。例如，可以通过在IaaS中运行的实例上部署修改后的数据库管理系统软件来构建数据库即服务。用户通过API（和一个web控制台）管
22、理数据库，并通过普通的数据库网络协议访问它，或者通过APl访问它。在PaaS中，云用户只看到平台，而不是底层的基础设施。在我们的示例中，数据库可根据需要进行伸缩，而不需要管理单个服务器、网络、补丁等。另一个例子是应用程序部署平台。这使得开发人员可以在不管理底层资源的情况下加载和运行应用程序代码。这种服务使PaaS可以运行任何语言编写的任何应用程序，将开发人员从配置和构建服务器中解放出来，让他们与时俱进，或者去操心集群和负载均衡之类的复杂问题。这个简单架构图展示了一个在IaaS架构之上运行的应用平台（PaaS）:OutsideWorldApplicationIApplicationIApplic
23、ationIApplicationApplicationPlatform.eComputePoolStoragePoOlPaaS不一定要建立在IaaS之上：没有理由不能自定义设计独立架构。定义的特点是消费者访问和管理平台，而不是底层基础设施（包括云基础设施）。1.1.3.1软件即服务SaaS服务是完整的、多租户的应用程序，也具有任何大型软件平台的复杂架构。为了提高敏捷性、弹性和（潜在的）经济利益，许多SaaS提供商构建在IaaS和PaaS之上大多数现代云应用程序（SaaS或其它）都使用IaaS和PaaS的组合，有时跨不同的云提供商。许多人还倾向于为一些（或全部）功能提供公共APIso他们经常需
24、要这些来支持各种各样的客户端，特别是web浏览器和移动应用程序。因此，所有SaaS都有一个APl位于应用程序/逻辑层和数据存储之上。然后有一个或多个表示层，通常包括Web浏览器、移动应用程序和公共APl访问。下面的简化架构图取自一个真正的SaaS平台，但它是通用的，己删除使用中的特定产品的引用:CloudLoadQpARSBInternalLoadWBalancer三三iPushRelational冬DatabasePaaSNo-SQLPaaS脸NotificationService逻辑模型从宏观上，云计算和传统计算都遵循一种逻辑模型，这种逻辑模型可以基于功能识别不同的层次。这有助于阐明不同计
25、算模型之间的差异： 基础设施：包括计算系统的核心组件：计算机，网络和存储，其他组件设立的基础，移动部件。 元结构：提供基础设施层与其他层之间接口的协议和机制，是一种将多种技术紧密联系起来、实现管理与配置的粘合剂 信息结构：数据和信息，如数据库中的内容，文件存储等 应用结构:部署在云端的应用程序和用于构建它们的底层应用程序服务。例如，PaaS的功能特性如消息队列，人工智能分析或通知服务不同的安全性将映射到不同的逻辑层。应用程序安全性映射到应用程序结构，数据安全性映射到信息结构，基础设施的安全性映射到基础设施层。InfostructureApplistructureMetastructureInf
26、rastructure云计算与传统计算的关键区别在于元结构。云计算元结构包括了可网络接入且远程访问的管理平台组件。另一个关键的区别在于，在云端，你往往会给每个层次赋予双重的任务。例如：基础设施包括用于创建云的基础设施以及云消费者使用和管理的虚拟基础架构。在私有云中，同一个组织可能需要同时管理上述两种基础设施：在公有云中，提供商管理物理基础设施，而消费者管理其部分虚拟基础架构。正如我们稍后要讨论的那样，这对谁是负责人，及管理、安全性有着深刻的影响。这些层次往往也映射到常见的TT组织中的不同专业和技术的团队。尽管最明显且最直接的安全管理差异在于元结构，但云与传统计算在每一个层次都有很大的差异。差异
27、的规模不仅取决于云平台，更取决于云消费者如何利用云平台。例如，一个极大程度基于云提供商的PaaS产品所实现的云应用程序，相比一个仅为了迁移至IaaS平台进行细小变更的应用程序而言，具有更多应用程序结构的差异。1.2云安全范围、职责和模型1.2.1云安全与合规性范围和职责这听起来也许很简单，但是云安全和合规性包含了一个安全团队在当前应当负责的所有职责。虽然延续了所有传统安全领域，但是其风险、角色和职责的性质，以及控制点的实施时常有着巨大的变化。虽然云安全和合规性的总体范围没有变化，但是任何一个云服务参与者都应当承担起相应的职责。可以这样想：云计算是一种共享技术模式，不同的组织通常会承担实施和管理
28、不同部分的责任。因此，安全职责也由不同的组织分担，所有的组织都包含在其中。这通常被称为共享责任模型，它是依赖于特定的云提供商和功能/产品，服务模型和部署模型的责任矩阵。从宏观上讲，安全职责是与任何角色对于架构堆栈的控制程度相对应的： 软件即服务：云服务提供商负责几乎所有的安全性，因为云消费者只能访问和管理其使用的应用程序，并且无法更改应用程序。例如，SaaS提供商负责周边安全，日志/监控/审计和应用安全性，而消费者可能只能够管理授权和权利。 平台即服务：云服务提供商负责平台的安全性，而消费者负责他们在平台上所部署的应用，包括所有安全配置。因此两者职责几乎是平均分配的。例如，使用一个数据库作为服
29、务时，提供商管理基本的安全，修复和核心配置，而云消费者则对其他负责，包括数据库要使用的安全功能，管理账户，甚至是身份验证方法。 基础设施即服务：类似PaaS,云服务提供商负责基本的安全，而云消费者负责他们建立在该基础设施上的其它安全，不同于PaaS,IaaS的消费者承担更多的责任。例如，IaaS的提供商将可能监视他们的网络边界所受到的攻击，但消费者在服务商提供的工具基础上，全权负责如何定义和实现自己的虚拟网络安全。InfrastructureIPlatformISoftwareasaServiceIasaServiceIasaServiceSecurityResponsibilityMostl
30、yConsumerMostlyProvider这些角色在使用云服务中介或其他中介机构和合作伙伴时就变得更加复杂。最重要的安全性考虑是确切地知道谁负责特定的云计算项目。如果任何特定的云提供商提供了特殊的安全控制，且你清楚地知道他们提供了什么以及如何运作，这一点相对而言就没有那么重要。消费者可以选择通过自身控制来消除控制的差异，或是选择不同的云提供商。当选择IaaS时，云消费者的责任就很高，而如果选择SaaS则相对较低。这是云服务提供商和消费者的安全关系的本质。提供商应当做什么？消费者应当做什么？云供应商是否给使用者提供了他们需要的服务？合同中担保了哪些责任和服务水平协议，以及技术文档和细则包含了
31、什么技术？与这种共享责任模式相关的，有如下两条建议： 云服务提供商应该清楚地记录其内部的安全控制和客户的安全功能，因此云消费者能够做出明智的决定。提供商也应正确地设计和实施这些控制。 无论是什么云项目，云消费者应建立一个责任矩阵，以确定由谁及如何实施控制。这也应该与所有必要的合规标准相一致。云安全联盟提供了两个工具，以帮助满足这些要求:共识评估问卷(CAIQ),为云服务提供商提供的标准模板以记录他们的安全与合规控制。 云控制矩阵(CCM),其中列出了云计算的安全控制，并将它们映射到多个安全和合规标准。该矩阵还可以用来记录安全责任。这两份文件需要根据具体的组织和项目要求进行调整，但它提供了一个全
32、面的初始模板,并可以确保满足合规要求。1.2.2云安全模型云安全模型是一个协助指导安全决策的工具。“模型”这个词可能有些模糊，所以为了明确我们的目的，我们分解出以下类型: 神酗鳏包括用于解释云安全概念和原理的可视化效果和描述，如本文提到的CSA逻辑模型。对特定的云安全控制或控制类别进行分类和细化，如CSACCMo 参翳版指实现云安全的模板，这个架构通常是具有普遍性的(例如IaaS安全参考架构)。它们可以是非常抽象的，与概念相关，或者相当详细，与特定的控制和功能相关。幽算提针对特定问题的可重复使用的解决方案。在安全方面，IaaS口志管理即其中一个例子。与参考架构一样，它们可能或多或少是抽象的或具
33、体的，甚至是特定云平台上的常见实现模式。这些模型之间的划分往往是模糊和重叠的，这取决于模型开发人员的FI标，甚至将它们中的一些称为“模型也可能不够准确，但是由于我们看到这些术语在不同来源之间可互换使用,所以将它们分组是合乎情理的。.A已经审查并推荐以下模型: CSA企业架构 CSA云控制矩阵(CCM) NIST云计算安全参考架构草案(NIST500-299号特刊)，其中包括概念模型，参考架构和控制框架。ISO/IECFDIS27017信息技术-安全技术-基于ISO/IEC27002的云服务信息安全控制实践守则。BusinessOperationSupportServices(BOSS)Info
34、rmationTechnologyOperation&SupportPresentationServicesSecurity&RiskManagement(ITOS)ApplicationServicesInformationServices(SABSA)三(SABSA)InfrastructureServices(TOGAF)Qericho)在本指南中，我们还提及其他领域特定的模型。1.2.2.1 一个简单的云安全流程模型虽然实施细节、必要的控制、具体过程以及各种参考架构和设计模型会根据具体的云项目有很大的不同，但是仍会有一个相对简单的的高级流程来管理云安全： 确定必要的安全和合规要求以及任
35、何现有的控制点。 选择云提供商、服务和部署模型。 定义架构。 评估安全控制。 确定控制差距。 设计和实施控制以弥补差距。 持续管理变更。由于不同的云计算项目，即使是同一个云提供商，也可能会采用完全不同的配置和技术,每个项目都应该根据自己的情形进行评估。例如，针对某一供应商部署在IaaS上的应用程序所适用的安全控制，与这家供应商部署在PaaS的类似项目所适用的安全控制相比，可能看起来区别很大。关键在于识别需求、设计架构，然后根据底层云平台的功能来识别差距。这就是为什么在将安全需求转化为控制之前，您需要了解云供应商和云架构。IdentifyDefineIdentifyManageRequireme
36、ntsArchitectureControlGapsChangesSeleaProvider,AssessSecurityDesignandService,andControlsImplementControlsDeploymentModels1-3重点关注领域组成CSA指南的其它13个领域着重介绍了云计算安全的关注领域，以解决云计算环境中战略和战术安全的“痛点(PainPOints),从而可应用于各种云服务和部署模式的组合。这些域分成了两大类：治理(governance)和运行(operations)。治理域范畴很广，解决云计算环境的战略和策略问题，而运行域则更关注于战术性的安全考虑以及在架
37、构内的实现。1.3.1治理域领域名称描述D2治理和企业风险管理组织治理和度量云计算带来的企业风险的能力。例如违约的判决先例，用户组织充分评估云提供商风险的能力，当用户和提供商都有可能出现故障时保护敏感数据的责任，及国际边界对这些问题有何影响等都是关注点。D3法律问题：合同和电子举证使用云计算时潜在的法律问题。本节涉及的的问题包括信息和计算机系统的保护要求、安全漏洞信息披露的法律、监管要求，隐私要求和国际法等。D4合规性和审计管理保持和证明使用云计算的合规性。本节涉及评估云计算如何影响内部安全策略的合规性、以及不同的合规性要求(规章、法规等)。同时还提供在审计过程中证明合规性的一些指导。D5信息
38、治理治理云中的数据。本节涉及云中数据的识别和控制；以及可用于处理数据迁移到云中时失去物理控制这一问题的补偿控制。也提及其它项，如谁负责数据机密性、完整性和可用性等。1.3.2运行域领域名称描述D6管理平面和业务连续性保护访问云时使用的管理平台和管理结构，包括Web控制台和APL确保云部署的业务连续性。D7基础设施安全核心云基础架构安全性，包括网络、负载安全和混合云安全考虑。该领域还包括私有云的安全基础。D8虚拟化及容器(Container)技术虚拟化管理系统、容器和软件定义的网络的安全性。D9事件响应、通告和补救适当的和充分的事件检测、响应、通告和补救。尝试说明为了启动适当的事件处理和取证，在
39、用户和提供商两边都需要满足的一些条目。本域将会帮助您理解云给您现有的事件处理程序带来的复杂性。DlO应用安全保护在云上运行或在云中开发的应用软件。包括将某个应用迁移到或设计在云中运行是否可行，如果可行，什么类型的云平台是最合适的(SaaSzPaaSzOrIaaS)ODll数据安全和加密实施数据的安全和加密控制，并保证可扩展的密钥管理D12身份、授权和访问管理管理身份和利用目录服务来提供访问控制。关注点是组织将身份管理扩展到云中遇到的问题。本节提供洞察评估一个组织准备就绪进行基于云的身份、授权和访问管理(IdEA)。D13安全即服务提供第三方促进安全保障、事件管理、合规认证以及身份和访问监督。D
40、14相关技术与云计算有着密切关系的已建立的新兴技术，包括大数据，物联网和移动计算1.4建议 理解云计算与传统基础设施或虚拟化之间的差异，以及抽象化和自动化对安全性的影响 熟悉NlST云计算模型和CSA参考架构 使用工具，如CSA的共识评估问卷（CAQ）,来评估和比较云服务提供商。 云提供商应清楚地记录其安全控制和功能，并使用类似CSACAIQ的工具进行发布. 使用工具，如CSA云控制矩阵（CCM）,来评估和记录云项目安全性和合规性要求和控制，以及每一个控制点的负责人。 使用云安全流程模型来选择提供商，设计架构，识别控制差距，以及实施安全性和合规性控制。1.5参考文献 RichMogull 基于
41、ChristoferHoff的参考模型和逻辑结构:治理与企业风险管理2.1 简介治理与企业风险管理都是被广泛涉及的主题。本指南集中讨论它们在云计算环境下的不同之处。而不是也不应被看做是与云计算无关的环境下的应用探讨。对安全专家来说，云计算对治理与企业风险管理带来的影响主要有以下四个方面： 治理包括组织运作中的策略、流程、以及内控措施。涉及到组织架构和领导层明确的方针，以及任何管理机制。关于治理更多的信息，请参考：ISO/IEC38500:2015信息技术组织IT治理ISACA-COBIT-企业IT治理与管理的业务框架ISO/IEC27014:2013信息技术安全技术信息安全治理 企业风险管理包
42、括组织全面的风险管理，与组织的治理和风险容忍度相一致。企业风险管理包括所有类型的风险，不仅仅是技术相关的风险。 信息风险管理包括涉及信息本身的风险管理，以及信息技术风险管理。组织面对各种风险，从财务到物理等涉及各个领域，信息仅仅是组织需要管理的一类资产而已。 信息安全是管理信息相关风险的工具和实践。信息安全并不是管理信息风险的全部和终结，政策、合同、保险和其他机制也发挥作用（包括非电子数据信息的物理安全等）。然而，信息安全的主要作用是对电子信息以及我们访问电子信息的系统，提供管理流程和控制措施。在如下图一个简化的层次结构中，信息安全是信息风险管理的工具，信息风险管理进而是企业风险管理的工具，企
43、业风险管理又是企业治理的工具。这四个层次是密切相关的，但需要关注各自的重点、流程和工具。InformationRiskManagementInformation Security2.2 TW奂硒询姨稣7雄;卿蹴!拥喻映和蜘省能够胭娱筋妫侬溺双詹魏基村的薜的黑沸醐都自圾2.1 概述2.L1治理云计算影响治理关系，因为它要么引入对第三方过程管理（在公共云或托管私有云的情况下），或在私有云的情况下可能改变内部的治理结构。管理云计算时要记住的首要问题是，一幽织施被汐领御债任即使是使用外部供应商的情况下。无论采用云计算或不采用云计算服务，这都是正确的。但需要理解的是，在云计算环境下的共同责任模式的概念，
44、是非常有用的。云服务提供商通常会试图利用规模经济来管理成本和提供云计算服务的能力。这意味着需要提供标准化的服务（包括合同和服务水平协议），对所有客户都是一致的。对待云服务提供商，组织的治理模式不一定能像对待其他专用的外部服务提供商一样，专用的外部服务提供商他们通常为每个客户定制自己的产品，包括法律协议。云计算改变了实施管理和治理的职责与机制。如任何业务关系一样，需要在合同中定义治理的职责和机制。如果关注的领域不在合同中明确，就没有可实施的保障机制，并且存在治理缺口。治理缺口不一定意味着需要排除使用外部供应商，但他们确实要求客户调整自己的流程以减少差距，或接受相关的风险。与任何其他领域一样，也有
45、用于治理的特定管理工具。此列表更侧重于外部云服务提供者的管理工具，但这些工具通常也可以运用在在内部私有化部署的环境下： 合同：管理的主要工具是云提供商和云客户之间的合同（对公有云和私有云都一样）。合同是把一切都变成法律条款，从而保障任何服务水平或承诺不会违约的唯一方式。合同是将治理扩展到业务合作伙伴和服务提供者的主要工具。ContractInternal，Controls也雌桢展懒酬腰!其 供应商（云提供商）评估：这些评估是云客户利用可用的信息和允许的流程/技术，来对潜在的云提供商进行考核的方法。这综合了合同和手册的研究，与第三方认证（法律条款上通常明确要求评估或审计的结果），以及技术研究等各
46、个方面。与任何供应商的评估都非常相似，包括财务上的可行性，历史，特色产品，第三方认证的结果，来自同行的反馈等等。更多关于评估的详细信息在此域和域4中描述。 合规报告：合规报告包括供应商内部（即自身）和外部合规评估的所有文件。它们是一个组织执行自己的内部控制措施情况的审计报告，客户可以选择对提供商进行审计（虽然这通常不是云服务的选项之一），或者由可信的第三方执行。第三方审核和评估通常是首选的，因为他们可以提供具有独立性的验证（假设你信任第三方）。合规报告往往提供给云服务的潜在客户和已有的客户，但是往往需要签署NDA或服务合同。这往往需要是执行公司审计的要求，并不一定能由云服务提供商控制。评估和审计应根据现有的标准（实际上有非常多的参考标准），关键是需要要了解标准的应用范围，而不仅仅是标准本身。像SSAE16标准具有明确的适用范围，包括评估对象（例如，供应商的服务有哪些）以及相关控制措施的实施评估。因此，一个云服务提供者“通过”了一个审计，不一定包含所有的安全控制措施，这对安全和风险管理
