云安全两大新能力：攻击回溯与容器安全

青藤云安全是主打 “自适应安全” 理念，专注在 “主机安全” 的安全初创公司。2014年成立至今，青藤云安全分别在2015年和2018年拿下了6000万的A轮以及2亿元的B轮融资，并连续三年（2017～2019）作为唯一中国厂商入选Gartner云工作负载保护平台市场指南。

让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：域名与空间、虚拟空间、营销软件、网站建设、山南网站维护、网站推广。

2018年对于青藤云安全而言是关键的一年。除了B轮融资到位外，青藤云安全在9月还正式发布了其首个重量级平台产品—— 青藤万相·主机自适应安全平台 。万相以承载业务的工作负载流为核心，对主机上的资产、状态、关键活动等进行感知，并生成安全指标，用于持续分析和风险发现，且适配物理机、虚拟机和云环境。11月，青藤云安全还和腾讯安全正式达成战略合作，作为可选安全组件（天眼云镜）出现在腾讯云的私有云标准方案中。

更多认可：以主机agent的形式来做安全

青藤云安全虽然是安全初创企业，但也有了4年多的 历史 。让张福引以为傲，也最让他放心不下的，是青藤云安全选择的这条技术路线，即不以流量分析为主，而是通过在物理主机安装轻量级agent的形式，选择这样一个位置来做安全。

青藤万相核心架构

自适应安全架构的四个能力象限，预测-检测-防御-响应，青藤云安全看准的 “检测” 能力。但和目前主流的检测思路不同，扎根于 “攻防理念” 的思路因缺乏足够深度和全面的可见性，对自身和攻击的理解都不足。如果要足够清晰、准确的认识自身、攻击及其带来的影响，张福认为，需要足够扎实的感知能力作为支撑。而实现此的技术方式，就是在物理主机上安装agent，以此为 “据点” 收集信息。己方的、敌方的，以及攻击者试图抹除的。

但从客户的角度，担忧也很明显。主机agent的形式，虽然安全离威胁近了，但安全离业务也近了。如果安全产品成熟度不够，出现了问题，导致了业务系统受到负面影响甚至服务中断，那么客户的安全或IT负责人，必不可少要承担更多的责任。

可以看到，安全工作中的平衡，体现在方方面面。

2018年，客户的反馈，以及业界对基于主机的产品形态的跟进，张福坦言，让他轻松了许多。

先说客户。客户对这种形式的顾虑，从2018年大量的反馈来看，张福认为已经开始减少。这个转变，得益于数字化转型的趋势，让客户越来越认识到云化后安全对于业务的重要性。

“

之前更多是合规市场，满足基线即可。同时，因为业务系统的开放性相对较弱，所以给对手留下的攻击面也小很多。但上云后，一切都不一样了。安全对业务的支撑和影响变得更加重要，对更好的安全能力，而不只是部署了哪些产品的需求，更加强烈。

无疑，从主机这个离（业务）数据、威胁都更近的的位置来做安全，效果会比纯粹的流量检测更好。这也满足了客户的需求。而青藤云安全对产品成熟度的追求，以及产品部署后持续维护、改进的大量投入，则最大程度减少了客户对 “可能给业务系统造成负面影响” 的忧虑。

而这两点，也是张福认为，除了技术思路外，自身产品能力重要的优势所在。

这两个重要优势，张福认为也得益于另一个点，就是青藤云安全的产品打磨思路。据张福介绍，青藤云安全的产品从研发到销售，不是传统厂商等产品足够成熟后再寻找客户的思路，而是在初具雏形时就会在国内寻找愿意尝试新的技术思路、有一定程度容错能力的客户，通过产品在客户的真实IT环境中，不断进行产品成熟度的打磨。例如招商银行、平安 科技 ，据张福介绍，都是自身安全实践和理解都走在比较靠前的两个青藤云安全的重要客户。

再谈谈业界。

众所周知，青藤云安全连续多年在Gartner的云工作负载保护平台市场指南榜上有名，对业内的技术趋势青藤云安全也一直跟的很紧。对青藤而言，业界的主流产品形态的改变，意味着对青藤云安全的技术路线选择的一种印证。

