云安全的未来是云原生安全

VSole2022-07-11 17:05:24

云计算的概念从提出到现在已经近 15 年时间。最初,业界大多将云计算架构分为基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS),这种基于虚拟主机(VM)为主体的虚拟化技术,从 IT 架构视角进行划分的方法虽然清晰但有局限性,因为它并不是完全站在应用和业务视角。等到容器虚拟化技术普及以后,一套以容器化、微服务、开发运营一体化(DevOps)和持续交付为主要要素,从云应用视角、全新的、专门为云计算设计的架构发展起来,这套架构就是云原生。

云原生产业联盟(CNIA)在《2020 年云原生发展白皮书》指出,2019 年中国云原生市场规模已达 350.2 亿元。云原生市场的快速发展有赖于其相对传统云技术的重要优势。从技术特征来看,云原生拥有极致的弹性能力、服务自治、故障自愈能力和大规模可复制能力;从应用价值方面来看,云原生异构资源标准化,加速了数字基础设施解放生产力,提升业务应用的迭代速度,在赋能业务创新方面有重要价值;从产业效用来看,云原生极大地释放了云的红利,成为驱动业务的重要引擎。

云原生以其技术优势以及不断扩大的应用场景,逐步普及到各行各业的敏捷开发与业务创新中,可以说“云原生正在吞噬一切”。

图1 云原生正在吞噬一切

一、云原生安全的特点

云原生作为云计算的未来阶段,其安全势必成为云安全的主要战场。云原生安全的需求主要体现在两个方面。一是新的组件面临新的风险,如容器的隔离性不如虚拟机(VM)而导致其更容易发生逃逸攻击等,这就需要新的产品及解决方案。二是传统的云安全需求(例如访问控制)在新的架构中需要改进以适应新的架构。

在以前的云计算时代,安全和云平台的结合不算紧密,大部分以安全资源池这种外挂形式来实现云安全,而云原生安全需要安全能力和云原生平台紧密结合,真正成为内生安全,这将是云安全的巨大挑战和机遇。

(一)不可变的基础设施

“不可变的基础设施”是云原生中非常重要的一个理念,可以说是云原生整个架构的核心思想,其贡献不亚于应用商店对智能手机的贡献。云原生对一个容器实例的更新是替换,而不是修改。这种方式保证了多实例间的一致性,有利于应用的弹性扩容。为了解决随之而来的效率问题,云原生用编排工具、微服务架构和 DevOps 一系列技术来保证替换的效率。相应地,“不可变的基础设施”也带来了安全防护思路的变化。

1. 资产识别的变化

一个容器中包括的软件及其运行方式,在打包镜像的时候已经确定。镜像是一个全量的软件包集合,对容器内的应用等资产识别,通过镜像便可了解全貌。基于不可变基础设施的思想下,一个软件的更新,会生成一个全新的镜像。

在容器运行状态时,需更多关注容器动态的变化,应该从集群视角,通过标签、命名空间(Namespace)等识别资产的业务属性。另外,需要对容器运行历史状况进行重点关注,各个架构下资产的生命周期完全不同,物理机是以年为单位、虚拟机是以月为单位、容器以分钟级为单位,而无服务器(Serverless)以秒级为单位。不同类型资产的特点如图 2 所示。

图2 不同类型资产的特点对比

2. 防护起点的变化

通俗的理解,云原生架构中的操作系统应该是基于容器技术的分布式架构解决方案Kubernetes,而不是主机操作系统(OS)。在云原生中,没有主机的概念,只有节点的概念,这个节点就是一个计算单元,可以是物理机、虚拟机、物联网设备等,所以在节点这一侧的安全防护可以通过收缩风险面来实现。各大云厂商都推出了云原生专用的 OS,如 CoreOS/Container Linux、Photon OS、RancherOS、Red Hat CoreOS (RHCOS)、Fedora CoreOS 等,这些专用操作系统极度精简,只保证基本的 Kubernetes 能运行,要求其他所有第三方的应用都运行在容器中,这一层的安全风险可以降到极小。每一个组织通过最小授权原则,都可以基于标准的操作系统进行加固后,制定自己的云原生 OS,从而解决 OS 一层的安全问题。在缩小风险面的同时,减少管理成本。

