云计算 – 沃通CA官网 https://wd.wosign.com Tue, 30 Jan 2024 08:10:21 +0000 zh-CN hourly 1 https://wordpress.org/?v=6.5.2 云原生应用保护平台 (CNAPP):落地云原生安全的核心抓手 /article/zixun/1881.html /article/zixun/1881.html#respond Tue, 30 Jan 2024 08:10:21 +0000 /?p=1881 随着云原生正式开启云计算的下半场,云原生安全也将是未来几年云安全的主要发展方向。

随着云原生技术在国内外的广泛应用,企业数字化转型的进程也不断加快,但安全维度能力缺失明显。一是现有合规要求无法全面覆盖云原生场景,二是现有安全防护手段无法有效针对云原生架构进行安全防护。于是DevSecOps以及安全左移相关的理念相继提出,狭义的理解是要在开发阶段引入必备的安全能力,广义的理解和三同步相呼应。具体到云原生场景,就是要在云原生应用的规划阶段就做好安全设计,并要求云原生安全的整体方案能够覆盖到运营阶段。

基于此,云原生应用保护平台(CNAPP)呼之欲出。

什么是云原生应用保护平台(CNAPP)?

2020年Gartner 发布了云原生应用保护平台创新洞察报告,使CNAPP成为时下流行的安全语。然而,CNAPP 不仅仅是一种炒作的新安全工具。CNAPP 是一个平台,旨在为具有云原生工作负载的现代企业用单一的整体安全解决方案替换多个独立工具。Gartner定义了CNAPP:云原生应用程序的最佳安全体系、需要一种集成性的平台,这种平台从开发阶段开始,延伸到运行时保护。企业管理者应该评估新兴的云原生应用保护平台,这些平台为云原生应用的安全提供了一个全生命周期的防护。

Gartner定义的CNAPP强调企业需要专注于云原生安全解决方案,这些解决方案提供完整的生命周期方法来实现应用程序安全,而不是简单的拼凑安全工具。随着云原生技术在国内的快速和大量普及,2022年信通院牵头发起了CNAPP标准框架的定义和能力要求,包括制品安全、基础设施安全和运行时安全三大能力域,覆盖云原生应用研发运营全生命周期,同时兼顾平台的双向反馈和环境适配能力,共计 15 个功能模块,包含 500+能力项,全面详细地评估了云原生应用的安全防护能力。总之,CNAPP不是一个单一的工具,它是以应用为中心,覆盖云原生整体技术架构和云原生应用全生命周期的整体安全解决方案。

为什么需要CNAPP?

为了解决云原生应用的基础设施和全生命周期过程中的风险,出现了CWPP、CSPM等云原生安全工具或者产品,但是这些工具或者产品只是为了解决单一的安全问题,也只聚焦在生命周期的某个阶段。DevOps改变了传统应用的开发模式,将开发和运维过程连接起来,保持云原生应用从开发到运维的一致性,并强调可观测性,如果安全的运营流程不能打通应用开发到运维的过程,会导致没有办法观察应用全生命周期安全风险,也没有办法制定覆盖从开发和运行时的一致安全策略,给云原生应用的安全运营过程造成巨大困扰。

这些困扰包括:

第一,在云原生供应链安全管理场景中,如果只在开发阶段关注供应链安全问题不能解决云原生应用全生命周期供应链安全问题,例如代码违规提交,镜像违规分发和部署导致供应链监控盲点,我们怎么发现和监控到这些问题?另外在日常漏洞运营过程中,如果通过威胁情报等渠道发现新的供应链安全漏洞后,我们应该怎么快速评估和定位哪些业务或者应用正在受影响?

第二,在云原生安全风险评估场景中,我们通过各种安全工具或者平台发现了大量安全漏洞后,怎么评估哪些漏洞应该被高优先级修复?漏洞修复前还有业务在开发、在部署、在上线怎么办?另外怎么评估漏洞是在生命周期哪个阶段哪个时间引入的,以及谁引入的?还有没有其它应用正在受影响?应该采取哪些措施防止风险进一步漫延或者缓解风险?

第三,在云原生安全治理场景中,我们怎么评估企业里面哪些应用风险最高?哪个业务部门风险最多?哪个容器镜像的风险影响面最大?另外在云原生应用开发流程里面哪个阶段引入或者发现的风险最多?我们应该优先改进哪个流程?从上面这些问题可以看出,多个、脱节的解决方案在可见性和集成复杂性方面天然地存在隔阂和间隙。这意味着 DevSecOps 团队需要做更多的工作,并降低跨企业工作负载的可观察性。而通过使用 CNAPP,企业可以解决这些问题并改善其整体安全状况。

如何实现CNAPP?

奇安信研究了国内外CNAPP各种安全框架,包括Gartner云原生安全技术体系和CNAPP平台定义,以及国内信通院CNAPP能力要求,并结合奇安信内生安全理念,设计了适合国内云原生安全场景的CNAPP安全框架,如下图所示。

