1. 权限验证概述
1.1 权限验证的定义
权限验证（Authorization）是系统安全的核心环节，它决定了“谁（Who）能对什么资源（What）执行什么操作（How）”。在业务接口层面，权限验证发生在身份认证（Authentication）之后，确保请求方拥有访问特定接口或数据的合法授权。
关键区分：认证（Authentication）验证“你是谁”，权限验证（Authorization）验证“你能做什么”。两者不可混淆。
1.2 为什么需要权限验证
在微服务架构和业务系统日益复杂的今天，缺乏权限验证将导致严重的安全风险与数据泄露。以下是核心原因：
- 数据隔离：防止用户越权访问其他用户或部门的敏感数据（如订单、财务记录）。
- 操作控制：限制非管理员执行删除、修改配置、提现等高风险操作。
- 合规审计：满足 GDPR、等保、SOX 等法规要求，记录谁在何时做了什么。
- 最小权限原则：只授予完成工作所需的最小权限，降低内部威胁和攻击面。
- 接口安全：防止未授权客户端调用后端 API，避免业务逻辑被滥用。
常见误区：很多团队只在前端做按钮级权限控制，后端接口不做校验。这是极其危险的——攻击者可以直接通过 curl 或 Postman 绕过前端直接调用接口。
1.3 常见权限模型对比
业界经过多年实践，形成了四种主流的权限模型。理解它们的差异是设计权限系统的第一步。
| 模型 | 全称 | 核心思想 | 适用场景 | 优缺点 |
|---|---|---|---|---|
| DAC | 自主访问控制 | 资源所有者自行决定谁可以访问 | 文件系统、个人文档共享 | 灵活但权限管理分散，易失控 |
| MAC | 强制访问控制 | 系统根据安全标签强制控制 | 军事、政府机密系统 | 安全性极高，但僵化、运维成本高 |
| RBAC | 基于角色的访问控制 | 权限授予角色，用户关联角色 | 企业管理系统、SaaS 平台 | 管理简单、扩展性好，业界最广泛 |
| ABAC | 基于属性的访问控制 | 根据用户、资源、环境属性动态计算 | 云原生、IoT、复杂策略场景 | 粒度最细、灵活，但实现复杂、性能开销大 |
1.4 四种模型关系与演进
下图展示了四种权限模型在灵活性与安全性之间的定位关系，以及从 DAC 到 ABAC 的演进路径。
1.5 模型选择建议
在实际业务中，没有银弹。以下是基于不同业务规模的选型参考：
- 小型系统 / 内部工具：DAC 或简单 RBAC 即可，快速交付。
- 企业级 SaaS / 后台管理：RBAC 是首选，配合角色继承和权限缓存。
- 金融 / 政务 / 高安全场景：MAC 或 RBAC + 强制安全标签。
- 云原生 / 多租户 / 动态策略：ABAC 或 RBAC + ABAC 混合（本课程重点）。
课程路线图：本章建立权限模型认知后，后续章节将深入 Go 语言中 RBAC 的实现、ABAC 策略引擎集成、中间件开发、性能优化与实战案例。
1.6 权限验证在 Go 接口中的位置
在典型的 Go Web 服务中，权限验证通常作为 HTTP 中间件（Middleware）存在，位于认证中间件之后、业务处理函数之前。下图展示了请求处理链路中权限验证的典型位置。
1.7 本章小结
- 权限验证是接口安全的核心防线，必须与认证区分。
- 四种主流模型各有优劣，RBAC 是业界最广泛的基础模型。
- 本课程将重点讲解 Go 语言中 RBAC 的实现，并引入 ABAC 作为扩展。
- 权限验证中间件位于认证之后、业务之前，是 Go Web 框架的标准架构。