所以云原生安全的起点应该是 Kubernetes,从 Kubernetes 的容器层面向下覆盖节点安全,向上覆盖微服务安全,而不是从底层的节点向上覆盖。因为节点向上的覆盖能力不足,特别是针对集群、网络策略和微服务等云原生特有的组件和功能的防护。

(二)防护边界的变化

云原生的整个架构是以服务云原生应用,以容器为主的虚拟化技术构建的,其秉承了软件定义一切的思想,相对于传统架构,其边界变得更加模糊。

图3 不同架构的边界特点

如图 3 所示 , 在传统数据中心(IDC)的环境中,系统的边界非常清晰,以网络设备上的边界划分为主。对外的边界由防火墙、路由器等来实现 ,内部的边界以虚拟局域网等措施来保证。所以传统 IDC 是以物理的网络设备作为边界区分,区分的标记主要使用物理地址(MAC),互联网协议地址(IP)。在以虚拟机为主的云计算环境中,以虚拟机为最小单元,以虚拟化网络的访问控制措施作为边界划分,颗粒度到虚拟机级别,以 IP地址或者内部域名来识别不同资产。

而在云原生环境下,资产视角变成业务视角和应用视角,主要通过命名空间进行区隔,而识别资产的方法主要以标签为主,所以整个边界变得模糊而且更细粒度,优势是天然对业务和应用进行了区分,但同时让安全控制和管理更为复杂,以 IP 或域名为主的安全防护措施势必需要调整。

此外,云原生的管控措施基于白名单机制,包括 Kubernetes 支持的网络策略就是白名单机制。云原生架构下的安全是基于零信任的思路进行防控,所以云原生是零信任在生产环境下落地实现的最佳 IT 架构。

(三)高度的流程化、自动化

上文中提到,DevOps 保证了云原生应用的发布效率,但安全防护往往和效率有一定冲突。传统的安全措施对效率的影响在非全自动化流程中可能不明显,例如业务上线的安全测试和检测一般是在质量保证(QA)完成后进行,等安全测试完成再确认上线。这些工作往往通过内部邮件来流转,内部对其及时性有一定的容忍度。

但在云原生下,DevOps 作为云原生应用的生命周期管理流程,安全管控需要无缝植入到这个流程中,也就是当前流行的开发安全运营一体化(DevSecOps)。DevSecOps 作为一个大的体系,除了代码安全测试,还应包括制品库安全管理,运行安全策略等。所以将云原生安全产品或者工具嵌入到 DevOps 流程,成为一个必选项。

(四)全新攻击手段

当前针对云原生的攻击手段越来越多样,无论是前两年爆出的特斯拉集群入侵事件,容器官方镜像仓库被投毒,还是在近年的攻防演练出现通过攻击容器得分的情况,都印证了这一趋势。2022 年,对于云原生的攻击开始增多,由于当前云原生系统普遍欠缺安全防护手段,攻击的得手率极高。在云原生安全领域的攻防不对等情况,比其他架构严重得多。针对云原生的攻击手段还有其独特性, 因此安全组织 MITRE 的对抗战术和技术知识库(ATT&CK 框架)推出了专门针对容器的攻击模型。

二、云原生安全典型应用案例

以小佑科技服务的某股份制银行云原生安全应用案例,来看云原生安全的典型应用场景。该银行全栈云容器平台基于 IaaS 私有云“两地三中心”架构部署于北京香山、酒仙桥、武汉三个数据中心,底层使用 IaaS 提供的节点约 2000 台,运行容器数量达到 2 万余个,涉及开发、测试、预投产、生产环境的近 50 个 Kubernetes 集群。在全栈云容器平台上承载的业务系统 43 个,包括手机银行系统、统一支付平台、金融服务开发平台、多方安全计算平台、5G 线上超市系统等金融业务系统。

(一)需求描述

该银行对云原生安全的需求如下。

1. 全生命周期自适应安全

