1、 云采用框架白皮书 文档版本：1.0 1 云采用框架白皮书 文档版本：1.0 2 目录 目录.2 作者.5 序言 1.6 序言 2.7 法律声明.8 1.背景介绍.9 1.1.什么是云采用框架.9 2.上云战略.10 2.1.企业上云的主要动机.10 2.2.上云所需的企业组织模型及其核心职责.11 3.上云准备.14 3.1.云上管理和治理框架 Landing Zone.14 3.2.阿里云上 Landing Zone 的主要组成部分.16 3.2.1.资源规划.16 3.2.2.财务管理.18 3.2.3.网络规划.21 3.2.4.身份权限.30 云采用框架白皮书 文档版本：1.0 3

2、3.2.5.安全防护.35 3.2.6.合规审计.40 3.3.基于 IaC 理念快速部署 Landing Zone.42 4.应用上云.47 4.1.企业应用上云规划.47 4.1.1.上云评估模型.47 4.1.2.业务调研.48 4.1.3.应用上云策略及决策流程.48 4.1.4.应用上云优先级及计划.49 4.2.应用上云实施.50 4.2.1.应用上云实施流程.50 4.2.2.应用调研.50 4.2.3.应用上云方案设计.51 4.2.4.上云迁移实施.58 4.2.5.测试与验证.59 4.2.6.割接与上线.60 5.运营治理.63 5.1.风险治理方法论.63 5.1.1.

3、风险治理的方法论.63 5.1.2.风险治理的工作开展.65 云采用框架白皮书 文档版本：1.0 4 5.2.阿里云上的治理基线.66 5.2.1.身份权限基线.66 5.2.2.数据安全基线.68 5.2.3.通用安全基线.71 5.2.4.业务连续性基线.73 6.结束语.75 7.基本概念.76 云采用框架白皮书 文档版本：1.0 5 作者 出品人|何登成（阿里云开放平台及企业 IT 治理负责人）核心作者|陈云龙、沈绎、王梓宏、魏俊欣 刘云飞、黄欢欢、刘文祥、李猛 任亚博、王觯程、刘自慧、管骥 张子轩、李超 总监制|蒋江伟（阿里云基础产品事业部负责人）袁千（阿里云国际事业部负责人）编辑与

4、设计吴公博、黄冠超 特别鸣谢 中国信息通信研究院及杨玲玲女士提供指导 云采用框架白皮书 文档版本：1.0 6 序言 1 云计算经过十几年的发展，已经从最初的概念，演变成为企业发展所必须的基础设施。今天，大家不会再去质疑云计算对企业发展的意义，而是开始探索如何在云的道路上走得更远。一方面，云计算实现了基础设施的快速交付和弹性扩展，也提供了丰富的云服务。企业可以在数小时内创建好自己的虚拟数据中心，也可以快速获得各类的 PaaS 和 SaaS 服务。另一方面，企业对于云上的安全合规、风险可控、资源可管的诉求随着业务大规模上云日益增加。因此，企业在使用云的时候需要平衡业务敏捷性和可管控性，在安全可控的

5、前提下实现业务的快速创新。阿里云开放平台团队在过去两年拜访了上百家企业客户，在跟客户相互交流学习的过程中，我们发现客户在云上管理与治理时，有两类比较显著的特征：业务优先和治理优先。业务优先型的客户上云以业务敏捷性为主，在云上的用量达到一定规模后，开始重新设计云上的 IT 管理和治理体系，返工成本和治理难度较大；治理优先型的客户，在上云准备的过程中对如何使用和管理云进行全面细致的设计和规划，规避规模化上云后带来的成本、合规、安全和管理等方面的风险，从而实现上云价值的最大化。通过总结这上百家企业客户在上云、管云过程中沉淀下来的经验和最佳实践，我们坚信各种行业的企业，无论规模大小，在云上构建起一个安

6、全合规、IT 资产可管可控的框架，并在此框架下实现业务的快速上云、快速创新，鱼与熊掌兼得，是完全可行的。但前提是，需要有一个比较好的方法论来指导，基于此，在 2021年初，阿里云联合信通院，编写了这本云采用框架白皮书。白皮书通过总结阿里云上百家企业客户的案例，在方法论层面对上云和管云进行探讨，并提供了基于 Landing Zone 的一系列最佳实践和自动化工具、脚本，帮助企业快速在阿里云上落地，在安全可控的环境下充分发挥云计算带来的技术优势，助力企业业务的敏捷创新与快速发展。蒋江伟 阿里巴巴高级研究员 阿里云基础产品事业部负责人 云采用框架白皮书 文档版本：1.0 7 序言 2 近年来，越来越

7、多的大型企业采用公有云作为核心的 IT 基础设施，而云原生技术也成为了企业的数字化转型的助推器。但随之而来，传统的 IT 管理和服务方法已经不能很好的适应并有效解决企业上云面临的诸多挑战，诸如安全合规、成本管理、资源的灵活使用和变更，敏捷开发和运维等等。为了确保业务在云上的快速落地和高效运营，以及将云原生的能力和企业 IT 管理战略能够更好的结合，需要有良好设计的云上 IT 管理和治理体系和可实践方法来支持。阿里云总结了多年的客户上云经验和最佳实践，输出了自己的云采用框架方法论，并且编写了这本云采用框架白皮书。该书不仅从 IT 管理的角度阐述了如何合理规划、使用和管理云资产以及构建合规、敏捷和

8、高效的企业 IT 服务体系；同时也从业务的视角描述了对云计算给企业带来的核心价值，比如有效利用云的标准服务模版来实现业务应用快速在云端落地、通过有效的成本和资源监控降低企业业务经营风险，使用云上自动化工具和方法提升企业敏捷开发和运维的能力和文化。未来，云计算将无处不在，企业对云使用要求也越来越高，阿里云的云采用框架将作为企业云治理的标准方法，助力企业管好云、用好云。袁千 阿里云国际事业部负责人 云采用框架白皮书 文档版本：1.0 8 法律声明 本文档的版权归阿里云所有，您应当通过阿里云网站或阿里云提供的其他授权通道下载、获取本文档，且仅能用于自身的合法合规的业务活动。一、文档使用及更新说明 1

9、.1 本文档仅作为用户使用阿里云产品及服务的参考性指引，阿里云以产品及服务的“现状”、“有缺陷”和“当前功能”的状态提供本文档。阿里云在现有技术的基础上尽最大努力提供相应的介绍及操作指引，但阿里云对本文档内容的准确性、完整性不作任何明示或暗示的保证。1.2 由于产品版本升级、调整或其他原因，本文档内容有可能变更。阿里云保留在没有任何通知或者提示下，对本文档的内容进行修改的权利，并在阿里云授权通道中不时发布更新后的文档。您应当实时关注用户文档的版本变更，并通过阿里云授权渠道下载、获取最新版的用户文档。二、知识产权声明 本文档中的材料和信息，包括但不限于文本、产品、图片、数据、档案、建议、资料，均

10、由阿里云和/或其关联公司依法拥有其知识产权，包括但不限于商标权、专利权、著作权等。非经阿里云和/或其关联公司书面同意，任何人不得擅自使用、修改、复制、公开传播、改变、散布、发行或公开发表。三、如何联系我们 您对本声明内容有任何疑问和意见，或者您发现本文档存在任何错误，您可以登录阿里云官网，点击上海品茶下方“联系我们”与我们联系。云采用框架白皮书 文档版本：1.0 9 1.背景介绍 1.1.什么是云采用框架 云采用框架为企业上云提供策略和技术的指导原则和最佳实践，帮助企业上好云、用好云、管好云，并成功实现业务目标。本云采用框架是基于服务大量企业客户的经验总结，将企业云采用分为四个阶段：上云战略、上云

11、准备、应用上云和运营治理，并详细探讨企业应在每个阶段采取的业务和技术策略；同时，还提供了一系列最佳实践、文档和辅助工具，帮助云架构师、云管理团队等干系人能够实现组织协同达成目标。ITIL（Information Technology Infrastructure Library）是 IT 服务管理的经典方法论，被企业广泛采用。ITIL 中核心的概念是 IT 服务，IT 服务是用来支持企业业务发展的技术服务，它的全生命周期包含服务战略、服务设计、服务转换、服务运营以及服务的持续改进五个阶段，其中：服务战略阶段：定义服务、明确服务的价值以及服务管理与业务之间的关系。服务设计阶段：定义服务的目标和要

12、素、模型和风险，定义管理服务的流程。服务转换阶段：提供发展和改进能力将服务交付到运营阶段。服务运营阶段：在服务交付和支持中保证效率和效果，为客户提供价值。云服务是当下最流行的 IT 服务之一，云服务的采用应遵循上述生命周期。我们的云采用框架就是以这样的理论体系为指导，定义了企业引入云服务的四个阶段：在上云战略阶段，领导层需要思考上云能为业务带来什么价值，并在公司层面确定战略。在上云准备阶段，IT 团队需要制定云采用的顶层设计，确保组织协同和可管可控。在应用上云阶段，开始迁移原有的系统上云或者在云上开展新的业务。在运营治理阶段，企业不断发现和解决运营过程中的问题和风险，提升服务质量。云采用框架白

13、皮书 文档版本：1.0 10 2.上云战略 2.1.企业上云的主要动机 概述 明确上云动机是制定企业上云战略的第一步。本章将讨论企业上云背后不同种类的动机，以及和这些动机相匹配的业务产出。企业上云动机的分类 我们可以根据上云的业务对上云动机进行分类。如果上云的业务是一个在云下已经存在的业务，那么上云主要是把云下的应用迁移到云上，这称为业务迁移上云。如果上云的业务是一个新构建的业务，首次部署运行就在云上，这称为业务创新上云。业务迁移上云 业务迁移上云是最为常见的一类上云动机，也是云计算技术商业化后最早期的企业普遍采用的上云方式。业务迁移上云的主要目的是：加速资源的交付效率，提高对业务需求的反应速

14、度 传统 IDC 采购周期从一个月到几个月不等。如果涉及到出海，对于企业来说 IDC 的规划甚至长达数年，而云上资源的交付效率近乎实时。降低成本 云计算将 IT 资产的成本由传统的 Capex 资产折旧模型转变为 Opex 的按量付费模型。这样做一方面减少企业的一次性 IT 投入，另一方面也可以让企业按需购买需要的资源，以节省成本。使用云提供的最新技术 云采用框架白皮书 文档版本：1.0 11 云厂商通常在产品技术的投入非常大。因此，云厂商提供的云服务通常在行业中比较领先，例如我们常说的云原生服务，如容器、中间件。提高服务的安全性 云厂商提供的是规模化在线服务。在安全性方面，云厂商有大量的数据

15、能够帮助客户更好的应对互联网上的攻击。业务创新上云 随着数字化转型的浪潮，当前许多企业开始业务创新。云上提供了较为丰富的 PaaS 和 SaaS 服务，因此云也是这部分转型的最佳选择。业务创新上云的主要目的是：云上提供丰富的创新能力，例如 IoT、大数据、业务中台，能够大幅降低企业业务创新的门槛。需要将业务快速推向新的市场。2.2.上云所需的企业组织模型及其核心职责 概述 企业上云和用云的整个生命周期，需要专业团队进行合理的规划、实施以及持续优化云采用方案，推进企业更好的利用上云的优势促进业务发展。本章讨论企业上云过程中所需要的组织模型和对应的核心职责。背景 企业通常至少有一个云管理团队，或由

16、相关负责人组建一个云卓越中心(Cloud Center of Excellence，简称 CCoE)负责规划和对接上云的整体方案，包括在公司层面确认上云的整体计划、步骤，以及收集业务团队的具体需求。了解云卓越中心 CCoE 上云所需的企业组织模型 首先，我们看一下一个典型的企业组织架构。为了便于理解，我们对这个组织结构进行了适当的简化。在这个架构中，不同的团队对公司的整体目标进行拆解，例如业务团队主要贡献公司的营收、流入目标，财务、法务等团队对公司的整体运营风险进行控制，产品技术团队则为业务团队提供技术支撑。云采用框架白皮书 文档版本：1.0 12 核心职责 企业采用云服务的过程中有以下核心工

17、作项：上云策略：从公司战略层面确定企业上云的动机和期望的业务结果。在充分论证企业上云的收益和风险后，最重要的是在公司上下充分传达和教育，确保公司高层、业务、研发、运维、财务、人力资源等各个相关团队统一认识，明确上云战略，各团队能够配合做出相应的计划和调整。制定企业上云计划，包括业务范围、上云的计划节奏、各阶段目标以及最终结果。协调各部门准备相应的预算、调配人员和组建必要的团队。上云准备：准备上云的基础环境，对云服务进行学习和测试，选择小规模的业务进行迁移验证。设计业务上云的整体架构，其中包括迁移方案和基于云技术的创新。规划业务上云的流程，协调业务部门配合实施业务上云。分阶段逐步实施业务迁移上云

18、，并在过程中调整方案，确保业务连续性和稳定性。应用上云：梳理企业应用系统清单，调研应用上云兼容性等相关特征，筛选需要上的云的应用，制定应用的上云策略。持续治理：充分预见和评估企业安全合规等风险，规划企业 IT 治理的整体方案、策略和基本规则，包括资源结构、身份权限、费用账单、合规审计、网络架构、安全策略以及监控规则等。在企业上云和用云过程中，通过治理规则预防、发现和及时治理风险。为了适应云采用框架，组织需要进行以下准备：企业管理层：企业管理层需要明确云在公司的战略地位以及各个团队应该如何使用云。云卓越中心：该团队可以是虚拟的组织，设计提供云服务的模式和管理体系，并提供相应的技术准备。其中的成员

19、包括 o 架构师和专业技术人员，负责上云架构设计和业务上云迁移工作；o 安全、合规等领域专家，负责设计企业 IT 治理方案、预估风险和制定治理规则；o 财务专家，负责制定财务的管理流程，成本分摊原则。云采用框架白皮书 文档版本：1.0 13 云管理团队：在企业业务全面上云之后，持续优化上云架构，为新业务提供云上环境。建立企业云上运维体系，搭建运维平台，以及通过自动化运维的方式，对云上环境进行持续治理和管理。根据新业务需求，分配所需云资源和所需权限，并对资源进行初始化配置后交付。应用运维团队只需用云，无需关注基础设施搭建。综上，平台运维工作也可细分为架构优化、云平台建设、资产管理、权限管理、云自

20、动化等多种职责。云采用框架白皮书 文档版本：1.0 14 3.上云准备 3.1.云上管理和治理框架 Landing Zone 定义 如果把上云框架的搭建比作建设社区，那么企业的中心 IT 团队就是社区的总设计师。一个好的社区通常具备较为完善的顶层设计，最终才能提供优质服务给社区租户。社区规划首先要考虑的是基础设施的布局和建设，包括道路的规划、门禁的管理、停车场的布局、楼房规格的规划等。其次，社区一般也会提供通用服务，例如垃圾分类、水电维修等，以及制定相应的社区规约来管理租户，例如装修时间规定、噪音规定。作为增值服务，高档社区还会提供统一的不同类型的样板间，比如统一水电、装修等。在阿里云，我们建

21、议企业在第一个应用上云前，需要有一整套顶层设计和一系列基础框架，为后续的业务上云扫清障碍。否则，可能会导致后续业务上云面临成本、网络、安全、效率等多方面的问题。业界通常把这些基础框架叫做 Landing Zone，我们也遵循这一命名方法。如上所述，在成熟的运维模型中，通常由企业的中心 IT 团队负责集中管理和管控，然后将云环境交付到业务团队。为了高效地提供安全、稳定的云环境，中心 IT 团队需要搭建一套企业级的管理和治理框架作为云环境的基础设施，为企业上云打好基础。例如，某跨国企业使用阿里云支撑公司多个业务系统，其中包含公司的互联网业务和 ERP，以及内部的 OA等系统，这些系统由不同的团队负