张福表示，近两年的行业会议，RSA、ISC等，EDR的崛起，特别是如CrowdStrike等厂商，依托主机侧轻量级代理的的形式实现的入侵检测和响应能力，正逐渐成为业界厂商的主流思路。

“

从产品角度，主机安全不应是一系列产品，而是一个核心做安全的位置。就像网络安全这四个字，有一层重要含义，就是在网络层来做安全。主机安全，业界目前的主流思路和我们一致，就是要通过在主机上安装agent来做。而且，可以看到，安全能力正在从传统的网络侧移向主机侧，通过 ‘位置’ 的改变，实现能力的跨越式提升。这个趋势已经可以明显的感受到。这会是整个产业的一个大升级。

2018年，青藤云安全发布了其重要的平台级产品 “万相”，在产品成熟度、客户和业界的接受度上，张福认为已经达到了预期；2019年，张福表示，首先，要基于“万相”这个平台，在产品能力上有所提升，真正解决客户问题。比如说弱口令的发现，这个需求看似很简单，而且有多家扫描器支持，但是实际情况是因为服务器对口令尝试频率的限制，效果并不好。但是如果通过主机agent做类似“白盒”的底层解析，不仅效率高，而且能够查出之前大量的漏报。

之后，就是新产品的方向。

青藤云安全不是销售导向的公司，所以张福始终认为做产品要“克制”，要谨慎，并且多年持续投入打造产品的准备。

上一个系列，青藤云安全的产品能力倾向感知或者说威胁发现；下一个，张福目前有两个计划，一是补足感知之后的分析能力，二是基于主机agent技术的积累，扩充一个安全场景。

新能力：攻击回溯与容器安全

先介绍要补充的分析能力。

青藤云安全最新发布的 青藤星池·大数据分析平台 ，定位在攻击场景的回溯分析，是青藤云安全威胁感知能力的延伸。

青藤云安全之前在威胁感知有多年的积累，其万相平台的 “资产清点、漏洞发现、入侵检测等“ 能力是典型代表。有了这些积累，下一步，张福认为，要补充分析能力。用张福的话说，是根据这些感知能力提供的线索，把整个攻击的过程回溯出来。

“

一旦发生安全事件，客户高层第一时间关心的并不会是谁攻击了我，或是他怎么进来的，而是我损失了什么。因为视损失的内容，后续的处置，包括问责、惩罚等，都可大可小。更严重的是，攻击者是否已经窥探、甚至拿到了一些高敏感数据。这些问题，之前大量的安全产品都是回答不了的，因为缺乏视野。主机上的agent，我认为是必备基础。

简单理解，和攻击溯源的目的不同，“星池”是利用大数据分析的相关技术，还原整个攻击链，特别是从客户资产的角度，记录攻击者的行为轨迹，明确客户的损失。

“

不仅要能快速、准确的发现攻击，也要高效地搞清来龙去脉，从感知到分析，对于青藤这是重要的能力延展。未来，我们还会融入处置响应的能力。实现安全闭环，才能更好的帮助客户提升安全能力。当然，这个闭环青藤不一定都要自己做，我们是非常开放而且看重合作的。青藤只做我们认为客户缺失的（能力），是要让客户的安全能力达到应有的高度，而不是抢市场，重复解决问题，甚至劣币驱逐良币。

容器安全是另一个新场景。

张福认为，容器是云计算的未来。国内很多互联网、金融行业的客户，都在快速拥抱容器。可以预见，容器将会很快成为主流的基础设施形态。

容器是一个新技术，而且使用便捷，但不代表安全问题就会少。张福表示，从云主机到容器，安全问题反而是有增无减，因为目前开发者更多还是在容器功能性上的完善。比如容器镜像的后门问题，几乎没有有效可靠的检测方法。反观业界，专注容器安全的厂商并不多；同时，思路几乎都是基于容器间的流量分析来做，像是传统的IPS放在容器这个形态下。但只是这样，张福认为能力深度并不够。

“

