云原生安全2.X 进化论系列|揭秘云原生安全2.X的五大特征

news/2024/11/24 0:36:57/

随着云计算技术的蓬勃发展,传统上云实践中的应用升级缓慢、架构臃肿、无法快速迭代等“痛点”日益明显。能够有效解决这些“痛点”的云原生技术正蓬勃发展,成为赋能业务创新的重要推动力,并已经应用到企业核心业务。然而,云原生技术在创造效益的同时,却也面临着严峻的安全问题。当下常见的云原生安全产品在发挥效能的同时也引入新问题。作为数字经济时代下的特殊产物,云原生安全解决方案的未来与演进又该何去何从?

安全狗推出云原生安全2.X专题,用翔实的系列文章为读者揭晓云原生安全的演进之路以及未来趋势。

在前一篇文章中,笔者提到了诸多云原生安全1.0、云原生安全1.X等由于其自身框架性问题而存在的无法解决的弊端与限制。云原生安全2.X,即,“一体化”全栈云原生安全模型方案具有5大特征,分别为软件资产管理和安全一体化、编排环境适配一体化、工作负载安全一体化、网络层安全一体化、应用安全一体化。

一、软件资产管理和安全一体化

当前云原生安全1.X方案通过采用组合多个特定安全工具来应对相应的安全问题的同时,也带来诸多问题:

  • 当使用工具越多时,需要配备的团队人员和使用培训等成本就越高

  • 软件供应链不可见,软件包间接依赖漏洞风险传递不可评估

  • 大杂烩的工具难以呈现在整个应用程序生命周期中的安全上下文

  • 不可变静态资产(镜像等)在不同生命周期阶段重复采集、重复安全检测

  • 资产安全管理停留在简单的搜索、统计阶段,缺乏多来源、多渠道资产数据深度融合和画像分析上

  • 缺乏提供预防优先的能力,IaC代码在构建阶段风险不可见,应用漏洞太多且修复率低下,大量带病镜像在运行时环境中进行

  • ... ....

基于对上述问题的分析,安全狗在云原生安全2.X方案中提出并细化了软件资产管理和安全一体化的目标:覆盖宿主机、镜像、容器、IaC的精细化静态、动态资产采集和安全检测,支撑“底数清、信息全、状态明、响应快”的软件资产及软件供应链安全管理需求,源头早期预防和深度分析的一体化需求。

软件资产管理和安全一体化该如何实现呢?如下图所示:

图1

针对实现路径的建议如下:

  • 首先采集范围要扩展,代码即基础设施中代码和软件供应链这样的新资产形态要扩展支持,达到底数清的目标

  • 然后是静态资产和动态资产一体化采集,达到信息全的目标

  • 三是资产的安全检测一体化,达到状态明的目标,特别是针对不可变资产在应用构建、部署和运行时的不同生命周期阶段采集和检测一次

  • 最后是基于多来源多渠道数据融合后的深度画像管理分析,支撑响应快的目标。

从实战场景的角度看,一体化目标需要达到的效果包括这五个方面:

覆盖从代码到云的细粒度精准资产一体化采集和安全检测

补全安全分析所需要素数据

解决无法支持0~1Day排查

软件供应链完整视图和风险评估

预防优先,结合漏洞情报提升漏洞修复率

二、编排环境适配一体化

在展开介绍编排环境适配一体化之前,我们需要先思考“为什么需要环境安全一体化”这个问题。

图2

如上图所示,云原生支撑环境涉及面广,环节多。因此,云原生安全1.X的方案在实际运行过程中也存在了系列问题:

  • 一是兼容性问题造成更多部署、运维负担;

  • 二是环境的配置安全往往由特定的安全产品分散割裂管理,比如使用CSPM产品解决不同供应商云平台配置安全问题;

  • 三是在国内“异构多芯、混合调度”场景往往需要同时独立部署通用版和信创版两个版本,整体安全管理被割裂。

因此,为了减轻用户安装、运维云原生安全产品的工作负担,在安全狗云原生安全2.X方案中提出了环境安全一体化的目标。针对国内关基类云原生架构“异构多芯 混合调度”的特性,可提供环境安全自适应一体化的功能,支撑统一的安全策略管理、实施、分析和无缝隙完整覆盖。

如下图所示,环境安全一体化对象清单包括CPU架构、操作系统、编排平台、容器运行时、网络CNI插件、镜像仓库、到CI/CD工具链。

图3

三、工作负载安全一体化

