关于flink:如何设计信息安全领域的实时安全基线引擎

摘要：本文整顿自奇安信团体高级技术专家覃永靖在 Flink Forward Asia 2021 行业实际专场的分享。本篇内容次要分为四个局部：

1. 什么是平安剖析
2. 计算框架的抉择
3. 引擎设计
4. 实际与瞻望

点击查看直播回放 & 演讲 PDF

一、什么是平安剖析

近 10 年来，大数据技术倒退突飞猛进。平安剖析场景和办法也更新换代。目前，罕用的平安剖析流程大略分为三个流程：

1. 日志采集解析。通过各种办法，从服务器、网关设施、终端、数据库或其它数据源采集各种流量日志、威逼日志、运行日志，和终端日志等数据；
2. 实时平安剖析。剖析过程次要有平安基线、关联剖析、平安规定、威逼情报，和平安知识库；
3. 平安经营和态势感知。这个流程基于平安剖析的后果来实现态势可视化、平安经营、多设施平安联动、平安编排等能力。

如上图所示，平安畛域次要有三个特点：

• 疾速响应。因为安全事件常常是突发的，比方破绽的披露、病毒的暴发等经常是在很短的工夫忽然产生，所以须要以十分无效和简略易用的形式来疾速的对突发的安全事件进行解决，能第一工夫响应客户的需要、应答各类安全事件；
• 场景定制。因为平安剖析和惯例的大数据分析场景会有一些不同，平安剖析检测的是异样而不是失常，还有畛域独有的一些需要，所以这里会波及到很多畛域定制开发的需要。
• 资源受限。相比惯例互联网大数据平台应用形式，平安剖析可应用的资源会有很多的限度，通常用户受限于估算和资源的限度，会尽可能的压缩和优化可用计算和存储资源规模，这会导致大量的组件采纳混合部署的形式，且未来硬件和集群扩大老本也很高，流程很长。

在实时数据安全方面，一共有五点需要：

• 第一是须要实时剖析。平安检测对时延要求严格，攻防单方抢时间差，须要能第一工夫检测到异样。同时因为是安全事件驱动，要求解决方案上线快，响应及时，能在最短时间造成防护能力；
• 第二是须要提供十分丰盛的剖析语义。平安检测的场景通常比较复杂的，须要提供丰盛的平安剖析语义，笼罩大部分平安剖析场景；
• 第三个是能灵便部署。因为客户的环境非常复杂，须要能反对各种大数据平台，比方客户自建的，或者是他购买的一些云平台，并且还要有最大的版本兼容性；
• 第四是须要实现最小的资源应用。反对部署从一到几十甚至上百台节点的集群，在资源占用尽可能小的同时反对大规模，比方上千条剖析规定或平安基线同时运行；
• 最初是运行稳固。平安产品部署在客户侧，须要 7×24 小时不间断运行，须要提供极高的运行稳定性，尽可能减少人工保护和染指，让客户无感知。

传统的平安分析方法个别是基于先验常识，采纳基于特色检测技术来进行异样检测，个别是通过剖析检测对象的数据或日志特点，而后人工演绎和统计出可检测特色，建设平安模型，比方平安规定、威逼情报等。这种形式比较简单和牢靠，能够很好的应答已有的攻打办法，然而它对未知的没有对应检测特色的攻打办法则不能无效的进行检测。

平安基线采纳基于行为的检测办法，应用检测对象数据和日志，采纳各种办法学习出行为特色，建设平安基线，并用于异样检测。

为了让大家能更好的了解平安基线的应用场景，这里列了三个实在场景：