22、责。为了更高效地使用云，公司成立新的“云管理团队”负责和云的对接。“云管理团队”的内部定位是公司负责提供云能力的团队，以此加速 IT 和业务升级。具体而言，“云管理团队”负责云上资源的快速交付、成本控制、质量保证，同时赋能业务部门在安全的前提下进行创新。“云管理团队”在阿里云提供的 Landing Zone 的基础上，构建了整个云服务体系。云采用框架白皮书 文档版本：1.0 15 架构 那么，一个完整的 Landing Zone，究竟包括哪些方面？基于服务众多企业客户的实践总结，我们定义了Landing Zone，其包含如下几个功能模块。后面我们将会对这些模块的设计进行详细的分解以及举例说明。

23、下表简要描述了上述功能模块。Landing Zone 模块 描述 资源规划 规划云上账号及其组织结构。根据公司的运维模式，定义所需要的管控关系。财务管理 管理云平台的合同、优惠、付款关系、账单，以及认证公司在云平台的实体、发票抬头等财务相关的属性。网络规划 规划云上 VPC 的拓扑结构、混合云网络的互联、网络的流量走向、相关的安全措施，以及如何构建高可用和可扩展的网络架构。身份权限 规划谁能够访问云，并通过单点登录 SSO 和细粒度授权实现人员按需访问。安全防护 通过在云上构建基础的安全环境，帮助业务系统在云上快速的安全落地。合规审计 设计治理的目标和流程，并通过相应的工具来实现对于治理规则的

24、监督。云采用框架白皮书 文档版本：1.0 16 运维管理 构建以 CMDB 为核心的运维管理体系，包含标准的发布变更流程，应用和基础设施的统一监控，集成企业的 ITSM 系统，提供自助服务。自动化 定义自动化场景和目标，并通过相应的工具实现自动化。常见的场景如 Landing Zone 自身的搭建以及 CI/CD 流水线的自动化。3.2.阿里云上 Landing Zone 的主要组成部分 3.2.1.资源规划 概述 企业在上云过程中采购云资源满足业务需要，云服务提供商一般会要求企业注册账号作为容器来放置和管理云资源。随着企业上云业务的增多，企业业务自身的复杂度及相互间的关系管理要求更为严苛，企

25、业一般会注册多个账号来应对问题：借助账号间的天然隔离性，使用多个账号实现企业不同业务或应用间的相互独立。针对业务复杂的大型企业，多个账号可以解决多法律实体、差异化结算关系等业务诉求。使用多个账号，可以突破单账号下云资源服务配额限制等约束。在阿里云，我们建议上云之初就规划采用多账号、组织化的资源（账号）管理架构，通过合理的组织结构和规则配置，以满足业务日后扩展的需求。资源目录概述 方案示例 X 公司有多个业务系统，由不同的团队管理。公司在搬迁上云期间，以账号为单元来承接一个个业务系统，并按照公司的业务线结构来组织账号进行管理。每一个应用分为生产、测试环境，用不同的账号隔离开。业务团队根据自己管辖

26、的范围获得相应的权限。接下来，我们将为您介绍多账号资源管理体系建立的设计思路与建议。云采用框架白皮书 文档版本：1.0 17 多账号结构规划 设计建议 使用阿里云的资源目录进行多账号的统一管理。按照业务的组织架构规划账号的组织结构。典型的架构可以选取在根资源夹下创建两个资源夹：Core、Applications。o 在 Core 资源夹中放置共享服务账号，用于集中横向管理类服务的部署，例如共享 VPC。o 在 Applications 资源夹中放置具体的应用。使用资源夹作为日后管控策略和基线实施单元。企业管理账号为资源目录的超级管理员，建议不要将其用于资源目录管理之外的其他任何用途。妥善管理此

27、账号，并设置 MFA 双重验证，加强安全访问管理措施。使用成员账号代表一个应用。建议通过角色扮演的方式访问成员账号。特殊限制 阿里云支持角色扮演方式访问的产品 使用标签描述资源 标签是对资产进行分类的简便方法。标签将元数据关联到资产。该元数据可用于基于各种数据点对资产进行分类。当使用标签对资产进行分类作为成本管理工作的一部分时，公司通常需要以下标签：业务部门，部门，计费单元，地理位置，环境，项目或“应用程序分类”。阿里云费用中心的“分账账单”可以使用这些标记创建成本数据的不同视图。设计建议 提前定义标签的目录和取值范围。绑定标签的背后是一个流程，因此提前设计好如何绑定标签非常重要。明确标签的使

28、用场景。我们建议使用标签用于包括但不限于如下场景：o 使用标签描述应用：一般情况下，组织可根据日常管理层级构建资源归属的标签组合。组合形式一般不会超过 3 个标签。例如，某企业为了能够快速找到对应资源，设计如下标签：云采用框架白皮书 文档版本：1.0 18 project：描述资源项目归属。env：描述资源环境信息。user：描述资源持有者信息。o 使用标签进行分账：阿里云费用中心的“分账账单”支持按标签细分阿里云成本的功能。最常见的情况，客户可以使用成本中心（costcenter）、业务单元（businessunit）或者项目组（project）将成本与业务部门进行关联。在分账账单中，费用报

29、告可以以任何标签维度归纳账单。因此，客户也可以轻松地将成本与技术/安全性维度作为分账维度，例如特定应用程序（application）、环境（env）等。o 自动化运维和监控：自动化运维/自动化开通是在日常业务中比较常见的场景。技术人员往往通过一类标签来定义批量运维、检测的策略。例如：某公司为其日常巡检进行了标签化，创建用途标签键 purpose 来进行日常资源巡检，标签值为 autocheck-8am，即每日早 8 点自动巡检。如果巡检发现异常，通过资源持有者标签 owner 来通知具体责任人进行处理。建立标签的巡检机制，及时发现没有绑定标签的云产品并评估影响和制定应对策略。特殊限制 阿里云支

30、持标签的产品 3.2.2.财务管理 概述 财务管理通常指合同、资金、发票、账单等方面的管理。财务管理是企业上云后面临的第一个问题。通常云厂商会提供较为通用的功能来满足大部分企业的需求，企业则需要根据自己的组织模式选择最优的商业关系。企业在这个阶段遇到的常见问题是：公司如何统一的管理和云厂商的合同、付账、发票？公司如何能够集中监控成本？例如，X 公司选择“云优先”的战略，逐渐将各个业务迁移上云。在出台统一的财务规划之前，部分业务已经先行上云，单独和云厂商签订云服务。在确定“云优先”的战略后，公司针对云厂商制定了统一的财务管理方式，由原来的分散管理模式，改为由公司整体和云厂商签订合同和结算，以便于

31、整体的管理和成本核算。对于不同业务，由业务部门申请相应预算和云账号进行云资源的购买。每个月公司对不同业务使用的云资源的费用进行统计，将成本分摊到不同的业务。在每个月的成本会议上，成本信息会同步到各个业务负责人以及CFO。对于超出预算的业务，业务部门会及时调整预算或者优化成本。财务管理的成功实施，通常要考虑企业财务组织结构、商务合同优惠、结算模式、预算管控等。下面将对这几个方面逐一阐述。企业财务组织结构 云采用框架白皮书 文档版本：1.0 19 企业财务组织结构，通常代表一家企业的成本管理结构。这个结构是多层级的，包括财务管理部门、业务部门和云资源。财务管理部门负责评估和管理云业务预算，为业务部

32、门的云上费用做统一结算，持续跟踪和分析消费账单。财务管理部门的职责通过财务管理部门账号来承载。业务部门负责在预算范围内开通和管理云资源。每个业务部门开通独立的云账号。云资源由业务部门开通和管理，归属于相应的业务部门账号下。使用企业财务服务提供的关联账号能力，将组织多层级结构搭建起来。在这种结构下，财务人员能清晰完整地了解整个企业的云上成本，便于进行消费预测和成本优化。业务部门的技术人员在预算范围内可以灵活地按需实时开通云资源，省去传统企业繁琐的资源申请流程，提升了工作效率。各企业的内部组织结构虽然不尽相同，但业务部门可以同时是项目或小组等成本管理的单元，可以按照自己的组织模式映射成上述结构。我

33、们的建议 财务人员需要与业务部门加强沟通，及时收集业务部门的资源采购计划，定期向业务部门同步成本分摊信息。财务人员需要持续关注费用趋势。财务人员设计标签分类，鼓励技术人员在开通云资源时绑定对应标签，便于基于标签做细粒度的分账。技术人员按需开通资源，在预算范围内优化资源结构。特殊说明 目前阿里云企业财务支持标准企业两级财务管理结构。对于集团公司，当前无法直接满足集团-子公司-部门的三级财务管理结构，需要按照子公司维度拆分成上述多个组织结构分别管理。在企业财务中，财务部门管理账号又称为“主账号”，业务部门账号又称为“关联子账号”。更多信息，请参见企业财务概述。商务合同优惠 商务合同优惠，指企业与云

34、厂商签订的商务优惠合同条款中约定的折扣。云采用框架白皮书 文档版本：1.0 20 企业与云厂商签订商务优惠合同时，需要将财务部门管理账号（主账号）设置为折扣生效的目标账号。这么做的好处是，业务部门账号的开通和云资源的消耗，结算时可以享受到主账号的折扣优惠。结算模式 在企业财务组织结构中完成多层级账号关系的搭建，设置由主账号统一结算，省去各部门独立结算开票的繁琐操作。上图是某企业 10 月份的费用结算图。财务部门管理账号（主账号）有 4 个关联子账号。在 10 月份结算周期内，财务人员可以从系统中看到各部门的费用账单和明细，最终由财务人员统一结算并开具发票。企业财务账号关联包括两种业务模式：财务

35、管理、财务托管。这两种模式的能力对比如下：合同优惠共享 账单统一查看 合并发票 统一付款 关联子账号使用代金券 财务管理 财务托管 关于企业财务业务模式的更多介绍，请参见：企业财务概述。特殊说明 财务管理模式下，不支持为所有子账号的消费合并开一张发票。需要筛选子账号，为指定子账号的消费开票。财务管理模式下，只有当主账号申请了阿里云信控身份，并且将信控身份同步给关联子账号时，主账号才可以为子账号历史消费账单实现统一付款。财务托管模式下，暂不支持关联子账号使用代金券。如果子账号要做 POC（Proof of Concept）测试，目前只能将代金券发放给主账号，且发放给主账号的代金券可能被其他子账号

36、消费而自动冲抵。预算管控 云采用框架白皮书 文档版本：1.0 21 预算管控有强管控和弱管控两种方式。企业可以根据自己的实际情况进行选择。强管控要求业务部门必须在预算内开通和使用资源，超出预算将无法开通新资源，已开通的资源也需要在申请追加预算后才能继续使用。弱管控是一种预警机制，为业务部门分配 quota（配额）额度，对额度做预警通知。即便业务部门的消费已超出额度，也不影响资源的开通和使用。特殊说明 财务托管模式，尚且不支持预算管控。财务管理模式支持强管控方式。主账号可通过信控划拨或余额划拨的能力，为子账号划拨可消费的信控额度或现金余额。子账号信控或余额已用完时，将无法开通新资源或进行升级操作

37、，已开通的资源也将受停机影响，需要联系主账号申请追加预算。3.2.3.网络规划 概述 企业业务上云需要有一个可扩展、安全可控的网络环境。公共云的网络环境与线下 IDC 类似，也是使用 IP地址段作为基本单元划分不同的网络空间，公共云一般以 VPC 为基本单元，每个 VPC 使用一个 IP 网段，若干个 VPC 组成企业云上整体网络空间。由于相同 IP 地址不能互通和 IPv4 地址空间相对较小两个限制，企业在进行上云早期规划时，需要提前做好网络规划，保证网络能够承载企业存量业务的同时，能够具备高可靠和可扩展性，以保证业务的稳定和未来的系统扩容和升级。关键步骤 在网络规划，有三个关键步骤需要决策

38、：1.一是确定所使用的地域，按照业务属性划分若干个 VPC 和各自使用的 IP 地址段。比如，使用阿里云上海地域，共分成 5 个 VPC，分别用来承载公网出入口、官方网站生产环境、官方网站 UAT 环境、内部 CRM 系统生产环境和内部 CRM 系统 UAT 环境。各自的 IP 地址段分别为 10.0.0.0/24、10.0.1.0/24、10.0.2.0/24、10.0.3.0/24 和 10.0.4.0/24。2.二是规划不同 VPC 间的互通、隔离逻辑，决定不同资源之间的路由、安全组或 NACL（Network Access Control List）规则。3.三是确定云上线下环境互联的

39、方式。如果企业有混合云需求，需要确定使用的上云连接方式，比如物理专线、SDWAN、VPN 等。网络规划方案 网络规划的主要场景有云上网络架构设计、云上云下网络互通、云上企业内部网络互通、云上企业间私网访问等，以下将展开说明。云采用框架白皮书 文档版本：1.0 22 场景一：云上网络分区 用户业务系统搬站上云，需要考虑业务系统之间的调用和访问关系，需要关心路由边界，需要关心未来的规模扩展，实现最合理的分区设计、最简单的运维管理、最灵活的弹性扩展。每个分区可以由一个独立的 VPC 承载，VPC 内按照部署的业务模块选择创建不同的虚拟交换机（子网），不同业务系统之间的互通即不同 VPC 之间的路由打

40、通，可以使用云企业网 CEN 打通，同时可以按需进行路由表隔离、路由过滤、路由策略设置等，来满足企业用户的个性化需求。按照使用习惯和业务访问关系，常见的分区有：业务生产区、开发测试区：这两个区域分别用于承载客户生产环境和测试环境的资源。互联网出口区：这个区域类似于线下 IDC 中的 DMZ 区，用于承载互联网出口资源，如 EIP，NAT 网关，SLB，云防火墙等资源。东西向安全区：用来承载南北向防火墙或其他云上 IDS/IPS 防护设备。内联运维区：用来承载跳板机，堡垒机等企业内部人员连接云上环境入口的资源。外联网区：用来承载连接第三方 IDC 等外部环境的跳板机，堡垒机的入口资源。场景二：本

41、地网络和云上网络的连通 云采用框架白皮书 文档版本：1.0 23 在云上构建新的业务系统时，也需要考虑和线下已有的网络进行打通，满足两方面的需求：业务搬站或系统迁移过程中，需要有大带宽、稳定、安全的网络通道。企业用户都会选择先把前置系统优先上云，比较重要的业务系统仍放在云下，一方面需要一个过渡，另一方面利旧云下已投入的 IT 资源，所以混合云状态会长期存在。线下分支机构会有和总部办公室、企业 IDC 之间的内网互通需求，当业务逐步上云后，会涉及到线下分支既需要和线下总部互通，也需要和云上互通。那最好的方案便是打通一张覆盖云上云下多地域的内网，同时确保每两点之间直接互通，不出现绕行。按照云下网络

42、环境的定位、规模和与云上系统的关系，推荐不同的互通方式：IDC 和大型企业总部：推荐使用物理专线互通。针对集团性企业，云下 IT 资源大多在一个大的机房内，通过物理分区或者逻辑分区隔离不同子公司之间的网络，但云上是不同的账号（账号间完全独立），此时可以由集团统一部署大带宽的专线，通过路由子接口和 VLAN 映射的方式把专线分成多个二层通道，每个二层通道关联一个 VBR（虚拟边界路由器），不同的 VBR 供不同的子公司使用，这样不仅资源共享投入产出比高，而且子公司之间的三层网络完全隔离。关于物理专线连接的更多信息，请参见专线介绍。企业分支和小型总部：推荐采用智能接入网关 SAG，通过 SAG 就

