1.1 业务背景
当前市面上的客服CRM、工作台没有专门针对信息安全做产品设计，产品框架下，客服员工大几率能直接接触到客户隐私信息，极易造成信息泄露及后续事件，即现有系统功能，无法满足呼叫中心、客服外包等场景下精细化运营管理需求。
2. 需求描述
2.1 需求列表
2.2 需求详细描述
2.2.1 名词解释
2.2.2 角色说明
2.2.3 场景监控首页以及风险详情
系统登陆：员工打开场景监控系统链接地址，显示登录页面，输入用户名、密码进行登录校验：
说明：只有在客服中心花名册登记在册的员工方可使用账户登录，其他架构员工不可登录。
原型图左侧黑底色部分为菜单栏，首页展示信息为整个客服体系风险触发内容（经理及以上职级员工、系统岗员工展示首页信息）；线上处理板块展示内容为某员工账户下处理中问题（一线主管有且仅有此板块权限）；推送管理板块内容为风险推送规则设置（系统岗位员工可配置此板块信息，并可配置他人菜单栏权限）。
列表页，可通过行政组信息、客服组信息、员工erp、处理状态、时间等字段组合为前置条件，筛选匹配命中范围。
通过行政组和客服组组合筛选，可命中某地四级架构下员工所触发风险；
通过行政组、客服组、处理状态信息可命中（过去七天至）目前某地四级架构下员工所触发风险的实际处理状态（待处理、已处理、无需处理）；
通过行政组、客服组、处理状态信息、时间戳可命中某一时间段内（截至目前）某地四级架构下员工所触发风险的实际处理状态；
通过员工erp字段可直接定位该员工是否触发风险、触发风险内容。前置条件命中的内容通过字段形式展示，字段分别为：ID、账号、风控场景、八小时点击量、状态。（如下图所示）
以上定位内容需要通过“搜索”按钮触发并展示在当前页面上，当前页面展示不完可翻页展示，直至展示完毕。第一面页尾显示当前条件下，触发的所有风险的条数。（如：共计1200条任务）
搜索结果支持一键全选、反选、推送；支持一键打标待处理、已处理、无需处理。全选内容对全部页面生效，非仅对本页面生效。每页展示条数需产品根据可实现情况进行定义。
（1）导出功能
前置条件命中结果，支持导出，字段如上。（ID、账号、风控场景、八小时点击量、状态、操作）
（2）重置
前置条件支持重置，点击重置按钮后，前置条件恢复初始状态。
（3）工作区
由ID、账号、风控场景、八小时点击量、状态、操作六个字段构成工作区。员工在操作列对具体风险进行处理。
具体处理方式可以分为两种：详情、更多。点击详情，跳转单个风险详情页。
（4）风险详情页
此页面存在三种触发条件，即首页工作区点击单个风险的详情信息或者主管点击系统推送的链接、分享链接。（推送逻辑推送板块详述）
详情页由敏感项、实时操作量、安全评估三个字段构成。系统根据管理员设定的点击阈值对敏感项的具体字段进行管控。截至当前时间，敏感项子字段实际操作量（点击量）低于阈值，安全评估显示勾号（评估通过）；截至当前时间，员工操作量（点击量）大于等于阈值，安全评估显示×号（评估不通过），系统进行记录并展示到首页工作区。
敏感项字段由具体页面决定，如CRM事件详情页，具体字段为：手机号查看次数、查看用户历史订单、客户京豆信息、客户实际支付金额、客户收货地址、客户账号信息。
详情页表尾展示三项功能按钮，分享、推送、打标。员工可以在详情页对风险进行打标处理，可选打标操作为：已处理、无需处理。任意打标后，风险均计入线上处理板块。（系统不自动跳转，需要员工手动点击）
分享链接逻辑为，系统管理员及有系统权限的主管可以进行链接分享，分享后的链接也只有主管及以上职级员工可以点开。点开后为风险详情页，被分享对象不可二次操作。如未打标前分享，则分享后的详情页风险状态展示为未处理；如打标后分享，则分享后的页面展示为已处理/无需处理。分享后的页面表尾不展示分享、推送、打标三项功能按钮。
推送逻辑为，员工操作量（点击量）大于等于阈值，系统自动推送至本人及其上级。未超过阈值的操作，管理员可以手动进行推送，推送规则如上。
（5）更多
点击更多后，弹出扩展菜单。员工可直接在此栏中快捷的对单条风险进行打标处理或者推送。
2.2.4 线上处理
系统根据规则推送或系统管理员手动推送的case，主管介入处理后均计入线上处理板块。无论处理方式为无需处理或已处理。
主管可根据行政组选择，定位自己的所在部门，点击确认后，今日数据及跟进中风险数据刷新。今日数据展示内容为各个监控内面当前架构下，风险触发量。时间段为当天该员工erp登录CRM后8小时。
行政组需要支持选择父节点，聚合展示四级部门数据。
2.2.5 推送管理
推送管理包含三个字页面：判断规则设置、推送模板设置，推送规则设置。
（1）判断规则设置
此页面由三部分元素构成，及系统监控的页面，页面的模块及按钮，监控配置点。系统监控的页面暂时为：订单详情页、用户信息页、CRM2.0事件页、CRM3.0处理页。不能写死，后续可能会有增加。
单机某一个选项卡（监控分页），即展示此页面的信息模块及具体按钮/链接。对所有按钮/链接埋点，管控员工的点击量。
由右侧监控配置部分对埋点信息进行阈值划分。此部分包含三个字段，业务角色、配置监控点、点击量阈值。
业务角色字段为业务自定义字段，非系统识别条件，需要支持即时修改。
配置监控点的逻辑分为四点，即支持根据系统角色控制相同角色最多可见次数；支持根据业务组配置最多次数限制；支持根据ERP单独配置个人的最多点击次数；当配置监控点选择为ERP时，需支持单个/批量录入。
需注意，配置监控点字段为系统判断字段，不支持即时修改，仅可在下拉表中三选一。（ERP、CRM角色、业务组）
点击量阈值逻辑同上文所述，此阈值为系统判断节点，超出设定阈值，系统自动触发推送，并要支持即时修改/跟新，即时生效。此阈值的生效时间周期为当天员工在生产系统登录ERP后的8个小时。（大夜班、跨业加班逻辑同上。）
点击确定按钮后，设定的规则及时生效。
注意：可对单个按钮设置点击量阈值，也可对整个模块设置点击量阈值。（按钮、链接被模块所包含）
（2）推送模版设置
如原型图所示，此页面主要实现的业务工能为对自动推送的case进行统一化文案配置。因现在可以实现的的自动推送途径仅存在两条，所以本文档中文案字段是对这两条途径进行配置。如有其他更优途径，再做讨论。
模板字段：#、模板名、主题、邮件内容、咚咚内容。其中”#”为顺序编号。
（3）推送规则设置
此页面对推送的逻辑及方式进行配置。
表头选项卡为系统现有监控的页面，不能写死，后续可能会有新的需要监控的页面。点击各个页面支持来回跳转。
员工点击新增按钮，弹出规则编辑栏。
场景分类判断规则为包含，可单选系统监控的任意场景、页面。（本次监控页面为订单详情页、用户信息页、事件页、处理页，不能写死，后续可能会有增加。）
发送邮箱可以自定义配置。
通知认可选择通知涉事员工、通知涉事员工主管、通知员工及主管、自定义。自定义可以自由设置接收人，支持多个接收对象。
注意，如果接受对象是员工，员工点开的超链不支持任何操作，仅其警示作用。
通知模块如上文所述，为系统管理员提前设置的模板。
推送频率可以选择每小时或者每天，因为信息安全事件已经产生，公司要做的就是就是及时止损，所以没必要做实时推送，可以一小时处理一波或者一天汇总推送一波。这里的时间阶段非员工ERP登陆时间作为起始时间，应是系统时间的00：00作为起始时间，23：59作为截止时间。
推送方式可勾选企业IM或者邮箱，按照业务运营实际情况进行。（可以两个都勾选）
系统自动推送、手动推送的链接，主管需要在当天下班前确认完毕，如未确认完毕，系统自动推送到其汇报对象邮箱，汇报对象若在24小时内为确认完毕，继续向上推送，不做上限。
3. 预期收益ROI
降低客服信息泄露造成的后续客诉事件发生率。具体公式根据各公司实际情况配置。
为何有权限设计的需求
禁止非法用户盗取资源
访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，每一台计算机具备浏览器，如果不建立一个完整的权限检测，那么一个非法用户可以轻而易举通过浏览器访问Web应用项目中的所有功能资源。
保证数据的保密性
公司内部员工的角色不同，自然对于系统使用功能的权限不一样，关于机密数据的列表菜单是不能允许让所有人进行访问的。
比如：一个电商网站的销售额等报表数据，是不允许公司内所有员工都进行查阅的，有针对地进行管理。
权限设计的方式有哪些？
以“用户”为单位的权限设计
以“权限”为单位的权限设计
以“用户”与“权限”结合的权限设计
针对以上三种类型，结合业务场景以及具体设计方式，详细进行讲解。
以“用户”为单位的权限设计
适用的业务场景
当使用该系统的人之中，存在很多拥有同一类权限的人，将拥有同一类权限的人定义为“角色”或者“部门”等其他称号，而这个集合的称号就是定义权限的集合体。
举例：在公司内部，运营部人员拥有查询报表的权限，客服部人员拥有审核商品评论的权限，而运营部人员和客服部人员人数众多，且权限一致，那么以“用户”为单位的权限设计更符合业务需求。
如何进行设计？
1、信息架构图
用户：添加用户过程中，分配至某一个部门，该部门拥有的权限就是该用户的权限
部门：添加部门时，除填写部门基本资料外，对该部门定义具体权限
2、业务流程图
具体流程：添加部门，给部门设置权限，添加用户时，设置所属部门，部门的权限即是该用户的权限。
3、具体原型图设计
添加部门：
添加用户：
由于公司内部资料的保密性，我纯手打两分钟，撸了个最简单的示意图进行参照，其设计方式相信一看即懂。
关于此方法的权限设计疑问
1.权限的类型有哪些？
权限分为菜单功能和特殊项区分权限。
菜单功能权限：为一个用户设置权限，该用户所属部门为运营部，运营部的权限设置中，勾选报表管理，但是未勾选导出报表。
那么该用户进入该系统，能看到菜单页，但是无法看到导出报表的按钮，因为没有改权限。
特殊项区分权限：有这样一个业务场景，该后台系统管理几个电商网站，我不希望A网站的运营人员看到B网站的销售额数据，同理，B网站的运营人员看不到A网站的销售额数据，似乎菜单功能权限不能为我们解决此问题。
那么，我们分两步走：
1、在给部门设置权限的页面，加上特殊项区分权限。
2、找出与此特殊项区分权限所有相关的页面，进行展示并进行标记。
以上为报表详情页，如果该用户所在部门的权限中，勾选了A站、B站以及C站的权限，那么在报表详情页中的搜索选项，出现的站点为权限勾选的网站，如果未勾选任何网站，那么相应地，报表详情页中查看不到任何网站的数据。
需要记住一点的是，涉及到特殊项区分权限的页面很多，产品经理需要全部找出，并进行合理的设计展示，完善方案后给到开发，进行代码的实现。
3.当遇到一个部门内部，必须针对不同的人设置不一样的权限，如何处理？
业务场景：一个后台管理系统管理众多电商网站的评论，客服部人员内部进行分工，1号客服负责A网站的评论审核，2号客服负责B网站的评论审核，3号客服负责C网站的评论审核，那么问题来了。
1号、2号、3号客服同属于一个部门，他们所拥有的权限不一样，你如何进行处理？
大部分人会想到一个解决方案：那就帮2号、3号客服再次新建一个部门，一个部门一个权限可以解决。
但是，这是有弊端的：
试想这种业务场景足够多的话，那么会造成的结果是：你的部门列表会有一堆重复的部门，部门之间也无法进行区分，显得页面非常乱。
有些重复的部门下只有一两个人，非常不利于进行管理
此路不通，怎么解决？
方法是制造一个二级部门的概念，部门太大需要在小组内再区分，就增加三级部门的概念。
三级部门属于二级部门，二级部门属于一级部门，针对现实的状况进行区分。
在添加部门时，选择一级部门时，如图所示：
选择二级部门时，如果所示：
选择不一样的部门类型，进行添加，针对部门进行权限设置，也更方便解决会有重复部门以及页面会很乱的情况。近 2 年，企业信息安全炒得很热，一直觉得这是做安全产品公司的事，离我比较远。但最近的一件事，改变了我的看法，促使我去思考：如何从产品设计上做好安全工作，保护客户利益。
女友是做外贸的，公司用的 CRM 系统是业内的一家新兴公司的 Saas 产品。上个月，她一同事的账号被盗，盗号的人给客户发了一封诈骗邮件。结果，客户把 3 万多美金的货款打到骗子那里了，钱反正是没追回来。
类似的事情不是第一次发生，之前她们的一客户还收到过钓鱼邮件，同样是客户把货款打到骗子那里。骗子只不过用的是个老掉牙的方法，用一个跟她们公司邮箱相仿的地址给客户发了银行帐户信息。客户没仔细看，以为是公司的邮箱，结果就中招了。
像上面的事情，最后的结局是两败俱伤：客户被骗了钱，不信任公司，公司也因此丢了客户。被骗以后，老板又没办法，你做外贸，总不能不用邮箱吧。同行之间一交流发现，大家都有碰到。好吧，次数多了，就习惯了。反应给软件提供方，他们也不重视，销售说是你自己没有注意安全，泄露了密码。一听，挺在理，没办法，拧着大腿还是得认倒霉。
听到上面的事，第一感觉就是可惜：一方面是公司客户的损失，另一方面是客户的流失。早期创过业，明白这对公司的影响。作为产品人，是可以采取一些技术手段，提高产品安全，减少此类事情的发生。虽然这些努力难以被后验量化，但是有价值的。如果等到事发之后再弥补，那时候就是一个大坑了。
信息安全本应是产品最基本的要求，在产品初期就该开始注意，尤其是企业产品，关系到客户的利益得失。很多的初创公司往往因为忙于产品初期的完善，对此不够重视。
金融公司里有严格风控系统，时刻监控用户的操作行为。初创公司不像大公司有足够资源来做这些事情，但至少可以做安全防护模块，并将其独立出来，还可以服务多个产品。设计的核心就是判断的客户的行为是否异常，然后给出相应的预警提示。可以从哪些方面下手呢？
我的构思是：类似风控系统，建立一个模型，针对用户的每一步操作行为行为进行动态打分。每一步操作的打分都不是孤立的，具有连贯性，都会基于历史的操作来进行判定。一旦触发了相应的阀值，系统就采取相应的保护机制。像这样，设定一个风险指数，从 0 到 1。系统对每一次账号的完整过程（从登录到活跃）进行评估，达到相应级别，系统采取相应的保护措施，比如，
账号登录
用户风险指数基于的行为轨迹来判定，有两个阶段：账号登录和账号操作。针对不同阶段，权衡不同因子，最终得出一个打分。下面是我的思路：
登录是安全保护的第一道防线，这个阶段就可以拦截大量的异常操作。
登录失败次数。记录账号短时间内登录失败的次数，防止别人通过大量的测试来获取你的密码，这也是最基本的保护。比如，有的密码输入错误次数达到 3 次以上后，就会加验证码。有的输入密码错误次数达到阀值后，限制一时间内才能的再试。
IP地址。一般用做判断登录地点是否为常在城市。另一方面用做辅助信息来做一些异常判断，做进一步限制。比如发现在某个IP存在频繁的指令行为，可以限制该IP的上账号活动。
使用设备。辅助信息，识别异常操作信号。
登录时间。记录用户的活跃情况，画出用户的工作时间分布图，帮助识别异常操作。比如用户一般都是工作时间登录，突然某一天出现凌晨 2:00 登录的现象，用户在些之前并没有登录连续活跃的记录，这时候就有一定的可疑性。
登录及活跃地点。辅助信息，识别用户的异常行为，可画出用户活动范围图，减少对异常情况的误判。现在有第三方IP地址库的公司，提供定位服务。所以即使是用PC，在不借助GPS和基站定位的情况下，也能精确地定位到你在某一栋楼里。
上面所列的判别因子都是相互影响，彼此之间会影响，需要权衡不同的因子，排除干扰，最后做出评定。
之前出差去过几次柳州，每次去柳州用百度云盘时，都会收到邮件，异常登录提醒。虽说是异地，但我一直用的是自己的手机，第一次提示还能理解，次数多了对用户就是干扰。
小试牛刀，假想一个场景：
小A 是做外贸的，很少出差。突然有一天，系统后台收到他的账号在长沙登录的请求，而在前一分钟，他的活跃地址还是在深圳。如果是你来设计安全规则，你会不会怀疑账号被盗，要求进行二级验证吗？
真实的情况可能是，小A 的公司在长沙有一办事处，他的一同事B 正好在那里出差。当时需要小A 来协助查找一信息，小A 正好要出去，就直接把账号密码给了同事B。同事B 登录用的是自己的电脑，小A 3天前在这台电脑上登录过。
账号操作
虽然登录阶段已有预防，但成功登录也并不意味账号是处于安全状态的。在条件成熟的情况下，即使有验证，骗子也能突破第一道防线。
给你发个引诱短信，你被骗点了链接，尝试登录，结果就泄露了帐号和密码。更糟的是，你还下载安装了病毒软件。当你手机接到验证码时，木马直接把验证码通过网络或短信转发到骗子那里。
账号通过之后，想要判定账号异常情况难度就大一些，但这不意味着就没有可努力的空间了。可以从一些短时间内可疑行为，结合网络的环境来评估。
可疑行为。以外贸软件为例，比如说：
大量的下载，导出文件。
大量的转发邮件。
大量的发送邮件。
其它敏感操作，如：
发送带有付款账号的邮件。
发送之后立即删除等
每个账号的安全评估也不是孤立的。不仅要留意独立账户的安全，还要关注不同账号之间关联判断。
举一个例子：
一伙诈骗团队发现某一产品的漏洞，破解多家企业用户的账号密码，借助非法手段通过了二级验证。但后台系统识别出来这种异常，同一IP上的出现多家企业账户登录，操作时间是在可疑的凌晨时段，三家企业分别在 3 个不同城市，但操作地点却在同一个地方，使用的设备也是从来没有用过的。系统可以直接对其IP进行封锁。在一定时间段时限制使用该IP访问产品。
脑洞时间
有安全防护，就会有误判，设计的时候不光要考虑安全，还要考虑好怎么尽可能减少误判的可能，以免给用户增加不必要的麻烦。这个设计过程实际上就是在建模，
通过规则的建立来模拟出用户的操作习惯。
判断账号的操作行为是否符合规则。
然后做出相应保护策略。
要想设计出稳定可靠又优雅的安全模块，需要持续不断地完善和优化上面的规则。但每个用户的习惯又都会不一样，如果这些优化工作都需要人来做，就要背后做规则的人去不停地学习用户习惯的判断，这个工作量是十分庞大的，而这恰巧是人工智能所擅长的事情。
兴许，未来有一家利用人工智能专注于安全，基本用户操作行为进行分析的公司。那些做产品的公司愿意的话，只要把用户的所有操作行为开放给上面第三方公司，第三方公司就能对用户的操作进行动态安全评估，得到反馈的公司根据结果再做出相应的保护策略。