业务风控之事前风控浅析（一）

最新推荐文章于 2024-04-21 15:12:13 发布

weixin_38639379

最新推荐文章于 2024-04-21 15:12:13 发布

阅读量1.3k

点赞数 22

文章标签：安全

本文链接：https://blog.csdn.net/weixin_38639379/article/details/135386630

版权

序

互联网社区的发展进程中，风控的角色是不可或缺的，业务风控在账号安全，活动营销，反爬中都有其活跃的身影。
大体上业务风控分为三个环节，事前，事中，事后。本文对事前风控进行概括性的解析。

名词解释

事前风控
「事前」指的是用户通过 PC , 手机等其他设备发出的请求，未到达业务服务之前，对请求进行甄别及风险处置。
事前风控主要着重于对爬虫的防治，网关防护的衍生治理，事中风控的补充。

接入点

从概念入手，事前风控需要在请求到达业务服务之前介入，那么「事前风控」对于业务应该是无感的。
且因为众多业务，事前风控接入业务时，应该不因业务进行定制逻辑，所以从接入形式来说，未到达业务的 http 形式的用户请求，便于接入「事前风控」，且对于业务无感。

那么从通用的互联网公司后端架构来讲，通常会有 nginx 网关将用户的 http 请求转发至对应业务的 Web 服务。
事前风控接入的最佳时机就在网关转发至业务之前

在这里插入图片描述
网关先将用户请求转发至事前风控服务，进行风险甄别和处置，风险请求返回特定结果（拦截类型，拦截文案）至网关，网关透传或者加工其他信息返回至用户设备，展示特定拦截页面。
正常请求，事前风控会返回正常结果给网关，网关再继续转发至业务，进行后续流程。

模块划分

事前风控需要在极短时间内完成「风险甄别」及「风险处置」。因为事前风控服务在网关与业务之间，如果「事前风控」处理时间过长，会严重影响用户的正常体验。
其中「风险甄别」耗时最长，需要进行频率统计及信息补充。
那么事前风控能否异步进行风险甄别，同步进行风险处置呢？这样用户发出请求后，只会增加事前风控的处置时长。
在这样的设想下，事前风控的模块设计应该如下图所示。
在这里插入图片描述

网关收到用户请求后，通过 kafka 将请求数据异步发送，风险甄别模块收到消息后，完成频率统计和关键信息补充，进行策略识别，完成风险甄别，对风险请求的关键特征如 ip，设备，账号进行封禁。写入 redis 或其他数据存储。但为了风险处置的查询速度， redis 最佳。
网关完成发送异步操作后，将请求转发给风险处置模块，风险处置模块读取 redis 中的风险数据，判断此次请求是否风险，继而决定是否拦截或放行。

至此，「事前风控」可分为「风险处置」和「风险甄别」模块。保证「事前风控」的接入不影响用户体验。

风险甄别

风险甄别模块通常会有「策略平台」的概念，策略平台对请求进行是否命中策略的判断。

策略平台

从用户层面讲，策略平台需要支持产品以及运营，在后台管理页面添加策略，风险甄别模块收到的请求后，需要判断请求是否满足策略中的等式。
从功能结构讲，策略平台需要「补充」、「字段加工」、「策略判定」、「处置」等环节。

下文从功能结构上详细介绍。

补充

补充指在收到请求后，策略平台可以通过其中某个属性，补充到更多数据。
比如请求中带有账号 ID ，那么策略平台可以根据账号 ID 请求账号服务的 RPC , 获得账号人的性别，邮箱等详细信息。
在实际策略运用中，偏向于通过补充设备具体信息，运行时环境，以及内部风险资源库，得到多种维度的数据。

字段加工

通常有些字段不能直接运用于策略运算，比如某条策略，账号 ID 的前四位等于 1000 。那么需要有一个环节将账号 ID 的前四位截取出来。
字段加工环节就是对字段进行加工，以符合策略运算的标准。

策略判定

策略包含左值运算符右值，在策略判定环节中，需要判定左值、右值是否满足运算符。
左值、右值通常有其中一项是从请求中解析出的属性，而另外一项则是用户拟定的内容。比如用户 ID 的尾号是 9 ，那么策略的左值就是用户 ID，经过「字段加工」环节得到用户 ID 尾号, 右值就是 9 ，运算符就是 = ，这样一条策略就写好了。
策略需要通过策略引擎运算，得出是否正确的结果。

那么策略平台的大致结构如下

在这里插入图片描述

策略偏向

如上文所述，「事前风控主要着重于对于爬虫的防治，网关防护的衍生治理，事中风控的补充。」
事前风控的风险识别模块，策略主要偏向于防治爬虫，而业内防止爬虫策略主要是频率统计类策略。
通常策略思路

确认风险维度，认清目前现状下，能够作为防治抓手的属性，比如账号 ID, IP，设备ID 等。
通过上述风险维度进行频率类统计，比如 10 分钟内账号 ID 访问某接口的次数。
通过策略平台制订策略，比如 10 分钟内账号 ID 访问某接口的次数 > 50 。
策略判定成功后，进行风险数据存储。

这样就完成了一次请求的频率统计，以及利用频率统计的结果进行策略判定。

风险数据

在完成请求的风险识别后，风险识别需要将这次请求的特征（也可以是策略偏向中的「风险维度」）记入风险数据中，可以是请求的 IP , 账号 ID 等。
存储形式需要支持快速检索，完成后续风险处置模块的快速风险判断。
redis 作为风险数据存储，那么风险特征应该写入 key 中，便于快速获取。

以上对风险识别模块进行了「策略平台」、「策略倾向」、「风险数据」三个角度的解析，阐述了风险识别主要对风险请求进行识别以及风险特征存储。

风险处置

本模块的目的，就是在收到用户同步请求后，快速判定是否存在风险特征，如果存在，立即拦截，或贴合业务需要进行多样性的处置手段。

特征风险判断

在收到请求后，解析出上文中「风险维度」的具体值，比如账户 ID 、请求 IP 等具体值，查询风险数据库，得到风险结果。
通常「风险处置」收到的请求要大于「风险甄别」，且有耗时要求，所以，风险处置模块编码实现中，需要格外注意性能。

策略平台

没错，其实「风险处置」模块具有很多的扩展点，因为其能够接收用户同步请求的独特优势，其在该请求环节，可以做到判断即时策略，即时拦截。
上文讲述的「事前风控主要着重于对爬虫的防治，网关防护的衍生治理，事中风控的补充。」，其中「网关防护的衍生治理，事中风控的补充」都可以通过「风险处置」完成。

网关防护的衍生治理

风险处置在请求环节中位于网关后，且请求是同步的，这就意味着，有些复杂的逻辑不能放在，或者不合适放在网关的拦截逻辑可以放在「风险处置」模块中。
在这里插入图片描述
比如签名的拦截策略，有些风险请求未带有加密 Header 或签名 Header , 网关因为其位置的重要性，以及通过防耦合的角度考虑，网关应该只负责签名的验签，验签后对验签失败的请求拦截，就可以放在风险处置模块