43、近入云，打破地域限制，覆盖各种分支形态，形成云上云下一张内网。因为阿里云提供非常多的 POP 接入点，所以分支最后一公里（采用VPN 加密通道）的距离会很短，长传全部走阿里云内网，端到端网络质量仅次于专线，但是价格接近VPN。关于智能接入网关 SAG 更多信息，请参见什么是智能接入网关。特殊分支：针对不方便部署 SAG（如海外偏远分支等）、企业想利旧资产等情况，通过 VPN 网关快速和云上内网打通。虽然效果不如智能接入网关 SAG，但是可以让偏远的分支先解决内网互通的诉求。关于 VPN 网关更多信息，请参见 VPN 网关。云采用框架白皮书 文档版本：1.0 24 场景三：企业内网络互通和隔离

44、因业务发展需要，子公司的业务系统需要和其他子公司或集团业务系统路由互通，但又不能影响其与公司内部其他业务系统的正常通信和安全策略。方案 1：使用 CEN 连接多个 VPC 当企业在不同业务账号中使用 VPC，可以让该 VPC 同时可以接入多个 CEN（可以是同账号的 CEN，也可以跨账号的 CEN），此时该业务系统的网段路由就可以在不同 CEN 的路由域里面，实现按需路由互通，且相互不影响。这样做的好处是：1）简单方便：无需改动业务架构，无需复杂的规划，只需要有一个加入的动作，即可实现异构路由域的快速互通，且不影响已有访问关系。2）边界清晰：VPC 的资源归属未发生任何变化，只是在路由层面进行

45、了网络通道的打通。方案 2：使用共享 VPC 采用共享 VPC，提供一个共享的私有网络环境，参与的业务团队各自部署资源，可以同时解决基础网络互通、资源独立、资产独立等问题。使用效果：1）方便分账：各子公司可以自己购买资源，共享 VPC 一方提供平台和共享资源（如 NAT、VPN、公网出口等）。2）快速满足业务需求：各子公司的资源部署在统一 VPC，路由天然互通。云采用框架白皮书 文档版本：1.0 25 多账号 VPC 的 CEN 互联和共享 VPC 的对比：特性 共享 VPC 方案 多帐号跨 VPC 互联方案 连通性 同 VPC 内天然路由互通。不同 VPC 之间天然路由隔离，使用CEN-TR

46、 进行路由配置。隔离性 使用 NACL 和安全组规则进行隔离。除了使用 NACL 和安全组之外，还可以使用 CEN-TR 进行路由层面的隔离。高级功能 无 可以通过安全VPC设置统一的东西向安全设备来提升内网安全级别。成本 同 VPC 内无收费项。同 region 使用 TR 互联，TR 按加载的实例数和实例之间的流量收费。运维 较简单 较简单 云采用框架白皮书 文档版本：1.0 26 使用限制 默认单个VPC内可创建24个不同帐号的 VSW。默认单个TR最多连接同region内200个TR Attachment（VPC/VBR/CCN）。场景四：公网出口及南北向网络安全管控 随着企业业务云化

47、进程逐渐进入深水区，简单地使用云上资源出公网已经无法满足业务的诉求，安全、成本、权限、监控等诉求的迭代，需要企业有系统性的视角来考虑如何做好公网出口的规划设计：安全：统一 DMZ-VPC 设计，对于企业/集团内的公网出入访问有严格的访问策略加以控制，同时具备可监管能力。成本：所有公网 IP 需具备共享一份或多份带宽的能力，提升带宽利用率，满足业务诉求的情况下做到成本最优。权限：由于组织架构及智能原因，在安全部门的要求下，IT/架构团队需要统一管控公网准入/出权限。各业务方需向 IT 申请才能开通公网访问权限。监控：统一监控，内网/外网访问情况做到可视可追溯，便于及时排查异常流量原因。在企业安全

48、、成本、权限、监控等诉求的迭代下，云上公网出口方案逐渐从原来的分布式公网出口演进为统一公网出口。前者适合企业上云初期，各部门/业务团队可按需使用 EIP/NATGW/SLB 进行各自的公网出口部署，自动度和灵活性较高，同时也带来了企业的云上安全和管理隐患问题；后者将公网出口进行统一部署、统一管理、统一监控、统一安全策略部署，更能满足企业云上的整体监管要求。简单场景统一公网出口架构设计 云采用框架白皮书 文档版本：1.0 27 WAN 区域设计 1）DMZ-VPC 设计：将企业云上整体的 WAN 能力均放在共享服务的 DMZ-VPC，该 VPC 内可按需部署 NATGW、Proxy、FW、行为管

49、理等公网产品。2）安全设计：联动 DDos、WAF、云防火墙等原生安全产品，保障公网出口安全，并结合 NACL实现安全访问策略。3）成本优化：启用共享带宽，并将所有 EIP 加入其中，节约成本。4）权限划分：利用将公网能力统一收口至 IT 部门，部署 DNAT+SNAT，业务 VPC 均通过 CEN实现跨 VPC 访问公网。5）监控管理：使用 NATGW+Flowlog 组合能力，监控公网出入口流量信息，并根据异动排查原因。统一公网出向设计 统一公网出：使用增强型 NATGW，并开启跨 VPC 访问 NATGW 能力。统一公网入向设计（可选）1）统一公网入：使用 DNAT+SLB（私）的方式。

50、2）独立公网入：适用个别业务独立性较强、一定规模的 Web/APP 服务，可在所属的业务 VPC中结合大规格 SLB/ALB 独立部署公网入口。复杂场景统一公网出口架构设计 云采用框架白皮书 文档版本：1.0 28 随着企业云上业务的发展，对于公网访问的场景和功能的丰富度也会增加，包含基础公网能力、第三方供应商 API 接口调用、指定域名访问出口等能力实现。本方案设计 3 个设计点，默认公网出口、第三方供应商 API 接口调用的特殊公网出口，以及指定域名访问出口，均部署在统一出口区域 DMZ-VPC。默认公网出口 在DMZ-VPC内部署增强型NATGW，并申请“统一网络出口”权限开通跨VPC访

51、问功能DMZ-VPC公网能力，实现统一公网出口。账号-1和账号-2的APP-VPC均可通过DMZ-VPC的默认NATGW的SNAT策略出局访问公网，同时并通过 DNAT 策略实现跨 VPC 的公网入口效果。第三方供应商 API 接口调用的特殊公网出口 在 VPC 已有默认 NATGW 的情况下，由于第三方供应商 API 接口调用时需要双方互相针对 IP 地址加白名单，且出口独立性较强，不能影响其他业务或被其他业务影响，需于 DMZ-VPC 再部署一个特殊的 NATGW，将三方目标网段路由给此 NATGW，实现特殊出口。账号-2 VPC 中的 ECS 访问常规公网时从默认 NATGW 出口出局，

52、调用第三方供应商 API 时从特殊公网出口出局。指定域名访问出口 云采用框架白皮书 文档版本：1.0 29 使用 SLB+EIP（ECS）+PrivateZone 方式实现特殊域名出口，将需要指定出口访问的域名部署在 PrivateZone 中并应用于本 VPC。当业务访问指定域名时，会被 PrivateZone 自动解析为 DMZ-VPC 的特殊域名出口的 SLB 私网IP，通过代理的方式从后端服务器的公网出口出局。下面我们将通过一个案例，为网络规划做一个整体性的介绍。方案示例 客户背景和业务系统 客户 X 公司是一家大型企业客户，企业内部各种 IT 应用系统众多，其中部分业务放在云上，如

53、CRM、文件服务、API 服务等。企业核心数据部分仍然部署在线下 IDC 中，需要云上业务系统能够访问到线下 IDC 中的数据。客户需要解决的问题 需要建立云上线下之间的高可靠混合云连接。根据业务需求为每个应用建立隔离的虚拟网络和对应的账号。部分业务支持 Internet 公网访问及流量审计。东西向网络安全防护。阿里云网络解决方案介绍 X 公司采用了阿里云标准的企业级云网络解决方案架构，所有云资源都使用中国香港地域部署，与线下 IDC保持一致。公司按照业务应用划分账号：3 个业务生产账号、3 个业务测试账号。VPC 方面，分别是接入层 3 个公共服务的 VPC、3 个生产 VPC 和 3 个测

54、试 VPC。混合云连接方面，线下 IDC 使用 2 条物理专线与公共云 VBR 打通，两条专线通过 BGP 路由协议实现主主冗余。所有 VPC 和 VBR 都使用云企业网转发路由器连接到一起，确保转发路由器可以自定义 VPC和 VBR 之间的互通路由。网络安全方面，公网出入口的安全审计通过 DMZ VPC 中的第三方防火墙实现，云网络架构可以实现将所有进出企业云上网络的公网流量通过统一的云原生或第三方安全设备进行过滤。内网东西向流量的安全防护通过安全 VPC 中的第三方防火墙实现，阿里云网络在国内云厂商中率先提供的路由穿透功能，可以实现将企业网络东西向流量进行统一管控，节省了分布式部署的成本支

55、出，同时大大降低了运维复杂度。解决方案架构图 云采用框架白皮书 文档版本：1.0 30 3.2.4.身份权限 概述 身份管理和访问控制是 Landing Zone 的基础模块之一。在企业在上云之初，应该首先考虑如何设计和落地身份管理和访问控制方案，而不是创建云资源。这样做的好处是：确保对云资源的任何访问都使用适当的身份，且每个身份拥有“最小够用”（既不过大，也不过小）的权限。确保从不同网络环境、设备、地理位置发起的对云资源的访问都是安全的。当身份、权限发生变化（如新增用户，用户职责发生变化，员工离职、转岗等）时，可以做到持续管理，降低配置难度和管理成本，避免信息泄漏、误操作等风险。在阿里云，我

56、们使用访问控制（RAM）等产品和服务来实现身份管理与访问控制的能力。RAM 概览 方案示例 在上云规划过程中，X 公司识别出有下列身份需要对云资源进行访问。身份类型 权限需求 超级管理员 10 人的云管理团队，其成员需要拥有对云治理服务（如身份、权限、资源、合规、安全、网络、监控、备份等）的管理权限，无需拥有对计算、存储等业务所需资源的直接管理权限，但在需要时可以接管控制权。该团队还可以细分为财务管理员、安全合规管理员、网络管理员、数据库管理员等角色，侧重于云治理框架中某一方面的管理工作。云采用框架白皮书 文档版本：1.0 31 企业员工 各业务团队成员，他们需要使用归属于本部门的云资源进行开

57、发、测试、运维等工作，一般不允许访问其他部门的资源，但如果出现跨部门合作，也应该可以被授权访问其他部门的资源。企业外部人员 部分业务团队，需要合作伙伴获取本部门少量资源的读写权限。企业客户 有些业务部门开发的应用提供代客户保存数据的服务，其业务场景需要允许客户直接访问由客户上传，但保存在企业的云存储中的数据。为了满足上述需求，X 公司按照“最小够用”原则，对所有身份进行精细化权限管理：对于超级管理员、企业员工 使用 RAM 的“单点登录”（Single Sign On,SSO）功能，将阿里云身份系统与企业自有身份系统打通，实现单点登录，并要求所有访问云资源的超级管理员、企业员工等使用 SSO

58、登录阿里云。对于企业外部人员 o 长期使用者，在企业身份系统中创建用户，采用同样的单点登录措施。o 临时使用者，在需要访问的云账号中创建 RAM 角色并授予带时间限制的有限资源访问权限，允许其使用自己持有的云账号进行角色切换登录。对于企业客户 每次客户需要访问云资源时，由企业应用程序为其生成短时有效的安全访问令牌（STS Token），供客户在应用程序内使用。我们用一个图更直观地说明上述精细化权限管理方案。云采用框架白皮书 文档版本：1.0 32 其中，身份集成部分的设计逻辑如下图所示。方案设计思路 下面我们详细说明身份管理和访问控制模块的设计思路。身份管理 针对超级管理员、企业员工和需要长期

59、使用企业云资源的外部人员，应使用企业自有的身份系统，以外部身份凭证登录阿里云。与只使用由云平台颁发的身份凭证相比，这样做有着诸多优势，包括：企业员工可以使用同样的用户名和密码登录企业自身应用和云平台。根据用户在企业身份系统中的指定属性，例如：根据其所属的组，来对应在云上不同账号、不同资源的操作权限。当员工转岗、离职时，只需要在本地进行转移组、删除等操作，即可解除其在云上的权限，不会造成信息泄露。云采用框架白皮书 文档版本：1.0 33 在各类外部身份凭证中，最常用的是由企业自有的身份系统（Identity Provider,IdP）提供的基于 SAML 2.0协议的身份凭证。阿里云提供基于 S

60、AML 2.0 协议的 SSO 能力，以满足企业使用外部身份凭证登录阿里云的需求。根据登录后转换成的云平台身份不同，SSO 又可以分为用户 SSO 和角色 SSO 两种。详细信息，请参考 SSO 概览。我们建议企业客户使用角色 SSO，并将企业 IdP 中的用户组映射到阿里云 RAM 角色，从而实现对企业内外部员工的有效管理。下面简要介绍企业对使用云资源的人员进行身份集成管理的工作模式。准备自有 IdP 企业需要首先准备自有 IdP，才能完成 SSO 配置。企业应做如下考虑：如果企业已经具有支持 SAML 2.0 协议的身份管理系统，如 Azure AD，ADFS 或企业自建 IdP，可以直接

61、用来与阿里云 RAM 进行 SSO 配置。对跨国企业、除云资源外还有其他云上应用需要访问的企业、需要与钉钉进行集成的企业等，可以考虑购买 Okta、阿里云 IDaaS 服务等云上 IdP 服务。对希望快速搭建 IdP 并开始使用的企业，可以考虑用开源软件如 KeyCloak、Shibboleth 搭建 IdP，也可以参考简单的开源实现。上云初期的一次性配置 在上云初期，企业需要进行一次性的初始化身份集成配置，主要步骤包括：1.在 IdP 配置一个与阿里云进行角色 SSO 的应用。2.为该应用分配使用的用户和用户组。3.根据阿里云角色 SSO 配置要求进行 SAML 属性配置。4.在每个阿里云账

62、号中配置身份提供商。5.测试配置结果。新增或移除阿里云账号时的配置 在企业新增或移除阿里云账号时，需要相应进行 SSO 配置修改，包括如下：根据 IdP 的 SAML 属性配置方式不同，可能需要进行配置修改，或重新分配用户与用户组。在新增账号中配置身份提供商。在移除账号中删除身份提供商。人员变动时的配置 当企业发生访问云资源的人员配置（新增用户，删除用户，变更用户权限）时，通常不需要进行 SSO 配置修改，只需要对用户和用户组进行操作，包括如下：云采用框架白皮书 文档版本：1.0 34 新增用户时，应在 IdP 中将其加入到已经配置了 SSO 访问的用户组。删除用户时，可以直接删除即可，IdP

63、 通常会自动移除其访问权限。用户权限发生修改时，应修改其用户组配置。访问控制 阿里云实现了基于属性的访问控制（Attribute Based Access Control,ABAC），这是一种权限描述能力强，可感知访问上下文以进行精细权限管理的先进访问控制机制。当客户请求到达阿里云时，阿里云将评估当前访问的请求特征、身份特征、资源特征，并与身份所配置的权限进行匹配，从而完成鉴权。每个云产品支持的身份和访问控制粒度可以参见支持 RAM 的云服务和支持 STS 的云服务。针对大部分人员用户来说，可以根据其职责进行较粗粒度的权限划分即可，一个企业通常针对如下几种角色进行权限设计：全局云管理员：拥有企

64、业在阿里云上资源的全部权限。网络管理员：拥有对各类网络产品的管理权限。数据库管理员：拥有对各类云上数据库的管理权限。监控管理员：拥有云监控、应用实时监控等服务的管理权限。安全管理员：拥有全部安全产品的管理权限。合规管理员：拥有合规相关产品的管理权限。日志管理员：拥有日志服务的管理权限。日志查看者：拥有读取日志的权限。应用管理员：只拥有某个应用所对应的资源权限。普通用户：不具备任何云上资源访问权限，只在必要时进行单个权限点授权。同时，还需要根据人员访问条件进行限制：所有人员必须在企业内网访问云资源（使用 IP 限制策略）。对于临时身份，同一种应用场景可以只使用一个 RAM 角色，但针对每个会话授

