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

时间  2019-11-11 标签 权限 设计 功能 数据

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

权限管理 Authority Management

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

通常指根据系统设置的安全规则或者安全策略，
用户能够访问并且只能访问本身被受权的资源。web

场景举例

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

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

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

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

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

分类

从控制力度来看，能够将权限管理分为两大类：
  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注入等模式，轻松越权得到未受权数据。
甚至对系统数据进行修改、删除，形成巨大损失。

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

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

这种转变，如图示：

权限能够怎样设计？

原文地址：https://www.jianshu.com/p/0ab125cf8258
联系我们 沪ICP备13005482号-10