服务器权限怎么设置

服务器权限设置的服务核心只有一句话：最小权限原则——给每个用户恰好够用的权限，多一分是器权风险，少一分是限设麻烦。

我见过太多服务器被黑，服务不是器权因为漏洞多高级，而是限设因为权限太宽松。去年帮一家电商公司排查故障，服务发现他们的器权数据库账号用的是root，密码还是限设“admin123”。运维说图省事，服务结果被扫号工具一天就破了。器权这不是限设技术问题，是服务懒。

权限设置分三层：系统层、器权应用层、限设数据层。

系统层管的是登录和命令。用Linux的话，别直接给root，用sudo授权。比如开发要重启服务，就只给systemctl restart nginx的权限，别给全部。改/etc/sudoers文件时小心点，语法错了会锁死所有sudo。我习惯先visudo -c检查，再保存。

应用层更细。Web服务器跑PHP还是Java，权限模型完全不同。Nginx的worker进程用www-data用户，那就别让它能写项目目录。上传目录单独开写权限，其他目录只读。这活儿烦，但必须做——我见过有团队把整个网站目录chmod 777，结果被上传了webshell，整站被删。

数据层最容易被忽视。数据库账号别用root，按业务拆。读写的账号、只读的账号、备份的账号分开建。MySQL里grant语句别偷懒，指定库表和IP来源。比如只允许应用服务器IP连接，其他IP一律拒绝。这样做的好处是，就算应用被拖库，攻击者也只能拿到那一个库的数据。

设置权限时有个坑：别用组权限代替个体授权。组权限看着方便，但人一多就乱。你给“开发组”全部写权限，那实习生也能改生产代码。正确做法是每个项目单独建组，人员变动时及时调整组成员。我见过因为组权限太宽，离职员工还能登录服务器的——人事忘了删账号，组权限还留着。

文件系统层面，ACL比传统权限好用。比如/tmp目录，系统默认sticky bit防删，但业务需要某个子目录让两个组共享写权限，ACL就能精确控制。setfacl -m u:zhangsan:rwx /path/to/dir，比改chmod省心多了。

权限设置不是一劳永逸的事。每季度做一次权限审计，用脚本扫一遍所有用户的家目录和sudo权限，把不活跃账号禁用。别嫌麻烦，你永远不知道哪个闲置账号被撞库了。

最后说个反直觉的事：权限设得太死也会出问题。之前有个客户把所有端口都封了，只留80和443，结果监控系统连不上，报警全失效。权限是平衡的艺术，不是越严越好。关键是知道谁需要什么，然后精确地给。

服务器权限这事儿，说白了就俩字：克制。克制给权限的冲动，克制图省事的念头。每次想“应该没事吧”的时候，想想那些被删库跑路的同行——他们当初也是这么想的。

很赞哦!（4）