博客

安全动态
投稿至邮箱: 在线投稿

当你说数据为王

作者:大番薯 公布时间:2016-05-09 阅读次数:5620

当你说数据为王

相比数量,我们更应关注数据质量。数据为王本身并没有错,问题是怎样的数据才能为王?

典型误区:只要数据多就能解决问题

当你说数据为王,通常会伴上大数据、Hadoop、Storm等一系列高大上的名词概念。我所在的团队每一天都在和数据打交道。我们建立了一套以数据为核心的风控运营体系。我们也注意到同行里很多企业都建立起了自身的风控系统,并且“数据为王“常常被大家挂在口边。

华丽风控系统背后是强大的数据技术支撑,然而一句“数据为王”却是风控建设过程中无数惨痛经验教训的总结。本篇不谈成功,我们只谈失败,谈谈那些决定风控系统能否真正取得成功的决定性因素。

关注数据质量

完整性

在某款玫瑰金手机首发的秒杀活动中,黄牛动用了有史以来最强大的资源向我们发起了最凶残的抢购请求。此时选购线各个接口开始报错,后端压力骤然飙升,监控系统疯狂告警。

为快速问题,团队筛选并封禁了大量IP地址,但仍然不能彻底解决后端系统的压力。大概有上千个的黄牛账号在持续更换IP疯狂请求购物车前端接口,压力传递到了后端。此时除了封禁IP,业务风控团队还需要快速识别黄牛所使用的ID并予以踢下线和冻结。

问题来了:通过这些异常IP向服务器发起请求的账户到底有哪些?从了解到的情况看,现有系统的日志包括:Nginx日志和购物车数据库记录。

购物车接口请求日志(Nginx)

http://example.com/cart/add.php?&product_id=1111&ip=1.1.1.1

购物车业务日志(MySQL)

cart_iduser_idproduct_idtime
112311112016-03-03 10:00:10
245611112016-03-03 10:00:12
378944442016-03-03 10:00:13

很显然Nginx日志中能够看到接口的参数,有商品,有IP,就缺少UserId。购物车数据库中存储了商品Id和UserId,但却没有IP。在这样的现实条件下,再强大的风控系统也无能为力,因为两组日志数据都不完整,任何一组都不能算是完整的信息。

试想,如果接口或MySQL两者中的任何一个能够完整记录一次购物请求的关键日志,业务安全监控绝不会如此被动,很显然我们需要的是这样的日志记录:

http://example.com/cart/add.php?&product_id=1111&ip=131.1.1.1&userid=123

或者:

cart_iduser_idproduct_idclient_iptime
11231111131.1.1.12016-03-03 10:00:10
24561111208.2.2.22016-03-03 10:00:12
37894444127.1.1.12016-03-03 10:00:13

准确性

经过上一次经验教训,购物车团队依照我们的要求在数据日志中同时增加了用户ID和IP两个信息。那么我们是不是可以轻松应对下一次抢购了呢?鼻青脸肿之后,我们明白——想得太简单了。由于公司网络架构的原因,购物车接口同时接受来自LVS、F5等不同设备的请求,这期间一个负载设备的错误配置导致购物车底层看到的用户IP地址为内网地址,而非用户真实IP!

cart_iduser_idproduct_idclient_iptime
11231111192.168.9.82016-03-03 10:00:10
24561111123.10.1.12016-03-03 10:00:12
37894444219.23.2.22016-03-03 10:00:13

好吧,如果你看到的IP已经不是真实攻击者的IP,那么如何才能执行封禁IP呢?

多样性

对异常订单进行二次筛选是风控运营人员每天在做也是最为头疼的工作。举个最简单的例子,下述订单一眼就能看出是异常。

order_idorder_timeorder_address
12016-04-16 12:00:01广州市.番禺区.氓气氕氖路1号
22016-04-16 12:00:02广州市.番禺区.気氘氙洔路2号
32016-04-16 12:00:03广州市.番禺区.洣津洦洧路3号
42016-04-16 12:00:03广州市.番禺区.紣崔败䴧路4号

但是,如果如果面临特征不明显的订单时,单纯依靠订单自身的信息是很难判断这些是否为异常订单。很显然,在分析异常订单时,风控运营人员需要更多的辅助信息以增加识别精准度和降低误报率。针对上述情况,如果增加人机识别等多样性数据,系统或运营人员能够再次降低异常订单的误判

order_idorder_timeorder_address页面浏览次数
12016-04-16 12:00:01广州市.番禺区.人民路102号20
22016-04-16 12:00:02广州市.番禺区.南朝大街105司库书城0
32016-04-16 12:00:03广州市.番禺区.胡杨小区2幢1010
42016-04-16 12:00:03广州市.番禺区.区政府大门口对面包子店5

这里只增加了一项最近出的PV计算,就能为识别恶意订单提供有力的佐证。

数据埋点&审计

无数血与泪的经验告诉我们,要做好业务风控,必须要让业务系统提供足够可用的日志记录,有时我们也称之为“埋点“。那么到底哪些信息是关键的,哪些又是必须记录下来的呢?我的团队对过往的日志记录和分析过程做了多次梳理和总结,最终形成如下结论。任何数据埋点必须包含以下几大要素:

  • 时间

    • 日期

    • 时间戳

  • 用户

    • 用户ID

    • 用户登录名

    • 用户手机号

    • 用户邮箱

    • 第三方账户唯一识别号

    • 用户付款账户

  • 设备

    • IP地址

    • IP段

    • IP地理区域

    • 客户端浏览器

    • 客户端APP

    • 微信

    • H5页面

  • 资源

    • 用户信息

    • 商品信息

    • 购物车信息

    • 订单信息

  • 访问方式

    • Web访问

    • APP访问

  • 访问结果

    • 成功

    • 失败

举一个例子:

2016-04-19 12:00:01,1234567,customer001@vip.com,13888888888,113.65.254*,广东.广州,login,android,v2.11,failed

最终解决问题的是你值得信赖的基础数据和分析方法。

最后才是数量

好了,我们已经解决了数据质量,接下来我们来解决数量的问题。嗯,我考虑好了,放在下一期:)

我将以业务风控为主题进行连载,关注VSRC微信公众号可以第一时间获取信息。变的是笔名,不变的是公众号,关注我吧。

原文:

http://mp.weixin.qq.com/s?__biz=MzI5ODE0ODA5MQ==&mid=2652277114&idx=1&sn=82afefde2b29c494347c897d211e2ac9#rd