对容器安全涉及的所有对象都进行防御,包括操作系统、Kubernetes 平台、容器、容器镜像、镜像仓库、微服务。在每一个资产对象的防护方案中,均考虑资产盘点、加固、检测、响应、预测这样的安全框架,形成安全运营的闭环。

2. 监测智能化

基于动态学习业务系统进程与网络流量的方法,采用机器学习技术,构建安全基线模型,实现风险识别和风险态势感知。配合传统基于规则的分析识别技术,加上机器学习技术从而较全面发现安全漏洞和风险。

3. 安全内生化

全栈云容器平台不仅仅提供基础运行环境,还直接集成安全能力。在创建 Kubernetes 集群时,便将防御容器以服务守护进程(Daemonset)的方式进行同步创建,每个集群节点运行一个防御容器,提供检测与防护能力。当集群扩容或缩容时,防御容器可以随着节点数量变化而自动做相应调整,减少安全运维成本。

4. 流程敏捷化

基于安全左移的思路,实现 DevSecOps。即在软件研发阶段便同步介入安全检查。通过在软件的整个生命周期中支持多个卡点,将风险尽早暴露,降低安全运维的成本。安全卡点包括 编排文件扫描、镜像安全扫描、镜像构建入库、镜像运行拦截等。安全左移能够尽早发现问题,有助于降低修复成本。

5. 零信任

按照零信任的思想,持续信任评估,动态访问控制。零信任的其中一条技术路线是微隔离。在容器网络中,需要采用微隔离技术来缓解风险。

(二)解决方案

结合该银行其系统特点和需求,设计了如下的云原生安全架构。

图4 云原生安全系统架构

1. 资产中心

资产中心对镜像、仓库、容器、集群节点、微服务、Kubernetes 配置信息等容器相关信息进行自动采集和实时更新,支持对每一类资产进行数据分级聚合展示,实现云原生资产的全面可视化,帮助用户更直观地了解当前云原生资产情况,消除安全与运维之间的信息壁垒。

2. 漏洞管理

基于漏洞的视角,对整体的风险进行梳理,形成发现漏洞 - 验证漏洞 - 修复漏洞的闭环。发现漏洞,对业务容器的镜像和集群进行扫描,得到当前存在的漏洞列表。验证漏洞,对漏洞进行验证,以确保扫描结果的正确性。分类分级,从漏洞的严重性与相关资产的重要程度,对漏洞进行评级,使得修复工作分得清优先级。修复与验证,对修复漏洞后的资产重新扫描审核,确认问题得到缓解。

3. 合规审计

在业务系统上线运行之前,对业务系统所在容器、集群以及节点进行合规检测,以防止不安全的配置导致容器逃逸或者集群入侵事件。全栈云原生安全防护平台在制定规范要求时,基于 CIS合规进行裁剪与自定义,并提供可视化的基线检测结果和修复建议,协助用户修复不合规的配置。

4. 镜像安全

镜像作为容器运行的基础,如果存在安全隐患、风险问题将直接影响到容器环境的安全性。面对镜像中可能存在的安全问题,需要对业务环境的镜像资产,进行自动扫描以及支持手动扫描来识别风险,对危险镜像基于策略进行阻断,对高危镜像提供可写入镜像源码文件(Dockerfile)的修复建议。

云原生安全防护平台支持对容器镜像制作过程、镜像运行、镜像发布进行全方位的监控和检测,可以自动获取节点和仓库中的镜像,并从官方漏洞库、木马病毒、可疑历史操作、敏感信息泄露、以及是否是可信任镜像等多个维度对镜像进行扫描。

5. 容器安全

云原生安全防护平台通过对容器的调用行为进行自动学习,形成容器的运行模型,同时对容器的调用行为进行监控,当容器出现模型之外的调用动作后,进行实时预警或阻断。

容器安全防护平台支持对容器内行为进行检测。当发现容器逃逸行为、读取敏感信息、启动恶意进程、挂载非法设备、映射敏感目录、修改命名空间等恶意行为时,根据预设策略触发报警或阻断容器运行,并对发现异常的 POD进行隔离。

6. 微服务安全

