1. 基于角色的访问控制

1）RBAC介绍

核心思想: 权限不是直接分配给用户，而是分配给角色，用户通过被赋予不同角色来获得相应权限
典型示例:
管理员角色可读写所有资源
普通用户角色只能读取部分资源
英文全称: Role-Based Access Control（基于角色的访问控制）

2）RBAC模型概述

三大核心要素:
用户：系统使用者，如商户ID
角色：权限集合，如管理员、编辑、访客
权限：具体操作，如请求接口、修改数据
关联关系:
用户-角色关联
角色-权限关联
商业应用: 可根据客户付费等级分配不同角色权限

3）角色分离的好处

解耦优势:
用户与权限通过角色间接关联
类似”中间人”模式，可灵活替换任意一端
系统设计启示:
增加中转层可提升系统灵活性
类比人体关节枢纽机制
实际价值: 权限变更只需调整角色分配，不影响用户直接操作

4）最小特权原则

核心定义: 只授予执行任务所需的最小权限
企业实践:
大公司(如阿里、腾讯)严格执行该原则
定期进行安全考核(如阿里季度/半年考)
安全效益: 显著降低越权操作风险
管理建议: 技术管理者应优先考虑安全性

5）灵活性与可扩展性

扩展方法: 通过新增角色和权限组合实现
调整优势:
权限增减不影响现有用户
角色调整可批量更新用户权限
设计要点: 保持角色定义的适度粒度

6）审计的便利性

审计场景: 当发生越权访问时
排查路径:
检查角色权限分配是否过量
验证用户角色分配是否准确
日志价值: 基于角色的操作记录更易追踪

7）委派功能

操作机制: 复制角色权限后局部修改
典型场景:
临时授权场景
特殊需求处理
实现示例: 从10个权限的角色复制出新角色，移除1个权限后分配

8）RBAC设计关键点

设计步骤:
定义资源与操作(权限)
定义角色分类
建立用户-角色关联
建立角色-权限关联
表结构提示: 需根据具体业务需求定制

9）RBAC应用场景

典型系统:
多角色后台管理系统(如电商平台的运营、客服等不同后台)
开放平台接口权限控制
多类型客户端应用(如美团中的用户、商家、骑手)
适用判断: 当系统需要区分不同用户群体的操作权限时
粒度说明: 虽可实现细粒度控制，但相比ABAC等方案控制维度较单一

2. 基于属性的访问控制

1）ABAC与RBAC的比较

控制粒度：ABAC比RBAC提供更高级别、更精细化的访问控制
决策基础：
RBAC基于角色进行授权
ABAC基于属性进行授权
关系说明：角色可以视为用户的属性之一，但两者设计理念不同（如同”动物”和”人”的包含关系）

2）ABAC模型中的属性

属性来源：分为用户属性、资源属性、操作属性和环境属性四类
策略定义：通过定义不同属性的组合来决定允许或拒绝访问

3）用户属性

典型属性：
IP地址
地理位置
所属部门
职务级别
示例：财务人员身份就是一种用户属性

4）资源属性

典型属性：
数据创建者/所有者
资源敏感级别
资源类型（如订单表、客户数据等）
示例：订单表的创建者信息是重要资源属性

5）操作属性

典型操作：
读（select）
写（update）
创建（insert）
删除（delete）
扩展控制：可细化到字段级别（如允许修改商品名称但不可修改上下架状态）

6）环境属性

典型属性：
时间（工作日/非工作时间）
网络条件（局域网/外网）
设备类型
实际案例：
12306系统在2300不可访问
谷歌服务在某些网络环境下不可用

7）ABAC的核心概念

决策机制：完全基于属性进行授权判断
策略示例：”允许工作时间的财务人员访问财务数据”包含：
用户属性：财务人员
资源属性：财务数据
环境属性：工作时间

8）ABAC的实现步骤

数据结构设计

基础表：
用户表（含地区等属性）
资源表（如订单表含创建者属性）
操作表（读写等操作定义）
核心表：
属性表（记录各类属性）
策略表（策略编号和描述）
策略条件表（属性判断规则）
策略配置示例
典型策略：
策略1：地区=中国 → 允许读操作
策略2：创建者=本人 → 允许写操作
条件存储：
属性字段（如”地区”）
比较运算符（如”=”）
属性值（如”中国”）
允许操作（如”读”）
动态策略实现
配置方式：
预置策略（系统初始化时写入）
动态配置（通过管理界面添加）
技术实现：
使用JSON存储属性路径（如user.region）
约定数据库字段命名规范
支持运算符配置（=,>,<等）
优势：新增策略时无需修改代码，通过配置即可实现

