- 背景
-
风控业务架构
- 组件层
- 业务层
- 决策层
- 能力层
- 计算层
- 可视层
-
基础安全组件
-
落地难点
- 接入场景多
- 接入终端多
- 接入组件多
- 待解决问题
-
架构特性
- 安全性
- 稳定性
- 易用性
-
问题分析
- 攻击场景
- 攻击还原
- 攻击步骤防御可行性分析
-
系统架构
- 组件层
- 透传层
- 决策层
- 能力层
- 安全性
背景
本篇文章会从系统架构设计的角度，分享在对业务安全相关基础安全产品进行系统设计时遇到的问题难点及其解决方案。
文章会以总-分的形式进行阐述。懂的不多，做的太少。欢迎批评、指正。
风控业务架构
6层，分别是组件层、业务层、决策层、能力层、计算层、可视层。
基建为基础安全产品的简称。
组件层
数据收集与行为反制。
更详细的思考在《风控安全产品的探索之路》这篇文章中，感兴趣可跳转阅读，这里就不再赘述。https://www.cnblogs.com/boycelee/p/15948323.html
业务层
风控数据透传与风控决策结果处理。
透传数据一般包括：风控数据和业务补充数据。
决策层
风控能力应用。
这一层的难点在于工程而非安全领域，例如：如何设计调用链路（降低计算时长）、如何处理超高并发流量、如何保护下游风控内部系统等。
能力层
能力层的职责是：识别基础安全风险。
能力层是风控系统的基石，它的能力决定了一个风控系统识别风险能力的下限。会从资源、接口、设备、链路、行为等维度进行系统性风险扫描。
计算层
补充风险识别能力。
计算层是对基础安全风险识别能力的补充，它的能力决定了一个风控系统识别风险能力的上限。从频率统计、策略规则、风险名单、模型识别、风险预警等维度对能力层进行能力补充。
可视层
提升运维效率。
可视层能够在事前能够分析风险潜在风险，事中有效执行并降低配置错误概率，事后观察风控效果。满足运营策略调整与风险管理的需求。
因为目前主要深入了解与实践的是组件层和能力层的建设，所以文章后续会从基建（基础安全产品）的视角进行系统性总结。
基础安全组件
落地难点
-
接入终端多
ADR（多技术栈）、IOS（多技术栈）、WX（原生、非原生）、WEB、TOUCH。
-
接入组件多
接入场景多
待解决问题
架构特性
在进行架构设计时，我会重点关注架构的这三大特性，分别是：安全性、易用性、稳定性。
安全性
稳定性
组件会应用在各个场景，所以要尽可能降低由安全组件造成故障的概率。
易用性
具体案例
以接口防护组件设计来举例。
问题分析
攻击场景
（以ip138查询网举例，不代表本人对该网站进行过攻击）
攻击还原
思路描述
攻击步骤
攻击步骤防御可行性分析
防止抓包
（2）除App，其他端防抓包基本不可防；
防止解析
（1）入侵性较强、强依赖；
（3）业务响应时长上升。
系统设计
系统架构
组件层
提供接口防护组件、验证组码件和登录组件。
透传层
决策层
进行入参校验、版控、能力使用以及反制决策等。
能力层
架构特性
安全性
关于安全性另一篇文章《业务安全相关安全产品的反思》中已经详细阐述，这篇文章就不过多赘述。https://www.cnblogs.com/boycelee/p/16223114.html
多个终端（Android、iOS、小程序、PC、Touch），其底层逻辑完全不一样。我们如何总结出统一的设计思想（方法论）这样的类工程问题。
上层与业务逻辑建立联系，中层多个组件间建立联系，下层与操作系统（WX容器、浏览器）建立联系。
稳定性
易用性
（1）组件化
（2）易用性提升
尽量在不入侵业务的前提下，降低接入成本。
a）方式一：是否有统一的网络框架？
安卓原生技术开发、苹果原生技术开发一般企业都有统一的网络框架进行网络出口管理，这时组件就可以从中找一个切面进行组件接入。
如小程序（或Android Hybird等）没有封装统一的网络库，而是页面直接使用HTTP协议发送请求，但有统一的工具库，此时可以帮业务提前做好组件引入工 作，业务使用时 直接本地调用即可。这也可以一定程度地提升易用性。
如网页端（WWW、TOUCH）提供好完整的风控.js文件，业务方使用时直接调用即可，虽然不如以上a、b两种方式更友好，但要强于代码拷贝的方案。
最后
懂的不多，做的太少。欢迎批评、指正。