## 适用场景
团队成员需要特定管理权限但不应拥有完整 root，例如值班同学只许重启 nginx，发布同学只许执行发布脚本。sudo 的授权文件支持到命令参数级别的控制，把这些零散需求收敛成白名单，是服务器权限治理的日常功课。顺云云服务器多人共管时，白名单比口头约定可靠得多。
## 步骤清单
先确定要放行的命令绝对路径，用 which 确认，授权匹配的是路径不是别名。然后编辑授权：永远用 visudo 编辑，它会做语法检查，防止一处笔误导致全体 sudo 失效。单条规则的写法是用户、主机、身份、命令四段，命令前加绝对路径。
deploy ALL=(root) NOPASSWD: /usr/local/bin/deploy.sh
ops ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx, \
/usr/bin/systemctl reload nginx
命令多的场景用别名分组，把角色与权限分离，可读性更好。改完保存时 visudo 自动检查语法，提示冲突或拼写问题时必须修正后再退出。
## 验证方法
授权用户执行 sudo -l 列出自己可用的命令，再实际执行一条验证生效。反向验证同样重要：尝试白名单外的命令应被拒绝并记录日志，日志默认落在 /var/log/secure 或 auth 相关文件里。
## 注意事项
放行脚本时要警惕脚本本身的写权限，用户能改脚本就等于拿到了任意 root，脚本属主必须是 root 且普通用户不可写。NOPASSWD 便于自动化但去掉了口令确认这道闸，只给最小命令集。通配符要克制，放行带星号的命令极易被构造出提权路径。
授权结构的进阶做法是角色化：把命令按职能分组定义为命令别名，再把用户归入组，授权规则只写组对命令别名的关系。人员流动时只需调整组成员，规则本身不动，几十人的团队也能维持清晰的权限地图。别名定义集中放在一个文件里，命名与职能对应，新规则的评审就有了统一入口。
审计这条线靠日志：sudo 的每次执行无论成败都记录执行者、目录与命令，集中转发到日志服务器后，定期抽样核对授权使用情况。某条规则的调用频率长期为零，说明授权过度可以收回；某条规则的失败尝试频繁出现，要么是命令路径变了，要么有人在试探边界，两种都需要跟进。