65、予单个资源、具有访问时间限制的权限，以确保权限最小化。说明 在进行角色 SSO 配置前，需要了解企业所使用的云产品是否支持 STS（即 RAM 角色访问），如果有不支持角色访问的产品，可能需要进行特殊考虑，如使用额外的 RAM 用户访问此类产品，或配置用户 SSO 等。最佳实践 RAM 角色集成企业 AD FS 身份认证 RAM 角色集成企业 OpenLDAP 身份认证 云采用框架白皮书 文档版本：1.0 35 3.2.5.安全防护 概述 Landing Zone 的安全架构主要包括：访问控制（这部分内容已在“3.2.4 身份权限”章节中描述）网络安全 计算安全 数据安全 通过在云上构建基础的

66、安全环境，帮助业务系统在云上快速且安全地落地，如下图所示。1.网络安全 阿里云上的网络区域通常是以层次化的方式由外部向内部进行划分的，概括来说，通常会有三个层级的网络区域结构：第一层级（地域与可用区）第二层级（虚拟专有网络 VPC）第三层级（子网与资源边界）云采用框架白皮书 文档版本：1.0 36 基于阿里云上三个层级的网络区域，自然也就形成了云上三道网络边界，也就是网络安全中常见的“层次化防御”的推荐架构：第一边界：互联网边界（南北向流量）云上业务如果对互联网开放，或是需要主动访问互联网，那流量必定会穿过阿里云与互联网的边界，也就是云上网络的第一道边界互联网边界。对于该类流量，我们通常称之为

67、南北向流量。针对这类流量的防护，在等保中有明确的要求。由于存在流量主动发起方的区别，防护的重点一般也会区分由外向内和由内向外的不同流量类型。第二边界：VPC 边界（东西向流量）VPC 是云上最重要的网络隔离单元，客户可以通过划分不同的 VPC，将需要隔离的资源从网络层面分开。但同时，由于业务的需要，部分流量又可能需要在 VPC 间传输，或是通过诸如专线、VPN、云连接网等方式连接 VPC，实现 VPC 间应用的互访。因此，如何实现跨 VPC 边界流量的防护，也是云上网络安全很重要的一环。第三边界：云资源边界（微隔离流量）由于 VPC 已经提供了很强的隔离属性，加上类似安全组的细颗粒度资源级管控

68、能力，通常在 VPC 内部不建议再进行过于复杂的基于子网的隔离管控，通常会使用安全组在资源边界进行访问控制。如果客户需要更精细化的 VPC 内子网隔离，也可以使用网络 ACL 功能进行管控。云采用框架白皮书 文档版本：1.0 37 2.计算安全 云上计算安全维度一般包含云主机安全和云容器安全：云主机安全 防护重点 1：入侵检测 阿里云用户可以通过云安全中心为用户提供的实时入侵检测能力，对异常登录、网站后门查杀（Webshell）、主机异常行为、主机系统及应用的关键文件篡改和异常账号等行为进行检测。同时，云安全中心还提供智能学习应用白名单的能力，识别可信和可疑/恶意程序形成应用白名单，防止未经白

69、名单授权的程序悄然运行，可避免主机受到不可信或恶意程序的侵害。防护重点 2：病毒检测 对主流勒索、挖矿、DDoS 木马等病毒的实时拦截能力，由云安全中心提供：在系统内核层面实现云上文件和进程行为的全局监控和实时分析，有效绕过顽固木马和恶意程序的反查杀能力 基于程序行为分析，挖掘出黑名单未能辨识的恶意威胁，实现主动拦截 云端病毒库实时更新，集成了国内外主流杀毒引擎、阿里云自研沙箱和机器学习引擎等前沿技术，可以避免因病毒库更新不及时而造成的损失。防护重点 3：漏洞管理 阿里云用户可以通过在主机上安装轻量级安全代理，实现和云端安全中心联动，提供最新的漏洞扫描的安全能 力，帮助用户实现同时对多个系统和

70、应用进行扫描和修复的安全运维工作。目前已支持检测主流 Windows 系统漏洞、Linux 软件漏洞、Web-CMS 漏洞、应用漏洞，同时还能为官方未能提供补丁的应用提供应急漏洞修复，以及临时提供针对网络上突然出现的紧急漏洞的检测和修复服务。防护重点 4：OS 和镜像加固 阿里云自研的 Aliyun Linux 2 OS 已经发布了经过国际第三方 Cyber Internet Security（CIS）组织认证的 OS Benchmark。用户可以遵循 CIS Benchmark 中的安全最佳实践（Remediation）操作规范来对 OS 进行安全加固，也可以通过遵循 CIS Benchma

71、rk 中最佳实践的加固脚本（Remediation Kit）来对 Aliyun Linux 2 OS 进行自动加固。CIS Benchmark 文档和加固脚本可以通过 CIS 官方网站免费获取。云容器安全 防护重点 1：入侵检测 云采用框架白皮书 文档版本：1.0 38 与主机安全类似，阿里云容器服务当前已经支持基于云安全中心的入侵检测，当前云安全中心在容器服务产品支持容器内 Web-CMS 漏洞检测和修复、Webshell 检测和修复、云查杀、进程异常行为、异常网络连接、进程启动日志、网络连接日志的功能。防护重点 2：镜像扫描和签名 针对基于 Linux 的部分基础镜像，阿里云容器镜像服务已

72、经提供了镜像安全扫描的功能，发现与扫描镜像相关的最新 CVE 安全漏洞信息，同时在适用的情况下会向用户提出漏洞修复建议。同时容器镜像的签名和校验可确保仅在 ACK 上部署经过容器使用方签名确认的容器镜像。通过强制执行验证，可以确保仅将经过验证的镜像集成到构建和发布流程中，从而对容器环境实施更严格的安全控制。同时也可以依赖二进制授权校验进行进一步的安全策略配置。防护重点 3：容器运行基线检查 通过针对容器环境的基线检查，发现潜在的基线合规问题，参考业界常用的 CIS Benchmark for Docker、CIS Benchmark for Kubernetes，以及阿里云容器最佳实践，进行安

73、全配置的维护。3.数据安全 云上数据安全参考数据安全成熟度模型，提炼出在云上构建数据安全的基础能力。防护重点 1：数据分类分级 每个企业都会有适用于其自身所在行业以及业务特点的标准和体系。分类分级标准的制定，并不应当只是纸面上的工作，而应该结合企业所在的行业和业务特点，有针对性的进行设计，并通过自动化的手段，辅以手 云采用框架白皮书 文档版本：1.0 39 工的方式，对海量的企业全域数据资产进行识别与分类，有效定位企业关键以及敏感类信息在企业数据资产中的分布和流转情况，并通过定级有针对性的进行保护。数据安全中心提供对数据源中保存的敏感数据的自动识别能力，对文件提供基于内容的敏感数据识别，且支持

74、 OCR（印刷文字识别）技术，对图片中保存的敏感信息进行提取和识别；同时内置深度神经网络和机器学习等先进技术，通过样本扫描、特征萃取、特征对比和文件聚类等算法，实现多达 44 种敏感数据的精准识别。同时数据安全中心提供了敏感数据发现后的自动分类分级以及统计展示能力，通过对结构化和非结构化数据源的敏感数据识别，自动对敏感信息进行识别结果归类。防护重点 2：静态数据防护 随着企业的数字化转型，数据会存储在各类云中提供的存储服务中。从最传统的块和文件类存储，到数据库、数据仓库类型的结构化存储，再到缓存、对象存储等新型存储方式，企业的数据会分布在各类应用系统和所使用的数据存储中。如何在数据存储的过程中

75、保护数据的保密性、一致性和可用性，是数据安全在存储阶段的重点。其中对于数据的加密和脱敏，是企业最常见的保护手段。数据加密 加密服务通过在阿里云上使用经国家密码管理局检测认证的硬件密码机，帮助客户满足数据安全方面的监管合规要求，保护云上业务数据的机密性。借助加密服务，用户可以进行安全的密钥管理，并使用多种加密算法来进行加密运算。密钥管理 密钥管理服务提供安全合规的密钥托管和密码服务，助您轻松使用密钥来加密保护敏感的数据资产，控制云上的分布式计算和存储环境。您可以追踪密钥的使用情况，配置密钥的自动轮转策略，以及利用托管密码机所具备的中国国家密码管理局或者 FIPS 认证资质，来满足您的监管合规需求

76、。数据脱敏 数据安全中心通过多年的内部沉淀，为广大云上开发者提供了近 30 种数据匿名化和去标识化算法，无论是应用开发人员，还是数据安全管理者，都可以根据实际业务场景灵活选择，自定义参数，做到个性化数据脱敏。数据安全中心提供了自定义脱敏模板能力，真正做到安全自适应。企业数据安全管理者可以通过自适应的脱敏解决方案，完成各类不同场景的数据脱敏分发，例如定期从生产环境向开发测试环境脱敏，不同数据类型（如 OSS 中的 csv 向 RDS 的数据表）之间的异构脱敏，数据库层面的原库/原表脱敏等等。防护重点 3：动态数据防护 数据传输过程中使用的网络通道不同，保护方式也会不同。对于客户端通过互联网发起的

77、访问，一般建议企业使用 SSL/TLS 证书来加密传输通道，防止发生中间人攻击窃取传输过程中的重要数据；对于企业站点间的数据传输，通常会使用 VPN 或专线对通信链路进行加固。云采用框架白皮书 文档版本：1.0 40 阿里云通过提供 VPN 服务，帮助企业构建端到端的数据加密通道，保障数据传输过程中的通信安全。同时阿里云还为用户访问网站提供了 SSL/TLS 协议来保护数据。阿里云证书服务可以在云上签发第三方知名 CA 证书颁发机构的 SSL 证书，实现网站 HTTPS 化，使网站可信，防劫持、防篡改、防监听，并对云上证书进行统一生命周期管理，简化证书部署，一键分发到其它阿里云的产品（包括 C

78、DN、SCDN、DCDN 和 SLB 等）。防护重点 4：数据安全审计 等保2.0 针对数据安全提出了“安全审计”和“个人信息保护”的相关要求。随着数字化转型的深入发展，企业重要数据已经从传统单一的数据库存储扩大到各类数据存储、大数据和数据中台等，统一的数据安全审计成为管理难题。数据安全中心可以实现对云上各类数据源的安全审计，并在此基础上深耕防泄漏场景，帮助客户实现全域数据的风险感知。利用机器学习技术，为数据的访问行为建立安全基线，在发生潜在数据风险，例如异常时间或地点访问时，及时预警并提供针对性的溯源能力和防护建议，化静态检测为动态感知，帮助客户快速应对突发的数据安全事件，提升整体响应能力。

79、3.2.6.合规审计 概述 企业往往需要应对来自企业外部和内部的审计合规要求。企业外部的三方审计认证机构会依据国家法律法规和行业标准对企业进行审计评测，要求企业在管理IT 系统时具备足够的可见和可控性，如必须保留 180 天及以上的审计日志。外部审计评测不通过则很可能会影响企业的经营资质和正常的商业活动。而在企业内部IT运维团队和安全合规团队往往承担着巨大的风险。为了充分利用云的灵活性和敏捷性，企业将业务搬迁上云。相比于传统云下的 IT 系统，运维团队面对更庞大的 IT 规模、更复杂的拓扑关系、更高频的运维动作，这使每天的运维工作潜藏着巨大的风险，也让安全合规团队的监管工作面临更大的挑战。一旦

80、运维管控或安全监管不充分，就很容易发生错误操作、失误操作、遗漏操作，致使业务中断或重要业务数据泄露，使企业遭受巨大损失。阿里云建议企业通过审计合规能力构建一个可见、可控、可追溯的安全运维环境：可见：可见的才是可控的，企业首先要确保能看到 IT 资源清单、IT 资源状态、IT 资源的详细配置、IT资源拓扑关系，以及实时的运维动作及资源变更。可控：在企业的运维团队管控云上 IT 资源的整个过程中，在合适的环节设置卡点。阻止红线行为的发生，及时发现并修复非法配置。可追溯：记录云上管控的整个过程并长期留存，这对于故障排查和历史问题回溯有必不可少的作用。也让企业能够基于历史不断完善和优化运维框架。云采用

81、框架白皮书 文档版本：1.0 41 如果把企业运行在云上的业务比作行驶在高速上的车队，那审计合规就是高速护栏、违章摄像头和行车记录仪，这会使企业 IT 运维团队和安全合规团队有可见的抓手和可控的手段，是使自身工作低风险进行所必需的能力。审计：客观记录云上 IT 运维的全过程，并做长期留存。合规：通过限制和持续监控，确保 IT 配置始终符合合规预期。示例 X 企业在上云之初启用了完整的审计合规能力，在后续长达数年的持续运营中，依赖审计数据和合规能力解决诸多问题。在上云之初开始记录云上 IT 的操作日志并长期留存。这些日志一方面可以满足三方审计的要求（留存180 天及以上的审计日志），另一方面通过

82、对历史日志的建模分析得到该企业的安全运维数据画像，该画像将有助于在后续运维中及时发现异常的来访 IP 和异常的管控动作，及时制止风险发生。企业持续记录云上资源的配置变更历史。即便是某些资源已经被释放，仍然能在数月后回溯当时保有的资源以及资源的详细配置，包括资源全生命周期的变更和标签信息。测试业务在云上运行一段时间后，在正式业务上云之前，X 企业先在云上实施了最基本的合规管控策略，让业务一开始就跑在一个可控环境下：除了指定的几个用户和角色，禁止授予其他用户角色 Admin 权限 禁止授权中出现“*”限定资源采购的地域、规格、数量 除了指定的几个用户和角色，其他人禁止采购和释放资源 强制设定强密码

83、策略 必须开启基础计算、存储资源的删除保护功能 .审计合规管理工具 IT 运维团队管理云上资源的过程中，有三个关键环节：事前限制、事中及时发现和修复、事后审计记录，对应的环境在阿里云上都有匹配的云服务或功能。云采用框架白皮书 文档版本：1.0 42 事前限制：禁止零容忍违规的发生，禁止修复成本极高的违规发生。事中发现和修复：在日常管控中需保留足够的灵活度，所以并不是所有事情都能一开始被拦截禁止，那就需要在灵活管控的过程中及时发现不合规问题并快速响应修复。事后审计记录：无论企业是否实现了事前限制和事中发现修复，事后审计都是最基本的手段，确保在问题暴露出来后有线索可排查和追溯。关于合规策略的设计将

84、在第 5 章运营治理中详细阐述。合规策略的本质目的是实现长期的持续的风险控制，通过禁止违规操作、及时发现并修复非法配置来保证云上 IT 的配置始终符合运维团队的预期要求，避免 IT配置失误造成的数据泄露或业务中断等。合规策略的制定需要充分考虑在企业不同的发展阶段所面对的潜在风险，识别风险、量化风险、制定合规策略、建立流程确保合规策略的运转，这是另一个庞大的方法体系。这对于企业在云上长期的安全稳定至关重要，更多信息请您参阅第 5 章运营治理。使用限制 管控策略（Control Policy）和阿里云配置审计（Cloud Config）服务目前仅支持部分核心产品，仍在持续更新中。了解权限策略 阿里

85、云配置审计（Cloud Config）服务中部分检测规则不支持修正模板，仍在持续更新中。了解配置审计 3.3.基于 IaC 理念快速部署 Landing Zone 概述 当企业确认好 Landing Zone 的设计方案，接下来就是需要实施部署到云上了。实施的方案有多种，除了云上的服务之外，一些第三方的工具也可以协助您完成整个Landing Zone的搭建。这里，我们以Terraform为例，借助 IaC 的理念，提供了一个包含基础设施构建（多账号体系搭建、网络规划、访问控制、安全合规），以及账号工厂（新账号初始化）的 Landing Zone 的搭建过程示例。云采用框架白皮书 文档版本：1.