云原生安全防护平台提供对微服务、应用进行周期性的检测。支持自动检测发现 Kubernetes 集群内的微服务以及应用编程接口(API)并通过可视化视角展示出来。能够通过手动或周期性自动发现的微服务以及 API 进行安全风险扫描。

7. 集群安全

Kubernetes 的多个核心组件均有不同程度的漏洞爆出,其中不乏高危甚至是超危漏洞。除了包含漏洞的组件,不安全的配置也可能使得整个集群处于风险之中。平台支持对不同类型云的集群的不同版本进行安全风险扫描,如 Kubernetes 版本信息披露、匿名身份验证、可能遭受的各类攻击等。

8. 网络微隔离

容器微隔离用于阻止容器间东西向的攻击,减小被攻击面,全自动构建和管理容器层的访问控制策略。主要通过双向控制、访问可视化、访问过程溯源的功能,对基于容器、容器组和业务视角进行超细粒度的双向网络访问控制,能够对非法访问的轨迹监控并溯源整个行为访问的过程。

三、云原生安全的关注点

企业在建设云原生安全体系时,除需要使用专业的云原生安全产品外,还包括持续的云原生安全运营。所以,企业在云原生安全建设还需重点关注以下三点。

(一)防御能力的有效性

容器运行时安全除了能够应对已知威胁,还应具备应对未知威胁的能力。在整体上对齐 MITRE的 ATT&CK 框架,增强安全事件分析能力,通过持续运营来优化配置,降低漏报与误报。风险检测的准确率提升了,才有可能进一步推进自动处置措施的编排落地。

此外,企业可以考虑部署云原生蜜罐来建立主动威胁情报能力。

(二)安全的左移

在软件生命周期中,越靠后修复问题的成本越高,越靠前修复问题的越低。安全左移是将安全投资更多地放到开发阶段,包括安全需求分析、安全设计、安全编码、供应链(软件库、开源软件等)安全、镜像安全等。

在云原生环境中,业务需要频繁调整、上线,安全左移的思路不仅让 DevOps 团队能够及早发现安全风险,还能降低安全投入、提高整体的安全水平,以确保及时解决安全威胁。DevOps 是云原生重要的组成部分,所以 DevSecOps 也是云原生安全的一个重要部分。

(三)工具链的整合

Gartner 2021 年技术成熟度曲线中增加了一个新类别云原生应用保护平台(CNAPP),包含一组集成的安全性和合规性功能,旨在开发和生产过程中保护云原生应用。有些企业使用了 10 个或更多不同的安全工具,手工将 DevSecOps 缝合在一起,每个工具都有独立的责任和应用程序风险视图。

在开发阶段,静态应用程序安全测试(SAST,通常所说的代码审计)、API 安全测试、动态应用程序安全测试(DAST)、基础架构即代码(IaC)扫描和威胁建模是保护云原生应用最常用的五种工具。

在生产运维阶段,WEB 应用程序防火墙(WAF)、WEB 应用和 API 保护(WAAP)、应用安全监控、云工作保护平台(CWPP)和云安全态势管理(CSPM)是保护云原生应用的五种最常用工具。

如果保护云原生应用需要使用来自多个供应商的多个工具,显然会降低开发和运维的效率,并造成风险的零散可见性。CNAPP 产品允许企业使用单个集成产品来保护云原生应用的整个生命周期。

CNAPP 重构了针对云原生应用安全防护的思路和方法。企业不应将开发和运行视为两个单独的部分,而分别使用不同的工具,应将安全性和合规性视为跨越开发和运维的连续统一体,并使用整合的安全工具。企业安全团队和 DevSecOps架构师可以采用综合的方法来理解和降低应用程序风险。通过在整个开发生命周期中综合考虑漏洞、及其运行环境(上下文)关系,以发现更多风险,使开发团队能够专注于应用程序中最大风险的部分。

四、总 结

