保障idc安全:分布式hids集群架构设计

up::终端基础设施 Endpoint Infrastructure-EDR

  • 转载自美团技术团队

    • https://tech.meituan.com/2019/01/17/distributed-hids-cluster-architecture-design.html
  • 背景

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

    • 对于HIDS产品,我们安全部门的产品经理提出了以下需求:
      • 满足50W-100W服务器量级的IDC规模。
      • 部署在高并发服务器生产环境,要求Agent低性能低损耗。
      • 广泛的部署兼容性。
      • 偏向应用层和用户态入侵检测(可以和内核态检测部分解耦)。
      • 针对利用主机Agent排查漏洞的最急需场景提供基本的能力,可以实现海量环境下快速查找系统漏洞。
      • Agent跟Server的配置下发通道安全。
      • 配置信息读取写入需要鉴权。
      • 配置变更历史记录。
      • Agent插件具备自更新功能。
  • 分析需求

    • 首先,服务器业务进程优先级高,HIDS Agent进程自己可以终止,但不能影响宿主机的主要业务,这是第一要点,那么业务需要具备熔断功能,并具备自我恢复能力。
    • 其次,进程保活、维持心跳、实时获取新指令能力,百万台Agent的全量控制时间一定要短。举个极端的例子,当Agent出现紧急情况,需要全量停止时,那么全量停止的命令下发,需要在1-2分钟内完成,甚至30秒、20秒内完成。这些将会是很大的技术挑战。
    • 还有对配置动态更新,日志级别控制,细分精确控制到每个Agent上的每个HIDS子进程,能自由地控制每个进程的启停,每个Agent的参数,也能精确的感知每台Agent的上线、下线情况。
    • 同时,Agent本身是安全Agent,安全的因素也要考虑进去,包括通信通道的安全性,配置管理的安全性等等。
    • 最后,服务端也要有一致性保障、可用性保障,对于大量Agent的管理,必须能实现任务分摊,并行处理任务,且保证数据的一致性。考虑到公司规模不断地扩大,业务不断地增多,特别是美团和大众点评合并后,面对的各种操作系统问题,产品还要具备良好的兼容性、可维护性等。
    • 总结下来,产品架构要符合以下特性:
      • 集群高可用。
      • 分布式,去中心化。
      • 配置一致性,配置多版本可追溯。
      • 分治与汇总。
      • 兼容部署各种Linux 服务器,只维护一个版本。
      • 节省资源,占用较少的CPU、内存。
      • 精确的熔断限流。
      • 服务器数量规模达到百万级的集群负载能力。
  • 技术难点:

    • 在列出产品需要实现的功能点、技术点后,再来分析下遇到的技术挑战,包括不限于以下几点:
      • 资源限制,较小的CPU、内存。
      • 五十万甚至一百万台服务器的Agent处理控制问题。
      • 量级大了后,集群控制带来的控制效率,响应延迟,数据一致性问题。
      • 量级大了后,数据传输对整个服务器内网带来的流量冲击问题。
      • 量级大了后,运行环境更复杂,Agent异常表现的感知问题。
      • 量级大了后,业务日志、程序运行日志的传输、存储问题,被监控业务访问量突增带来监控数据联突增,对内网带宽,存储集群的爆发压力问题。
    • 我们可以看到,技术难点几乎都是服务器到达一定量级带来的,对于大量的服务,集群分布式是业界常见的解决方案。
  • 架构设计与技术选型

    • 对于管理Agent的服务端来说,要实现高可用、容灾设计,那么一定要做多机房部署,就一定会遇到数据一致性问题。那么数据的存储,就要考虑分布式存储组件。 分布式数据存储中,存在一个定理叫CAP定理
    • CAP的解释
      • 关于CAP定理,分为以下三点:
        • 一致性(Consistency):分布式数据库的数据保持一致。
        • 可用性(Availability):任何一个节点宕机,其他节点可以继续对外提供服务。
        • 分区容错性(网络分区)Partition Tolerance:一个数据库所在的机器坏了,如硬盘坏了,数据丢失了,可以添加一台机器,然后从其他正常的机器把备份的数据同步过来。
      • 根据定理,分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP定理的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致,即丧失了Consistency。如果为了保证数据一致性,将分区一侧的节点设置为不可用,那么又丧失了Availability。除非两个节点可以互相通信,才能既保证Consistency又保证Availability,这又会导致丧失Partition Tolerance。
      • 参见:CAP Theorem
    • CAP的选择
      • 为了容灾上设计,集群节点的部署,会选择的异地多机房,所以 「Partition tolerance」是不可能避免的。那么可选的是 APCP
      • 在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 比较符合我们要求。很多大型公司都在使用,比如KubernetesAWSOpenStackAzureGoogle CloudHuawei Cloud等,并且etcd的社区支持非常好。基于这几点因素,我们选择etcd作为HIDS的分布式集群管理。
  • 分布式HIDS集群架构图

  • 编程语言选择

    • 考虑到公司服务器量大,业务复杂,需求环境多变,操作系统可能包括各种Linux以及Windows等。为了保证系统的兼容性,我们选择了Golang作为开发语言,它具备以下特点:
      • 可以静态编译,直接通过syscall来运行,不依赖libc,兼容性高,可以在所有Linux上执行,部署便捷。
      • 静态编译语言,能将简单的错误在编译前就发现。
      • 具备良好的GC机制,占用系统资源少,开发成本低。
      • 容器化的很多产品都是Golang编写,比如Kubernetes、Docker等。
      • etcd项目也是Golang编写,类库、测试用例可以直接用,SDK支持快速。
      • 良好的CSP并发模型支持,高效的协程调度机制。
  • 产品架构大方向

    • HIDS产品研发完成后,部署的服务都运行着各种业务的服务器,业务的重要性排在第一,我们产品的功能排在后面。为此,确定了几个产品的大方向:
      • 高可用,数据一致,可横向扩展。
      • 容灾性好,能应对机房级的网络故障。
      • 兼容性好,只维护一个版本的Agent。
      • 依赖低,不依赖任何动态链接库。
      • 侵入性低,不做Hook,不做系统类库更改。
      • 熔断降级可靠,宁可自己挂掉,也不影响业务 。
  • 框架设计

    • 如上图,在框架的设计上,封装常用类库,抽象化定义Interface,剥离etcd Client,全局化Logger,抽象化App的启动、退出方法。使得各模块(以下简称App)只需要实现自己的业务即可,可以方便快捷的进行逻辑编写,无需关心底层实现、配置来源、重试次数、熔断方案等等。
  • 后面不再赘述,感兴趣请参考原文

Notes mentioning this note