服务器权限设置方法

上周帮一家创业公司排查故障，服务法他们的器权数据库被误删了整整三个月的用户订单。查来查去，限设问题出在一个实习生身上——他用root账号登录了生产环境，置方本想清理临时表，服务法结果一条模糊的器权DELETE语句把主表清空了。这事儿不能全怪实习生，限设真正的置方问题是他们的服务器权限设置形同虚设。

服务器权限的服务法核心就一句话：每个账号只给够用的权限，绝不多给一分。器权这跟发门禁卡一个道理，限设普通员工不该有CEO办公室的置方钥匙。

第一步：分清账号类型

先把服务器上的服务法账号分三类：管理员、运维、器权普通应用账号。限设管理员账号只在系统初始化、紧急修复时使用，平时锁起来。运维账号负责日常部署和日志查看，权限限定在特定目录和命令。应用账号则专门跑服务，比如Nginx、MySQL，它们只允许访问自己的数据目录和配置文件。

我见过太多公司所有员工共用同一个root密码，还贴在钉钉群里。这等于把家门钥匙复制了五十份，丢一份都不知道是谁拿的。

第二步：用sudo替代直接root登录

别让任何人直接SSH登录root。正确的做法是编辑/etc/sudoers文件，给特定用户授权特定命令。比如允许运维执行systemctl restart nginx，但不允许他们修改防火墙规则。

# 在sudoers中添加 ops_user ALL=(ALL) /usr/bin/systemctl restart nginx ops_user ALL=(ALL) /usr/bin/tail /var/log/nginx/error.log

这样即使账号被入侵，攻击者能做的也有限。前几天有个客户说他们被勒索病毒加密了网站目录，一查原因——所有服务器都用同一个密码直接root登录，病毒进来后畅通无阻。

第三步：文件系统权限要细化

Linux下用chmod和chown控制文件访问。但很多人只会用chmod 777，这等于把文件内容贴在大街上。正确做法是：目录用755，普通文件用644，可执行文件用750，配置文件中含密码的用600。

举个例子，你的.env文件里存着数据库密码，如果权限是644，意味着服务器上任何一个用户都能读它。改成600后，只有所有者能查看。就这一条，能堵住80%的配置泄露风险。

第四步：定期审查和回收权限

员工离职了，他的账号删了吗？外包人员项目结束，云服务器上的密钥换了吗？很多公司根本没有这个习惯。我建议每季度做一次权限审计，列出所有账号和它们的权限清单，挨个确认是否还需要。

有个细节容易被忽略——服务账号的shell。如果某个服务账号的shell是/bin/bash，意味着有人能通过它登录执行任意命令。应该改成/sbin/nologin，只让它跑服务，不提供交互式登录。

第五步：开启审计日志

权限设置得再好，也得有人盯着。开启auditd服务，记录谁在什么时候执行了什么命令。别小看这个，出事的时候它能帮你快速定位责任人，而不是像那家创业公司一样，查了两天才知道是实习生干的。

权限管理不是一锤子买卖。每次有新员工入职、新服务上线，都要重新审视一遍。你不需要一步到位搞出完美的权限体系，但至少从今天开始，把root密码换掉，把每个人手里的钥匙收一收。服务器安全这事，懒一天，风险就多一天。