“Least Privilege”——最小权限原则——属于少数几条没有人反对的安全原则之一。相应地，它被写进了很多地方：权限方案、角色描述、申请单和运维手册。只是，这些文档没有一份能决定一个账户实际上可以做什么。决定这一点的，是该账户所在系统的配置。本文说明两者为何会出现偏差、如何摸清实际状况，以及在纠正之前需要考虑什么。
标准有哪些要求
这项要求本身，在常见框架中的内容表述是一致的。NIST 在 SP 800-53 中将其描述为控制项 AC-6：只允许为完成所分配任务所必需的访问——明确地也包括代表用户行事的进程。自动化和服务账户因此并未被排除在外，而是同样包含在内。该控制项的增强项更为具体：特权账户应限于指定的人员或角色（AC-6(5)），已分配的权限应定期审查其必要性并在必要时收回（AC-6(7)），特权功能的执行应予以记录（AC-6(9)）。
BSI 在 IT 基本保护模块 ORP.4 中提出了同样的原则：账户标识和权限只能根据实际需要授予（ORP.4.A2）。值得注意的是要求 ORP.4.A3。它不仅要求记录账户标识和权限配置，还要求“定期检查”这份文档“是否反映了权限分配的实际状况”。
由此，检查的方向已经确定：从系统到文档，而不是反过来。一份没有人拿来与现实比对的文档，描述的只是一种意图。
模式：文档说 X，有效权限说 Y
这种偏差很少是疏忽的结果。它之所以产生，是因为权限同时在多个地方发挥作用——也因为一个名称或一段描述比一项有效权限更容易读懂。两个教科书式的例子可以让这一点变得具体。
假设一个用于数据备份的服务账户在权限方案中被描述为“只读”。在目录服务中，它是某个组的成员，而这个组本身又是一个管理组的成员。每一项成员关系单独看都合情合理。但加在一起，这个账户能做的远不止读取——而只看直接组成员关系的人，是看不到这一点的。
假设某个平台中的一个角色名为“查看者”，但除读取权限外，它还包含更改角色分配的权限。名称选得没错，角色却错了。依赖名称来分配这个角色的人，实际上授予了对方给自己增加更多权限的能力。
在这两种情况下，适用的是同一个原则：一项限制只有在目标系统对其进行检查的地方才算得到执行。写在方案里、名称里或某个调用工具里的东西，是一种描述，而不是一项控制。
询问系统，而不是询问文档
实际权限通常可以直接向系统查询：
- 在使用 sudo 的 Linux 上： 根据手册，
sudo -n -l会列出调用用户在当前主机上的权限。选项-n会阻止任何密码提示——如果需要输入，sudo 会报错中止，而不是等待。这使得该调用适用于自动化检查。附加一个命令时，sudo 会有针对性地回答恰好这一调用是否被允许，而不会执行它。 - 在目录服务中： 查看一个账户对某个对象的有效权限，包括嵌套组和继承的权限——而不是它理应所属的组的列表。
- 在云服务和平台服务中： 查看针对某一具体操作评估后的策略，而不是角色名称。
没有反向探测，检查就什么也证明不了
一项只确认允许情形的检查，带有一个内在的弱点。“这个账户能做它被允许做的事吗？”这个问题，一个拥有完全访问权限的账户同样会回答“是”。因此，这一结果无法区分一个被干净地加以限制的账户和一个不受限制的账户。
真正有说服力的是反向核验：一个必须被拒绝的请求。 假设某个账户应当只能重启某一个特定服务。那么检查中就应当包括这样的问题：它能编辑权限配置吗？能创建账户吗？能启动一个具有提升权限的任意 Shell 吗？借助 sudo -n -l <befehl>，可以在不执行任何操作的情况下提出这类问题；在目录服务和平台中，有效权限的评估功能可以做到同样的事。不过，sudo -n -l /bin/sh 返回“否”并不能排除 root Shell：带有 Shell 逃逸能力的被允许程序——例如 find、vim 或 less——或者被允许参数中的通配符，都会打开同一条路径。只要其中任何一个问题得到“是”，描述就是错误的——无论正向检查的结果如何。
有两个细节能让反向探测站得住脚。第一：要评估回答本身，而不仅仅是看有没有出现“是”。否则，一次因网络错误或意外的密码提示而根本没有完成的调用，看起来就像一次拒绝。第二：反向探测应纳入 AC-6(7) 和 ORP.4.A3 所要求的定期审查，而不只是在验收时进行。权限会因配置管理、更新和紧急干预而发生变化。
收紧之前，先保住修复路径
发现一项授予得过宽的权限的人，会想把它关掉。这里有一条在规划中很容易缺失的原则：一项限制不得移除通往其自身纠正的唯一路径。 如果被限制的账户同时也是唯一有权更改权限配置的账户，那么新规则中的错误此后就只能通过控制台访问、恢复或重建来修复。
由此得出的是一个顺序，而不是一种放宽。在收回一项权限之前，要先弄清楚哪条路径可以把它重新授予回来，以及这条路径能否在限制之后依然存在。在第一个管理身份被限制之前，应当已经存在一个拥有独立访问途径、且经过验证的第二个独立管理身份。BSI 在 ORP.4.A20 中针对应急预案提出了一个相关的思路：采取预防措施，以便在权限管理本身不可用时仍能保持工作能力。
影响广泛的自动化账户属于 Tier 0
用于推送、配置或自动化的账户，常常被视为运维工具。一旦它们在许多系统上拥有广泛的管理权限，它们就不止于此了：控制了它们的人，也就控制了这些系统。
Microsoft 在 Enterprise Access Model 中描述，以前的 Tier 0 层级已扩展为“Control Plane”（控制平面），并要求贯彻这一层级结构，使较低层级无法控制较高层级。其中明确包括持续查找可能导致非预期权限提升的配置弱点。对于拥有广泛权限的账户标识，BSI 建议采用多因素身份认证（ORP.4.A10）。
您应当检查什么
- 摸清有效权限——针对每一个服务账户和自动化账户，在系统上进行。
- 为每一项正向检查确定一项反向探测，且该探测必须被拒绝。
- 把限制落实在执行它们的地方。
- 在每一次收紧之前，建立并验证修复路径。
- 像对待 Tier 0 一样对待影响广泛的自动化账户： 多因素保护、日志记录、指定的责任人。
sector7 如何提供支持
我们在角色与权限方案、特权账户管理、多因素身份验证以及操作系统加固方面为您提供支持——包括策略、文档和审计。详情请见网络安全。
来源
- ORP.4 Identitäts- und Berechtigungsmanagement (Edition 2023) – BSI，IT-Grundschutz-Kompendium Edition 2023
- NIST SP 800-53 Rev. 5, OSCAL 格式目录（控制项 AC-6 及其增强项） – NIST，Release 5.2.0，截至 2026-05-11
- Securing privileged access – Enterprise access model – Microsoft Learn，2026-05-06
- Sudo Manual – sudo 项目
- Sudoers Manual – sudo 项目（章节“Preventing shell escapes”“Wildcards in command arguments”）