随着云原生进入快速发展期，越来越多的企业步入云原生化进程，但传统基于边界的防护模型已不能完全满足云原生安全的需求，基于安全“左移”原则的 DevSecOps 应运而生，将从 DevOps 全流程为企业的业务系统注入安全风险免疫能力。

云原生时代的安全新机遇

云原生技术实践联盟（CNBPA）在近日发布的《第四期（2021-2022）传统行业云原生技术落地调研报告——金融篇》中指出：安全“左移”——云原生安全策略成 2022 金融科技新焦点。

1649820108166688.png

以容器、微服务、服务网格为代表的云原生技术正在被广泛使用，重塑了云端应用的设计、开发、部署和运行模式，实现了自动化、易管理、可观测的全新 DevOps 体系，使开发者和运维人员能够最大限度地提高生产力，更敏捷、更高效、更安全地进行应用迭代。

然而，云原生给业务带来敏捷积极影响的同时，也带来了全新的安全挑战：

· 以容器为载体的云原生应用实例极大地缩短了应用生命周期；

· 微服务化拆分带来应用间交互式端口的指数级增长以及组件间设计复杂度的陡升；

· 多服务实例共享操作系统带来了单个漏洞的集群化扩散风险；

谈及云原生安全，不少人还停留在传统安全意识和观念，关注 Web 攻防、系统攻防、密码暴力破解等。然而，安全总是具有“短板效应”，有时，一个简单的端口暴露、未授权访问没及时处理就为攻击者提供了不费吹灰之力长驱直入的机会。

此外，云原生技术架构带来的风险，在未来数年内，可能会成为攻击者关注和利用的重点，进而发动针对云原生系统的攻击。传统基于边界的防护模型已不能完全满足云原生的安全需求，这就要求我们必须探索出一条更适合云原生时代的持续安全之路。

避坑指南：云原生安全风险一览

众所周知，只有通过全面了解云原生面临的安全风险，才能够更精准、更快速地搭建更可靠的云原生安全防护模型。以下就是备受大家关注的六大云原生安全风险，来看看你入坑了吗？

1649820212272586.png

1. 容器网络安全风险

网络的细粒度划分增加了访问控制和分离管控难度。

云原生环境下，服务细粒度划分，业务依赖关系复杂，如果容器网络层不能跟随业务关系实现细粒度访问控制策略，就会带来权限放大风险。比如：无需被外网访问的业务被默认设置了外网访问权限、容器网络可以无限制的访问宿主机节点的下层网络等，攻击者将利用这些漏洞，获取权限外甚至核心系统的访问控制权限，实现越权甚至提权攻击。

此外，云原生网络既有东西向流量、又有南北向流量，服务间流量访问频繁；且多服务实例共享操作系统，一个存在漏洞的服务被黑客攻陷将会导致同一宿主机上的其他服务受影响，如果 Pod、ns 之间、没有做好网络隔离策略，外部攻击就能从高风险实例逃逸，伴随东西向流量在集群网络内部的实例间进行横向攻击，致使威胁在集群内扩散。比如：有些容器平台采用 underlay 模式网络插件，使得容器 IP 与节点 IP 共享同一网络平面，在业务 IP 最终暴露给最终用户同时，管理控制台会面临被入侵的风险。

2. 编排及组件安全风险

云原生编排组件存在漏洞及管控风险增加入侵概率。

首先，非法提权暗含潜在安全隐患，如果普通用户获得管理员权限或者 Web 用户直接提权成管理员用户，编排工具可能存在多种漏洞导致此类攻击。比如：如果系统中存在一个 K8s 的提权漏洞，允许攻击者在拥有集群内低权限的情况下提升至 K8s api server 的权限；通过构造一个对 K8s api server 的特殊请求，攻击者就能以 K8s api server 身份向后端服务器发送任意请求，实现权限提升。

其次，编排工具组件众多、各组件配置复杂，配置复杂度的提升增加了不安全配置的概率，而不安全配置引起的风险不容小觑，可能会导致编排工具中账户管理薄弱，或部分账户在编排工具中享有很高特权，入侵这些账户可能会导致整个系统遭到入侵。

