Linux sudoers 怎么做最小授权：命令白名单、路径固定与审计验收

日常给部署、运维账号分配服务启停权限时，最容易走两个极端：要么直接给账号全开root权限，要么图省事写个带宽泛通配符的sudo规则。前者一出误操作直接扩大事故影响面，后者看似用着方便，实则没拦住参数拼接、路径跳转甚至环境变量劫持的绕过入口。想把sudoers权限控到最小，正确做法是把授权四要素「哪个用户、在哪台主机、以什么身份运行、允许执行哪条固定命令」全写死，最后再通过实际权限核验和日志审计闭环验收。

先定生产目标：只让部署账号完成一件事

假设账号 deployer 只需要重启 order-api.service，目标不是让它拥有“会管理服务”的能力，而是只允许一条可审计的操作。先确认命令的绝对路径：

command -v systemctl
readlink -f "$(command -v systemctl)"
systemctl cat order-api.service

不同发行版通常把 systemctl 放在固定系统目录，但不要把经验值直接写进规则。以机器上 readlink -f 的结果为准；服务名也要写成明确的 order-api.service，不要把整个 unit 管理权交给账号。

用 Cmnd_Alias 写出最小白名单

可以在 /etc/sudoers.d/order-api-deployer 中放一条独立规则：

Cmnd_Alias ORDER_API_SERVICE = /usr/bin/systemctl restart order-api.service
deployer ALL=(root) NOPASSWD: ORDER_API_SERVICE

这里有四个约束：主体是 deployer，主机范围是 ALL，目标用户只写 root，允许的命令是固定绝对路径和固定 unit 名。若只在某台机器使用，可以把第一个 ALL 换成主机名，减少配置误复制后的影响。

NOPASSWD 适合自动化重启场景，但不要把它误解为“任意 root 操作免密”。它仍然只对同一条命令生效。若不需要无交互运行，删掉这个标签，让系统按默认策略要求认证。

参数和路径边界：通配符为什么容易放大权限

sudoers 的命令匹配不是普通正则表达式。把命令写成 /usr/bin/systemctl *，实际上会把启动、停止、查看、编辑甚至其他 unit 操作一起放进授权范围；把参数写成宽泛的 *，也会让账号获得规则之外的操作空间。

更安全的策略是为每个动作拆一条别名，并且把unit名固定：

Cmnd_Alias ORDER_API_RESTART = /usr/bin/systemctl restart order-api.service
Cmnd_Alias ORDER_API_STATUS  = /usr/bin/systemctl status order-api.service
deployer ALL=(root) NOPASSWD: ORDER_API_RESTART, ORDER_API_STATUS

如果确实需要允许有限参数，先在测试机验证每一种参数组合，再把规则拆成几条可读的固定项。不要用“先放宽，后面再收紧”的方式上线，因为第一次授权就可能被脚本、环境变量或误操作留下不可见的依赖。

用 visudo 过语法关，再看真实权限清单

编辑sudoers文件前先用专用工具打开，避免语法错误把管理员锁在门外：

sudo visudo -f /etc/sudoers.d/order-api-deployer

保存后切换到目标账号核对规则。测试必须覆盖允许项和相邻的拒绝项：

sudo -u deployer -H sudo -l
sudo -u deployer -H sudo /usr/bin/systemctl status order-api.service
sudo -u deployer -H sudo /usr/bin/systemctl restart order-api.service
sudo -u deployer -H sudo /usr/bin/systemctl restart billing-api.service

最后一条应该失败。成功项的结果也不能只看返回码，还要确认服务状态、启动时间和新进程是否符合预期。若 sudo -l 显示的授权比文件里写的更宽，继续检查 /etc/sudoers 和其他 /etc/sudoers.d/ 文件，因为多条匹配规则会共同影响最终结果。

日志验收和回退：把权限变更留在可观察窗口

生产变更完成后，记录变更文件的校验值、测试时间、执行账号和服务结果。系统日志位置因发行版和日志服务不同而异，可以先从日志入口确认：

sudo journalctl --since "10 minutes ago" | grep -i sudo
sudo grep -i sudo /var/log/auth.log 2>/dev/null
sudo grep -i sudo /var/log/secure 2>/dev/null

如果出现未授权命令尝试，日志里至少要能定位用户、目标用户、命令和时间。没有审计记录时，不要把“命令成功”当作权限设计完成，先核对系统日志策略和sudo的事件记录配置。

回退也应当简单：先移走这一份独立规则或恢复上一份经过校验的文件，再次运行 visudo -c，然后用 sudo -l 确认权限已收回。不要直接清空整个主 sudoers 文件。

相关问题：最小授权里最容易踩的三个坑

为什么固定了 systemctl 还要固定 unit 名？

因为只限制程序路径而不限制参数，账号仍可能操作其他服务。命令和参数要一起收紧，尤其是重启、启停和配置查看这类动作。

NOPASSWD 能不能和通配符一起用？

语法上可以，但安全边界会变差。免认证只应绑定少量固定命令；如果必须允许参数，优先拆分规则并对每个组合做越权测试。

sudo -l 和 sudoers 文件显示不一致怎么办？

先看完整的包含文件和规则顺序，再确认账号所属组、主机名匹配和目标用户。sudo -l反映的是当前账号在当前主机上的最终可用清单，比只打开某一个文件更接近真实运行结果。

收尾检查：用四项结果决定是否发布

一份可交付的 sudoers 变更至少要留下四项结果：visudo 校验通过、目标账号的允许命令成功、相邻高风险命令失败、日志能回溯用户与命令。四项都满足后，再把规则纳入配置管理，并保留上一版文件的回退入口。这样权限收紧不是一次性手工改动，而是能被复查和撤回的生产配置。