云原生安全发展的趋势,从基础设施层面来看分为几个步骤:首先是“部署容器化”,然后是“容器微服务化”,再到“服务网格化”,最后实现“无服务器化”。对应的安全能力建设,首先是容器安全,然后开始关注微服务应用与数据安全,以及与服务网格(ServiceMesh)配套的安全能力建设。从软件的生命周期来看,云原生安全建设则会更关注在 DevOps 的开发流程中做到同步的安全需求设计、安全开发、安全测试、安全发布和安全运维,形成整体的 DevSecOps方案。

随着云原生技术的普及,云原生安全将完成现有云安全的替代,所以将来再讨论云安全时,可能指的就是云原生安全。

kubernetes云计算
本作品采用《CC 协议》,转载必须注明作者和本文链接
网络犯罪组织使用一个称为Weave Scope的合法工具,在目标Docker和Kubernetes集群上建立了无文件后门。据研究人员称,TeamTNT网络犯罪团伙卷土重来,他们通过滥用一种名为Weave Scope的合法监控工具攻击Docker和Kubernetes实例。但是接下来,攻击者下载并安装 Weave Scope。TeamTNT小组专门研究攻击,通常使用恶意Docker映像进行攻击,并证明了自己的创新能力。TeamTNT之前也有文档记载在AWS内部署独特且罕见的凭证窃取蠕虫。
Controller Manager 中 的 Node Controller 通 过 APIServer 定期读取节点状态信息,并做响应处理。业务系统通过调用密码机提供的密码服务,实现数据的机密性、完整性、有效性和不可否认性。作为 Node 节点接入 Kubernetes服务器密码机,内部也采用了Docker 生成 VSM。当创建 VSM 需从外部下载镜像时,Docker 可能会从外部下载到恶意镜像,恶意镜像可能导致服务器密码机内部的敏感数据被窃取或破坏。因此,服务器密码机可从以下两个维度限制恶意镜像在服务器密码机中执行。
容器安全工具涵盖多种任务,包括配置加固和漏洞评估任务。Gartner持续观察AST市场发展的主要驱动力是支持企业DevSecOps和原生应用程序的需求。Checkmarx SCA的供应链安全执行行为分析,并对给定的开源包添加操作风险指标。这得到了Gartner客户的积极反馈。Checkmarx一直在简化软件许可,将大多数产品与开发人员的数量联系起来。
所有这一切须经认证过程加以验证,最大限度地降低未授权方窃取数据的可能性。这两个漏洞向黑客暴露了流出安全飞地的机密信息。上个月,谷歌、英伟达、微软和AMD联合发布了一套名为Caliptra的规范,用于在芯片上建立安全层存放受保护的可信数据。谷歌已经拥有了自己的机密计算技术,该名为OpenTitan的技术主要关注引导扇区保护。
本文收集整理了目前市场上主流的7款CSPM解决方案,并对其应用优势和存在的不足进行了分析。综合能力表现较突出Prisma Cloud是Palo Alto公司推出的一款CNAPP解决方案,拥有面向混合、多云和原生等环境的全面安全态势管理功能。Lacework的机器学习驱动方法允许平台自动管理安全,不仅用于行为分析,还用于威胁情报和异常检测。
“贴身”保护5G边缘计算
据悉,跨平台加密货币挖掘僵尸网络LemonDuck正在针对开源应用容器引擎Docker,以在Linux系统上挖掘加密货币。
2022年1月6日,360漏洞团队监测到 Red Hat发布安全公告,修复了多个存在于 OpenShift Container Platform中的中危漏洞。
勒索软件现在已经成为制定灾难恢复计划和灾难恢复技术的关键原因之一。也就是说,许多供应商继续利用快照作为全面灾难恢复和勒索软件保护的元素之一。从2016年到2021年,勒索软件造成的全球损失从3.25亿美元上升到200亿美元。这意味着企业需要重新考虑其针对勒索软件用例的灾难恢复策略,因为传统的数据保护解决方案和灾难恢复计划可能不起作用。
当前,计算已经成为新型基础设施的关键支撑技术。在疫情期间,推动了大量远程办公、政务防疫、百姓生活等SaaS应用和移动应用。要回答计算未来数年的发展,则需要回顾计算在过去的发展。需要注意到,计算在国内发展总体可分为三个阶段。
VSole
网络安全专家