运维实战之3分钟搭建“银行级”用户权限体系，新手也能一次搞定！

📌 前面：为什么你的服务器总像“菜市场”？

刚接手一台服务器，你是不是经常遇到这种场景：

开发说“我要看日志”，你直接给了他 root 密码；

DBA 说“我要重启 MySQL”，你大手一挥给了 sudo ALL；

运维同事重启 Nginx 时，不小心敲成了 reboot……

结果就是：权限失控 ≈ 服务器裸奔。

今天就带大家用一个真实后台管理系统的需求，手把手搭建一套标准化、可追溯、易扩展的用户权限体系。全程只需要 10 条命令，但背后的设计思想，足够你用上 3 年。

🎯 场景还原：

一个后台管理系统需要什么样的“安保”？假设我们有一套名为 “若依” 的后台管理系统，有三类角色：

核心思想就一句话

| 基于组授权，而不是基于人——以后新人来了，直接加入组，权限自动到位。

🧱 第 0 步：

1.准备工作（强烈建议）为了避免和之前的实验“打架”，建议用一台快照恢复过的干净虚拟机（Rocky Linux 10 / Ubuntu 22.04 均可）。

2. 如果你用的是 Ubuntu，注意命令和 Rocky 有一点点区别，我会特别标注。

🔧 第 1 步：创建三个"部门"——用户组

在 Linux 系统中，用户组（Group）就像是公司的"部门"，它是权限管理的基础单元。通过将用户分配到不同的组，我们可以实现批量权限管理，而不是为每个用户单独设置权限。

为什么需要用户组？

想象一下，如果你的公司有 100 个开发人员，每个开发人员都需要访问相同的代码仓库和日志目录。如果没有用户组，你需要为这 100 个用户分别设置相同的目录权限。而有了用户组，你只需要：

这样，权限管理就变得简单高效。当有新员工加入时，只需将其加入对应的组，权限自动生效；当员工离职时，只需将其从组中移除，权限自动收回。

创建三个核心用户组

根据我们的场景需求，我们需要创建三个用户组，分别对应三个不同的角色：

# 创建运维组
groupadd devops
创建数据库管理员组
groupadd dba
创建开发组
groupadd developer

这三个组分别代表：

• devops：运维团队，负责服务器维护、服务部署和监控
• dba：数据库管理员团队，负责数据库管理和维护
• developer：开发团队，负责应用开发和维护

验证用户组创建

创建完成后，我们可以验证一下组是否成功创建：

# 查看最后创建的三个组
tail -3 /etc/group

如果一切正常，你会看到类似这样的输出：

devops:x:1001:
dba:x:1002:
developer:x:1003:

这里的数字（1001、1002、1003）是组的 GID（Group ID），系统会自动分配。每个组的格式是：

组名:密码占位符:GID:组成员列表

用户组管理常用命令

除了创建组，你还需要掌握以下常用命令：

用户组文件详解

Linux 中的用户组信息主要存储在以下两个文件中：

让我们看看 /etc/group 文件的具体格式：

# 查看 devops 组的详细信息
getent group devops

输出格式为：组名:密码:GID:成员列表

• 组名：组的名称
• 密码：通常为"x"或"!"，表示密码存储在 /etc/gshadow 中
• GID：组的唯一标识符
• 成员列表：属于该组的用户列表，用逗号分隔

👤 第 2 步：招人！创建用户并"分部门"

用户组就像公司的"部门"，现在部门建好了，该"招人"了。我们将为每个角色创建对应的用户账户，并将他们分配到正确的"部门"（用户组）。

创建用户并分配到组

使用 useradd 命令创建用户，并通过 -g 参数指定主组，-G 参数指定附加组：

# 创建运维用户，主组为 devops
sudo useradd -m -s /bin/bash -g devops -G devops ruoyi-admin
创建 DBA 用户，主组为 dba
sudo useradd -m -s /bin/bash -g dba -G dba ruoyi-dba
创建开发用户，主组为 developer
sudo useradd -m -s /bin/bash -g developer -G developer ruoyi-dev

参数说明：

