云原生技术架构成熟度模型解读| 学习笔记

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
函数计算FC,每月15万CU 3个月
简介: 快速学习云原生技术架构成熟度模型解读

开发者学堂课程【云原生技术架构成熟度模型解读:云原生技术架构成熟度模型解读】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/6/detail/12


云原生技术架构成熟度模型解读

 

内容介绍:

一、学习前言

二、总体介绍

三、云原生技术架构成熟度

四、云原生业务应用成熟度

五、云原生架构安全成熟度

 

一、学习前言

接下来学习《信通院云原生能力成熟度》标准解读,以及在参与测评过程中得到的结果介绍。

今天的学习主要包含以下四部分内容:首先将介绍云原生成熟度相关的标准产生背景以及当前云原生发展的趋势,后面三部分是基于信通院的云原生能力成熟度标准,包括基础架构、业务应用和架构安全三个方面做详细解读和对测评结果的分析,这里面还包含友商参与得到的结果的对比。

 

二、总体介绍

1.云原生成熟度衡量标准产生背景

过去几年云原生技术得到了高速的发展,云原生技术能够给企业带来非常高的应用开发的效用提升。

(1)IDC 预测:

到2024年,由于采用了微服务、容器、动态编排和 DevOps 等技术,新增的生产级云原生应用在新增应用的占比将从2020年的10%增加到60%。到2024年,数字经济的发展将孕育出超过5亿个新应用服务,这与过去40年间出现的应用数量相当。到2025年,超过一半的中国500强企业将成为软件生产商,超过90%的应用程序为云原生应用程序。到2025年,2/3的企业将每天发布新版本软件产品

这都是云原生技术的发展能够给企业带来效用提升的非常直观的影响。

(2)在去年,信通院发布的中国云原生应用调查中,

如图:

image.png

可以看到,有接近半数的企业用户已经把容器技术应用于核心生产环境,容器技术推广效果非常好,并且相较2020年有大幅度的占比提升。在微服务领域,超八成用户已经采用或计划采用微服务架构进行应用开发,微服务已成为应用开发的架构优选。在 Serverless 领域,作为云原生领域的一个新兴的技术的引进方向,目前在核心业务使用 Serverless 的用户接近2成,已开始和计划使用 Serverless 技术的用户超过七成,市场潜力非常大。

(3)

①如图:

image.png

在这种情况下,大量的企业用户一方面认同云原生技术能够带来的价值提升,比如提升资源利用率、提升弹性伸缩效率、提升交互效率、提升系统运维效率等,并且从趋势上看,2021年对于这些价值的认同相较2020年得到了大幅提升,也就是说企业客户对云原生技术的认同感大幅度提升。但同时也能看到,企业用户对云原生技术选型的顾虑也是大幅提升的,这里主要包括大规模应用云原生技术时,对于安全性、可靠性、性能和业务连续性等方面的顾虑,同时对于高速发展的技术栈,带来的过度复杂,学习成本高的问题也是企业用户非常关注的点。所以,在和很多客户沟通的时候也可以看到,很多客户在面对云原生技术的时候通常处于一个比较纠结的状态:一方面既希望企业的 IT 架构可以享受技术发展的红利,享受云化带来的效率,提升成本降低。但同时也会对过于复杂的技术,对相关技术人员,对技术控制的不足可能带来的一系列问题有非常大的顾虑。

②如图

image.png

在这种情况下,大量的企业用户一方面认同云原生技术能够带来的价值提升,比如提升资源利用率、提升弹性伸缩效率、提升交互效率、提升系统运维效率等,并且从趋势上看,2021年对于这些价值的认同相较2020年得到了大幅提升,也就是说企业客户对云原生技术的认同感大幅度提升。但同时也能看到,企业用户对云原生技术选型的顾虑也是大幅提升的,这里主要包括大规模应用云原生技术时,对于安全性、可靠性、性能和业务连续性等方面的顾虑,同时对于高速发展的技术栈,带来的过度复杂,学习成本高的问题也是企业用户非常关注的点。所以,在和很多客户沟通的时候也可以看到,很多客户在面对云原生技术的时候通常处于一个比较纠结的状态:一方面既希望企业的 IT 架构可以享受技术发展的红利,享受云化带来的效率,提升成本降低。但同时也会对过于复杂的技术,对相关技术人员,对技术控制的不足可能带来的一系列问题有非常大的顾虑。

