html5网站正在建设中模板下载,wordpress postmeta表,wordpress的优缺点,中国建筑集团有限公司官网2024届校园招聘权限管控可以通俗的理解为权力限制#xff0c;即不同的人由于拥有不同权力#xff0c;他所看到的、能使用的可能不一样。对应到一个应用系统#xff0c;其实就是一个用户可能拥有不同的数据权限#xff08;看到的#xff09;和操作权限#xff08;使用的#xff09;。
…权限管控可以通俗的理解为权力限制即不同的人由于拥有不同权力他所看到的、能使用的可能不一样。对应到一个应用系统其实就是一个用户可能拥有不同的数据权限看到的和操作权限使用的。
主流的权限模型主要分为以下五种 ACL模型访问控制列表 DAC模型自主访问控制 MAC模型强制访问控制 ABAC模型基于属性的访问控制 RBAC模型基于角色的权限访问控制
ACL模型访问控制列表
Access Control ListACL是最早的、最基本的一种访问控制机制是基于客体进行控制的模型在其他模型中也有ACL的身影。为了解决相同权限的用户挨个配置的问题后来也采用了用户组的方式。
原理每一个客体都有一个列表列表中记录的是哪些主体可以对这个客体做哪些行为非常简单。
例如当用户A要对一篇文章进行编辑时ACL会先检查一下文章编辑功能的控制列表中有没有用户A有就可以编辑无则不能编辑。再例如不同等级的会员在产品中可使用的功能范围不同。
缺点当主体的数量较多时配置和维护工作就会成本大、易出错。
DAC模型自主访问控制
Discretionary Access ControlDAC是ACL的一种拓展。
原理在ACL模型的基础上允许主体可以将自己拥有的权限自主地授予其他主体所以权限可以任意传递。
例如常见于文件系统LINUXUNIX、WindowsNT版本的操作系统都提供DAC的支持。
缺点对权限控制比较分散例如无法简单地将一组文件设置统一的权限开放给指定的一群用户。主体的权限太大无意间就可能泄露信息。
MAC模型强制访问控制
Mandatory Access ControlMAC模型中主要的是双向验证机制。常见于机密机构或者其他等级观念强烈的行业如军用和市政安全领域的软件。
原理主体有一个权限标识客体也有一个权限标识而主体能否对该客体进行操作取决于双方的权限标识的关系。
例如将军分为上将中将少将军事文件保密等级分为绝密机密秘密规定不同军衔仅能访问不同保密等级的文件如少将只能访问秘密文件当某一账号访问某一文件时系统会验证账号的军衔也验证文件的保密等级当军衔和保密等级相对应时才可以访问。
缺点控制太严格实现工作量大缺乏灵活性。
ABAC模型基于属性的访问控制
Attribute-Based Access Control能很好地解决RBAC的缺点在新增资源时容易维护。
原理通过动态计算一个或一组属性是否满足某种机制来授权是一种很灵活的权限模型可以按需实现不同颗粒度的权限控制。
属性通常有四类 主体属性如用户年龄、性别等 客体属性如一篇文章等 环境属性即空间限制、时间限制、频度限制 操作属性即行为类型如读写、只读等。
例如早上9:0011:00期间A、B两个部门一起以考生的身份考试下午14:0017:00期间A、B两个部门相互阅卷。
缺点规则复杂不易看出主体与客体之间的关系实现非常难现在应用的很少。
RBAC基于角色的权限访问控制
Role-Based Access Control核心在于用户只和角色关联而角色代表对了权限是一系列权限的集合。
RBAC三要素 用户系统中所有的账户 角色一系列权限的集合如管理员开发者审计管理员等 权限菜单按钮数据的增删改查等详细权限。
在RBAC中权限与角色相关联用户通过成为适当角色的成员而得到这些角色的权限。
角色是为了完成各种工作而创造用户则依据它的责任和资格来被指派相应的角色用户可以很容易地从一个角色被指派到另一个角色。
角色可依新的需求和系统的合并而赋予新的权限而权限也可根据需要而从某角色中回收。角色与角色的关系同样也存在继承关系防止越权。
优点便于角色划分更灵活的授权管理最小颗粒度授权 RBAC的深度拓展
RBAC模型可以分为RBAC0、RBAC1、RBAC2、RBAC3 四个阶段一般公司使用RBAC0的模型就可以。另外RBAC0相当于底层逻辑后三者都是在RBAC0模型上的拔高。
我先简单介绍下这四个RBAC模型
1. RBAC0模型
用户和角色、角色和权限多对多关系。
简单来说就是一个用户拥有多个角色一个角色可以被多个用户拥有这是用户和角色的多对多关系同样的角色和权限也是如此。
RBAC0模型如下图没有画太多线但是已经能够看出多对多关系。 2. RBAC1模型
相对于RBAC0模型增加了角色分级的逻辑类似于树形结构下一节点继承上一节点的所有权限如role1根节点下有role1.1和role1.2两个子节点 角色分级的逻辑可以有效的规范角色创建主要得益于权限继承逻辑我之前做过BD工具类CRMBD之间就有分级经理、主管、专员如果采用RBAC0模型做权限系统我可能需要为经理、主管、专员分别创建一个角色角色之间权限无继承性极有可能出现一个问题由于权限配置错误主管拥有经理都没有权限。
而RBAC1模型就很好解决了这个问题创建完经理角色并配置好权限后主管角色的权限继承经理角色的权限并且支持针对性删减主管权限。
3. RBAC2模型
基于RBAC0模型对角色增加了更多约束条件。 如角色互斥比较经典的案例是财务系统中出纳不得兼管稽核那么在赋予财务系统操作人员角色时同一个操作员不能同时拥有出纳和稽核两个角色。
如角色数量限制例如一个角色专门为公司CEO创建的最后发现公司有10个人拥有CEO角色一个公司有10个CEO这就是对角色数量的限制它指的是有多少用户能拥有这个角色。
RBAC2 模型主要是为了增加角色赋予的限制条件这也符合权限系统的目标权责明确系统使用安全、保密。
4. RBAC3模型
同样是基于RBAC0模型但是综合了RBAC1和RBAC2的所有特点
这里就不在多描述读者返回去看RBAC1和RBAC2模型的描述即可。
RBAC 权限管理的在实际系统中的应用
RBAC 权限模型由三大部分构成即用户管理、角色管理、权限管理。
用户管理按照企业架构或业务线架构来划分这些结构本身比较清晰扩展性和可读性都非常好。
角色管理一定要在深入理解业务逻辑后再来设计一般使用各部门真实的角色作为基础再根据业务逻辑进行扩展。
权限管理是前两种管理的再加固做太细容易太碎片做太粗又不够安全这里我们需要根据经验和实际情况来设计。
1.用户管理
用户管理中的用户是企业里每一位员工他们本身就有自己的组织架构我们可以直接使用企业部门架构或者业务线架构来作为线索构建用户管理系统。
需要特殊注意实际业务中的组织架构可能与企业部门架构、业务线架构不同需要考虑数据共享机制一般的做法为授权某个人、某个角色组共享某个组织层级的某个对象组数据。
2.角色管理
在设计系统角色时我们应该深入理解公司架构、业务架构后再根据需求设计角色及角色内的等级。
一般角色相对于用户来说是固定不变的每个角色都有自己明确的权限和限制这些权限在系统设计之处就确定了之后也轻易不会再变动。
1. 自动获得基础角色
当员工入职到某部门时该名员工的账号应该自动被加入该部门对应的基础角色中并拥有对应的基础权限。这种操作是为了保证系统安全的前提下减少了管理员大量手动操作。使新入职员工能快速使用系统提高工作效率。
2. 临时角色与失效时间
公司业务有时需要外援来支持他们并不属于公司员工也只是在某个时段在公司做支持。此时我们需要设置临时角色来应对这种可能跨多部门协作的临时员工。
如果公司安全级别较高此类账号默认有固定失效时间到达失效时间需再次审核才能重新开启。避免临时账号因为流程不完善遗忘在系统中引起安全隐患。
3. 虚拟角色
部门角色中的等级可以授权同等级的员工拥有相同的权限但某些员工因工作原因需要调用角色等级之外的权限相同等级不同员工需要使用的权限还不相同。
这种超出角色等级又合理的权限授予我们可以设置虚拟角色。这一虚拟角色可集成这一工作所需的所有权限然后将它赋予具体的员工即可。这样即不用调整组织架构和对应的角色也可以满足工作中特殊情况的权限需求。
4. 黑白名单
白名单某些用户自身不拥有某部门的顶级角色但处于业务需求需要给他角色外的高级权限那么我们可以设计限制范围的白名单将需要的用户添加进去即可。
在安全流程中我们仅需要对白名单设计安全流程即可审核在白名单中的特殊用户做到监控拥有特殊权限的用户减少安全隐患。
黑名单比较常见的黑名单场景是某些犯了错误的员工虽然在职但已经不能给他们任何公司权限了。这种既不能取消角色关联也不能完全停用账号的情况可以设置黑名单让此类用户可以登录账号查看基本信息但大多数关键权限已经被黑名单限制。
3. 权限管理
权限管理一般从三个方面来做限制。页面/菜单权限操作权限数据权限。 1. 页面/菜单权限
对于没有权限操作的用户直接隐藏对应的页面入口或菜单选项。这种方法简单快捷直接对于一些安全不太敏感的权限使用这种方式非常高效。
2. 操作权限
操作权限通常是指对同一组数据不同的用户是否可以增删改查。对某些用户来说是只读浏览数据对某些用户来说是可编辑的数据。
3. 数据权限
对于安全需求高的权限管理仅从前端限制隐藏菜单隐藏编辑按钮是不够的还需要在数接口上做限制。如果用户试图通过非法手段编辑不属于自己权限下的数据服务器端会识别、记录并限制访问。
4. 数据权限如何管控
数据权限可以分为行权限和列权限。行权限控制看多少条数据。列权限控制看一条数据的多少个字段
简单系统中可以通过组织架构来管控行权限按照角色来配置列权限但是遇到复杂情况组织架构是承载不了复杂行权限管控角色也更不能承载列的特殊化展示。
目前行业的做法是提供行列级数据权规则配置把规则当成类似权限点配置赋予某个角色或者某个用户。 用户管理系统权限设计中的更多实践细节
1.超级管理员
超级管理员是用来启动系统配置系统的账号。这个账号应该在配置好系统创建管理员之后被隐藏起来。超级管理员账号拥有系统中全部权限可穿梭查看各部门数据如果使用不恰当是系统管理的安全隐患。
2.互斥角色如何处理
当用户已经有用的角色和即将添加的角色互相互斥时应该在添加新角色时提示管理员因角色互斥的原因无法进行新角色添加。如需添加要先撤销掉前一个角色再添加新角色。
3.用户管理权限系统设计一定要简单清晰
在设计权限系统之处一定要理清思路一切从简能不增加的多余角色和权限逻辑就一定不要增加。因为随着公司业务的扩大权限和角色也会随之增多如果初期设计思路不严谨那么权限系统会随着业务的扩大而无限混乱下去此时再来整理权限已经太晚了。所以初期设计就一定要条理清晰简单明了能避免后续非常多不必要的麻烦。
4.无权提示页
有时员工 A 会直接给员工 B 分享他当下正在操作的页面但有可能员工 B 无权查看。此时我们应该在这里考虑添加「无权提示页」避免粗暴的 404 页面让员工 B 以为是系统出错了。
