网站建设维护工作职责,重庆网站建设沛宣网络,个人网站做重定向图片,广东网站系统建设背景 近年来#xff0c;互联网上安全事件频发#xff0c;企业信息安全越来越受到重视#xff0c;而IDC服务器安全又是纵深防御体系中的重要一环。保障IDC安全#xff0c;常用的是基于主机型入侵检测系统Host-based Intrusion Detection System#xff0c;即HIDS。在HIDS面… 背景 近年来互联网上安全事件频发企业信息安全越来越受到重视而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」是不可能避免的。那么可选的是 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/21 以上才会选做Leader来保证数据一致性。另外一个网络分区的Member节点将无主。语言亲和性也是Golang开发的Client SDK库稳定可用。Key存储的数据结构支持范围性的Key操作。User、Role权限设定不同读写权限来控制Key操作避免其他客户端修改其他Key的信息。TLS来保证通道信息传递安全。Txn分布式事务API配合Compare API来确定主机上线的Key唯一性。Lease租约机制过期Key释放更好的感知主机下线信息。etcd底层Key的存储为BTree结构查找时间复杂度为O㏒n百万级甚至千万级Key的查找耗时区别不大。etcd Key的设计 前缀按角色设定 Server配置下发使用 /hids/server/config/{hostname}/master。Agent注册上线使用 /hids/agent/master/{hostname}。Plugin配置获取使用 /hids/agent/config/{hostname}/plugin/ID/conf_name。Server Watch /hids/server/config/{hostname}/master实现Agent主机上线的瞬间感知。Agent Watch /hids/server/config/{hostname}/来获取配置变更任务下发。Agent注册的Key带有Lease Id并启用keepalive下线后瞬间感知。 异常下线会有1/3的keepalive时间延迟 关于Key的权限根据不同前缀设定不同Role权限。赋值给不同的User来实现对Key的权限控制。 etcd集群管理 在etcd节点容灾考虑考虑DNS故障时节点会选择部署在多个城市多个机房以我们服务器机房选择来看在大部分机房都有一个节点综合承载需求我们选择了N台服务器部署在个别重要机房来满足负载、容灾需求。但对于etcd这种分布式一致性强的组件来说每个写操作都需要N/2-1的节点确认变更才会将写请求写入数据库中再同步到各个节点那么意味着节点越多需要确认的网络请求越多耗时越多反而会影响集群节点性能。这点我们后续将提升单个服务器性能以及牺牲部分容灾性来提升集群处理速度。 客户端填写的IP列表包含域名、IP。IP用来规避DNS故障域名用来做Member节点更新。最好不要使用Discover方案避免对内网DNS服务器产生较大压力。 同时在配置etcd节点的地址时也要考虑到内网DNS故障的场景地址填写会混合IP、域名两种形式。 IP的地址便于规避内网DNS故障。域名形式便于做个别节点更替或扩容。我们在设计产品架构时为了安全性开启了TLS证书认证当节点变更时证书的生成也同样要考虑到上面两种方案的影响证书里需要包含固定IP以及DNS域名范围的两种格式。 etcd Cluster节点扩容 节点扩容官方手册上也有完整的方案etcd的Client里实现了健康检测与故障迁移能自动的迁移到节点IP列表中的其他可用IP。也能定时更新etcd Node List对于etcd Cluster的集群节点变更来说不存在问题。需要我们注意的是TLS证书的兼容。 分布式HIDS集群架构图 集群核心组件高可用所有Agent、Server都依赖集群都可以无缝扩展且不影响整个集群的稳定性。即使Server全部宕机也不影响所有Agent的继续工作。 在以后Server版本升级时Agent不会中断也不会带来雪崩式的影响。etcd集群可以做到单节点升级一直到整个集群升级各个组件全都解耦。 编程语言选择 考虑到公司服务器量大业务复杂需求环境多变操作系统可能包括各种Linux以及Windows等。为了保证系统的兼容性我们选择了Golang作为开发语言它具备以下特点 可以静态编译直接通过syscall来运行不依赖libc兼容性高可以在所有Linux上执行部署便捷。静态编译语言能将简单的错误在编译前就发现。具备良好的GC机制占用系统资源少开发成本低。容器化的很多产品都是Golang编写比如Kubernetes、Docker等。etcd项目也是Golang编写类库、测试用例可以直接用SDK支持快速。良好的CSP并发模型支持高效的协程调度机制。产品架构大方向 HIDS产品研发完成后部署的服务都运行着各种业务的服务器业务的重要性排在第一我们产品的功能排在后面。为此确定了几个产品的大方向 高可用数据一致可横向扩展。容灾性好能应对机房级的网络故障。兼容性好只维护一个版本的Agent。依赖低不依赖任何动态链接库。侵入性低不做Hook不做系统类库更改。熔断降级可靠宁可自己挂掉也不影响业务 。产品实现 篇幅限制仅讨论框架设计、熔断限流、监控告警、自我恢复以及产品实现上的主进程与进程监控。 框架设计 如上图在框架的设计上封装常用类库抽象化定义Interface剥离etcd Client全局化Logger抽象化App的启动、退出方法。使得各模块以下简称App只需要实现自己的业务即可可以方便快捷的进行逻辑编写无需关心底层实现、配置来源、重试次数、熔断方案等等。 沙箱隔离 考虑到子进程不能无限的增长下去那么必然有一个进程包含多个模块的功能各App之间既能使用公用底层组件Logger、etcd Client等又能让彼此之间互不影响这里进行了沙箱化处理各个属性对象仅在各App的sandbox里生效。同样能实现了App进程的性能熔断停止所有的业务逻辑功能但又能具有基本的自我恢复功能。 IConfig 对各App的配置抽象化处理实现IConfig的共有方法接口用于对配置的函数调用比如Check的检测方法检测配置合法性检测配置的最大值、最小值范围规避使用人员配置不在合理范围内的情况从而避免带来的风险。 框架底层用Reflect来处理JSON配置解析读取填写的配置项跟Config对象对比填充到对应Struct的属性上允许JSON配置里只填写变化的配置没填写的配置项则使用Config对应Struct的默认配置。便于灵活处理配置信息。 type IConfig interface {Check() error //检测配置合法性
}func ConfigLoad(confByte []byte, config IConfig) (IConfig, error) {
...
//反射生成临时的IConfigvar confTmp IConfigconfTmp reflect.New(reflect.ValueOf(config).Elem().Type()).Interface().(IConfig)
...//反射 confTmp 的属性confTmpReflect : reflect.TypeOf(confTmp).Elem()confTmpReflectV : reflect.ValueOf(confTmp).Elem()//反射config IConfigconfigReflect : reflect.TypeOf(config).Elem()configReflectV : reflect.ValueOf(config).Elem()
...for i 0; i num; i {//遍历处理每个FieldenvStructTmp : configReflect.Field(i)//根据配置中的项来覆盖默认值if envStructTmp.Type confStructTmp.Type {configReflectV.FieldByName(envStructTmp.Name).Set(confTmpReflectV.Field(i))Timer、Clock调度 在业务数据产生时很多地方需要记录时间时间的获取也会产生很多系统调用。尤其是在每秒钟产生成千上万个事件这些事件都需要调用获取时间接口进行clock_gettime等系统调用会大大增加系统CPU负载。 而很多事件产生时间的准确性要求不高精确到秒或者几百个毫秒即可那么框架里实现了一个颗粒度符合需求的比如100ms、200ms、或者1s等间隔时间更新的时钟即满足事件对时间的需求又减少了系统调用。 同样在有些Ticker场景中Ticker的间隔颗粒要求不高时也可以合并成一个Ticker减少对CPU时钟的调用。 Catcher 在多协程场景下会用到很多协程来处理程序对于个别协程的panic错误上层线程要有一个良好的捕获机制能将协程错误抛出去并能恢复运行不要让进程崩溃退出提高程序的稳定性。 抽象接口 框架底层抽象化封装Sandbox的Init、Run、Shutdown接口规范各App的对外接口让App的初始化、运行、停止等操作都标准化。App的模块业务逻辑不需要关注PID文件管理不关注与集群通讯不关心与父进程通讯等通用操作只需要实现自己的业务逻辑即可。App与框架的统一控制采用Context包以及Sync.Cond等条件锁作为同步控制条件来同步App与框架的生命周期同步多协程之间同步并实现App的安全退出保证数据不丢失。 限流 网络IO 限制数据上报速度。队列存储数据任务列表。大于队列长度数据丢弃。丢弃数据总数计数。计数信息作为心跳状态数据上报到日志中心用于数据对账。磁盘IO 程序运行日志对日志级别划分参考 /usr/include/sys/syslog.h LOG_EMERGLOG_ALERTLOG_CRITLOG_ERRLOG_WARNINGLOG_NOTICELOG_INFOLOG_DEBUG在代码编写时根据需求选用级别。级别越低日志量越大重要程度越低越不需要发送至日志中心写入本地磁盘。那么在异常情况排查时方便参考。 日志文件大小控制分2个文件每个文件不超过固定大小比如20M、50M等。并且对两个文件进行来回写避免日志写满磁盘的情况。 IRetry 为了加强Agent的鲁棒性不能因为某些RPC动作失败后导致整体功能不可用一般会有重试功能。Agent跟etcd Cluster也是TCP长连接HTTP2当节点重启更换或网络卡顿等异常时Agent会重连那么重连的频率控制不能是死循环般的重试。假设服务器内网交换机因内网流量较大产生抖动触发了Agent重连机制不断的重连又加重了交换机的负担造成雪崩效应这种设计必须要避免。 在每次重试后需要做一定的回退机制常见的指数级回退比如如下设计在规避雪崩场景下又能保障Agent的鲁棒性设定最大重试间隔也避免了Agent失控的问题。 //网络库重试Interface
type INetRetry interface {//开始连接函数Connect() errorString() string//获取最大重试次数GetMaxRetry() uint...
}
// 底层实现
func (this *Context) Retry(netRetry INetRetry) error {
...maxRetries netRetry.GetMaxRetry() //最大重试次数hashMod netRetry.GetHashMod()
for {if c.shutting {return errors.New(c.shutting is true...)}if maxRetries 0 retries maxRetries {c.logger.Debug(Abandoning %s after %d retries., netRetry.String(), retries)return errors.New(超过最大重试次数)}
...if e : netRetry.Connect(); e ! nil {delay 1 retriesif delay 0 {delay 1}delay delay * hashInterval
...c.logger.Emerg(Trying %s after %d seconds , retries:%d,error:%v, netRetry.String(), delay, retries, e)time.Sleep(time.Second * time.Duration(delay))}
...
}事件拆分 百万台IDC规模的Agent部署在任务执行、集群通讯或对宿主机产生资源影响时务必要错峰进行根据每台主机的唯一特征取模拆分执行避免造成雪崩效应。 监控告警 古时候行军打仗时提倡「兵马未动粮草先行」无疑是冷兵器时代决定胜负走向的重要因素。做产品也是尤其是大型产品要对自己运行状况有详细的掌控做好监控告警才能确保产品的成功。 对于etcd集群的监控组件本身提供了Metrics数据输出接口官方推荐了Prometheus来采集数据使用Grafana来做聚合计算、图标绘制我们做了Alert的接口开发对接了公司的告警系统实现IM、短信、电话告警。 Agent数量感知依赖Watch数字实时准确感知。 如下图来自产品刚开始灰度时的某一时刻截图Active Streams即etcd Watch的Key数量即为对应Agent数量每次灰度的产品数量。因为该操作是Agent直接与集群通讯并且每个Agent只Watch一个Key。且集群数据具备唯一性、一致性远比心跳日志的处理要准确的多。 etcd集群Members之间健康状况监控 用于监控管理etcd集群的状况包括Member节点之间数据同步Leader选举次数投票发起次数各节点的内存申请状况GC情况等对集群的健康状况做全面掌控。 程序运行状态监控告警 全量监控Agent的资源占用情况统计每天使用最大CPU\内存的主机Agent确定问题的影响范围及时做策略调整避免影响到业务服务的运行。并在后续版本上逐步做调整优化。 百万台服务器日志告警量非常大这个级别的告警信息的筛选、聚合是必不可少的。减少无用告警让研发运维人员疲于奔命也避免无用告警导致研发人员放松了警惕前期忽略个例告警先解决主要矛盾。 告警信息分级告警信息细分ID。根据告警级别过滤根据告警ID聚合告警来发现同类型错误。根据告警信息的所在机房、项目组、产品线等维度来聚合告警来发现同类型错误。数据采集告警 单机数据数据大小、总量的历史数据对比告警。按机房、项目组、产品线等维度的大小、总量等维度的历史数据对比告警。数据采集大小、总量的对账功能判断经过一系列处理流程的日志是否丢失的监控告警。熔断 针对单机Agent使用资源大小的阈值熔断CPU使用率连续N次触发大于等于5%则进行保护性熔断退出所有业务逻辑以保护主机的业务程序优先。Master进程进入空闲状态等待第二次时间Ticker到来决定是否恢复运行。各个App基于业务层面的监控熔断策略。灰度管理 在前面的配置管理中的etcd Key设计里已经细分到每个主机即每个Agent一个Key。那么服务端的管理只要区分该主机所属机房、环境、群组、产品线即可那么我们的管理Agent的颗粒度可以精确到每个主机也就是支持任意纬度的灰度发布管理与命令下发。 数据上报通道 组件名为 log_agent 是公司内部统一日志上报组件会部署在每一台VM、Docker上。主机上所有业务均可将日志发送至该组件。 log_agent会将日志上报到Kafka集群中经过处理后落入Hive集群中。细节不在本篇讨论范围 主进程 主进程实现跟etcd集群通信管理整个Agent的配置下发与命令下发管理各个子模块的启动与停止管理各个子模块的CPU、内存占用情况对资源超标进行进行熔断处理让出资源保证业务进程的运行。 插件化管理其他模块多进程模式便于提高产品灵活性可更简便的更新启动子模块不会因为个别模块插件的功能、BUG导致整个Agent崩溃。 进程监控 方案选择 我们在研发这产品时做了很多关于linux进程创建监控的调研不限于安全产品大约有下面三种技术方案 方案Docker兼容性开发难度数据准确性系统侵入性cn_proc不支持Docker一般存在内核拿到的PID在/proc/下丢失的情况无Audit不支持Docker一般同cn_proc弱但依赖AuditdHook定制高精确强对于公司的所有服务器来说几十万台都是已经在运行的服务器新上的任何产品都尽量避免对服务器有影响更何况是所有服务器都要部署的Agent。 意味着我们在选择系统侵入性来说优先选择最小侵入性的方案。 对于Netlink的方案原理可以参考这张图来自:kernel-proc-connector-and-containers 。 系统侵入性比较 cn_proc跟Autid在「系统侵入性」和「数据准确性」来说cn_proc方案更好而且使用CPU、内存等资源情况更可控。Hook的方案对系统侵入性太高了尤其是这种最底层做HOOK syscall的做法万一测试不充分在特定环境下有一定的概率会出现Bug而在百万IDC的规模下这将成为大面积事件可能会造成重大事故。兼容性上比较 cn_proc不兼容Docker这个可以在宿主机上部署来解决。Hook的方案需要针对每种Linux的发行版做定制维护成本较高且不符合长远目标收购外部公司时遇到各式各样操作系统问题数据准确性比较 在大量PID创建的场景比如Docker的宿主机上内核返回PID时因为PID返回非常多非常快很多进程启动后立刻消失了另外一个线程都还没去读取/proc/进程都丢失了场景常出现在Bash执行某些命令。 最终我们选择Linux Kernel Netlink接口的cn_proc指令作为我们进程监控方案借助对Bash命令的收集作为该方案的补充。当然仍然存在丢数据的情况但我们为了系统稳定性产品侵入性低等业务需求牺牲了一些安全性上的保障。 对于Docker的场景采用宿主机运行捕获数据关联到Docker容器上报到日志中心的做法来实现。 遇到的问题 内核Netlink发送数据卡住 内核返回数据太快用户态ParseNetlinkMessage解析读取太慢导致用户态网络Buff占满内核不再发送数据给用户态进程空闲。对于这个问题我们在用户态做了队列控制确保解析时间的问题不会影响到内核发送数据。对于队列的长度我们做了定值限制生产速度大于消费速度的话可以丢弃一些数据来保证业务正常运行并且来控制进程的内存增长问题。 疑似“内存泄露”问题 在一台Docker的宿主机上运行了50个Docker实例每个Docker都运行了复杂的业务场景频繁的创建进程在最初的产品实现上启动时大约10M内存占用一天后达到200M的情况。 经过我们Debug分析发现在ParseNetlinkMessage处理内核发出的消息时PID频繁创建带来内存频繁申请对象频繁实例化占用大量内存。同时在Golang GC时扫描、清理动作带来大量CPU消耗。在代码中发现对于linux/connector.h里的struct cb_msg、linux/cn_proc.h里的struct proc_event结构体频繁创建带来内存申请等问题以及Golang的GC特性内存申请后不会在GC时立刻归还操作系统而是在后台任务里逐渐的归还到操作系统见debug.FreeOSMemory FreeOSMemory forces a garbage collection followed by an attempt to return as much memory to the operating system as possible. (Even if this is not called, the runtime gradually returns memory to the operating system in a background task.) 但在这个业务场景里大量频繁的创建PID频繁的申请内存创建对象那么申请速度远远大于释放速度自然内存就一直堆积。 从文档中可以看出FreeOSMemory的方法可以将内存归还给操作系统但我们并没有采用这种方案因为它治标不治本没法解决内存频繁申请频繁创建的问题也不能降低CPU使用率。 为了解决这个问题我们采用了sync.Pool的内置对象池方式来复用回收对象避免对象频繁创建减少内存占用情况在针对几个频繁创建的对象做对象池化后同样的测试环境内存稳定控制在15M左右。 大量对象的复用也减少了对象的数量同样的在Golang GC运行时也减少了对象的扫描数量、回收数量降低了CPU使用率。 项目进展 在产品的研发过程中也遇到了一些问题比如 etcd Client Lease Keepalive的Bug。Agent进程资源限制的Cgroup触发几次内核Bug。Docker宿主机上瞬时大量进程创建的性能问题。网络监控模块在处理Nginx反向代理时动辄几十万TCP链接的网络数据获取压力。个别进程打开了10W以上的fd。方法一定比困难多但方法不是拍脑袋想出来的一定要深入探索问题的根本原因找到系统性的修复方法具备高可用、高性能、监控告警、熔断限流等功能后对于出现的问题能够提前发现将故障影响最小化提前做处理。在应对产品运营过程中遇到的各种问题时逢山开路遇水搭桥都可以从容的应对。 经过我们一年的努力已经部署了除了个别特殊业务线之外的其他所有服务器数量达几十万台产品稳定运行。在数据完整性、准确性上还有待提高在精细化运营上需要多做改进。 本篇更多的是研发角度上软件架构上的设计关于安全事件分析、数据建模、运营策略等方面的经验和技巧未来将会由其他同学进行分享敬请期待。 总结 我们在研发这款产品过程中也看到了网上开源了几款同类产品也了解了他们的设计思路发现很多产品都是把主要方向放在了单个模块的实现上而忽略了产品架构上的重要性。 比如有的产品使用了syscall hook这种侵入性高的方案来保障数据完整性使得对系统侵入性非常高Hook代码的稳定性也严重影响了操作系统内核的稳定。同时Hook代码也缺少了监控熔断的措施在几十万服务器规模的场景下部署潜在的风险可能让安全部门无法接受甚至是致命的。 这种设计可能在服务器量级小时对于出现的问题多花点时间也能逐个进行维护但应对几十万甚至上百万台服务器时对维护成本、稳定性、监控熔断等都是很大的技术挑战。同时在研发上也很难实现产品的快速迭代而这种方式带来的影响几乎都会导致内核宕机之类致命问题。这种事故使用服务器的业务方很难进行接受势必会影响产品的研发速度、推进速度影响同事SRE运维等对产品的信心进而对后续产品的推进带来很大的阻力。 以上是笔者站在研发角度从可用性、可靠性、可控性、监控熔断等角度做的架构设计与框架设计分享的产品研发思路。 笔者认为大规模的服务器安全防护产品首先需要考虑的是架构的稳定性、监控告警的实时性、熔断限流的准确性等因素其次再考虑安全数据的完整性、检测方案的可靠性、检测模型的精确性等因素。 九层之台起于累土。只有打好基础才能运筹帷幄决胜千里之外。 参考资料 https://en.wikipedia.org/wiki/CAP_theoremhttps://www.consul.io/intro/vs/serf.htmlhttps://golang.org/src/runtime/debug/garbage.go?hFreeOSMemory#L99https://www.ibm.com/developerworks/cn/linux/l-connector/https://www.kernel.org/doc/https://coreos.com/etcd/docs/latest/作者简介 陈驰美团点评技术专家2017年加入美团十年以上互联网产品研发经验专注于分布式系统架构设计目前主要从事安全防御产品研发工作。 关于美团安全 美团安全部的大多数核心人员拥有多年互联网以及安全领域实践经验很多同学参与过大型互联网公司的安全体系建设其中也不乏全球化安全运营人才具备百万级IDC规模攻防对抗的经验。安全部也不乏CVE“挖掘圣手”有受邀在Black Hat等国际顶级会议发言的讲者当然还有很多漂亮的运营妹子。 目前美团安全部涉及的技术包括渗透测试、Web防护、二进制安全、内核安全、分布式开发、大数据分析、安全算法等等同时还有全球合规与隐私保护等策略制定。我们正在建设一套百万级IDC规模、数十万终端接入的移动办公网络自适应安全体系这套体系构建于零信任架构之上横跨多种云基础设施包括网络层、虚拟化/容器层、Server 软件层内核态/用户态、语言虚拟机层JVM/JS V8、Web应用层、数据访问层等并能够基于“大数据机器学习”技术构建全自动的安全事件感知系统努力打造成业界最前沿的内置式安全架构和纵深防御体系。 随着美团的高速发展业务复杂度不断提升安全部门面临更多的机遇和挑战。我们希望将更多代表业界最佳实践的安全项目落地同时为更多的安全从业者提供一个广阔的发展平台并提供更多在安全新兴领域不断探索的机会。 招聘信息 美团安全部正在招募Web二进制攻防、后台系统开发、机器学习算法等各路小伙伴。如果你想加入我们欢迎简历请发至邮箱zhaoyan17meituan.com 具体职位信息可参考这里https://mp.weixin.qq.com/s/ynEq5LqQ2uBcEaHCu7Tsiw 美团安全应急响应中心MTSRC主页security.meituan.com