86、0 43 IaC 理念 IaC（Infrastructure as Code,基础设施即代码）是使用软件开发原则和实践的基础设施自动化。简而言之，就是把基础架构像软件一样来对待，然后通过编写、测试和执行代码以定义、部署、更新和释放基础架构。通过编写代码来管理云上 Landing Zone 的部署和配置，可以更快地实现基础设施的交付，降低手工配置的成本，监测配置偏移，以实现自动化、可维护的部署和实施过程。当需要更改 Landing Zone 的设计方案时，可以更改代码，对其进行测试，然后将其应用于系统中。设计建议 我们在示例代码中展示了一个完整的 Landing Zone 部署方案，但不同的企业

87、都会有不同的需求。您可以克隆我们的示例代码，并自定义修改，以满足您特定的需求。在设计和实施过程中，我们建议您考虑以下原则：独立的 POC（Proof of Concept）验证环境：创建单独的云账号，用于基础设施等的验证。一个 Landing Zone 的实施包含了很多方面的内容。一个独立的 POC 环境有助于您发现代码中的问题，并且方便后续方案修改。在应用到生产环境之前，也可以作为验证阶段，避免影响线上业务。选择合适的地域：在部署网络等资源之前，确保选定的地域有满足您业务所需的资源类型。您可以参考对应云产品的官方文档，来确认所需资源是否在您选定的地域提供服务。使用 Terraform bac

88、kend 保存部署状态：通过使用 Alibaba Cloud Terraform provider 提供的backend 能力，将 Terraform 执行过程的状态保存在云端，避免状态保存在本地丢失导致后续难以变更，同时也便于多人协作。使用 Terraform workspace 来隔离不同云账号的状态：在账号工厂新建云账号过程中，我们建议您给每个新账号都创建唯一的workspace，后续在该账号中部署业务资源时，也可以复用该workspace。使用版本控制管理部署脚本：基于 IaC 理念将基础设施代码化后，即可加入到版本控制里。通过版本控制，可以实现基础设施架构变更的追踪、回滚等能力。使用

89、 CI/CD（Continuous Integration/Continuous Delivery）流程实现自动化部署：结合 CI/CD 流程，可以实现代码变更后的评审、预检查、自动化部署，规范化运维链路，保障实施过程的准确性。因为部署过程中需要用到的 AK 权限较大，使用自动化流程，可以避免 AK 存放在运维人员电脑上，降低 AK 泄露风险。同时，对于账号工厂能力，也可以结合企业 ITSM 系统，实现业务方提交新账号需求，审批通过后自动完成账号创建，提升效率。Landing Zone 示例代码介绍 您可以在我们的官网 Github 仓库查看示例代码。这里我们针对复杂企业、跨国企业样板间案例进

90、行介绍。在示例脚本中，我们包含了两大模块：foundations：即基础设施，在该模块中，会完成云上 Landing Zone 基础的搭建。如果后期Landing Zone 的设计方案没有变化，该模块只需要运行一次即可。具体包含以下内容：云采用框架白皮书 文档版本：1.0 44 o 多账号结构：初始化 Core、Applications 资源夹以及创建 SharedServices 账号。o 身份管理和访问控制：初始化安全策略，在 SharedServices 账号中创建相应角色。o 网络：基于 SharedVPC 方案，在 SharedServices 账号中初始化网络架构，会创建 DMZ

91、VPC、SharedServices VPC、生产 VPC 和非生产 VPC，并通过 NACL、云防火墙等实现网络访问控制。o 治理框架：创建多账号统一的操作日志投递和跟踪，初始化基础的配置审计规则。account-baseline：即账号工厂，用于创建新的用于部署业务的云账号。具体包含以下操作：o 账号创建：通过资源目录创建账号并放入 Applications 资源夹内。o 访问控制：初始化基础的 RAM 角色。o 网络：在 SharedServices 账号中的生产 VPC 和非生产 VPC 内创建业务使用的 VSwitch，并通过资源共享能力，共享给该业务云账号，同时配置适当的 NACL

92、 规则实现业务间的访问控制。o 治理框架：这部分由于已经在 foundations 中配置过，所以在创建新的业务云账号过程中，无需再次配置。在具体的实施过程中，账号工厂需要在基础设施初始化好之后才可以运行。基础设施运行完毕后，会打印出已经创建好的资源信息，账号工厂创建新账号的过程，会依赖这些信息。后续如果需要新的云账号，可以再次运行账号工厂模块，提供一份新的配置，完成云账号的创建和初始化步骤，以保障所有的业务云账号，都能够满足企业 Landing Zone 的设计要求。部署 Landing Zone 接下来，我们通过示例代码，介绍 Landing Zone 的部署过程。在开始之前，我们假设您已

93、经对 Terraform 的使用方式有了一定的了解。如果您还不熟悉 Terraform 的操作，请参考 Hashicorp 官方提供的文档。在开始部署之前，请先在管理账号下创建一个 RAM 用户，并授予 AdministratorAccess 权限，生成一个AK，用于执行接下来的所有操作。基础设施初始化 首先将我们的示例代码克隆到您的本地，然后进入到 example/03-complex-enterprise/foundations 这个文件夹。我们提供了丰富的配置项，您可以通过修改 settings.tfvars 中的配置项，来自定义您的 Landing Zone设置。在执行过程中，Terr

94、aform 会自动使用您修改后的配置项。在 foundations 的配置项中，主要包含基础设置（basic_settings）和网络设置（network_settings）两个部分，我们首先看一下基础设置部分。云采用框架白皮书 文档版本：1.0 45 在该部分，先关注一下 shared_services_account_roles 这个配置项，该配置项定义了 SharedServices 账号内置的角色，是个数组，可以根据需求进行修改和添加。比如需要新增一个查看监控的角色，则在最下面新增：role_name=EnterpriseIdP-MonitorViewer policies=Aliyu

95、nCloudMonitorReadOnlyAccess 接下来，治理项的配置 governance 也建议进行修改，因为审计日志投递到的 OSS Bucket 以及审计跟踪的名称均需要全局唯一，不能和其它用户的命名重复，建议修改为一个含有企业特定标示的名称（假定这里公司名为 AlibabaCloud），如下：governance=bucket_enterprise_audit_logs=alibabacloud-landingzone-enterprise-audit-logs trail_enterprise_audit_logs=alibabacloud-enterprise-audit-

96、logs 在 network_settings 中，请关注每个 vpc_开头的配置项里的 cidr_block，代表了该 VPC 的网段。请根据自身业务规模合理规划网段，确保能够容纳所需资源数量，并且保证四个 VPC 的网段不重合，一旦设置并部署业务之后，后期难以修改。确保配置项正确后，通过 Terraform plan 预检查配置，确认无误后执行 apply 命令，耐心等待基础架构初始化成功。初始化成功后，Terraform 会返回类似下方的输出，请妥善保存该输出，便于后续执行账号工厂的步骤。foundations=cloudfirewall=cen_instance_id=cen-xxxx

97、xxxxxx vpc_dmz_cidr_block=10.34.11.0/24 .master_uid=88 rd_folder_application_id=fd-xxxxxxx 云采用框架白皮书 文档版本：1.0 46 shared_services_uid= 云采用框架白皮书 文档版本：1.0 47 4.应用上云 4.1.企业应用上云规划 4.1.1.上云评估模型 随着企业信息系统的持续建设，IT 与业务不断的融合，企业应用类型及模板不断发展，怎么从大量企业应用系统中，筛选需要上云的应用，确定应用上云的策略及优先级，是上云实施前需要做的事情。所

98、以，我们建议在企业进行上云迁移实施前，对企业总体应用进行上云规划，以企业上云战略及规划为指导方向，梳理企业应用系统清单，调研应用上云兼容性等相关特征，制定应用的上云策略，以及应用上云迁移优先级。阿里云上云评估模型如下图所示。云采用框架白皮书 文档版本：1.0 48 4.1.2.业务调研 上云规划阶段调研的目的是制定应用的上云策略，以及上云优先级，所以，这一阶段，我们调研的信息，主要包含上云兼容性，以及业务痛点及规划、安全合规要求等。上云兼容相关特征 上云兼容性主要包含基础设施相关兼容性以及应用架构兼容性特征 基础设施兼容性特征 硬件依赖性：是否有特殊硬件要求，比如 USB 加密狗等 性能要求：

99、是否有特殊性能要求，比如运行环境 CPU、内存规格，IO 或网络要求等，云上是否能满足 操作系统要求：是否有特殊版本操作系统要求，云上是否能提供 应用架构兼容性特征 集中式/分布式架构：应用是否分布式架构，以及使用的分析式架构框架，是否有对对应的 PAAS 产品支持兼容 源代码可控性：源代码是否操作及维护，是可有能力支持上云迁移或改造 技术组件上云兼容性：包含数据库、存储、中间件等技术组件，是否有对应兼容的云产品 其他特征 业务/技术痛点或诉求：是否有业务或技术上的痛点或诉求，比如当前集中式架构迭代速度无法支持业务快速发展，需要做微服务改造 资源/数据增长需求：当前基础设施环境，是否满足业务预

100、期的资源或数据增长需求，以及数据增长要求对架构提供优化需求，比如数据库容量未来无法业务未来数据增量，在上云同时，需要做水平拆分 安全合规要求：是否有行业特征的安全合规要求，云的安全合规等级是否满足行业要求 容灾要求：是否容灾或数据灾备要求，云产品能力是否支持 4.1.3.应用上云策略及决策流程 上云策略 上云规划阶段，需要确认应用的上云策略，是否平迁或改造上云，根据阿里云的以往项目实践，我们建议的上云策略包含以下几点。保持现状 保留应用程序在当前的 IT 环境，作为非云基础设施的一部分 云采用框架白皮书 文档版本：1.0 49 平迁上云 应用比较容易移植到云环境上，使用云产品可替兼容替换技术组

101、件，少量修改应用配置后重新部署到新的云平台。优化上云 通过使用云上 PaaS 产品及服务，对应用进行局部优化，提升性能或稳定性。重构上云 应用组件不适配云的架构，或者不符合成本效益，因此需要对应用进行重构，基于新的云平台构建云原生架构的应用。决策流程 根据业务调研阶段输出的应用系统清单及应用特征数据，每个应用最终对应上云评估策略的中一个类别。其决策流程可以参考下图。4.1.4.应用上云优先级及计划 考虑到企业应用系统规模较大，各方面资源无法保障所有应用系统并行上云。所以，我们建议制定应用上云优先级，并明确迁移批次及计划，使得所有资源能够有效被利用，并降低上云风险。我们建议应用上云先级级的制定，

102、以“速赢”为原则，即优先迁移上云难度低且上云收益高的应用。根据应用的上云难度及上云价值收益，可以将应用上云优先级，划分低中高三个象限，应用上云批次确认后，根据企业上云战略及规划，制定企业应用上云总体实施计划，云采用框架白皮书 文档版本：1.0 50 4.2.应用上云实施 4.2.1.应用上云实施流程 阿里云基于业界最佳实践和大量上云项目的经验累积，总结出以下迁云流程，这一过程建立在完成了企业应用上云规划后，以应用为单位进行进一步的迁移计划和实施。4.2.2.应用调研 在上云实施阶段，应用调研的目标，是为了解应用的应用架构以及使用的技术组件，以制定云上目标详细方案，包含云上应用架构设计，产品选型

103、及容量评估、迁移方案以及割接方案等，所以这一阶段调研的信息比较详细。应用架构及依赖 应用架构：应用模块及模块间关系，节点配置及数量；应用开发语言及框架。应用依赖：其他应用间的依赖关系，以及外部依赖，主要用于割接方案参考；技术组件 数据库：数据库类型，版本，数据量，性能要求等；中间件：中间件类型，版本，集群规模及容量【可选】，如消息队列、缓存等；存储：使用存储设备的接口协议，及数据量；应用性能基线 应用的性能指标要求，用于测试验证阶段性能测试目标参考；调研工具 如果企业系统非常庞大，应用之间耦合多，各系统的负责部门不同，人工收集的方式难免会有疏漏，难以完整厘清所有应用系统以及系统间的复杂依赖关系

104、。我们建议使用阿里云提供针对企业应用上云场景提供应用发现服务（Application Discovery Service），满足企业在迁云阶段的评估、规划、建设、迁移的需求评 云采用框架白皮书 文档版本：1.0 51 估。采用无侵入式采集技术，不影响在线业务的性能前提下从主机和进程两个维度构建架构拓扑，自动分析识别主机和进程信息、资源使用水位以及各应用和组件之间的依赖关系。更多详情，请参见应用发现服务。4.2.3.应用上云方案设计 基于应用调研结果，针对平迁上云、优化上云、重构上云三类应用上云策略，结合我们以往项目实践经验，以下分别给出典型场景的示例上云方案。平迁上云方案 产品选型策略 针对传

105、统应用平迁上云场景，常见产品对标选型策略如下图所示。场景示例：单体应用迁移 云上重部署应用 针对平迁方式的应用上云场景，对于已有成熟 CI/CD 工具及流程的企业，我们建议优先使用现有 CI/CD 工具，在云上重新部署应用。对于还没有构建 CI/CD 能力的企业，我们建议先使用云上 DevOps 产品构建企业的 CI/CD 自动化平台，通过 CI/CD 流水线，在云上重新部署应用。基于阿里云云效产品构构建 CI/CD 流水线如下图所示。云采用框架白皮书 文档版本：1.0 52 镜像迁移 对于普通单体应用，也可以使用阿里云自主研发的迁移平台服务器迁移中心（Server Migration Cen

106、ter，简称 SMC），可将单台或多台迁移源迁移至阿里云。迁移源（或源服务器）概指企业待迁移 IDC 服务器、虚拟机、其他云平台的云主机或其他类型的服务器。在应用服务迁移过程中，使用 SMC 服务将在 IDC 部署的业务应用服务自动、快速、一站式迁移到云上 ECS，同时提供工具支持将自建 Kubernetes 的应用迁移到云上。更多详细信息，请参见 SMC 最佳实践。优化上云方案 场景示例：应用容器化上云 以 Kubernetes 为代表的容器技术正成为云计算新界面。容器提供了应用分发和交付标准，将应用与底层运行环境进行解耦。Kubernetes 作为资源调度和编排的标准，屏蔽底层架构差异性，

107、帮助应用平滑运行在不同基础设施上。应用容器化规范化改造 容器化的应用必须要规范化，我们不希望所完成的容器镜像只能在生产环境中运行，也不希望该容器有着外部依赖，我们希望应用在容器化之前，最少满足这三项要求：与操作系统解耦，能在各种系统中运行并有极大的可移植性 适合部署在现代的云平台上，配置与代码分离 开发与生产环境对等，能够使用现代的包管理工具实施封装打包 所以，对应用进行容器化前，必须对应用进行检查并实施类似的改造，也就是进行应用规范化，规范化的过程根据已有应用的实际情况有较大的不同，一般来说，越是现代的、面向互联网的应用越容易容器化。对容器化应用的规范化改造有以下内容：云采用框架白皮书 文档

108、版本：1.0 53 准代码：明确一份代码，多分部署的原则，一个应用程序只能有且只有一个代码库或一个主库，确保该代码库中能够支持开发、测试、构建操作。依赖管理：大多数编程语言都会提供一个打包系统，用来为各个类库提供打包服务，我们期望应用程序能够显示的表示自己的依赖，使用 pom.xml 或者 package.json 来描述自己的全部依赖，不要有隐式依赖。这样能够为开发者和流水线简化配置流程，可以完成一句话构建。配置注入：数据库地址、三方证书、API Key 等等这些在不同环境下有区别的配置应该能够独立注入，我们要求在不同环境下，容器一致，但配置不同。可以使用环境变量或 Config Servi