②如图:

image.png

这里简单把这些顾虑分成供给侧和需求侧两端来看。云原生已经是大势所趋,但是在企业用户执行层面确实存在诊断难、规划难和选型难等问题,站在技术供给的角度,因为云原生技术不像虚拟化等技术,已经发展的很完善,所以技术及发展以及产品发生的脉络是很难把握的,云原生技术经过了六年的高速发展,其中也是经历了很多技术路线的改变,在这个过程中用户对发展脉络是很难把握的,同时用户的需求是多变的,缺少主线,还有技术押宝的风险。在用户需求侧,整体的架构规划缺乏标准参照,当用户设计业务系统架构的时候,是没有权威的参照物说明如何去应用云原生技术;同时还有建设路径不清晰、技术路线庞杂难筛选、自身架构技术水平缺乏对比、现实需求和供应商能力不能精准对应等需求侧的困难。所以站在供给和需求两端来看,是缺少行业权威建设的云原生建设指南,能够给到企业客户在规划自身 IT 架构云原生化有一步一步演进的操作指南。这个指南需要解决用户侧实际问题为前提,并且以行业发展的趋势为指引来实现用户云原生化的快速和高效落地。

2.阿里云《云原生架构成熟度模型》

基于这些一系列的问题,阿里云的云原生团队对19年底和20年初推出了阿里云的《云原生架构白皮书》,它是把阿里巴巴在过去几年在云原生领域的建型和推进的经验进行了总结,并且在《云原生架构白皮书》中也提出了云原生架构的成熟度模型。

如图:

image.png

提出的成熟度模型主要包括服务化能力、弹性能力、无服务器化程度、可观测性、韧性能力和自动化能力这六个指标维度,并且每个维度给出了0到3分的发展阶段的评分。客户可以基于这些维度对于自身的 IT 架构系统进行一个比较详细的评分,并且基于总分能够整体定级,分为零级、基础级、发展级和成熟级。基于这样的云原生成熟度模型,有助于企业站在全局的视角看自身 IT 架构云原生化后成熟度的情况。

3.信通院《云原生能力成熟度标准》

(1)如图:

image.png

站在信通院的角度,从16年开始也开始做云原生相关的行标和 IT 数的制定,目前已经覆盖了如容器、微服务和 Serverless 等,是一个相对比较完整的云原生评估体系,但是可以看到,过去的行标是一个点状发布,并不能很好的站在整体视角去评估整个企业在落地过程中成熟度表现情况。在这种情况下,2020年初信通院和30多家企业一起共同制定了云原生能力成熟度的评估体系,这个体系发展到现阶段总共包含了三部分内容:技术架构的成熟度、业务应用的成熟度和架构安全的成熟度。在建立整个成熟度体系的过程中参考了之前由阿里云云原生应用平台团队推出的成熟度模型,并且这个标准还在发展中,目前在上一周进行了新一轮的开会讨论。第五部分是云原生中间件成熟度标准。

(2)信通院的云原生成熟度体系的核心目的,是为了联系供需双方,加固云原生的能力。

如图:

image.png 

可以看到,这里简称为 T、A、S 这样的三层结构。在 T 这块,也就是技术架构成熟度模型,它主要是面向供给侧,供给侧主要包含云原生技术服务商比如阿里云,或者面对大客户内部的企业 IT 部门。在需求侧,这里有业务应用成熟度,用 A 表示,需求侧主要是企业的业务线或者阿里云的业务型的企业客户。这里同时还有一个负责架构安全的成熟度评估模型,这个是供给侧和需求侧都需要参考的架构安全成熟度评估体系。这套体系建立好之后,就可以给企业客户带来以下价值:

第一是多维度把脉,能够准确定位企业云原生化改造阶段。第二是进行差异化分析,详细诊断企业当前云原生能力建设短板。第三是基于其他当前发展阶段,定制化的去做提升,明确输出企业未来能力改进方向和计划。

(3)如图:

image.png

