端产品的安全性设计

　　在B端产品中，为了确保企业内部数据的安全性，我们应如何设计去满足其不同业务情况下的需求。本文将安全性需求分为三类，通过用户、职责、职位给出其对应的解决方案。
　　每个企业，由于内部组织架构、职责岗位、业务等等方面的不同，安全性的需求也不相同。但是从产品维度来说，安全性的设计是通用的。
　　安全性需求
　　首先，可以将安全性需求分为三类：
　　第一类，登陆安全性，即限制用户登陆。什么人可以登陆，什么人不可以登陆。
　　第二类，界面安全性，不同的职责人员所需要查看或编辑的页面不相同。例如，营销人员可以查看营销活动信息，而无法查看销售信息。
　　第三类，数据安全性，即同样的页面看到的数据不同，例如，销售A与销售B所看到的数据不相同，但销售经理可查看A与B的数据。
　　知识点
　　1。员工与用户的区别
　　员工不等于用户，员工可以是用户，用户不一定是员工。
　　员工，是指员工是指单位中各种用工形式的人员，包括固定工、合同工、临时工，以及代训工和实习生。
　　用户，则是基于产品的，是指使用该产品的人员。
　　在B端产品中，由于各类业务需要，会存有企业内部的基础员工数据等。（例如，某一业务的业务单据或流程中的关系人，为了防止重名以及唯一性，一般都是以HR中的工号作为系统内员工的唯一性。）这个时候，就容易将员工用户搞混。
　　员工数据与客户数据等均为主数据，而用户则是在员工基础之上，增加的一层身份，但用户并不都是员工。举个例子说明一下，某企业的经销商下单平台，除了企业内部员工允许下单外，经销商也可使用该平台下单。而此时，经销商并不属于员工，但属于用户。
　　2。用户、职责、职位的关系
　　职位，指机关或团体中执行一定任务的位置，即只要是企业的员工就应有其特定的职位。
　　职责，职位上必须承担的工作范围、工作任务和工作责任。
　　简单来说，职位指的就是岗位，职位有上下级。一个职位一个人，但一个人可以有多个职位（身兼数职）。而职责则指的是该职位所要做的事。
　　为了更好的区分职责职位的关系，以销售公司为例，如下图
　　其中，西南销售经理、西南销售1、西南销售2均为职位，且西南销售经理为西南销售的上级，西北销售经理为西北销售人员的上级。但西南销售经理与西北销售经理的职责相同，均为销售经理职责；下级的职位很多，但职责也相同，为销售人员职责。
　　解决方案
　　1。登陆安全性
　　通过系统内用户的设置，当且仅当登陆人位为用户时，即可成功登陆并使用产品。
　　2。界面安全性
　　界面安全性，通过对职责分配不同界面来满足该需求。
　　参考上面的销售公司的组织架构图。销售人员的职责相同，因此系统对于该职责所展示的界面一致。而财务经理与销售的职责不同，所以系统展示的界面也不相同。
　　例如某个系统内部包括销售拜访模块和应收款模块，销售人员需要拜访模块来进行日常活动，而财务需要应收款模块进行工作。
　　因此，将销售拜访模块分配给销售人员职责；将应收款模块分配给财务相关职责。这么做，销售人员也看不到应收款信息，而财务也看不到销售拜访信息。
　　3。数据安全性
　　数据安全性，即相同页面，不同用户看到的数据不相同。常见的数据安全性分为以下几种，个人安全性、职位安全性、团队安全性、组织安全性、基于某业务的安全性、所有安全性等。
　　个人安全性，一般取的是创建人，即谁创建的数据谁可以看，其他人无法查看。注意，该安全性一般在企业的业务数据中很少使用，原因是因为企业内部人员离职后的数据问题。例如客户数据，若创建人离职，则该数据很难转移给下一个人（总不能让技术小哥底层改数据吧，技术小哥会打人的）。
　　职位安全性，即取的是创建人职位。该职位及该职位上级均可查看该条数据。除此之外，若有人员离职，可通过更换职位使数据转移到下一个人。
　　团队安全性，即对于某一客户或者某一业务数据，是由团队共同负责。团队的创建职位可添加其他职位用户至团队中，团队中的成员均可有权限查看该条数据。
　　组织安全性，在集团型的企业中，各子公司的数据是独立的。例如子公司的销售总监仅可查看该组织内的所有销售数据，而无法查看其他组织的数据。职位是有组织的，用户的组织是基于职位。所以，一般的职位安全性可满足大部分组织安全性的需求。
　　基于某业务的安全性，是指某一业务模块的数据是基于其某一基础数据的安全性。例如，当且仅当客户负责人才可创建关联的单据。此时，该业务单据的安全性是基于客户负责人的，因此，所有该客户的单据均有权限查看。
　　所有安全性，就是所有的数据均可以查看。
　　常用的安全性就这么多，虽然是B端产品，但在设计的时候，除了满足业务需求之外，也要充分考虑到系统的灵活性，在减轻后续运营的精力之外，可以极大提高企业内部的业务效率。
　　另外，权限除了查看外，还包括新建、编辑、删除等等，比较详细的就不做说明啦。希望可以帮到大家！