当我们的产品使用者越来越多的使用者加入，流量越来越大。各种牛逼投资机构开始看上了你的时候，很多灰色地带的黑手也开始盯上了你这块流量蛋糕。这时候，对于使用者异常行为的防护就会变得越来越重要。但是，往往现实总是那么残酷，无法拒绝的业务需求与不得不做的安全管控，在一定的成本控制之下，对于人力的投入选择变得异常艰难。对于这样的场景，TJ给大家推荐下面这个开源专案：

- 专案名称：陌陌风控系统静态规则引擎- Github：https://github.com/momosecurity/aswan

架构介绍

后台介绍

名单型策略描述符为**{引数名:单选,假设是“使用者ID”} {操作码：在/不在} {XX专案:单选，可选全域性} 的 {维度：单选}{方向：黑/白/灰名单}**示例：使用者ID 在 初始专案 的 使用者黑名单 中

布林型策略不传阈值的布林型，描述符为 {引数名:单选，假设是"账号ID"} {操作码：是/不是} {内建函式：异常使用者} 示例：账号ID是异常使用者传阈值的布林型，描述符为 {引数名:单选，假设是"账号ID"} {操作码：大于/小于/等于/不等于} {内建函式：历史登入次数} {阈值：170} 示例：账号ID历史登入次数大于100

内建函式是什么？就是自定义的一些逻辑判断函式，只需要满足要求返回布林值即可。比如注册时间是否在某个范围以内，当前装置是否是常用装置。时段频控型策略描述符为 同一 {计数维度:单选，假设是“装置”} 在 {时段：时间跨度} 内限制 {阈值：整数N} 次 某动作 示例：同一装置一天内限制操作10次. 可是我怎么知道当前已经有多少次呢？这就需要上报，上报后将计数 详见第9条 资料来源管理

限使用者数型策略描述符为 同一 {计数维度:单选，假设是“装置”} 在 {时段：时间跨度} 内限制 {阈值：整数N} 个使用者示例：同一装置当天限10个使用者 此策略同样需要上报的资料，且由于与使用者相关，因此上报资料中必须包含user_id字段(在资料来源中需配置) 详见第9条 资料来源管理

规则管理管控原子：命中某条策略后的管控动作，比如拦截... 把上面2--5中所述的策略原子按照优先级组合起来，由上向下执行，直到命中某条策略，则返回对应策略的管控原子。此模组更多是重互动，完成策略的配置、组合、权重等等

日志管理所有命中策略的日志均在此展示，也会包含审计相关的日志，下一期会基于此日志，开放拦截溯源功能。

许可权配置供许可权设定使用，精确限定某个使用者能看哪些页面的资料。 详见 其它 -- 许可权管理。资料来源配置示例策略：同一装置一天内限制登入1000次 那么每次登陆就需要上报一条资料，系统会分类计数，并分类储存。 储存的名字叫啥？就是此处要配置的资料来源。对于此策略，只需要配置资料来源，命名为login_uid, 字段包含uid, uid型别是string。然后程式就能根据uid为维度计数，并自动计算指定时间视窗内是否超出指定阈值。重要：由于逻辑必然依赖时间资讯，为通用且必需字段，timestamp为预设隐含字段，型别是时间戳(精确到秒，整数)

呼叫样例

呼叫上报服务假设存在名称为test的资料来源, 且资料来源含有的资料是: {"ip": "string", "user_id": "string", "uid": "string"}curl 127.0.0.1:50000/report/ -X POST -d \'{"source": "test", "user_id": "10000", "ip": "127.0.0.1", "uid": "abcabc112333222", "timestamp": 1559049606}\' -H "Content-Type:application/json"

关于服务拆分开源样例中，为了简化安装部署，查询和上报揉进了一个服务。实际场景中，显然读写应该分离。1.可以直接此方式部署2份，域名不同，一份用于查询(上报界面不被访问)，一份用于上报(查询界面不被访问)，流量分发在nginx层完成2.risk_server.py中修改配置URL_2_HANDLERS，选择您需要的服务界面部署内建函式的扩充套件

不带阈值的内建函式扩充套件以是否异常使用者内建函式为例程式码见 aswan/buildin_funcs/sample.py 中的 is_abnormal 方法带阈值的内建函式布林型策略扩充套件以历史登入次数内建函式为例程式码见 aswan/buildin_funcs/sample.py 中的 user_login_count 方法注意：阈值计算不包含在内建函式中进行，控制流详见 aswan/buildin_funcs/base.py

其它

考虑到企业使用者大多数为域账户登入，因此推荐使用LDAP认证模组直接整合。但考虑到大家的场景不一样，因此也可以手动增加使用者，样例程式码如下:

# coding=utf-8

from django.contrib.auth.models import User

username = \'username\'

password = \'password\'

email = \'[email protected]\'

first_name = \'测\'

last_name = \'试\'

# 普通使用者

User.objects.create_user(username=username, password=password, email=email, first_name=first_name, last_name=last_name)

# 管理员账户

User.objects.create_superuser(username=username, password=password, email=email, first_name=first_name, last_name=last_name)

新增完成后，让使用者登入，然后管理员配置许可权即可。

许可权管理

目前的许可权模型包含如下元素，可在对应的页面进行配置。

具体图示如下:

配置相关

为了在不同环境载入不同的配置，我们使用了RISK_ENV这个环境变数，系统在执行时会自动通过这个环境变数的值载入对应的配置档案。

为了方便专案启动，在未设定这个值时，系统预设会载入 develop 环境的配置。而在执行测试时(python manage.py test)时，RISK_ENV的值必须是 test 。

转载自公众号：TJ君