• 场景一，DBA 用户账号登录异样。比方登录地位异样，登录工夫异样，应用数据库的行为异样等。比方一个 DBA 用户，通常是在某些工夫、某些 IP 或是某些地点登录，然而某天忽然在另外一个中央登录了，且工夫也不是通常登录工夫，那这可能就是一个异样，须要生成异样事件；
• 场景二，邮件发送附件数量超过惯例值。比方平安基线学习部门或者整个公司发送邮件的行为数据，发现某一个用户发送附件的数量和历史学习数据有较大出入，那这可能是一个异样；
• 场景三，最近账号登录 VPN 服务的次数异样。通过学习用户账号 VPN 历史登录行为，构建平安基线，如果未来发现账号登录异样，则产生异样事件。

二、计算框架的抉择

目前支流实时计算框架次要有两个，Spark 和 Flink。咱们当初设计这个引擎是在 2018 年左右，过后咱们钻研了 Storm、Spark、Flink 这三个计算框架，综合各方面因素最终抉择了 Flink 作为底层计算框架。过后应用的 Flink 是 1.4 版本左右，是一个比拟成熟的版本，相比其它框架，它的 API 以及它的底层分布式和流计算实现形式比拟合乎咱们的应用场景。

Flink 的劣势点比较突出，它是分布式计算框架，部署灵便，适配目前常见大数据平台。它领有很好的解决性能，能达到高吞吐低提早，这非常适合进行实时平安剖析。它还提供灵便的 DataStreaming API，不便实现定制化需要。另外，还反对简略易用的检查点和保留点机制。并且，作为目前十分热门的计算框架，社区沉闷，有丰盛的文档和场景样例。

尽管 Flink 有很多劣势，但当企业资源受限，规定集数量上千规模的状况下。Flink 在满足业务及性能需求上遇到了很多问题。比方无大规模规定语义 / 流优化，不足平安场景定制窗口和逻辑，无平安基线相干算子以及无资源爱护机制等。

三、引擎设计

引擎利用框架分为三层：

1. 底层是部署层，通常是一个大数据集群；
2. 第二层是平安剖析层，基于 Flink DataStreaming API 来构建平安基线引擎，Flink 负责底层的分布式计算和事件流发送，具体的业务计算由平安基线引擎来实现。平安基线引擎向用户提供的应用接口为规定和 DSL，用户通过界面来下发规定 DSL 给引擎，引擎依据规定和 DSL 来对事件流进行剖析和计算，同时依据规定语义应用内部的数据，比方常识数据、威逼情报、资产和破绽等；
3. 用户通过第三层的应用层来治理和应用引擎。并基于引擎数据后果态势剖析，平安经营，资源监控等具体平安业务。

引擎的业务流程分为三块，即用户界面，引擎服务和引擎剖析工作。用户通过用户界面来进行规定配置、基线治理和运行监控。引擎服务以 RESTfull API 的形式向用户提供规定下发、基线下发、状态监控等服务。引擎服务在接管到用户的规定下发申请后须要对下发的规定集进行解析、优化之后生成剖析工作代码包，剖析工作代码提交大数据集群运行，剖析工作在运行过程中接管引擎服务的基线发下数据，对运行时基线进行增删改操作。剖析工作还向引擎服务报告工作运行状态，引擎服务将工作运行状态映射成业务监控信息，提供给用户查问和剖析应用

因为大部分用户不是研发人员，所以须要提供一种针对平安剖析场景，进行特定优化的平安剖析语言。它须要具备以下几点：

• 简略易用，学习成本低，易上手，一个没有研发背景的人也能通过简略学习之后就能上手应用，且合乎平安剖析人员的直觉思维；
• 须要提供丰盛的数据类型，首先要提供丰盛的根底数据类型，其次是平安剖析罕用的数据比方 IP，各类工夫、资产、破绽、威逼情报、地理位置等提供间接反对，使用者能够不做任何定制就能间接应用各类数据；
• 提供丰盛的语义，尤其对平安剖析语义进行加强和定制；
• 反对扩大，尽管提供的平安剖析语义比拟全面，反对大部分平安剖析场景，但还是会遇到一些无奈间接反对的非凡场景，此时就须要以扩大的形式来反对这类需要。