再详细拆解,云原生成熟度这套体系可以包含一个体系、三个视角和五个特性。一个体系指之前提及的三角关系即业务服务云、技术架构云和架构安全云;三个视角指包含了业务应用的建设视角(着眼于业务应用拆分解耦,充分融合底层架构技术实现应用韧性,主要面向应用架构的合理性视角)、IT 基础平台视角也就是通过技术架构建设视角(着眼于服务全局的技术架构、技术路径和全景能力规划)和系统安全视角也就是安全能力建设视角(着眼于新形态技术架构下的端到端安全防护能力构建),基于这样三个视角,再通过五个特性去做特性雷达的详细阐述;五个特性主要包括弹性、自动化、可观测性、自愈和高可用,这五个特性是后续在制定相关的测试用例和评分标准时候主要参考的五个维度。

 

三、云原生技术架构成熟度

1.标准解读

接下来针对云原生成熟度中最重要的云原生技术架构成熟度进行学习

可以看到,云原生技术架构成熟度的第一部分是技术架构,涵盖了4个能力域、12个过程域、46个能力子项以及在最后进行测评时候有476个细分能力要求,通过这样的测评能够帮助用户对照定位技术架构水平,并根据自身业务需求结合模型高阶能力定制技术架构演进方向。

如图:

image.png

详细看这4个领域,从底往上可以看到,首先是偏向 AS 层的资源管理域,它包含了融合调度、存储、计算和网络环境相关的成熟度的帮助评估,往上是运维保障域,包含基础运维、高可用和可观测性,是保障域里面有核心要去做测试的三个过程域,再往上是研发测试域,对应的有研发支撑和测试支撑,再往上是应用服务域,主要包含应用编排部署、应用治理和应用中间件等三个过程域。

基于这样的四个能力域的详细定义,可以把最终的测试结果分为初始级、基础级、全面级、优秀级和卓越级五个成熟度等级。初始级指技术架构局部范围开始尝试云原生化应用,并取得初步效果,突出了容器化的特征。

基础级指技术架构在局部范围内进行深入的云原生化应用;取得良好效果,突出了有云原生平台建设的特征。全面级指技术架构在更大范圈内体系化的应用云原生技术,具备关键技术模块的相关能力,突出了体系化的特征,相当于在云原生技术在企业内部的落地。

优秀级指技术架构全面云原生化各技术模块已高度云原生化,架构的弹性、自动化和自愈能力已有全面提升,突出了规模化的特征。卓越级指技术架构已完成全面云原生化改造且个技术模块功能已相当完善,能够很好的支撑上层应用,突出了智能化的特征。

目前,技术架构的成熟度测评参与的企业很多,其中阿里云是第一个通过测评的企业,通过相关测评的还有腾讯和华为。

2.测评结果

如图:

image.png 

接下来把四个主要的能力域的测评情况进行叙述,由于包含了非常多的能力子项和过程域,这里将从每个能力域的一到两个标准,去感受不同成熟度对技术和产品的能力要求是什么。因为整体目前相关标准的最终定稿还没有发布,所以现在可以看到的标准是修订过的版本,它不一定是最终版,所以在这里只需要了解即可,具体以信通院发布的为准。

(1)资源管理域

如图:

image.png

首先是资源管理域,这里看弹性能力,从级别上看,有一到五级,提及到的所有评测是以一到五级做一个递进。在一级里面,作为资源管理域的弹性要求支持计算资源的扩缩容即可;在二级,二级在一级的基础上要达到虚拟机能达到规格的弹性能力;在第三级,在二级的基础上要达到支持集群的扩容效率的提升,比如实现把节点扩缩容的能力;在第四级,在三级的基础上需要支持容器的快速弹性,支持亚秒级的容器启动,并且支持函数计算等相关信息业务的扩容效率和启动时长,比如铅实例的分钟级扩容能力;在第五级,在四级的基础上需要达到支持亚秒级的大象容器弹性启动能力,支持容器的应用扩展效率提升,比如万实例的扩容能力。可以看到,每一级的提升都是相对比较明显的,在资源管理域里,如上图,可以看到能力测评结果,在计算环境、网络环境和存储环境三个主要领域中都得到了最高分,在融合调度这个领域达到了四级,但并不表示能力只在四级,这是因为最终在设计相关的测试用例时只给了四级,这个领域的测评主要参评的产品有容器服务、Serverless 容器服务、函数计算、Serverless 应用引擎、存储产品线、弹性产品和计算产品线等。

