本文主要是讲一讲 toC 的基础业务安全该怎么做，实际上各大厂的做法都是为核心业务量身定做具体的方案，但建设基础业务安全的大思路都是一致的。
基础思路
做基础建设时，生产网被入侵、脱裤或者某个网页被挂马，这是天大的锅。小公司还好，影响范围有限，大公司的话还要和监管知会并放出相应的影响。而业务安全的建设思路更像是筛子：
追求抓大放小：业务安全的目标实际上是相对而言的，众所周知黑产是永远打不尽的，解决绝大部分，并有相应的识别能力就算做到及格线了
降低黑产作恶者的ROI：通增加黑产的操作成本，降低他们的不合法收益，以账号注册为例，黑产都是在应用程序早期阶段囤积大量账号，所以在你应用启动时，你就要考虑用什么样的验证码、邮箱 OR 绑定手机；做 IP 控制、客户端允许注册数限制、请求头限制、设备信息限制等等，这些都是特别基础，实现难度不大的方式
收集大量数据：这里要注意相关的隐私法规，国内就不说了，国际上还有GDPR CCPA之类的，没用大量数据支撑，算法做的再好，没法训练没法聚类，搞风控一定是玩不转的
纵深防御：安全领域中经典概念在这里一样有用，举个例子，做风控数据时候先用机器初筛，用漏斗过滤以便后续的人工抽样 case
多更新：无论是客户端还是 web 前端，黑产都能通过逆向手段来模拟出应用程序的行为，作为开发者几乎没办法避免你的端被逆向出通讯协议，唯一能干的就是多换算法，小版本更新小的协议参数，大版本脱胎换骨，但做这个很麻烦，在一些小步快跑的互联网公司不太好推
黑 IP 库、黑手机号库、弱密码库等等：小厂玩不转，而且还可能有被监管的风险
账号安全的思路
这里要分两类，依旧以 toC 模式来讲，账号体系可以认为是两类，一类属于强账号体系，你不注册账号用不了这些应用，例如闲鱼、例如微信；另一类是相对较弱的账号体系，例如百度，什么值得买等，但大趋势是所有的应用都在往强账号体系走，不用账号登录你就不能体验应用完整的功能。
做账号安全的基础业务安全需要做这些：
注册阶段：要不要做接口防刷、要不要上 MFA、验证码、要不要做些特殊的难逆向的算法，再细致一点的话，要不要做防重放？要不要对注册流程做形式化验证？这都是要考虑的，当然，还有要考虑商业相关，例如你注册防刷做的太好，运营想买量都难对不对。。。
登录阶段：和注册有些重合，要考虑撞库、暴力破解、盗号、非常用设备登录，这些都是很基础的对抗手段；再从大一点的视野考虑，你应用的登录入口是只有一个吗？除了 Web、APP端之外，有没有放出其他的登陆形式，例如某些 API、SMTP等等，这些都是要在设计阶段好好考虑的。稍微高级一点的，是不是要做好用户画像，以针对不同异常级别登录来做出不同的挑战？当然从我的角度看，做好基础就暂时够了，不是大厂就别想高级货了，因为没数据，一方面是用户不够，另一方面是采集到的数据太少。
密码重置：单独要把密码重置这一块拎出来说，有时候找回密码这个功能会惹出很大麻烦，设计没经过大量验证，自行设计的流程有逻辑漏洞，这时候被黑产逮到就惨咯，一方面大量的用户被黑，可能被黑产控制；另一方面要是再涉及到丢钱就更麻烦了...当然，有些应用会设计好支付密码，能略微减轻一些这方面的影响。
多设备登录：多设备登录要控制，例如，我们应用的设计可以是，允许 PC客户端、手机客户端、网页端、电视端这种不同类型的登录；但不能允许两个 PC 端或者两个手机客户端同时登录。再例如 Google 的安全设计是允许交叉登录验证，例如你在常用手机上登录了你的 Gmail，但是你如果在新设备做网页登录时，你可以用手机做两步验证，在手机上点允许就能在新设备的网页上登陆了，同时你的 Gmail 会受到一封新邮件告诉你有异地登陆。国内一般喜欢做短信通知。
（平台型公司）账号共享体系建设：这一步我相信小公司不会有太多涉猎，主要是中大型公司有很多个 Web App，而这些 App 都是通过单点登录做的账号共享体系，也就是说一套用户名和密码，可以在各个子应用上登录（假设有权限的话）。从更高角度看，这样设计带来了相当好的便利性，但也会引发”单点故障“，也就是说一旦用户被 XSS 盗了 token 之后，就等于用户全部的子应用都沦陷了。如何解决呢，我看过百度的客户端实现，它加了一个参数叫 BDUSS，针对不同的业务选择是否验证 BDUSS，例如下载就必须要有 BDUSS，这个 BDUSS 是服务器签发的。
以上面就是账号的业务安全的基础，也就是说小公司至少做到这样才算基本完备。接下来再举个例子：
电商交易中的风控思路
假设你搞了一个初创电商公司，为了拉新你们运营搞了个活动，原价抢茅台，你如何保证这些茅台真的被你的客户抢走了呢？而不是被黑产薅走？
这就又是业务安全的范畴了，你的目标是：
以原价销售茅台的形式，增加平台的用户数和月活。你希望原价茅台被真实用户买走，而不是被一堆黑产薅羊毛。
基础做法：
账号安全：前面讲过了，第一步也是最重要过滤手段，如果账号安全做的好，你可以通过账号这个大筛子干掉一大批恶意用户；同时没有那么多人挤入你的平台，平台甚至还可以变相达到节约成本的目的，毕竟一次抢购原价茅台机会，流量上来了和DDoS没啥区别了也。
拆分业务：啥意思呢？这是个小的点，把抢购类的业务安全域要和其它业务分开，不止可以避免一波流量下来主站都挂了，能更好的优化资源配置，从运维角度看能省钱、省机器，能提升系统稳定性；另一方面从安全的角度看，隔离能很好的降低攻击面。
业务流程优化：临时更改页面逻辑（如果你协议逻辑变更的够多，黑产来不及做逆向就达到目标了，但要注意你改逻辑的时间，下发的慢正常用户的页面还没变你就开始抢购，那大家就都没得玩咯）、临时增加难以绕过的验证码（例如旋转为正的验证），这些都是小技巧；稍高级点的就是通过建设好的风控系统识别用户，无论是画像还是行为逻辑都行，但这个又回到了小公司玩不转这点了
反爬逻辑：假设公司太小，没啥风控系统怎么办？那就做些简单的反爬，可能有些爬虫不解析js代码；如果黑产用无头浏览器，就要看 plugins之类的参数了，高级前端有很多方式检测，不过这里又涉及到准确率的问题
以上都是技术手段，但其实做安全有时候要做一些跳出技术视角的东西，技术不一定能解决的东西还有其他方案。举个例子：山姆会员抽茅台，你办会员卡还不行，需要办卓越会员，一次性投资六百多；办完会员卡还要每月有消费；每月消费还不行，你还得要在北上广深这些地方有实地消费记录；这三板斧下来，黑产的成本直接起飞，这也是一种参考视角咯
以上只是很基础很基础的风控，做到上面只能说是勉强到了60分，实际上要做好风控远不止这些工作。
一套完善的风控业务安全建设中，是跨多领域的，例如你要做需求分析、风险分析、特征分析、风险建模，还要做好相应的应急响应和紧急回退计划。假设你搞了一套自认为很强的风控，结果推送下去误打击率高的离谱，全网都是负面新闻怎么办？”引咎辞职“？第三方视角只能认为你是捅了篓子就跑，擦屁股还要留给继任者...
最后
业务安全是一个很大的话题，也是一个值得深入研究的领域，本文也只是写了很少很少的部分。业务安全的起源纯粹是黑产，上古时期黑产就通过入侵，拖库，然后卖数据去赚钱。但现在随着互联网承载的各种业务的兴起，黑产盈利的门槛开始降低，不再须要入侵了对方才能套利，仅通过业务层面的漏洞，通过灰色手段就能获利。
扯一点题外话。
实际上绝大部分公司对整个安全的重视度都太低了，为什么？
做安全太贵，不说拉一整个团队来揽下广义上信息安全的工作，单说设备，一套 AC + AF + EDR 价格就奔着六位数去了，并且还是持续式投入。
从甲方公司的角度看，做安全很难看到实际的效果，无论是你写了个多少个自认为牛b的规则，抑或是自行实现了一套轻量级、分布式、拓展性极强的 HIDS，再或者你是个挖洞大拿，0 day手拿把掐，但对于甲方公司来说，这些都是纯成本部门，我们很难拿出可量化的”表“来说服管理层。
啥情况下管理层会认真思考安全的重要性呢？被拖库了，数据泄露了一大批；又或者生产网服务器被拿下之后当肉鸡；或者办公网全部被勒索病毒拿下，这时 CTO 觉得，不行，我需要几个人来救火，于是安全团队就来了。
安全行业的从业者也是一样，有些人觉着安全压倒一切，只要安全不出问题，业务死掉无所谓，这种就属于典型的甩锅心态，不是说这样子不对，工作而已，但这样做安全很难获取运维团队和研发的支持；还有些人从业时间不长，一腔热血和理想觉得”安全真的不可或缺“；或者是乙方心态 - 过度强调安全，过度鼓吹新技术，毕竟要靠安全吃饭嘛，可以理解。
难搞，只能说越来越好吧！
吐槽一句：我想找个 Web 3 的工作机会咋就这么难！