不难看出,整个框架以应用为中心,安全能力覆盖整个云原生架构以及云原生应用的全生命周期。其中纵向从下到上覆盖云原生应用运行的基础设施,包括IaaS平台、PaaS平台、主机及容器工作负载以及应用自身对应的微服务,横向从左到右覆盖云原生应用的整个生命周期,包括开发、部署和运行时。

值得注意的是,CNAPP平台作为提供云原生安全防护与运营能力平台,自身不需要具体实现从基础设施层到应用层的各种安全能力,而是通过对接这些能力来实现云原生全生命周期安全运营的效果,包括数据采集和分析,策略下发和告警响应处置等。

但CNAPP平台应包含四个核心能力模块,我们认为分别是资产管理、配置管理、风险评估和安全态势。企业依托平台的这些功能模块,可以实现云原生应用全生命周期安全运营。

首先是云原生资产管理。

CNAPP的资产管理模块包含云原生资产定义、云原生资产采集和云原生资产关联三个过程。其中云原生资产的定义非常关键,传统环境或者云环境的资产定义比较简单,一般是以工作负载的IP为主,结合其它业务属性进行定义,并把资产等数据保存在CMDB等系统中。但是云原生技术出现后,因为容器IP的不固定,这种单纯以IP定义并管理资产的方式不再适用,同时传统环境或者云环境一般只关注应用运行时资产,没有覆盖应用的开发和部署阶段。

因此在云原生场景下,资产需要被重新定义,需要以应用为中心并覆盖应用的全生命周期。

云原生应用在生命周期各个阶段的资产形态不一样,需要把它们都定义出来,包括代码、镜像、集群、nodes、namespace、service、pods、进程和端口等。云原生资产定义好后,就需要进行云原生资产的采集,需要从云原生应用生命周期的各个阶段进行采集,包括代码仓库、镜像仓库、k8s集群和运行时容器等。最后资产采集回来以后,需要围绕应用将生命周期各个阶段的不同资产进行关联,为后面安全能力的关联、风险关联和态势分析打下基础。

其次是云原生配置风险管理。

在业务向云原生技术架构转型过程中,云平台的配置风险和云原生平台的配置风险是最容易被忽略的,一方面是因为用户对云产品或者云服务的配置不熟悉,容易配错,另外一方面也缺乏一些工具方便用户进行配置检查和问题修复。

CNAPP的配置管理模块用于解决云原生应用整个运行环境的配置安全,包括云平台、容器编排平台、主机以及容器等工作负载,它通过从CSPM、KSPM以及CWPP产品中采集配置数据并进行集中分析,按照优先级给出配置风险和修复建议,并且在应用整个生命周期中持续进行监控,保证应用全生命周期配置安全。

第三是云原生风险评估。

在日常安全运营过程中,漏洞的修复和告警处置是最重要的工作之一,但是面对大量漏洞和海量告警时,漏洞修复和告警处置的优先级就成为一个问题。

CNAPP的风险评估模块通过多源数据汇总计算、叠加网络暴露面计算并结合资产重要性等业务属性对资产的风险进行整体评估,给出漏洞修复和告警处置的优先级。其中多源数据汇总计算除了结合云原生应用的漏洞、基线和弱口令等脆弱性数据,还结合了应用的流量以及告警威胁数据,进行实时动态计算。叠加网络暴露面计算是指会根据云原生资产的网络拓扑以及流量数据,计算云原生应用的南北向和东西向暴露面。最后根据资产的标签或者分类属性,结合资产的重要性等业务属性进行综合风险评估。

第四是云原生安全态势。

CNAPP的安全态势模块用于辅助企业从宏观角度了解企业所有业务的整体风险情况。其中面向业务的态势分析,包括可视化展现应用态势、镜像态势和租户态势,指导需要重点改进的业务部门以及应用,而面向DevOps流程的态势分析,包括可视化展现开发态势、部署态势和运行时态势,指导需要重点改进的流水线阶段。

结语

云原生时代,需要建设以云原生应用保护为核心的CNAPP平台,为云原生应用提供全生命周期的安全防护及可视化,同时具备云原生应用的风险评估和全流程管理能力,为云原生应用提供事前安全预警分析、事中攻击威胁实时检测、事后响应处置的云原生安全运营闭环,全方位保护云原生应用全生命周期安全并满足监管合规要求。奇安信通过打造一系列全部云原生化的研发平台,支撑安全产品和安全服务的云原生化,为客户业务云原生转型提供全套完整的云原生安全解决方案。

奇安信CNAPP能力基于云原生化的大禹平台,覆盖各种公有云、私有云、混合云以及云原生环境,通过定义标准的资产、漏洞、基线、日志和告警等LDM模型,支持海量数据的采集、分析和存储,为客户业务数字化转型提供一体化的全生命周期安全解决方案。

随着云原生正式开启云计算的下半场,云原生安全也将是未来几年云安全的主要发展方向。CNAPP作为云原生安全的整体解决方案,也将值得更多企业进行深入探索和实践。

关于作者

鲍坤夫 奇安信云安全研发总监