(2)运维保障域

如图:

image.png

第二个领域是运维保障域,这里看容灾备份。第一级要求支持简单的容灾设计,支持本地容备容灾能力,支持应用数据全量备份能力,以上是基础的容灾要求;第二级在一级基础上要求支持异地的容备容灾能力,支持应用数据增量备份能力,支持手动恢复容备能力;第三级在二级基础上需要达到支持同层综合容灾能力,支持同层综合应用数据和应用配置备份存储,支持同层综合应用数据恢复,按备份应用的配置拉起应用;第四级在三级的基础上,支持两地三中心的业务架构;第五级在四级的基础上支持异地多活容灾能力,支持异地综合的应用数据备份存储,支持异地综合的应用数据恢复和拉起。每一个能力的层级都是对容灾备份的相关能力提出了更加具体更加高阶的能力要求,所以在运维保障域里分为基础运维域、过程域、可观测过程域和高可用观测域,整体得到了五个五级,三个四级的测评结果,在这个领域测评中,主要涉及到的阿里云产品有应用实时监控服务 ARMS、Prometheus 监控、链路追踪、应用高可用服务、日志服务、混合云容灾服务和容器服务 ACK 等。

(3)研发测试域

如图:

image.png

第三个领域是研发测试域,现在讲解这个领域的具体要求,以代码资产管理这个能力项为例。

第一级支持集中式的代码管理,这个是现在企业基本上都能达到的;第二级在一级基础上支持采用 Get 方式管理源代码,代码资产具备每日备份机制;第三级在二级基础上需要达到支持以工具方式对应用过程中的文档进行统一管理,支持以自评库方式对研发中产生的自评包括 war 包、镜像等镜像进行统一管理,支持使用经过验证的线上 SAS 化工具进行能力补充,比如产品定义相关;第四级在三级基础上要达到支持统一账号登录前工具和系统对账簿支持的如线上 SAS ,其账号由公司而不是个人管理,公司采用统一一致的研发相关数字资产管理体系,不存在私建 Get 库或采用未受监管的系统管理研发过程中数字资产管理体系,对内部研发人员,外部服务人员的账号可以实施不同的管理和权限策略;第五级在四级基础上需要增加支持各代码管理系统间的联动与关联分析,支持基于研发产生的数字资产进行质量分析如代码扫描,支持基于研发产生数字资产进行效能分析如效能探达。在研发测试域里主要包含了研发和测试两个过程域,目前可以得到测试结果,研发支撑域里获得了一个四级,七个五级;测试支撑域里获得了五个四级,两个五级。这个领域参评的主要产品有云效、云端开发 DevStidio、性能测试、先知(安全众测)、渗透测试、API 网关、Alibaba Cloud Toolkit 和移动测试。

(4)应用服务域

如图:

image.png

最后一个领域是应用服务域,这里以服务化这个能力项为例讲解应用服务域的能力要求。第一级是零散的使用服务治理相关产品,不具备产品化能力,无法实现快速复制到另外一个项目上,无统一的系统计算方案;第二级在一级基础上,要求已初步具备产品化能力,需要实现快速复制到另外一个项目上,有统一的服务治理平面,在一个平台上可以完成各服务治理能力的配置,有统一的系统计算方案如认证机制,接口设计等;第三级在二级基础上需要支持微服务治理平台,自身使用微服务架构构建可为虚拟机容器服务网格等提供服务治理服务,各组件均可支持多实例同时提供服务;第四级在三级基础上需要增加可支持大规模微服务系统治理,提供完善的系统接口和安全的访问机制,向外提供丰富的服务治理服务,拥有高可用设计和容灾架构,能够达到要求;第五级在四级基础上增加服务治理组件,均可实现在线更新,提供多中心,多活,单元化等高可用的架构支持,同时纳入大量不同种类的应用集群。在应用服务域中参与测评的主要产品包括 MSE、ASM、ADP、容器服务 ACK、EDAS 和 SAE 等。在最终测试结果中,在应用中间件的过程域中得到了两个四级,两个五级的评价,在应用治理获得了三个四级,两个五级的评测结果,在应用编排领域获得了两个五级的测评结果。

