云原生应用安全

案例介绍

Cilium 是一种开源的云原生网络实现方案，与其他网络方案不同的是，Cilium着重强调了其在网络安 全上的优势，可以透明的对 Kubernetes 等容器管理平台上的应用程序
服务之间的网络连接进行安全防护。Cilium 在设计和实现上，基于 Linux的一种新的内核技术 eBPF，可以在 Linux内部动态插入强大的 安全性
、可见性和网络控制逻辑，相应的安全策略可以在不修改应用程序代码或容器配置的情况下进行 应用和更新。Cilium 在其官网上对产品的定位称为“eBPF-based Networking, Observability, and Security”，因 此可以看出，其特性主要包括这三方面：（1）供 Kubernetes 中基本的网络互连互通的能力，实现容 器集群中包括 Pod、Service 等在内的基础网络连通功能；（2）依托 eBPF，实现 Kubernetes 中网络的可 观察性以及基本的网络隔离、故障排查等安全策略；（3）依托 eBPF，突破传统主机防火墙仅支持 L3、 L4微隔离的限制，支持基于 API的网络安全过滤能力。Cilium 供了一种简单而有效的方法来定义和执 行基于容器 /Pod 身份（Identity Based）的网络层
和应用层（比如 HTTP/gRPC/Kafka 等）安全策略。Cilium 的参考架构 [37]如下图所示，Cilium 位于容器编排系统和 Linux Kernel 之间，向上可以通过编 排平台为容器进行网络以及相应的安全配置，向下可以通过在 Linux内核挂载 eBPF 程序，来控制容器 网络的转发行为以及安全策略执行。
图 7.3　Cilium 架构
Cilium Agent 在进行网络和安全的相关配置时，采用 eBPF 程序进行实现。Cilium Agent 结合容器 标识和相关的策略，生成 eBPF 程序，并将 eBPF 程序编译为字节码，将它们传递到 Linux内核。
图 7.4　Cilium 部署架构
默认情况下，Cilium 与其他网络插件一样，供了整个集群网络的完全互联互通，用户需要根据自己 的应用服务情况设定相应的安全隔离策略。如下图所示，每当用户新创建一个 Pod，或者新增加一条安全 策略，Cilium Agent 会在主机对应的虚拟网卡驱动加载相应的 eBPF 程序，实现网络连通以及根据安全策 略对数据包进行过滤。比如，可以通过采用下面的 NetworkPolicy 实现一个基本的 L3/L4 层网络安全策略。

云原生异常检测

云原生异常检测

异常分类

根据异常表现位置的不同，我们可以将其划分为网络侧异常和主机侧异常。这与传统的网络侧入侵 检测系统（NIDS）、主机侧入侵检测系统（HIDS）的分类是一致的。
网络异常 指的是集群东西或南北向流量上体现出来的异常，又可以细分为：行为型异常（例如：后 端数据库被发现有集群外通信的南北向流量，短时间内产生大量网络连接等）和载荷型异常（例如：某 Pod 被检测出 Webshell 流量等）。
为了区别传统的主机异常 ，我们将主机侧的异常限制在容器级别，也就是集群内部 Pod 自身所表现 的异常。根据异常涉及因素的不同，我们可以将其划分为行为型异常（例如：有新进程运行、进程以新 用户身份运行等）和资源型异常（例如：CPU/ 内存资源占用率过高、可用存储空间减小过快等）。

云原生网络侧异常检测方法

由于云原生环境下生态的开放性和容器网络的复杂性，传统 NIDS不能很好地监控检测到云原生环 境中网络流量中隐藏的入侵行为。云原生环境需要与之相适应的网络入侵检测机制。
具体来说，云原生网络入侵检测机制需要实现对 Kubernetes 集群每个节点上 Pod 相关的东西及南 北向流量进行实时监控，并对命中规则的流量进行告警。告警能够定位到哪一台节点上、哪一个命名空 间内的哪一个 Pod。
针对这些需求，我们可以采用基于 Pod 的流量检测方法：在每个节点上部署一个流量控制单元和策 略引擎，流量控制单元负责将特定 Pod 的流量牵引或镜像到策略引擎中，策略引擎对接入流量进行异 常检测（类似传统 IDS）并向日志系统发送恶意流量告警。集群内另有一编排引擎负责监控日志系统的 告警事件，根据告警定位到节点、命名空间、Pod，然后构建并下发阻断规则给流量控制单元，形成从 检测到阻断的完整闭环。该机制如下图所示：
图 8.1　基于 Pod 的流量检测方法示意图

云原生主机侧异常检测方法

基于进程模型的异常行为检测