3. 基于策略的访问控制

核心概念：PBAC(Policy-Based Access Control)是以策略规则为核心的访问控制方式，区别于基于角色(RBAC)和基于属性(ABAC)的访问控制模型。
策略本质：策略本质上是一组访问控制规则，通过评估用户、资源、操作和环境等多维度因素来决定是否允许访问。

1）策略的定义

规则组成：策略由用户角色、部门属性、时间条件等要素构成，例如：
管理员可对所有文档进行读写删除
销售部门仅能访问本部门文档
仅工作时间允许访问特定数据
动态特性：策略可包含临时性参数（如用户实时地理位置），这些参数不适合作为固定属性存储在用户表中。

2）策略与属性的灵活性比较

设计出发点：
RBAC以角色为核心
ABAC以属性为核心
PBAC以策略规则为核心
包含关系：策略模式比属性控制更灵活，可以包含属性判断（如json(user.region,order.owner.region)），还能处理非固定属性（如网络环境）
典型场景：
地区限制访问（如大陆地区不可访问特定网站）
时间段控制（如仅工作时间允许访问）
动态环境判断（如网络IP位置）

4. 基于上下文的访问控制

1）能力与上下文的定义

术语解释：
CBAC：Context-Based Access Control（基于上下文的访问控制）
CoBAC：Capability-Based Access Control（基于能力的访问控制）
命名差异：
学术界存在不同命名习惯，CoBAC有时也被称为CBS或C
其中C可翻译为”能力”（Capability）
核心区别：
CBAC侧重环境上下文（如时间、地点）
CoBAC侧重用户能力属性（如权限等级）

2）CBAC与CoBAC的概念

共性要素：
用户表（如用户ID、姓名）
资源表（如订单ID）
操作表（如读/写操作编码）
类比说明：
类似动物分类中的”虎种”与”亚种”关系
本质都是访问控制模型，侧重维度不同

3）CBAC的组成与示例

核心组件：
能力表：存储权限能力项（如能力1、能力2）
用户-能力关联表：建立用户与能力的映射关系
能力-权限关联表：定义能力对应的具体操作权限
运行流程：
验证用户身份
查询用户关联能力
校验能力对应的资源操作权限
实例演示：
用户表：1号用户”依然”
资源表：1号订单
能力表：能力1→读权限
关联关系：用户1→能力1→读订单1

4）CoBAC的上下文表与示例

上下文表特点：
存储环境变量（如工作日定义）
通常需要人工维护（如节假日调整）
示例：股票系统需维护特殊交易日
典型上下文：
时间上下文（工作日/节假日）
网络环境（WIFI/4G/5G）
地理位置（IP区域）
权限判定逻辑：
与CBAC的整合：
在权限判定时增加上下文条件校验
上下文ID作为权限规则的附加参数

5. 访问控制模型总结

1）主流访问控制模型

RBAC（基于角色的访问控制）：通过角色作为中间层来管理用户权限，用户通过分配角色间接获得权限。
ABAC（基于属性的访问控制）：根据用户属性（如部门、职级）、资源属性和环境条件动态判断访问权限。
PBAC（基于策略的访问控制）：通过预定义的策略规则（如）进行权限决策。
CBAC（基于能力的访问控制）：用户直接关联能力（如），能力决定可执行操作。
CoBAC（基于上下文的访问控制）：在传统模型基础上增加上下文条件（如）。

2）设计方法论

设计出发点：明确系统权限设计的核心维度（角色/属性/上下文等），但不要被单一模型限制。
扩展性原则：初始设计可通过加表（用户-能力关联表、策略条件表等）实现模型融合，例如：
RBAC中扩展属性表（user(region)+order(owner)）
CBAC中增加上下文条件（+context(weekday)）
实践建议：实际工作中可能简化或复杂化模型设计，关键在于掌握”表结构可扩展”的底层逻辑。

3）混合应用案例

典型场景：订单状态修改权限控制
用户属性：
资源属性：
上下文条件：
最终决策：
混合设计：
基础采用RBAC角色分配
增加ABAC属性校验（地区匹配）
叠加CoBAC时间限制
通过关联表实现能力扩展

4）核心思想总结

技术服务于业务：模型只是工具，应基于业务需求选择/组合设计（如电商系统可能同时需要RBAC+ABAC）
消除设计恐惧：所有bac变体本质都是”用户-资源-操作”关系的不同组织方式
架构师思维：
初始设计抓住一个核心维度（如先实现RBAC）
后续通过、等表扩展
示例：已实现的RBAC系统可通过添加表支持属性校验