授权（Authorization）

授权的核心是 “**基于身份或属性，动态判断主体是否有权访问资源**”，防止合法身份的主体越权操作（如普通员工删除企业核心数据）。

其技术体系从 “静态规则” 发展到 “动态决策”，从 “集中管控” 升级到 “分布式授权”，可分为**授权模型、授权框架、实践工具**三大模块。

## 授权模式

> 自主访问控制（Discretionary Access Control, DAC）

定义：资源所有者自主决定谁能访问资源及权限，权限可由所有者主动转让（如 “你分享文件给同事，并允许他再分享给他人”）。

核心逻辑：资源关联 “访问控制列表（ACL）”，记录 “哪个主体有哪种权限”（如 “用户 A→文件 X→读取权限”）。

优点：灵活性高，符合个人或小型团队的权限管理习惯。

缺点：权限易扩散（如 “转让的权限被多级传递”）、缺乏集中管控，不适合高安全需求场景。

场景：个人设备（如电脑文件共享）、小型团队协作（如部门内部文档共享）。

案例：Windows/Linux 文件系统的权限管理（如 Linux 的 rwx 权限：读、写、执行）、云存储桶的 ACL 配置（如阿里云 OSS 允许特定用户读取文件）。

> 强制访问控制（Mandatory Access Control, MAC）

定义：由系统（而非资源所有者）基于 “主体和客体的安全级别” 强制分配权限，所有者无法自主修改权限，核心是 “按安全等级隔离”。

核心逻辑：

- 为每个主体（用户 / 进程）和客体（文件 / 数据库表）分配 “安全级别”（如 “绝密 > 机密 > 秘密 > 公开”）；
- 系统预设规则：仅当 “主体安全级别 ≥ 客体安全级别” 时，才允许访问（如 “机密级用户可访问秘密级文件，但无法访问绝密级文件”）。

优点：安全性极高，严格防止高敏感资源泄露。
缺点：灵活性差、权限配置复杂、运维成本高。
场景：军事系统、政府机密数据、金融核心交易数据（需最高级别的安全隔离）。
案例：美国国防部的 “Bell-LaPadula 模型”（用于机密数据隔离）、Linux 的 SELinux（Security-Enhanced Linux）、Windows 的 BitLocker 加密存储。

> 基于角色的访问控制（Role-Based Access Control, RBAC）

定义：通过 “角色” 作为中间层，关联 “主体 - 角色 - 权限”，先为角色分配权限，再将角色赋予用户，核心是 “按职责分配权限”。

核心逻辑（RBAC96 国际标准模型）：

- 定义角色：根据业务职责划分（如 “开发工程师”“运维人员”“财务审核员”）；
- 分配权限：为每个角色绑定 “最小必要权限”（如 “运维人员” 拥有 “服务器重启权限”，无 “数据库删除权限”）；
- 关联用户：将用户归入对应角色（如 “张三” 被分配 “开发工程师” 角色，自动获得该角色的所有权限）。

特性：

- 角色继承：高级角色继承低级角色的权限（如 “高级开发工程师” 继承 “开发工程师” 的权限）；
- 角色互斥：冲突角色不可同时赋予同一用户（如 “财务录入” 与 “财务审核” 角色互斥，避免舞弊）。

优点：

- 权限管理简化：无需为每个用户单独配置权限，只需维护角色与权限的映射；
- 符合企业组织架构：角色与岗位职责对齐，人员变动时（如离职、调岗）仅需调整角色。

缺点：角色定义依赖固定职责，面对动态场景（如临时项目、跨部门协作）灵活性不足。

场景：绝大多数企业场景（如 OA、CRM、云平台管理），是目前应用最广泛的授权模型。

案例：企业 ERP 系统的权限管理（如 “财务角色” 仅能访问财务模块）、云平台 IAM（如 AWS IAM 的角色授权）。

> 基于属性的访问控制（Attribute-Based Access Control, ABAC）

定义：通过 “主体、资源、环境的多维度属性” 动态判断权限，核心是 “按属性组合决策”，而非预定义角色。

核心逻辑：

1. 定义属性维度（三类核心属性）：
   - 主体属性：用户职位（如 “产品经理”）、部门（如 “研发部”）、资质（如 “PMP 认证”）；
   - 资源属性：资源类型（如 “客户数据”）、敏感度（如 “高敏感”）、所属项目（如 “项目 A”）；
   - 环境属性：访问时间（如 “工作日 9:00-18:00”）、访问设备（如 “企业办公电脑”）、网络位置（如 “内网 IP”）；
