服务器权限管理有哪些新手容易忽略的细节？

聊到服务器权限管理，很多人第一反应就是“root别乱给”、“密码设复杂点”。这些当然没错，但真到实操里，新手栽跟头的地方往往不在这些明面上，而是一些看起来不起眼、却后患无穷的细节。今天就当个旁观者，跟大家掰扯掰扯几个最容易踩的坑。

第一个容易被忽略的，是“权限分配过于粗犷”。不少新手接手服务器后，习惯性地把所有开发者、技术支持的账号一股脑塞进同一个用户组，或者直接给一堆人用同一个“root”级别的sudo权限。这个操作短期看方便，但一出事就是连锁反应。比如某个小项目临时工账号泄露，攻击者拿着它就能拿到服务器最高控制权，几乎所有数据都不设防。实际上，linux权限体系里还有个用户组权限（group）和ACL（访问控制列表）可以用，按需搞几层角色分组，日常运维、只读查日志、后台更新、数据库连接，各走各的权限通道，出了事才追得到源头。

另一个特别常见的细节是，sudo权限配置里“不加限制”。很多新手在sudoers里直接写一句 username ALL=(ALL) ALL，意味着这个用户做任何事情都不需要再确认。更稳妥的做法是限制执行命令的范围，比如只允许运行 systemctl、docker、chown 等几个固定命令，或者添加 NOPASSWD 参数来控制是否需要输密码。尤其对于账面上有几十、上百个账号的服务器，如果有人误操作运行了 rm -rf /，或者恶意脚本刷了一堆系统文件，再回头看日志就已经来不及了。一句话，sudo越细，翻车概率越低。

说到“权限回收”，这个坑更多是在管理流程上。很多团队早期给出去的API密钥、SSH密钥、redis密码、数据库连接信息，等到项目结束或人员离职了，根本没有系统抽象回收的机制。服务器上挂了十几年的老密钥，换了好几个项目都还在跑，风险比想象中的大得多。建议新手至少做到：每季度清理一次所有已知用户和密钥；离职或项目结束时第一时间把账号禁用或删除；部署时SSH密钥和密码分开管理，不搞“一把钥匙开所有锁”的套路。

还有一个非常具体但极度容易被忽视的点——文件权限。很多新手装完nginx、apache后，图省事把网站根目录以及所有文件设为777（所有人都可以读、写、执行），或者把.env、.config这些敏感配置文件的权限开得太宽。这事儿严重的后果就是，攻击者一旦上传一个小马，直接在web目录下写日志、窃数据库连接信息、拿系统shell，全链条崩了。最规范的配置是：web文件的目录权限设置在755或750（owner写，其他人只读），配置文件如wp-config.php则建议400甚至是600，owner只能web server用户，其他人压根碰不到。同时把上传目录单独拎出来，加上禁止脚本执行的规则。

最后是大家很容易忽略的“目录结构权限”。新手进服务器喜欢一股脑把所有内容塞在同一个目录下，比如 /var/www/html 直接挂载用户上传、缓存、日志、备份。出了事，攻击者顺着上传路径翻到备份文件，或者缓存目录写了个软链接，直接捅穿全局。分清路径责任：上传、日志、备份、配置，每个目录各走各的权限和owner。比如日志就只给日志的读写权限，备份目录额外加个挂载只读保护。这样哪怕哪个路径失守了，受威胁的区域也只限于那个范围的权限，服务器核心资产能保住。

聊这些细节，不是说非要一上来就搞多复杂。新手从最简单的事儿开始做起就行：把SSH的root登录权限收回来、给开发者开放专属子用户、把sudo范围缩到精准命令、文件权限不要超过755，尤其是敏感文件。慢慢来，最怕以为权限管理就是改个密码就完了。最后留两个问题给你自己想想：你线上服务器到底有多少现役用户和密钥？离职或者下线的项目人员权限真的清干净了吗？