保障云服务器安全，“独立主机+独占内核”还不够！

2024-11-06

随着云计算的发展和云原生应用场景的普及，以容器和微服务为代表的云原生技术，受到人们的广泛关注，但是随着传统业务上云和容器化改造过程，也带来了越来越多安全挑战。

具体来说，主要分为以下几类：

容器镜像安全——

镜像是一个包含应用/服务运行所必需的操作系统和应用文件的集合，用于创建一个或多个容器，它们之间联系紧密，镜像的安全性将会影响容器安全。

运行环境安全——

作为容器的载体和编排管理软件，主机和容器编排平台等运行环境也是容器安全的重要因素。主机上的容器并未实现完全隔离，如果主机未进行安全加固，一旦攻击者发起提权攻击，将会控制主机上其他容器。

共享内核风险——

传统容器共享操作系统内核，但并未实现完全隔离，若虚拟化软件存在漏洞，或宿主机被攻击，将会造成容器逃逸或资源隔离失效，影响某个容器或多个容器的安全。

网络隔离风险——

网络实现了容器之间、容器与外部之间的通信，以及应用之间的交互，但在虚拟化的容器网络环境中，其网络安全风险较传统网络更复杂、严峻。如果容器之间未进行有效隔离和控制，则一旦攻击者控制某台主机或某台容器，可以以此为跳板，攻击同主机或不同主机上的其他容器，也就是常提到的“东西向攻击”，甚至有可能形成拒绝服务攻击。

安全争分夺秒，运行环境怎能拉胯？！UOE（统信安全运行环境）应运而生！

传统Docker容器技术采用共享宿主机内核方式运行，利用内核特性实现对不同用户的命名空间进行隔离，使用CGroups进行硬件资源分配与限制，POSIX Capabilities进行root权限分割等，Seccomp限定系统调用。

但是传统docker底层实现局限导致了容器的隔离性，封闭性还是远远低于拥有独立GuestOS的虚拟机。由于操作系统内核漏洞，Docker组件设计缺陷，以及不当的配置都会导致Docker容器发生逃逸，从而获取宿主机权限。

有鉴于此，统信软件自研打造UOE（统信安全运行环境），全面针对以上问题，使出几大“看家本领”：

底层容器技术安全

UOE借鉴业内先进轻量虚拟机技术设计，参考Firecracker架构如下图

UOE容器基于kvm，所创建的microVM独享内核，不存在容器所面临的隔离性等安全问题。UOE采用精简的设备集，只包含5种设备：virtio-net、virtio-block、virtio-vsock、串行控制台和一个最小键盘控制器仅用于停止microVM。因此对比传统的虚拟机，microVM攻击面更小，因此也更安全。

最小化权限构建

UOE的设计原则是容器系统默认最小化权限需求，包括：

- 关键文件权限应最小并可用

- etc/shadow、密钥等文件的权限应为0400（只能被root帐户读取），/boot 的权限应为0700（只能被root帐户读写执行）

- 拥有suid/sgid权限的文件必须经过评审才能集成

- 禁止除/tmp之外目录权限为777的目录

- 禁止非必要服务默认自启

- 禁止存在未评审的端口被监听

所有的自研应用包括内核，排除使用不安全的算法，包括MD（MD5，MD2，MD4）、SHA1(sha160)、HMAC-MD5、HMAC-MD5-96、DES、AES(CBC模式)。

容器隔离安全

UOE设计之初就考虑到容器的网络隔离和存储隔离安全设计。

网络隔离使用网络插件CNI（容器网络接口）来管理 VM 网络，CNI提供了一种应用容器的插件化网络解决方案，方案定义了对容器网络进行操作和配置的规范，通过插件的形式对CNI接口进行实现。