109、ce 方式进行管理，使用 Config Service 时也需要做到无依赖。服务配置化：后端依赖的服务比如数据库 MySQL、PostgreSQL，缓存、队列等都需要做到可配置化，将配置拿出，系统不应该区别对待这些服务。进程整理：应用程序尽量做到一个进程运行，如果使用多个进程比如 nginx+php 也可以接受，但一定要目的单一，易于管理。同时以也需要保证进程的无状态特性，使用内存存储 session 造成粘性是无法接受的，并且状态应该持久化入数据库。单一的、无状态的进程也可以反映到并发上。易处理：表示可以瞬间开启或停止，这有利于快速、弹性的伸缩应用，迅速部署变化的代码 或 配置，稳健的部署应

110、用。当然也需要支持优雅的终止，即受到 SIGTERM 后会处理完任务，或者在服务中心注销，再进行关闭。容器化上云流程 传统应用容器化大致分为五个阶段：应用现状分析：梳理应用使用的资源、系统的逻辑架构拓朴、应用服务的所有数据依赖、应用上下游服务依赖关系、服务所依赖的进程、系统中需要保留的重要日志及数据、数据和文件权限等；方案规划和设计：根据前期对应用系统现状的调研和分析结容器平台特性，应用系统产出新的系统架构图和迁移的改造计划，比如是直接容器化上云还是改造后再容器化上云，以及容器化后业务系统功能和性能测试方案、系统的割接方案等。编写 Dockerfile：若要打包应用程序以供在 Docker 中

111、运行，需要编写脚本文件 Dockerfile，用于自动执行所有应用程序部署时需要执行的步骤。这通常包括一些 Shell 配置命令，以及用于复制应用程序包、设置所有依赖项的指令，也可以解压缩已压缩的存档或安装包。Docker 镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。在 Docker 镜像使用中，我们最好把经常变化的内容和基本不会变化的内容要分开，把不怎么变化的内容放在下层，创建一个基础镜像供上层使用。云采用框架白皮书 文档版本：1.0 54 生成镜像：使用docker commit命令将

112、某个container的环境提交成为持久化的docker image。使用docker build命令基于dockerfile构建。这种构建方式的优势在于可以通过docker history命令溯源镜像的生成过程。并且消除了 docker commit 可能把一些不需要的东西误提交的隐患。镜像构建成功后，只要有 docker 环境就可以使用，通过利用 docker push 命令将镜像推送到镜像仓库中去。应用部署：将 docker 镜像部署到对应 Kubernetes 集群应用。在 Kubernetes 集群上需要用到的部署模板，在具体实施过程中，可以根据不同的模板来部署到对应不同的集群。重构

113、上云方案 传统单体应用架构问题 单体应用复杂度高，应用迭代发布周期慢，无法支撑业务快速发展的需求；开发者需要关注架构的所有细节（限流、熔断、降级等服务治理，数据访问及消息通信）；运维需要负责底层基础设施（包括数据库、缓存、虚拟机等）的稳定性；云原生应用架构 云原生应用架构特点 应用代码按业务域拆分解耦，降低复杂度；开发者只需关注业务逻辑，与业务不相关功能下沉到云基础设施；技术体系走向开放和标准；运维无需关注基础设施稳定性，更多精力专注于自动化；云原生应用架构建议 云原生应用架构示例，如下图所示。云采用框架白皮书 文档版本：1.0 55 微服务解决“应用架构复杂度”问题；服务治理解决“业务开发关

114、注与业务无关的限流、熔断、降级能力”；容器解决应用“部署问题”问题；K8S 解决应用“编排和调度”问题；Service Mesh 解决“侵入性微服务改造”问题；专项上云方案 场景示例：阿里云 SAP 上云方案 SAP HANA 是一个软硬件结合体，提供高性能的数据查询功能，结合了大量交易与实时分析能力，显著提升商业效率，助力企业数字化转型。阿里云多个 ECS 企业级云服务器产品规格通过 SAP HANA 认证，企业用户可以在阿里云上放心部署和运行基于 SAP HANA 数据库的关键业务系统。SAP 在企业管理软件领域有着丰富经验，结合阿里云弹性和可扩展性、快速部署、高度稳定性、全球基础设施等优

115、势，可以帮助企业轻松应对业务变化，加速业务系统的部署。阿里云 SAP 上云及云上运维最佳实践 云采用框架白皮书 文档版本：1.0 56 针对企业用户 SAP 上云的需求，阿里云提供了场景丰富的 SAP 云上部署及运维最佳实践，详情参见 SAP 解决方案 数据上云方案 数据上云架构设计 数据在同一业务库中采用多租户隔离机制；为数据服务层建立一套统一的管理规范，所有业务用户账号在完成相关审批流程后对相应的数据字段进行授权安全访问，对数据只有读的权限，不能对原始数据进行直接修改或删除，做到数据不搬家，可用不可见；建立统一的数据资源视图和数据血缘跟踪能力，能够对所有的数据的生命周期进行溯源查询，用以甄

116、别数据变更过程中的真实性和准确性；根据不同业务场景结合流程节点和风险管控要求，对相关数据进行分析、建模、挖掘，提高数据服务支持。数据上云安全防护 在企业数据迁移上云的过程中,实施数据分层保护功能已成为一个关键优先事项。同时，数据保护控制必须辅之以强大的监控工具和访问管理控制,以构建数据的整体视图，对数据的全生命周期进行监控。重点考虑以下关键数据保护领域。数据分类：围绕数据识别、清单、标签和分类的功能和流程；静态数据保护：有关加密/令牌化的解决方案和注意事项,包括密钥管理；传输中数据保护：功能包括 TLS/SSL 层保护、数据丢失防护解决方案和安全数据传输；数据监控：通过操作中心(SOC)进行日

117、志记录和监视功能；在云环境中,以数据为中心的保护需要在整个数据生命周期中进行。阿里云数据上云迁移最佳实践 数据库上云 包含关系数据库及 NoSQL 数据库上云等场景，以 Mysql 为例，主要考虑以下几点：根据性能场景需求，选择匹配的产品及实例规格，以最低成本达到业务需求 比如 RDS 和 PolarDB，RDS 主要是主备模式，读写 IO 在单机上执行，走主机总线，RT 相对较低，而PolarDB 是云原生的读写分离架构，读写 IO 会走网络，RT 相对较高。从产品架构上分析，对于 RT要求比较高的场景，建议使用 RDS，其他情况，相同规格 PolarDB 实例一般比 RDS QPS 性能要

118、高。未来数据增长 未来三年内数据增长，如果超过单实例最高规格性能，建议 PolarDB-X，通过水平切分的方式，将数据分布在多个底层 mysql 库，通过并行的分布式数据库操作来实现性能的提升。云采用框架白皮书 文档版本：1.0 57 迁移过程数据膨胀 全量数据迁移过程并发 INSERT 导致目标实例的表存在碎片，全量迁移完成后目标实例的表空间会比源实例大（迁移完成后可通过 optimize table 合并碎片，优化存储空间），所以建议选择实例规格时，预留一定的存储空间以防存储打满；识别无主键表 无主键表不支持增量迁移，需要提前识别，对于无主键表单独做全量迁移。阿里云数据库上云迁移工具及最佳

119、实践 数据传输(Data Transmission，简称 DTS)是阿里云提供的一种支持关系型数据库、NoSQL、OLAP 等多种数据源之间数据交互的数据服务。DTS 的数据迁移功能支持同构或异构数据源之间的数据迁移，同时提供了库表列三级映射、数据过滤等多种 ETL 特性，适用于多种数据库迁移上云场景。详情请参见在线迁移服务。存储数据上云 主要指非结构化数据，常见于内容管理类型的应用系统，涉及大量文件对象的存储和管理，传统的解决方案包括：本地磁盘存储，数据定期备份。但这种方案存储存储容量和性能的扩展性、存储自身的高可用性等问题。采用 IP-SAN、NAS 等对数据做集中存储，这种方案成本较高；

120、在数据库中存储文件。这种方案成本高，对数据库的存储资源消耗和性能影响都比较大。针对文件对象存储，阿里云提供开放存储服务（OSS），具备高可用、高扩展、高效性、低成本等特点，能有效解决内容管理类型应用的文件对象的存储问题。应用系统需要基于 OSS 进行相关改造，主要包括：根据应用系统文件的存储结构在 OSS 中规划 Bucket，以及文件目录结构；设置 Bucket 访问权限（public-read-write/public-read/private），对于安全级别要求高的应用，可设置文件在 OSS 上以密文形式存储；对程序代码进行扫描，查找出涉及文件向存储读写的代码，将这些代码改造为以 OSS

121、 SDK 接口的实现。这里需要注意，对于较小的文件（100M）推荐采用 SDK 提供的 Multipart Upload 接口对文件做分块多线程上传，以提升文件上传效率。阿里云存储数据上云迁移工具 云采用框架白皮书 文档版本：1.0 58 阿里云在线迁移服务是阿里云提供的存储产品数据通道。使用在线迁移服务，可以将第三方数据轻松迁移至阿里云对象存储 OSS，详情请参见在线迁移服务。4.2.4.上云迁移实施 建立上云迁移组织及保障机制 在上云迁移实施前，需要建议迁移组织及保障机制，明确各小组职责及成员，确定保障机制把握项目工作进度和工作质量。迁移组织架构 根据阿里云以往项目经验，建议组织分为以下小

122、组，如下图所示，各小组职责如下。项目管理办公室：负责项目进度、风险及问题管理，以及内部宣贯。实施架构组：负责总组上云方案、割接方案设计，以及项目实施过程中技术风险把控。应用开发组：负责应用开发、部署及应用迁移实施工作；运维组：负责云上资源管理、数据组、中间件迁移实施及数据校验工作；测试组：负责功能测试、联调测试及性能测试工作。项目实施保障机制 建立项目管控机制，把握工作进度和工作质量，包含以下内容：内部定期沟通计划 项目周报制度 问题和风险分析计划 制定迁移实施计划 云采用框架白皮书 文档版本：1.0 59 由于上云迁移实施存在风险，所以，在应用上云实施执行前，我们建议制定详细的实施计划。这个

123、计划表里面包含了上云迁移及割接过程的全部任务、时间段、各方人员等。项目实施过程按照这个计划表跟踪执行即可。4.2.5.测试与验证 功能测试及联调测试 在应用上云割接前，需要进行充分的功能测试与联调测试，验证云上环境应用运行情况。功能测试及联调测试依赖企业自已的测试团队及流程工作，不作过多描述，仅在此建议，对应用功能点进行分级，优先测试验证核心功能点，对不同级别功能点测试问题，制定不同紧急程度的问题跟踪。性能测试 1）性能测试流程 2）业务测试模型构建 业务测试模型构建主要是根据搜集到的性能测试需求和生产系统的相关信息完成性能模型的构建工作，并指导性能测试过程以及测试结果的生成。3）监控性能指标

124、 监控指标包含业务监控指标、操作系统监控指标、中间件监控指标、数据库监控指标呢，旨在监控从各个维度描述压测时性能表现。4）构建性能测试数据 测试数据主要包含两类，基础测试数据 基础测试数据一般取自生产环境真实请求日志。基础测试数据非常适合真实业务模型，当然，也可以对基础测试数据进行过滤处理，获取单一业务场景测试数据。采用参数化测试数据 参数化测试数主要根据业务请求参数，按测试模型场景构建。参数化测试涉及的范围很多，比如需要准备大量用户名及相应密码参数数据；模拟纳税人纳税申报，需要准备大量的纳税人识别号、纳税人内码或纳税人系统内部识别号等参数数据，这类数据准备要求符合实际运行要求并且保证数据表之

125、间的关联关系。云采用框架白皮书 文档版本：1.0 60 5）测试场景 常见性能测试场景，主要包含以下几种：基准测试：基准测试的目的是检查业务本身是否存在性能缺陷。同时为将来的混合场景的性能测试性能分析提供参考依据。稳定性测试：主要侧重系统在持续的压力情况下，业务处理能力及系统可能存在的缺陷。业务突变测试：主要考察当业务进行突变以后，系统是否出现异常，资源在突变前后变化情况。可靠性测试：主要是模拟各种故障（网络中断，服务异常、HA 切换）下，系统是否能正确切换，处理能力是否有明显变化。6）测试实施及报告 基于测试工具，构建对应测试场景的脚本，通过测试结果，并根据观测的性能指标，撰写测试报告。7）

126、测试工具 阿里云性能测试 PTS（PerformanceTesting Service）产品是面向所有技术背景人员的云化测试工具。PTS是具备强大的分布式压测能力的 SaaS 压测平台，可模拟海量用户的真实业务场景，全方位验证业务站点的性能、容量和稳定性。PTS 目标是将性能压测本身的工作持续简化，使您可以将更多的精力回归到关注业务和性能问题本身。在PTS 平台上，您可以用较低的人力和资源成本，构造出最接近真实业务场景的复杂交互式流量，快速衡量系统的业务性能状况，为性能问题定位、容量最佳配比、全链路压测的流量构造提供最好的帮助。进而提升用户体验，促进业务发展，最大程度实现企业的商业价值。详情参

127、见 PTS 产品文档。4.2.6.割接与上线 割接上线前的准备 应用的割接上线是整个应用上云迁移实施的最关键环节，这一环节出问题，可能会造成重大故障。针对割接上线的重要性，我们建议在实施应用割接前，制定详细的割接前检查清单,这个清单的严谨程度也许很大程度上决定了割接成功率。根据我们以往的经验，对割接上线前的准备工作，以下给出几点经验：割接前需要严格确认是否所有需要预先准备的工具、迁移环境（客户本地数据中心端、网络、云端）等已经就绪。检查和确认云环境 Landing Zone 已经就绪，并且确认云环境中的规模，安全，控制，网络以及身份验证与设计保持一致。割接上线时需多方人员参与，软件厂商、集成商

128、、用户方、云厂商等,确认这些相关人员是否已经就绪。支持的方式是现场、远程还是电话。云采用框架白皮书 文档版本：1.0 61 回滚预案是否就绪。割接过程好像在打一场大的战役，很多的任务或子任务会分配半小时内计划执行结束，整个过程可能会非常紧张。为降低压力，即使因为某个主客观原因导致迁移无法成功进行，如果有补救措施会让整个迁移团队降低很多压力。这个补救措施之一就是回滚预案，也即是失败后回滚到客户的原数据中心恢复业务应用，需要在割接时预留回滚执行的时间。回滚执行后，然后拥有充足的时间排查问题，以备下一个割接窗口期内再次割接。根据项目实际场景，设计一个检查清单，这个清单需包含了迁移割接任务的全部前置条

129、件。制定详细的割接实施方案 迁移项目是复杂的，大部分迁移割接的时候都会或多或少的遇到一些无法预料的问题。造成割接失败，可能有主观原因和客观因素。主观原因可能因为迁移调研问题、迁移方案设计缺陷、迁移验证过程不够全面等。客观因素通常是客户 IDC、运营商网络、云数据中心故障等。无论那种问题导致，都可能会对迁移割接造成失败。根据以往的项目经验，我们建议在割接前制定详细的割接实施方案，以下是关于割接实施方案的一些建议。数据验证，确认割接时与割接前数据保持一致。通常客户的大部分服务器镜像及数据会在割接前预先在云端复制完成。在割接窗口期开启后需要确保云端复制的数据与客户数据中心下线前保持严格一致。并非所有

