CentOS服务器上很多运维事故的根源不是外部攻击，而是内部权限失控。用root账号直接跑应用、执行脚本、挂载定时任务，一旦应用本身存在漏洞或被注入恶意代码，攻击者就能直接拿到整个服务器的控制权。把应用拆分成独立运行账号，让每个服务只拥有完成自身任务所需的最小权限，是目前成本最低、效果最直接的安全加固手段。
独立运行账号的核心逻辑很简单：一个应用一个账号，账号只对应用自己的目录、日志、临时文件和必要系统资源有读写执行权限，对其他应用目录、系统配置、用户数据一律隔离。这样即使某个Java应用被上传了webshell，攻击者也只能在这个账号的权限范围内活动，无法读取数据库配置文件、无法修改其他服务、无法安装系统级后门。
先判断哪些应用必须拆分账号不是所有进程都需要独立账号，但以下几类必须拆分：对外提供Web服务的中间件（Nginx、Apache、Tomcat）、运行用户上传内容的脚本语言环境（PHP、Python、Node.js）、数据库服务（MySQL、PostgreSQL、Redis）、消息队列（RabbitMQ、Kafka）以及所有自定义业务应用。这些服务直接面对外部输入或处理敏感数据，是攻击者最常利用的入口。
判断标准可以简化为：只要这个进程会解析外部输入、执行文件操作或监听网络端口，就不应该用root运行。CentOS默认安装的很多服务其实已经自动创建了专用账号，比如nginx会创建nginx用户，mysql会创建mysql用户，但很多运维在手动部署时图省事，直接用root启动，等于把这些默认的安全设计全部废弃了。
创建独立账号的具体操作以部署一个Python Web应用为例，先创建专用账号并锁定登录：
useradd -r -s /sbin/nologin -d /opt/myapp myapp
这里-r参数创建系统账号，不分配家目录下的常规用户环境；-s指定为nologin，禁止该账号通过SSH或控制台登录；-d指定应用根目录。如果应用需要写入日志，再单独创建日志目录并授权：
mkdir -p /var/log/myapp chown -R myapp:myapp /opt/myapp /var/log/myapp chmod 750 /opt/myapp chmod 750 /var/log/myapp
750权限意味着只有myapp用户和同组用户可以读写执行，其他用户完全无法访问。这比常见的755或777安全得多。如果应用还需要读取某些系统文件，比如时区信息、SSL证书，单独用setfacl授权即可，不要直接改目录属主。
systemd服务单元中的权限控制CentOS 7及以上版本用systemd管理服务，服务单元文件里可以精细控制运行账号和权限。一个标准的服务单元应该这样写：
[Unit] Description=My Python Web Application After=network.target [Service] Type=simple User=myapp Group=myapp WorkingDirectory=/opt/myapp ExecStart=/usr/bin/python3 /opt/myapp/app.py Restart=on-failure RestartSec=5 NoNewPrivileges=true PrivateTmp=true ProtectSystem=full ProtectHome=true ReadWritePaths=/var/log/myapp [Install] WantedBy=multi-user.target
User和Group指定运行账号，这是基础。NoNewPrivileges=true阻止进程通过setuid等方式提升权限，即使应用内部有漏洞也无法获取更高权限。PrivateTmp=true给进程分配独立的临时目录，防止通过/tmp目录进行攻击。ProtectSystem=full把整个文件系统设为只读，只有ReadWritePaths列出的目录可写，这样即使应用被攻破，也无法修改系统二进制文件或配置文件。ProtectHome=true则直接屏蔽对/home目录的访问，避免用户数据泄露。
这些参数组合起来的效果是：即使攻击者拿到了应用的shell，他能做的也极其有限——只能读写/var/log/myapp和/opt/myapp，无法安装工具、无法读取其他用户数据、无法修改系统配置。这种纵深防御比单纯改账号权限又进了一步。
定时任务和脚本的权限隔离很多运维习惯把备份脚本、清理脚本直接放在root的crontab里执行。这些脚本如果调用了某个有漏洞的应用或处理了不可信的文件，同样会以root权限运行。正确做法是为每类维护任务创建独立账号，或者至少用最小权限账号执行脚本。
比如备份任务只需要读取应用数据目录、写入备份目录，就创建一个backup账号，只对这两个目录有权限，然后在/etc/cron.d/下创建独立的任务文件：
30 2 * * * backup /usr/local/bin/backup_myapp.sh
脚本本身要检查权限，避免被篡改后以高权限执行。脚本文件属主设为root，权限设为755，其他用户只读不可写。如果脚本需要读取敏感配置，用setfacl单独授权，而不是把整个目录开放给backup账号。
数据库账号的权限最小化应用连接数据库的账号往往拥有过高权限。很多部署文档直接让应用使用root或拥有ALL PRIVILEGES的账号连接数据库，这是非常危险的做法。一旦应用存在SQL注入，攻击者就能通过数据库账号读写服务器文件、执行系统命令。
正确做法是为每个应用创建独立的数据库账号，只授予必要的库表权限。例如一个只需要读写业务库的应用：
CREATE USER 'myapp'@'127.0.0.1' IDENTIFIED BY 'strong_password'; GRANT SELECT, INSERT, UPDATE, DELETE ON myapp_db.* TO 'myapp'@'127.0.0.1'; FLUSH PRIVILEGES;
不要授予FILE、SUPER、PROCESS等管理权限，这些权限在MySQL中可以被用来读取服务器文件或查看其他用户进程。Redis同理，不要用root启动，设置requirepass，绑定内网地址，禁用危险命令。
文件权限的默认值与umask设置独立账号部署后，文件权限的默认值也要配合调整。很多应用在运行时创建的文件默认权限是644或755，这意味着同组或其他用户可以读取甚至写入。对于多应用共存的服务器，应该为每个应用账号设置严格的umask。
在systemd服务单元中可以设置UMask参数：
[Service] User=myapp Group=myapp UMask=027
027意味着新创建的文件默认权限是640（属主读写、同组读、其他无权限），目录是750。这样应用生成的日志、缓存、临时文件不会意外暴露给其他账号。对于需要共享文件给其他服务的场景，再单独用setfacl处理，不要依赖宽松的umask。
审计与监控独立账号的活动权限隔离不是设置完就结束了，还需要持续监控这些独立账号的行为。CentOS自带的auditd可以记录关键文件和系统调用的访问情况。建议对以下操作添加审计规则：
auditctl -w /etc/passwd -p wa -k identity_changes auditctl -w /etc/shadow -p wa -k identity_changes auditctl -w /opt/myapp -p wa -k myapp_changes
这样任何对密码文件、应用目录的写入操作都会被记录。配合日志分析，可以及时发现异常行为。同时定期检查系统中是否存在非预期的特权进程，比如用root运行的自定义脚本、异常的网络监听端口。
常见误区和注意事项拆分账号过程中有几个容易踩的坑。第一，不要为了省事给独立账号配置sudo权限，sudo本质上还是给了root权限，等于白拆。第二，不要把多个应用共用一个账号，这样应用之间无法隔离，一个应用被攻破会连累其他应用。第三，不要用777权限解决权限不足的问题，应该用setfacl精确授权。第四，修改账号权限后要彻底测试应用功能，有些应用在非root环境下会因为无法写入某些目录而异常，需要提前梳理清楚所有需要读写的路径。
另外，CentOS 7已经停止维护，很多生产环境正在迁移到Rocky Linux或AlmaLinux。这些系统与CentOS高度兼容，本文的所有操作在这些系统上同样适用。迁移过程中正好是重新梳理权限模型的好时机，不要直接把旧的root运行方式带过去。
独立运行账号配合systemd的权限限制参数，能把应用被攻破后的影响范围压缩到最小。这套方案不需要额外购买安全设备，也不需要复杂的配置，只需要在部署和运维流程中坚持执行。对于大多数CentOS服务器来说，这是性价比最高的安全加固手段之一。