青藤做容器安全是很天然的，因为我们四年多的积累都在主机侧，80%以上的技术经过对容器的重新适配后都可以复用。

据了解，青藤云安全的 容器安全产品“蜂巢” ，只需要在承载容器的物理机上安装agent，就可以将安全能力做到容器内进程行为的深度；同时在管理上，“蜂巢”可以在万相平台上进行统一管理，方便客户将安全能力和策略随着业务在各形态间迁移。

张福表示，客户在使用容器的时候就已经在考虑安全问题了，这是之前做安全不具备的条件。青藤云安全的核心是保证工作负载（workload）的安全，无论它的形态是怎样。主机agent的形式，张福认为在容器这个场景下也是有足够优势和独特竞争力的。后续，也会把容器间的流量分析作为补充能力加入，成为一个综合性产品。

不可否认，目前，容器安全在中国还是早期市场。所以，对于“蜂巢”，青藤云安全的思路更多还是进行开放行的测试，为后续产品化的过程做铺垫。

“

首先，‘蜂巢’ 会支持应用较为广泛的开源容器，比如docker、国内的灵雀云，并开放给在容器的应用走在前面，有大量应用场景而且愿意和我们合作的客户，帮助我们不断的改进，一起成长。这也是产品化过程所必须要有的投入，我们的目标是在3-4年后，成为容器安全领域的领先者。

等保2.0：云安全合规解读

此外，作为国内的安全企业，青藤云安全也必须要足够重视合规的市场需求，特别是在5月13日正式发布等级保护2.0一系列标准后。

云计算系统网络架构是扁平化的，业务应用系统与硬件平台松耦合。所以，首先，在云计算系统边界划分上，存在两个典型场景：一是业务应用不独占硬件物理资源的情况，定级系统的边界应划在虚拟边界处；二是业务应用对应的系统模块存在相对独立的底层服务和硬件资源，系统边界划分到硬件物理设备上。

其次是在安全责任及定级方面。程度认为，要综合考虑被测系统是云计算平台还是业务应用系统，以及被测系统的服务模式，来判断不同的安全责任。

此外，在定级过程中还需注意下面4点：

1. 云计算平台安全保护等级，原则上不低于其承载的业务系统的安全保护等级。

2. 国家关键信息基础设施（重要云计算平台）的安全保护等级应不低于第三极。

3. 在云计算环境中，应将云资源平台作为单独定级对象，云租户侧的等级保护对象也应作为单独的定级对象定级。

4. 对于大型云计算平台，应将云计算基础设施和有关辅助服务系统划分为不同的定级对象。

在建设整改方面，云等保中增加了虚拟化、云管理平台、镜像文件等云计算独有内容，并强调安全能力在云平台建设中的集成。在平台内部，强调通讯加密与认证、动态监测预警、快速应急响应能力建设、安全产品合规等能力要求。

据了解，青藤云安全已经推出针对云等保2.0中安全计算环境部分的解决方案，覆盖通用要求中身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范，以及资源控制六个部分。

相关阅读

这家初创公司做自适应安全

腾讯安全与青藤云安全：高安全能力与创新安全公司的结合

金融行业中容器技术被泛接受和使用，容器安全将要面临哪些问题？

容器有多安全?

很多人认为，容器比虚拟机安全性更低，因为如果容器主机内核存在漏洞，那么它可以提供一种进入共享它的容器的方法。管理程序也是如此，但由于管理程序提供远远少于Linux内核(通常实现文件系统，网络，应用程序进程控制等)的功能，因此它的攻击面更小。

但是在过去的几年里，为了增强容器的安全性开发了大量的软件。

例如，Docker(和其它容器系统)现在包括一个签名的基础架构，允许管理员签署容器镜像，以防止不可信的容器被部署。

然而，可信任的签名容器不一定可以安全运行，因为在签名后容器中的一些软件可能会被发现漏洞。因此，Docker和其它容器提供容器安全扫描方案，可以就容器镜像是否有任何可被利用的漏洞而通知管理员。

