以Docker为代表的容器技术，直接运行于宿主机操作系统内核，因此对于容器安全，很多人会有着这样的疑问：EDR（Endpoint Detection and Response）等主机安全方案，能否直接解决容器安全的问题？针对这样的疑问，本文将结合容器安全的建设思路，简要分析其与EDR之间的一些异同。
摘要
以Docker为代表的容器技术，直接运行于宿主机操作系统内核，因此对于容器安全，很多人会有着这样的疑问：EDR（Endpoint Detection and Response）等主机安全方案，能否直接解决容器安全的问题？针对这样的疑问，本文将结合容器安全的建设思路，简要分析其与EDR之间的一些异同。
1. 概述
近两年，随着容器技术越来越多的被大家所青睐，容器安全也逐渐得到了广泛的关注和重视。NeuVector、Aqua、Twistlock等初创公司，陆续的推出了其容器安全的产品和解决方案。在国内，以绿盟科技为代表的安全厂商，也不断的在容器安全领域进行探索和尝试。
对于容器环境，或者是容器云，其本质是云计算的一种实现方式，我们可以将其称为PaaS或者CaaS。因此，其整体的安全建设思路，是遵循云计算安全架构的。
容器云环境的安全建设，如果暂时抛开物理安全的话，可以粗略分为两个主要方面：一方面是容器云内部的安全建设，这包括基础设备的安全、东西向网络的安全、管理平台的安全、虚拟化安全以及数据安全等；另一方面就是容器云内外之间的网络通信安全，也就是通常讲的南北向网络安全。
这样，对于容器云的安全方案，可以分别从这两个方面进行设计：对于南北向的网络安全，可以通过安全资源池引流的方式，实现相应的安全检测与防护，这也是很多安全厂商在云安全解决方案上的主要实现方式。对于容器云内部的安全，可以通过特定的容器安全产品进行实现。最后将这两部分统一接入云安全的集中管理系统，进行统一的安全管理和运营。
2. 容器安全的核心问题
早在2018年11月，我们发布了《绿盟科技容器安全技术报告》[1]，报告中详细阐述了容器环境可能面临的安全威胁以及相应的处置方式。这里我们将容器安全的核心问题做个简单的回顾和总结。
概括来说，容器/容器云安全，可以包括以下四个类别：
第一，就是容器环境基础设施的安全性，比如主机上的安全配置是否会影响到其上面运行的容器，主机上的安全漏洞是否会影响到容器，主机上的恶意进程是否会影响到容器，容器内的进程是否可以利用到主机上的安全漏洞等。
第二，是容器的镜像安全，这里包括镜像中的软件是否存在安全漏洞，镜像在构建过程中是否存在安全风险，镜像在传输过程中是否被恶意篡改等。
第三，是容器的运行时安全，比如运行的容器间隔离是否充分，容器间的通信是否是安全的，容器内的恶意程序是否会影响到主机或者其它容器，容器的资源使用情况是否是安全的等。
第四，是整个容器生态的安全性，比如Docker/Kubernetes自身的安全性如何，ServiceMesh/Serverless对容器安全有什么影响，容器中安全密钥的管理和传统环境有什么不同，容器化后的数据隐私保护跟传统的数据隐私保护是否一致等。
从上述容器安全的核心问题来看，镜像的概念相对来说是容器所特有的，因此对于容器的镜像安全，EDR是一定不会覆盖的。另外就是容器的生态安全，这块更多的是容器相关的技术栈带来的安全机遇和挑战，因此典型的EDR产品肯定也是无能为力的。
行文至此，开篇所提出的问题“EDR等主机安全方案，能否直接解决容器安全的问题？”就已经有了初步的答案：肯定是不可以的。
首先，来看一下，当前部分厂商专门针对容器环境所提供的安全产品和安全服务都能提供什么样的安全能力，以及技术架构是什么样的。
3. 容器安全产品/服务
首先以Google GCP（Google Cloud Platform）[2]上所提供的容器安全（Container Security）服务能力为例，具体分析当前容器安全产品/服务主要实现了什么样的安全能力。
3.1 Google Container Security
Google在其GCP上保障容器环境的安全时，主要分为了三个方面：
（1）基础架构安全。主要是指容器管理平台能够提供的基本安全功能，确保开发者拥有所需的工具来安全的构建容器化服务，这些功能通常内置于Kubernetes等容器编排系统中。比如使用IAM来管理对项目的访问权限、使用基于角色的访问权限控制（RBAC）功能来管理对集群和命名空间的访问权限、日志审计、网络隔离、基础设施ISO合规等。
（2）软件供应链安全。主要就是前文所提到的容器镜像安全，包括安全的基础镜像维护、CVE漏洞扫描、镜像准入检测等。
（3）运行时安全。确保安全响应团队能够检测到环境中运行的容器所面临的安全威胁，并做出响应。这些功能通常内置于安全运营工具中。比如Google通过集成了Stackdriver实现日志分析、通过集成合作伙伴Aqua Security、Capsule8、StackRox、Sysdig Secure、Twistlock等安全产品，实现异常活动的检测、使用容器运行时沙盒gVisor更好的隔离容器。
下面以其运行时安全的合作伙伴Aqua Security为例，简要分析其所实现的安全能力以及技术架构。
3.2 Aqua Security
Aqua Security[3]是一家2015年成立的以色列容器安全平台厂商，在DevOps、微服务等业务平台中，为容器化环境提供先进的安全方案。
3.2.1 主要安全能力
（1）漏洞管理。扫描容器镜像和无服务器功能，查找已知的漏洞、嵌入的密钥、配置和权限问题、恶意软件和开源许可。
（2）运行时防护。通过对镜像的准入控制，防止不受信任的镜像运行，并确保容器保持不变，防止对运行中的容器进行任何更改。可以基于自定义策略和机器学习的行为配置文件，实时监视和控制容器的活动。
（3）密钥管理。在运行时可以安全的将密钥传递给容器，在传输和存储时进行加密，将它们加载到内存中，而不需要在磁盘上进行持久化存储，在磁盘上它们只对需要它们的容器可见。
（4）容器防火墙。自动发现容器间网络连接，并得到参考的上下文防火墙规则，通过白名单确定合法的连接，阻止或警告未经授权的网络活动。可以与流行的网络插件（如Weave或Flannel）和服务网格（如Istio）无缝连接。
（5）合规和审计。PCI-DSS、HIPAA之类的法规合规性检测，以及NIST、CIS的最佳实践检测。提供细粒度事件日志记录，并且集成多种日志分析和SIEM工具，如Splunk、ArcSight等，可以集中管理审计日志。
3.2.2 实现架构
如下图所示是Aqua Security官方提供的系统参考架构图，结合另外一款容器安全产品的参考架构（图5），可以看出，整个系统基本都是由平台和探针两部分组成。
在平台侧，一方面实现相关的安全管理控制的能力，另一方面实现数据相关的分析和智能化能力。
在探针侧，则主要通过在每个容器运行的主机上部署一个安全探针，通过这个探针进行相关的安全策略执行以及相关数据的采集（暂不讨论Serverless）。据笔者了解，这个分布式的探针，通常会有两种体现形态，一种是以特权容器的方式融合在容器环境的管理平台中，另一种是主机安全常见的部署Agent方式。从本质上来讲，两种形态只是部署和管理方式有所区别。
4. EDR
既然现有的EDR产品不能直接用来解决容器安全的所有问题，那么对于容器环境面临的前述安全问题，EDR能否解决其中的一部分呢？
先看一下EDR的定义是什么？典型的EDR产品又能做些什么？
Gartner对于EDR给出了如下的定义：
| EDR tools provide an ability to analyze and search detailed, current and historic endpoint data for traces of malicious activity and bring the high-risk data to an analyst’s attention with additional capabilities to actively respond to those activities if necessary. |
EDR工具集提供一种分析/检索更详细/实时/历史的终端数据能力，进而发现恶意活动的痕迹，让安全分析师关注高风险的数据，并且在必要时积极的进行响应。
Gartner的这个定义，看上去似乎有些抽象，简单一点的解释就是：通过收集终端上的各种数据，在这些数据中分析并发现恶意的活动，进而采取相应的防御手段。那么都会收集什么样的数据？收集到了这些数据又能发现什么样的恶意行为？
下面从EDR典型的设计架构开始，进行具体的解释。
4.1 典型架构
下图展示了Gartner给出的典型EDR架构，其主要包括两个部分：一部分是部署在待防护终端上的代理（Agent），这里的终端既可以是虚拟化的云主机，也可以是物理的服务器主机，还可以是办公的PC机，当然甚至也可以是更轻量的IoT终端设备（跟容器的可运行环境基本是一致的）；另一部分则是控制平台，这里的控制平台既可以通过本地的集中化方式部署实现，也可以部署在云端，或者是采用云端和本地化混合的部署方式，不同的安全能力部署在不同的位置。
4.2 代理都收集什么样的数据？
- 终端设备的基本元数据。包括CPU、内存、网卡（IP、MAC）、操作系统、安装软件、硬件数据、Device数据等。
- 网络数据。包括终端设备上的DNS和ARP表以及其它实时网络数据、开放的端口以及相关的进程数据、终端的网络连接数据、可访问终端的URL数据等。
- 运行时数据。包括终端上运行的进程/线程以及其对应的元数据、用户登录注销数据、进程间通信（IPC）数据、进程行为数据（例如数据读写）等。
- 存储数据。文件（通常只包含特定的文件或者可执行文件）以及文件元数据（比如文件名/大小/类型、校验和等）、文件变更信息、syslog、主引导记录（MBR）信息等。
- 其它数据。比如加载的DLL、激活的设备驱动程序、已加载的内核模块、CMD或者PowerShell历史命令等数据。
4.3 EDR能发现什么恶意行为？
基于上述收集到的数据，EDR通常可以应用于以下安全场景：
（1）主机风险检测。结合多种安全基线与规范要求，通过账户、网络、进程、系统配置等多维度风险检测，系统全面的发现不符合安全管理规范的主机。
（2）可疑行为检测。通过实时监控主机关键的风险入口，结合威胁情报以及相关安全规则，对端口扫描攻击、暴力破解攻击、恶意脚本攻击、系统漏洞攻击、Webshell攻击等可疑行为进行高效快速的检测发现。
（3）威胁狩猎。平台收集的各种层面的数据，可以提供关于主机健康状况的大量信息。通过正确的筛选、挖掘，利用这些数据可以发现、追踪到更多潜在的威胁行为，主动的进行威胁捕获。
（4）阻止恶意行为。例如主机的微隔离，通过控制主机的进出站流量，实现对异常主机的隔离。
4.4 小结：对比容器安全，有哪些是无法满足的？
根据前文对于容器安全核心问题的描述，以及EDR的功能概述，除了容器的镜像安全和容器生态安全之外，在主机安全以及容器运行时安全方面，EDR确实能够不同程度的提供相关的安全检测和防护能力。
相同点：
（1）从功能层面，容器安全和EDR都要求实现其对应主机的安全，包括资源层面、权限层面、网络层面等多个方面，因此，对于容器安全来说，EDR产品可以100%的进行功能的复用，保障容器环境的主机安全。
（2）从技术层面，在二者的主流技术实现路径上，均采用了“平台+探针”的技术架构，可以以最小的成本开销，实现安全能力的复用和整合。
不同点：
二者之间的不同点，主要来源于容器环境利用namespace和cgroup做了一层资源的隔离，因此：
（1）当前EDR所监测的数据，仅限于主机层面，对于容器内部的行为和活动，是没有覆盖到的，比如容器内进程行为的监控、容器内用户权限的监控等。（具体可参考《解析容器进程管理》一文）
（2）在网络安全上，当前EDR更关注于主机的进出站网络流量，也就是主机物理网卡上的流量，而在容器环境中，还有相当大比例的网络通信存在于主机内部的容器之间，因此，这种容器间的东西向网络安全防护，当前EDR也是无法实现的。
（3）权限管理。容器环境之上，通常运行的基于微服务架构的业务应用，因此有着复杂的权限管理以及访问控制策略，虽然这些通常是由容器业务平台进行设计和实现，但是作为安全服务，是需要有能力对其进行监控和异常检测的。而EDR在这方面几乎还只停留在主机资源的权限管理上，这一点也是无法满足需求的。
（4）对于容器内应用的密钥管理、密钥隐藏等容器业务强相关的安全需求，EDR也是无法满足的。
5. 总结
本文重点围绕“EDR等主机安全方案，能否直接解决容器安全？”这个问题，分别从容器安全的几个核心问题、当前容器安全产品和服务所提供的安全能力，以及EDR产品与容器安全需求的吻合度这几个方面来进行了具体论述。
考虑到容器环境在技术实现上的特点，通过EDR实现容器安全确实有着一定的优势。但是考虑到容器环境又有着很多特殊性，在安全上还有很多特定的需求，因此，直接利用EDR去应对容器安全的问题，还是远远不够的。
比较好的解决办法就是，结合各家之所长，一方面有效的利用EDR在主机安全上可以做到的全面、深入的安全检测能力；另一方面，结合容器环境特定的需求，实现安全能力的有效扩展和延伸。这样，就可以尽可能高效的实现容器环境的安全防护了。
参考文献
[1] 2018绿盟科技容器安全技术报告，http://www.nsfocus.com.cn/content/details_62_2852.html
[2] Google Container Security，https://cloud.google.com/containers/security/
[3] Aqua Security，https://www.aquasec.com/