• -m：创建用户主目录（/home/用户名）
• -s /bin/bash：指定用户的默认 shell 为 bash
• -g devops：指定用户的主组（primary group）
• -G devops：指定用户的附加组（supplementary groups）

为用户设置初始密码

创建用户后，需要为他们设置密码：

# 为运维用户设置密码
sudo passwd ruoyi-admin
为 DBA 用户设置密码
sudo passwd ruoyi-dba
为开发用户设置密码
sudo passwd ruoyi-dev

系统会提示你输入并确认密码。建议使用强密码，或者使用 echo "密码" | passwd –stdin 用户名 进行批量设置（生产环境慎用）。

验证用户创建和分组

创建完成后，验证用户信息和所属组：

# 查看用户基本信息
id ruoyi-admin
id ruoyi-dba
id ruoyi-dev
查看用户所属的所有组
groups ruoyi-admin
groups ruoyi-dba
groups ruoyi-dev
查看 /etc/passwd 中的用户记录
grep -E "ruoyi-admin|ruoyi-dba|ruoyi-dev" /etc/passwd

正常输出应该类似：

# id ruoyi-admin
uid=1001(ruoyi-admin) gid=1001(devops) groups=1001(devops)
grep 输出示例
ruoyi-admin:x:1001:1001::/home/ruoyi-admin:/bin/bash
ruoyi-dba:x:1002:1002::/home/ruoyi-dba:/bin/bash
ruoyi-dev:x:1003:1003::/home/ruoyi-dev:/bin/bash

用户管理常用命令

关键配置文件

现在，我们的三个"员工"已经招聘到位，并分配到了正确的"部门"。下一步，我们将为他们配置具体的"工作权限"——精细化的sudo命令控制。

🔑 第 3 步：发"门禁卡"——设置统一初始密码

用户创建完成后，下一步就是为他们设置统一的初始密码，就像发放"门禁卡"一样。这一步看似简单，但却是安全管理的第一个实际接触点。

为什么需要统一初始密码？

在企业环境中，为新用户设置统一的初始密码有几个重要原因：

设置密码的两种方法

在 Linux 中，设置用户密码主要有两种方式：

方法一：交互式设置（推荐）

# 为运维用户设置密码
sudo passwd ruoyi-admin
为 DBA 用户设置密码
sudo passwd ruoyi-dba
为开发用户设置密码
sudo passwd ruoyi-dev

执行命令后，系统会提示你输入并确认密码。这种方式最安全，因为密码不会出现在命令行历史中。

方法二：非交互式设置（批量操作）

# 使用 chpasswd 命令批量设置密码
echo "ruoyi-admin:YANGge123" | sudo chpasswd
echo "ruoyi-dba:YANGge123" | sudo chpasswd
echo "ruoyi-dev:YANGge123" | sudo chpasswd

或者使用 passwd 的 –stdin 选项：

echo "YANGge123" | sudo passwd –stdin ruoyi-admin
echo "YANGge123" | sudo passwd –stdin ruoyi-dba
echo "YANGge123" | sudo passwd –stdin ruoyi-dev

⚠️ 重要安全提示：非交互式设置会将密码明文显示在命令行历史中，生产环境慎用！如果必须使用，请确保：

密码策略最佳实践

为了确保密码安全，建议实施以下策略：

🛡️ 第 4 步：上"紧箍咒"——精细化 sudo 权限（核心中的核心！）

前面的用户、用户组、密码都是"基础设施"，真正让权限体系"活"起来的，是 sudo 精细化配置。这一步如果做错了，前面全白费；这一步做好了，你的服务器安全等级直接提升一个量级。

为什么 sudo 权限需要"精细化"？

很多人图省事，直接给用户加一行 username ALL=(ALL) ALL，这意味着这个用户可以执行任何命令，本质上等于给了 root 权限。一旦这个用户的密码泄露，攻击者就能为所欲为。

精细化 sudo 的核心原则是：只给用户完成工作所需的最少命令，多一个都不给。这就是信息安全里的"最小权限原则"（Principle of Least Privilege）。