在运行时工作负载安全方面云原生安全1.X方案也存在一些问题,如下图所示。总体来说,主要体现在两个方面:一是主机安全、容器安全这样单品堆叠部署所带来的问题;二是安全能力孤立、分散在主机侧和容器侧,在应对容器逃逸、内核漏洞利用等高级威胁时力不从心。

图4

底层技术原理来看,如下图所示,容器和宿主机是共用内核的轻量级隔离。一方面攻击者更容易逃逸以及进行横移攻击等,另外一方面,主机工侧和容器侧安全更适合构建一体化、协同化的威胁监测、防护和响应技术体系。

图5

因此,云原生安全2.X工作负载安全一体化的目标是:构建基于“容器侧、主机侧”的“全栈式”“一体化”多维度云原生高级威胁检测技术体系,具有联合发现、协同抵抗的体系化作战的效果。

通过工作负载安全一体化实现多维度云原生高级威胁检测技术合理布局设计,包括:主机侧和容器侧检测一体化,静态检测和动态检测一体化,特征检测、AI检测和进程行为模型检测一体化这样既能提升容器逃逸等高级威胁的整体防护效能,又能降低安全组件资源的占用。

四、网络层安全一体化

当前云原生安全1.X方案的网络层安全在四个方面存在很大的局限性

1

网络平面分层防护影响性能

  • 宿主机侧和容器侧独立防护,缺乏协同

  • 同一Packet重复检查,高峰时刻对业务稳定性和吞吐影响大

2

访问控制底层技术达不到企业级技术要求

  • 传统网络安全方案和工具的简单移植,包括OVN的ACL,或Iptables等集成

  • 缺乏利用eBPF构建同时兼顾主机和容器侧L3-L7层的新方案

3

网络模式支持单模

  • 往往只支持Overlay,或Underlay一种

  • 对于不支持Kubernetes NetworkPolicy的VPC子网方案、或SR-IOV方案兼容性差

这3个方面的技术局限性综合在一起,导致第4点在应用场景方面的局限。虽然1.X方案可以满足一般场景需求,但无法满足“高度合规监管,技术安全性、稳定性、网络延迟和资源消耗要求严格”高级场景需求。换句话说,类似银行核心业务系统云原生化升级,对多模网络场景下网络访问控制的严苛技术要求是达不到的。

4

应用场景存在较大局限性

  • 只满足普通业务场景需求,在性能、稳定性等方面无法达到企业级技术要求

  • 无法满足银行、电力等核心业务系统云原生化需求

底层技术角度看1.X的网络安全方案,如下图所示,使用传统的 kube-proxy 处理 Kubernetes Service, 从网卡收到一个包开始,包在内核中的转发路径特别长,图中所有橙色的框都是 Netfilter 处理点,也就是利用传统iptables工具实现访问控制的作用点,而Netfilter 大流量情况下性能很差。

图6

因此,我们在2.X中提出了网络层安全一体化的目标,采用基于零信任模型和eBPF技术设计开发高性能云原生防火墙实现主机、容器层网络安全一体化。

从技术上要如何实现

首先利用eBPF技术解决性能问题,技术原理如图所示,利用eBPF技术要过传统的内核网络栈,缩短包转发路径。前提条件是用户的Linux内核升级到更现代化的一点的版本,建议4.19以上。

图7

然后利用eBPF解决网络安全问题。我们选择入站流量安全控制来举例,技术原理如下图所示。首先对入站流量的劫持,主要使用 eBPF 程序 hook bind 系统调用完成。和 iptables 不同,iptables 可以针对每个 netns 单独设置规则,eBPF 程序 attach 到指定 hook 点后,会对整个系统都生效。换句话说,采用eBPF技术的云原生防火墙就是能支持宿主机和容器底层网络访问控制的一体化

 图8

然后基于零信任模型实现L3-L7层访问控制策略,以及与服务网格的协同联动等安全管理需求:

  • 基于身份的(identity-based)L3-L7 网络安全

  • API-aware 安全(HTTP、gRPC 等)

  • mTLS透明加/解密

  • 利用sockmap/redirection 做 socket 重定向,实现与服务网格协同

  • ... ...

五、应用安全一体化

如下图所示,云原生安全1.X的应用安全安全所存在的不足归纳起来主要有三个方面的原因:

01

当前主流的技术路线为内联 Web 应用防火墙 (WAF) 和单点 API 安全工具来帮助用户阻断web安全威胁;以sidecar模式部署。最大的问题是安全组件自身占用资源过大,且和业务应用绑定在同一个Pod中,在业务高峰时刻,这种技术路线方案需要安全团队有时要牺牲应用程序性能来增加保护,这给安全团队带来了挑战,往往导致安全团队最终关闭安全工具以保持应用程序正常运行。

