权限设计=功能权限+数据权限

权限管理 Authority Management

目前主要是通过用户、角色、资源三方面来进行权限的分配。
具体来说，就是赋予用户某个角色，角色能访问及操作不同范围的资源。
通过建立角色系统，将用户和资源进行分离，来保证权限分配的实施。

一般指根据系统设置的安全规则或者安全策略，
用户可以访问而且只能访问自己被授权的资源。

---

场景举例

企业IT管理员一般都能为系统定义角色，给用户分配角色。
这就是最常见的基于角色访问控制。

场景举例：

1. 给张三赋予“人力资源经理”角色，“人力资源经理”具有“查询员工”、“添加员工”、“修改员工”和“删除员工”权限。此时张三能够进入系统，则可以进行这些操作；
2. 去掉李四的“人力资源经理”角色，此时李四就不能够进入系统进行这些操作了。

以上举例，局限于功能访问权限。还有一些更加丰富、更加细腻的权限管理。

比如：

1. 因为张三是北京分公司的“人力资源经理”，所以他能够也只能够管理北京分公司员工和北京分公司下属的子公司（海淀子公司、朝阳子公司、西城子公司、东城子公司等）的员工；
2. 因为王五是海淀子公司的“人力资源经理”，所以他能够也只能够管理海淀子公司的员工；
3. 普通审查员审查财务数据的权限是：在零售行业审核最高限额是￥50万，在钢铁行业最高限额是￥1000万；高级审查员不受该限额限制；
4. ATM取款每次取款额不能超过￥5000元，每天取款总额不能超过￥20000元。

这些权限管理和数据（可以统称为资源）直接相关，
又称为数据级权限管理、细粒度权限管理或者内容权限管理。

---

分类

从控制力度来看，可以将权限管理分为两大类：

1. 功能级权限管理；
2. 数据级权限管理。

从控制方向来看，也可以将权限管理分为两大类：

1. 从系统获取数据，比如查询订单、查询客户资料；
2. 向系统提交数据，比如删除订单、修改客户资料。

 

---

概念

用户身份认证，是要解决这样的问题：用户告诉系统“我是谁”，系统就问用户凭什么证明你就是“谁”呢？
所以，用户身份认证，根本就不属于权限管理范畴。
　　对于采用用户名、密码验证的系统，那么就是出示密码
　　——当用户名和密码匹配，则证明当前用户是谁；
　　对于采用指纹等系统，则出示指纹；
　　对于硬件Key等刷卡系统，则需要刷卡。
密码加密，是隶属用户身份认证领域，不属于权限管理范畴。

系统管理，一般是系统的一个模块。
而且该模块一般还含有权限管理子模块。
因此，很多人误认为权限管理系统只是系统的一个小小的子模块。

系统管理里面的权限管理模块，只是一个操作界面，让企业IT管理员能够设置角色等安全策略。
系统背后还有很多权限验证逻辑，这些都并不属于该模块。
总体来说，该模块相当于给权限管理模块提供了一些数据，比如：张三是人力资源经理等。
更多混淆概念，请参考：《对权限管理认识的一些误区》。

---

技术实现

按照权限管理的力度，逐步介绍权限管理实现技术。

① 功能权限管理技术实现

功能权限管理技术，一般就使用基于角色访问控制技术RBAC（Role Based Access Control）。该技术被广泛运用于各个系统，非常容易掌握。该技术模型如下图示：

 

权限验证
功能级的权限验证逻辑非常简单：查看该当前登录用户的角色是否包含该功能的权限。
如果有，则表示有权访问，否则表示无权访问。
对于WEB系统，一般定义一个Filter就可以完成权限验证，无需在各个程序入口进行权限判断。

程序伪代码如下：

// 获取访问功能
*String url=request.getRequestPath();*
// 进行权限验证
*User user=request.getSession().get("user");*
*boolean permit=PrivilegeManager.permit( user, url );*
*if( permit ) {*
*chain.doFilter( request, response );*
*} else {*
// 可以转到提示界面
}

② 数据级权限管理技术实现

目前，数据级权限管理领域，一直没有统一的技术。

大体上，软件开发人员采用如下技术：

1. 硬编码，也就是将这种逻辑以 if/else 等形式与业务代码耦合在一起，这种情况居多；
2. 使用规则引擎，也有一些企业将这种逻辑以规则形式提出来，并使用规则引擎解析规则；
3. 使用第三方专业软件，有开源中间件Ralasafe；
    开源框架Spring Security；
    商业产品Oracle Entitlements Server，
    IBM Tivoli Access Manager，
    UPMS通用用户权限系统等。

