独家|一文了解58安全画像系统演进之路

导语

为帮助58各业务方构建智慧型安全防控网络，我们自主研发了基于大数据的安全画像系统，该系统是一个分析型安全防控管理平台，可基于猎人平台（58信息安全部开发的实时风控安全平台）实现统一的信息安全风控管理，帮助业务方实现事前的情报预警，事中的风险识别，事后的案件追溯，并与第三方数据有效集成，最终帮助业务线实现精准风险打击和智慧运营的效果。

演化过程

安全画像系统从去年初第一个版本的开发开始，到现在将近两年的时间里，经过了无数次的需求迭代和几次大的架构演化，从最初的只有几个服务接口和一堆脚本的查询工具逐步演化成现如今的一个系统化平台，目前平台拥有完整数据闭环，多元化的综合服务能力。系统沉淀了20亿+的数据，共10个维度，200多种标签，承载着每日超过20亿次的调用量。

最初的安全画像

安全画像在设计的初衷只是为了给各个业务线提供一系列基于业务安全的，涉及账号、IP、手机号等多个维度的标签数据集，将在58平台上出现过的黑产、或有恶意行为的资源进行标识，从而大幅度提高黑产的攻击成本，有效的降低58平台中出现的各种违规和恶意行为。画像标签应用到风控对抗的策略中，最核心的价值就是数据，所以如何不断提高数据的覆盖率和准确率是关键，而如何从海量的日志中提取特征数据并分析出有效对抗黑产行为的策略是解决这些关键问题的前提，下图就是安全画像服务最初的结构。我们通过对外采购数据和基于58平台的流量日志进行特征的抽取和分析，并通过执行SQL和其它脚本，将输出的风险数据写入标签库。同时我们需要开发一个高性能的服务接口来对外提供实时查询能力。如果想提供高性能的查询服务，首先要选择一个可以支持高并发、低延时的数据库作为存储，标签数据的格式是非常松散的，各个维度的标签结构都不相同，同时考虑到标签的总数据量可能会在几T甚至几十T的级别，高峰期每秒钟的访问量可能会到达几万到几十万，我们采用了文档型数据库mongodb，它可以提供大块的内存来缓存热点数据，满足高并发查询的要求，并且它成熟的数据持久能力也可以保证我们海量的标签数据不会丢失。我们采用分片路由模式进行部署，总共做了5个分片集群，每个分片都是一个由5个副本组成的副本集。保证了超过1T数据量的数据存储、10w+的QPS并发能力，1ms以内的平均访问延时，满足了最初的查询要求。

第一次演化，完成平台化建设

为了满足早期系统快速出策略，快速验证的要求，很多策略的执行脚本都是快速部署到服务器上，并简单通过操作系统的定时任务去调度，随着标签和维度的不断扩充、标签存量也不断增长，几乎每天都会有新的策略需要上线，部署和维护成本越来越大，系统的单点隐患日益凸显，而监控能力几乎没有，任务运行出错时很难被发现，所以基于整个画像系统的平台化建设在这个时期已迫在眉睫。1.  策略调度平台由于最开始的策略基本都是基于hive表中的历史数据，所以我们开发了一个定时执行策略脚本的分布式离线任务调度平台，当时的调度平台主要包括三大模块：分析引擎、接入引擎和调度总线。系统每天都会为策略脚本生成一个任务来执行，并为每个任务创建一个状态机，来控制状态的流转。

• 分析引擎以容器的方式部署在各种环境的服务器（当时我们的策略执行脚本有python语言开发的、java语言开发的、还有通过hadoop客户端直接触发HiveSql的），这样基于任何语言开发的脚本都可以在分析引擎的容器中运行，这个部分只负责策略脚本的执行，策略脚本的输出为标签数据的更新（增加、删除、修改）日志，同时分析引擎可以将任务执行过程、异常信息上报到调度总线，由调度总线统一存储和管理任务执行的运行状态。

• 接入引擎将标准化格式的更新日志进行解析，并实时写入标签库，同时也会将执行情况和执行异常信息向调度总线进行上报。

• 调度总线统一接收分析引擎和接入引擎上报的任务状态信息，并将每一个处于不同阶段的任务状态维护在一个统一的会话上下文中。用户可以方便的通过监控后台查看任务的执行状态，并通过可视化页面对每个任务进行配置下发、任务重跑、超时控制、异常分析等操作。

