类别: 原则
类型: 安全与系统设计原则
来源: 计算机安全与操作系统研究，1970 年代由 Saltzer 与 Schroeder 系统提出
别名: PoLP、最小必要访问
类型: 安全与系统设计原则
来源: 计算机安全与操作系统研究，1970 年代由 Saltzer 与 Schroeder 系统提出
别名: PoLP、最小必要访问
快速回答 — 最小权限原则（Principle of Least Privilege）强调：用户、服务和进程只应获得完成当前任务所需的最小权限，不多给、不长期给。这样可以显著降低入侵扩散、误操作破坏和权限滥用带来的系统性风险。
什么是最小权限原则？
最小权限原则（Principle of Least Privilege）是一条访问控制规则：任何主体的权限都应被限制在“完成合法任务所需的最小集合”。系统更安全的关键，不是“没人出错”，而是“即使出错也伤害可控”。最小权限同时防两类风险：一类是攻击者拿到账号后横向扩张，另一类是正常人员在高权限环境下发生误操作。实践中，它常与关注点分离、快速失败原则、可逆性原则一起构建高可靠操作体系。
最小权限原则的三层理解
- 入门：只给完成当下工作真正需要的权限。
- 实践：建立基于角色的授权、审批流程和周期性权限复核。
- 进阶：使用临时凭证、细粒度策略引擎和持续权限监测机制。
起源
最小权限原则在 1970 年代经典安全设计研究中被明确提出，核心思想是通过收缩权限边界来缩小攻击面并限制失效传播范围。 随着企业系统从单机走向分布式与云原生，该原则从“账号权限配置”演进为“身份治理 + 策略执行 + 生命周期管理”的系统工程。NIST 等安全框架长期将“最小必要访问”视为基础控制目标。 它的长期价值在于架构层：权限边界如何设计，决定了组织在错误、内部风险和外部攻击下的韧性上限。核心要点
最小权限不是一次性清理，而是持续运营机制。应用场景
最小权限适用于技术系统，也适用于跨部门业务流程。云基础设施权限
用资源级策略替代通配符授权，让服务只访问其职责范围内资源。
数据平台治理
依据数据敏感等级授予读写权限，对导出和跨域同步设置额外限制。
内部管理后台
将日常支持操作与不可逆操作分离，关键变更需要额外确认。
个人与团队操作习惯
区分日常账号与管理员账号，减少“高权限日常化”导致的误伤。
经典案例
2013 年 Target 数据泄露事件后，多个公开安全复盘都指出：攻击者在获取第三方凭证后能够横向移动，与过宽权限和分段不足密切相关。该事件成为企业权限治理的里程碑案例。 可核查指标是损失规模：公开财报与媒体报道显示，其后续处置、法律与运营相关成本累计达到数亿美元量级。最小权限并不能单独阻止所有入侵，但它能显著压缩“被攻破后的扩散半径”，降低系统级损害。边界与失效场景
最小权限若执行不当，会从“安全机制”变成“流程负担”。- 过度收紧导致停摆：没有快速例外通道时，合法业务会被频繁阻断。
- 绕过治理形成影子通道：审批过慢会促使团队私下共享账号或凭证。
- 静态角色失真：组织变化快时，固定角色模型容易积累隐性过授。
常见误区
很多团队把最小权限误解为合规清单动作。误区：最小权限一定会拖慢效率
误区：最小权限一定会拖慢效率
纠正：低质量流程会拖慢效率；设计良好的临时授权机制通常能兼顾效率与安全。
误区：它只是 IT 部门的事
误区：它只是 IT 部门的事
纠正：财务、运营、HR、供应商协作都涉及权限风险，同样需要最小授权。
误区：做了 RBAC 就足够
误区：做了 RBAC 就足够
纠正：RBAC 只是基础，还需要权限生命周期复核、上下文策略和快速回收机制。
相关概念
最小权限与以下原则协同时，安全与可运维性更平衡。关注点分离
先划清职责边界，再分配权限，能减少权限重叠与灰区。
快速失败原则
早期暴露权限配置错误，避免风险在系统中长期潜伏。
可逆性原则
关键操作可回滚时，即使权限失误也能快速止损。