公司新闻 火狐体育app:中后台学习笔记 – 数据权限 来源:火狐体育最新官网登录入口 作者:火狐体育app 发表时间: 2022-12-05 01:00:00

  曾经看到过这样一个需求:他想知道,我 为什么 能够看到这条数据 ? 如果这条数据是我自己创建的,那么其他能看到这条数据的人,都由于什么原因呢 ?

  但在回答这个问题之前,可能要先完成另一件事情,分析清楚到底什么是数据权限 ? 都有哪些业务场景,需要数据权限的支持 ?

  简单来讲,数据权限就是用户是否能够查看数据,主要是为了业务系统的信息安全考虑,不同的人,在不同的场景下,所能看到的数据范围也不一样。

  为了行文方便,后续统一使用 查看数据 进行描述,实际上像增 / 删 / 改 / 查 / 锁定 / 解锁 / 分享等的数据权限类型有很多,就不在本文中介绍了。

  本文将结合在工作中遇见的一些业务场景,跟大家分享一些常见的数据权限设计,也希望能够总结出一套,最符合本公司业务的数据权限架构体系。

  基础数据权限通常会承载到一个权限媒介上,比如说权限集,职能等。他通常包括两部分,对象级权限与字段级权限。

  简单来讲,对象级权限可以控制到一个用户是否能够看到某一个业务菜单或者业务 Tab,也就是说用户甚至可以不知道系统中有这一类的数据。对象级权限的设计会包含下面几部分。

  当然,对于不同的企业,可能还会有更精细的管理,比如针对数据的转移,锁定 / 解锁等基本功能可以也需要做控制。

  关于 查询所有关联 和 修改所有关联 ,他的权限优先级是要高于其他权限规则。比如商机、订单、报价单等业务对象都关联了客户,那么如果在客户上设置了 查询所有关联 的话,就会覆盖掉具体关联业务实体设置的对象级权限。

  根据业务需要,即使可以看到某个业务对象,但也需要对某些隐私字段做数据权限处理。 例如:联系人电话、薪水等信息,不会对所有人开放。

  其实对于很多业务系统来说,可能上面的基础数据权限设计已经能够满足大部分数据权限场景了,但问题是有一类 特殊场景 解决不了。

  几乎所有复杂的数据权限设计,都是为了解决这个问题,而且因为使用场景差异太大,很难找到一个一揽子解决方案。所以需要多种方案结合,才能在便捷性、安全性上,满足中大企业复杂的数据权限要求。

  要想解决 某 一部分 数据,只允许 一部分 人操作,理论上那就意味着每一条数据都应该可以被控制。

  通常来讲,系统默认权限应该是 最严格的 , 唯一 的 限制 数据权限的方式,其他的记录级数据权限,应该是在系统默认权限的基础上,增加额外的数据权限。

  比如最极端的限制条件,所有的业务数据都是不可见的。 当然对于某些公司来讲,一些数据是全员可见的,比如像公告、通讯录、社区帖子等类型的数据。

  系统默认权限如果需要修改,应该要受到严格的控制流程管理,毕竟这是整个数据权限架构中,唯一的限制。

  通常来说,如果一个用户拥有某个业务实体创建对象的权限,那么针对这条特定的记录,用户创建完成记录后,会自动变为这条记录的所属人 ( owner ) 。

  在系统默认权限的基础上,记录的所属人就属于一种新增的数据权限,可以对这个用户进行查看操作 ( 可进行的操作应该基于基础数据权限 ) 。

  由于业务的需要,记录会在不同的用户之间进行数据转移的操作 ( transfer ownership ) ,所以记录所属人,不一定是记录的创建人。

  相关功能的成员可以在列表视图中看到这些分配器中的记录数据,并进行所属人认领的操作(更多详细内容,我会更新在后续的公海池设计当中)。

  每个企业的组织架构都会区分部门,那么就有一个非常自然的需求场景:看到本部门以及下级部门相关的所有数据。

  还有一些情况,有些公司的数据是由专门的团队负责创建的,那么针对于这些数据,就需要可以变更数据的所属部门的能力。

  随着业务的不断发展,可能会遇到跨部门数据查看的需求,也就是说,一个用户有主要的所属部门,以及根据数据权限需要而设置的多个相关部门。

  通常的做法,就是在为每一个用户,指定一个直属上级负责人,直属上级负责人会被赋予所有下属层级的相同数据权限。

  为了管理方便,也可以为直属负责人设置助理,助理与直属负责人具备相同的数据权限,这样更灵活的让不同的用户能够跳脱出公司组织架构的束缚。

  使用部门权限体系会带来一个问题,企业的组织架构往往与业务的架构是不一致的。而且业务架构会经常变化,而结构变化对于数据权限控制来讲,是一个挑战。

  这样的话,在创建岗位的同时,也可以很好的了解公司架构到底应该以什么样的形式组织在一起更高效。

  可以从上至下的设置岗位层级,比如说最高层岗位叫 CEO,可以查看整个组织的数据。然后以事业部总经理或者地区负责人的岗位,继续向下细分,查看各自岗位下的数据。

  岗位层级权限还有一个更加强大的能力,就是岗位与数据之间可以是 m:n 关系,也就是说同一条数据可以同时共享给多个岗位,满足更加复杂的数据共享场景。

  岗位层级的设计,可以将数据与用户解绑,这在人员变动,业务调整时,可以很方便的做数据共享的变更。

  对于数据权限还有一类更加接近直觉的设计方式,也就是别搞那些花里胡哨的概念,我就是要把 这一部分 数据,共享给 那一部分 人,简单直接一点,怎么做?

  换句话来讲,如果上面的权限设计体系统统不能满足业务场景,可不可以提供一种直接的数据共享方式。

  当然这里面的 特定用户 ,不仅仅只用户本身,所有包含用户的容器概念元素 ( 部门、群组、角色等 ) ,应该都包含在内。

  共享规则虽然方便,但解决不了一类更要命的数据权限场景,有些共享场景是没有办法提前可以预想的,是随机的,是随时随地的,怎么办 ?

  手工共享的数据权限设计,完全是基于记录所属人的自由意志,记录所属人认为数据应该共享给谁,就共享给谁好了。

  需要注意的是,当记录的所属关系发生变更时,那么手工共享关系应该直接解除。记录所属人也需要可以随时查看和修改,当前这条数据的手工共享情况。

  手工共享的确可以解决非常态化规则的数据权限场景,但麻烦的是,共享关系会随着记录所属人的所属关系转移,而全部丢失。

  对于一条记录来讲,如果大部分需要共享的用户不会经常发生变动,可以尝试使用团队成员的方式来进行手工共享。

  记录所属人或者有记录编辑权限的团队成员,可以同时添加其他用户作为这条记录的团队成员,记录会对所有团队成员共享。

  如果需要频繁共享给一个虚拟组织团队,就需要在每一条数据上添加若干个,相同的团队成员,效率很低。

  群组就会很好地解决这个问题,若几个用户之间需要经常共享数据,那么可以将用户们用群组圈起来,记录的所属人,可以通过将自己创建的、符合条件的数据,自动共享到若干群组中,用户也可以通过手动共享的方式,将某条数据共享到群组中。

  群组数据的共享应该是独立的,通过类似其他岗位层级,直属上级相关的其他权限,是无法突破群组成员限制的。也就是说 UserA 是群组成员,可以看到群组的数据,但 UserA 的上司由于不是群组成员,所以看不到群组的数据。

  对于大型企业应用场景,经常会出现销售、产品、服务分属于不同的业务单元,但需要根据不同的规则共享客户等相关资源。那么就可以创建多个区域层级,让同一个客户按照不同的层级结构共享给各个不同的业务单元。

  与岗位层级类似,区域层级通常应用于地盘资源管理的数据权限划分,通过多个不同的区域维度规则,如地区、客户等级、行业、产品线。相应的数据在创建 / 编辑后,可以自动进入到符合规则的区域。

  通过一些级联跟随分配的设置,数据下的相关数据也可以同时进入到相同区域,比如客户下的订单,订单下的回款单等。

  Object 业务对象级权限,说的是一个区域成员针对于具体的业务对象,是什么权限。比如针对于客户,是查看还是编辑 ?

  Hirerachy 层级权限,是说针对于业务实体,除了本级区域的权限,是否也具备下级区域的权限。

  针对于每一个区域,也可以设置这个区域的记录负责人(Territory Record Owner),这样对于基于区域管理的业务属性来讲,可以将记录做到最灵活的配置。

  小王已经从 A 事业部转岗,还能通过助理权限看到 B 事业部的客户呢,应该马上取消小王的权限。

  小张是 C 事业部的销售成员,通过群组权限看到他本应看到的客户,而不是岗位权限看到这个客户,看来客户的分配逻辑有一些问题。

  更重要的是,经常的审视数据权限体系的因果关系,也会对业务本身认识得更清晰,优秀的数据权限体系,甚至可以优化公司的业务运营体系,让效率提升自下而上的发生。

  一个媒介已经被定为成 Element,就不要同时还具备 Owner 的属性,不然可能虽然一时解决了问题,但今后的扩展会无比艰难。

  权限媒介的使用场景类型,可以帮助我们认识到,权限的灵活性,要把 人 的判断纳入到整个体系中来。过高的设置成本不但会加大业务的复杂度,而且也会让 人 失去控制感。

  相信了解了权限媒介的自身属性和使用场景之后,那我们就可以试着总结出一套适合自己公司数据权限体系架构的最佳实践原则。

上一篇:国家统计局上线新版数据库 初步实现部委数据共享 下一篇:加速数实融合腾讯云数链通数据共享隐私计算平台荣获杰出案例
关注我们
©2022 火狐体育最新登录网址_官网app入口 京公网安备110177777720125 火狐体育最新登录网址|火狐体育app