调度平台部署结构图如下:
策略调度平台的上线大大减少了任务执行的出错率和开发人员的日志维护和部署的工作量，同时也极大的调高了策略分析人员上线、评估策略的效率。
2.  配置中心在策略调度实现了线上自动化后，我们开发了统一的基于标签、策略等元数据管理的配置中心。在项目初期，由于没有体系化地对系统进行规划，查询服务、接入服务、策略管理这些子系统相互之间都是隔离的，对元数据的管理没有中心化的概念，每上线一个标签，平台内的各个子系统都需要更新各自的配置文件，梳理和校对的工作变的十分繁琐，尤其是对外的查询服务每次都要进行一次系统的重新上线才能提供最新的标签能力，这样非常容易出现错误，导致系统的不稳定。配置中心整合了各系统的元数据，并保证了格式的统一，方便了对标签从定义、策略分析、评估、预上线、发布上线、监控、下线的完整流程进行管理。使策略分析，数据运营到标签上线的整个流程实现完全自动化。经过在多个环节的平台建设，我们的架构体系演化如下：

• 独立的运营后台，通过配置中心服务为各个子系统提供统一的元数据配置中心。

• 策略调度平台，使策略更新和任务调度实现自动化。

•  对外服务和接入服务通过配置中心实现配置的统一。

第二次演化，提高数据效果

平台化的建设经过几次迭代之后，标签和策略的上线速度得到了大幅度的提高，标签存量也有了显著的提升。但是某些标签的覆盖率和召回率却一直上不去，经过评估和分析发现，我们标签的准确率其实一直保持非常高的水平，只是标签在打完后，黑产好像很快又能绕过基于标签上线的策略，使我们标签看起来“没有作用”了，原因有两方面：1. 时效性由于之前我们打标签的策略基本都是基于离线的历史数据跑出来的，时间周期多数都在T+1，有的甚至更长，有威胁的行为都是在问题出现了很久我们才能打上标签，而黑产的攻击行为一般都不会维持时间很长，我们的很多标签打上后其实已经失去了意义，所以我们开始考虑将现有的部分离线策略升级为实时策略。如果想上实时策略，我们首先要解决数据源的问题，线上有很多业务日志都没有提供实时的数据源，有的即便提供了，格式也是五花八门，很难统一。所以我们研发了一个可以支持实时数据接入和流转的平台，它将不同数据源的业务日志统一收集，并进行标准化，以便进行后面的规则配置。数据源进行标准化之后还需要一个可以灵活配置规则的规则配置模块，我们自行研发的规则引擎，用户可以通过可视化页面进行配置，生成规则表达式，表达式执行引擎通过规则计算，输出匹配结果，我们根据匹配结果就可以在相应维度的标签上打上分值。2.  多维度我们之前基本上都是基于用户在某一场景的历史行为进行分析，抽取异常特征，然后在满足某些条件后打上相应的行为标签，通过这种方式获得的标签虽然准确率高，但是涉及的维度非常单一，黑产通过变换资源，就可以轻易绕过我们的策略。为了更有效的打击黑产，我们开始通过基于多个场景和数据源的综合维度进行关联分析。

•  决策引擎，起先我们基于业务线的部分活动场景，提取出一些针对于非人类行为的或者其他有恶意行为的标签和特征，我们定义了黑产行为、机器行为、用户行为异常、使用异常资源、业务违规、正常几个决策结果类型。决策引擎在基于多个维度的数据进行计算后会给调用方返回上述问题类型中的一种或者多种。

•   异常流量监测，我们的算法工程师通过基于图关联异常检测的聚类方法，将有恶意行为的群体进行聚合，并给聚合后的每个簇进行打分，得分高的基本可以判定为异常流量。经过评估，这种算分模型可以应用到很多业务场景，但同时存在实时性差的问题，所以我们尝试用工程的方式来实现算法能力，算法工程师通过对样本的训练，会提取出某个场景下最合适的特征和参数，工程把通过算法计算出来的簇和特征放到缓存中，然后实时接入后面到来的每一条流量，再通过特征关联的方式将新的流量合并到已有的簇中或者创建新的簇，并将可疑的簇进行评分，得到决策结果。这种基于算法模型的异常流量检测方法，已经在注册场景验证并获得不错的效果，我们会给检测出来的用户打上恶意注册的标签。

第三次演化，实现资源共享