2. 配置决策规则：例如「若主体部门 = 研发部 AND 资源所属项目 = 项目 A AND 访问环境 = 内网 → 允许读取资源」；

优点：

- 灵活性极高：支持动态场景（如临时项目、跨部门协作），无需频繁调整角色；
- 细粒度管控：可基于多维度属性精准控制（如 “仅允许张三在办公室用企业电脑访问项目 A 的高敏感数据”）。

缺点：属性定义复杂，规则逻辑易冗余（如大量属性组合导致规则数量爆炸），需依赖自动化工具（如规则引擎）管理。

场景：云环境、IoT 系统、零信任架构、跨组织协作（如供应链数据共享）。

案例：云平台权限管理（如阿里云 RAM 基于用户属性、资源属性动态授权）、IoT 设备控制（如 “仅允许家庭 WiFi 下的手机控制智能门锁”）；

> 基于策略的访问控制（Policy-Based Access Control, PBAC）

定义：将授权逻辑抽象为 “全局策略”，通过 “策略引擎” 解析策略并动态决策，可视为 ABAC 的 “策略化延伸”。

核心逻辑：

- 制定策略：采用标准化语言（如 XACML，可扩展访问控制标记语言）定义全局策略，例如「所有财务数据仅允许财务部门在工作日访问，且需 MFA 验证」；
- 策略引擎：接收访问请求（主体 + 资源 + 操作 + 环境），解析策略并判断是否允许；
- 动态执行：策略变更时（如 “财务数据访问时间调整为 8:00-17:00”），仅需修改全局策略，无需逐个调整资源权限。

优点：

- 集中管控：所有授权逻辑统一在策略中，便于合规审计；
- 可扩展性强：支持跨系统、跨平台的统一授权。

缺点：策略语言学习成本高（如 XACML 语法复杂），策略引擎性能要求高。

场景：大型企业、跨平台系统（如混合云）、高合规需求场景（如金融、医疗）。

案例：大型企业跨平台授权（如混合云环境下的统一权限策略）、金融行业合规授权（如符合《个人信息保护法》的客户数据访问控制）。

> 基于任务的访问控制（Task-Based Access Control, TBAC）

定义：围绕 “任务流程” 分配权限，仅在任务执行的 “特定阶段” 赋予用户必要权限，任务完成后权限自动回收，核心是 “按任务生命周期管控权限”。

核心逻辑：

1. 定义任务流程：拆分任务为多个阶段（如 “采购流程” 分为 “申请→审批→付款→归档”）；
2. 绑定阶段与权限：每个阶段仅赋予对应权限（如 “审批阶段” 仅允许审批人执行 “同意 / 拒绝” 操作，无 “付款” 权限）；
3. 权限动态回收：任务进入下一阶段或完成后，上一阶段的权限自动失效。

优点：

- 最小权限动态化：权限仅在任务需要时存在，降低滥用风险；
- 贴合业务流程：与企业实际业务深度结合；

缺点：依赖清晰的任务流程定义，对无固定流程的场景不适用。

场景：流程化业务（如财务审批、采购管理）、需要追溯任务责任的场景。

案例：企业审批系统（如财务报销审批流程）、工单系统（如 IT 运维工单的 “创建→处理→关闭” 阶段权限控制）；

## 授权框架

> OAuth 2.0：第三方应用的授权框架

定位：解决 “第三方应用如何在不获取用户账号密码的情况下，安全获取用户在某平台的资源权限”（核心是 “授权委托”，而非认证）。

角色：

- 资源所有者（User）：用户；
- 客户端（Client）：第三方应用（如知乎）；
- 授权服务器（Authorization Server）：资源平台的授权中心（如微信）；
- 资源服务器（Resource Server）：存储用户资源的服务器（如微信存储用户头像的服务器）。

授权模式：

- 授权码模式（Authorization Code Flow）：最安全，适合 Web 应用、移动 APP，流程见OIDC 部分；
- 密码模式（Resource Owner Password Flow）：用户直接向客户端提供账号密码，仅适合高度信任的客户端（如企业内部 APP）；
- 客户端模式（Client Credentials Flow）：无用户参与，客户端用自身凭证（Client ID/Secret）获取权限，适合后端服务间调用（如 API 接口授权）；
- 简化模式（Implicit Flow）：直接返回 Access Token，不经过授权码环节，适合纯前端应用（如 SPA），安全性较低；

核心凭证：

- Access Token（访问令牌）：用于访问资源服务器的临时凭证，有效期短（如 1 小时）；
- Refresh Token（刷新令牌）：用于 Access Token 过期后重新获取，有效期长（如 30 天），需安全存储（如服务器端）。