(5)小结

如图:

image.png

基于这样四个领域的分别的测试结果,可以看到,信通院推出这样的技术架构成熟度体系之后,阿里云是首批也是首家通过所有的四个云原生能力域,12个过程域、46个能力子项、476个细分能力要求的厂商。也覆盖了内部数十条业务线,50多款云原生产品,全方位的考察了阿里云云原生产品的服务丰富度,同时技术人员对信通院的测评人员对于整个测试过程的要求是非常细致的,最终产生了将近400页的测评报告,对每一个能力子项都有非常详细的测评过程,数据的记录,充分的表明了整个测评的可靠性,阿里云最终得到的云原生成熟度等级是四级,并且在四个指领域得到了 L4+ 的结果。由于成熟度的标准主要是面向于未来发展的,所以说在测评过程中已经和信通院达成了一致的态度,也就是说在首批测评过程中不会产生五级要求,因为这对未来的方向不具备指导性,所以在一开始最高级就是四级。

3.友商对比

image.png

同时也可以看一下友商的测评情况,在云原生技术架构成熟度的首批测评用户里,最值得关注的是华为和腾讯两家友商,目前阿里云得到的结果是四个 L4+ ,华为的结果是三个 L4+ 和一个 L4,腾讯只完成了三个过程域,三个能力域的测评,具体原因不清楚,得到的结果是两个 L4+ 和一个 L4,以上是技术架构相关的情况。

 

四、云原生业务应用成熟度

下面简单介绍一下云原生业务应用成熟度相关的内容。

1.标准解读

因为业务应用成熟度主要面向的是业务系统平台的一个构建能力建设的评测,所以在这个过程中,阿里云作为云服务提供方是不参与这个测评的,这里只对其简单介绍。

作为 TAS 模型中的重要部分,它覆盖3个能力域,15个过程域,能够全方位诊断云原生业务应用综合成熟度水平,并结合弹性、高可用、自愈、可观测性和自动化等五大云原生应用特性成熟度,从业务应用视角为项目团队指引能力提升方向,更好地匹配业务应用发展需求。

在这里也是设计了五个级别,

如图:

image.png

 

首先看初始级,它的业务架构是完全没有做云化的,并且完全基于单体应用架构;往上是基础级,它具备架构级的弹性,基于分布式应用架构,应用服务具备有限的弹性和容灾能力;第三级是全面级,应用架构服务化改造开始,应用具备一定的弹性和高可用,实现多维度的应用监控;再往上是优秀级,应用架构服务化基本完成,充分享受云原生生态,应用具备弹性、高可用,基本实现服务自愈,可观测性以及自动化;应用架构再往上是卓越级,应用架构持续演进,应用全面实现弹性、高可用、服务自愈、可观测性以及自动化和智能化交付。可以看到,经过这样五级评测,能够一级一级的把企业用户的应用成熟度做一个评价。

 

五、云原生架构安全成熟度

下面介绍云原生架构安全成熟度模型的相关内容。

讲解分为:云原生安全性挑战、云原生在国内外的发展趋势、信通院在云原生标准化安全工作的演进、模型在五大域的细分解读,阿里云的测评结果、友商对比

1.标准解读

(1)云原生安全挑战和发展趋势

随着云原生技术架构的演进成熟,在企业应用进行云原生改造化的同时,安全问题也随之出现,基于传统的基于边界和信任域的安全架构已经不适合云原生环境,同时应用测容也为架构带来了更多的攻击面,敏捷,弹性等云原生特征对传统安全技术也带来了新的挑战。为此无论是应用商家还是用户都迫切需要构建自身的云原生架构安全防护体系。

在国内,信通院是最早关注也是最早投入云原生安全调研的权威研究机构,如图,在信通院今年对于云原生用户调查报告显示:

image.png

大部分的企业用户已经认识到云原生安全能力建设的重要性,安全性尤其是容器服务和微服务相关安全问题也连续两年成为客户最关心的问题。

在海外,以云原生安全为背景的安全防护实践已经经过了一段时间的积累,可以看到,除了政府层面的标准发布以外,企业在云上的安全预算也在不断增加,如图:

