服务器如何设置分权？不同角色权限怎么划分？

遵循最小权限原则，通过用户组、sudo白名单、文件ACL和角色权限隔离，把管理员、运维、开发、审计四类角色的操作边界彻底分开，谁也不能越过自己的权限范围。

很多服务器事故不是黑客攻进来的,而是权限太乱自己人搞坏的，运维误删目录、开发直连数据库改数据、测试拿root乱跑脚本这些问题的根源都是同一个：没有做分权设置，今天聊的是落地方法，不是纸上谈兵。

服务器权限怎么设置？先搞懂三个基础机制

设置分权之前,得明白Linux系统的权限底层逻辑，不理解这三个机制，后面所有操作都是在碰运气。

用户和用户组：一切权限的起点

每个有权限的实体都是用户（user），用户能归到某个组（group），文件或目录有三类身份：属主（owner）、属组（group）、其他人（others），分别对应读（r=4）、写（w=2）、执行（x=1）权限。

举个例子,-rw-r--r-- 表示属主可读写，属组和只读，这个基础决定了你能给某个用户单独开权限，还是给一批用户开组权限，实际场景中，不要直接为单个用户配权限，先建组再往组里加人，后期管理会轻松得多。

sudo授权：给普通用户开一扇安全的门

root权限不能随便给,但运维日常操作又需要部分管理能力，解决办法是sudo，通过编辑 /etc/sudoers 文件，你可以允许某个用户或组执行特定命令，而不用把root密码交出去。

比如允许运维组重启nginx,可以在sudoers里写：

%ops ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

关键点有两个：指定具体命令路径，避免通配符；慎用 ALL 参数，授权范围越窄，出事的面积越小。

ACL和RBAC：从“能做什么”到“按角色分配”

传统的用户/组/其他人权限模型粒度太粗，比如你想让开发小李只读 /var/log/app 目录，但不能看其他日志，传统权限做不到，这时需要ACL（访问控制列表），用 setfacl 命令给特定用户单独设置权限：

setfacl -m u:xiaoli:r /var/log/app

ACL解决的是“某个文件对某个用户开放到什么程度”，而RBAC（基于角色的访问控制）解决的是“某个角色应该有什么权限”，实际企业中，你不需要从零造RBAC系统，直接用Linux的用户组模拟角色，或者借助Ansible等自动化工具维护角色定义。权限模型越接近“按角色分配”，分权管理越清晰。

Linux服务器分权管理：不同角色权限怎么划分

这是最核心的问题,不同角色的职责边界，决定了你的权限设计方案，行业共识是至少拆出四类角色，而不是让所有人挤在一个管理员账号里。

超级管理员（root）只留一两个入口

root账号是服务器的“总钥匙”，必须严格控制，日常管理用普通账号登录，需要提权时再通过sudo临时获得权限，root密码最好由运维负责人保管，而且开启密钥登录，不使用密码登录，防止暴力破解。

一个团队里,root直接使用人数不应超过两人，其他人一律走sudo授权入口，如果服务器在云平台上，还可以借助云厂商的“子账号”功能，把控制台的权限和服务器内的root完全隔离。

运维工程师能做事，但不能越界

运维角色需要重启服务、查看系统状态、修改配置，但不需要永远拥有最高权限，合理的做法是给运维组分配sudo白名单，只允许执行明确列出的命令。

比如允许运维执行systemctl管理服务、tail查看日志、vim编辑指定配置文件：

%ops ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/tail, /usr/bin/vim

注意,vim这种命令风险不小，因为编辑任何文件都意味着可以改内容，更稳妥的方式是只允许sudo编辑 /etc/nginx/ 目录下的文件，而不是全局vim。

开发人员访问项目和日志，不能碰系统目录

开发需要的权限是：读取应用日志、部署代码、重启自己负责的服务，这些需求可以细化到目录层面，开发角色通常不需要 /etc 配置修改权，也不需要查看其他用户目录。

假设应用部署在 /srv/app，开发组可以这样设：

setfacl -R -m g:devs:rwx /srv/app
setfacl -R -m g:devs:r /var/log/app

同时sudo权限里给开发一条重启特定服务的命令：

%devs ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart app-service

这样开发既能干活,又无法影响系统安全。

只读审计角色只给查看，不给执行

有些场景需要第三方或者安全团队检查服务器状态,但不能让他们留下痕迹或改动东西，只读权限可以通过设置shell为 /bin/rbash（受限bash）或者配合sudo规则实现，更直接的方法是给该角色一个专属账号，加入一个只读组，并对所有关键目录设置只读ACL。

审计角色连sudo都不要给,他的需求就是看日志、看配置、看进程，一旦允许执行命令，哪怕只是 ls，也意味着有被利用的风险。

用具体命令落地：从创建用户到角色授权