130、问题都会导致迁移失败。遇到问题的时候，首先评估问题的严重程度，如果不是关键业务应用的重要的问题，可以将割接流程继续进行，同时该问题继续解决。与客户协商，该问题是否会会对业务有很大影响，如果客户可以接受的话，可以先上线，然后尽快解决该问题。迁移时间拖延问题处理。如果割接时不够顺利，因为种种主客观原因导致迁移割接时间长于计划时间，可以与客户协调，一起决定是否可以延迟一些时间上线。通常设计割接计划时都会留出一些缓冲时间，如果需要延迟的时间过长是客户无法接受的，那就只能执行回滚预案了。网络切换问题处理。比如 IP,端口，网络配置,DNS 等问题，在之前的调研和检查中出现遗漏。这种问题在割接时经常会遇到

131、，出现这种问题紧急联系相关负责方尽快解决，但并不一定会影响割接整体进行。迁移的不仅是服务器或数据。而是整个企业的 IT 应用及环境，客户应用需要的身份管理、安全配置、数据及系统备份、高可用性架构配置，容灾方案等都需要完成。严格按照迁移设计方案中指定的云服务型号匹配云上资源。拿 VM 举例，通常云上会提供十几个系列，数百种 VM 型号，使用错误的 VM 即使能够将服务启动起来，但会带来性能、功能以及成本的问题。迁移过程确保安全合规。数据迁移严格使用加密数据传输，加密数据存储。证书、密码、权限按照合规的方式申请和使用，杜绝泄露隐患。避免因安全合规性问题带给客户严重损失。制定详细的割接及回滚步骤，明

132、确每个步骤执行时间点，前置条件，相关责任人等。以下是割接及回滚步骤的示例模板，在具体的项目中可以根据项目需求来设计定制。割接后持续观察验证 云采用框架白皮书 文档版本：1.0 62 割接后对迁移的应用云上运行情况持续观察验证，做好业务和数据做好监控，持续观察业务的运行状态，直到确认完全没有问题，割接执行工作才算基本结束。云采用框架白皮书 文档版本：1.0 63 5.运营治理 5.1.风险治理方法论 5.1.1.风险治理的方法论 企业需要进行风险治理 风险是指尚未发生但可能发生的问题，这些问题最终或多或少会造成业务的损失。此处所说的“风险”，特指因 IT 系统相关问题可能造成的业务损失。比如：I

133、T 系统中存放的业务数据被恶意盗取致使客户个人隐私数据泄露，这将使企业面对客户流失、舆论危机、法律责任和巨额罚款。IT 系统因无法承载突发的业务流量而瘫痪，又因缺乏基础的灾备恢复机制致使整个业务长时间中断，这将使企业遭受巨大的业务损失和后续的客户流失。经过第三方认证机构评定，IT 系统不符合行业基础安全标准，商务合作伙伴认为该企业存在较大的潜在风险，决定终止商务合作。对于业务需重度依赖 IT 系统的企业，如游戏、在线教育、直播、电商等，IT 风险治理就更加重要，否则可能就要遭受企业收益和名誉的双重损失，严重时甚至需要承担法律责任。风险治理的工作思路 企业应配备专门的团队（或人员）负责风险治理的

134、工作。风险治理团队应站在管理者的角度考虑整个企业的风险治理决策，输出清晰的风险定义、风险治理策略、治理策略的实施制度，并建立一定的监管流程来监督策略的实施，确保风险治理的可监督、可强制。云采用框架白皮书 文档版本：1.0 64 风险治理团队要充分采纳一线业务团队和运维团队的风险提案，再从战略上判断是否要形成对应的风险决策、风险治理策略，从上而下地实施治理监管。实施过程中，应与一线业务团队和运维团队紧密合作，共同协定业务风险的评估机制、风险治理的实施办法和效果 SLA（Service-level Agreement）。风险治理是在与一线业务团队和运维团队达成共识并充分协作的前提下不断迭代升级，是

135、一项长期工作。风险治理的步骤 下图是阿里云建议企业内负责风险治理的职位或团队的工作路径：风险识别&评估：充分考察企业在每个阶段面对的潜在风险，并通过量化风险可能造成的损失来评定风险等级，针对不同的风险等级制定不同程度的治理决策。治理策略：将治理决策转化为治理策略，治理策略是可被系统化实现的规则，在实际的工作中对于 IT管理行为能起到禁止或告警的作用。持续监督：成熟的企业会追求用技术手段落地管理决策，阿里云平台也提供了相应的服务能力。云上系统化的治理可以分为如下两部分：-事前拦截：可以通过启用阿里云的安全防护产品主动防御恶意攻击，还可以通过管控策略（Control Policy）默认禁止某些管控

136、行为和变更的发生。-事后发现：可以基于阿里云配置审计（Cloud Config）服务设置对资源配置的检测条目，及时发现违规资源的出现并及时修正。云采用框架白皮书 文档版本：1.0 65 5.1.2.风险治理的工作开展 合理地进行风险治理 在传统 IT 治理中，有时会采用充分的前置防护。在业务正式上线之前，充分分析业务运营流程并评估潜在风险。将治理措施在中台部署完成后，业务才上线运营。后续的业务管理流程只能使用事先经过治理审批的既定流程。而业务的迭代升级则需要进行新一轮的评估。这显然不适用于当前的云计算环境，原因如下：企业上云是为了充分利用云的敏捷性和弹性，云上 IT 系统的运维变更是高频且复杂

137、的。过度的治理会限制云上业务的敏捷发展，使风险治理团队与业务团队成为对立面。风险永远存在，企业上云过程中的转变其实会带来更大的风险。但并非所有风险都需要被 100%规避，需要充分评估风险的实际影响，采取不同的应对方法。在上云的不同阶段，或业务发展的不同阶段，风险治理的要求是不同的。而在云上，各个阶段的转换很迅速，没有风险治理团队能一开始就探测到所有潜在风险，风险治理是需要跟随业务的发展持续迭代的。所以，风险治理团队需要在潜在风险控制、业务发展速度、IT 治理成本中找到平衡。在业务发展的不同阶段，针对不同的风险采取不同的应对措施，持续迭代企业的风险治理策略。风险治理策略的起点 前序文章中说过，风

138、险是一直存在且不断变化的，对于某个企业来说，在业务上云的不同阶段、在云上发展的不同阶段都会面临不同于传统 IT 的各种风险。那么，与之相应的风险治理也必将是一个迭代的过程。但万事开头难，在新项目中启动风险治理比持续迭代一套风险治理策略更难。在没有明确的业务逻辑前，很难有靶向地制定风险治理策略。此时，需要先定义一个无业务倾向性的起点治理基线。企业应根据初上云的业务实际情况来制定起点治理基线，需考虑初上云业务的业务性质、云上运维人员数量、需托管的云上 IT 规模等。以下提供较通用的基线策略，可以作为参考：限定云上可采购的资源白名单和规模上限。资源必须具备基础标签，如归属部门、归属计费单元、SLA

139、承诺、归属环境、归属 owner 等。限定可以创建资源的区域。限定可管控资源的白名单用户和白名单角色列表。保障运维可行的情况下，保证最小人群具备采购和释放的权限。最小权限管理原则，高危权限需严格审批。强制遵从强密码策略。必须开启基础计算、存储资源的删除保护功能。云采用框架白皮书 文档版本：1.0 66 必须关闭关键计算、存储资源的公网访问。风险治理策略的迭代 企业规划上云时，最初可能会将一些内部平台和运维系统搬迁上云，此时往往不涉及核心业务，所以不需要过多考虑数据防护、网络防护、灾备机制的问题，只需要通过起点治理基线避免过度采购、过度授权的风险。但随着企业将核心业务搬迁上云，核心业务又在云上得

140、以大规模发展，在此过程中就需要逐步考虑更多潜在风险并基于起点治理基线不断地升级风险治理策略。几个主要的治理基线 身份权限治理基线 通用安全治理基线 数据安全治理基线 成本控制基线 业务连续性基线 小结 IT 风险治理的初衷是为了更好地支持业务发展而不是让业务束手束脚，在企业发展过程中的每个环节采用充分且合理的管理策略尤为重要。当前，云上业务的发展迅速且多变，IT 风险治理也随业务快速迭代。企业的IT 风险治理团队只有与业务团队、运维团队紧密合作、充分沟通，才有可能保持对业务风险的充分判断和合理规避。5.2.阿里云上的治理基线 5.2.1.身份权限基线 身份权限管理是为了缜密地识别、验证和授权个

141、人、用户组或角色，并为其授予云上 IT 的适当访问权限。身份权限治理基线可以认为是云上 IT 风险治理的第一步，无论企业最先安排哪部分业务上云，企业对云上账号、角色、权限的风险治理都需要率先制定章程。后续随着业务的飞速扩张，云上的账号体系也必将越来越复杂。且业务上云后，传统 IT 中的中心化托管不再适用，中心运维团队需要下放运维身份和权限给业务团队，以支持更灵活的运维模式。在上云最初制定并实施治理基线，可避免在规模壮大后可能出现的人员冗杂、权限难以梳理、账号无法清退的困境。避免因低效混乱的账号管理遭受恶意访问和攻击。例如：某知名证券企业在上云之初时，仅在云上部署测试单元，共注册了 3 个主账号

142、分别用作测试账号、生产账号和审计账号。在没有具体业务上云的情况下，事先在云上实施了身份权限的风险治理。具体要求如下：云采用框架白皮书 文档版本：1.0 67 仅允许白名单内的 RAM 用户和 RAM 角色在云上进行管控操作。那么，即便 RAM 用户和 RAM 角色被创建出来，也可以利用白名单约束其活动。根账号和具备较高权限的 RAM 用户必须开启多因素认证（MFA）认证，强制高权限 RAM 用户必须开启多因素认证。必须采用强密码策略。当认证协议和密码策略发生变更时需收到告警，这是对身份权限管理策略的强监管。将所有账号的操作事件统一归集到权限隔离的审计账号，并做安全分析。该企业在后续长期的运营中

143、，主账号增长到 15 个，活跃的 RAM 用户超过 70 个。中心运维团队下放管控权限给业务团队和第三方服务商。在企业内部建立了一套用户身份变更管理流程，当发生人员离职、人员组织架构变动、人员变更归属项目时，分别对云上 RAM 用户、权限以及所属的用户组进行变更，实现云上身份权限的缜密管理。应对的风险 不同的企业管理模式可能导致身份权限管理中面对不同的风险，常见的风险如下：高权限风险。活跃的管控账号直接为主账号或具备管理员权限的 RAM 用户，可能给运维人员的误操作提供了更大的空间，对资源错误的变更、释放、主机升级都可能造成业务中断。较弱的认证机制和密码策略。这可能增加账号被盗用的可能性，进而

144、遭到恶意破坏和数据窃取。闲置的有效账号。长期闲置的具备一定权限的账号可能是离职员工的曾用账号，闲置账号不及时回收可能成为安全管理的盲区，被恶意利用。缺乏操作审计监管。企业不监控和收集云上的访问事件，将无法及时发现访问事件背后的恶意意图，如高频的登录失败、无权限访问、异常访问等。在真正发生恶意操作后也难以复盘和追责。随着业务的发展壮大，云上的 IT 管理人员、IT 规模、业务复杂度都在成倍增长，企业应周期性审视身份权限管理的风险辨识，及时更新风险的定义并推进风险治理策略的升级实施。治理基线 企业应根据云上运维人员数量、运维人员的工作边界、需托管的业务数量、需托管的云上 IT 规模、具体托管的业务

145、内容等实际情况来制定自己的身份权限治理基线，以下提供较通用的基线策略，可以作为参考：账号基本安全 o 为主账号的登录行为开启多因素认证（MFA）。o 避免在应用程序中使用主账号访问密钥（AK），应禁止存在主账号访问密钥（AK）。使用访问控制 o 避免直接使用主账号管控资源，应通过创建 RAM 用户并合理授予最小必要权限来进行云上管控。云采用框架白皮书 文档版本：1.0 68 o 为所有 RAM 用户的登录开启多因素认证（MFA）。o 限定云上活跃的 RAM 用户和 RAM 角色白名单。o 必须采用强密码策略。密码有效期不超过 90 天。密码最小长度不小于 8。密码中必须包含大小写字母、数字、特

146、殊符号。禁止设置使用过的密码。一小时内最多允许 5 次密码输入错误。o 应对用户组授权，避免直接给 RAM 用户授权，通过用户组管理 RAM 用户。o 仅为指定的有限人员设置管理员权限，并严格禁止企业内多人共享一个 RAM 用户。充分审计 o 将所有操作事件统一归集到独立的审计账号，由专职的审计人员管理，与运维人员权限隔离。o 基于操作事件实现持续的安全分析。o 当发现认证协议和密码策略发生变更时需收到告警。o 当主账号有操作行为时收到告警。o 定期对比 RAM 用户实际发生的操作行为和已获得的授权，避免过度授权。持续治理 o 使用云上具备持续监控和持续检测能力的治理工具。o 开启云平台推荐的

147、治理基线，结合企业自身实际需求实现自定义策略。5.2.2.数据安全基线 识别数据泄露风险 企业迁移上云后，IT 系统对数据的存储、传输、处理方式与云下有巨大的差别。数据使用模式的变更会使企业面临潜在的数据泄露风险。如何防范数据泄露也是众多企业在核心业务上云后最关心的问题之一。数据泄露可能迫使企业面对业务终止、舆论危机、财务损失、法律责任和巨额罚款。国家近年也在不断完善个人信息保护的相关法律法规，强调企业在保护个人信息上的直接责任，对企业提出明确的纲领要求和系统技术要求。同时，也在建立制度对企业的数据安全水位进行监督测评，并明确对一些数据泄露情节的处罚制度，涉及到巨额罚款或业务终止。云采用框架白

148、皮书 文档版本：1.0 69 可见，真实的数据泄露事故和任何疑似泄露的舆论新闻均会对企业造成实质损害。企业在评估数据泄露风险时应关注以下方面：国家法规和行业标准对企业 IT 系统的数据安全要求。来自企业外部的恶意攻击和非法爬取。来自企业内部的误操作或恶意操作导致的数据泄露。数据泄露风险的治理策略 风险治理策略的设计与企业采用的数据安全框架紧密相关。数据安全框架是指在数据管理的整个生命周期内采购合理的技术手段和平台服务以构建安全能力，这是一种安全决策。而相应的数据风险治理是确保在长期运维过程中，IT 系统的配置和变更始终符合安全决策的要求。数据安全框架 企业想要实施有效的数据防护措施需要从管理制

149、度和技术策略两个角度来考虑。云平台会为数据管理生命周期的每个环节提供安全能力，但对于安全能力的正确采用、准确实施都需要依赖企业内部有对应的组织架构、安全制度、内建流程的支撑。在企业内部，应该有专职的安全团队统筹整个企业的数据和应用安全，识别潜在的安全风险并制定安全决策。安全决策应该包括基本的安全规范、安全等级标准、安全防护 IT 采用方案、内部权限管理流程等。安全团队还需要制定与业务团队、运维团队的交互流程和协作机制，确保安全决策在可见、可控、可监管的前提下得以实施。在技术方面，针对数据管理生命周期的各个环节要采取对应的防护措施，在数据的使用中做到及时扫描、完备防护、可审计、可检测、及时响应、

150、可溯源。下图为数据管理的生命周期及需要采取的技术手段。云采用框架白皮书 文档版本：1.0 70 数据泄露风险治理框架 安全小组制定了安全决策后，安全决策一部分直接转变为 IT 安全部署的指导策略，即企业 IT 系统的安全架构要求，比如采购防火墙、采购敏感数据保护服务。还有一部分会转变为治理策略，即安全小组在长期的业务运营过程中用来监督安全架构被正确实施的监管框架，比如是否每个云账号都开启了防火墙。数据泄露风险的治理框架取决于数据安全框架。企业会根据真实情况在数据管理的生命周期内制定不同的防护方案。以下提供较通用的治理策略，企业可根据实际情况选用：对业务数据进行关键性分级分类，并隔离存储。为存储