平安剖析语言须要设计一个专门的编译器来对平安剖析人员设计的平安剖析语句和规定进行编译和优化。编译器须要提供一些个性和优化的反对：

• 公共表达式优化。对剖析语句中雷同语义逻辑进行优化，升高反复计算和计算复杂度；
• 援用数据表优化。一个规定集中可能有上千条剖析语句和规定，它们会大量的援用内部数据表数据，须要对表计算进行计算优化，比方 hash 匹配、大规模 IP 匹配优化、大规模正则匹配和串匹配优化等；
• 常量表达式优化。进步运行性能；
• 表援用优化。蕴含援用示例归并和援用语义归并两个局部，升高援用表的资源占用。

剖析语句和规定编译之后生成运行子图，每一条语句和规定对应一个子图，此时须要集中所有规定进行图优化，分为四个流程：

1. 第一步是图交融，图交融波及子图交融，行将规定集中所有子图交融成一个运行图，而后进行图节点语义交融、工夫窗口归并、援用公共资源优化；
2. 第二步是数据流优化，升高图规模，缩小传输数据量，次要进行 Key 前置、语义等价节点交融、网络吞吐平衡，缩小数据歪斜、节点归并，大幅压缩超大图节点数量等操作；
3. 第三步是字段裁剪，升高传输事件大小，进而升高网络 IO 压力，次要蕴含图上字段推导和裁剪以及字段归并；
4. 最初是代码生成，将剖析语句和规定语义生成代码，并将执行图映射到 Flink DataStream API。

实时计算一个外围因素是工夫，不同的工夫解决办法和实现计划会带来差别很大甚至齐全不同的计算结果。实时剖析中，工夫次要影响两个性能，即工夫窗口和工夫线。

在平安剖析场景里，工夫窗口须要反对通用滑动工夫窗口、也要反对天然工夫滑动工夫窗口，比方每年，每月，每星期等天然，甚至是变长时间、须要反对层叠窗口反复数据交融，升高数据存储量、能主动进行反复计算打消，防止反复告警、工夫定时器归并、事件乱序正确处理，防止事件乱序引起错误计算。

工夫线可分为事件产生工夫和工夫解决两类，进而延长出工夫精度，不同的工夫精度会对解决性能和存储造成很大的压力，比方须要对工夫进行排序的场景。因为实时剖析中事件可能是乱序的，因而须要反对延迟时间，解决大部分因为乱序而造成的计算不精确问题。局部计算场景波及零碎工夫 <-> 事件工夫之间的互相转换，须要能提供两种工夫的转换计算方法。因为执行图是大量子图交融而来，因而须要同时反对对全局和部分工夫水位进行治理，保障图上工夫线能正确推动。

平安基线分为三类：

• 第一类是统计类平安极限，蕴含常见的工夫类、频率类、空间类、范畴类和多级统计类的平安基线；
• 第二是序列类，比方指数平滑类和周期类平安基线；
• 第三是机器学习类的平安基线，比方应用一些聚类算法的平安基线，决策树类平安基线等。

基线解决流程次要分为三个局部：基线学习、基线检测和基线路由，其中交叉事件过滤、工夫窗口、基线降噪、基线治理等流程。基线学习流程蕴含从音讯队列和存储中读取事件流，通过事件过滤和工夫窗口聚合，事件流中可能蕴含乐音数据，还需进行数据降噪流程，最初基线学习流程学习输出的事件流程，生成对应的平安基线。学习实现的平安基线在进行基线治理流程之后用于异样检测，用于预测和异样检测，如果发现异常行为，则产生异样事件，输入到后续的解决流程，用于后续的业务的应用。用户在应用过程中可能须要批改或删除一些学习好的基线或者本人新建一个基线，这些基线的增删改操作通过基线路由性能来实现，基线路由流程将用户编辑的基线在图上路由之后正确的散发到对应的图节点实例中。