sudoers 配置的黄金法则

在动手之前，记住三条铁律：

第一步：编写 sudoers 配置文件

创建独立配置文件 /etc/sudoers.d/ruoyi：

在打开的文件中写入以下内容：

%devops ALL=(ALL) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx
%dba ALL=(ALL) /usr/bin/systemctl start mysql, /usr/bin/systemctl stop mysql, /usr/bin/systemctl status mysql
%developer ALL=(ALL) /usr/bin/tail -f /var/log/ruoyi/*, /usr/bin/cat /var/log/ruoyi/*
​

配置解读：

• %devops：百分号表示这是一个用户组，不是单个用户
• ALL=(ALL)：可以在任何主机上以任何用户身份执行（这是标准写法）
• NOPASSWD:：执行这些命令时不需要输入密码，适合自动化脚本场景。如果你希望每次执行都要输入密码（更安全），去掉 NOPASSWD: 即可
• NGINX_CMDS：只能执行这个别名里定义的命令，多一个都不行

✅ 验收入：怎么知道我们做对了？

1.保存退出后，立刻检查语法是否正确：

# 检查 sudoers 配置语法
sudo visudo -c

如果输出 /etc/sudoers: parsed OK，说明语法没问题。如果报错，立即用 visudo 修复，千万不要退出当前终端——一旦语法错误且退出了 root shell，你可能再也 sudo 不回去了。

2.逐用户验证权限

分别切换到三个用户，测试他们的 sudo 权限边界：

# === 测试运维用户 ruoyi-admin ===
# 切换到运维用户
su – ruoyi-admin
✅ 这些应该成功
sudo systemctl status nginx # 查看 Nginx 状态，OK
sudo systemctl restart nginx # 重启 Nginx，OK
sudo nginx -t # 测试 Nginx 配置，OK
❌ 这些应该被拒绝
sudo systemctl status mysql # 想偷看 MySQL？拒绝！
sudo cat /etc/shadow # 想看密码文件？门都没有！
sudo reboot # 想重启服务器？做梦！
退出
exit
=== 测试 DBA 用户 ruoyi-dba ===
su – ruoyi-dba
✅ 这些应该成功
sudo systemctl status mysql
sudo systemctl restart mysql
❌ 这些应该被拒绝
sudo systemctl status nginx # 想动 Nginx？越界了
sudo reboot
exit
=== 测试开发用户 ruoyi-dev ===
su – ruoyi-dev
✅ 这些应该成功（假设 /var/log/app/ 下有日志文件）
sudo tail -f /var/log/app/app.log
sudo cat /var/log/app/error.log
❌ 这些应该被拒绝
sudo cat /etc/passwd # 想看系统文件？不许
sudo systemctl status nginx # 想管服务？没门
exit

3.当用户尝试执行未授权的命令时，sudo 会拒绝并记录日志：

Sorry, user ruoyi-dev is not allowed to execute '/usr/bin/cat /etc/passwd' as root on server01.

而且这次失败的尝试会被记录到 /var/log/secure（Rocky Linux）或 /var/log/auth.log（Ubuntu）中，方便审计追溯。

4.sudo 权限审计与追溯

所有 sudo 操作（无论成功还是失败）都会被系统记录，这是安全审计的重要依据：

# Rocky Linux / CentOS：查看 sudo 操作日志
sudo grep sudo /var/log/secure | tail -20
Ubuntu / Debian：查看 sudo 操作日志
sudo grep sudo /var/log/auth.log | tail -20
查看某个用户的所有 sudo 操作
sudo grep "ruoyi-admin" /var/log/secure | grep sudo

日志中会清晰记录：谁在什么时间用 sudo 执行了什么命令，工作目录是什么。一旦出了问题，可以快速追溯到具体的人和操作。

小结

至此，我们完成了整个"组 + 用户 + 命令锁"三层权限体系的搭建：

以后不管是新人入职还是岗位调动，只需要一条命令：usermod -aG devops 新用户名，权限自动生效。这才是企业级权限管理的正确姿势。

有问题欢迎在评论区留言交流！