更专业的容器安全软件也被开发出来了。比如Twistlock，它提供的软件可以配置容器的预期行为和“白名单”进程，网络活动(如源和目标IP地址和端口)，甚至是某些存储实践，以便可以标记任何恶意的或意外的行为。

另一家专业的容器安全公司Polyverse采用了不同的方法。它利用了这样一个事实，容器可以在几分之一秒内启动，以便每隔几秒在已知的良好状态中重新启动容器化应用程序，将黑客必须利用在容器中运行的应用程序的时间最小化。

哪一个Linux发行版适合用作容器主机?

如果Linux发行版的预期用途只是充当容器主机来运行容器，那么它们大多数都是功能上臃肿的。因此，很多Linux发行版本被设计为专门用于运行容器。

一些例子包括：

·Container Linux(以前的CoreOS Linux)—为容器而构建的第一个轻量级容器操作系统之一。

·RancherOS –由容器构建的简化的Linux发行版，专门用于运行容器。

·Photon OS - 最小的Linux容器主机，被优化在VMware平台上运行。

·Project Atomic Host - Red Hat的轻量级容器操作系统拥有基于CentOS和Fedora的版本，Red Hat Enterprise Linux中还有一个下游企业版本。

·Ubuntu Core - 最小的Ubuntu版本，Ubuntu Core被设计为用于物联网设备和大规模云端容器部署的主机操作系统

如果是Windows环境会怎么样?

除了在任何运行3.10(或更高版本)的Linux内核的Linux发行版上运行，Docker还可以在Windows上运行。

这是因为在2016年，微软在Windows Server 2016和Windows 10中引入了运行Windows容器的能力。这些是为Windows设计的Docker容器，并且它们可以在任何Docker客户端或微软的PowerShell中进行管理。

(微软还引入了Hyper-V容器，这些容器是运行在Hyper-V虚拟机中的Windows容器，用于增加隔离度。)

Windows容器可以部署在Windows Server 2016的标准安装中，精简的Server Core安装或Nano Server安装选项，专门用于在容器或虚拟机中运行应用程序。

除了Linux和Windows之外，Docker还在流行的云平台上运行，包括亚马逊的EC2，谷歌的 Compute Engine，微软的Azure和Rackspace。

容器最终会取代全面的服务器虚拟化吗?

由于一些重要的原因，这在可预见的未来不太可能。

首先，仍然有广泛的意见认为虚拟机比容器提供了更高的安全性，因为它们提供了增强的隔离级别。

其次，可用于编排大量容器的管理工具还不如管理虚拟化基础架构的软件(如VMware的 vCenter或微软的System Center)全面。对这类软件进行了大量投资的公司在没有充分理由的情况下不太可能放弃他们的虚拟化基础架构。

也许更重要的是，虚拟化和容器也开始被视为互补技术而不是敌对技术。这是因为容器可以在轻量级虚拟机中运行，以增加隔离度，进而提高安全性，并且因为硬件虚拟化可以更轻松地管理支持容器所需的硬件基础架构(网络、服务器和存储)。

VMware鼓励投资虚拟机管理基础架构的客户在其轻量级虚拟机上的Photon OS容器Linux发行版上运行容器，而这些轻量级的虚拟机可以在vCenter进行管理。这是VMware的“VM中的容器”策略。

但是，VMware还引入了所谓的vSphere集成容器(vSphere Integrated Containers ，VIC)。这些容器可以被直接部署到独立的ESXi主机，也可以像虚拟机一样被部署到vCenter Server。这是VMware的“容器作为虚拟机”策略。

这两种方法都有其优点，但重要的是，能够在虚拟化基础架构中使用容器而不是替换虚拟机，这往往是很有用的。

常见的容器安全威胁有哪些？

以Docker 容器的安全问题为例

(1) Docker 自身安全

Docker 作为一款容器引擎，本身也会存在一些安全漏洞，CVE 目前已经记录了多项与 Docker 相关的安全漏洞，主要有权限提升、信息泄露等几类安全问题。

(2) 镜像安全

由于Docker 容器是基于镜像创建并启动，因此镜像的安全直接影响到容器的安全。具体影响镜像安全的总结如下。