一般来说，不同应用的业务场景可能不同，但是对于给定集群来说，其在一段生产运营时间内的业 务模式是相对固定的。这意味着，业务依赖的程序和模块是确定的。
我们可以进一步得出，该集群在一段时间内运行的进程是确定的，进程行为模式在一个合理的范围 内。在容器环境下，业务通常以镜像为单位进行交付，因此，无论容器启动多少个，创建于相同镜像的 容器内部的进程行为总是相似的。
基于上述合理假设，我们能够在镜像级别收集集群内部业务正常运行期间的进程集合及进程行为、 属性集合，采用自学习的方式，自动构建出合理的镜像进程模型。学习结束后，可以采用这些模型进行 容器内异常检测。
检测系统定期获取容器进程数据，当收到尚未建立进程行为模型的容器进程数据时，将自动为该镜 像建立并开始训练一个新的模型。在经过指定的训练学习周期（例如一周、一个月等），模型训练结束， 自动转为检测模式。此后，再收到该镜像相关的容器进程数据时，检测系统将利用模型针对这些数据进 行异常检测。系统检测出异常后，向运营人员发出告警通知，运营人员基于业务实际环境判断告警是否 正确，如果告警正确则进行相应处置；否则，运营人员可以对检测模型进行小范围修正。
整个流程分为学习、检测两个阶段：
容器集群是由大规模容器组成的运行环境，容器是基于镜像创建而成的动态运行时客体。镜像与容 器之间通常是一对多的关系，换言之，在容器集群环境中，来自同一个镜像的容器往往不止一个。
检测系统定期收集集群各宿主机节点上所有运行容器内部的所有进程数据，第一次收到数据后，利 用本次数据为该次数据涉及到的每一个镜像初始化进程行为模型。行为模型是对该镜像生成的容器在运 行时的正常行为范围的界定。
在学习期间，此后每一次收到与该镜像关联的容器进程信息时，利用这些新增信息不断更新该镜像 的模型，即更新模型中的进程列表，直到学习期结束，将模型状态改为“已就绪”。
模型的学习流程如下图所示：
图 8.2　模型学习流程
在学习期结束后，每一次收到数据后，检测系统将该次数据中属于同一镜像的数据与数据库中该 镜像的进程行为模型做匹配，如果待测数据中的进程属性不在模型的镜像进程列表描述的对应进程的 属性中，或待测数据的 CPU、内存等资源使用情况超出了镜像进程列表中记录的对应进程的历史最大 CPU、内存资源使用率，则判定异常，并输出告警。
基于模型的检测流程如下图所示：
图 8.3　基于模型的检测流程

基于系统调用的攻击行为检测

几乎任何一个有意义的进程在运行期间都会执行系统调用（System call），恶意进程也不例外，甚 至调用得更多更为频繁。另外，恶意进程的调用方式往往具有区别于正常进程的特征。
例如，2019 年著名的 runC 容器逃逸漏洞 CVE-2019-5736，它的特征是，在利用过程中需要以 / proc/self/exe 为路径参数执行 open 系统调用，在后续过程中，还会以 /proc/self/fd/ 为路径参数前缀 采用写方式执行 open 系统调用，以覆盖宿主机上的 runC 二进制文件。这样的参数内容在容器内业务 进程中非常罕见的。因此，特定系统调用 + 特定参数就是该漏洞的明显特征。
再如，“脏牛”（CVE-2016-5195）漏洞可以用于容器逃逸，在漏洞的触发过程中，恶意进程需要 同时高频调用 mmap 和 madvise 函数，或 mmap 和 ptrace 函数。“脏牛”属于竞态条件漏洞，其显 著特征是攻击者不能保证自己某一次的攻击一定会成功，只能根据系统状态、CPU 类型等估计出一个 大概的成功率。因此，为了成功触发漏洞，攻击者必须以尽可能快的速度进行系统调用。这种高频性是 值得防守者关注的明显特征。
同 CVE-2019-5736 漏洞利用一样，多数攻击行为都可以通过直接检测某次系统调用或连续几次系 统调用的异常来判断是否发生了某一类攻击行为。
然而，与“脏牛”漏洞利用一样，还有一些攻击行为不能简单地通过单次或有限次系统调用的异常 来判断。很可能每一个系统调用都是常见的，参数都是正常的，但是高频调用就能以一定概率触发漏洞。 对于这类攻击行为，我们就不能简单地采用上面的方式来检测了，概率式的攻击需要统计式的检测。例 如，我们可以检测一段时间窗口内系统调用的类型和频度，如果某个可能触发漏洞的系统调用集合内各 函数的频度都超过了某阈值，且这种调用模式在正常业务中是不常见的，那么这段时间内就很可能发生 了某漏洞的攻击利用行为。
8.4.　小结
在各行各业积极上云的今天，如何及时准确发现云原生环境内部的异常威胁并进行告警和处置，是 云原生平台开发运维和应急响应团队必须考虑的问题。对大规模云原生环境进行及时有效的异常检测监 控已经成为业务云原生化过程中的迫切需求。

云原生应用安全

应用安全

随着云计算模式的不断发展，企业拥抱数字化转型已逐渐成为行业共识，与此同时，应用也趋于云 原生化，为应现代应用架构趋势，包括移动访问、微服务设计模式、本地 / 云端部署的应用导致 API 数量倍增，可以说云原生应用中大部分交互模式以从 Web 请求 / 响应转向各类 API请求 / 响应，例如 RESTful/HTTP、gRPC 等。因而，API 安全在云原生环境中就显得尤为重要。

云原生应用的安全现状分析

云原生应用的 API安全基本归类于网络层面公开的 API存在的安全问题，微服务场景中，API安全 防护变得更加复杂，传统的单一入口防护已无法完全覆盖 API安全范畴。
近些年来，企业将各自的 Web 应用逐步向云原生应用的方向迈进，云原生应用中，API既充当外部 与应用的访问入口，也充当应用内部服务间的访问入口，可见 API已然被用来发展业务和推动创新。然 而，企业面对大量的 API设计需求，其相应的 API安全方案往往不够成熟，从而引起了 API滥用的风险。 据 Gartner 预测，到 2022 年，API 滥用将成为导致企业 Web 应用数据泄露最频繁的攻击载体 [38]。
API的实现及处理方式通常为客户端 / 服务端的形式，客户端存在的 API滥用现象最终是由于服务 端的安全威胁导致，我们通过调研发现，这些安全威胁包括注入攻击、DDoS 攻击、认证授权失败、敏 感信息泄露、中间人攻击、参数篡改等，关于每种威胁的攻击场景及实现原理由于篇幅限制，此处不做 赘述，详细内容可参考 OWASP在 2019 年发布的 API安全 Top10 报告 [39]。

参考资料

绿盟 云原生安全技术报告

友情链接

GB-T 30146-2013 公共安全 业务连续性管理体系要求