• 硬编码形式弊端是非常显然的。
  耦合性强，难以测试；系统组件复用率低；
  系统后期改动代价非常大，牵一发而动全身。
• 使用规则引擎可以解决很多问题，学习难度尚可。
  但规则引擎并不是专业用于权限管理的，
  所以对于复杂一些的权限管理，就显得力不从心。
• Ralasafe和Oracle、IBM的商业产品一样，都是中间件形式，
  对应用系统和应用数据库结构没有要求。
  都有管理界面进行直接操控管理，而且都能在线进行测试。
  • 相比较，Ralasafe还可以控制查询权限（即从系统查询订单、查询客户等），
    Oracle、IBM的商业产品没有这方面功能；
  • 从产品学习难度来看，Ralasafe只要有一些IT经验，就能快速上手；
    Oracle、IBM产品即使是专业人员，也难以掌握。
  • Spring Security是框架，需要对你的应用系统进行改动，你的系统必须在该框架进行设计编写。
    它只是帮助开发人员将权限提取出来了，但数据级权限还需要开发人员开发Voter。
    而且配置工作巨大，难以测试。
  • 虽然上述提到的产品，都是Java产品。
    但Ralasfe和Oracle、IBM的商业产品，以中间件形式，
    可以部署在独立服务器上，使用web service等方式与非Java系统交互。

---

实施

① 功能级权限控制
这是很多系统都能做到的。
让系统使用者（一企业IT管理员）定义角色，给用户分配角色。
成功实施该步骤，用户能在功能级进行权限管理。
整个过程无需软件开发商参与。

② 部分预定义好的数据级权限
有些复杂一点的系统，提供了一些规则和管理界面，
可以让系统使用者（一般是企业IT管理员）输入规则参数。

比如普通审查员审查财务数据的金额区间，勾选某用户能够查询哪些组织机构的订单数据。

这是给企业提供了部分控制数据级权限的能力。
但该能力还非常弱，仅限于已定义好的策略，不能适应安全策略变化。
而且，企业需求肯定会随着业务发展、时间推移，发生变化。

比如：普通审查员审查区间由原来的单一设置区间，改为按照行业、按照地域来设置不同的区间。
用户查询订单不仅和组织机构有关，还和订单业务领域（体育、食品等）有关。

当这些需求发生的时候，企业还要求助于软件开发商进行修改。

③ 企业完全掌控安全策略

企业完整掌控安全策略，应该包括2个方面内容：

1. 功能级权限管理完全自我掌控；
2. 数据级权限管理完全自我掌控。

实现这方面需要，还需要考虑企业的IT能力：
IT能力没有软件开发商强，而且权限管理涉及整个系统安全，关系重大。

因此软件必须是这样的：

1. 图形化、集中管理的，便于企业管理；
2. 可在线测试的，定制策略后在不影响业务的情况下，进行测试，确保无误。
   目前，就Ralasafe和Oracle、IBM产品满足要求。

---

注意问题

不良的权限管理系统，必然留下系统漏洞，给黑客可趁之机。
很多软件可以轻松通过URL侵入、SQL注入等模式，轻松越权获得未授权数据。
甚至对系统数据进行修改、删除，造成巨大损失。

很多系统，尤其是采用硬编码方式的系统，存在权限逻辑与业务代码紧密耦合，
同时又分散在系统各个地方，系统漏洞势必非常多，
而且随着系统不断修改，漏洞逐步增多。

好的系统，应该将权限逻辑集中起来，由专业的安全引擎进行设置、解析。
业务逻辑调用安全引擎，获得权限结果，不再使用非专业模式。

这种转变，如图示：

 

---

权限可以怎样设计？

1、后台设计（一）：后台设计三原素

后台系统，在目前接触来看，主要分几种：管人、管事、管物。管人的，有对内和对外的两种类型，对外的CRM（客服管理系统）、对内的考勤系统；管事的，简而言之，就是人可以做什么事、可以怎样去做事，这种最经典的就是数据统计后台、业务流管理后台；管物的，主要是指电商类型的商城管理后台，用于管理商品的交易

    但是，从本质上看，后台主要有权限管理、工作流、记录流三大方面。可以归结为一句话，谁可以对什么进行怎样的操作，需要产生什么记录：简称who-where-how-what

权限管理（who-where）

