用户管理手册
用户管理手册
系统术语
用户
系统的使用者通常称为用户，用户登录后，系统通过各种标识赋予用户操作和查看权限。
后台需要对用户账户、操作权限和数据权限等进行管理。用户管理贯穿业务各个环节，是支撑业务运营的核心部分。
系统用户一般分为内部用户和外部用户。这种区分是从平台运维角度出发，平台运维公司的员工称为内部用户，其他用户称为外部用户。
外部用户
外部用户隶属关系比较复杂，有的挂靠在某公司之下，无需注册，由系统管理员分配账户。
有的则以独立个体存在，例如：钉钉，以独立个体注册，公司邀请员工，员工同意后才有了归属。
第三种情况是用户以独立个体注册时选择所属公司，这种方式存在两个问题：
用户随意选择企业，不能保证准确性；
是否要在后台维护企业基础数据，不维护的话，无法统一数据源，维护的话，不能覆盖全部注册用户的企业。
选择哪种方式，需要根据实际业务情况进行设计。
例如
目前平台的服务对象是门店销售员，由于业务冲突，平台无法获得企业级的合作，前两种情况需要隶属公司在平台上进行操作，只能选择第三种方式，用户以独立个体注册平台，并填写所属企业。
为避免第三种方式存在的问题，做如下处理：
用户注册填写企业，无需选择基础数据；
后台维护企业基础数据；
用户审核时，有平台客服人员选择企业基础数据。
这样既减少了用户操作的繁琐，平台又能获得精准的数据。
内部用户
内部用户也有归属，旧有的平台添加员工时选择归属，在员工管理菜单下展示为员工列表，这样做需要提前维护组织机构，频繁切换菜单。
像钉钉、企业微信等，在维护员工时，按照公司的组织架构进行维护，在同一页面完成部门和员工的添加，层级关系清晰（见下图）：
内部用户一般无需注册，由系统管理员分配。分配的账户可以是字符串，也可以是员工的手机号码。
角色与权限
每个账号，都被赋予了特定的角色；而每个角色的背后，都有其对应的权限信息。
通过RBAC权限管理模型，用户可按照实际业务的需要分配不同的角色和权限，在共享一个软件平台的基础上，实现不同用户的不同功能。
权限的赋予分为自动赋权和手动赋权两种。
外部用户的自动赋权一般是账户有默认的基础权限，要想获得更多的权限需要另外开通；内部用户的自动赋权，一般是把角色与行政关系下的部门建立绑定关系，用户进入到该部门后，账户自动被加入到对应的角色中，并且拥有该角色所有的权限。
手动赋权无法通过用户行政关系自动绑定来实现，需要手动建立角色赋予给账户。
例如：要求客服专员只能看分到自己名下的客户，上级领导看全部下级的客户，通过两种方式实现：
一是通过组织机构的上下级归属自动赋予数据权限；
另外一种用数据角色，实现跨部门查看数据。
另外，角色可以继承，子账户继承父系角色的权限。例如：赋予某企业级外部用户admin某些权限，该企业下的其他子账户只能从admin权限中选择可用权限。
权限依据属性可分为操作权限和数据权限。
操作权限会从功能菜单、功能操作两方面考虑，角色勾选上菜单和功能，拥有该角色的账户即可操作相应的菜单和菜单下的操作（例如新、增、改、查），分配操作权限页面见下图：
数据权限会从菜单、列表及数据字段三个颗粒度考虑：
菜单是最粗颗粒度的数据权限，获得授权即可查看该菜单下的全部数据；
列表是较细颗粒度的权限，不同角色的用户进入同一菜单页后，查看的列表字段相同，但量级不同，例如上面描述的员工看自己的数据，领导看全部员工数据；
数据字段是最细颗粒度的权限，不同角色的用户进入同一菜单页后，可见的数据字段有差异，这些字段共存在一个菜单页中，只是受限于不同的角色权限。
单点登录
平台会涉及多个应用系统，例如：合同管理、资金管理、小程序管理、兑换商城等，可通过单点登录（SSO）。
在多个应用系统中，实现登录一次就可以访问所有相互信任的应用系统。
应用系统加入了单点登录协议，管理用户帐号的负担就会减轻，实现应用系统的用户、角色和组织机构统一化管理。
要实现SSO，需要：
统一集中的用户身份管理系统。所有应用系统共享一个身份认证系统，用户登录时，信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。
所有应用系统能够识别和提取ticket信息。应用系统对ticket进行识别和提取，通过与认证系统的通讯，自动判断当前用户是否登录过，从而完成单点登录功能。通过基于互联网协议的单点登录、登出体系实现用户不同应用系统间身份一致性，实现信息空间身份一致性。
不论是外部用户，还是内部用户管理，都涉及到账户、角色和权限的管理。
本文从自身经验出发，总结了各个环节需要注意的地方，另外单点登录涉及到用户管理，贯穿整个平台，此部分技术人员参与的比较多，本文只做了简要的总结。
用户管理系统最难的是后续的维护，系统中往往会出现很多冗余的角色，这都需要慎重思考，和业务沟通清楚后再做调整。
用户系统模块架构
用户管理模块架构如下：
整个模块为用户管理，下分三块分别是：
部门组织架构：
所有部门人员信息的在线展示以及对应的人员列表，此处同步公司域库数据，附加了当前在线状态的显示；
角色权限管理：
此处分为角色组的建立以及对应权限的把控，角色组以及所属成员按需创建和添加，建完之后对应做权限的控制，包含功能权限、资源权限、数据权限、集成系统的访问权限；
权限申请管理：
此处是针对权限管控后，用户对无权限资源进行的权限申请处理以及对应的权限赋予操作（权限批复结果会自动生成消息通知，与公告消息相通）。
用户管理
账号管理，是管理员最常用到的功能。这一模块，需要设置相应字段，对内部人员的信息进行管理，首先应该具备“新增”、“删除”、“编辑”这三项基础的操作功能。另一方面，考虑到部分企业存在内部奖惩机制， 对某项指标不合格或者行为违规的员工， 做出暂停使用账号的处理结果，因此，在上述三项基础操作功能之外，可以再增加“禁用”和“启用”的功能。
账号列表
账号列表应该优先显示重要的字段，比如ID、用户名、真实姓名、部门、角色、账号状态、注册时间等。当然，除了这些，后端还需要记录下用户的其他字段，比如最近登录时间、登录次数等等操作记录。如下图：
添加账号
当管理员点击“新增”按钮时，当前页面可以跳转到填写账号信息的页面， 也可以通过弹窗的方式出现。新增账号的字段应当尽量详细，以便将来对用户行为做统计分析。同时在这个阶段，我们可以通过判断用户的身份，来给他赋予相应的角色。在这一步，不需要配置权限，因为角色本身就是带有权限的。如下图：
角色管理
角色管理部分，是用来管理内部用户的角色信息。角色，是对具有共同特征的某一类人群的身份归纳，在这个模块里，我们需要设置一些字段来描述角色信息，降低学习成本，让管理员能够轻松识别角色的特质，从而为不同的用户赋予对应的角色身份。
角色列表
角色列表类似账号列表，也是将一些重要字段展示出来，让管理员能够很快的了解角色的相应信息，比如角色ID、角色名称、基本权限、操作权限等。当基本权限和操作权限非常繁杂的时候，可以只显示重要的几类，其他的详情，可以点击查看。
在角色列表，只需保留“新增”和“删除”功能，“搜索”功能也可以不需要，因为角色的种类通常比较少，否则会给管理员增加负担。如下图：
新增角色
“新增角色”和“编辑角色”，都是给角色赋予相应的权限。过去我在给角色配置权限的时候，使用过下拉菜单的方式来选择。但如果碰到权限非常繁杂的情况，下拉菜单就不太适用了。这个时候，可以将权限都罗列出来，可以分组排序，也可以默认全部选中，然后让用户根据需求去勾选掉不需要的权限。如下图：
权限管理
权限管理这部分，是逻辑性最强的一块，需要提前准备好一份权限清单，将权限的名称、描述、性质（基本/操作）等信息梳理清楚。
权限列表
在做权限梳理之前，一定要与开发人员沟通好，确定哪些权限是同类型的，可以归为一组，而哪些功能又必须是分开设置的。拿我之前做的这个项目为例，这个产品没有涉及工作流环节，但Boss想让不同角色的用户，看到不一样的界面，所以除了通常的操作权限划定之外，还有一些基础的菜单查看权限，也要细分。当然了，因为权限细分起来非常繁杂，所以权限列表还需要有分页的功能，也可以加上搜索功能。如下图：
新增权限
“新增权限”页面，是为开发人员设置的，开发人员可以在这里将代码内容录入。具体如下图：
以上介绍的用户管理三大模块，是专门针对后台系统设计的，面向的用户也是企业内部人员，从产品需求上来说，追求的是规范、标准和流程化。
如何做好角色赋权
自动赋权：用户自动进入角色
如果角色与行政关系下的组织部门存在绑定关系，那么如果一个用户进入到该组织部门后，该用户会自动被加入到对应的角色中，并且拥有该角色所有的系统权限。如一个财务人员【小张】入职财务部后，那么该用户无需进行额外的授权即可在对应财务报表系统查看该部门员工可查看的财务数据报表和对应的操作权限（比如操作财务审批等）；
角色赋权：用户被添加进角色
业务是不断创新和发展的，随着业务的发展，会有越来越多的新的角色被设置和创建，比如公司新启动了一个企业团餐项目，项目部横向的从各个部门找了多个员工组建项目团队，并且该项目的业务权限也只是授权给这批员工可查看和操作，那么，在此项目中，会产生一个新的角色 “ 财务1 ”，系统高级管理员会把从财务部门选中的财务【小张】添加到“ 财务1 ”这个角色中，那么【小张】即可获得查看企业团餐项目业务数据报表和操作的权限。这种权限的授予无法通过用户行政关系的自动绑定来实现；
角色继承：角色权限的继承
权限可以是独有的，也可以是继承的。每个角色都有自己的权限集，角色继承其实也就是继承父系角色的权限，一般角色在继承其父系角色的全部权限的基础上增加拥有一些自己的权限。而系统角色继承往往存在于用户分级管理比较明确的团队或者公司；
角色互斥：角色包含的权限互斥
角色互斥的业务背景：当一个业务流程由于风控的原因，需要将其操作给划分成分开的几个步骤时，需要给这几个不同的步骤授权不同的角色，并且这些角色之间需要进行互斥。比如大额财务报销审批流程，财务人员【小张】拥有了审批人权限后，就无法将审核确认的权限再授予小张，以此来规避一个人完成大额报销而带来的财务风险；
临时角色：给特殊客户临时身份
临时角色往往是针对特殊群体设置的，比如公司有特殊访问团队莅临，需要给这些特殊的客户一些临时身份来体验某些功能操作。那么把这些人添加到部门的组织架构中显然是不合适的，因为这些人只是临时的摆放者，不是企业员工；其次，这些客户需要体验的功能操作往往是横跨多个业务模块和产品线的（比较繁杂），一般公司并没有现成的固定角色符合拥有客户所需的全部操作权限，因此需要给这些客户开设临时角色，并且支持给临时角色最大的权限选择空间；
黑白名单：
如何做好权限系统
上述组织架构和权限申请部分基本很容易理解，逻辑相对复杂一些的当属角色权限管理这部分，先看一张关系图：
做好权限管理有以下几个重点：
1. 人员组成要灵活
这部分的人员组成不一定是按照岗位角色来的，有可能是跨部门跨岗位形成的自定义角色组，因此不能直接套用之前的岗位角色，需要可以创建新的角色组，当然角色组多了还可以给角色组分大类，以便更清晰一些。
2. 权限覆盖要全面
权限常规来说可以分为功能权限、数据权限、资源权限，当然根据产品不同也可能有更多的权限分类。大到每个顶部导航模块，小到页面上每个功能按钮，都属于权限的范围。与此同时资源内容的全量呈现还是部分呈现就涉及到资源权限的管控；有的数据我能访问，你不能访问，这种权限的区分把控在于数据权限的设置。
在上述案例中，我们的数据权限采取的是黑名单制，顾名思义就是我选择谁不能看到哪些数据，默认情况下是所有人可以看到所有数据，这个可以根据具体情况进行正反向设计。
比如大部分都是可看的，不可看的是少数，那么就用黑名单方便一些；如果大部分都是不公开的，只有少数是公开的，那么白名单会更方便一些，因情况而异。
3. 权限把控要灵活
正常来说角色权限管理对于一个需要此方面把控的产品来说就像空气一样不可或缺，虽然我们不常注意它的存在，但是用的时候一定要确保其规范、安全、可靠。
之前我们在做的过程中有过这样的一次经历，一般被赋予了某个角色的人员具有把私有表转为公共可见表的权限，而对应的删除操作，当时开发则做成了谁建的表谁删除，其余人即使有同样权限也不能进行删除这样的模式。
在一次不经意操作中我们发现共同拥有这个权限的人删除不了别人建的公共表，我跑去告诉同事说这张表是他建的，需要他删除，然后我就去了洗手间，但顿时感觉这样的逻辑存在问题，假使十个人建了十张表然后都转为公共表了，那么如果这十个人离职了，这些表还非这些账号不能进行删除操作了吗？（不包含开发同事从数据库删除的情况，因为我们设计产品的最终目的就是减少进行数据库的操作，最大化方便使用并且逻辑合理）
因此意识到这一问题后，我们小组立即进行了讨论并且及时做了更新。虽然这样也存在不是表的主人删除他人表的可能性，但通常来说：
第一，这样的情况相对较少；第二，对应的解决方案是可以通过把删除表的功能只赋予一个最高管理员，其余角色不能随意操作，这样来管控。总之要保证权限把控的灵活性，这是第一原则。
实际情况其实更复杂一点，因为我们还涉及私有表可删除（所有人都有的功能）、可移动到公共表（部分被赋予权限的人员具有的功能，无权限人员不显示此操作按钮）；公有表的查看（所有人都具有的功能）、公有表的删除（部分被赋予权限的人员具有的功能，无权限人员不显示此操作按钮）等，那天本来约了人，但为了调这个并和开发讲清楚，赴约都临时取消了（捂脸）。
4. 权限申请要智能
权限申请其实和之前的权限把控是对应的，有的权限是把控之后，相应用户看不见被屏蔽的痕迹，也没有申请入口，而有的可以做成暂无权限的提示，同时提供申请入口。
在上述案例中，我们在部分屏蔽场景中提供了权限申请的入口，当用户点击申请后，会自动在后台接收一条权限申请的消息，上面显示申请人基本信息、申请源、申请时间以及批复操作（通过/拒绝），具体的申请处理流程如下图：
在这块令我比较欣慰的一点是我们的技术同事把权限开通做的相对智能化了一些，即在通过权限申请的时候，相继会产生2条动作：
一个是在上述的角色权限模块自动开申请用户开通相应权限（包含功能权限、数据权限和资源权限）；
另一个则是在开通流程走完之后把申请反馈通知发送到该用户的消息账户，这两个任务完成后，即权限申请“通过”，整个流程基本在1秒内完成。当然即使开放后的权限未来也有可能被收回，所以这块的灵活性是毋庸置疑的。
外部用户管理
用户信息管理是客户关系管理的底层基础。
用户接触一款新产品，从开始了解，深度使用，最后到流失，整个过程会产生大量的数据信息流动，通过对这些用户信息的高效管理，可以指导用户分群、个性化消息推送、生命周期管理和关联推荐等一系列运营策略。用户信息的最大化的合理利用，能够更精细为用户提供服务，有效的达成业务目标。
在用户信息中包含了用户从注册到注销在平台产生的数据，包含用户的基本信息，账号信息，订单信息，统计信息，收货地址信息，等其他信息。
基本信息：包含用户的账号ID，注册来源，手机号码，性别，会员级别，城市地区，头像，昵称等
基础信息是描述客户基本属性的静态数据，主要来源于用户注册和使用时录入的信息。用户基础信息一般通过电商CRM系统的会员信息库进行存储和管理，会员信息库就好比存放着平台每一位用户的名片夹。
用户的基础信息字段繁多，大致可以归为六大类：
人口属性信息：用户的姓名、性别、年龄、生日、所在省市区街道、婚姻情况；
平台属性信息：昵称、注册时间、会员类型、会员等级；
联系信息：手机号、邮箱、QQ、微信、微博、其他第三方关联账号；
收货信息：默认与非默认收货姓名、收货地址、收货电话；
卡与支付信息：会员卡信息、银行卡信息；
认证信息：在校认证信息、营业执照认证信息、消费贷认证信息等。
账号信息：账号信息包含用户的支付账号信息若平台自有支付系统，则可以展示用户绑定的银行卡信息（隐藏部分）
订单信息：订单信息包含用户所有的订单，比如用户历史订单，待支付订单等等，在订单列表中需要将该用户下的所有拉取出来。
收货地址信息：收货地址信息则显示用户的收货地址，收货人，联系方式等。
行为信息是用户使用产品时产生的动态数据，主要来源于系统的事件埋点与后台日志：
· 事件埋点对用户的行为事件进行了全流程的记录，再通过各种页面来源（source）进行相互关联，可以详细记录用户的行为路径。
· 后台日志记录了交易信息，包括订单id、商品id、货号、单价、颜色、尺码等记录、通过“时间戳”来证明发生时间。
通过用户完整的行为信息，我们可以还原最完整、真实的交易场景：
· 用户是谁：目标用户、用户画像、是否源于其他用户分享；
· 买了什么：商品品类、风格、件数、颜色、尺码、价格、上市时段；
在哪发生：线上的模块、页面、路径；线下的城市、商圈、地址、店名。
行为信息可以间接反映用户的行为偏好和决策路径，通过自建数据分析平台或第三方分析工具进行系统化的管理，可以为具体业务方案提供可靠的数据依据，带来可量化的指导。
基于行为信息的生命周期管理
基于用户在平台的消费记录，可以按照用户是否使用过产品来划分为新用户与老用户；老用户还可以根据用户使用产品的情况，按生命周期划分为留存用户、沉默用户和流失用户，举一个简单划分方式：
· 未激活新客：注册了产品之后，还没有正式使用（如电商的首次下单）的用户；
· 留存用户：在指定一段时间周期（如30天）内有使用过产品的用户；
· 沉默用户：对使用产品的积极性下降，连续一段时间周期（如30~60天）未使用产品的用户；
· 流失用户：曾经使用过产品，现在已经连续很长一段时间（如61天以上）没有再使用过产品的用户。
会员权益模块
在会员权益模块展示了会员权益的获取与注销的规则及会员权益规则的修改与新增。因为不同业务形态不同用户层所以会员模块的设计具有较高的灵活性，本文不做展开。
会员权益设置：包含会员级别设置，升级设置，降级设置等等。
会员权益展示：这里则是设置好的会员权益展示。比如会员升级条件等等。
RBAC权限设计模型
（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联，从而获得某些功能的使用权限。权限被赋予给角色，而不是用户，但是一个用户可以拥有若干个角色，当一个角色被赋予给某一个用户时，此用户就拥有了该角色所包含的功能权限。简单地说，一个用户拥有若干角色，每一个角色拥有若干功能权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。如下图：
· 用户：成功认证并登录系统的操作员（主体：who）
· 权限：访问资源的许可（how）
· 角色：权限的集合体
· 资源：引入这第四个概念，包括系统菜单、页面、按钮等（what）
4A模型
4A模型
是指：认证Authentication、账号Account、授权Authorization、审计Audit，中文名称为统一安全管理平台解决方案。即将身份认证、授权、审计和账号（即不可否认性及数据完整性）定义为网络安全的四大组成部分，从而确立了身份认证在整个网络安全系统中的地位与作用。
附录
1. 一个用户拥有多个角色，多角色之间如果存在互斥关系如何处理？
如果一个用户已经被添加到某一角色范围下，那么，当给该用户添加一个与当前角色存在权限互斥关系的角色时，系统会进行互斥性判断，后面的角色就无法给该用户添加成功；
2. 业务发展过程中，如何保证不同角色之间权限拆分清晰？
随着业务的快速发展，一定会不断新增不同的角色和更多的功能模块，而且这些角色和功能权限之间的关系也会日益混乱，这个时候需要产品经理和业务方一起，及时的面对业务的发展变化，及时、快速的梳理业务调整范围，作出对应的改变；
3. 用户权限管理系统核心难点是前期的产品设计吗？
用户权限管理系统核最难的不是前期的产品设计，而是后续的运营维护，因为权限系统的结构往往不会随意变更，但是随着业务发展快速出现的角色和功能模块，为了防止角色和功能权限之间的关系变得混乱，在建立新的角色和分配权限的时候需要思路清晰且慎重调整。
以上是 用户管理手册 的全部内容， 来源链接： utcz.com/z/512241.html
