Cmnd_Alias实现运维角色精细化授权的核心是按职责归类命令、严格限定绝对路径与参数、绑定系统组而非个人，并通过主机/身份/命令三重约束达成最小权限。
用 Cmnd_Alias 实现运维角色精细化授权，核心是把命令按职责归类、路径参数写死、再绑定到角色组，而不是给个人开权限。它不是“多加几行就能用”，而是先想清楚“这个角色该做什么、不该做什么”，再用语法精准表达。
按业务职责定义命令别名
别名不是罗列命令，而是封装一类操作意图。比如“监控人员”只需查状态和日志，“部署人员”需重启服务但不能删配置，“DBA”能执行特定 SQL 但不能进交互式 shell。
- 监控组常用命令：Cmnd_Alias MONITOR_CMD = /bin/ps aux, /usr/bin/top, /bin/df -h, /usr/bin/journalctl -u nginx.service --since "24 hours ago"
- 部署组限定动作：Cmnd_Alias DEPLOY_CMD = /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx, /usr/bin/rsync --archive --delete /opt/app/ /var/www/html/
- DBA 安全操作：Cmnd_Alias DBA_CMD = /usr/bin/mysql -u appdb -h localhost appdb -e *, /usr/bin/mysqldump -u appdb -h localhost appdb
所有命令必须用绝对路径（用 which 或 command -v 确认），参数要显式写出或严格限定范围（如 -e * 可接受，* 单独跟在命令后不行）。
用系统组代替个人账号统一管理角色
不要写 alice ALL = (root) DEPLOY_CMD，而应复用 Linux 系统组，便于 OS 层统一增删成员。
- 直接授权组：%deploy ALL = (root) NOPASSWD: DEPLOY_CMD
- 或先建用户别名：User_Alias DEPLOY_TEAM = %deploy, jenkins
- 再绑定：DEPLOY_TEAM ALL = (root) NOPASSWD: DEPLOY_CMD, MONITOR_CMD
这样新增部署人员，只需 usermod -aG deploy username，无需改 sudoers 文件。
组合主机与执行身份进一步缩小权限边界
一条规则可同时约束目标主机、切换身份、命令集，三者叠加才叫“精细化”。
- 只允许在 Web 服务器上以 www-data 身份操作 Nginx：%webadmin web-servers = (www-data) NOPASSWD: DEPLOY_CMD
- 数据库维护只能在 DB 主机上以 postgres 用户运行：%dba db-servers = (postgres) NOPASSWD: DBA_CMD
- 禁止高危子命令：在别名中显式排除，如 !/usr/bin/systemctl stop mysql, !/bin/bash
注意：拒绝项（!）必须写在同一 Cmnd_Alias 内，且放在允许项之后才生效。
配置分离 + 语法校验 + 实际验证
别把所有内容堆在 /etc/sudoers 里。推荐拆到 /etc/sudoers.d/ 下独立文件，例如 /etc/sudoers.d/deploy-role：
- 文件名用小写+短横线，内容保持 Cmnd_Alias → User_Alias → 授权规则顺序
- 每次修改后必须运行 sudo visudo -c 校验语法，失败则不保存
- 切到目标用户执行 sudo -l -U username，确认列出的命令 exactly 符合预期
- 手动试一条授权命令（如 sudo systemctl restart nginx），再试一条未授权的（如 sudo reboot），确保被拒绝
安全不是靠“没出事”，而是靠“想清楚再写、写完必验证、改完即审计”。