场景：第三方登录（如 “用 QQ 登录游戏”）、跨平台 API 授权（如 “抖音 APP 授权第三方工具管理作品”）。

> JWT（JSON Web Token）：轻量级权限 / 身份凭证

定位：紧凑的、自包含的令牌格式，用于在各方之间安全传递 “身份或权限信息”，常与 OAuth 2.0、OIDC 配合使用。

令牌结构（3 部分，用 “.” 分隔，Base64 编码）：

- Header（头部）：指定令牌类型（JWT）和签名算法（如`{"alg":"HS256","typ":"JWT"}`）；
- Payload（载荷）：存储核心信息，包括 “标准声明”（如`exp`表示过期时间、`iss`表示签发者）和 “自定义声明”（如`user_id: 123`、`role: dev`）；
- Signature（签名）：用 Header 指定的算法对 Header+Payload 签名（如 HS256 用密钥签名），确保令牌未被篡改；

优势：

- 自包含：令牌包含所有必要信息，服务器无需查询数据库即可验证权限，适合分布式系统；
- 轻量：JSON 格式比 XML 简洁，传输速度快。

注意事项：

- Payload 是 Base64 编码（不是加密），敏感信息（如密码）需避免存入，或使用 JWE（JSON Web Encryption）加密；
- 无状态：令牌一旦签发无法撤回，需通过缩短有效期、维护黑名单（如 Redis）应对令牌泄露。

场景：OIDC 的 ID Token、OAuth 2.0 的 Access Token、分布式系统中的权限传递（如微服务间通过 JWT 确认权限）。

> STS（Security Token Service，安全令牌服务）

定位：生成临时权限凭证的服务，核心是 “动态管理权限，降低长期凭证泄露风险”。

功能：

- 生成临时凭证：为主体生成短期有效的 Access Token、Secret Key，替代长期固定密钥；
- 权限精细化控制：通过 AssumeRole 接口临时获取特定角色的权限（如 “只读权限”）；
- 跨账户授权：支持不同云账户、不同身份系统间的权限委托。

场景：跨账户资源共享、第三方应用集成、临时特权访问（如运维人员临时执行高危操作）。

案例：AWS STS、阿里云 STS，如 “企业 A 授权企业 B 的员工通过 STS 临时访问其云存储”。

## 安全风险

| 安全挑战            | 核心风险                                                     | 应对措施                                                     |
| ------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| 权限冗余 / 过度授权 | 普通用户拥有高级权限（如开发人员有数据库删除权限）           | 1. 遵循最小权限原则；2. 定期权限审计（如每季度回收冗余权限）；3. 采用 ABAC 动态调整权限 |
| 权限蔓延            | 用户调岗后未回收旧角色权限（如员工从研发转行政后仍有代码库访问权） | 1. 人员变动触发权限自动调整（如 HR 系统与授权系统联动）；2. 定期用户权限复核 |
| 动态场景授权难      | 临时项目团队需跨部门访问资源，角色配置繁琐                   | 1. 采用 ABAC/PBAC 模型；2. 临时权限自动过期（如 24 小时后失效） |
| 权限决策不透明      | 无法追溯 “为何允许 / 拒绝某访问请求”，合规审计困难           | 1. 记录授权决策日志（含主体、资源、属性、规则）；2. 采用 PBAC 统一策略，便于审计 |

## 协同技术

> SSO（单点登录）：认证与授权的 “统一入口”

SSO 不仅是认证技术，更是**认证与授权的协同载体**。

认证层面：用户一次登录，多系统共享认证状态；

授权层面：SSO 认证通过后，向各系统传递用户身份和基础权限信息（如角色、部门），各系统基于该信息执行授权决策；

典型案例：企业员工通过 SSO 登录 OA 后，访问 CRM 时无需重新认证，CRM 基于 SSO 传递的 “销售角色” 授权用户访问客户数据。

> 零信任架构（Zero Trust Architecture, ZTA）：认证与授权的 “动态协同升级”

零信任架构的核心理念是 “永不信任，始终验证”，彻底重构了认证与授权的协同模式：

认证层面：从 “一次认证终身有效” 升级为 “持续认证”，实时验证用户行为、设备状态、环境属性（如 “用户从内网切换到公网时，触发 MFA 二次认证”）；

授权层面：从 “静态权限” 升级为 “动态授权”，基于实时认证结果调整权限（如 “用户设备存在恶意软件时，临时收回高敏感资源访问权”）；

协同逻辑：认证与授权 “持续联动”，每一次访问请求都需同时验证身份合法性和权限合法性，无 “永久信任” 状态。