镜像软件存在安全漏洞：由于容器需要安装基础的软件包，如果软件包存在漏洞，则可能会被不法分子利用并且侵入容器，影响其他容器或主机安全。

仓库漏洞：无论是Docker 官方的镜像仓库还是我们私有的镜像仓库，都有可能被攻击，然后篡改镜像，当我们使用镜像时，就可能成为攻击者的目标对象。

用户程序漏洞：用户自己构建的软件包可能存在漏洞或者被植入恶意脚本，这样会导致运行时提权影响其他容器或主机安全。

(3) Linux 内核隔离性不够

尽管目前Namespace 已经提供了非常多的资源隔离类型，但是仍有部分关键内容没有被完全隔离，其中包括一些系统的关键性目录（如 /sys、/proc 等），这些关键性的目录可能会泄露主机上一些关键性的信息，让攻击者利用这些信息对整个主机甚至云计算中心发起攻击。

而且仅仅依靠Namespace 的隔离是远远不够的，因为一旦内核的 Namespace 被突破，使用者就有可能直接提权获取到主机的超级权限，从而影响主机安全。

(4) 所有容器共享主机内核

由于同一宿主机上所有容器共享主机内核，所以攻击者可以利用一些特殊手段导致内核崩溃，进而导致主机宕机影响主机上其他服务。

既然容器有这么多安全上的问题，那么我们应该如何做才能够既享受到容器的便利性同时也可以保障容器安全呢？下面我带你来逐步了解下如何解决容器的安全问题。

如何解决容器的安全问题？

(1) Docker 自身安全性改进

事实上，Docker 从 2013 年诞生到现在，在安全性上面已经做了非常多的努力。目前 Docker 在默认配置和默认行为下是足够安全的。

Docker 自身是基于 Linux 的多种 Namespace 实现的，其中有一个很重要的 Namespace 叫作 User Namespace，User Namespace 主要是用来做容器内用户和主机的用户隔离的。在过去容器里的 root 用户就是主机上的 root 用户，如果容器受到攻击，或者容器本身含有恶意程序，在容器内就可以直接获取到主机 root 权限。Docker 从 1.10 版本开始，使用 User Namespace 做用户隔离，实现了容器中的 root 用户映射到主机上的非 root 用户，从而大大减轻了容器被突破的风险。

因此，我们尽可能地使用Docker 最新版本就可以得到更好的安全保障。

(2) 保障镜像安全

为保障镜像安全，我们可以在私有镜像仓库安装镜像安全扫描组件，对上传的镜像进行检查，通过与CVE 数据库对比，一旦发现有漏洞的镜像及时通知用户或阻止非安全镜像继续构建和分发。同时为了确保我们使用的镜像足够安全，在拉取镜像时，要确保只从受信任的镜像仓库拉取，并且与镜像仓库通信一定要使用 HTTPS 协议。

(3) 加强内核安全和管理

由于仅仅依赖内核的隔离可能会引发安全问题，因此我们对于内核的安全应该更加重视。可以从以下几个方面进行加强。

宿主机及时升级内核漏洞

宿主机内核应该尽量安装最新补丁，因为更新的内核补丁往往有着更好的安全性和稳定性。

使用Capabilities 划分权限

Capabilities 是 Linux 内核的概念，Linux 将系统权限分为了多个 Capabilities，它们都可以单独地开启或关闭，Capabilities 实现了系统更细粒度的访问控制。

容器和虚拟机在权限控制上还是有一些区别的，在虚拟机内我们可以赋予用户所有的权限，例如设置cron 定时任务、操作内核模块、配置网络等权限。而容器则需要针对每一项 Capabilities 更细粒度的去控制权限，例如：

cron 定时任务可以在容器内运行，设置定时任务的权限也仅限于容器内部；

由于容器是共享主机内核的，因此在容器内部一般不允许直接操作主机内核；

容器的网络管理在容器外部，这就意味着一般情况下，我们在容器内部是不需要执行ifconfig、route等命令的 。

由于容器可以按照需求逐项添加Capabilities 权限，因此在大多数情况下，容器并不需要主机的 root 权限，Docker 默认情况下也是不开启额外特权的。