基线的周期分为 learn，ready，close，expire 四个阶段：

• learn 示意学习阶段，在这个阶段基线学习输出的事件流；
• ready 阶段示意以后工夫线曾经到了基线的学习截止工夫，然而因为延迟时间，基线须要期待一个延迟时间，在这个时间段基线能够持续学习提早的事件，同时基线能够用于异样检测；
• close 示意以后工夫线到了延迟时间，此时基线不再学习输出的事件，只用于异样检测；
• expire 示意以后工夫线到了基线超时工夫，须要基线进行进行异样检测，并删除。

基线的计算由两种状况触发：

• 第一种是事件触发计算，每条事件达到之后会触发一次异样检测计算；
• 第二种是工夫触发计算，基线周期会注册工夫定时器，工夫定时器触发之后会触发相干基线计算流程。

基线的输入分为基线异样事件输入和基线内容输入：

• 基线异样事件输入产生于基线异样检测过程，当发现异常事件时须要输入对应的事件；
• 基线内容输入产生于基线学习实现之后须要将基线自身进行输入，用于基线编辑和基线自身异样剖析。

用户在应用过程中，可能会常常编辑已有基线或者本人依据一些剖析和数据来新建特定场景的平安基线。基线编辑之后须要能下发到基线引擎中，这就波及如何在线编辑和更新基线。

• 首先须要基线是可编辑的，要求剖析语言反对基线编辑相干语义，同时基线数据结构的设计须要反对基线编辑的语义，最初是要提供一套基线编辑可视化流程，蕴含基线展现、批改、删除等性能，用户能够间接在页面进行基线的编辑和下发；
• 第二是要求基线是可路由的，剖析语句和规定在通过编译和图优化之后的实在执行图和页面显示的规定运行会有很大的不同，一个可路由的基线要求实现编译时构建全局基线更新流图、一套运行时基线路由办法，蕴含执行流图的路由流构建，播送和定向路由的反对，最终实现准确的基线数据散发；
• 最初还要求基线是可更新的，须要有一套清晰的基线更新语义，定义基线运行周期和计算方法，而后在你基线更新过程中，任何一个地位都可能会产生异样导致更新失败，此时须要设计一套机制能在任何地位失败后将信息反馈用户，用于谬误断定和问题修复。

在基线学习过程中，通常学习周期是比拟长的，比方最近一周、最近一个月等，长周期的学习通常会面临一个数据割裂的问题，比方学习最近一周的数据，然而当初是星期三，也就是说最近一周的数据分成两个局部，其中从星期一到星期二的数据是保留在历史数据存储中，星期三及之后的数据是实时产生的，这里会波及历史和实时数据交融学习的问题。这里能够分为三种状况：

• 第一是待学习数据全副是历史数据，这须要反对历史数据学习范畴探测，和在线基线更新；
• 第二是待学习的数据全副是实时数据，这要求反对基线主动学习、基线自动检测和基线自动更新；
• 第三种是方才举例的这种，也是最简单的状况，即历史和实时数据交融，这须要反对历史和实时数据边界划分、基线交融、反复数据打消。

基线学习的数据中通常会有一些乐音，这些乐音可能是某一次异样操作，比方用户某一次的异样登录，也可能是数据采集的过程中引入的谬误数据，因而须要对乐音进行打消，来减少基线准确性，缩小误报。

数据降噪依据数据类型能够简略分为数值类数据降噪和非数值类数据降噪两种，这两种解决形式会有不同。乐音的断定次要有四种：

• 第一种是绝对于本周期的数据来判断，即与本周期其余数据进行比照，判断是否是乐音；
• 第二是相比上一个周期，与最近一个周期的数据进行比照，判断是否是乐音；
• 第三个是相比历史数据，与历史上所有的数据来进行比照来判断是否是乐音；
• 最初是用户自定义一个乐音断定逻辑，比方设定大于多少小于多少它是乐音。