权限管理，是指一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源。通俗解释就是，谁是否对某资源具有实施 某个动作（运动、计算）的权限

      权限管理，目前主要是通过用户、角色、资源三方面来进行权限的分配。具体来说，就是赋予用户某个角色，角色能访问及操作不同范围的资源。通过建立角色系统，将用户和资源进行分离，来保证权限分配的实施。

       那么，权限可以怎样设计呢？

       如果是业务流后台，在设计权限时，可以按业务类型进行角色设计，比如客服、运营、充值员；如果是数据统计后台，可以按用户类型来进行角色设计，如对外用户、内部人员；如果是CRM，则可以按用户的职位等级进行划分。在进行一级划分后，往往还需要对角色进行细分，例如客服，可以细分为 普通客服、客服组长、客服总监，通过级别的划分来控制可访问及操作的数据。

        另外，在进行角色的细化时，有两点是需要注意的：

1. 同类型的角色，上下级角色的权限关联是怎样的？上级角色是否能对下级角色的业务进行操作？下架的操作是否需要上级的审核？

2. 对外用户，是采取权限分离，还是采取两个不同的后台去处理？前者的话，实现起来方便一些，就看系统对于安全性的考虑；后者的话，会更加的安全，在数据的处理上也会方便一些

        虽然我们将权限管理放在第一位，但是在实际开发过程中，权限的分配往往是在整个后台开发完毕后才去实现的（主要是为了避免权限设置对开发造成影响）。

工作流（how）

工作流（Workflow），指“业务过程的部分或整体在计算机应用环境下的自动化”。是对工作流程及其各操作步骤之间业务规则的抽象、概括描述

        工作流主要解决的主要问题是：为了实现某个业务目标，利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务。

        设计工作流时，除了最基本的单个后台工作流的设计，还有多个后台之间进行工作流的设计。OK，先从最基本的单个后台开始聊聊，工作流的设计，其实和2C产品的需求设计很相似：

1. 在了解业务需求后，产出适合的业务流程图（业务流程图此处不展开，稍后另开一章来写）、状态图（部分简单的工作流不需要出这个），通过业务流程图，向开发更好的传递业务需求

2. 搭建工作流的产品架构图，主要是罗列工作流涉及到的功能模块（广度思考），这个时候，就可以将产品架构图和其他人进行碰撞；为什么不使用产品原型图来碰呢？这个以下几点原因：

（1）产品原型产出周期较长，不适合前期的思维碰撞

（2）产品架构图比产品原型返工更容易，能够更快的迭代

（3）可以针对后期加入的需求低成本的进行讨论，使开发设计库表时，更好的考虑拓展性

3. 通过前两步，基本可以把工作流较好的传递给研发那边；紧接着，可以将产品架构图进行细化，细化到什么程度呢？最好是把工作流涉及的点都能够细化在上面，这样，在产出产品原型图的时候，可以更加全面的是思考单个模块与整个后台系统之间的交互

4.在第三点，有提到了产品架构图的细化，接着，就是放大招的时候— 出产品原型图

5.适当的重复上述3、4点，这样，一个较完整的工作流就设计好了

      在出了产品原型图，就要开始和研发大大进行更凶残的肉体碰撞了，关于肉体碰撞的细节，在这里就不展开了，但是可以补充一句：做产品得耐操！

      上面讲述的都是单个系统内的工作流设计，那么 多个系统协同处理的工作流有什么不同呢？

      首先在设计上，基本流程不会有区分。主要是要和系统架构师多多沟通，让一整套系的工作流能够更好的满足业务需求。在进行沟通的时候，最好可以先自己拟定一份假想架构图，这份产出物更多关注的是不同系统之间的数据交互，表明系统间的输出、输入，这样，在定好满足需求的架构上，才能够更好的对工作流进行设计。

       其次，还有一点细节是需要关注的，那就是在不同后台的原型图中，要注意描述清楚工作流是否与其他模块有所交互，这样方便自己，也方便他人。

记录流（what）

      后台系统进行设计时，往往都会有一个专门的操作日志，记录后台登录用户的操作轨迹，主要是因为后台数据对于企业来说是比较有价值的，所以需要对其进行保护。

      总的来说，记录流主要分 操作轨迹、数据查询两种。

      操作轨迹，很容易理解，就是用户对后台的数据进行操作所产生的记录，需要达到一步一记录的程度。这种，在进行设计时，就是将初始状态、变更状态、操作内容、操作人、操作时间罗列清楚就OK了，不同业务差异性不大，算是后台的标配模块

      数据查询，这个的话，更多是对于工作流中产生的数据进行整理，然后形成的功能模块。这种的话，不会像操作轨迹那样，每一步都会记录下来。而是会根据具体的业务需求来进行设计，以满足用户能够在后台中针对不同纬度的数据进行查询、了解、分析，获取价值。

      出了上述的三个基本模块，在进行后台设计的时候，还有一点可以关注一下，尽量使用默认控件去进行设计，以及不同模块之间，能够使用较为统一的交互方式，这样开发起来更有效率。