再者，容器在默认状态下并未对容器内进程的资源使用國值做限制，以 Pod 为单位的容器编排管理工具也是如此。资源使用限制的缺失，导致环境面临资源耗尽的攻击风险，攻击者可以通过在容器内运行恶意程序，或对容器服务发起拒绝服务攻击占用大量宿主机资源，从而影响宿主机和宿主机上其他容器的正常运行。

3. 镜像安全风险

镜像构建部署过程不规范引入安全风险。

首先，在传统模式中，部署的软件在其运行的主机上“现场”更新；与此不同，容器则必须在上游的镜像中进行更新，然后重新部署。因此，容器化环境的常见风险之一就是用于创建容器的镜像版本存在漏洞，从而导致所部署的容器存在漏洞。

其次，镜像配置不当可能会让系统面临攻击危险，例如，镜像未使用特定用户账号进行配置导致运行时拥有的权限过高；镜像含 SSH 守护进程导致容器面临不必要的网络风险等。

此外，镜像及容器技术一个主要的特点就是方便移植和部署，云原生用户可以将符合 OCI 标准的第三方镜像轻松部署到自己的生产环境中。因此，攻击者可将含有恶意程序的镜像上传至公共镜像库，诱导用户下载并在生产环境中部署运行，从而实现其攻击目的。

4. 镜像仓库安全风险

镜像仓库模式增加云原生软件供应链风险来源。

首先，镜像仓库安全风险主要涉及仓库账号及其权限的安全管理、镜像存储备份，传输加密、仓库访问记录与审计等，这些方面如果存在加固或配置策略不足的问题，就可能导致镜像仓库面临镜像泄露、篡改、破坏等风险。例如，垂直越权漏洞，因注册模块对参数校验不严格，导致攻击者可以通过注册管理员账号来接管 Harbor 镜像仓库，从而写入恶意镜像。实际使用中，用户往往会将镜像仓库作为有效且获得批准的软件源，因此，镜像仓库遭到入侵将极大增加下游容器和主机的被入侵风险。

除此之外，镜像仓库面临的另一个重要安全问题就是保证容器镜像从镜像仓库到用户端的完整性。如果用户以明文形式拉取镜像，在与镜像仓库交互的过程中极易遭遇中间人攻击，导致拉取的镜像在传输过程中被篡改或被冒名发布恶意镜像，则会造成镜像仓库和用户双方的安全风险。

5. 运行时安全风险

容器特性增加了容器运行时逃逸风险和威胁范围。

首先，用户可以通过修改容器环境配置或在运行容器时指定参数来缩小或扩大约束。如果用户为不完全受控的容器提供了某些危险的配置参数，就为攻击者提供了一定程度的逃逸可能性，包括未授权访问带来的容器逃逸风险，特权模式运行带来的容器逃逸风险。

其次，将宿主机上的敏感文件或目录挂载到容器内部，尤其是那些不完全受控的容器内部，往往会带来安全问题。在某些特定场景下，为了实现特定功能或方便操作，人们会选择将外部敏感卷挂载入容器。随着应用的逐渐深化，挂载操作变得愈加广泛，由此而来的安全问题也呈现上升趋势。例如：挂载 Docker Socket、挂载宿主机进程文件系统引入的容器逃逸风险等。

再者，相关程序漏洞，指的是那些参与到容器生态中的服务端、客户端程序自身存在的漏洞。例如 CVE-2019-5736 正是这样一个存在于 runC 的容器逃逸漏洞。

更重要的一点是，容器的内核和宿主机共享，且容器技术本身建立在 Linux Namespace 和 Linux Cgroups 两项关键技术之上，所以 Linux 内核本身所产生的漏洞会导致容器逃逸。Linux 内核漏洞危害极大、影响范围极广，是各种攻防话题下不可忽视的一环。近年来，Linux 系统曝出过不少存在提权隐患的内核漏洞，典型的就是脏牛漏洞（DirtyCOWCVE-2016-5195）。

6. 新用云形态带来新的安全风险

