安全日志分析系统架构
作者：糖果
0×00 概要
接着上一篇基于Openresty+的WEB安全防护系统来讲， 对于类似的这种系统来说，对其日志进行的分析是一种很常见的应用场景，对应安全防护系统来说，产生威胁日志给安全人员看几乎是必须的。而平时创建日志分析系统很多都是同时汇聚很多系统的日志的， WAF，IDS，网关，很多系统产生日志都可以用同一系统，汇聚日志，分析日志。我们先回顾一下基于Openresty+的WEB防护系统的那张图。
这张图上图的非常抽象概况，只是指明了WAF管理结点直接推送数据给日志中心，而数据的传输靠的就是syslog传输的，然后， 通过日志分析系统对WAF威胁检查的误报率和漏报率进行统计，但这个图上的这个日志系统图是高度概括的，只是一个方框，而这篇的目地是把日志分析系统实现具体化一些，将一个框图内部通过更细的视图展示出来。
0×10 系统构成图
这张图上的日志系统比上一张图更具体的说明了其内部构成，并举了两个例子，一个是邮件服务的例子，另一个是移动应用网关的系统例子，实际生产中，我们收集了更多系统的日志，显然都画到一张图上也画不下。典型的应用系统都会涉及到负载均衡，集群，应用服务器，而且是多层级的。我们只用少数的例子说明一上问题。
0×11 邮件网关
上图的左边的系统，是一个典型的邮件系统的移动端的网关服务，也是一个多层级的基于负载均衡的系统， 当用户想通过域名访问邮件网关时，DNS服务器会根据有户的线路，把用户的请求转给对应线路的邮件网关的负载均衡的IP，在这之前也可在负载均衡前加一个威胁过滤的服务，如果共享一台的话过滤服务的，这台服务器需要有智能选路的功能。当主请求到达负载均衡服务时，负载均衡把请求转给后端的邮件网关，邮件网关再做完相关的检查后，会把请求现转给exchange邮件服务的负载均衡，由负载均衡决定由具体的那台服务器进行处理，如果在网关阶段主请求就有问题，就会拒绝请求。
在这个过程中，有多少结点产生日志，就可以汇聚多少的日志数据。
1.邮件网关的日志（Openresty）。
2.邮件服务器的的日志。（Exchange）
3.WAF系统日志。
0×12 移动网关
上图右边的系统是一个移动网关，移动服务网关和邮件网关功能类似，让外网用户的请求通过网关转给内网服务器。图上画是基于单层负载均衡，当代入到内部系统时，内网的被请求系统是不是基于负载均衡就不考虑了。这个应用系统，日志中心只是收集网关上的数据，网关代入到内网服务，并不向日志中心发数据，应用本身就是代理，可以聚合日志的地方主要是：
1办公移动网关的日志（Openresty）。
2.WAF系统。
0×13 日志分析系统
日志分析的内部实现要比图上画的复杂，图只是将日志中心的基本服务部署画出来，有些mongo数据库和kafka队列没有体现在图上。日志中心分析系统的核心存储中心就是ES集群，还有管理数据存储的数据管理结点服务， 到管理节点使用的也是负载均衡技术，因为管理结点有一个以上。并且，日志分析系统，提供数据检索的WEB服务，与WEB服务相接关联的业务：
1.日志审计系统。
2.可视化大屏幕。
3.自动化分析服务。
0×20 安全日志处理业务
我们构建日志中心的目地是为了安全运维工作使用，我们对上一个图进行了加工，将原画收集两个系统的图，只改成收集邮件系统，把空出来的位置，用于展示日志中心的三大核心业务。
0×21 日志审计查询
我们把分布在各个子系统中的日志收集起来的一个目地是为了集中查询，我们通过创建安全审计的WEB服务，通过浏览器，对散落各地的日志进行快速的审计查询。这样我们不用一台台的登上服务器去查看各个服务器上的文本日志，提高工作效率。
0×22 大屏幕可视化
平时我们会关注很多应用系统的服务状态，当有了日志系统，我们可以根据系统的日志，来判断系统的服务状态和安全状态，我们可以通过对日志进行分析，来判断系统是否被扫描攻击。
0×23 智能自动化任务
我们通过启动定时任务，去定期的检查系统的安全状态，生成安全报告。
0×30 业务系统实现
有进对于安全运维的人员来说，不关心系统的具体实现，只关心是否可以提供相应的服务。对于开发人员来说，就要隐藏一些实现细节，让安全运维人员把精力集中在安全业务上。下面是一个更具体的日志中心系统的内部实现展开图。
这是一个抽象的数据流图，表示了原始的日志数据的，从那里的服务产生的，如何通过Input(输入监听)和Stram进行逻辑组织的，存储到了那里，通过提供服务，对外提供日志的查询操作。这个图从左向右看是：服务器产生日志数据，数据通过代理推送到监听数服务上，通过日志中心的管理结点，将数据存到集群里，然后对外开放了WEB REST服务，提供基于HTTP的查询服务。然后基于查询服务，再次开发实现了日志审计查询，可视化大屏幕展示，和AI自动化处理。
0×40 日志中心物理部署
我们通过一个更具象化的部署图，展现出日志中心服务都应该由那些服务组成。
为了说明问题，还是简化了系统的展示图，实际的项目中的部署图可能与这张图可能不太一样，差别体现在，有的服务是多点，有的的单点服务，更理想的状态，我们还是希望服务器都是有备份机的，而且是解耦互不影响的。
0×50 总结
有时考虑到企业的运营成本，构建一个日志中心可能并不能使用商用的系统，比如说Graylog免费，就不买商用的解决方案splunk。那怎么办呢？如果预算不够就用开源吧。 我们本身也基于graylog做了日志分析系统。无论我们使有什么样的工具，对于安全运维来说，常用需求是固定的，而技术是日新月异，比如现在有新的日志分析产品Aplace Flink等。这章我们只是给出一个大体的日志中心的架构图，之后我们会用具体的软件来实现图上的架构。