为了提高公司运营效率，公司打算为所有员工设计一套员工管理系统，让所有员工可以在线上交流，进而提高每个人的工作效率。设计系统的任务落到产品小王肩上。小王之前是做社区类产品的。小王想只要自己设计一个账号系统和权限系统，把权限作为方法关联的账号上，最后再设计一个类似论坛的交流模块，让公司人员把相关数据按照不同格式发布自己的工作信息，同时设计统计功能，让老板可以清晰看到员工的工作记录。
说着，产品小王便按照自己的想法出了一份关于账号体系和权限的需求文档，在下班前交付给研发老王，然后自己就下班了。
第二天研发老王气汹汹一大早就来找产品小王了，说到：按你这么设计系统的账号系统，以后所有的功能都不能做，你好好想想吧。产品小王陷入了无限的自我怀疑中：又不能做了？？？？到底是什么原因？？
背景
B端产品和C端产品最大区别之一是账号体系。C端产品注重用户产生的价值，通过提高用户价值进而提高产品价值，从这个意义来说，在C端产品的账户体系中每一个账号是一致的，所以C端的账号体系比较简单。但是B端产品更注重不同用户间相互协作，解决问题，进而提高效率，增强产品价值。这要求B端产品能为不同账号提供不同功能，不同数据，不同页面，所以B端的账号体系就复杂得多。
比如，在小红书的账号体系中，刚注册的用户和粉丝过百万的用户能使用的功能是基本一致的。而基础的销售管理软件中，销售主管需要查看团队销售数据，但是作为普通销售只需要查看自己的销售数据就可以。
RBAC（Role-Based Access Control）
安全原则
设计软件是要遵守权限安全原则，主要内容包括：最小特权原则，责任分离原则，数据抽象原则和两人控制原则，具体内容如下：
最小特权原则（Least Privilege）：在完成某种操作时所赋予网络中每个主体(用户或进程)必不可少的特权，确保可能的事故、错误、网络部件的篡改等原因造成的损失最小；
责任分离原则（Segregation of Duties）：是指遵循不相容职责相分离的原则，实现合理的组织分工，所谓不相容职责是指企业里某些相互关联的职责。比如财务整理和审批两种权限如果赋予一个人，就会增加发生差错和舞弊的可能性，必须将两项权限分离开；
数据抽象原则（Data abstraction principle）：数据抽象原则决定了操作内容。CRUD增删改查操作是最常见的数据抽象。CRUD只适用于单一实体（数据库的内容），CRUD对于软件系统中的实体是远远不够的。在软件设计中，需要通过数据抽象原则设计更多操作内容，比如在员工管理系统中的离职，请假等操作。数据抽象原则不但提高了操作便利性，而且通过封装模块提高了数据访问的安全性。
两人控制原则（Two Person Control）：也叫双重控制，要求对于敏感业务需要两人同时批准才能进行。比如一个会计系统需要两名经理同时批准才能发行2500万以上的发票；
RBAC理论内容
RBAC理论是成熟的软件账号权限设计理论，且符合以上安全原则，下面介绍RBAC原则的主要内容；
远古时代
在没有RBAC原则时，软件设计直接对用户进行权限赋予，达到控制用户权限的目的。
直接对用户赋予权限的问题是当用户变多，权限复杂，导致工作量急速增大，不适合现在的成熟的软件行业；
RBAC-0
在RBAC理论中，用户和权限不直接关联，而是通过角色产生间接关联。用户和角色之间是多对多的关系，角色和权限之间是多对多关系，如下所示。
系统为角色配置权限，进而把角色分配给用户，达到给用户分配权限的目的。这是最常用的权限控制结构，现在还多小型软件还是用这种权限控制结构。
RBAC-0最大的问题是没有实现高精度控制权限，同时也没有限制角色之间，用户之间，角色和用户之间的关系，是初级的操作理论，不适合现代大型系统使用。
RBAC-1
RBAC-1理论进一步完善了角色的理论，在角色中增加了等级的概念。也就是说子角色的权限一定小于父角色。如下
RBAC-2
RBAC-2在RBAC-1的基础上继续完善了角色的理论，具体如下：
- 单个用户可分配的角色数量有限；
- 单个角色可分配的用户数量有限；
- 增加角色互斥功能，互斥的角色不可同时分配给同一用户；
- 角色A和角色B之间存在等级关系；
现在大型软件系统的权限控制系统的设计理念是以RBAC-2理论为中心，再根据业务的实际情况进行调整。
下面的图片描绘了小王所在公司的组织架构。该集团是一个在全国拥有多家分公司的大型上市公司，下图是该公司的组织架构图（图片来自网络）。文章剩余部分以如何以该集团设计管理软件为例说明软件系统中的角色及权限控制如何设计。
明确问题
实现对通讯范围的控制。比如分公司B的管理人员只能访问该分公司下的市场拓展部，服务中心，工程管理部，环境管理部，秩序管理部，质量管理部，行政人事部，财务部的相关数据，而无法查看分公司A的相关数据。物业管理部的普通员工只能访问该部门的通讯录；
实现对功能权限的控制。比如市场部只能访问市场相关的网页，工程管理部只能访问工程管理部相关的页面。市场部的领导或者HR可以为该部门增加员工，但是普通员工就无法增加员工；
实现对标准对象的字段的控制。比如人力资源部领导可以看到全公司的员工数量，但是人力资源部的普通HR是无法看到该数据；
实现对标准对象的类型的控制。比如同样是在市场部的员工A和员工B可以同时访问订单中心，但是员工A是主要负责发货订单，员工B主要负责售后，所以员工A只要看到待发货订单，员工B只要看到售后订单。
实现方案
实现理论
实现原则：以RBAC理论为设计原则，并根据实际情况进行拓展，具体内容如下：
将RBAC理论中的“角色”实现为软件中的“角色”和“职能”两大内容，由“角色”和“职能”共同控制用户的权限；
将现实世界的事物（这个例子中可以理解为客户，员工，订单等事物）抽象为软件中的标准对象（对应抽象为客户，员工，订单），实现对实现世界的事物的准确控制；
具体设计
通过设置角色中的可见范围和权限范围控制用户的通讯范围，如图所示。
在新建职能时，通过控制标准对象中的业务类型实现不同员工看到同一标准对象的不同业务类型。
以订单中心为例，在设置职能时，可以选择订单的业务类型，具体页面如下：
通过职能设置实现对菜单，页面，按钮的控制，实现菜单，页面，按钮对不同用户的区别访问。以客户管理为例，具体页面如下：
通过对标准对象中的字段控制，实现控制员工是否可以访问或者编辑数据。以订单为例：
通过编辑标准对象的内容，实现对标准对象的精确控制。比如，在客户标准对象中，可以对客户中的类型，字段，布局，创建规则等相关内容进行，编辑。具体页面如下
总结
在B端产品中，账号和权限系统时产品设计中最关键的环节之一，产品经理必须根据业务的实际情况认真思考在未来比较长一段时间内会遇到的问题，必要时需要和研发仔细讨论解决方案，先做加法再做减法，在底层数据结构预留好相关结构，这样做功能迭代才能有的放矢，不会出现这个功能做不了的情况。
tips：文章内容的主要内容是对角色及权限控制的架构进行描述，所举例子偏理想化，读者阅读时需要辨别例子是否能用于真实工作中。