理论讲完,直接上操作步骤，下面是一个新服务器从零做分权的标准流程。

创建用户组：

groupadd ops
groupadd devs

创建用户并指定主组：

useradd -g ops -m -s /bin/bash xiaoyun
useradd -g devs -m -s /bin/bash xiaokai

设置密码或密钥认证：

passwd xiaoyun

给用户加入sudo组外的定制白名单,编辑 /etc/sudoers.d/ops 文件，内容如下：

%ops ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/tail, /usr/bin/journalctl
%devs ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart app-service

给应用目录设置属组和ACL：

chown -R root:ops /srv/app
chmod -R 770 /srv/app
setfacl -R -m g:devs:rwx /srv/app
setfacl -R -m g:devs:r /var/log/app

最后一个关键步骤：禁用root远程登录，编辑 /etc/ssh/sshd_config：

PermitRootLogin no

然后重启sshd服务,做完这一步，所有管理员都必须通过普通用户+sudo提权来操作，服务器安全等级直接上一个台阶。

小团队和企业级的分权差异：到底选哪种方案

不同规模的团队,分权成本差异非常大，不要一上来就学大厂搞复杂的IAM系统，也别一台服务器就裸奔root。

小团队服务器分权管理方案

三五个人的团队,用用户组+sudo+ACL就够了，不需要额外软件，所有操作都在终端里完成，节省成本很重要，很多人买了一台优惠云服务器之后，觉得配置简单就不做权限分离，其实这些基础命令花不了10分钟。

小团队的分权重点是：每个人都用自己的账号登录，不要混用一个公共root，即使只有一个运维，也建议创建个人账号，再给自己配sudo，这样操作记录里有明确的责任人。

企业级分权方案

十几个或上百台服务器的企业,手工给每台机器配sudo不现实，企业级方案通常需要集中化管理：

• 用LDAP或FreeIPA统一身份认证,用户密码集中管理，不用每台机器单独设置。
• 配合Ansible批量下发sudo规则和ACL策略,确保所有服务器权限一致。
• 利用云平台的RAM或CAM服务,控制台操作和服务器内操作权限分离。

企业级的核心是“权限基线”，所有服务器使用同一套角色定义，新增员工自动获得对应权限，离职时一键禁用。

数据库服务器权限怎么设置？别让开发直连root

数据库是服务器上最敏感的部分,分权要求比系统权限更严格，很多公司直接把数据库的root或管理员账号发给开发和测试，这是极其危险的做法。

MySQL的例子很典型,创建应用账号时，限制来源IP和操作权限：

CREATE USER 'app_user'@'192.168.1.%' IDENTIFIED BY 'StrongPass';
GRANT SELECT, INSERT, UPDATE, DELETE ON appdb. TO 'app_user'@'192.168.1.%';

只读账号给SELECT权限：

CREATE USER 'readonly_user'@'%' IDENTIFIED BY 'ReadPass';
GRANT SELECT ON appdb. TO 'readonly_user'@'%';

同样,PostgreSQL和Redis也支持用户权限配置，行业共识认为：数据库账号必须做到最小权限，比如API服务只需要增删改查，就不给DDL（建表、删表）权限；报表工具只读即可，绝不能给写入权限。

数据库分权还有一个细节：通过跳板机（堡垒机）访问数据库，不要将数据库端口直接暴露在公网，这样即使账号泄露，攻击者也无法从外网直连数据库。

服务器分权后常见问题解答

权限设置完毕后，如何验证配置是否生效？

用新账号登录,尝试执行允许的和禁止的操作，比如sudo执行一个没授权的命令，系统会提示该用户在sudoers中未被允许，查看当前有效权限可以用 sudo -l 命令，它会列出你被授权的所有命令，检查ACL用getfacl，检查目录权限用ls -l。

配置sudo时不小心把用户锁在root之外了怎么办？

如果你当前还没有退出root登录,立刻编辑sudoers文件恢复，如果已经退出且普通用户无法提权，唯一的办法是重启服务器进入单用户模式（或者通过云厂商控制台重置密码）。每次修改sudoers之前，先执行 visudo -c 检查语法，这个习惯能避免绝大多数锁死事故。

如何让多个运维人员共管一台服务器又不互相干扰？

为每个运维创建独立的个人账号,统一加入ops组，通过sudo日志记录每个人的命令操作，在 /etc/sudoers 中开启日志：

Defaults logfile=/var/log/sudo.log

这样谁执行了什么命令一目了然,同时配合系统的auditd服务，可以追踪文件变更行为，分权的本质不是限制能力，而是让每次越权都有迹可循。

分权管理没什么神秘的,就是明确身份、限定范围、记录行为，从一台服务器的最小权限开始，逐步扩展成整个集群的自动化角色治理，这是每个运维团队都绕不过去的基本功，先把手上这台机器做好分权，再去考虑更复杂的方案。