image.png

据 Paloalto 今年的云原生安全报告显示,今年企业在安全预算的投入占比会超过企业在整个云原生预算的20%。在企业对于云原生安全迫切需求的前提下,出现了以云原生安全为背景的开源项目,可以看到,CNCF 社区也出现了很多相关的开源项目。

在业界已经有了一定的知名度,另外今年 CNCF 也会发布《云原生安全白皮书》,

通过上面对云原生安全挑战和趋势的分析,可以明白在国内需要一个权威机构定制专业化的安全标准帮助指导和规范云服务商和企业客户构建云原生环境下全方位,端到端的安全防护体系。

(2)下面介绍这次云原生安全标准化工作的历史演进

如图:

image.png

 

在19年基于容器平台的安全能力立项,阿里云就是首批参与标准定制并且首批通过测评的服务商;20年十月,信通院主办的云原生产业大会上,阿里云、华为、腾讯以及一些主要容器安全厂商作为首批成员成立了云原生安全工作组;从20年4月开始,信通院联合业界20多家单位的近40名专家历时一年完成了国内首个云原生安全成熟度模型标准的编纂,为企业云原生安全能力建设提供了自检标准和建设指南;同年信通院联合18家企业发布了《云原生架构安全白皮书》,其中阿里云也是全程参与了白皮书的研讨和定制流程。

(3)如图:

image.png

下面了解此次云原生架构安全能力成熟度的评估模型。首先在分级的评估方法上,和技术架构成熟度类似,分为五级,分级是为了做到差异化的分析以及多维度把脉的要求。其中卓越级的标准是 L5 的标准,也是力求为云服务商在云原生安全能力建设的后续提出明确的指导方向,而优秀级标准也就是 L4 标准,包含了当前各服务商具备的相当优秀的一些产品安全能力来帮助云服务商在整个测评过程中通过差异化的比较来发现自身不足。

整个体系涵盖了五大能力域,包括基础设施安全、基础架构安全、应用安全、研发运营安全以及安全运维五大能力域,15个能力子项,46个实践项和近400个细分能力要求,本次阿里云也参与了五大能力域的所有细分子项的评测。

(4)如图:

image.png

以上是五大能力域下各个子项的细分实践项的展示。可以看到,图中涵盖了很多云原生安全相关的产品化能力,投入本次评测的阿里云服务也非常多,包括容器服务、镜像服务、云原生中心、外部应用防火墙等20款云原生产品,全方位的考察了阿里云在云原生安全能力上的丰富度,另外本次考察的力度也是非常细致的,除了信通院工程师严格实行标准的验证以及细致的考核外,所有的测试项均基于阿里云的生产环境完成,最终的评测报告也是达到了将近400页。

(5)下面进行五大能力域细分的解读

①首先是基础设施安全域,阿里云在计算存储网络等云基础上构建了非常坚实的平台底座安全的能力。在计算安全方向,云原生安全中心和容器镜像服务来支持漏洞的安全检测、告警、溯源以及分析,同时也支持镜像的漏洞的自动智能修复能力,同时还支持将 DDOS 等进行镜像扫描以及丰富的配置能力;在网络安全方向,云防火墙支持多重的边界防护以及基于流浪学习结果的自适应的智能策略推荐下发的能力;在存储安全方向,容器服务的备份中心可以支持应用数据的 ED 备份以及快速恢复,而 ACK  war 也提供了多元可供应场景下的两地三中心的备份容灾能力,同时 ACK 还支持基于软硬一体的 GB 计算技术来帮助实现内存维度的信息保护。

②如图:

image.png

接下来是云原生基础架构安全域的讲解,首先在云原生网络侧,容器服务和云原生安全中心提供了 POD 维度这种东西向的控制以及智能阻断的能力,同时还支持这种集群网络拓扑这种可视化的展示,LAS 网络服务也提供了 Serverless 框架下的全链路的流量加密、观测、监控以及七层的防控能力;在编排和组建安全方向,ACK 容器服务可以支持多维度的自动化的安全巡检的能力,帮助发现集群应用潜在的风险,并提供加固的建议,使用托管的机制还可以实现集群节点 CUE 的自愈化修复能力,同时在访问控制上,ACK 集群的 RSA 功能还可以支持集群应用侧 POD的云上任务,资源的权限隔离;在整个镜像安全方向,ACR 容器镜像访问企业版提供了云原生的交付链,功能,可以结合镜像完整进行校验等产品化能力,构建企业级的供应链能力;在运时安全方向,云原生安全中心可以支持容器维度的 run time 的实时检测、告警以及智能处理来帮助企业抵御敏感文件操作,异常连接等多种容器内的攻击行为。