声明:本文来自虎符智库,版权归作者所有。文章内容仅代表作者独立观点,不代表沃通CA立场,转载目的在于传递更多信息。如有侵权,请联系删除。

]]>
/article/zixun/1881.html/feed 0
《面向云计算的零信任体系 第3部分:安全访问服务边缘能力要求》行标发布 /article/policy/1760.html /article/policy/1760.html#respond Wed, 10 Jan 2024 02:23:00 +0000 /?p=1760 标准共分为网络、安全、统一管控和云部署四个部分,根据四个象限的能力成熟度由低到高划分基础级、增强级、先进级和卓越级四个等级。

中华人民共和国工业和信息化部公告2023年第38号文件正式发布行业标准:YD/T 4598.3-2023《面向云计算的零信任体系 第3部分:安全访问服务边缘能力要求》,并于2024年4月1日正式施行。

近年来,云服务发展势头迅猛,产业生态日益成熟,应用程度不断深化,云计算战略价值在全球范围内持续提升。党的十八大以来,党中央高度重视安全生产工作,不断完善安全生产制度,筑牢安全底线,云网络的安全保障成为信息通信行业安全生产的重要组成部分。

随着企业纷纷拥抱数字化转型,IT架构从以传统数据中心为核心向以云计算为承载的数字基础设施转变,以数据中心内部和外部进行划分的安全边界被打破。SASE作为一种全新的安全理念,重新定义了网络安全和架构,实现网络安全的云化转型。

中国信通院于2021年6月牵头制定《面向云计算的零信任体系 第3部分:安全访问服务边缘能力要求》,汇聚了来自中国电信、中国移动、腾讯云、白山云、金山云、深信服、浪潮云、新华三、应通科技、北京神州、绿盟科技、启明星辰、天融信、青云科技、江苏易安联等众多云厂商、安全厂商的专业建议和宝贵经验。

标准介绍

《面向云计算的零信任体系 第3部分:安全访问服务边缘能力要求》基于零信任的安全思想,提供融合多元的云网安全管控,满足数字化转型对新一代网络安全架构的需求。SASE将网络连接能力与安全能力有机结合,构建基于云计算统一交付的服务模型,促进安全云和移动环境中的网络访问。标准共分为网络、安全、统一管控和云部署四个部分,根据四个象限的能力成熟度由低到高划分基础级、增强级、先进级和卓越级四个等级,旨在对厂商提供的云网络安全产品服务进行客观、全面的评估。

网络能力

SASE应具备基础网络连接能力,实现用户终端、分支、数据中心间数据互通、网络管理与网络加速等。

安全能力

保证用户端到端之间的各层级安全访问,同时,具有身份驱动的特点。首先应具有对身份的识别与管理能力,具备零信任安全防护机制,对每个用户的每一次访问默认采取零信任方式进行评估,根据评估结果执行对应的安全策略。

云部署能力

SASE将能力分布在边缘,在边缘具备提供接入、处理与执行能力,提供全网内低延时、安全的访问。

统一管控能力

SASE应具备统一管控平台,提供统一的配置、运维、网络与安全监控、统一身份管理与态势感知能力,将资源根据身份评估进行统一编排。

声明:本文来自云计算开源产业联盟,版权归作者所有。文章内容仅代表作者独立观点,不代表沃通CA立场,转载目的在于传递更多信息。如有侵权,请联系删除。

]]>
/article/policy/1760.html/feed 0
《面向云计算的零信任体系 第2部分:关键能力要求》行标发布 /article/policy/1757.html /article/policy/1757.html#respond Wed, 10 Jan 2024 02:20:05 +0000 /?p=1757 覆盖用户零信任访问场景和工作负载零信任访问两个场景。

中华人民共和国工业和信息化部公告2023年第38号文件正式发布行业标准:YD/T 4598.2-2023《面向云计算的零信任体系 第2部分:关键能力要求》,并于2024年4月1日正式施行。

中国信通院于2019年开始牵头制定YD/T 4598.2-2023《面向云计算的零信任体系 第2部分:关键能力要求》,在标准制定的过程中汇集大量来自云用户、云厂商、安全厂商的专家建议与实践经验,齐聚行业智慧完成了标准的制定。

标准介绍

YD/T 4598.2-2023《面向云计算的零信任体系 第2部分:关键能力要求》从用户零信任访问场景和工作负载零信任访问两个场景展开:

用户零信任访问场景

主要侧重对南北向流量的安全防护能力提出要求,包括多源评估能力、终端安全监测、终端应用监测、终端设备检测、动态安全阻断、策略执行能力等;

工作负载零信任访问场景

主要侧重对东西向流量的安全防护能力提出要求,包括多源评估能力、工作负载监测、访问控制能力、动态安全阻断、策略执行能力、网络管理能力等。

面向云计算的零信任体系 第2部分 关键能力要求 架构图

声明:本文来自CAICT可信安全,版权归作者所有。文章内容仅代表作者独立观点,不代表沃通CA立场,转载目的在于传递更多信息。如有侵权,请联系删除。

]]>
/article/policy/1757.html/feed 0