风控安全产品系统设计的一些思考

海鸥一飞

背景

本篇文章会从系统架构设计的角度，分享在对业务安全风控相关基础安全产品进行系统设计时遇到的问题难点及其解决方案。

内容包括三部分：（1）风控业务架构；（2）基础安全产品的职责；（3）基础安全产品相关系统架构的设计要点。

文章会以总-分的形式进行阐述。懂的不多，做的太少。欢迎批评、指正。

风控业务架构

我把风控业务架构的分层分为6层，分别是组件层、业务层、决策层、能力层、计算层、可视层。

以下基建为基础安全产品的简称。

组件层

组件层的职责是：数据收集与行为反制。

从接口、设备、行为三个维度进行数据收集，接收决策层的指令进行行为反制。为了保证数据的收集数据的可靠性，就衍生出了壳、混淆、反调试等加固策略。

业务层

业务层的职责是：风控数据透传与风控决策结果处理。

将风控所需要的数据透传至决策层，业务层获取到决策层数据后，根据决策层结果选择执行风险反制或业务逻辑。

透传数据一般包括：风控数据和业务补充数据。

决策层

决策层的职责是：风控能力应用。

决策层是整个风控业务的核心，将风控能力高效连接起来，有效、合理地应用能力层、计算层所具备的能力。这一层的难点在于工程而非安全领域，例如：如何设计调用链路（降低计算时长）、如何处理超高并发流量、如何保护下游风控内部系统等。

其中包括：风控参数预处理、风控能力应用（组件/名单/模型等）、风险决策（规则引擎）、反制决策（观测/登录/验证码/行为验证/封禁）。

能力层

能力层的职责是：识别基础安全风险。

该层包括：设备指纹、环境检测、接口防护、验证码、IP风险、手机号风险、链路风险等。

能力层是风控系统的基石，它的能力决定了一个风控系统识别风险能力的下限。会从资源、接口、设备、链路、行为等维度进行系统性风险扫描。

计算层

能力层的职责是：补充风险识别能力。

该层包括：数据引擎、规则引擎、风险名单、识别模型、风险预警。

计算层是对基础安全风险识别能力的补充，它的能力决定了一个风控系统识别风险能力的上限。从频率统计、策略规则、风险名单、模型识别、风险预警等维度对能力层进行能力补充。

可视层

可视层的职责是：提升运维效率。

该层包括：运维报表、引擎配置、流量监控、事件追踪。

可视层能够在事前能够分析风险潜在风险，事中有效执行并降低配置错误概率，事后观察风控效果。满足运营策略调整与风险管理的需求。

因为目前主要深入了解与实践的是组件层和能力层的建设，所以文章后续会从基建（基础安全产品）的视角进行系统性总结。

基础安全组件落地难点

• 接入场景多
  拉新激活、账号、反爬（多业务线）、交易（多业务线）、营销（多业务线）。
• 接入终端多
  ADR（多技术栈）、IOS（多技术栈）、WX（原生、非原生）、WEB、TOUCH。
• 接入组件多
  

​        防护组件（指纹、环境检测、接口防护等）、验证码组件、登录组件等。

架构特性

在进行架构设计时，我会重点关注架构的这三大特性，分别是：安全性、易用性、稳定性。

全性

因为是安全组件，其识别能力和组件自身安全性是首先要保证的。

稳定性

组件会应用在各个场景，所以要尽可能降低由安全组件造成故障的概率。

易用性

尽可能降低业务接入的成本。

具体案例

以接口防护组件设计来举例。

问题分析攻击场景

（以ip138查询网举例，不代表本人对该网站进行过攻击）

海鸥一飞

攻击还原

思路描述

请求离开容器后，通过抓包的方式，获取并解析数据，然后进行数据篡改、伪造鉴权，最后重新构造数据并发送请求。

攻击步骤

（1）抓包；（2）解析数据；（3）数据篡改；（4）伪造鉴权；（5）构造数据；（6）发送请求。

攻击步骤防御可行性分析

防止抓包

（1）抓包在应用外进行；

（2）除App，其他端防抓包基本不可防；

（3）防御性价比不高。

防止解析

解决方案是加密。

（1）入侵性较强、强依赖；

（2）加解密服务稳定性要求高；

（3）业务响应时长上升。

系统设计系统架构

描述系统分层、职责、关系以及运行规则。

组件层

提供接口防护组件、验证组码件和登录组件。

透传层

通过数据共享或业务系统透传方式透传风控参数。

决策层

进行入参校验、版控、能力使用以及反制决策等。

能力层

提供接口检测能力等。

架构特性
安全性

全性的难点除了风险识别上的难点，还有就是面对多个终端（Android、iOS、小程序、PC、Touch），其底层逻辑完全不一样。我们如何总结出统一的设计思想（方法论）这样的类工程问题。

如防容器脱离，我总结的思想就是：上层与业务逻辑建立联系，中层多个组件间建立联系，下层与操作系统（WX容器、浏览器）建立联系。

稳定性

易用性

（1）组件化

关于前端组件的易用性，不能与业务过于耦合，需要根据业务特性进行适当地解耦。如果与业务系统过于耦合，首先是在对防护逻辑进行升级时势必会影响业务，就需要投入测试人力进行业务逻辑回归，其次是防护能力往其他场景迁移也会有代码重复冗余的问题。

（2）易用性提升

如何在组件化的前提下进行易用性提升？我坚持的原则是尽量在不入侵业务的前提下，降低接入成本。

我的解决方案是，结合项目前端技术栈特点进行如下选择：

a）方式一：是否有统一的网络框架？

​        如使用安卓原生技术开发、苹果原生技术开发一般企业都有统一的网络框架进行网络出口管理，这时组件就可以从中找一个切面进行组件接入。

b）方式二：是否有统一组件？

​        如小程序（或Android Hybird等）没有封装统一的网络库，而是页面直接使用HTTP协议发送请求，但有统一的工具库，此时可以帮业务提前做好组件引入工        作，业务使用时        直接本地调用即可。这也可以一定程度地提升易用性。

c）方式三：是否可以引入三方组件？

​        如网页端（WWW、TOUCH）提供好完整的风控.js文件，业务方使用时直接调用即可，虽然不如以上a、b两种方式更友好，但要强于代码拷贝的方案。

最后

软件工程没有银弹，逆向工程永远胜利。

懂的不多，做的太少。欢迎批评、指正。