保障IDC安全：分布式HIDS集群架构设计

背景

近年来，互联网上安全事件频发，企业信息安全越来越受到重视，而IDC服务器安全又是纵深防御体系中的重要一环。保障IDC安全，常用的是基于主机型入侵检测系统Host-based Intrusion Detection System，即HIDS。在HIDS面对几十万台甚至上百万台规模的IDC环境时，系统架构该如何设计呢？复杂的服务器环境，网络环境，巨大的数据量给我们带来了哪些技术挑战呢？

需求描述

对于HIDS产品，我们安全部门的产品经理提出了以下需求：

1.满足50W-100W服务器量级的IDC规模。

2.部署在高并发服务器生产环境，要求Agent低性能低损耗。

3.广泛的部署兼容性。

4.偏向应用层和用户态入侵检测（可以和内核态检测部分解耦）。

5.针对利用主机Agent排查漏洞的最急需场景提供基本的能力，可以实现海量环境下快速查找系统漏洞。

6.Agent跟Server的配置下发通道安全。

7.配置信息读取写入需要鉴权。

8.配置变更历史记录。

9.Agent插件具备自更新功能。

分析需求

首先，服务器业务进程优先级高，HIDS Agent进程自己可以终止，但不能影响宿主机的主要业务，这是第一要点，那么业务需要具备熔断功能，并具备自我恢复能力。

其次，进程保活、维持心跳、实时获取新指令能力，百万台Agent的全量控制时间一定要短。举个极端的例子，当Agent出现紧急情况，需要全量停止时，那么全量停止的命令下发，需要在1-2分钟内完成，甚至30秒、20秒内完成。这些将会是很大的技术挑战。

还有对配置动态更新，日志级别控制，细分精确控制到每个Agent上的每个HIDS子进程，能自由地控制每个进程的启停，每个Agent的参数，也能精确的感知每台Agent的上线、下线情况。

同时，Agent本身是安全Agent，安全的因素也要考虑进去，包括通信通道的安全性，配置管理的安全性等等。

最后，服务端也要有一致性保障、可用性保障，对于大量Agent的管理，必须能实现任务分摊，并行处理任务，且保证数据的一致性。考虑到公司规模不断地扩大，业务不断地增多，特别是美团和大众点评合并后，面对的各种操作系统问题，产品还要具备良好的兼容性、可维护性等。

总结下来，产品架构要符合以下特性：

1.集群高可用。

2.分布式，去中心化。

3.配置一致性，配置多版本可追溯。

4.分治与汇总。

5.兼容部署各种Linux 服务器，只维护一个版本。

6.节省资源，占用较少的CPU、内存。

7.精确的熔断限流。

8.服务器数量规模达到百万级的集群负载能力。

技术难点

在列出产品需要实现的功能点、技术点后，再来分析下遇到的技术挑战，包括不限于以下几点：

• 资源限制，较小的CPU、内存。

• 五十万甚至一百万台服务器的Agent处理控制问题。

• 量级大了后，集群控制带来的控制效率，响应延迟，数据一致性问题。

• 量级大了后，数据传输对整个服务器内网带来的流量冲击问题。

• 量级大了后，运行环境更复杂，Agent异常表现的感知问题。

• 量级大了后，业务日志、程序运行日志的传输、存储问题，被监控业务访问量突增带来监控数据联动突增，对内网带宽，存储集群的爆发压力问题。

我们可以看到，技术难点几乎都是服务器到达一定量级带来的，对于大量的服务，集群分布式是业界常见的解决方案。

架构设计与技术选型

对于管理Agent的服务端来说，要实现高可用、容灾设计，那么一定要做多机房部署，就一定会遇到数据一致性问题。那么数据的存储，就要考虑分布式存储组件。 分布式数据存储中，存在一个定理叫CAP定理：

CAP的解释

关于CAP定理，分为以下三点：

• 一致性（Consistency）：分布式数据库的数据保持一致。

• 可用性（Availability）：任何一个节点宕机，其他节点可以继续对外提供服务。

• 分区容错性（网络分区）Partition Tolerance：一个数据库所在的机器坏了，如硬盘坏了，数据丢失了，可以添加一台机器，然后从其他正常的机器把备份的数据同步过来。

根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP定理的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了Consistency。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了Availability。除非两个节点可以互相通信，才能既保证Consistency又保证Availability，这又会导致丧失Partition Tolerance。

参见：CAP Theorem

CAP的选择

为了容灾上设计，集群节点的部署，会选择的异地多机房，所以 「Partition tolerance」是不可能避免的。那么可选的是 AP 与 CP。

在HIDS集群的场景里，各个Agent对集群持续可用性没有非常强的要求，在短暂时间内，是可以出现异常，出现无法通讯的情况。但最终状态必须要一致，不能存在集群下发关停指令，而出现个别Agent不听从集群控制的情况出现。所以，我们需要一个满足 CP 的产品。

满足CP的产品选择

在开源社区中，比较出名的几款满足CP的产品，比如etcd、ZooKeeper、Consul等。我们需要根据几款产品的特点，根据我们需求来选择符合我们需求的产品。

插一句，网上很多人说Consul是AP产品，这是个错误的描述。既然Consul支持分布式部署，那么一定会出现「网络分区」的问题， 那么一定要支持「Partition tolerance」。另外，在consul的官网上自己也提到了这点 Consul uses a CP architecture, favoring consistency over availability.

Consul is opinionated in its usage while Serf is a more flexible and general purpose tool. In CAP terms, Consul uses a CP architecture, favoring consistency over availability. Serf is an AP system and sacrifices consistency for availability. This means Consul cannot operate if the central servers cannot form a quorum while Serf will continue to function under almost all circumstances.

etcd、ZooKeeper、Consul对比

借用etcd官网上etcd与ZooKeeper和Consul的比较图。

在我们HIDS Agent的需求中，除了基本的服务发现 、配置同步 、配置多版本控制 、变更通知等基本需求外，我们还有基于产品安全性上的考虑，比如传输通道加密、用户权限控制、角色管理、基于Key的权限设定等，这点 etcd比较符合我们要求。很多大型公司都在使用，比如Kubernetes、AWS、OpenStack、Azure、Google Cloud、Huawei Cloud等，并且etcd的社区支持非常好。基于这几点因素，我们选择etcd作为HIDS的分布式集群管理。

选择etcd

对于etcd在项目中的应用，我们分别使用不同的API接口实现对应的业务需求，按照业务划分如下：

• Watch机制来实现配置变更下发，任务下发的实时获取机制。

• 脑裂问题在etcd中不存在，etcd集群的选举，只有投票达到 N/2+1 以上，才会选做Leader，来保证数据一致性。另外一个网络分区的Member节点将无主。