最小权限管理需分层落实：创建独立UID/GID隔离角色，禁用非交互账户登录shell，文件权限“窄而准”（如私钥600、配置目录750），服务进程降权运行并锁死能力边界，sudo严格白名单控制且全程日志审计。
服务器最小权限管理不是靠一套命令搞定的事，而是把Linux权限模型的每一层都用到位，让内部人员或被入侵的进程既“进得来”，又“干不了坏事”。核心思路就一条：让每个操作主体——用户、服务、脚本——只拥有刚好够用的身份和能力，多一分权限，就多一分篡改风险。
用好UID/GID隔离不同角色
Linux一切权限始于身份。不能让运维、开发、数据库管理员共用一个账号，更不能让服务进程和人用同一个UID。
- 为每类职责创建独立系统用户，比如
deploy（只负责代码发布）、backup（只运行备份脚本）、nginx（只读网站文件+写日志） - 禁用所有非交互账户的登录shell，统一设为
/usr/sbin/nologin，避免被当作跳板 - 用
chown和chgrp明确归属：配置文件属root:appadmin，日志目录属appuser:applog，上传目录属www-data:upload
文件权限要“窄而准”，不靠运气防误删
很多人以为chmod 644很安全，其实对敏感文件来说，它等于向整个组开放了读取权。真正的窄权限是“谁真需要读，才给谁读”。
- 私钥、数据库连接串、API密钥等必须
600（仅属主可读写），且不能放在Web可访问路径下 - 服务配置目录如
/etc/myapp/设为750，属主root，属组appadmin，其他用户完全不可见 - 绝对禁用
o+w（其他用户可写）。用find / -type d -perm /o+w 2>/dev/null定期扫描并修复
服务进程必须降权运行，且锁死能力边界
一个Web服务启动时需要绑定80端口，但之后全程不需要root权限。让它一直以root跑，等于给攻击者留了一扇开着的门。
- 在systemd服务单元中强制指定
User=appuser和Group=appgroup - 启用
NoNewPrivileges=yes，阻止进程通过execve()等方式重新获取特权 - 用
ProtectSystem=strict和ProtectHome=read-only禁止修改/etc、/usr和家目录 - 若需监听1024以下端口，改用
setcap 'cap_net_bind_service+ep' /path/to/binary，而不是用root跑
sudo不是放行单，是精确的权限开关
允许用户执行sudo systemctl restart nginx没问题，但绝不能让他执行sudo bash或sudo cp /etc/shadow .。
- 用
visudo按组配置，例如%webops ALL=(www-data) NOPASSWD: /bin/systemctl restart nginx - 禁用
sudo su -和sudo -i，防止绕过命令白名单 - 开启
Defaults logfile="/var/log/sudo.log"，所有提权操作必须留痕 - 配合
auditd监控execve系统调用，发现异常命令链（如curl | bash）立即告警
