权限最小化要求每个主体仅拥有必要权限，需创建专用低权限账户、精确sudo命令白名单、服务进程全程降权、自动化审计与监控。
权限最小化不是“少给点权限”，而是确保每个用户、服务或进程只能碰它真正需要的那几样东西——多一丁点都不行，少一点就跑不起来。这直接决定系统被攻破后的爆炸半径。
怎么创建一个真·低权限运维账户
别用 adduser 默认一路回车，那会给你一个带家目录、可登录、能执行任意命令的“准root”。要的是“只干一件事”的专用账户：
- 用
adduser --shell /usr/sbin/nologin --home /opt/backupuser backupuser创建无交互 Shell 的账户 - 立刻禁用密码登录：
passwd -l backupuser，只允许密钥认证（ssh-copy-id后检查~/.ssh/authorized_keys权限是否为 600） - 如果它只负责 rsync 备份，就在
/etc/sudoers.d/backupuser里写死命令白名单：backupuser ALL=(root) NOPASSWD: /usr/bin/rsync /var/www/* /backup/, /bin/tar -cf /backup/*.tar /var/log/nginx/ - 验证是否生效：
sudo -lU backupuser—— 输出必须只显示你明确授权的那两行，多一行都算配置失败
为什么 sudo 配置里不能写 ALL=(ALL) ALL
这是最常被抄进生产环境的“快捷键”，后果是：只要拿到这个账号的密码或密钥，等于直接拿到 root shell。攻击者不需要提权，已经站在顶点了。
- 真实风险案例：某次 Web 漏洞导致 PHP 进程被注入，攻击者通过
system("sudo cat /etc/shadow")直接拖库 - 正确做法是按动词（command）而非按角色（role）授权，比如运维查日志只需
/bin/journalctl -u nginx，而不是给整个journalctl - 务必启用
Defaults env_reset（默认已开），否则攻击者可通过SHELL=/bin/bash sudo -E bash绕过限制 - 敏感操作必须留痕：
Defaults logfile=/var/log/sudo.log，且该文件权限设为600，属主为root:root
服务进程还在以 root 跑？立刻降权
nginx、redis、mysql 这些服务默认可能用 root 启动再降权，但启动瞬间的 root 权限仍可能被利用（如 /proc/self/exe 替换）。真正的最小化是全程不碰 root。
- 查当前状态：
ps aux | grep -E "(nginx|redis|mysql)" | grep -v grep，看 USER 列是不是root - Nginx：在
nginx.conf顶部加user www-data;，并确保/var/log/nginx/和/var/www/所有权归www-data - Systemd 服务：编辑
/etc/systemd/system/mysqld.service，在[Service]下加User=mysql和Group=mysql，然后systemctl daemon-reload & systemctl restart mysqld - 验证降权效果：
sudo -u mysql ls /root应返回Permission denied，而不是静默成功
定期审计不是“看看就行”，得自动化抓异常
人工 ls -l /etc 或 getent group sudo 很容易漏掉新添的账号或悄悄变宽的权限。真正的最小化依赖持续校验。
- 每周自动扫描其他用户可写的系统配置：
find /etc -type f -perm -o+w 2>/dev/null，结果非空就必须处理 - 用 OpenSCAP 做基线比对：
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_stig --report report.html /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml - 关键文件变更监控不能只靠
auditd，还得配告警：auditctl -w /etc/passwd -p wa -k usermod，再配合ausearch -m USER_CHAUTHTOK -ts today抽查 - 最容易被忽略的一点：临时脚本或运维工具（如放在
/opt/bin/下的自定义备份脚本）往往权限设成 755，且属主是 root —— 它们一旦被篡改，就是完美的提权跳板
