服务器服务权限管理要求所有服务以专属低权限账号运行，禁止使用root；每个服务需绑定独立非登录用户，配置user/group、nonewprivileges等限制，并定期巡检与加固。
服务器系统服务的运行权限管理，本质是把“谁在跑、以谁的身份跑、能干啥”这三件事管清楚。默认情况下，很多服务（比如 Apache、Nginx、MySQL）会以 root 或高权限用户启动，一旦被攻破，攻击者就能直接获得系统控制权。标准化管理的目标就是：所有服务都用专属低权限账号运行，且该账号仅具备完成本职工作所需的最小能力。
明确服务运行身份原则
每个服务必须绑定一个独立、非登录、无 shell 的专用用户，不能共用 root 或普通运维账号。这个用户只负责运行对应服务进程，不参与交互、不拥有家目录、不分配密码。
- Nginx/Apache 应使用 www-data 或 nginx（非 root）
- 数据库（如 MySQL/MariaDB）应使用 mysql 用户
- Redis 默认用 redis 用户，若未启用则需手动创建并配置
- 自研服务必须新建专用用户，例如 appuser，并用
useradd -r -s /sbin/nologin appuser创建
检查并修正现有服务权限配置
先确认当前哪些服务还在用高危身份运行：
- 查所有服务的运行用户：
ps aux | awk '{print $1,$11}' | grep -E '(/usr|/opt|/var)' | sort -u - 重点检查 root 进程中是否包含业务服务二进制路径（如
/usr/bin/nginx） - 查看服务单元文件（systemd）：
systemctl show --property=User,Group nginx.service，确认 User= 字段不是 root - 对 Nginx，检查
/etc/nginx/nginx.conf中 user 指令是否已设为nginx;或www-data; - 对自定义服务，修改其 systemd unit 文件（如
/etc/systemd/system/myapp.service），在[Service]段添加：User=myapp<br>Group=myapp<br>NoNewPrivileges=true<br>RestrictSUIDSGID=true
限制服务账号能力边界
光换用户还不够，得防止它“越界”：
- 禁用服务账号的登录能力：
sudo usermod -s /sbin/nologin nginx - 禁止创建新特权进程：
NoNewPrivileges=true（写入 service 文件） - 关闭 SUID/SGID 权限继承：
RestrictSUIDSGID=true - 限制可访问路径：
ProtectHome=true（隐藏 /home）、ProtectSystem=full（挂载 /usr、/boot 只读） - 禁止网络外连（如日志上报类服务除外）：
PrivateNetwork=true（隔离网络命名空间）
定期验证与自动化巡检
权限配置容易被后续更新或手动操作覆盖，需固化检查机制：
- 每月执行一次扫描脚本，输出所有服务的 User/Group 设置及实际进程 UID/GID 是否一致
- 将关键检查项加入 CI/CD 流水线或 Ansible playbook，部署新服务时自动校验
- 在安全审计日志中记录每次服务 unit 文件变更，关联操作人与时间戳
- 配合 SELinux 或 AppArmor 策略，对服务进程做域隔离（如 nginx_t、mysqld_t），进一步约束文件和系统调用范围
