保障IDC安全：分布式HIDS集群架构设计
1. 转载自美团技术团队
2. 背景
近年来，互联网上安全事件频发，企业信息安全越来越受到重视，而IDC服务器安全又是纵深防御体系中的重要一环。保障IDC安全，常用的是基于主机型入侵检测系统Host-based Intrusion Detection System，即HIDS。在HIDS面对几十万台甚至上百万台规模的IDC环境时，系统架构该如何设计呢？复杂的服务器环境，网络环境，巨大的数据量给我们带来了哪些技术挑战呢？
3. 需求描述
对于HIDS产品，我们安全部门的产品经理提出了以下需求：
- 满足50W-100W服务器量级的IDC规模。
- 部署在高并发服务器生产环境，要求Agent低性能低损耗。
- 广泛的部署兼容性。
- 偏向应用层和用户态入侵检测（可以和内核态检测部分解耦）。
- 针对利用主机Agent排查漏洞的最急需场景提供基本的能力，可以实现海量环境下快速查找系统漏洞。
- Agent跟Server的配置下发通道安全。
- 配置信息读取写入需要鉴权。
- 配置变更历史记录。
- Agent插件具备自更新功能。
4. 分析需求
- 首先，服务器业务进程优先级高，HIDS Agent进程自己可以终止，但不能影响宿主机的主要业务，这是第一要点，那么业务需要具备熔断功能，并具备自我恢复能力。
- 其次，进程保活、维持心跳、实时获取新指令能力，百万台Agent的全量控制时间一定要短。举个极端的例子，当Agent出现紧急情况，需要全量停止时，那么全量停止的命令下发，需要在1-2分钟内完成，甚至30秒、20秒内完成。这些将会是很大的技术挑战。
- 还有对配置动态更新，日志级别控制，细分精确控制到每个Agent上的每个HIDS子进程，能自由地控制每个进程的启停，每个Agent的参数，也能精确的感知每台Agent的上线、下线情况。
- 同时，Agent本身是安全Agent，安全的因素也要考虑进去，包括通信通道的安全性，配置管理的安全性等等。
- 最后，服务端也要有一致性保障、可用性保障，对于大量Agent的管理，必须能实现任务分摊，并行处理任务，且保证数据的一致性。考虑到公司规模不断地扩大，业务不断地增多，特别是美团和大众点评合并后，面对的各种操作系统问题，产品还要具备良好的兼容性、可维护性等。
- 总结下来，产品架构要符合以下特性：
- 集群高可用。
- 分布式，去中心化。
- 配置一致性，配置多版本可追溯。
- 分治与汇总。
- 兼容部署各种Linux 服务器，只维护一个版本。
- 节省资源，占用较少的CPU、内存。
- 精确的熔断限流。
- 服务器数量规模达到百万级的集群负载能力。
5. 技术难点：
在列出产品需要实现的功能点、技术点后，再来分析下遇到的技术挑战，包括不限于以下几点：
- 资源限制，较小的CPU、内存。
- 五十万甚至一百万台服务器的Agent处理控制问题。
- 量级大了后，集群控制带来的控制效率，响应延迟，数据一致性问题。
- 量级大了后，数据传输对整个服务器内网带来的流量冲击问题。
- 量级大了后，运行环境更复杂，Agent异常表现的感知问题。
- 量级大了后，业务日志、程序运行日志的传输、存储问题，被监控业务访问量突增带来监控数据联突增，对内网带宽，存储集群的爆发压力问题。
我们可以看到，技术难点几乎都是服务器到达一定量级带来的，对于大量的服务，集群分布式是业界常见的解决方案。
6. 架构设计与技术选型
对于管理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的产品。
7. 满足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的分布式集群管理。
8. 分布式HIDS集群架构图
9. 编程语言选择
考虑到公司服务器量大，业务复杂，需求环境多变，操作系统可能包括各种Linux以及Windows等。为了保证系统的兼容性，我们选择了Golang作为开发语言，它具备以下特点：
- 可以静态编译，直接通过syscall来运行，不依赖libc，兼容性高，可以在所有Linux上执行，部署便捷。
- 静态编译语言，能将简单的错误在编译前就发现。
- 具备良好的GC机制，占用系统资源少，开发成本低。
- 容器化的很多产品都是Golang编写，比如Kubernetes、Docker等。
- etcd项目也是Golang编写，类库、测试用例可以直接用，SDK支持快速。
- 良好的CSP并发模型支持，高效的协程调度机制。
10. 产品架构大方向
- HIDS产品研发完成后，部署的服务都运行着各种业务的服务器，业务的重要性排在第一，我们产品的功能排在后面。为此，确定了几个产品的大方向：
- 高可用，数据一致，可横向扩展。
- 容灾性好，能应对机房级的网络故障。
- 兼容性好，只维护一个版本的Agent。
- 依赖低，不依赖任何动态链接库。
- 侵入性低，不做Hook，不做系统类库更改。
- 熔断降级可靠，宁可自己挂掉，也不影响业务 。
11. 框架设计
如上图，在框架的设计上，封装常用类库，抽象化定义Interface，剥离etcd Client，全局化Logger，抽象化App的启动、退出方法。使得各模块（以下简称App）只需要实现自己的业务即可，可以方便快捷的进行逻辑编写，无需关心底层实现、配置来源、重试次数、熔断方案等等。
后面不再copy，感兴趣请参考原文