徐州服饰网站建设,国外平台卖货,校园网站建设简介,关于文化馆网站建设的材料| 在互联网时代#xff0c;安全已经成为企业的命脉。美团信息安全团队需要采用各种措施和手段来保障业务安全#xff0c;从而确保美团平台上的用户和商户利益不会受到侵害。 本文主要介绍了美团在打造自有规则引擎Zeus#xff08;中文名“宙斯”#xff09;的过程中#x… | 在互联网时代安全已经成为企业的命脉。美团信息安全团队需要采用各种措施和手段来保障业务安全从而确保美团平台上的用户和商户利益不会受到侵害。 本文主要介绍了美团在打造自有规则引擎Zeus中文名“宙斯”的过程中信息安全团队遇到的挑战以及对应的解决方案并分享了很多踩过的坑同时还有一些思考和总结。希望对从事安全领域相关工作的同学能够有所启发或者帮助。 背景 美团App每天都面临着各类的欺诈、盗号、作弊、套现以及营销活动被恶意刷单、恶意抢占资源等风险。而业务安全团队采用的主要措施和手段就是在业务请求中识别出谁、在什么时间、通过什么方式、做了什么事。这个识别逻辑的制定过程叫做策略的生产。同时还要对已经完成生产的策略进行快速的验证和落地以防止风险变化后策略失效。从发现风险经过策略生产、验证再到最终的落地部署全流程的处理速度和效果将决定整个业务的成败。 在业务发展初期我们可以通过硬编码的方式将风控逻辑部署在业务逻辑中实现但美团的业务比较复杂从最初的团购形式经过与大众点评、摩拜、猫眼等业务的融合发展到涵盖餐饮、到店、猫眼、外卖、金融、酒店、旅游、大交通等多个垂直领域。随着业务的快速发展适用于初期的硬编码方式出现了策略分散无法管理、逻辑同业务强耦合、策略更新迭代率受限于开发、对接成本高等多种问题。此时我们需要有一套可配置化的规则管理平台进而实现风控策略与业务解耦、快速部署、验证。 但规则引擎的建设初期会面临着各种困难和挑战主要包括以下几个方面 在业务层面垂直领域多包含几乎所有的吃喝玩乐服务。美团细分业务多达百个。服务用户角色多用户、商户、供应商、渠道商交易频率高日订单量大。在风险层面存在用户作弊、商家刷单、账号盗用冒用、支付和信贷等多种风险。在企业外部环境层面黑产已形成自下而上的产业链攻击方式升级比较快速。 针对以上这些挑战我们打造了自有的规则引擎 Zeus中文“宙斯”来源于“宙斯盾”作战系统的启发期望规则引擎平台能同“宙斯盾”一样成为先进的中央作战决策系统实现对风险的精准、高效打击。 下面我们就来具体介绍一下美团信息安全团队在系统构建过程中面临的挑战以及对应的解决方案。 挑战与方案 1. 业务多-接入成本高 规则引擎最早只是业务系统中的一个函数逐步演化成了独立的服务。而这个独立服务与业务后台的交互是单点方式即业务后台在关键动作节点前调用规则引擎判断“有没有风险”。但这样每次新增加一个业务或新出现一个风险场景时规则引擎和业务都要重新进行对接联调。频繁地调整给上下游团队都带来了不小的负担而且在频繁的更改中系统质量也难以保证。如何便捷、快速地实现业务接入是系统设计的核心目标之一。 在接入成本上一次性集中接入往往是最便捷的方式。因此我们选择在每个业务都会通用节点接入规则引擎例如用户中心、商户中心、订单中心、收银台等均为各类业务的通用节点规则引擎同这些通用节点对接业务在调用通用节点时通用节点调用规则引擎即可完成业务的接入。 随着美团业务和场景种类的增多现在也存在不经过通用节点的业务。因此我们需要提供通用的接入接口目前业务侧直接调用一个独立服务接口即可获得风控判断。 2. 风险点多-逻辑复杂、逻辑复用 风险点多且业务多进一步增加了场景、策略逻辑的复杂度。表达式语言可支持的逻辑计算范围有限复杂的逻辑若仍通过硬编码实现会存在效率低、不易复用等问题。 受模块化思维启发我们将复杂的逻辑封装成模版实现配置化并支持逻辑复用。这样就大大提升了规则引擎可实现的逻辑范围。目前我们已经建设的几类常用的封装逻辑如下 扩展函数主要用于数据格式的提取和处理比如字符串、数组等格式转换、数据提取等。通过扩展函数功能对业务侧数据格式要求大大降低也降低了业务侧数据处理的负担。累计因子在业务中会高频使用到与累计相关的逻辑。例如在登陆、下单、支付等事件需要同IP的UserID进行计数计算计算结果作为特征引用在规则中。规则引擎引入了内部研发的高效事件计数服务实现累计通用逻辑的封装比如支持累计周期、计数/求和/最近几次、累计值等计算逻辑配置化等等。决策表因子部分业务中需要引擎处理的判断条件较多各条件又相互组合存在多种决策方案的情况这就需要用精确、简洁的方式来描述这类复杂逻辑。在低频使用时我们可以通过硬编码的case-when、if-else等语句实现但在实时性和配置化上不尽人意。最终我们通过决策表将多个独立的条件和多个动作直接地联系、清晰地表示出来并实现了逻辑的封装。名单库因子与名单库联动过程中将查询名单的逻辑进行封装。工具因子将一堆规则进行打包形成大的逻辑集合并对组成的规则设置评分。在执行时输出评分结果并实现跨场景、跨业务应用同时将大逻辑进行“黑盒”处理简化逻辑复用时的配置、沟通成本。风险点多的另一个挑战点是在多业务中会存在同质性即制定的风险策略是可复用的。当一百条规则需要复用在几十个场景中逐个配置的效率太低不仅一致性难以保障后续的修改也是问题。同时又衍变出部分复用、部分差异化让业务直接复用场景行不通。因此我们引入【规则组】的概念将规则聚类管理。比如众包识别规则组、虚假设备规则组、涉黄内容识别规则组等。业务在应用时可在自己的场景中进行差异化的应用。 3. 风险变化快、长期对抗-效果验证速度 当外部风险变化时风控的对抗也需要及时响应这是一个争夺“主导权”的比赛。风控通过对不同阶段的组合打击实现策略的健壮性包括用于识别有没有风险的基础对抗阶段、引导节奏混淆视听的“短平快”阶段、诱敌深入的“高精尖”阶段。对应系统需要支持不同阶段的策略配置、迭代和验证需求。而在策略迭代和部署阶段需要特别注意因配置错误导致的误命中问题。 参考开发环境分类测试环境、预发布环境和生产环境。规则引擎在规则的部署和迭代上可通过标记、双跑和回溯功能我们通过应用实时线上流量和历史数据来验证策略的有效性。 标记规则在场景中的状态标记状态的规则逻辑将灰度执行即与生效规则类似会实时执行但决策信息不实时返回给上游业务方不影响决策。同时用户可在实时日志查询中查看标记规则的命中情况。双跑规则在场景中的状态双跑状态的规则逻辑将灰度执行但仅会出现在修改生效规则、因子因子修改导致引用规则的逻辑执行变化时才会存在的状态。回溯规则在场景中的状态回溯状态的规则逻辑将灰度执行但仅使用回放的历史数据。通过这些功能可以降低策略迭代的风险缩短策略部署上线的时间周期。 思路总结 在确认清楚挑战和解决方案之后规则引擎的整体建设思路就已经形成了。现今规则引擎随着业务的快速扩张由一个内部系统逐渐发展为服务多个风控团队的公共平台。 从初期主要围绕风控防控痛点进行搭建的表达式服务包升级到配置化平台在配置效率和执行效率也得到了很大的提升。同时随着人工智能技术的应用和风控对抗进入白热化规则引擎也将从配置化快速迭代至自动化、智能化。 1. 确定核心快速论证、快速落地 在系统建设中进行了充分的论证后就需要快速落地避免因长项目周期需求发生裂变而导致不可控。在初期我们已经建立了aviator表达式服务包并稳定服务。因此配置化平台搭建时仍基于表达式语言引入场景、规则、因子、决策等概念搭建将策略的执行分为执行层和计算层。 执行层通过场景获得一堆规则集合规则执行完成后将其结果和对应的决策返回。 结果和在规则执行时会进行其构成因子计算。 2. 根据角色进行定向提效 规则引擎搭建的初衷之一是提升风控对抗的整体效率。在对抗过程中我们需要各种角色配合例如开发建设系统、策略制定者、策略使用者和风险用户等因此需要针对各类角色定向开展提效工作。 1风险用户处理提效风险用户 业务已经可以实时获得风控的决策但发现风险用户会在很多场景下重复攻击。对这类用户的处理除了对当次行为阻断还要阻断其未来的行为因此就有名单管理的诉求。我们通过与名单库的联动提升该类用户的处理效率。 例如在美团金融项目场景下严重逾期的用户会加入禁贷名单再次申贷时取消其贷款资格。 2业务接入提效业务方 除了上面介绍的统一接入外还有一种常见的情况业务无法在发起请求时就将执行所需要的全部参数准备好此时就需要引擎能主动获取外部数据。针对这类情况规则引擎通过数据接口的方式实现了外部数据的补充在策略执行时根据计算需要动态获取相关的参数。在实现与外部数据联动的功能后大大降低了使用规则引擎业务方数据准备阶段的压力从全部参数准备简化为仅提供核心参数即可剩余参数按需引擎自行调度即可。 3策略管理提效产品 策略产品是规则引擎的主要用户主要的工作流程是围绕策略管理、分析、验证进行提效。如何管理大量的规则和应用场景怎样快速验证策略有效性、评估误伤率客诉反馈问题如何快速还原规则命中情况针对这些维度我们分别提供不同的产品功能进行提效。 在策略管理层面可通过规则组方式、因子工具等进行同类规则集合的管理、打包和复用。在规则分析层面可通过实时查询规则的执行详细数据和将规则执行流程进行回放提升分析效率。在策略验证层面提供标记、双跑和回溯提升策略验证速度。4工程效率提效工程师 复杂的逻辑且具有通用性就可以对特征逻辑封装避免工程师重复进行逻辑开发工作释放出的开发资源可以进行其它维度的提效。 5算法/模型接入提效算法工程师 当对抗升级时策略的产生者由人变为算法/模型。而机器的生产效率远远高于人人工搬运算法/模型会成为迭代效率的瓶颈怎样跟算法、模型平台进行快速联动呢最简单、快速的方式就是使用引擎提供的外部数据联动方式将模型结果包装成数据接口使用。但在实践过程中我们发现模型的出入参数较多且存在变化整体的配置化效率低模型应用和迭代频率受限制。公司内部提供的深度学习还是算法工程平台目前主攻计算、训练等场景在上下游应用提供标准化的数据产出但无法同类似引擎的平台对接。 因此仅聚焦在引擎与算法平台的联动上可通过建设调度模块实现1.训练样本预处理–2.算法平台对接–3.自动化生成接口–4.自动注册接口/策略至引擎–5.评估任务启动–6.评估结果处理策略上下线、样本数据沉淀–1.训练样本预处理的闭环流程。 3. 发现问题、横向扩展、兼容更多场景 随着引擎在多业务场景的应用我们发现几个实时引擎不好处理的场景。比如拉新场景需要结合“注册登陆交易”等多种行为来判断是否有“薅羊毛”等黑灰产行为需要将很多事件放到一起去综合判定。当发现风险时或在当前时间点漏过的变异风险在发现之后需要对历史数据进行回捞这些在实时引擎中都不太好实现。当前已有的异步引擎也无法很好地进行覆盖。为了避免做“重复造轮子”的事情团队充分地讨论了实时、异步和离线引擎的定位和服务边界。 在实时引擎已经覆盖的逻辑基础上我们引入新的封装逻辑-个体因子全局因子实现SQL语句的配置化管理进而实现批量累计、聚合特征的计算比如近一年某商家的平均下单金额近30天商户大盘下单均值标准差等批数据的复杂逻辑。并基于Spark和实时引擎底层实现多流和批数据的处理解决上述场景无法处理的一些问题。 4. 业务实践结果 交易安全 策略产品在日常工作中通过对业务分析发现风险、挖掘风险特征并应用在策略中。通过Zeus实现策略的部署和应用大大降低了业务风险提升风险防控效率。例如在某业务地推场景中发现B、C端联合刷单风险以返利、送赠品收到诱骗下单。 金融安全 金融风控主要有反欺诈和信用安全。反欺诈同业务安全在策略形态上相同都是判断有无风险在决策结果上是通过和拒绝。因此通过普通决策即可满足业务需求。 但信用安全会比前两者复杂一些在决策上除了通过和拒绝外对于通过的请求要进行分层实现金融的差异化定价。因此需要在规则引擎中引入更多功能来满足业务需求。主要包括 路由场景可支持多层决策流模式即一堆规则的集合支持按照逻辑进行分流满足指定条件可以指定走向在每个节点进行条件设置实现最终流向。例如对于某分期场景用户申请一笔贷款需要经过欺诈识别、信用评估后方可给出最终的额度、定价。决策衍生参数适用于复杂的多级路由决策场景Key-Value型数据在决策中指定衍生参数信息从而在路由场景中产生全局传递变量比如流转过不同的场景需要将用户进行等级分类。决策附加信息适用于复杂决策场景Key-Value型数据在决策中指定附加信息从而实现更多决策信息的计算及返回比如加入风控名单库加入什么风险类型、风险等级、名单类型。 未来发展与思考 目前规则引擎正处于配置化阶段正在向自动化、智能化的阶段发展从而不断提升策略的管理和迭代的速度。但业务间的智能化诉求和进程不同平台可以提供更多集成托管服务从而提升各业务的智能化覆盖度。 其次引擎仍然存在无法处理的几个问题 一些长时间周期特征无法快速应用的问题例如近一年的时间周期。如何将离线引擎和实时引擎在特征计算上组合实现特征的快速生产、验证和应用从而扩展引擎的计算能力范围、提升风控业务的对抗效率。 当前引擎的接入对非复杂逻辑需求的业务就比较重。而接入成本是各业务接入时重点评估的因素如何实现快速、低成本的业务接入包括技术接入和人员操作接入考虑提供模块化的引擎计算服务能力适用于各类业务诉求实现按需接入比较“臃肿”的全局接入会更快速和便捷。但这种在引擎侧怎样更好地管理这些模块也是一个挑战。 最后业务流量和策略的增长速度仍在高速增长引擎的稳定性和策略管理效率也需要持续提升。 踩过的坑 1. 如何实现产品功能高聚合架构上低耦合 规则引擎建设时兼容各类业务场景具备了极高的灵活性同时自身也相对复杂。从顶层的路由场景到底层的参数路由场景-场景-规则组-规则-决策-因子-参数-数据接口-参数每一个节点、节点间都是由用户配置的在产品上期望用户的操作流程是连贯的在一个操作流程中解决尽量多的问题。系统架构上包括配置层、执行层、计算层、数据获取层等各层之间相互依赖对最终引擎的输出结果负责底层上需要尽量的解耦合才将降低单模块对引擎的影响。但在实践中随着业务诉求的增多慢慢就出现来产品上的低耦合、架构上的高耦合情况。 例如在用户修改生产策略时的强制更新流程优化项目中 就涉及了这个问题。在产品功能上用户修改策略–双版本策略并行执行–两版本数据核验–修改完成但在系统架构上上述的产品流程就产生了系统架构高耦合即生产修改双版本问题配置层、执行层、计算层高度耦合。项目一期上线后在性能上、后续功能扩展性上都有瓶颈。随后技术项目优化配置层的缓存模式采用增量更新方式。产品功能上增加用户进入修改模式后修改。重新立项后实现了用户修改流程闭环、系统架构上仅配置层兼容双版本执行层和计算层无耦合。 因此在产品功能设计上除了用户闭环操作外还需要考虑是否低耦合。在技术优化时需要前瞻性的开展去耦合项目。 2. 如何平衡系统复杂度与业务需求 随着接入业务的增多又需要兼容新业务定制化需求就面临这一个问题定制化的功能不具有通用性大量定制功能将加重平台的复杂度。这个问题一直困扰引擎建设团。目前我们采用的也许不是最优但比较有效的办法。主要通过定、判、看Gap将业务需求转化为系统模块升级功能和非系统功能 功重新定义“定制和通用”。在现实中有些定制化需求其实是业务速度已经远远领先于其它业务所有需求看上去是定制化实际上是未来可预见性的问题。未将业务需求进行分类判断需求是针对主干流程还是分支节点。看Gap需求同当前建设情况比对差距。对于系统模块升级功能可逐个完成。对于非系统功能可通过提供公共对接服务的外挂来实现。 3. 特别需要“防呆”设计 人工操作会存在各类误操作引起的风险问题在产品设计上用户操作简洁的初衷是好的但需要增加防止错误发生的限制方法。在实践中这些“防呆”设置大大降低了人工误操作Case例如 业务高峰期封版—禁止业务高峰期时变更策略。降低无逻辑验证的误伤情况–策略上线前强制标记验证执行是否符合业务预期修改生产上应用的策略强制双跑验证修改后的逻辑执行是否符合业务预期。降低逻辑配置错误几率–策略部署时强制测试逻辑正确性。惯性操作–验证数据结果强制回填等。4. 产品功能最佳实践的意外惊喜 要承认一个事实就是最了解功能使用的可能不是规则引擎的产品经理。在规则引擎的建设中出现了这样的”惊喜”例如 规则组功能建设初期目标是实现规则的高效管理、复用。在A业务场景基于规则组除实现规则的高效管理、复用外还实现了决策计算。但这种用法在随着其业务的发展复杂度增加已经不再利于策略高效管理目前还在寻找更优的解决方案。累计因子的功能是将对多条请求进行计数或求和逻辑进行封装。B业务基于上述功能上还是实现了事件行为记录、多事件时序性累计和拦截行为的累计。目前在其业务下广泛使用并有效地识别了跨事件风险。总结而言做好业务定期应用回访和应用监控是非常有必要的。 招聘信息 美团信息安全部正在招聘实习生业务方向包括安全\后端开发\机器学习算法\自然语言处理\风控策略\数据开发\Web前端\测试开发\产品经理\产品运营\安全与隐私合规等。工作地点北京/上海。欢迎感兴趣的同学发送简历至techmeituan.com邮件标题注明美团信息安全团队
