权限最小化

定义

权限最小化指在计算环境的某一抽象层次上，每个主体（可能是用户、进程或程序）只能取得与其正当目的相称的信息与资源，不应拥有更多。美国国家标准与技术研究院的术语表把它表述为：把用户（或代表用户行事的进程）的访问特权限制到完成所分配任务的最低必要程度^[1]。

它区别于单纯的身份认证与授权流程：前者解决“你是谁、能不能进”，权限最小化则管“进来之后能碰多少东西”，并且要求持续治理而非一次性开通^[1]。在中文技术文献中，这一原则常被称为最小授权原则或最小特权原则，用于描述同一类访问控制要求^[2]。

Saltzer 与 Schroeder 的原始表述是：系统中的每个程序和每个用户都应当以完成工作所需的最小权限集合来运行^[3]。这一表述针对的是权限集合而非权限类型，因此同一原则既能约束人的账号，也能约束软件模块^[4]。

原理

权限最小化的作用机制可以从两个量上理解：攻击面是未授权者可利用的全部入口之和，爆炸半径是一次失陷后能够波及的范围。削减每个主体的权限，等于同时压缩这两项数值^[5]。

以 Web 服务器为例，若进程以 root 权限运行，一旦被攻破便可改写整台机器上的任意文件；若改为只能读取站点目录的低权限账号，攻击得手后的影响就被约束在该目录内^[5]。这一差异可用下式粗略表达：潜在损失 ∝ 主体被授予的权限集合大小，而权限最小化试图让该集合恰好等于任务所需集合。

落实该原则依赖细粒度的访问控制模型。基于角色的访问控制把权限绑定到角色而非个人，人员岗位变动时可集中调整；基于属性的访问控制进一步引入时间、设备状态、数据敏感度等上下文；强制访问控制则设定用户无法自行逾越的边界^[1]。对管理员账号，常见做法是日常使用普通账号、仅在特定时间窗口临时提权，到期自动收回^[1]。

发展历程

这一思想在 1970 年代中期逐渐成形。Saltzer 与 Schroeder 在 1975 年讨论计算机系统信息保护的论文中把它列为保护机制的设计原则之一，该表述此后被反复引用，成为该原则的通行出处^[1]。也有资料提到，同期其他文献已经用不同名称表达过近似观点，Peter J. Denning 的《容错操作系统》常被视为概念的先声^[6]。

在操作系统层面，早期 Unix 只提供 root 与非 root 的二值选择，很难按需分配权限；后续版本与 Windows 逐步把 root 权限拆分为更细的子权限，使按需授权成为可能^[6]。Linux 上的 sudo 工具允许在配置文件中为特定角色开放 root 的部分能力，是管理员场景中的典型实现，但当服务器规模扩大后，分散在各主机上的独立配置难以保持一致^[7]。

进入云计算与零信任阶段后，该原则被写入规范文件。美国国家标准与技术研究院的 SP 800-53 以 AC-6 控制项把最小权限列为联邦信息系统的基线要求，并附加特权账号日志、定期权限复核等增强项^[1]。零信任概念由 Forrester 分析师 John Kindervag 于 2010 年提出，2020 年美国国家标准与技术研究院发布 SP 800-207 后成为通用框架，其中的访问决策在验证身份之后仍需按最小权限发放^[8]。

应用

操作系统是最早的落地场景。Unix 与 Linux 通过用户和组归属、文件权限位以及 SELinux、AppArmor 等框架实施限制；Windows 则以用户账户控制机制，在程序请求管理员权限时弹出提权确认，并用完整性级别约束低完整性进程对高完整性资源的操作^[1]。移动设备同样采用类似思路，应用在调用摄像头、麦克风等隐私相关部件前必须获得用户或管理员的授权^[9]。

在数据库和云环境中，原则体现为账号与策略的收窄。电商系统的商品目录服务只需要对商品表有读取权限，不应具备删除客户记录或修改财务数据的能力^[5]。云平台的身份与访问管理则要求为每个服务账号编写只覆盖实际调用范围的策略，例如图像缩放函数只应能读上传桶、写结果桶^[5]。

软件架构层面，微服务拆分使每个服务持有独立凭据和独立权限，邮件服务因此无须接触数据库或支付信息^[5]。设备制造领域也有对应要求：固件与网络控制软件不应默认带管理员权限，组件之间宜通过虚拟化或沙箱隔离，使攻破单个组件不足以掌控整机^[9]。

管理与合规侧，常见做法包括按角色申请账号、关键操作由多人批准、权限设置有效期、人员调岗或离职时立即调整或撤销权限、定期复核授权清单^[10]。审计时通常关注两类偏差：一是授予了但从未使用的权限，二是本可降级的权限，前者带来水平越权风险，后者带来垂直越权风险^[11]。

局限

“最小”本身难以精确计算。要确定一个程序真正需要哪些权限，需先明确它的任务规格并证明其实现符合规格，而对通用编程语言而言这一问题不可判定；对扩展程序的权限推断也因此只能给出近似结果^[12]。实践中可行的做法是人工判断并删除明显多余的权限，所得集合通常仍大于理论最小值^[13]。

权限粒度存在两难。过细的权限能精确贴合需求，但数量一多就难以管理和理解，管理员负担显著上升；过粗的权限则必然授予多余能力，一旦被误用或滥用，损失随之放大^[14]。角色模型虽能打包同类权限，但不同角色的人员仍可能持有远超实际需要的访问范围^[14]。

权限会随时间自然累积。授予权限有明确的需求驱动，撤销权限却缺少推动力：多余权限不影响工作，也很少有人主动清理，于是调岗、临时授权、系统默认配置等因素叠加，形成权限膨胀。服务账号、API 密钥等非人类身份往往在创建时被赋予宽泛范围，既无明确责任人，也无到期时间，容易长期游离于复核流程之外。

收回权限还可能带来运行风险。系统常在缺少内部访问限制的状态下成长，业务与工具均假设权限充足，事后收紧可能以难以预料的方式中断服务，因此改造往往遇到阻力^[14]。此外，权限最小化只约束主体能做什么，无法阻止攻击者向已失陷的进程注入代码并自行开启权限，它必须与隔离、监测等手段配合使用^[6][9]。

参见

• 访问控制 —— 权限最小化所依托的技术框架，决定主体能对客体执行哪些操作。

• 基于角色的访问控制 —— 把权限绑定到角色、再分配给人员的常见模型。

• 零信任架构 —— 以持续验证为前提的安全架构，最小权限是其核心组成之一。

• 攻击面 —— 权限最小化试图压缩的入口总量。

• 提权 —— 主体获取超出原有范围权限的过程，正是该原则要抑制的风险。

• 职责分离 —— 与最小权限并列的另一条访问控制设计原则。