安全狗推出云原生安全2.X专题，用翔实的系列文章为读者揭晓云原生安全的演进之路以及未来趋势。
一、软件资产管理和安全一体化
- 当使用工具越多时，需要配备的团队人员和使用培训等成本就越高
-
软件供应链不可见，软件包间接依赖漏洞风险传递不可评估
-
大杂烩的工具难以呈现在整个应用程序生命周期中的安全上下文
-
不可变静态资产（镜像等）在不同生命周期阶段重复采集、重复安全检测
-
资产安全管理停留在简单的搜索、统计阶段，缺乏多来源、多渠道资产数据深度融合和画像分析上
-
缺乏提供预防优先的能力，IaC代码在构建阶段风险不可见，应用漏洞太多且修复率低下，大量带病镜像在运行时环境中进行
-
… ….
软件资产管理和安全一体化该如何实现呢？如下图所示：
图1
针对实现路径的建议如下：
- 首先采集范围要扩展，代码即基础设施中代码和软件供应链这样的新资产形态要扩展支持，达到底数清的目标
- 然后是静态资产和动态资产一体化采集，达到信息全的目标
- 三是资产的安全检测一体化，达到状态明的目标，特别是针对不可变资产在应用构建、部署和运行时的不同生命周期阶段采集和检测一次
- 最后是基于多来源多渠道数据融合后的深度画像管理分析，支撑响应快的目标。
从实战场景的角度看，一体化目标需要达到的效果包括这五个方面：
①覆盖从代码到云的细粒度精准资产一体化采集和安全检测
②补全安全分析所需要素数据
③解决无法支持0～1Day排查
④软件供应链完整视图和风险评估
⑤预防优先，结合漏洞情报提升漏洞修复率
二、编排环境适配一体化
在展开介绍编排环境适配一体化之前，我们需要先思考“为什么需要环境安全一体化”这个问题。
图2
如上图所示，云原生支撑环境涉及面广，环节多。因此，云原生安全1.X的方案在实际运行过程中也存在了系列问题：
- 一是兼容性问题造成更多部署、运维负担；
- 二是环境的配置安全往往由特定的安全产品分散割裂管理，比如使用CSPM产品解决不同供应商云平台配置安全问题；
- 三是在国内“异构多芯、混合调度”场景往往需要同时独立部署通用版和信创版两个版本，整体安全管理被割裂。
如下图所示，环境安全一体化对象清单包括CPU架构、操作系统、编排平台、容器运行时、网络CNI插件、镜像仓库、到CI/CD工具链。
图3
三、工作负载安全一体化
在运行时工作负载安全方面云原生安全1.X方案也存在一些问题，如下图所示。总体来说，主要体现在两个方面：一是主机安全、容器安全这样单品堆叠部署所带来的问题；二是安全能力孤立、分散在主机侧和容器侧，在应对容器逃逸、内核漏洞利用等高级威胁时力不从心。
图4
从底层技术原理来看，如下图所示，容器和宿主机是共用内核的轻量级隔离。一方面攻击者更容易逃逸以及进行横移攻击等，另外一方面，主机工侧和容器侧安全更适合构建一体化、协同化的威胁监测、防护和响应技术体系。
图5
通过工作负载安全一体化实现多维度云原生高级威胁检测技术合理布局设计，包括：主机侧和容器侧检测一体化，静态检测和动态检测一体化，特征检测、AI检测和进程行为模型检测一体化这样既能提升容器逃逸等高级威胁的整体防护效能，又能降低安全组件资源的占用。
四、网络层安全一体化
当前云原生安全1.X方案的网络层安全在四个方面存在很大的局限性：
-
宿主机侧和容器侧独立防护，缺乏协同
-
同一Packet重复检查，高峰时刻对业务稳定性和吞吐影响大
-
传统网络安全方案和工具的简单移植，包括OVN的ACL，或Iptables等集成
-
缺乏利用eBPF构建同时兼顾主机和容器侧L3-L7层的新方案
-
往往只支持Overlay，或Underlay一种
-
对于不支持Kubernetes NetworkPolicy的VPC子网方案、或SR-IOV方案兼容性差
这3个方面的技术局限性综合在一起，导致第4点在应用场景方面的局限。虽然1.X方案可以满足一般场景需求，但无法满足“高度合规监管，技术安全性、稳定性、网络延迟和资源消耗要求严格”高级场景需求。换句话说，类似银行核心业务系统云原生化升级，对多模网络场景下网络访问控制的严苛技术要求是达不到的。
-
只满足普通业务场景需求，在性能、稳定性等方面无法达到企业级技术要求
-
无法满足银行、电力等核心业务系统云原生化需求
从底层技术角度看1.X的网络安全方案，如下图所示，使用传统的 kube-proxy 处理 Kubernetes Service， 从网卡收到一个包开始，包在内核中的转发路径特别长，图中所有橙色的框都是 Netfilter 处理点，也就是利用传统iptables工具实现访问控制的作用点，而Netfilter 大流量情况下性能很差。
图6
从技术上要如何实现？
首先利用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的应用安全安全所存在的不足归纳起来主要有三个方面的原因：
图9
里应外合一体化方案如何实现呢？技术原理如下图所示：
图10
-
带外WAF：在不影响应用程序性能的情况下从L7层监控防护 Web 应用程序和 API，并与工作在L3-L4层网络微隔离等安全设施联合防御，降低性能开销。这对于那些对业务至关重要或对延迟敏感的 Web 应用程序或 API 非常有用。
-
微服务网关：对于传统单体应用，推荐使用集中的微服务安全网关。
-
内联RASP：应对频发的0Day、nDay漏洞开发一套基于虚拟补丁的漏洞防御技术平台
-
全栈安全协同，联防联抗。
本文主要分析了安全狗所提出的云原生安全2.X的五大特征以及每个特征对应的目标等等。在下篇文章笔者将重点介绍安全狗云原生安全产品云甲是如何落地云原生安全2.X概念，以及云原生安全2.X的未来拓展方向是什么，敬请期待~
