1. 权限安全基础：权限模型与最小权限原则

权限安全，说白了就是回答三个问题：谁、能干什么、在什么条件下。我做了十几年安全架构，见过太多因为权限设计不合理导致的严重事故。今天咱们就从最基础的权限模型讲起。

1.1 权限的本质与边界

先聊聊权限的本质。我个人理解，权限就是主体对客体的操作许可。主体可以是人、服务、设备；客体是文件、数据库、API；操作就是读、写、执行、删除。

边界在哪？边界就是权限不能超越职责。你想想看，一个普通员工能看工资条，但不能改工资条；能提交报销，但不能审批自己的报销。这就是边界。

我在项目中遇到过一家金融公司，他们把管理员权限给了所有运维人员。结果一个实习生误操作，删了生产数据库的索引。嗯，这就是边界没划清楚。

1.2 四大经典权限模型

权限模型发展了几十年，主流的有四种。我按出现顺序给你捋一遍。

模型	全称	核心思想	适用场景
DAC	自主访问控制	资源所有者自己决定谁可以访问	个人文件、共享文档
MAC	强制访问控制	系统根据安全标签强制控制	军事、政府机密系统
RBAC	基于角色的访问控制	权限绑定到角色，用户通过角色获得权限	企业应用、ERP、CRM
ABAC	基于属性的访问控制	根据主体、客体、环境属性动态决策	微服务、云原生、IoT

DAC：自主访问控制

DAC 是最早的模型。文件的主人说了算，他想给谁读就给谁读。Linux 的文件权限就是典型例子。

# Linux 文件权限示例
-rw-r--r--  1 alice devteam  1024 Jan 15 10:00 report.pdf
# alice 可以读写，devteam 组员只能读，其他人只能读

但 DAC 有个大问题：权限传播不可控。A 把文件分享给 B，B 又分享给 C，最后谁有权限你根本不知道。我曾经帮一家律所做安全审计，发现一个机密合同被分享了七层，源头早查不到了。

MAC：强制访问控制

MAC 正好相反，权限不由用户决定，由系统强制。每个主体和客体都有安全标签，比如「绝密」「机密」「公开」。只有标签匹配才能访问。

我记得在给某政府部门做方案时，他们要求所有文档必须打标签，用户不能越级读，也不能越级写。这就是典型的 MAC 场景。

RBAC：基于角色的访问控制

RBAC 是目前企业用得最多的模型。它引入了「角色」这个中间层。权限不直接给用户，而是给角色，用户通过扮演角色获得权限。

# RBAC 权限分配示例
角色: 财务主管
  权限: 查看财务报表、审批报销单、导出账目

用户: 张三
  角色: 财务主管
  实际权限: 查看财务报表 + 审批报销单 + 导出账目

这样做的好处是管理方便。你想想看，公司有 1000 个员工，如果每个人单独配权限，配到猴年马月？但抽象成 10 个角色，管理成本直线下降。

不过 RBAC 也有坑。我在项目中遇到过一家公司，他们定义了 200 多个角色，比员工还多。这就失去了 RBAC 的意义。角色粒度要适中，我建议一个角色覆盖 10-50 个用户比较合理。

ABAC：基于属性的访问控制

ABAC 是更灵活的模型。它不看你是谁，而是看你有什么属性。属性包括：

• 主体属性：部门、职级、工龄、是否通过安全培训
• 客体属性：机密等级、所属项目、创建时间
• 环境属性：访问时间、IP 地址、设备类型、地理位置

举个例子：

# ABAC 策略示例（伪代码）
策略: 允许访问财务系统
条件:
  主体.部门 == "财务部" AND
  主体.职级 >= "高级" AND
  环境.时间 BETWEEN "09:00" AND "18:00" AND
  环境.IP 属于公司内网

ABAC 的威力在于动态决策。同样是财务部的人，高级员工白天在公司能访问，初级员工或者晚上从家里访问就被拒绝。这在 RBAC 里很难实现。

1.3 最小权限原则

最小权限原则，英文叫 Principle of Least Privilege，简称 PoLP。它的定义很简单：只给完成任务所需的最小权限，不多给一分。

听起来简单，做起来难。我见过太多反面案例：

• 给所有开发人员生产数据库的 root 权限
• 给实习生管理员账号「方便学习」
• 一个服务用超级管理员账号跑

我曾经帮一家电商公司做安全加固。他们有个订单处理服务，居然用 root 账号跑。我说为什么？答曰「省事」。结果这个服务被 SQL 注入，攻击者直接拿到了整个数据库。如果当时只给订单表的读写权限，损失会小得多。

实施最小权限，我总结了四个步骤：

1. 梳理权限清单：列出每个角色/服务需要访问哪些资源
2. 按需分配：只给必要的操作（读/写/执行），不给多余的
3. 定期审计：每季度检查一次权限，收回不再需要的
4. 动态调整：人员变动、职责变化时及时更新权限

1.4 权限模型选型对比

选哪个模型？我根据实际经验给你一个参考：

场景	推荐模型	理由
个人文件管理	DAC	简单直接，用户自己控制
高安全等级系统	MAC	强制策略，不可绕过
企业通用业务系统	RBAC	管理方便，成熟稳定
微服务/云原生	ABAC	动态决策，适应复杂环境
混合场景	RBAC + ABAC	角色做粗粒度，属性做细粒度

我个人习惯用 RBAC 做基础框架，然后在关键节点用 ABAC 做精细化控制。比如：角色决定「能不能访问财务模块」，属性决定「能不能在非工作时间访问」。这样既保证了管理效率，又兼顾了灵活性。

1.5 本章知识体系图

下面这张图把本章的核心知识点串起来了。你可以把它当作思维导图来用。

这张图把本章内容分成了四个板块。你可以看到，权限本质是基础，四大模型是工具，最小原则是底线，选型是实战。它们环环相扣，缺一不可。