最后，在执行docker run命令启动容器时，如非特殊可控情况，–privileged 参数不允许设置为 true，其他特殊权限可以使用 --cap-add 参数，根据使用场景适当添加相应的权限。

使用安全加固组件

Linux 的 SELinux、AppArmor、GRSecurity 组件都是 Docker 官方推荐的安全加固组件。下面我对这三个组件做简单介绍。

SELinux (Secure Enhanced Linux): 是 Linux 的一个内核安全模块，提供了安全访问的策略机制，通过设置 SELinux 策略可以实现某些进程允许访问某些文件。

AppArmor: 类似于 SELinux，也是一个 Linux 的内核安全模块，普通的访问控制仅能控制到用户的访问权限，而 AppArmor 可以控制到用户程序的访问权限。

GRSecurity: 是一个对内核的安全扩展，可通过智能访问控制，提供内存破坏防御，文件系统增强等多种防御形式。

这三个组件可以限制一个容器对主机的内核或其他资源的访问控制。目前，容器报告的一些安全漏洞中，很多都是通过对内核进行加强访问和隔离来实现的。

资源限制

在生产环境中，建议每个容器都添加相应的资源限制。下面给出一些执行docker run命令启动容器时可以传递的资源限制参数：

1  --cpus                          限制 CPU 配额

2  -m, --memory                    限制内存配额

3  --pids-limit                    限制容器的 PID 个数

例如我想要启动一个1 核 2G 的容器，并且限制在容器内最多只能创建 1000 个 PID，启动命令如下：

1  $ docker run -it --cpus=1 -m=2048m --pids-limit=1000 busybox sh

推荐在生产环境中限制CPU、内存、PID 等资源，这样即便应用程序有漏洞，也不会导致主机的资源完全耗尽，最大限度降低安全风险。

(4) 使用安全容器

容器有着轻便快速启动的优点，虚拟机有着安全隔离的优点，有没有一种技术可以兼顾两者的优点，做到既轻量又安全呢？

答案是有，那就是安全容器。安全容器是相较于普通容器的，安全容器与普通容器的主要区别在于，安全容器中的每个容器都运行在一个单独的微型虚拟机中，拥有独立的操作系统和内核，并且有虚拟化层的安全隔离。

安全容器目前推荐的技术方案是Kata Containers，Kata Container 并不包含一个完整的操作系统，只有一个精简版的 Guest Kernel 运行着容器本身的应用，并且通过减少不必要的内存，尽量共享可以共享的内存来进一步减少内存的开销。另外，Kata Container 实现了 OCI 规范，可以直接使用 Docker 的镜像启动 Kata 容器，具有开销更小、秒级启动、安全隔离等许多优点。

如何提高服务器的安全性？

1、系统漏洞的修复

安装好的系统都会有系统漏洞需要进行补丁，一些高危漏洞是需要我们及时补丁的, 否则黑客容易利用漏洞进行服务器攻击。

2、系统账号优化

我们服务器的密码需要使用强口令，同时有一些来宾账户例如guest一定要禁用掉。

3、目录权限优化

对于不需要执行与写入权限的服务器我们要进行权限修改，确保不把不该出现的的权限暴露给攻击者让攻击者有机可趁。

例如我们的windows文件夹权限，我们给的就应该尽可能的少，对于用户配置信息文件夹，不要给予everyone权限。

4、数据库优化

针对数据密码和数据库端口访问都要进行优化，不要将数据库暴露在公网访问环境。

5、系统服务优化

去除一些不必要的系统服务，可以优化我们系统性能，同时优化系统服务可以提升系统安全性。

6、注册表优化

注册表优化可以提升网络并发能力，去除不必要的端口，帮助抵御snmp攻击，优化网络，是我们优化服务器不可缺少的环节。

7、扫描垃圾文件

垃圾文件冗余可能会造成我们的服务器卡顿，硬盘空间不足，需要我们定期进行清理。

本文名称：存储服务器的容器安全 存储服务器的容器安全性怎么样
分享URL：http://kswjz.com/article/dopgoeg.html