151、核心重要数据的存储服务实施敏感数据管理，包括敏感数据识别、敏感数据的脱敏引用等。开启数据存储服务的静态数据加密。为存储服务开启备份策略，制定明确的数据恢复 RTO、RPO。禁止匿名的数据访问。禁止公网数据读写。对数据的写入权限和读取权限管理遵循最小权限原则，并定期复查授权情况，避免冗余授权。确保完整收集所有数据访问和写入的日志。实时监控数据访问行为，周期性复盘和分析数据访问日志，及时发现可疑的数据访问。企业内部定期复盘治理策略，确保满足业务的数据泄露风险治理需求。企业应根据业务的发展不断升级与加固 IT 安全框架，同时迭代相应的治理框架。云采用框架白皮书 文档版本：1.0 71 5.2.3.通

152、用安全基线 安全是企业 IT 架构永恒的核心话题，企业的安全团队应根据企业业务上云后可能面对的安全风险制定安全决策。安全决策将演变为云上的 IT 安全采购策略和安全架构，对企业云上的网络、应用、主机、数据提供安全防护。而安全治理基线是企业需要在云上采用的一种持续监控和治理的手段，以保证安全策略被正确完整的实施。企业从云下的专有域迁移到公有云的互联社区，使企业面对的安全环境变得更复杂。企业上云后将云下 IT系统搬迁上云，这种变化给企业带来弹性伸缩的便利性，但同时也增加了企业对公网的资产暴露。企业上云过程中对数据的存储、处理、传输方式均发生变化，这增加了数据泄露的风险。在上云最初制定明确的安全决策

153、和安全策略并实施安全治理基线，这可以企业保障安全策略的持续执行，使云上 IT 始终在云安全能力的纵深防御中，使企业拥有比云下更安全的防御深度。例如，某知名游戏公司将业务单元搬迁上云时就制定了较高的安全策略并启动相应的治理基线。具体要求如下：所有资产按关键程度和存储数据的敏感度进行标记。开启数据存储服务的静态数据加密。包含重要数据的网络应与其他子网隔离，并定期审视流量。所有公网端口，必须设置自动 DDoS 防护。为所有业务应用开启防火墙功能。企业在后续飞速地业务扩张中，以治理基线约束每个业务应用的安全部署，确保主机、网络、数据、应用始终处于安全防护中，实现安全上云的目标。应对的风险 企业应从网络

154、、应用、主机、数据四个维度充分评估上云风险。网络安全风险：虚拟化网络的多层化使网络架构的实施和网络策略配置更复杂，外连的多样性使组织内部网络架构梳理变得困难。若配置不当会让黑客更容易实施横向攻击，使业务大面积受损。且上云使企业被攻击的可能性大幅增加。应用安全风险：应用上云后更容易受到恶意访问，云上攻击的成本和实施门槛均降低。云采用框架白皮书 文档版本：1.0 72 主机安全风险：上云后主机会被更频繁的变更，且大多数企业上云后会弱化前序的审批环节，这使变更本身潜藏复杂的风险。上云后增加了主机的暴露率，更容易被电子货币等业务攻击和侵占。主机弱点及配置不当会带来安全漏洞和资产损失。数据安全风险：数据

155、的采集、传输、存储、处理的环境和方式均发生变化，使企业面对更大的数据泄露风险。企业必须对业务敏感数据、用户隐私数据做充分识别和特殊保护，确保遵循国内国际的数据保护条例。治理基线 安全治理基线的设计与企业采用的安全决策和架构有紧密关系。安全决策决定了云上 IT 安全架构和采购策略，决定了云上启用的安全技术手段和安全服务。而相应的安全治理基线是确保在长期持续的 IT 管理中需要采用的一种持续监控和治理的手段，以保证安全策略被正确完整地实施。假设下图为企业通用的云安全采用框架：以下提供较通用的治理策略，企业可根据实际情况选用：为面向公网的 IP 启用 DDoS 高防，清洗流量型和资源耗尽型 DDoS

156、 攻击，隐藏被保护的源站服务器。为业务开启云防火墙，管理互联网到业务的访问控制策略（南北向）和业务与业务之间的微隔离策略（东西向），进行流量监控、精准访问控制、实时入侵防御。为应用开启防火墙防护外部访问风险，防御各类 OWASP 常见 Web 攻击并过滤海量恶意 CC 攻击，避免网站资产数据泄露。在云上建立安全中心或启用安全中心，开启主机内的安全基线监控，如威胁检测、漏洞扫描、补丁升级、入侵检测等，确保开启了安全告警 网络入网网段不能是全网段，且需限制 22 和 3389 等风险端口的开启，设置最细粒度的入网控制策略 开启网络流量日志的记录 隔离网络之间的路由遵从最小够用原则 云采用框架白皮书

157、 文档版本：1.0 73 确保系统盘和数据盘启用加密 5.2.4.业务连续性基线 业务连续性侧重强调在长期的云上运营过程中保证业务不中断。业务中断是 IT 运维中较常见的事故，与数据泄露等风险不同，业务中断并不存在侥幸。一旦发生业务中断企业将即刻面临实际的业务损失，业务恢复所耽误的时间越长损失就会越大。且伴随着停机造成的直接盈利损失，还有客户信心流失、信誉损伤、名誉损伤，甚至影响更广泛的商业合作的达成。企业应在重要业务上云之前优先制定能保障业务连续性的合规治理基线，确保重要业务上云之后不会因误操作、防护不足、负载激增等导致业务中断，同时也要确保真有中断发生的时候能快速恢复，尽可能减少因业务中断

158、所造成的损失。应对的风险 企业应考虑以下风险可能影响业务连续性：不连续的资源管理风险。无人为操作，因业务依赖的 IT 资源欠费导致的资源自动释放，致使业务中断。误操作风险。运维人员错误的大量删除 IT 资源，致使业务中断。突增的负载。大多数互联网业务普遍存在所谓“高峰期”，对高峰期预判不足，可能导致因负载过量而业务中断。超长的恢复时间。当业务中断真实发生时，如果没有预设备份机制和快速的灾后恢复机制，会导致业务中断的时间数倍延长，这期间的业务损失是几何倍的增长。治理基线 企业应根据实际业务性质决定采用的治理策略，尤其是对公网防护能力、备份恢复能力、弹性能力的选择，这些将带来较大的成本。以下提供较

159、通用的基线策略，可以作为参考：根据 IT 所承载的实际业务，对 IT 资源进行关键性分级，对于承载关键业务、会影响重要客户或大量客户、业务本身需要较高稳定性 SLA 的 IT 资源进行标记。并对不同关键性层级的 IT 资源区分采取不同的治理策略。对于关键性的 IT 资源应开启自动续费并确保账号中有足够的余额，或设置资源到期提前提醒及时续费，避免因欠费而停机中断。在全局保证最小人群具备删除资源的权限，避免权限泛滥提升误操作的概率。删除资源等影响业务连续性的关键操作应要求必须开启 MFA 认证，执行高危操作时增加多元认证确认。为关键性较高的计算、网络、存储、数据库资源开启释放保护，避免来自自动脚本

160、的误删除。云采用框架白皮书 文档版本：1.0 74 为面向公网的 IP 启用 DDoS 高防，清洗流量型和资源耗尽型 DDoS 攻击，隐藏被保护的源站服务器。为业务开启云防火墙，管理互联网到业务的访问控制策略（南北向）和业务与业务之间的微隔离策略（东西向），进行流量监控、精准访问控制、实时入侵防御。为应用开启防火墙防护外部访问风险，防御各类 OWASP 常见 Web 攻击并过滤海量恶意 CC 攻击，避免网站资产数据泄露。实时监控关键性 IT 资源的负载，计算、网络等核心资源的负载应始终保持在 80%以下，避免因负载过重导致业务中断。采用弹性扩容缩容的运维方案，在业务高峰期快速扩容确保稳定性。为

161、每个业务制定明确的 RTO 和 RPO，采取能满足容灾要求的备份机制和恢复机制。对核心业务的数据平台制定高频率备份和多区域复制 为关键性业务虚机启用热备份和高可用模式 企业应根据业务的发展不断升级与加固稳定性防护和灾备机制，同时迭代相应的治理框架。云采用框架白皮书 文档版本：1.0 75 6.结束语 本云采用框架白皮书始终关注于企业在业务目标和云采用目标达成一致，在云采用的生命周期：上云战略、上云准备、应用上云和运营治理四个阶段为企业提供业务和技术策略指导，帮助企业从组织、人员和技术层面着手采取行动，确保云采用的价值最大化和风险最小化。本云采用框架白皮书是阿里云产品团队、全球交付团队服务众多企

162、业客户将业务落地在阿里云的设计和实施经验总结，因此特别感谢这么多给予我们信任、帮助我们改进的客户。由于时间紧迫和视野局限，第一版本的云采用框架白皮书在一些观点和方法上还有纰漏和瑕疵，我们也非常欢迎您将意见和建议反馈到官网（https:/ 文档版本：1.0 76 7.基本概念 概念 说明 访问控制 访问控制（RAM）是阿里云提供的管理用户身份与资源访问权限的服务 阿里云账号（主账号）开始使用阿里云服务前，首先需要注册一个阿里云账号，是阿里云资源归属、资源使用计量计费的基本主体 身份 访问控制（RAM）中有三种身份：RAM 用户、用户组和 RAM 角色 RAM 用户 RAM 用户有确定的身份 ID

163、 和身份凭证，通常与某个确定人或应用程序一一对应 用户组 用户组是 RAM 的一种实体身份类型，用户组可以对职责相同的 RAM 用户进行分类并授权，从而更好的管理用户及其权限 RAM 角色 RAM 角色是一种虚拟用户，RAM 角色有确定的身份，可以被赋予一组权限策略，但没有确定的登录密码或访问密钥 默认域名 阿里云为每个账号分配了一个默认域名，格式为 账号别名（企业别名）每个阿里云账号可以在 RAM 中设置一个全局唯一的账号别名。账号别名主要用于 RAM 用户登录，登录成功后可作为显示名 域别名 如果您持有公网上可以解析的域名，那么您可以使用该域名替代您的默认域名，该域名称为域别名。域别名就是

164、指默认域名的别名 访问密钥 访问密钥指的是访问身份验证中用到的 AccessKey ID 和 AccessKey Secret 多因素认证 多因素认证（MFA）是一种简单有效的最佳安全实践，在用户名和密码之 云采用框架白皮书 文档版本：1.0 77 外再增加一层安全保护 服务提供商 指利用 IdP 的身份管理功能，为用户提供具体服务的应用 身份提供商 是一个包含有关外部身份提供商元数据的 RAM 实体，它可以提供身份管理服务 安全断言标记语言 安全断言标记语言（SAML 2.0）是实现企业级用户身份认证的标准协议，它是 SP 和 IdP 之间实现沟通的技术实现方式之一 单点登录 阿里云支持基于

165、 SAML 2.0 的单点登录，也称为身份联合登录 元数据文档 元数据文档由企业 IdP 提供，一般为 XML 格式，包含 IdP 的登录服务地址、用于验证签名的公钥及断言格式等信息 SAML 断言 SAML 协议中用于描述认证请求和认证响应的核心元素。例如：用户的具体属性就包含在认证响应的断言里 OAuth 应用 获取用户授权，并获取代表用户身份的令牌，从而可以访问阿里云 OAuth 范围 OAuth 2.0 服务通过 OAuth 范围来限定应用扮演用户登录阿里云后可访问范围 权限策略 权限策略是用语法结构描述的一组权限的集合，可以精确地描述被授权的资源集、操作集以及授权条件。资源 云服务呈

166、现给用户与之交互的对象实体的一种抽象，例如：ECS 实例等 限制条件 权限策略基本元素之一，表示授权生效的限制条件 操作 权限策略基本元素之一，表示对具体资源的操作。取值为：云服务所定义的 API 操作名称 效力 权限策略基本元素之一，表示授权效力。取值为：允许或拒绝 云采用框架白皮书 文档版本：1.0 78 被授权主体 指策略中定义的权限主体，被授权主体可以为 RAM 用户、用户组或 RAM角色 资源目录 阿里云面向企业客户提供的一套多级账号和资源关系管理服务 标签 标签是云资源的标识，可以帮助您从不同维度对具有相同特征的云资源进行分类、搜索和聚合，让资源管理变得更加轻松 资源共享 指多账号

167、间通过共享的方式将一个账号指定资源共享给一个或多个目标账号使用 资源所有者 资源所有者是资源共享的发起方，也是共享资源的拥有者 共享的资源 共享的资源通常为某个云服务的某类资源。例如：专有网络的交换机 资源使用者 资源使用者是资源共享的受益方，对共享的资源具有特定的操作权限 共享单元 共享单元是资源共享的实例。共享单元本身也是一种云资源，拥有独立的ID 和 ARN 资源组 资源组在阿里云账号下进行资源分组管理的一种机制 资源夹 资源夹是资源目录内的组织单元，通常用于指代企业的分公司、业务线或产品 企业管理账号 企业管理账号是资源目录的超级管理员，也是开通资源目录的初始账号 操作审计 操作审计帮

168、助您监控并记录阿里云账号的活动，包括通过阿里云控制台、OpenAPI、开发者工具对云上产品和服务的访问和使用行为 影子跟踪 如果您创建跟踪的同时追踪了多个地域的操作事件，则操作审计会在相关地域创建相同配置的跟踪来收集这些地域的操作事件，这种跟踪叫做影子跟踪 平台事件跟踪 平台事件跟踪是阿里云账号创建的用于记录平台操作事件的跟踪 云采用框架白皮书 文档版本：1.0 79 跟踪 通过设置跟踪将操作事件保存到指定的 OSS 存储空间和 SLS Logstore下，便于进一步分析和存储 Home 地域 Home 地域是发起创建跟踪操作的地域 全局事件 全局事件是全局服务的操作事件。在操作审计控制台的事

169、件查询页面，选择任意地域均可看到全量的全局事件 全局服务 全局服务是不区分地域的服务，例如：RAM。全局服务会产出全局事件 平台操作事件 平台操作事件是阿里云运维团队针对用户服务的维护操作所产生的事件。您可以通过平台操作审计创建跟踪，记录此类事件 操作事件 操作事件是用户通过阿里云控制台、OpenAPI、开发者工具访问和管控云上服务所产生的事件记录 配置审计 一项资源审计服务，为您提供面向资源的配置历史追踪、配置合规审计等能力 等保预检 等保 2.0 预检为云上的合规检测，为您动态且持续地检测阿里云上资源的合规性，从而避免正式检测时多次反复整改，帮助您快速通过等保检测 合规时间线 规则评估在资

170、源配置变更发生时触发，配置时间线会有一个对应的合规时间线，是每次合规评估结果的历史记录 规则 规则指用于判断资源配置是否合规的规则函数。配置时间线 配置审计为您提供每个监控范围内资源的配置时间线 资源配置详情 配置审计通过云服务开放的资源查询接口可获取当前阿里云账号下的所有资源 资源类型 资源类型是一组实体资源的归类 云企业网 承载在阿里云提供的高性能、低延迟的私有全球网络上的一张高可用网络。云企业网可帮助您在不同地域 VPC 间，VPC 与本地数据中心间搭建 云采用框架白皮书 文档版本：1.0 80 私网通信通道。转发路由器 一个云企业网实例将在每个地域内创建一个转发路由器作为您在每个地域内的网络管理运维中心 专有网络 VPC 用户基于阿里云创建的自定义私有网络，不同的专有网络之间二层逻辑隔离，用户可以在自己创建的专有网络内创建和管理云产品实例 交换机 vSwitch 组成专有网络的基础网络设备，用来连接不同的云资源实例 高速通道 EC 用于建立线下 IDC 和云上 CEN 间的私网通信通道，为客户提供一条高灵活度、高质量和高安全性的跨网络通信链路 智能接入网关 SAG 阿里云提供的一站式快速上云解决方案。企业可通过智能接入网关实现Internet 就近加密接入