数据降噪时候通常会须要保留相干数据，比方要用历史的数据来进行乐音断定，那么就须要存储一些历史的要害数据，历史数据通常十分多，为了升高存储，须要进行优化降噪数据结构的优化，比方最小化降噪要害数据，字段裁剪等。

引擎运行中一个十分重要的局部是如何监控以及爱护资源。波及到三个方面的内容：

• 第一个是稳定性加强，须要动静监控基线运行过程中内存的占用，引擎中可能同时运行了几百上千基线规定，须要能监控每条基线规定内存占用有多少，对于内存占用异样的规定，须要采取内存保护的措施，比方删除一些数据或者将它隔离进去，避免影响其它失常规定的运行，删除的时候能够采纳资源优先级的治理，如果优先级比拟低，且同时占用大量的资源，就可能会把资源给缩小甚至停用规定的运行。引擎同时还对基线计算过程进行监控，监控过程如果发现重大影响图解决性能的慢门路，则采纳子图隔离的形式将慢门路对应的子图隔离进去，避免对其它剖析流程造成影响；
• 第二是状态监控，状态监控蕴含两个局部，第一局部是引擎将执行图所有计算节点的状态数据，比方 CPU、内存、磁盘、输入输出等信息报告给监控服务；第二局部是监控服务将执行图的运行信息处理之后映射为规定状态信息，实现图状态到业务状态的转换。对于大规模执行图和高并发执行的剖析工作须要对图状态报告流程进行优化，升高资源占用；
• 第三是流量管制，引擎的上游业务可能是一些解决能力比较慢的流程，比方数据库写等，此时须要反对流量管制，避免较快的解决流程向较慢的解决流程输出过多的数据而引起资源适度耗费和卡顿，流量管制须要反对被动流量管制、被动流量管制以及工夫窗口相干的流量管制，通过用户配置或主动解决来解决前后解决性能不一引起的数据失落和零碎不稳固问题。

用户在应用过程中常常要对规定进行操作，这些操作会引起运行工作的启停，启停过程中数据须要前后保障统一，不能因为启停而导致保留的数据失落。

Flink 自身反对工作重启时从新加载数据，然而在基线引擎这里问题会比较复杂，因为用户可能会停用、启用或者批改规定，这会引起规定集发生变化，进而引起执行图发生变化，为了保障工作重启时不变的规定能正确从 savepoint 加载到到正确的数据，须要反对图部分状态稳固，即在图优化过程中图部分变动不影响其它子图，同时在代码生成过程中保障稳固子图生成稳固的执行代码，变动规定只影响与其相干的子图，其它不变的规定不受影响。

基线学习过程中通常保留大量的两头数据，为了放慢 savepoint 和 checkpoint 速度，须要对简单数据结构的序列化和反序列化进行优化，还需反对增量状态。引擎服务通常须要对多用户提供剖析服务，因而还需对多用户多任务的状态进行治理，保障每个工作都能精确关联到其对应的状态数据。

四、实际与瞻望

剖析引擎提供的实时平安剖析能力服务于公司大部分大数据产品，比方大数据与平安经营平台、态势感知、EDR、云平安、工控互联网、智能平安等。随着这些产品部署了近千个客户，包含央企、政府、银行、公安等，同时还反对常见国产化零碎和各类公有云。部署的环境从一到几百台集群规模，事件量从几百到上百万 EPS，还加入和反对了上百次部委和央企的专项口头。

随着常识的扩散和各类安全漏洞的频发，各种攻打手法和平安威逼也层出不穷，这对平安剖析能力的要求也越来越高，须要引擎能继续进行更新和优化，以进步对平安攻打的检测能力，后续须要持续将更多更好的行为学习算法和技术与平安基线集成，进步平安基线的检测能力。同时冀望能将引擎的一些实际通过某些渠道回馈到社区，让更多的人能应用其中好的设计和实际。

点击查看直播回放 & 演讲 PDF

更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～