背景
近年来,互联网上安全事件频发,企业信息安全越来越受到重视,而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定理
:
![](https://i-blog.csdnimg.cn/blog_migrate/058590e14f2590a4400240238448f827.png)
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的比较图。
![](https://i-blog.csdnimg.cn/blog_migrate/401f3893c7f5744adbe175f46cb4ff81.jpeg)
在我们HIDS Agent的需求中,除了基本的服务发现
、配置同步
、配置多版本控制
、变更通知
等基本需求外,我们还有基于产品安全性上的考虑,比如传输通道加密
、用户权限控制
、角色管理
、基于Key的权限设定
等,这点 etcd
比较符合我们要求。很多大型公司都在使用,比如Kubernetes
、AWS
、OpenStack
、Azure
、Google Cloud
、Huawei Cloud
等,并且etcd
的社区支持非常好。基于这几点因素,我们选择etcd
作为HIDS的分布式集群管理。
选择etcd
对于etcd在项目中的应用,我们分别使用不同的API接口实现对应的业务需求ÿ