随着企业数字化转型进程的不断深化，IT 架构从以传统数据中心为核心向以云计算为承载转变，多云、混合云、分布式云成为主要形态，以数据中心内部和外部进行划分的安全边界被打破，IT 架构面临更多安全信任危机。

这方面的风险主要包括：资源暴露面增大，工作负载可信程度难以保证；分布式应用架构导致东西流量激增，默认可信的风险大；数字化工作空间扩展，终端和身份可信状况都需要把控。

DevSecOps：更让企业放心的云原生安全防护模型

在新技术、新生态、新业务、新市场需求的不断冲击下，企业对业务应用的要求变成了“更快的迭代速度、更高的服务质量、以及更强的安全性”，企业安全开发运维模式逐渐向更敏捷、更稳健、更安全的 DevSecOps 新模式转型。在“Everything Shift Left”的大背景下，DevSecOps 则完美地满足了当前企业敏捷安全开发运维的需求趋势，能够有效防范上述安全风险，被广泛认为是云原生时代更让企业放心的安全防护模型。

1649820265468650.png

首先，在进行云原生安全防护模型时，企业应该遵循安全“左移”设计原则。所谓安全“左移”，即尽量早地暴露安全问题从而减小被攻击面，越早发现问题就能用越小的成本去规避安全风险，将云原生安全管控融入到 DevOps 的全流程中，从开发到上线全生命周期覆盖。

比如：在上线前的开发过程中，可以先进行代码安全扫描、以及黑盒、灰盒测试；在构建镜像仓库后，进行镜像深度扫描、镜像签名类工作；在上线后，进行容器配置检查、监控容器运行时的异常行为；通过早期定位安全问题，提前进行排查，最终减少攻击面和潜在的运行风险。

1649820273549130.png

在安全“左移”原则基础之上，我们可以从以下 4 个维度，进一步构建基于 DevSecOps 的云原生安全架构模型：

· 基础设施安全：主要是 IaaS 层的安全，包括计算安全、网络安全、存储安全等。

· 云原生计算环境安全：在镜像安全方面，针对镜像安全风险可以进行镜像扫描、镜像签名、敏感信息扫描，针对镜像及镜像传输过程中的安全，可以进行镜像仓库访问控制、镜像仓库安全通信等；在运行时安全方面，可以进行容器运行时异常行为分析，如发生敏感挂载等问题时可以进行有效监控，并及时做出容器隔离等安全响应；在编排及组件安全方面，可以增加 CIS 等安全基线扫描、针对 K8s 集群的漏洞扫描、敏感信息加密、访问控制、对命名空间之间、Pod 之间的资源隔离与限制；在容器网络安全方面，可以制定和主机或外部服务之间的访问控制策略、更细粒度的网络隔离、以及网络入侵行为的监控。

· 云原生应用开发运营安全：在微服务安全方面，可以进行微服务的 API 安全治理、微服务之间的访问控制和安全通信；在研发运营安全方面，要更关注安全设计、代码安全、制品安全，同时可以进行静态应用测试、动态应用测试、交互式应用测试，尽早规避安全风险，并进行运行时安全配置；在数据安全方面，可以通过数据加密、数据备份、数据脱敏，来保障安全性。

· 安全管理：在整体云原生平台构建以及 K8s 集群管理过程中，企业还应该关注安全审计、用户权限管理、安全策略、监控管理、密钥管理等一系列相关配置。

在实践方面，以某全国性大型银行为例，该银行全栈云容器平台作为驱动金融数字基础设施建设的重要引擎，通过建立上述安全“左移”的云原生安全防护模型，践行安全可靠的 DevSecOps 理念，实现了企业级的全生命周期自适应安全、IT 系统智能化检测、可靠的容器安全管理、敏捷化 DevSecOps 流程、零信任安全风险评估，大大提升了其业务系统的安全风险免疫能力，构筑了强大的云原生安全防线。

点击此处，详细了解灵雀云如何帮助您的企业提升应对IT风险的免疫力，与灵雀云工程师一起规划探讨，云原生安全最佳实践。