接触权限这部分是起于去年，因公司实际业务需要，需要对系统原先的权限模型进行改造。一年下来，也算是对权限开发有了些心得，因此写篇文章记录下。
- 一个完善的访问控制系统，需要些什么
- 典型访问控制策略，根据业务情况不同可能一个也可能多个组合起来用，具体可以看下文的权限模型
- 入参检验，这四个字其实包含了很多方面，比如边界检查，如果不限制用户的输入尺寸，多个肉鸡一起发超大字符串，服务器很快就顶不住了，轻则服务器崩溃，重则被攻击者拿到root权限和导致内存数据泄露，其他还有非法SQL检验，用户环境检验（防跨站请求伪造）等等
- 防遍历查询，引发遍历查询漏洞的典型情况是使用自增ID作为查询的入参，其他还有一个比较容易被忽略的点，举个客服查看用户工单的例子，客服一般是没有权限直接查看用户数据的，但是当用户提交工单后，客服必须有查看该用户部分信息的权限，而在工单结束之后，系统需要收回客服的查看该用户信息的权限，如果系统设计忽略了这点，就可能会导致用户数据泄露。另外，关键接口的限流和审计也很重要，但这是另外一回事了，足够另写一篇文章的。
接下来列举一些常见的权限模型
*** Discretionary Access Control (DAC)**
该模型常见于操作系统，如图所示，基于对象所属的用户或者组限制访问对象
- **Role-Based Access Control (RBAC) **
这个模型应该都很熟悉了，普遍存在于CMS，ERP，CRM等系统中，能很好的反映出现实世界当中的权限体系。RBAC模型存在以下约定(摘自维基百科):
RBAC定义了三个主要规则：
-
角色分配：仅当对象已选择或分配了角色时，对象才能行使权限。
-
角色授权：必须为主体授权主体的活动角色。
-
权限授权：仅当对象的活动角色被授权时，对象才能行使权限。
-
S =主题=个人或代理
-
R =角色=定义权限级别的职务或职务
-
P =权限=对资源访问方式的批准
-
SE =会话=涉及S，R和/或P的映射
-
SA =主题分配
-
PA =权限分配
-
RH =部分排序的角色层次结构。RH也可以写成：≥（表示法：x≥y表示x继承了y的权限。）
-
一个主体可以分配多个角色。
-
一个角色被分配给多个主体。
-
一个角色可以具有许多权限。
-
可以将权限分配给许多角色。
-
可以将一个操作分配给许多权限。
-
可以将权限分配给许多操作。
根据NIST开发的RBAC规定，RBAC模型还可以分为3个等级
1.也就是以上描述的RBAC核心内容
2.分层RBAC，引入了角色的继承概念
3.约束RBAC，引入了职责分离的概念
关于RBAC模型，这里就不继续赘述了，有兴趣的可以去下载个NIST关于RBAC的标准文档看看。---> PDF在这里 <---
- Lattice-based Access Control(LBAC)
基于网格的访问控制模型，国内更多的被称为基于标签的访问控制(Lable-based)。
这是一个很复杂的模型，知识面有限，目前我见过的使用场景只有IBM的DB2数据库。
DB2通过使用安全标签的方式，来实现行级和列级的读写访问控制。
- Attribute-based Access Control(ABAC)
基于属性的访问控制，有时也被称为基于策略(PBAC)或者基于声明(CBAC)的访问控制，其实现的核心是XACML——基于属性的访问控制策略语言。XACML支持绝大部分的算术函数，字符串函数，逻辑符号，正则表达式，甚至XPath和部分高阶函数(anyOf，allOf等)。
由此可见ABAC模型有多强大的动态授权能力了，你可以定义某人在某个时间点在哪里能做什么事情和在这个人处于什么条件下的时候不能做什么事情。
ABAC有其标准化的文档，具体可以参考NIST的ABAC标准。
ABAC的用途非常广泛，无论是ERP，CRM，CMS系统，还是数据库，文件系统都可见其身影，典型的使用场景就是某些情况下用户只能访问自己私有的数据，不能访问其他人的数据。
其他还有很多权限模型，比如流程引擎当中使用的TBAC(基于任务的访问控制)，防火墙使用的CBAC(基于上下文的访问控制)，Linux内核使用的RSBAC(基于规则集的访问控制)等等。
参考书籍：《数据安全架构与设计实战》——郑云文 著
