《阿里云:2023金融企业上云登陆区(Landing Zone)白皮书(64页).pdf》由会员分享,可在线阅读,更多相关《阿里云:2023金融企业上云登陆区(Landing Zone)白皮书(64页).pdf(64页珍藏版)》请在三个皮匠报告上搜索。
1、 2 目录 目录.2 法律声明.5 序言.7 1 金融企业云上治理需求洞察.8 金融上云,合规先行.9 容灾建设成为必选项.10 混合云需要统一治理架构.11 2 金融企业上云登陆区建设指南.13 企业上云总体建设思路.13 企业上云登录区Landing Zone解决方案.15 金融企业上云登录区建设要点.18 3 金融企业上云资源架构.20 企业组织多账号结构设计.20 金融企业云上财务规划.22 使用标签进行资源分类.25 云资源统一命名规范.26 4 金融企业上云网络规划.27 企业级云上网络分区设计.27 网络分区设计.27 分区间网络互通.27 云上业务互联安全设计.28 云上DMZ
2、区域设计.28 默认公网出口.29 第三方API调用的特殊公网出口.29 3 指定域名访问出口.30 云上云下混合组网设计.30 金融企业IDC和总部与云上互联.31 金融线下多分支机构互联.31 金融机构与三方监管机构网络互联.32 跨地域构建企业全球一张网.32 云上同城/异地容灾网络设计.33 小结.34 5 金融企业上云安全防护.36 云上与云下安全的区别.36 基础设施和数据的权限分离.36 交付形态转变.37 安全责任共担模型.37 阿里云云上安全整体方案.38 云上基础安全建设.38 第一步:定义安全管理合规体系.38 第二步:评估安全风险.39 第三步:建设基础防护.39 第四
3、步:安全持续运营.41 云上身份与权限安全.41 身份管理.41 权限管理.45 云上数据安全.47 防护重点1:数据分类分级.49 防护重点2:静态数据防护.49 防护重点3:动态数据防护.50 防护重点4:数据安全审计.50 小结.51 6 金融企业上云容灾设计.52 容灾技术架构选型.52 云上容灾方案设计.53 4 云上容灾参考架构.56 同城容灾参考架构.57 异地容灾参考架构.59 小结.61 7 结束语.62 附录:参考文档.63 5 法律声明 本文档的版权归阿里云所有,您应当通过阿里云网站或阿里云提供的其他授权通道下载、获取本文档,且仅能用于自身的合法合规的业务活动。一、文档使
4、用及更新说明 本文档仅作为用户使用阿里云产品及服务的参考性指引,阿里云以产品及服务的“现状”、“有缺陷”和“当前功能”的状态提供本文档。阿里云在现有技术的基础上尽最大努力提供相应的介绍及操作指引,但阿里云对本文档内容的准确性、完整性不作任何明示或暗示的保证。由于产品版本升级、调整或其他原因,本文档内容有可能变更。阿里云保留在没有任何通知或者提示下,对本文档的内容进行修改的权利,并在阿里云授权通道中不时发布更新后的文档。您应当实时关注用户文档的版本变更,并通过阿里云授权渠道下载、获取最新版的用户文档。二、知识产权声明 本文档中的材料和信息,包括但不限于文本、产品、图片、数据、档案、建议、资料,均
5、由阿里云和/或其关联公司依法拥有其知识产权,包括但不限于商标权、专利权、著作权等。非经阿里云和/或其关联公司书面同意,任何人不得擅自使用、修改、复制、公开传播、改变、散布、发行或公开发表。三、如何联系我们 您对本声明内容有任何疑问和意见,或者您发现本文档存在任何错误,您可以登录阿里云官网,单击上海品茶下方联系我们与我们联系。出品信息 6 出品方:阿里云计算有限公司 监制 陈立伟,黄永法 编写成员 宁江彬,刘冰,龚韵中,庄鑫博,冉庆坤,吴骋骐,张威,钱岩,林龙军,孙岩,崔迪,王睿超 特别鸣谢 张翅(阿里云智能新金融行业解决方案总经理)李津(阿里云智能全球技术服务部总经理)祝顺民(阿里云智能云网络总经
6、理)欧阳欣(阿里云智能云安全总经理)何登成(阿里云智能开放平台总经理)7 序言 在数字经济高速发展的大背景下,金融行业的顶层政策标准指引、传统IT架构升级、业务数字化转型、金融信息技术应用创新需求驱动等因素的多重影响,金融行业上云进程不断加速,从早期的简单用云已经步入到日益深化的阶段。总体看有三个特点来看这个发展和变化。一、随着音视频、大模型等等新技术的出现,不断影响改变着金融业务在客户服务上的形态,金融行业上公共云的业务类型和规模也日益增多。二、金融行业自身技术架构也在不断拥抱和采用云平台和云原生技术,建设自己专有的云平台,更为重要的是绝大多数金融机构都选择公专一体的云平台技术路线。三、随着
7、对云采用的熟悉,金融机构对用云过程中的业务合规、数据安全、稳定可靠、成本优化的要求也越来越高,需要提供一套精细化的上云策略和技术的指导原则和最佳实践。结合阿里云服务众多大型企业客户全栈上云的最佳实践所沉淀的“云采用框架”,以及金融行业的业务、技术和管理要求特点,阿里云首次发布金融企业上云登录区白皮书。在云采用的上云战略、上云准备、应用上云和运营治理的四个阶段中,用云的第一步至关重要,直接影响金融企业中与云相关的架构、研发、运维、运营等等一系列部门的生产关系,同时梳理业务分阶段稳步上云的样板规范。期望以本文开启金融企业客户上云治理的第一个篇章,为未来金融企业更全面的采用更复杂云平台奠定基础。张翅
8、 阿里云智能新金融行业解决方案总经理 8 1 金融企业云上治理需求洞察 分布式、云原生、人工智能等创新技术对传统金融业务带来颠覆性的冲击,金融企业开始积极探索和寻求数字化转型带来的红利,新冠疫情的爆发、大模型的落地应用,更是加速了这一过程。同时,部分传统金融企业面临IT基础设施陈旧、维护和更新成本高的问题,业务创新发展遇到瓶颈。在此背景下,云计算技术成为金融企业数字化转型的重要引擎之一,金融企业对于业务上云和原生创新的需求明显增强。目前,金融客户普遍认可上云的价值:提效降本、弹性敏捷、数据智能、IT现代化等,数字金融行业的一些头部客户已经使用了较多的云服务、并将部分核心业务系统部署在云上。越来
9、越多的金融企业开始积极探讨如何制定及实施“云战略”,上云已经成为金融企业数字化转型的趋势和方向。随着企业上云市场从摸索期进入成熟期,企业对上云的关注点也从保障单个应用顺利迁移上云,转向业务规模上云的管理和治理,当企业上云一段时间、云上资源达到一定规模之后,往往会出现资源管理混乱、网络地址冲突、成本分摊不清、身份权限泄露等一系列运维和安全运营的问题,分析其原因在于,企业客户在上云之初缺乏经验,没有系统性的规划和设计企业云上整体架构。针对企业上云规划场景和需求,阿里云在2021年5月份正式发布Landing Zone企业上云解决方案。过去两年时间,我们通过Landing Zone解决方案服务了20
10、多家金融行业客户进行上云规划和落地。通过拜访、调研这些金融企业客户的管理者和运维团队,我们总结了金融行业上云最为关注的三个方面需求,并在后面章节重点阐述对应的金融行业最佳实践。9 金融上云,合规先行 国内金融企业需要满足监管机构与行业相关政策、以及一系列的安全合规标准(如等保2.0、PCI DSS),一些成熟的大型金融企业制定了企业内部的安全管理制度,安全合规问题在金融企业往往拥有“一票否决权”。因此,对于金融企业上云来说,在考虑云的性能、弹性等技术优势时,必须提前做好安全合规方面的整体设计和沟通,降低业务上云风险。以下梳理了近年来国务院、工信部及人民银行等部门出台的一系列法律法规技术规范,皆
11、在指导云计算的设计、开发、使用和部署,规范引导云计算的建设,提升云服务商的服务水平,规范云计算行业应用市场。时间 发布单位 文件名称 2015.1 国务院 关于促进云计算创新发展培育信息产业新业态的意见 2015.7 国务院 关于积极推进“互联网+”行动的指导意见 2015.11 工信部 云计算综合标准化体系建设指南 2016.7 银保监会 中国银行业信息科技“十三五”发展规划监管指导意见(征求意见稿)2017.7 人民银行 中国金融业信息技术“十三五”发展规划 2018.10 国务院 基于云计算的电子政务公共平台安全规范 2019.7 网信办联合四部委 云计算服务安全评估办法 2019.8
12、人民银行 金融科技(FinTech)发展规划(2019-2021 年)2019.12 保险行业协会 保险行业云计算场景和总体框架 2021.12 人民银行 金融科技发展规划(2022-2025 年)2022.1 银保监会 中国银保监会办公厅关于银行业保险业数字化转型的指导意见 2023.1 证券行业协会 证券公司网络和信息安全三年提升计划(2023-2025)(征求意见稿)表:金融行业监管相关政策梳理 为了支撑云计算相关政策的具体落地,人民银行牵头制定了云计算相关的技术标准,并于2020年印发了中国人民银行关于发布金融行业标准强化金融云规范管理的通知(银发【2020】247号),用于规范云计算
13、技术在金融行业的应用。云计算技术金融应用系列标准包括:云计算技术金融应用规范 技术架构(JR/T 01662020)云计算技术金融应用规范 安全技术要求(JR/T 01672020)云计算技术金融应用规范 容灾(JR/T 01682020)10 人民银行在2020年底发布了金融行业网络安全等级保护实施指引 第2部分:基本要求(JR/T 0071.2-2020),规定了云计算应用在金融行业时需要满足的各等级保护的安全要求。以等保2.0为例,网络安全等级保护制度2.0国家标准中与云相关的要求包括:云上信息系统纳入检测范围。充分考虑了当前企业信息系统的业务多样性和复杂性,新增了云计算平台纳入检测范围
14、。云上租户的信息系统成为独立的检测对象。随着云上服务的复杂度和灵活性日渐成熟,云上租户对托管的资源具有越来越高的控制权,从等保2.0开始,云上租户使用云平台服务所构建的云上信息系统将作为独立的检测对象。强调持续的安全能力构建,而非一次性检测。等保2.0对系统的持续合规要求融入到条例中,引导并监督企业构建一个可持续保护信息系统的安全能力。容灾建设成为必选项 金融行业有着极高的业务连续性要求,保护信息系统免受自然灾害、物理损坏、人为故障影响业务持续运行等的挑战也越来越高。因此,金融企业在上云之初就需要考虑到业务系统的连续性需求,提前做好高可用和容灾架构设计。我国政府及金融监管机构历来高度重视金融行
15、业安全稳定运行及发展,出台了一系列标准及规范以促进金融行业的灾备建设,如下:网上银行信息系统安全通用规范(JR/T 0068-2020)云计算技术金融应用规范 容灾(JR/T 0168-2020)金融行业信息系统信息安全等级保护实施指引(JR/T 0071-2012)商业银行数据中心监管指引(银监办发 2010 114 号)银行业信息系统灾难恢复管理规范(JR/T 0044-2008)其中,云计算技术金融应用规范 容灾(JR/T 0168-2020)标准规定了金融领域云计算平台的容灾要求,包括云计算平台容灾能力分级、灾难恢复预案与演练、组织管理、监控管理等内容。该标准针对金融行业特点,更新定义
16、了 4 个容灾等级和 4 个能力要素,是指导金融行业云上容灾建设的核心标准。11 JR/T 0168-2020 定义的关键指标如下:RTO:恢复时间目标(recovery time object),指灾难发生后,信息系统从停顿到必须恢复的时间要求。RPO:恢复点目标(recovery point object),指灾难发生后,数据必须恢复到的时间点要求。应用于金融领域的云计算平台容灾能力等级关键指标要求 容灾等级 RTO RPO 可用性 3 级 24 小时 24 小时 每年非计划服务中断时间不超过 4 天,系统可用性至少达到 99%。4 级 4 小时 1 小时 每年非计划服务中断时间不超过 1
17、0 小时,系统可用性至少达到 99.9%。5 级 30 分钟 0 每年非计划服务中断时间不超过 1 小时,系统可用性至少达到 99.99%。6 级 2 分钟 0 每年非计划服务中断时间不超过 5 分钟,系统可用性至少达到 99.999%。应用于金融领域的云计算平台应至少达到容灾能力 3 级要求,本文以金融行业常见的 4/5/6 级分析,其核心技术要求如下:同城和异地均需提供数据灾备能力 同城和异地均需部署同等能力的网络及数据处理能力 应用系统具备高可用能力 具备自动或集中式切换能力 至少每年进行一次相关预案的更新和演练 混合云需要统一治理架构 金融企业由于所处行业的特性,团体云加私有云的混合云
18、基础设施模式普遍存在。对于采用混合云架构的企业来说,统一管理和运维混合云架构,是摆在基础架构和运维团队面前的挑战。因此,金融企业在采用不同云服务的过程中,需要通过一套统一的IT治理架构体系管理异构基础设施,并12 提前做好整体规划设计(包括身份、网络、安全和运维等多个维度),能够避免后期管理混乱、网络冲突、安全风险等问题,简化服务流程、提升统一运维效率,有效支撑业务在云上的敏捷创新。13 2 金融企业上云登陆区建设指南 企业上云总体建设思路 云计算经过十几年的发展已经从最初的概念,逐步演变成为企业数字化转型的基础底座。云计算与传统数据中心相比,在资源供给、使用和管理模式等方面有所不同,因此企业
19、在云转型的过程中,采用一套适合云形态的管理和治理架构成为必然。阿里云作为中国最大的云服务供应商(Cloud Service Provider),将服务大量企业客户的经验,总结形成云采用框架(Cloud Adoption Framework,简称CAF):一方面从IT管理的角度阐述了如何合理规划、使用和管理云资产以及构建合规、敏捷和高效的企业IT服务体系,另一方面从业务的视角描述了对云计算给企业带来的核心价值,比如有效利用云的标准服务模版来实现业务应用快速在云端落地、通过有效的成本和资源监控降低企业业务经营风险,使用云上自动化工具和方法提升企业敏捷开发和运维的能力和文化。云采用框架定义了企业引入
20、云服务的四个阶段:在上云战略阶段,领导层需要思考上云能为业务带来什么价值,并在公司层面确定相应的战略。在上云准备阶段,IT团队需要制定云采用的顶层设计,确保组织协同和可管可控。在应用上云阶段,开始迁移原有的系统上云或者在云上开展新的业务。在运营治理阶段,企业不断发现和解决运营过程中的问题和风险,提升服务质量。金融企业上云的过程,一般可以分为“尝试上云-核心上云-全面上云”三个阶段:从部分应用、测试业务尝试上云,到数据库、关键业务系统等核心上云,到包括基础设施、技术平台、数据平台、业务应用、运维管控系统的全面上云和云上持续演进。14 在组织层面,企业上云和用云的整个生命周期,需要专业团队进行合理
21、的规划、实施以及持续优化云采用方案,推进企业更好的利用上云的优势促进业务发展。企业通常至少有一个云管理团队,或由相关负责人组建一个云卓越中心(Cloud Center of Excellence,简称CCoE)负责规划和对接上云的整体方案。Tips 我们在服务客户过程中,发现有些企业有很明确的上云业务目标和推进计划,但是往往忽略了在组织层面的团队建设。常见的几个误区和现象:1)团队缺少使用云的经验,落地进度和质量不能进行有效管理;2)团队缺少云架构师的角色,对业务需求和技术架构缺少综合判断;3)团队间缺少横向沟通,认为“上云只是IT团队内部的事情”。15 下图是一个典型的企业组织架构,不同的团
22、队对上云关注点不尽相同,需要有一个云管理团队在公司层面确认上云的整体计划、步骤,以及收集业务团队的具体需求。例如,安全合规问题往往是金融企业上云关注的重要因素,云团队在上云规划之初邀请安全合规团队参与项目设计与评审,能有效降低企业上云风险和后期整改成本,保障上云项目顺利有序进行。为了满足企业上云需求,企业组织需做好以下准备:企业管理层:企业管理层需要明确云在公司的战略地位以及各个团队应该如何使用云。云卓越中心:该团队可以是虚拟的组织,设计提供云服务的模式和管理体系,并提供相应的技术准备。其中的成员角色包括:架构师和专业技术人员,负责上云架构设计和业务上云迁移工作;安全、合规等领域专家,负责设计
23、企业IT治理方案、预估风险和制定治理规则;财务专家,负责制定财务的管理流程,成本分摊原则。云管理团队:在企业业务全面上云之后,持续优化上云架构,为新业务提供云上环境。建立企业云上运维体系,搭建运维平台,以及通过自动化运维的方式,对云上环境进行持续治理和管理。根据新业务需求,分配所需云资源和所需权限,并对资源进行初始化配置后交付。应用运维团队只需用云,无需关注基础设施搭建。企业上云登录区Landing Zone解决方案 阿里云Landing Zone解决方案基于大量企业的上云实践验证,将企业云上 IT 治理框架分为八个模块,并16 通过这八个模块实现客户的云上治理,帮助企业规划云上资源结构、访问
24、控制、网络架构、安全合规体系,搭建可管理、可扩展的云环境。企业客户可以在此基础上缩短上云周期,将原有的业务平顺上云并快速开展新业务。Landing Zone 框架示意图 Landing Zone在以下八个模块,针对企业不同业务场景,形成了一套解决方案集合。资源管理 在上云准备阶段,客户需要根据业务现状和应用的长期规划,设计资源管理方案,包含:账号架构:规划阿里云上多账号体系,规划上云应用的资源部署原则。标签体系:基于标签进行资源的管理,设计标签元数据和标签的全生命周期流程。财务管理 云上财务管理方案,包含:成本分账:设计成本核算模型,对云上支出进行基于成本中心的账单分析方案。成本分析:设计客户
25、的财务分析方案,提供阿里云计费能力对接方案,协助客户接入企业内部财务分17 析平台,获取账单、费用明细等费用数据。成本优化:根据所采用的云服务成本优化的最佳实践、部署方案和审计方案。身份权限 企业云上身份权限管理方案,包含:身份认证:梳理身份使用场景,根据场景设计身份认证集成方案,实现与现有身份认证管理系统的集成。权限管理:梳理企业云上角色,基于“权限最小化”原则进行权限定义。网络规划 企业级网络规划主要包含以下部分:网络接入方案:规划客户环境与云平台网络接入方案,包括专线或VPN接入、应用层访问接入,运维管理接入方案。云内部网络方案:定义网络架构规划方案,包括VPC规划、网段及IP地址规划、
26、云上DMZ区域设计。云间互联方案:基于阿里云CEN,在不同的区域、不同的账号、不同的本地数据中心建立VPC互联。安全防护 在上云登录区建设阶段,安全方案主要涉及以下方面:网络安全:主要指安全组配置,设计云上网络安全域划分方案,通过网络安全区域进行应用的隔离,同时针对应用的具体需求进行联通配置。主机安全:包括主机的漏洞、威胁和攻击防护方案。数据安全:包括密钥管理、数据库访问控制、存储访问控制,根据客户需求设计满足客户安全要求的数据安全方案。合规审计 预防性管控:设计符合企业合规红线,禁止执行某些管理操作,基于管控策略实现租户级的管控。发现性管控:设计合规基线并对企业资源进行持续监控,发现不合规资
27、源时,进行记录、报警乃至自动修复。操作日志的审计:对云上操作、资源变更等日志进行持久化保存,以备审计之需。18 运维管理 为了提升企业IT整体运维效率,运维管理方案主要关注:监控管理:基于阿里云已有的监控产品,以阿里云云监控+Arms+Prometheus 为基础,帮助客户设计应用和基础设施监控的标准和规范。日志管理:基于阿里云已有日志服务产品SLS,结合客户实际情况设计日志接入和管理规范。自动化 上云登录区建设关注的自动化方案,主要包含:自动化管理流程设计:基于客户现状,设计自动化基础设施管理流程,包括基础设施代码研发、管理、部署规范。CI/CD 工具集成设计:设计针对客户现有CI/CD工具
28、的集成方案,包含CI/CD 工具部署基础设施所需的阿里云环境网络连通性方案以及基础设施部署所需的阿里云上相关服务的认证授权方案。IaC 模版:构建服务目录模版化资源创建,实现自助服务,包含RAM 身份创建模板、网络基础设施构建模板。金融企业上云登录区建设要点 通过Landing Zone的规划、设计和落地的过程,企业可以从架构、标准、组织、流程、工具多层面达到上云Ready;当企业真正规模上云之时,企业内部的组织、流程和团队人员已经可以很好的承接项目的落地,并以合规、安全、最佳实践的姿势达到云卓越运营,顺利开启企业的云上数字化转型之旅。19 图:上云登录区建设从多维度推进企业云转型 本章介绍了
29、企业上云框架和Landing Zone解决方案的整体内容,白皮书后续章节将主要聚焦于金融企业上云登录区的四个建设要点:1)资源架构,2)网络规划,3)安全防护,4)容灾设计。我们在每个模块沉淀了多个场景化解决方案,了解更多细节内容,请访问阿里云CAF官网和Landing Zone官网。Landing Zone解决方案大图 20 3 金融企业上云资源架构 云上资源架构,主要是从企业组织维度来看,企业如何实现云上不同业务之间的资源安全隔离、高效运维和财务管理等云上资源管理需求。这背后的原因是云的形态不同于传统数据中心,公有云服务商以账号(Account)的形式为不同用户提供服务,账号成为资源管理的
30、基本单元,并以账号维度提供财务账单。本章节将介绍企业组织多账号体系、财务规划,以及资源标签和命名规范等资源管理最佳实践。企业组织多账号结构设计 阿里云账号(Alibaba Cloud Account),是阿里云资源归属、资源使用计量计费的基本主体。阿里云账号为其名下所拥有的资源付费,并对其名下所有资源拥有完全控制权限。随着企业上云业务的增多和规模的增大,业务之间的复杂度明显提升,对于云资源的管理提出了巨大的挑战,这也要求企业在上云初期要做好提前规划。我们建议企业用户上云之初规划采用结构化的资源(多账号)管理架构,通过合理的组织结构和规则配置,以满足业务日后扩展的需求。企业云上使用多账号体系具备
31、以下优势:资源隔离:云上多个账号实现企业不同业务或应用间的资源相互独立;组织管理:对于大型企业客户,多账号可以解决多法律实体、多业态管理等业务诉求;配额管理:多个账号可以突破单账号下云资源服务配额限制等约束;财务管理:可以实现各业务账号的独立结算,突破单账号资源配额的限制。21 多账号结构规划 结合账号规范以及资源管控隔离的需求,我们通常建议设置一个主账号(MA:Master Account)作为支付账号,同时也是账号结构中的根账号,该账号下不放置具体的云资源,在该账号的根资源夹下创建两个资源夹:Core、Applications,用以管理成员账号。在 Core 资源夹中放置共享资源的账号:用
32、于集中横向管理类服务的部署,例如网络账号、日志账号、安全账号等。在 Applications 资源夹中放置具体的应用:应用账号可以结合企业的实际需要按照多个维度进行设计,如:环境(开发、测试、生产)、成本中心、应用、业务线、部门等。使用资源夹作为日后管控策略和基线实施单元。建议通过角色扮演的方式访问成员账号。金融企业常见的账号划分维度:维度一,按业务隔离:保险/基金/大数据/维度一,按应用环境:生产/测试/开发/维度三,按网络类型:公网/内网/某金融企业多账号设计案例 22 企业主账号(Root Account):X公司的阿里云资源目录主账号,除了可以对企业资源目录管理以外,同时也是企业财务中
33、心的唯一入口账号,可以管理整个企业平台级别的阿里云财务事务。核心账号(Core Accounts):根据不同功能设计了4个核心服务账号,主要是用于部署企业云环境安全防护、网络管控、资源日志监控与企业共享服务有关的云基础设施,形成对企业成员账号的统一服务管理。网络与安全账号(NetworkSecurity Account):负责整个企业组织的网络和安全核心组件的部署和配置。审计合规账号(Audit Account):负责所有企业成员的云上操作归集和服务合规配置审查。日志账号(Logging Account):负责收集并临时存储来自所有企业成员账号中的云服务日志,并统一投递到企业的中心日志分析系统
34、。共享服务账号(SharedService Account):用于部署企业共享的服务与资源。业务账号(Business Unit Accounts):X公司以环境维度来划分和管理企业的业务账号,在不同环境下再对业务部门进行区分。创建出来的新企业成员账号将自动应用在企业规划好的安全与合规框架下,并被赋予合理的资源访问权限。金融企业云上财务规划 财务管理主要指企业在用云过程中的账单、资金、费用、发票等财资票税方面的管理;云上的财务管理规范的设计需要考虑到财务管理的核心目标,即确保企业财务的合法、规范、透明和精准,同时提高财务管理的效率和便捷性,对于金融企业,除了上述的关注点外,财务处理的自动化和智
35、能化也是其重点关注的内容,阿里云提供了丰富的财务功能来满足企业复杂的财务管理需求,企业可以根据实际的业务要求选择最合适的财资管理方式。通常而言,金融企业有着完善的财务结算体系以及在其他云上的财务实践,所以阿里云上的财务管理方案需要适配企业已有的财务管理体系,在设计财务管理方案之初,金融企业可能会面临如下的挑战:如何在阿里云上统一管理账单、信控、合同、付款、发票?如何根据团队、部门、成本中心、项目等维度进行快速的账单拆分?23 如何有效集中监控成本和支出?针对以上的挑战,结合企业财务组织结构、商务优惠、结算模式、成本监控等因素进行考量。我们设计如下:企业财务组织结构,通常代表一家企业的成本管理结
36、构。这个结构是多层级的,包括财务管理部门、业务部门和云资源。财务管理部门负责评估和管理云业务预算,为业务部门的云上费用做统一结算,持续跟踪和分析消费账单。财务管理部门的职责通过财务管理部门账号来承载。业务部门负责在预算范围内开通和管理云资源。每个业务部门开通独立的云账号。云资源由业务部门开通和管理,归属于相应的业务部门账号下。统一管控:企业财务部门可以实现统一的财资管理:账单、信控、合同、付款、发票集中管控。快速分账:企业财务部门可以根据不同维度实现快速分账,如成本中心、团队、BU、项目等。成本分析:结合多账号体系,各账号的开销一目了然,有助于各业务部门的成本分析和管理。使用企业财务服务提供的
37、关联账号能力,将组织多层级结构搭建起来。在这种结构下,财务人员能清晰完整地了解整个企业的云上成本,便于进行消费预测和成本优化。业务部门的技术人员在预算范围内可以灵活地按需实时开通云资源,省去传统企业繁琐的资源申请流程,提升了工作效率。各企业的内部组织结构虽然不尽相同,但业务部门可以同时是项目或小组等成本管理的单元,可以按照自己的组织模式映射成上述结构。设计建议 财务人员需要与业务部门加强沟通,及时收集业务部门的资源采购计划,定期向业务部门同步成本分摊信息。财务人员需要持续关注费用趋势。财务人员设计标签分类,建议技术人员在开通云资源时绑定对应标签,便于基于标签做细粒度的分账。技术人员按需开通资源
38、,在预算范围内优化资源结构。企业在建立账号关联时,客户可以根据企业自身的管理需要,选择如下业务模式之一:【财务管理】、【财务托管】。24 财务托管 主账号、子账号都是官网的普通账号,有完整的财务属性。在该业务模式下,子账号将自己的资金、发票、账单财务权限赋予给主账号,统一由主账号进行子账号的代付、开票、账单结算等业务管理,这也是金融企业在广泛使用的一种财资管理模式。财务管理 主账号、子账号都是官网的普通账号,有完整的财务属性。主子账号之间建立关联后,通过授权关系进行业务管理。在日常业务过程中,主子账号分别管理自己的资金信控、优惠合同、账单发票等。当进行授权后,被授权一方可以管理另一方被授权的业
39、务。如:子账号授权主账号查看账单,则被授权的主账号可以查看子账号的账单。商务优惠 商务优惠,指企业购买使用云服务的资费与优惠,包括与阿里云签订的商务合同条款中约定的框架折扣。企业可以采用财务托管的模式,从而将主账号(如财务部门管理账号)设置为折扣生效的目标账号。这么做的优势体现在:关联账号的开通和云资源的使用,计费出账时可以享受到主账号的折扣优惠。成本账单 阿里云面向企业客户,提供成本账单功能:企业可以用来观察每月的成本;可以基于实例、基于产品来看费用的分摊情况。对于预付费的消费而言,也可以把消费费用分摊到每个月。并且,财务管理与托管的主账号可显示全部关联账号的所有分摊数据。25 费用分析 另
40、外,阿里云费用分析功能还可帮助企业更好地管理云服务资源的消费情况。使用费用分析功能,可以多维度查看资源成本的趋势(最大支持12个月)、查看全面的成本组成结构、进行未来成本的预测等,并可将一组筛选条件保存为报告,快捷查看。使用标签进行资源分类 标签是对资产进行分类的简便方法。标签将元数据关联到资产,该元数据可用于基于各种数据点对资产进行分类。当使用标签对资产进行分类作为成本管理工作的一部分时,企业通常需要以下标签:业务线、部门、成本中心、地理位置、环境、项目、应用等。阿里云费用中心的“分账账单”可以使用这些标记创建成本数据的不同视图。提前定义标签的目录和取值范围。这背后是一套基于业务的标签设计和
41、使用流程,需要提前设计。明确标签的使用场景:o 使用标签进行分账:阿里云费用中心的分账账单支持按标签细分阿里云成本的功能。最常见的情 况,客户可以使用成本中心(cost center)、业务单元(business unit)或者项目组(project)将成本与业务部门进行关联。客户也可以轻松地将成本与技术或安全性维度作为分账维度,例如特定应用(application)、环境(env)等。o 自动化运维和监控:自动化运维/自动化开通是在日常业务中比较常见的场景。技术人员往往通过一类标签来定义批量运维、检测的策略。建立标签的巡检机制,及时发现没有绑定标签的云产品并评估影响和制定应对策略。使用标签描
42、述应用:一般情况下,组织可根据日常管理层级构建资源归属的标签组合。组合形式一般不建议超过 3 个标签。例如,某金融企业为了能够快速找到对应资源,设计如下标签:地区:描述资源地域归属,比如:北京、上海、新加坡。部门:描述资源的业务归属信息,比如:信息部、销售部、xx分公司。环境:描述资源归属的业务环境,比如:生产、测试、研发。26 云资源统一命名规范 云资源建议遵循统一的命名规范,后期在运维阶段,可以通过资源名称快速定位到该资源的所有者及其关键信息,云资源的命名规范我们建议遵循以下原则:使用描述性和有意义的名称:使用能清楚表明资源用途和功能的名称,为了避免名称过长,建议使用无歧义的缩写。保持一致
43、性:确保在所有资源的命名规范中保持一致性。避免使用特殊字符:避免在资源名称中使用逗号、点或空格等特殊字符。使用分层命名结构:使用分层命名结构,帮助您将资源组织成逻辑组。例如,您可以使用包含环境、应用和资源类别的命名规范。通常建议命名规范中不应超过五个字段。27 4 金融企业上云网络规划 在公有云商业模式推出之前,传统金融企业构建其IT系统主要是在其云下数据中心部署大量的服务器、交换机、路由器等设备进行物理组网,以此来支撑企业内部的应用系统以及对外提供的业务服务。随着越来越多的金融客户选择上云,如何在云上搭建一套企业级安全的网络,成为了传统金融机构上云面临的核心问题。传统数据中心网络中的安全防护
44、,一般的做法都是部署大量的安全设备组建一个安全域来实现企业系统的安全防护和访问控制,网络流量需要按照业务逻辑和安全防护等级穿过安全域内的不同设备,这就是所谓的服务链(Service Chain)。随着SDN及网络虚拟化的不断推进,服务链逐渐变得更加重要,服务链场景下主要有南北向流量(访问internet/被internet用户访问)和东西向流量(企业内部系统互访)组成。客户在公有云上部署应用的时候也会延续相同的安全策略,VPC到VPC的流量,VPC和本地IDC以及VPC与internet之间流量都希望能够实现统一的安全控制。本章从金融行业企业级云上网络分区、云上容灾网络设计、云上DMZ区设计、
45、云上访问流量安全管控设计、构建全球一张网及云上云下混合云组网等场景分别进行阐述,便于读者能够全面地了解阿里云网络的能力,协助客户更好地上云。企业级云上网络分区设计 基于VPC网络基础互联、网络安全域分区、网络安全隔离和访问控制等云上组网核心的诉求,云上网络分区设计原则整体分为以下三个部分。网络分区设计 满足业务规模化发展需求,合理划分VPC和vSW,DMZ、生产、开发测试、运维管理等独立VPC部署。满足可靠稳定性,重要业务业务系统跨可用区部署。满足业务之间的高效调用和交互,关联业务尽可能部署同Region。分区间网络互通 采用CEN-TR,打通阿里云上任意Region开通的业务系统,实现全局一
46、张内网。28 VPC按需加入TR,按需控制不同VPC之间or不同vSW之间的互通关系。采用多路由表,配置默认路由,将对互联网的访问调流到DMZ区,统一公网出口。云上业务互联安全设计 公网出入口配置云防火墙管控进出流量(可搭配WAF)。跨分区通过云企业网(CEN)搭配云防火墙实现策略管控。VPC内配置安全组策略,实现微隔离,建议搭配云防火墙,实现策略统一管理。云上DMZ区域设计 传统金融机构客户在安全、成本、权限、监控等诉求的迭代下,云上公网分布式出口方案逐渐从原来的分布式公网出口演进为统一公网出口。如图:29 前者适合企业上云初期以及一些非敏感业务,各部门/业务团队可按需使用EIP/NATGW
47、/LB进行各自的公网出口部署,自动度和灵活性较高,同时也带来了企业的云上安全和管理隐患问题;后者则将公网出口进行统一部署、统一管理、统一监控、统一安全策略部署,更能满足金融客户云上的整体安全管控及监管要求。同时,当前绝大部分传统金融机构还未完全上云,云上和IDC构建混合云网络的架构也是主流落地场景。针对混合云架构的阶段,金融客户也可以考虑将IDC的DMZ区优先部署上云,通过阿里云网络和云安全的能力在云上1:1完成DMZ上云的改造。本方案着重介绍了传统金融机构DMZ区在云上的设计理念。本方案主要分3个设计场景,默认公网出口、第三方供应商API接口调用的特殊公网出口,以及指定域名访问出口,均部署在
48、统一出口区域DMZ-VPC。默认公网出口 在DMZ-VPC内部署增强型NATGW,并申请“统一网络出口”权限开通跨VPC访问功能DMZ-VPC公网能力,实现统一公网出口。账号-1和账号-2的APP-VPC均可通过DMZ-VPC的默认NATGW的SNAT策略出局访问公网,同时并通过DNAT策略实现跨VPC的公网入口效果。第三方API调用的特殊公网出口 30 在VPC已有默认NATGW的情况下,由于第三方供应商API接口调用时需要双方互相针对IP地址加白名单,且出口独立性较强,不能影响其他业务或被其他业务影响,需于DMZ-VPC再部署一个特殊的NATGW,将三方目标网段路由给此NATGW,实现特殊
49、出口。账号-2 VPC中的ECS访问常规公网时从默认NATGW出口出局,调用第三方供应商API时从特殊公网出口出局。指定域名访问出口 使用LB+EIP(ECS)+PrivateZone方式实现特殊域名出口,将需要指定出口访问的域名部署在PrivateZone中并应用于本VPC。当业务访问指定域名时,会被PrivateZone自动解析为DMZ-VPC的特殊域名出口的LB私网IP,通过代理的方式从后端服务器的公网出口出局。云上云下混合组网设计 金融客户在云上构建新的业务系统之前,往往云下已投入较多的IT资源,所以上云后,部分企业会选择将31 部分业务系统保留在企业IDC,混合云状态会长期存在。同时
50、,金融企业往往拥有较多的线下分支机构,有与总部办公室、企业IDC之间的内网互通需求,当业务逐步上云后,会涉及到线下分支既需要和线下总部互通,也需要和云上互通。那如何打造一张覆盖云上云下多地域互联的内部局域网,同时确保每个分支/总部之间两端之间最短路径互通,解决传统网络绕行问题,是金融客户上云对云供应商云网络能力构建的另外一块强诉求。阿里云网络按照传统金融机构线下不同组织环境的定位、规模以及与云上系统的关系,推荐如下互通方式。金融企业IDC和总部与云上互联 推荐使用高速通道-物理专线互通。针对传统金融机构,云下IT资源大多分布在两地三中心的多个数据中心机房内,通过物理分区或者逻辑分区隔离不同业务
51、区域之间的网络。此时通过总部/IDC统一采购一组合规运营商大带宽专线,接入到阿里云专线接入点机房。从而和云上环境,构建一条稳定、低时延、高质量的内部专线通道,满足安全合规上的诉求。关于高速通道-物理专线的更多信息,请参见高速通道-物理专线。金融线下多分支机构互联 推荐采用智能接入网关SAG,通过SAG就近加密接入阿里云分布在全球的pop点,打破地域限制,覆盖各种分支形态,形成云上云下一张内网。因为阿里云提供非常多的POP接入点,所以分支机构最后一公里(采用VPN加密通道)的距离会很短,长传全部走阿里云内网传输物理专线,从而保证端到端网络质量仅次于专线,但是价格接近VPN。关于智能接入网关SAG
52、的更多信息,请参见智能接入网关。针对不方便部署SAG(如偏远分支机构等)、企业想利旧资产等情况。则可以通过本地的VPN网关快速和云上VPN网关实现内网打通。虽然效果不如智能接入网关SAG,但是可以让偏远的分支优先解决内网互通32 的诉求。关于VPN网关的更多信息,请参见VPN网关。金融机构与三方监管机构网络互联 传统金融机构,往往需要与多个三方监管机构互联已完成业务数据的互通/上报,而监管机构为了其安全管控的要求需指定分配金融机构的访问ip地址。针对如上场景,利用阿里云VPC 私网NAT来实现云上云下地址冲突、监管机构指定通讯ip等挑战,让云上金融客户轻松应对。云上VPC与三方金融监管机构互联
53、场景下,应监管机构网段要求,存在如下两个需求:1、阿里云侧需支持公网私用地址;2、阿里云侧需完成云上VPC源地址转换成监管分配的地址。注1:图示箭头业务访问方向 注2:访问节点1为VPC默认系统路由表,访问节点2为NAT所在的子网路由表,访问节点3为VBR路由表。跨地域构建企业全球一张网 阿里云网络依托于阿里巴巴全球底层物理传输资源,以云企业网产品为核心,结合高速通道-物理专线、智能接入网关SAG及VPNGW等接入网络,可以帮金融客户快速的构建全球一张企业内网,以便客户可以分钟级地打通部署在阿里云全球各地region的服务,完成业务的全球化。33 全场景的接入能力:物理专线、SAG或VPN网关
54、等多种混合云网络接入方式,实现企业一点就近接入。灵活组合,高可用:双物理专线,专线+VPN,专线+SDWAN方式灵活组合,快速构建一张稳定上云网络。全球跨域互联:云企业网CEN打通客户各地域IDC,分支,阿里云VPC,快速构建一张稳定,可靠,高弹性的私有全球网络。云上同城/异地容灾网络设计 金融企业对于业务容灾要求非常高,在云上如何利用云网络的能力实现容灾备份是客户业务架构落地的核心能力构建。场景利用阿里云LB(7层应用型ALB/4层网络型NLB)构建应用池,解决应用单节点问题,RTO=0 场景利用将ECS分布在不同可用区,结合SLB/RDS默认同城容灾,轻松实现整个系统同城容灾,单IDC故障
55、,自动切换,RTO=0 场景开通灾备资源,通过DTS服务+CEN跨地域带宽实现跨region数据同步,达到两地三中心应用容灾级容灾,切换时只需依次切换RDS和修改域名服务指向即可,RTO分钟级 34 业务部署模式:相同的业务应用可以分别部署在阿里云不同Region的多个数据中心(例如:北京2个机房和上海2个机房)。生产中心和同城灾备中心处于Active模式,应用访问同一数据库实例(数据在两个同城中心各存储一份),异地灾备中心处于Standby模式。数据复制方式:RDS服务实现从北京生产到北京同城灾备,再到上海异地灾备的单向串级数据复制,OSS服务实现从北京生产到北京同城灾备,再到上海异地灾备的
56、单向串级数据复制。故障切换回切:DNS将生产IP从原生产中心修改到灾备中心,实现北京到上海的故障切换和服务恢复机制,主站发生故障时,由备站继续提供服务。详细的灾备架构参见第四章“金融企业上云登陆区建设要点(3)容灾设计”。小结 对于金融企业不同业务场景的需求,从登录区整体架构和云网络产品能力出发,金融客户云上网络建设场景主要总结为以下三类。第一类:云上核心系统的网络基础架构构建 场景说明 落地实施方案 金融行业企业级云上网络分区 请参考基于CEN-TR实现企业级云上互联 金融企业云上容灾网络设计 构建全球一张网 35 云上DMZ区设计 请参考企业级公网统一出口方案 第二类:云上云下混合云网络构
57、建及统一化管理 场景说明 落地实施方案 云上云下混合云组网 请参考混合云组网方案 金融机构与三方监管机构互联 请参考与三方监管机构网络互联 第三类:云上网络安全强管控构建 场景说明 落地实施方案 云上访问流量网络安全管控设计 请参考转发路由器TR结合云防火墙部署方案 36 5 金融企业上云安全防护 金融行业的业务特点决定了其信息系统掌握了大量个人敏感信息,如身份信息、征信信息、账号信息、鉴别信息、金融交易信息、财产信息、借贷信息等客户金融信息,既有客户在金融业务过程中积累的业务数据,也有个人隐私数据。安全是金融信息系统的重中之重,一切业务都必须在安全合规的基础上开展。近年来,金融行业数字化转型
58、不断深入,加速与新技术的业务融合的同时,针对金融信息系统的安全威胁持续升级,全球出现了很多重大金融信息安全事件。如2021年1月,印度某支付处理公司超过1亿用户的借记卡、信用卡信息遭窃取。2022年2月,乌克兰某银行受到DDoS攻击,导致部分服务中断,客户无法访问网上银行账户。面对金融行业信息安全的新态势,国家从中央部门、监管机构、研究机构等不同层面均出台了法律法规、调控政策、行业标准等,对关键信息基础设施安全、数据安全和个人信息保护、供应链安全等提出了明确要求。阿里云在国家政策法规的指导下,建设了金融团体云,服务于银行、证券、保险、基金等金融机构,采用独立的机房集群提供满足监管要求的云产品,
59、按照人民银行和银保监会的合规标准建设,在安全性、服务可用性和数据可靠性等方面作了大幅增强。与此同时,阿里云结合金融行业安全特点,同各大头部金融厂商一起在金融上云的建设实践中不断形成完善安全保障体系,在基础架构安全、混合云安全、数据安全等领域沉淀了一系列的解决方案。云上与云下安全的区别 与传统云下部署IT系统不同,云上金融应用在安全建设上会伴随着一系列的改变,主要表现在以下方面。基础设施和数据的权限分离 在金融企业系统上云的过程中,会伴随着基础设施和数据的所有权、管理权、使用权进行了分离,最明显的是基础设施和数据不在本地,数据的所有权仍属于最终用户,但管理权和使用权根据责任分担模型进行了分工。例
60、如,大部分情况下对数据和资源的直接控制措施(物理、逻辑、人员、隔离措施)将由云计算服务提供商负责,用户将更加专注于自身的业务。37 交付形态转变 从基于传统本地的安全开发、运维和测试到基于云弹性扩展的构建,业务数据和应用从基于传统IDC设施到基于云计算基础设施和云产品生态构建。开发、测试、运维、安全和交付模式均在快速变化。组织的数据从原本封闭的单一数据中心扩散到云计算中心。上云后,用户将通过基于云原生的安全产品和云产品安全能力实现基础安全,用户将更加关注交付本身的安全,而不是大量基础安全工作。安全责任共担模型 这些改变所带来的问题是如何定义云厂商和用户的安全边界,由此也诞生了云上安全共担模型。
61、这种共担模式可以减轻客户的运维负担,因为云厂商负责运行、管理和控制从主机操作系统和虚拟层组件,一直到服务运营所在物理设施的安全性。客户负责管理操作系统(包括更新和安全补丁)、其他关联应用程序软件以及云厂商提供的安全组防火墙的配置。管理者可以利用云上优势,快速搭建满足业务发展的安全保障措施,使得传统云下企业能够享受云安全带来的技术红利,提升传统企业安全防护水平。这一责任共担的性质还提供了支持部署的灵活性和客户控制能力。图:阿里云安全责任共担模型 同时需要注意,用户在使用不同的云上产品时,所承担的安全责任不尽相同,在使用云上IaaS产品时,用38 户侧需对数据安全、应用安全、中间件安全、数据库安全
62、、容器安全、虚拟机安全、虚拟存储安全、虚拟网络安全进行负责,在使用云厂商PaaS产品时,用户只需对数据安全、应用安全负责,在使用云厂商SaaS产品时,用户仅需对数据安全负责。阿里云云上安全整体方案 阿里云提供了全面的安全基础设施能力,覆盖虚拟化安全、主机安全、应用安全、数据安全、业务安全以及各种监控审计措施的云盾系列安全产品,满足云上安全合规和风控需求。云上基础安全建设 企业在上云时,可通过以下四步建设云上安全防护体系。第一步:定义安全管理合规体系 根据合规、法律要求、自身风险状况选择要导入的安全组织和体系,协助企业整体考虑安全体系。根据云上业务系统所属的业务性质,例如在国内从事金融行业服务必
63、须考虑等级保护和第三方支付合规以及行业监管机构的安全要求,如果业务拓展到海外还应考虑PCI-DSS以及当地的法律监管要求。同时,通用的39 ISO27001也是上市公司内控的一个重要考虑因素。在定义安全管理合规体系的同时,建议对所有系统进行分级分类,不同安全等级系统执行不同安全防护标准。第二步:评估安全风险 安全风险评估是企业信息系统建设的安全根基,进行安全评估可以达到“以最小成本获得最大安全保障”的效果。未经安全评估的系统,可能存在大量安全漏洞,给企业业务带来巨大损失。阿里云提供渗透测试服务,安全专家通过模拟真实黑客的技术手段对目标进行漏洞检测,突破系统的安全防护手段,深入评估漏洞可能造成的
64、实际影响。渗透测试的人员为阿里云渗透测试专家。渗透测试服务可以帮助您发现当前系统中存在的安全隐患,增加信息安全的认知程度,同时也可以检验当前防御手段的有效性。用户可在系统上线前通过该服务对其进行安全风险评估。第三步:建设基础防护 用户在云上建设基础防护也可分为进阶的三步走。安全基础配置:用户可通过云厂商默认安全能力,减少网络攻击面和权限滥用。比如使用安全组和ACL对资源进行访问控制,RAM进行集中授权、集中审计提供可靠的原始数据,通过操作审计分析操作记录整体安全运行态势、实现全生命周期的日志管理,快照服务可对日常数据记录管理、数据泄密追溯、覆盖数据全生命周期。40 基础安全防护:在完成安全基础
65、配置后,可通过云安全中心和云防火墙建设企业安全能力的第一道屏障,帮助企业抵御攻击和入侵,提高主动安全防御能力。云安全中心具备持续监测、深度防御、全面分析、快速响应能力,有效发现和阻止病毒传播、黑客攻击、勒索加密、漏洞利用、AK泄漏等风险事件,帮助实现一体化、自动化的安全运营闭环,保护主机、容器、虚拟机等工作负载安全性,同时满足监管合规要求。云防火墙可实现南北向和东西向流量的统一管理,提供流量监控、精准访问控制、实时入侵防御等功能,全面保护用户的网络边界。从而建设企业安全能力的第一道屏障,帮助企业抵御攻击和入侵,提高主动安全防御能力。增强安全防护:在基础安全防护之上,可通过web应用防火墙、SS
66、L证书、数据库审计、堡垒机等云上安全产品,对网络层和应用层以及数据库安全、运维安全等多方位安全能力进行加强,进一步构建云上系统的安全防护能力并满足相关合规需求。41 第四步:安全持续运营 安全规划和建设完毕后,还需要持续管理和持续运营,通过对日常的安全管理,形成相关制度,对人、系统、云上资源、安全产品等整体的管理、外包的管理、日常安全意识的灌输等等。同时,安全运营工作同步持续进行,包括资产管理、漏洞管理,应急响应等等。并针对业务特性在一些特定领域加强安全防护,包括加大数据安全的力度(如敏感数据保护、加密等)、建设身份认证中台来对整体的用户账号进行统一管理,以及业务安全建设(如内容安全、风控、实
67、人认证等),这样才能发挥云上系统安全能力的最大作用。云上身份与权限安全 身份管理 身份是指在云环境中执行操作的实体。云上主要有两种身份类型:人员身份和程序身份。人员身份通常代表组织中的个人,比如企业中的安全管理员、运维管理员、应用开发者。通常通过阿里云的控制台、CLI、特定场景下的客户端等方式对云上的资源进行操作。程序身份则代表应用程序或服务,往往是通过阿里云的 OpenAPI 来访问云上的资源和数据。在阿里云上,针对两种类型的身份管理,核心有两大原则:缩小暴露时长和缩小暴露面积。42 基于这两大核心原则,针对不同类型的身份管理,在阿里云上有以下最佳实践可以参考。人员身份 避免使用 Root
68、身份 在阿里云上,注册完一个阿里云账号后,即可通过用户名和密码的方式登录到阿里云控制台,登录成功后,即获得了 Root 身份。该身份具有该账号下所有的权限,一旦账号密码泄漏,风险极高。另外,如果多人共用该身份,每个人都保有该账号的用户名和密码,会增加泄漏的可能。同时,多人共享的情况下,在云上的操作日志中无法区分出是组织中哪个人使用了该身份进行了操作,也无法进行进一步溯源。因此,除了极个别场景,应该尽可能的使用阿里云 RAM(Resource Access Management,访问控制)身份进行云上资源的访问,避免使用阿里云账号的 Root 身份。对于 Root 身份的使用,参考下述“建立更安
69、全的登录机制”一节中的最佳实践,提升 Root 身份的安全性。实现人员身份的统一认证 通过集中化的身份提供商(Identity Provider,简称 IdP)来进行人员身份的统一认证,能够简化人员身份的管理,确保组织内在云上、云下的人员身份的一致性。当人员结构变更、人员入、离职时,能够在一个地方完成人员身份的配置。对于云环境的使用者来说,也无需为其颁发额外的用户名和密码(如 RAM 用户名和密码),只需要保管好其在组织内的 IdP 中的身份和凭据即可。对于一些组织而言,通过一些网络上的访问控制措施,使其 IdP 仅能够在企业内网访问,给人员身份的认证过程增加了额外一个限制条件,进一步保障了企
70、业人员身份的安全。阿里云支持基于 SAML 2.0 协议的单点登录(Single Sign On,简称 SSO)。在阿里云上,我们建议通过 RAM SSO 的方式跟组织内的 IdP 进行集成,实现人员身份的统一认证。对于云上有多个阿里云账号的复杂组织,还可以通过云 SSO 进行多账号下的 SSO 集中化配置,进一步实现多账号下的人员身份统一管理,提升管理效率。建立更安全的登录机制 1.对于人员身份的登录方式,往往是通过用户名和密码的方式进行。一旦用户名和密码泄漏,攻击者极有可能通过该身份登录阿里云,造成一些不可挽回的损失。因此,对于人员身份来说,保护好用户名和密码显得尤为重要。可以从以下几种方
71、式提升登录方式的安全性:43 2.提升密码强度。如增加密码位数、混合使用数字、大小写字母、特殊字符等。针对阿里云 RAM 用户,管理员可以设置密码强度规则,强制 RAM 用户使用更复杂的密码,降低密码泄漏和被破解的风险。3.避免密码混用。在不同的服务、站点,或不同的用户共用一个密码,增加了密码的暴露面积,会增加密码泄漏的可能性。如果其中一个服务或用户的密码泄漏,那攻击者就可以通过尝试登录的方式,找到共用密码的其他服务。因此,确保不同服务、不同用户使用不同的密码,能过降低密码泄漏的风险。4.定期轮转密码。密码存在的时间越长,泄漏风险越高。通过定期重设密码,降低单个密码存在的时长,能够进一步降低密
72、码泄漏风险。针对阿里云 RAM 用户,管理员可以在密码强度规则中设置密码有效期,来实现密码定期轮转。5.使用多因素验证。多因素认证 MFA(Multi Factor Authentication)是一种简单有效的安全实践,在用户名和密码之外再增加一层安全保护,用于登录阿里云或进行敏感操作时的二次身份验证,以此保护您的账号更安全。阿里云支持虚拟 MFA、U2F 安全密钥等多种二次验证方式。建议为云上的人员身份都启用二次验证。对于使用云下 IdP 进行统一身份认证的组织,也建议在 IdP 侧提供二次验证的选项。程序身份 不使用云账号 AccessKey 云账号 AccessKey 等同于阿里云账号
73、的 Root 权限,也就是该账号内的完全管理权限,而且无法进行条件限制(例如:访问来源IP地址、访问时间等),也无法缩小权限,一旦泄漏风险极大。对于程序访问的场景,请使用 RAM 用户的 AccessKey 来进行阿里云 API 的调用。避免共用 AccessKey 多个程序身份共用 AccessKey,或程序身份、人员身份共用 AccessKey 的情况下,AccessKey 所关联的权限需要包含所有身份的使用场景,导致权限扩大。另外,共用场景下,一处泄漏会导致所有应用都受到影响,风险扩大,同时增加了泄漏后的止血难度。对于同一个应用的不同环境,如生产环境、测试环境,往往需要访问不同的资源,同
74、时,测试环境代码往往不够稳定和健壮,更容易有泄漏风险,如果共用同一个 AccessKey,测试环境 AccessKey 泄漏后也极容易造成对生产环境的影响,导致业务安全风险。因此,针对不同应用、大型应用的不同模块、同一个应用(或模块)的不同环境(如生产环境、测试环境44 等),都建议创建不同的 AccessKey 供程序身份使用,每个 AccessKey 只有该场景下所需要的权限,避免共用 AccessKey 的情况。定期轮转 AccessKey 同人员身份的用户名密码一样,AccessKey 创建和使用时间越长,泄漏的风险越高。每隔一段时间,通过创建新的 AccessKey,替换掉应用在使用
75、的 AccessKey,并将旧 AccessKey 进行禁用和删除,实现 AccessKey 的定期轮转。另外,也可以通过阿里云密钥管理服务(Key Management Service,简称 KMS)的凭据管家功能,实现自动化的定期 AccessKey 轮转。除了 AccessKey,其余类型的程序访问凭据,都应该进行定期轮转,降低凭据泄漏风险。使用临时凭据代替固定凭据 通过给 RAM 用户或云账号的 Root 身份创建 AccessKey 供程序调用,都属于固定凭据类型。一旦创建出来,在删除之前,就是由固定的 AccessKey ID 和 AccessKey Secret 组成了该凭据。使
76、用固定凭据会造成很多风险,比如应用研发人员将固定 AccessKey 写入了代码中,并将其上传到了 Github 等公开仓库,造成了 AccessKey 泄漏,最终导致业务受损。在阿里云上,我们建议尽可能通过角色扮演的方式获取临时凭据 STS Token,代替固定 AccessKey 的使用。每个 STS Token 生成后,在超过角色最大会话时间(小时级)后,自动失效,从而降低了因固定凭据泄漏导致的风险。针对不同类型的云上应用部署方式,阿里云提供了相应的功能,集成了 STS Token 凭据的使用:1.针对在 ECS 实例上部署的应用,通过授予 ECS 实例 RAM 角色,将 RAM 角色跟
77、实例进行绑定,应用程序中即可通过实例元数据服务获取 STS Token。2.针对在 ACK 上部署的应用,通过开启 RRSA 功能,实现 RAM 角色和指定 ServiceAccount 进行绑定,在 Pod 维度即可扮演对应角色实现 STS Token 的获取。3.针对在函数计算中部署的 Serverless 应用,可以为对应函数所属服务绑定服务角色,实现 STS Token 的获取。无论哪种部署方式,在应用代码中通过阿里云官方提供的 SDK,根据部署类型设置相应的身份验证(Credentials)配置,都可以便捷的直接获取 STS Token,无需关心具体的凭据缓存以及过期更新逻辑。45
78、权限管理 云上的权限管理是为了控制某个身份在什么条件下对哪些资源能够执行哪些操作。阿里云上的授权方式分为以下几种:1.基于身份的授权:主要是指针对 RAM 用户、用户组或角色进行授权。2.基于资源的授权:部分云产品支持为某个特定资源绑定权限。如 OSS 的 Bucket Policy,支持向其他账号的 RAM 用户授予访问权限,以及向匿名用户授予带特定 IP 条件限制的访问权限。3.管控策略(Control Policy):管控策略是一种针对启用了资源目录(Resource Directory,简称 RD)的多账号组织,基于资源结构(资源夹或成员)的访问控制策略,可以统一管理资源目录各层级内资
79、源访问的权限边界,建立企业整体访问控制原则或局部专用原则。管控策略只定义权限边界,并不真正授予权限。4.会话策略(Session Policy):在角色扮演的过程中,可以指定一个会话策略,定义本次扮演中可以获得权限,进一步缩小角色权限的范围。同样,会话策略只限定权限,并不真正授予权限。无论基于何种授权方式,合理的权限设置能够阻止未经授权的访问,保护云上资产和数据的安全。因此,云上的权限管理的核心原则就是权限最小化,只给身份授予必要的权限,确保权限最小够用。基于该原则,针对不同身份类型的授权,在阿里云上有以下最佳实践可以参考。人员身份的权限管理 基于人员职能进行授权 对于组织来说,不同职责的人需
80、要访问云上不同类型的资源。安全管理员往往需要访问安全产品,如云安全中心、云防火墙等,但数据库管理员往往只需要访问数据库相关的产品,如云数据库 RDS 等。但对于同一职责,尤其是一些基础职能,如财务、数据库管理员、安全管理员、审计员等,所需要访问和管理的资源范围往往是一致的。因此,建议针对人员职能划分,进行权限的抽象,简化授权过程,降低管理成本。在对职能权限进行抽象后,可以通过将人员身份加入到指定职能用户组的方式进行组织,提升授权效率。按资源范围授权 虽然权限管理的核心原则是最小化授权,但如果为组织中的每个人员身份都定制化权限,对于大型组织来说,会大大降低管理效率。因此,按照人员所管理的业务应用
81、对应的资源范围进行授权,能够简化授权逻46 辑,提高权限策略复用率,进而在权限最小化和管理效率中取得平衡。在云上,建议通过阿里云账号或资源组两种方式,区分不同业务应用的资源。如果企业使用多个阿里云账号管理云资源,则可以使用资源目录构建企业组织结构,对账号和资源进行集中、有序地管理,不同的业务应用按账号维度进行区分,授权时应用范围选择整个云账号。如果企业使用一个阿里云账号管理所有云资源,各个项目组可以使用资源组作为资源隔离和权限管理的容器,在授权时应用范围选择指定资源组。因此,在用云过程中通过合理的资源规划,按照资源范围进行授权,能够提升整体的权限管理效率。程序身份的权限管理 精细化授权 除一些
82、特定业务场景外,应用程序所需要访问的阿里云资源,对应进行的操作是可以预期的,尽可能的通过自定义权限策略来定义该程序身份所需要的最小权限。比如一个用户社区需要展示用户头像,支持头像上传,那么该程序仅需要特定 OSS Bucket 的 GetObject 和 PutObject 权限即可。相反,如果直接使用系统策略,给该程序授予 AliyunOSSFullAccess 权限,那么一旦该程序身份泄漏,攻击者就有该云账号下所有 OSS Bucket 的所有权限,风险极高。通用的最佳实践 定期审查权限 在授权完成后,还需要定期对权限的授予进行审计确保每个身份的权限持续满足最小够用原则。需要重点关注的场景
83、:1.特权身份:比如拥有所有产品权限的管理员,拥有 RAM 等管理与治理相关产品所有权限的身份,都属于重点审计对象。确保这些身份拥有这些特权是合理的。2.闲置权限:除了特权身份外,对于其他产品权限,也可以结合云上的操作审计日志,判断该身份的权限是否有闲置情况。设置权限边界 对于云上有多个阿里云账号的组织,可以基于资源目录管控策略,限制成员账号内的 RAM 身份权限范围,禁用一些高危操作降低身份泄漏风险。如禁止成员删除域名或修改域名解析记录、禁止成员删除日志记录等。47 在绑定管控策略前,建议先进行局部小范围测试,确保策略的有效性与预期一致,然后再绑定到全部目标节点(资源夹、成员)。云上数据安全
84、 金融行业数据关系到国计民生,且与自然人、法人和非法人组织的合法权益以及国家安全和公共利益密切相关,是国家数据安全重点保护对象,因此金融行业是落实和实施数据保护的重点行业之一。下面是常见的金融行业与数据安全相关的法律法规 GB/T 31186-2014 银行客户基本信息描述规范 JR/T 0071 金融行业信息系统信息安全等级保护实施指引 JR/T 0149-2016 中国金融移动支付 支付标记化技术规范 JR/T 0171-2020 个人金融信息保护技术规范 JR/T 0068-2020 网上银行系统信息安全通用规范 参考JR/T 0171-2020 个人金融信息保护技术规范,整个金融行业,
85、包含银行、证券、保险、信托、信贷等等领域的常见数据类别分成业务数据、个人数据和公司数据三类,其中每个分类还有细化数据信息的子类。根据数据的重要性又分成了C1到C3三个等级,且分级分类基于7大核心原则:权责一致、目的明确、选择同意、最少够用、公开透明、确保安全、主体参与。48 整个金融行业中个人数据上云趋势逐渐变化,C1类个人数据慢慢过渡到C1和脱敏后的C2类非核心日常业务数据,直至过渡到最终的C2和C3类的核心业务数据。云上数据安全参考数据安全成熟度模型,提炼出在云上构建数据安全的基础能力,主要包括:数据分类分级 静态数据防护 动态数据防护 数据安全审计 49 防护重点1:数据分类分级 每个企
86、业都会有适用于其自身所在行业以及业务特点的标准和体系。分类分级标准的制定,并不应当只是纸面上的工作,而应该结合企业所在的行业和业务特点,有针对性的进行设计,并通过自动化的手段,辅以手工的方式,对海量的企业全域数据资产进行识别与分类,有效定位企业关键以及敏感类信息在企业数据资产中的分布和流转情况,并通过定级有针对性的进行保护。数据安全中心提供对数据源中保存的敏感数据的自动识别能力,对文件提供基于内容的敏感数据识别,且支持OCR(印刷文字识别)技术,对图片中保存的敏感信息进行提取和识别;同时内置深度神经网络和机器学习等先进技术,通过样本扫描、特征萃取、特征对比和文件聚类等算法,实现多达44种敏感数
87、据的精准识别。同时数据安全中心提供了敏感数据发现后的自动分类分级以及统计展示能力,通过对结构化和非结构化数据源的敏感数据识别,自动对敏感信息进行识别结果归类。防护重点2:静态数据防护 随着企业的数字化转型,数据会存储在各类云中提供的存储服务中。从最传统的块和文件类存储,到数据库、数据仓库类型的结构化存储,再到缓存、对象存储等新型存储方式,企业的数据会分布在各类应用系统和所使用的数据存储中。如何在数据存储的过程中保护数据的保密性、一致性和可用性,是数据安全在存储阶段的重点。其中对于数据的加密和脱敏,是企业最常见的保护手段。数据加密 加密服务通过在阿里云上使用经国家密码管理局检测认证的硬件密码机,
88、帮助客户满足数据安全方面的监管合规要求,保护云上业务数据的机密性。借助加密服务,用户可以进行安全的密钥管理,并使用多种加密算法来进行加密运算。密钥管理 密钥管理服务提供安全合规的密钥托管和密码服务,助您轻松使用密钥来加密保护敏感的数据资产,控制云上的分布式计算和存储环境。您可以追踪密钥的使用情况,配置密钥的自动轮转策略,以及利用托管密码机所具备的中国国家密码管理局或者FIPS认证资质,来满足您的监管合规需求。数据脱敏 50 数据安全中心通过多年的内部沉淀,为广大云上开发者提供了近30种数据匿名化和去标识化算法,无论是应用开发人员,还是数据安全管理者,都可以根据实际业务场景灵活选择,自定义参数,
89、做到个性化数据脱敏。数据安全中心提供了自定义脱敏模板能力,真正做到安全自适应。企业数据安全管理者可以通过自适应的脱敏解决方案,完成各类不同场景的数据脱敏分发,例如定期从生产环境向开发测试环境脱敏,不同数据类型(如OSS中的csv向RDS的数据表)之间的异构脱敏,数据库层面的原库/原表脱敏等等。防护重点3:动态数据防护 数据传输过程中使用的网络通道不同,保护方式也会不同。对于客户端通过互联网发起的访问,一般建议企业使用SSL/TLS证书来加密传输通道,防止发生中间人攻击窃取传输过程中的重要数据;对于企业站点间的数据传输,通常会使用VPN或专线对通信链路进行加固。阿里云通过提供VPN服务,帮助企业
90、构建端到端的数据加密通道,保障数据传输过程中的通信安全。同时阿里云还为用户访问网站提供了 SSL/TLS 协议来保护数据。阿里云证书服务可以在云上签发第三方知名 CA 证书颁发机构的 SSL 证书,实现网站 HTTPS 化,使网站可信,防劫持、防篡改、防监听,并对云上证书进行统一生命周期管理,简化证书部署,一键分发到其它阿里云的产品(包括 CDN、SCDN、DCDN 和 SLB 等)。防护重点4:数据安全审计 等保2.0针对数据安全提出了“安全审计”和“个人信息保护”的相关要求。随着数字化转型的深入发展,企业重要数据已经从传统单一的数据库存储扩大到各类数据存储、大数据和数据中台等,统一的数据安
91、全审计成为管理难题。数据安全中心可以实现对云上各类数据源的安全审计,并在此基础上深耕防泄漏场景,帮助客户实现全域数据的风险感知。利用机器学习技术,为数据的访问行为建立安全基线,在发生潜在数据风险,例如异常时间或地点访问时,及时预警并提供针对性的溯源能力和防护建议,化静态检测为动态感知,帮助客户快速应对突发的数据安全事件,提升整体响应能力。51 小结 针对云上资产访问和管理场景,建议金融企业遵从以下安全原则。网络隔离(纵深防御):通过云产品的安全隔离和访问控制功能,实现网络、系统、应用和数据不同维度的隔离以实现纵深防御。认证授权(最小权限):仅授权使用者必须的云账号和子账号权限,并开启双因素认证
92、措施和关键操作二次认证能力。安全加密(开启加密措施):通过传输加密和存储加密措施实现数据在云上全程加密。监控告警:通过日志和监控措施及时发现配置变动、异常登录和操作、数据泄露以及异常攻击等。52 6 金融企业上云容灾设计 容灾技术架构选型 从用户视角看,同城容灾、异地容灾、两地三中心、异地多活,都需要遵循一定的架构前提,需要统筹考虑业务容灾指标、防范的灾难类型、投入成本等。从机房选址、业务适配成本、数据同步技术、容灾切换等几个方面看,四种典型容灾架构的主要特征对比如下图所示:图:四种典型容灾架构的对比 综合上述分析,容灾架构的选型,是灾难恢复目标和建设成本的综合结果。容灾架构选型时的核心决策要
93、素 53 应用容灾设计维度 应用:梳理清楚影响业务连续性的风险点,确认应用系统的上下游及其内部的依赖关系。需要重点关注已经上云或即将上云的应用系统清单、应用系统分类及其容灾等级要求、明确本期的目标容灾系统、分析目标应用系统的完整上下游依赖关系。云平台:确认目标应用系统涉及的云产品清单及其容灾能力。云产品清单,包括了云产品名字和版本号信息。容灾能力,包括产品的容灾能力及限制条件。基础设施:确认目标应用系统涉及的网络流量路径。重点分析的角度可以从互联网流量和内网流量这两个角度开展。云上容灾方案设计 重点关注点如下:根据业务场景,划分对应应用系统的等级。例如银行的应用系统,通常会根据优先级由高到低,
94、划分为 S、A、B、C、D 几个等级。系统性梳理目标应用系统的核心功能和非核心功能。确定核心功能和非核心功能,预期要达到的容灾等级,对应关注的指标是 RTO 和 RPO。在技术和资源有限的情况下,区分核心功能和非核心功能的容灾等级,是非常必要的。根据应用系统的等级划分和使用场景的分类,一种通用的容灾等级分类映射关系如下:S 级和 A 级的应用系统,通常代表用户最核心的系统。除了本系统独立运行外,同时还是 B 级、C 级54 和 D 级应用系统所依赖的基础系统。依此类推,B 级的应用系统,也可能是 C 级和 D 级应用系统所依赖的基础系统。S级和A级的应用系统,对容灾等级要求最高,通常会规划同城
95、和异地两种容灾方式。其他等级,则会根据经济成本和技术复杂度,选择性采纳同城的容灾方式。图:应用等级及其容灾等级的映射关系 应用容灾设计原则 每一种方法论,都有其前提条件。应用容灾设计这个步骤的目的,是指导应用系统如何利用云计算平台的优势,来达到期望的容灾能力。应用容灾设计通用原则,如下:应用容灾设计通用原则 原则 减少风险数量 原则 降低故障概率 原则 缩小影响范围 原则 缩短恢复时长 少依赖 弱依赖 分散、平衡、隔离 可观察、可灰度、可回滚、冗余、自愈 55 分类、分层、应用解耦 开关、缓存、读写分离、分库分表、异步、多副本 虚拟化、容器化、网格化、负载均衡、限流、降级、CDN、网关 监控系
96、统、集群高可用、弹性伸缩、自动重试、回滚、重启 通过这四个基础原则和多个容灾项目的建设经验,本文从应用系统的视角,总结出应用容灾指引的最佳实践,分别是应用设计指引和应用部署指引,如下:应用设计指引与部署指引 原则 减少风险数量 原则 降 低 故障概率 原则 缩小影响范围 原则 缩短恢复时长 应用设计指引 应用无状态化设计 本 中 心调用优先 应用微服务化 支持幂等重试 弱 依 赖并及时缓存 增加开关,降低对下游系统的弱依赖 资源拆分,划分最小容灾单元 网 络 连接信息 存 配置中心 大 文 件 存 OSS API 注 册 到网关,使用网关进行限流和降级 自动有限次重试 实时业务和离线业务解耦
97、增 加 开关,控 制 多中心的定时任务 设 置 数据表接入层流量优 选 云 产56 的主键 读写分离 品,慎用开源产品 系统间通过接口交换数据,慎用跨系统直连写入数据库和存储。慎 用 数据库的大事务 兼容全局 ID 不连续 数据库读写分离 应用部署指引 保持应用的版本在多中心相同 冗 余 部署多台服务器 分配数据库的最小权限 对等资源部署应用在多中心 使用 SLB 提供对外服务 为每个应用分配逻辑隔离的云实例 慎用 host 绑定 设 置 服务器组 的 负载均衡 为每类客户端APP 分配独立的域名和端口 配置应用级监控 跨中心的域名解析至本中心的 IP 分 配 域名并关 联 至本中心的 IP
98、配 置 Nginx 动 态 解析域名 使用 CDN 加速服务 云上容灾参考架构 阿里云金融团体云支持通过同城+异地模式部署,同城容灾通过金融云同一个Region 2个或3个对等部署的57 可用区互为备份,当任一可用区出现异常时,应用系统和数据可以实时切换到备可用区,异地容灾是通过在应用部署的主Region相隔较远的异地Region,建立功能相同的系统,当主Region因意外(如火灾、洪水、地震、人为蓄意破坏等)停止工作时,整个应用系统可以切换到灾备Region,使得系统功能可以继续正常工作。容灾系统需要具备较为完善的数据保护与灾难恢复功能,保证生产中心不能正常工作时数据的完整性及业务的连续性,
99、并在最短时间内由灾备中心接替,恢复业务系统的正常运行,将损失降到最小。对于部分容灾等级要求5级以上的金融应用,可以采用经典的两地三中心部署架构,即同城容灾架构和异地容灾架构组合,同城的两个数据中心采取同步或异步的数据同步方式,同城和异地之间采取异步的数据同步方式。该架构既可以应对城市内单中心的灾难,又可以应对城市级的灾难。对于金融核心应用需要严格确保灾难情况下RPO=0,通过两地四中心容灾架构图实现,在同城Region主备容灾基础上增加第三个AZ,并且引入支持数据一致性协议的数据库服务,实现同城应用数据库RPO=0,应用系统通过域名访问部署在金融云各机房里的应用服务,金融应用系统使用高可用容灾
100、能力的云产品满足容灾要求,该方案对用户应用侵入少,金融云用户可以聚焦于业务开发,降低应用开发难度。阿里云提出金融级云原生理念和框架体系,指导金融机构在完整技术链路中结合金融级的高可用、高性能、业务连续性等特征全面落地云原生,金融机构可以使用多地多中心多活方案,将应用系统和数据库进行单元化拆分和部署,确保应用系统在AZ和Region级别故障下依然保持对外服务能力。金融机构在实现云上容灾架构设计和部署的同时,需要根据监管要求每年定期进行容灾演练用于验证容灾能力,实现真正的能切、敢切、常切。以下根据金融机构典型上云容灾实践提供部分参考架构。同城容灾参考架构 58 接入层 流量路径:应用请求通过域名解
101、析到达DMZ区,DMZ区先通过前置 SLB(CLB)分发流量到WAF、防火墙、应用负载均衡SLB及微服务MSE网关,然后到达应用ACK集群。在应用ACK集群中通过ASM的业务服务入口网关到达应用Pod容器。核心组件部署模式:SLB采用多可用区模式,MSE云原生网关采用多节点部署。应用层 应用无状态化:应用服务不做业务数据的本地存储(本地盘),容器集群(ACK)存储需要采用数据卷的存储方式。服务冗余部署:业务服务中应用容器的Replica值至少要为2。同城容灾部署:容器集群节点通过节点池进行管理,结合指定部署集,指定反亲合策略。59 存储层 存储组件PaaS产品化:出于成本、可靠性、弹性和韧性角
102、度的考虑,要求采用的存储产品均使用云平台提供的商业化产品或托管类开源产品,减少运维成本和潜在的稳定性风险。高可用产品规格:产品选型要求使用多可区的高可用规格。部分不支持多可区的产品(NAS,云盘),采用快照备份进行数据容灾。异地容灾参考架构 60 接入层 流量路径:应用请求通过域名解析到达DMZ区,DMZ区先通过前置 SLB(CLB)分发流量到WAF、防火墙、应用负载均衡SLB及微服务MSE网关,然后到达应用ACK集群。在应用ACK集群中通过ASM的业务服务入口网关到达应用Pod容器。流量管控:在流量入口侧,通过GTM挂载两个地域的SLB(如果没有引入GTM类产品,就需要通过直接调整DNS配置
103、来实现),日常情况下流量只导向主站点内网DMZ区入口SLB,容灾时调度到灾备站点内网DMZ区入口SLB。应用层 应用无状态化:应用服务不做业务数据的本地存储(本地盘),容器集群(ACK)存储需要采用数据卷的存储方式。服务冗余部署:业务服务中应用容器的Replica值至少要为2。异地容灾部署:热备模式:在异地灾备Region将所有相关服务进行对等部署,保证可以承载主站所有服务流量。冷备模式:建立容器集群等应用基础PaaS服务,应用冷备(通过容器镜像和云盘快照),日常不部署不启动。存储层 存储组件PaaS产品化:出于成本、可靠性、弹性和韧性角度的考虑,要求采用的存储产品均使用云平台提供的商业化产品
104、或托管类开源产品,减少运维成本和潜在的稳定性风险。高可用产品规格:产品选型要求使用多可区的高可用规格。部分不支持多可区的产品(NAS,云盘),采用快照备份进行数据容灾。数据备份与同步:RDS通过DTS产品建立起关系数据库的异地容灾备份 通过OceanBase跨Region主备库建立起关系数据库的异地容灾备份 通过Redis全球多活使异地实例通过同步通道保持实时数据同步 61 对象存储OSS通过跨区域复制功能来完成异地数据同步与容灾 ES通过应用层双写或基于xpackccr的数据同步方案 通过DTS产品建立起MongoDB的异地数据备份和同步 小结 业务连续性是金融上云用云的核心关切,人民银行为
105、此在云计算标准云计算技术金融应用规范中专门制定了JR/T 01682020 容灾标准,明确指出金融机构应根据业务连续性目标和业务发展规划,对云计算平台进行详细的风险分析,并定期执行演练。本章节参照对应的容灾标准,结合阿里云平台容灾能力以及在服务金融客户实践中的沉淀,提供了金融机构云上容灾方案设计参考。62 7 结束语 本解决方案白皮书聚焦在金融企业上云规划和云上IT治理领域,结合对金融企业上云的洞察和行业领先的 IT 治理框架给出了金融企业上云的观点与建议,同时结合阿里云产品服务能力给出了金融企业成功落地在阿里云的最佳实践与操作指南,帮助金融企业从组织、人员和技术层面着手采取行动,确保上云价值
106、最大化和风险最小化。受限于篇幅和形式,白皮书无法给出所有解决方案,最新 Landing Zone 解决方案请查 看 Landing Zone 官网。本解决方案白皮书是阿里云新金融事业部架构师团队、产品团队和全球交付团队服务众多金融企业上云的经验总结,因此特别感谢给予我们信任和帮助我们改进的客户。63 附录:参考文档 1 中国人民银行.JR/T 0166-2020 云计算技术金融应用规范 技术架构 2 中国人民银行.JR/T 0167-2020 云计算技术金融应用规范 安全技术要求 3 中国人民银行.JR/T 0168-2020 云计算技术金融应用规范 容灾 4 中国人民银行.金融科技发展规划(
107、2022-2025年)5 中国人民银行.R/T 0071-2012 金融行业信息系统信息安全等级保护实施指引 6 中国人民银行.JR/T 0044-2008 银行业信息系统灾难恢复管理规范 7 国务院.关于促进云计算创新发展培育信息产业新业态的意见 8 国务院.关于积极推进“互联网+”行动的指导意见 9 工信部.云计算综合标准化体系建设指南 10 国务院.基于云计算的电子政务公共平台安全规范 11 网信办联合四部委.云计算服务安全评估办法 12 保险行业协会.保险行业云计算场景和总体框架 13 银保监会.中国银保监会办公厅关于银行业保险业数字化转型的指导意见 14 证券行业协会.证券公司网络和信息安全三年提升计划(2023-2025)(征求意见稿)15 阿里云Landing Zone解决方案官网:https:/ 16 阿里云云采用框架官网:https:/ 64