快手12·22事故原因的合理猜测

终于到了自己擅长的领域,就随便写写图一乐吧

先简单介绍下自己,到目前在大厂做了三年半的安全产品,做了两年直播内容安全产品,对风险防控算是有所了解

风险防控的基本流程算是三步走,定标准,依据标准识别风险,对风险内容&账户进行处罚

其中风险识别的流程绝大多数场景是先过一遍机器审核,机器判断不了的再过一遍人工审核

在内容安全里面,直播比较特别的一点是,直播很难做到先审后发,都是先发后审,就是你直播过程中,发现你可能存在风险行为,再召回进行审核,所以一但出现风险内容,线上用户是可以直接看到的,不存在说先审核内容再让你直播;这也是为什么这次风险集中在直播爆发,短视频存在先审核再发布的机制,可以规避上述风险

在这次的事件里面,怀疑有以下三种可能

1.黑产在夜间,人工审核人力较为不足的节点,通过预先识别好的方案,绕开机器审核,大量进行违规内容的直播,这个时候,由于业务低峰期,人工审核较为不足,加上上述直播场景不能先审后发,就导致线上出现大量风险内容没有人工审核,造成风险外溢

2.黑产攻击了下发处罚的接口,导致无法对违规内容和账号进行处罚,进而导致风险外溢

3.并非黑产主动攻击,而是因为风险内容暴增,导致处罚接口性能出现问题,导致无法处罚

以上三种可能里面,我更倾向于第二种,因为昨天外溢的风险内容是多样的,有色情,也有血腥暴力,不同风险类型会有不同的识别算法和模型,黑产很难同时突破多个防线,要想同时几种风险内容都出现在线上,最大的可能就是处罚出问题了,而故障持续时间这么长,结合今天快手突然开始大量招聘网络安全工程师,我会更加怀疑是内部系统被攻击了

那有什么方法可以尽可能减少这种风险呢,我们风险防控会分为三步走,事前事中事后,然后可以针对四类主体做管控(自然人,设备,账号,内容),在这个场景里面,其实我们事前可以做很多,最直接的就是识别到容易发布不良内容的风险账户,前置不允许直播或者提升开播门槛;举几个例子,我们可以要求注册x天内账户开播前必须人脸认证,也可以回收x天不活跃账户的直播权限,必须在平台有一定的活跃行为后才允许直播,也可以识别客户端行为,检测到录播的中断直播/减少推流;本质上增加黑产的作恶成本,就能解决绝大多数黑产问题,因为黑产也不是傻子,不会亏钱,让他们作恶成本变大,赚不到钱,自然就不会作恶了;在事前能做的管控其实很多,不要什么都留到事中来做,事中对系统性能和时效要求就非常高了

当然,放在事前来做会有一个问题,就是一定会有人因为你对他进行直播拦截了,就不直播了,肯定会对业务核心数据有少许影响,那到底是保风险还是保KPI,那就仁者见仁智者见智了

相关推荐
itmigrate5 小时前
前端项目里,Object.is 并不是 === 的平替
前端
喵了几个咪6 小时前
GoWind CMS 拆解:在 Go 里给 TipTap 搭一套 Yjs 协同后端
开发语言·后端·golang
Flynt6 小时前
我把微信运动的排行榜和定点推送复刻了一遍:100万次步数更新只要4秒,坑在别处
redis·后端·性能优化
小大宇7 小时前
Vue知识点6-computed计算属性
前端·javascript·vue.js
程序员海军7 小时前
尤雨溪 : Vue 4 已经在规划中了!
前端·javascript·vue.js
2601_949970697 小时前
HumanizeDuration 跨端三方库仓颉适配全流程
前端·javascript·flutter
_孤傲_8 小时前
快速掌握 MySQL 语法
数据库·后端·mysql
风骏时光牛马9 小时前
后端服务接口开发与性能优化
前端
kyriewen9 小时前
我让 4 个 AI 互相 review 代码,最温柔的那个下手最狠
前端·程序员·ai编程
计算机魔术师9 小时前
493家公司白砸AI钱?Apollo这组数据戳破了幻觉
前端