③如图:

image.png

接下来是云原生应用安全域的讲解。

云原生应用安全也包括应用侧防护的方方面面。可以使用云防火墙和外部应用防火墙等服务来实现企业应用南北向以及东西向的攻击防护和细密的防护控制,同时也支持 API 漏洞,包括攻击和敏感数据泄露的检测和分析,以及自动修复的建议。同时企业应用还可以接入 AMS 服务来实现 API 维度的调用链监控以及 API 服务资产管理。在微服务安全方向,MSE 服务引擎可以通过云原生网关结合云防火墙等服务来保持微服务网络通信的安全。在提供丰富的微服务治理能力的同时,也提供了安全监控以及应用代码层的防护能力。在 Severless 安全方向,函数计算服务支持存储网络等函数资源的这种防护控制和租户隔离,同时还支持函数资源流量的实时监控以及完备审计

④如图:

image.png

 

最后看云原生研发运营安全域和安全运维域的情况。首先是研发运营域,阿里云安全团队对平台内部的研发运营流程有严格的安全审计和管理,包括对云产品的定制化的需求管理以及对制品安全的自动化扫描进行校验和身份溯源,在安全设计上,也支持系统化的微型建模以及内部标准化的安全设计规范的基础战略。在测试安全方向,内部也有完善 DE流程来实现无需人工干预的风险识别与运营。

云原生应用如何提供安全运维也是企业关心的重点问题,在安全管理方向,容器服务和云原生安全中心服务都支持丰富的云原生可视化资产管理的能力,同时基于日志服务也提供了管控侧和业务侧的完备的实名日志,并且支持基于审计的智能分析,告警以及图表化的展示能力。在策略管理上,容器服务支持基于 OPA 的集群部署时刻的策略制定引擎,同时云效服也针对云原生开发测试领域提供了基于云原生策略的流程配置以及相应的安全检测功能,在安全运营方向,云原生安全中心支持以密挂诱导来捕获攻击者并且实现自定义的攻击反制,同时支持多维度可视化的检测预警以及溯源分析能力,另外自身的阿里云危险警报平台也可以通过多种驱道来进行漏洞情报的获取,来帮助企业安全运维团队提高整体的运营管理效率。

2.测评结果和友商对比

最后请看测评结果,如图:

image.png

阿里云在本次标准的五个域的测评中都取得了国内唯一的全域最高等级认证,右边的表格也展示了首批通过本次云原生安全成熟度标准的企业,关于本次测评的完整的测试用例以及检测报告会上传到内部资料库中,可以自行下载。以上就是对本次测评的解读。