02

大型攻防演练过程中,0day漏洞频发,而官方补丁迟迟到来,或者需要重启业务,或者老旧应用无法提供补丁,因此,安全团队需要一套基于能解决虚拟补丁的漏洞防御技术平台。

03

头痛医头脚痛医脚的孤立防护的局限性。

图9

因此,云原生安全2.X提出应用安全一体化的目标,我们归纳为构建器“里应外合”的无缝衔接方案,可以灵活地保护关键应用程序,而不至于在性能和稳定性方面做出过大的牺牲。

里应外合一体化方案如何实现呢?技术原理如下图所示:

 图10

  • 带外WAF:在不影响应用程序性能的情况下从L7层监控防护 Web 应用程序和 API,并与工作在L3-L4层网络微隔离等安全设施联合防御,降低性能开销。这对于那些对业务至关重要或对延迟敏感的 Web 应用程序或 API 非常有用。

  • 微服务网关:对于传统单体应用,推荐使用集中的微服务安全网关。

  • 内联RASP:应对频发的0Day、nDay漏洞开发一套基于虚拟补丁的漏洞防御技术平台

  • 全栈安全协同,联防联抗。

本文主要分析了安全狗所提出的云原生安全2.X的五大特征以及每个特征对应的目标等等。在下篇文章笔者将重点介绍安全狗云原生安全产品云甲是如何落地云原生安全2.X概念,以及云原生安全2.X的未来拓展方向是什么,敬请期待~


http://www.ppmy.cn/news/23636.html

相关文章

《唐诗三百首》数据源网络下载

2023年的 元宵之夜,这场以“长安”为主题的音乐会火了!在抖音,超过2300万人次观看了直播,在线同赏唐诗与交响乐的融合。许多网友惊呼,上学时那些害怕背诵的诗句,原来还可以有这么美的表达这场近80分钟的音乐…

谈谈Spring中Bean的生命周期?(让你瞬间通透~)

目录 1.Bean的生命周期 1.1、概括 1.2、图解 2、代码示例 2.1、初始化代码 2.2、初始化的前置方法和后置方法(重写) 2.3、Spring启动类 2.4、执行结果 2.5、经典面试问题 3.总结 1.Bean的生命周期 1.1、概括 Spring中Bean的生命周期就是Bean在…

Negative Prompt in Stable Diffusion

必读链接:https://www.reddit.com/r/StableDiffusion/comments/z7salo/with_the_right_prompt_stable_diffusion_20_can_do/ A lot of people have noticed that Negative Prompt works wonders in 2.0, and works even better in 2.1. Negative hints are the op…

怡合达业务大规模容器化最佳实践

作者:肖念康,东莞怡合达智能制造供应链资深 Java 开发工程师,主要负责公司内部 DevOps、代码托管平台、任务需求管理平台的研发及其他项目的管理,云原生的研究与开发工作。 公司简介 怡合达致力于自动化零部件研发、生产和销售&am…

【笔记】移动端自动化:adb调试工具+appium+UIAutomatorViewer

学习源: https://www.bilibili.com/video/BV11p4y197HQ https://blog.csdn.net/weixin_47498728/category_11818905.html 一、移动端测试环境搭建 学习目标 1.能够搭建java 环境 2.能够搭建android 环境 (一)整体思路 我们的目标是Andr…

雪花算法snowflake

snowflake中文的意思是 雪花,雪片,所以翻译成雪花算法。它最早是twitter内部使用的分布式环境下的唯一ID生成算法。在2014年开源。雪花算法产生的背景当然是twitter高并发环境下对唯一ID生成的需求,得益于twitter内部高超的技术,雪…

【逐步剖C】-第六章-结构体初阶

一、结构体的声明 1. 结构体的基本概念 结构体是一些值的集合,这些值称为成员变量。结构体的每个成员可以是不同类型的变量。结构体使得C语言有能力描述复杂类型。 如学生,有姓名、学号、性别等;如书,有作者,出版日期…

冷知识|鹤顶红还能用来修长城?

大家好,我是建模助手。 在上篇浅浅地蹭了波热点之后,我灵机一动,倒不如也搞一搞建筑方面的冷知识?冷热搭配,事半功倍... 问问大家,如果谈起古建筑,关键词都有什么?是庄严、震撼、壮…