网站建设视频,注册网站有什么用,网站内容优化的主要方法,谷歌网站怎么做推广随着云计算技术的蓬勃发展#xff0c;传统上云实践中的应用升级缓慢、架构臃肿、无法快速迭代等“痛点”日益明显。能够有效解决这些“痛点”的云原生技术正蓬勃发展#xff0c;成为赋能业务创新的重要推动力#xff0c;并已经应用到企业核心业务。然而#xff0c;云原生技…
随着云计算技术的蓬勃发展传统上云实践中的应用升级缓慢、架构臃肿、无法快速迭代等“痛点”日益明显。能够有效解决这些“痛点”的云原生技术正蓬勃发展成为赋能业务创新的重要推动力并已经应用到企业核心业务。然而云原生技术在创造效益的同时却也面临着严峻的安全问题。当下常见的云原生安全产品在发挥效能的同时也引入新问题。作为数字经济时代下的特殊产物云原生安全解决方案的未来与演进又该何去何从 安全狗推出云原生安全2.X专题用翔实的系列文章为读者揭晓云原生安全的演进之路以及未来趋势。 在前一篇文章中笔者提到了诸多云原生安全1.0、云原生安全1.X等由于其自身框架性问题而存在的无法解决的弊端与限制。云原生安全2.X即“一体化”全栈云原生安全模型方案具有5大特征分别为软件资产管理和安全一体化、编排环境适配一体化、工作负载安全一体化、网络层安全一体化、应用安全一体化。 一、软件资产管理和安全一体化
当前云原生安全1.X方案通过采用组合多个特定安全工具来应对相应的安全问题的同时也带来诸多问题 当使用工具越多时需要配备的团队人员和使用培训等成本就越高 软件供应链不可见软件包间接依赖漏洞风险传递不可评估 大杂烩的工具难以呈现在整个应用程序生命周期中的安全上下文 不可变静态资产镜像等在不同生命周期阶段重复采集、重复安全检测 资产安全管理停留在简单的搜索、统计阶段缺乏多来源、多渠道资产数据深度融合和画像分析上 缺乏提供预防优先的能力IaC代码在构建阶段风险不可见应用漏洞太多且修复率低下大量带病镜像在运行时环境中进行 ... ....
基于对上述问题的分析安全狗在云原生安全2.X方案中提出并细化了软件资产管理和安全一体化的目标覆盖宿主机、镜像、容器、IaC的精细化静态、动态资产采集和安全检测支撑“底数清、信息全、状态明、响应快”的软件资产及软件供应链安全管理需求源头早期预防和深度分析的一体化需求。
软件资产管理和安全一体化该如何实现呢如下图所示 图1
针对实现路径的建议如下 首先采集范围要扩展代码即基础设施中代码和软件供应链这样的新资产形态要扩展支持达到底数清的目标 然后是静态资产和动态资产一体化采集达到信息全的目标 三是资产的安全检测一体化达到状态明的目标特别是针对不可变资产在应用构建、部署和运行时的不同生命周期阶段采集和检测一次 最后是基于多来源多渠道数据融合后的深度画像管理分析支撑响应快的目标。
从实战场景的角度看一体化目标需要达到的效果包括这五个方面
①覆盖从代码到云的细粒度精准资产一体化采集和安全检测
②补全安全分析所需要素数据
③解决无法支持01Day排查
④软件供应链完整视图和风险评估
⑤预防优先结合漏洞情报提升漏洞修复率 二、编排环境适配一体化
在展开介绍编排环境适配一体化之前我们需要先思考“为什么需要环境安全一体化”这个问题。 图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-basedL3-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的未来拓展方向是什么敬请期待~