相关实践学习
巧用云服务器ECS制作节日贺卡
本场景带您体验如何在一台CentOS 7操作系统的ECS实例上,通过搭建web服务器,上传源码到web容器,制作节日贺卡网页。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
8天前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
2天前
|
Kubernetes Cloud Native 云计算
云原生技术深度解析:重塑企业IT架构的未来####
本文深入探讨了云原生技术的核心理念、关键技术组件及其对企业IT架构转型的深远影响。通过剖析Kubernetes、微服务、容器化等核心技术,本文揭示了云原生如何提升应用的灵活性、可扩展性和可维护性,助力企业在数字化转型中保持领先地位。 ####
|
2天前
|
运维 Cloud Native Devops
云原生架构:重塑企业IT的未来####
随着数字化转型浪潮的汹涌,云原生架构凭借其高度灵活、可扩展和高效的特性,正逐步成为企业IT系统的核心。本文将深入探讨云原生架构的核心要素、技术优势以及如何引领企业实现业务创新与敏捷交付。 ####
|
3天前
|
运维 Kubernetes Cloud Native
Kubernetes云原生架构深度解析与实践指南####
本文深入探讨了Kubernetes作为领先的云原生应用编排平台,其设计理念、核心组件及高级特性。通过剖析Kubernetes的工作原理,结合具体案例分析,为读者呈现如何在实际项目中高效部署、管理和扩展容器化应用的策略与技巧。文章还涵盖了服务发现、负载均衡、配置管理、自动化伸缩等关键议题,旨在帮助开发者和运维人员掌握利用Kubernetes构建健壮、可伸缩的云原生生态系统的能力。 ####
|
9天前
|
Kubernetes Cloud Native API
云原生架构下微服务治理的深度探索与实践####
本文旨在深入剖析云原生环境下微服务治理的核心要素与最佳实践,通过实际案例分析,揭示高效、稳定的微服务架构设计原则及实施策略。在快速迭代的云计算领域,微服务架构以其高度解耦、灵活扩展的特性成为众多企业的首选。然而,伴随而来的服务间通信、故障隔离、配置管理等挑战亦不容忽视。本研究聚焦于云原生技术栈如何赋能微服务治理,涵盖容器编排(如Kubernetes)、服务网格(如Istio/Envoy)、API网关、分布式追踪系统等关键技术组件的应用与优化,为读者提供一套系统性的解决方案框架,助力企业在云端构建更加健壮、可维护的服务生态。 ####
|
10天前
|
监控 安全 Cloud Native
云原生安全:Istio在微服务架构中的安全策略与实践
【10月更文挑战第26天】随着云计算的发展,云原生架构成为企业数字化转型的关键。微服务作为其核心组件,虽具备灵活性和可扩展性,但也带来安全挑战。Istio作为开源服务网格,通过双向TLS加密、细粒度访问控制和强大的审计监控功能,有效保障微服务间的通信安全,成为云原生安全的重要工具。
29 2
|
10天前
|
弹性计算 监控 Cloud Native
云原生架构下的性能优化实践与策略####
在数字化转型加速的今天,云原生技术以其弹性、敏捷和高效的特点成为企业IT架构转型的首选。本文深入探讨了云原生架构的核心理念,通过具体案例分析,揭示了性能优化的关键路径与策略,为开发者和企业提供了可操作的实践指南。 ####
|
13天前
|
监控 Cloud Native 测试技术
云原生架构下的性能优化与实践####
【10月更文挑战第21天】 本文深入探讨了在云原生环境下,如何通过一系列技术手段和最佳实践来提升应用性能。文章首先概述了云原生架构的基本原则与优势,随后详细分析了影响性能的关键因素,包括容器编排、微服务设计、持续集成/持续部署(CI/CD)流程以及监控与日志管理。针对这些因素,文中不仅介绍了具体的优化策略,如资源请求与限制的合理配置、服务间通信的高效实现、自动化测试与部署的优化,还结合案例分析,展示了如何在实际项目中有效实施这些策略以显著提升系统响应速度和处理能力。此外,文章还强调了性能测试的重要性,并提供了几种常用的性能测试工具和方法。最后,总结了云原生性能优化的未来趋势,为开发者和架构师
15 2
|
3天前
|
Cloud Native API 云计算
云原生架构的深度探索与实践####
本文深入探讨了云原生架构的核心概念、技术特点及其在现代软件开发中的应用实践。通过分析云原生架构如何促进企业数字化转型,提升业务敏捷性与可扩展性,本文旨在为读者提供一个全面而深入的理解框架。我们将从云原生的定义出发,逐步深入到其关键技术组件、最佳实践案例及面临的挑战与解决方案,为开发者和企业决策者提供宝贵的参考与启示。 ####
|
9天前
|
缓存 资源调度 Cloud Native
云原生架构下的性能优化实践与策略####
【10月更文挑战第26天】 本文深入探讨了云原生环境下性能优化的核心原则与实战技巧,旨在为开发者和企业提供一套系统性的方法,以应对日益复杂的微服务架构挑战。通过剖析真实案例,揭示在动态扩展、资源管理、以及服务间通信等方面的常见瓶颈,并提出针对性的优化策略,助力企业在云端环境中实现更高效、更稳定的应用部署。 ####
20 0

热门文章

最新文章

下一篇
无影云桌面