系统经过多次迭代之后，已经形成了一个完整体系的、数据闭环的、能提供多种综合能力的服务平台，在漫长的迭代过程中，我们不断对整个平台进行领域划分，逐渐抽离出一些基础能力的组件和模块，这些组件和模块也很适用于其它业务场景，甚至可以成为解决其它业务场景相关问题的标准方案。1.  规则引擎在风控对抗类的产品中，很多时候都需要灵活的配置规则来拦截黑产的恶意行为，这时我们把画像平台中实时打标签的规则配置模块有意识地进行业务边界的划分，一部分是规则命中后的处理方式：在安全画像平台中的处理方式是给不同维度的数据打标签；在反爬系统和账号安全系统里是拦截异常流量和账号。而另一部分提供了规则配置和计算，并最终输出命中结果的能力，就被抽象成通用的独立产品-规则引擎。
2.  数据流转平台对于风控类的系统，实时数据的接入、过滤、处理是必不可少的业务流程，我们需要沉淀出一个基于实时数据的可标准化、可自定义过滤规则、并且可以对结果数据重复使用的平台，数据流转平台就是在这样的背景下逐渐演化出来的产品。数据流转平台最核心的价值是整合我们各个业务线和策略场景需要使用的实时数据源，并推动业务标准化数据格式，把同一数据源的接入和使用成本降到最低。同时可以对标准化和过滤后的数据进行回放，这在很多需要策略分析和策略验证的业务场景中是非常有意义的。下面我们简单介绍一下它的架构设计：

• 平台封装了各种类型的消息中间件接入层（SourceRecv），包括kafka、wmb等，同时为了支持每个数据源历史数据的接入，集成了基于hive存储的云窗（58大数据云平台）API。

• 我们定义了统一的标准化层（StandardFlow）和过滤层（filter），实现各种规则的过滤需求并支持用户自定义扩展。

• 为了保证每秒几十万级的数据吞吐量，我们对数据流进行了大幅度的合并和压缩，并统一输出到hbase进行存储（output）

•  系统采用hbase存储标准化和过滤后的数据流的目的有两个，一是可以支持按照任意时间点的数据回放，二是可以满足多个业务应用系统多次重复使用同一结果数据集的需要。

• 平台为应用方提供了统一的代理层（proxy）和sdk，以简化应用方对接数据流转平台的难度，提供了实时数据流推送和历史数据拉取两种方式。

• 系统为用户提供配置管理后台（config）可以满足用户自行接入数据源、对数据源进行标准化和规则过滤的要求。

3.  名单库平台提供了一个开放的名单库，目的是存储其它产品线和业务线在和黑产对抗中沉淀下来的黑名单数据，并提供给用户自行维护和管理。用户也可以通过平台将名单库进行授权，将数据共享给其他业务线使用。我们的运营人员也可以对数据进行审核，将效果好的数据抽取到标签库中，来扩充标签存量。从下图表示的结构中可以看到，蓝色部分是目前平台已经有的功能，画像平台已经拥有了完善的数据更新、数据存储和高性能服务查询的能力，同时拥有一个完善的基于元数据的管理、标签生命周期管理的平台化体系，名单库只需根据业务线提供的资源维度和黑名单数据按照平台规范的数据结构进行转换，集成到平台中就可以了。类似的通用组件和模块还有业务指标平台、第三方数据服务平台等，详细设计方案我在这里不一一阐述了。

安全画像整体架构

经过这几次大的演化，安全画像平台现在的整体结构如下图所示：我们将画像平台系统划分成5个域，每个域在业务扩展和技术架构选型上都可以相互独立，互不影响。

•  能力域是系统最终提供画像数据和其他综合服务能力的聚合，通过统一的服务接口和门户，为各业务线提供每日20多亿次访问请求。

• 运营域集成了各种后台运营管理系统，面向的用户为数据分析师、产品和运营人员等。通过统一的授权和交互风格，可以对整个平台更轻量化的运营。

• 支撑域和通用域是平台的核心，平台中所有数据的流转、元数据的生命周期管理都基本由这两个功能域中的系统提供能力。同时我们将安全产品中的一些通用能力进行抽象，将能力扩展到其它产品和系统中去。

• 基础数据域对58的大数据平台做了一层代理，主要完成对平台日志的收集和第三方数据源的接入工作。

业务效果

安全画像系统上线的一年多时间里，不断为58平台下大量的业务线和场景提供实时有效的安全对抗能力。通过猎人平台风控策略的对接，活动防刷服务、线索发现服务，关联关系服务，招财猫标准评分服务等能力的输出，产生了非常好的效果，其中在58全职招聘涉黄项目贡献度占比31%，58租房微信吸粉治理贡献度占比79%，赶集微信吸粉治理贡献度占比99%。并在多个活动场景中提供拦截能力，共拦截恶意用户量20万左右，平均拦截率占比22%左右。
作者简介吕芳  58同城 / 安全平台部 资深后端开发工程师

END

往期推荐：
独家|58同城实时计算平台架构实践
独家|前端高性能队列应用实践探秘