JumpServer 堡垒机落地实战：三类用户模型与 sudo 白名单

SSH 加固之后权限问题暴露得更明显了：业务机器上人手一个账号、root 随处可用、发出去的密码收不回来、出了事谁也说不清”那条命令是谁敲的”。数量到十几台之后，靠约定已经管不住了，上一套堡垒机是唯一的出路。这篇记录 JumpServer 的落地过程。

一、为什么必须要有统一入口

直连模式下有四个治不了的病：

  • 账号泛滥：每个人一个 root 或业务账号，密码到处传，离职了账号还在；
  • 权限不可控：开发能登生产、能改配置，没人知道；
  • 没有审计：出事只能查命令历史，多用户共享账号时基本没法定位；
  • 暴露面大：业务服务器直接开 22 端口对公网，每天被扫。

堡垒机的定位就是：唯一入口 + 统一认证 + 权限隔离 + 操作审计。所有运维操作要么走 Web 终端，要么 SSH 先连堡垒机再选资产，业务机不再对个人开放。

跳板机和堡垒机的区别也顺带说清：跳板机只是”一台中转服务器”；堡垒机是一整套平台，多了统一账号体系、资产授权、命令过滤、录像回放这些能力。

二、部署与组件构成

JumpServer 的组件比想象中多，但安装脚本已经全包了：

1
2
3
4
5
6
7
8
cd /opt
tar -xf jumpserver-ce-v3.x.x-x86_64.tar.gz
cd jumpserver-ce-v3.x.x-x86_64
cat config-example.txt          # 先看配置模板（端口、数据库、Redis 参数）

./jmsctl.sh install             # 安装（会初始化 MySQL/Redis/Docker 组件）
./jmsctl.sh start               # 启动
./jmsctl.sh -h                  # 其他管理命令：down / uninstall

装完记住两件事：默认密码登录后立刻改掉，以及马上开启 MFA——堡垒机是内网权限最集中的一台机器，它被攻破等于全公司沦陷。

核心组件（理解它们才好排障）：Core（主服务：用户/资产/授权/审计）、Koko（SSH 协议代理，ssh/sftp 转发）、Luna（Web 终端）、Magnus（数据库代理）、RDP/VNC 代理（连 Windows）。

三、三类用户模型：先想清楚再动手

这是 JumpServer 权限体系的骨架，没理顺就上线，后面全是返工：

类型 是什么 例子
普通用户 登录 JumpServer 的真实员工 kf_user01、yw_user01
系统用户 堡垒机登录到后端服务器时用的账号 kfhd（开发）、ywhd（运维）
特权用户 管理后端服务器的高级账号 root 或免密账号

落地顺序固定为七步：

1
2
3
4
5
6
7
8
9
# 1. 建用户组：开发组 dev、运维组 ops
# 2. 建普通用户并入组（一人一号，禁止共享）
# 3. 建特权用户（先在底层打通免密）
ssh-keygen -t ed25519
for ip in 172.18.1.{7,41,51}; do ssh-copy-id -i ~/.ssh/id_ed25519.pub $ip; done
# 4. 建系统用户（账号模板负责自动推送到目标服务器）
# 5. 建资产（服务器/数据库/网络设备）
# 6. 授权：组对组（开发组 → 开发资产组，用 kfhd 身份）
# 7. 验证：从作业中心看账号是否自动推送成功

实际登录逻辑（生产模型）：

1
2
3
4
5
普通用户 kf_user01/kf_user02  →  Web 或无感知 SSH 登录到 JumpServer
     ↓ 按授权选择资产
系统用户 kfhd（开发连接账号）   →  只能做业务操作
系统用户 ywhd（运维连接账号）   →  走 sudo 白名单提权
特权用户 root                  →  批量管理、Ansible 自动化用

四、sudo 白名单：不给 root，但要能干活

“不给 root”不是一句口号，落地要靠 sudo 规则，而且必须用全路径：

1
2
3
4
5
# 先查命令真实路径
which systemctl whoami

# 单独文件管理，不动 /etc/sudoers 主文件
visudo -f /etc/sudoers.d/kfhd

开发组（只给业务相关操作）：

1
2
3
4
kfhd ALL=(ALL) NOPASSWD: /usr/bin/systemctl status tomcat, \
                          /usr/bin/systemctl restart tomcat, \
                          /usr/bin/tail -f /data/app/logs/*, \
                          /usr/bin/less, /usr/bin/cat

运维组（系统级操作放开一档）：

1
2
ywhd ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/tail, /usr/bin/less, \
                          /usr/bin/yum, /usr/bin/docker, /usr/bin/chmod, /usr/bin/chown

自查命令常备：sudo -l 看自己有什么权限、id 看身份、which 确认路径——sudo 白名单写错路径是最常见的”配了不生效”原因。

JumpServer 账号模板推下来的 sudo 配置默认免密（用户已在堡垒机做过一次认证），这符合”一次认证、一次授权”的设计，但命令列表一定要按业务收紧，别图省事写 /usr/bin/*。

五、命令过滤与 MFA

命令过滤是堡垒机的核心风控，在”访问控制 → 命令过滤”里配置：

1
2
3
4
# 危险命令组示例
rm -rf /, mkfs.*, dd if=/dev/zero, shutdown, poweroff, drop database, truncate table

# 策略：运维组执行危险命令 → 审批；开发组 → 直接拒绝

MFA 必开：堡垒机账号是内网最高价值目标。生产规范是”新用户强制绑定 MFA 才能登录”+90 天密码轮换。绑定走用户中心 → 安全设置，扫码即可（TOTP 小程序）。

另外两个实用功能：

  • 网域：多云多地域的机器通过”区域网关”分层管理，堡垒机对网关免密、网关对域内机器免密；
  • 数据库资产：通过 Magnus 代理接入，SQL 也进审计，高危 SQL（无 where 的 delete、drop）可以配拦截规则。

六、关掉直连：最后一步，也是最关键的一步

堡垒机装好只是开始，业务服务器不关直连，一切白搭：

1
2
# 每个业务节点的 sshd 只允许堡垒机网段访问
# 或在云安全组/防火墙层面：业务机 1022 端口只放行堡垒机 IP

我们当时的落地清单：

  1. 全量服务器 SSH 基线加固（改端口、禁 root、密钥认证、fail2ban）；
  2. 部署 JumpServer，改默认密码、开 MFA、配邮件告警；
  3. 按”用户组 → 普通用户 → 系统用户 → 特权用户”建完模型；
  4. 资产按环境（生产/测试）和业务分组纳管，账号模板统一推送；
  5. 授权按组对组最小化，sudo 白名单收紧到业务实际需要；
  6. 开启命令过滤，高危命令走审批；
  7. 防火墙层面只放行堡垒机到业务机的连接；
  8. 开发/运维各验证一次完整链路（登录、提权、传文件）；
  9. 审计落地：定期抽查录像，离职账号当天回收。

七、安全红线

上线后写进团队规范、谁都不能碰的几条：

  • 禁止绕过堡垒机直连业务机——发现直连端口一律封；
  • 禁止共享账号——一人一号，否则审计形同虚设；
  • 禁止 root 满天飞——root 只留给特权用户，日常操作走 sudo 白名单；
  • 禁止明文密码——配置文件、笔记、代码库里都不能存密码，走密码管理器或 ansible-vault；
  • 禁止永久会话——会话超时、空闲踢下线；
  • 高危操作必审批——rm -rf、drop 库这类必须留下审批记录。

八、收尾感受

堡垒机上线一个月后回看，最大的变化不是”安全了多少”，而是出了问题能查到人、能回放现场——这比任何事前的口头约定都管用。运维的权限治理本质上是被审计压力倒逼出来的规范：当每个人都知道操作会留痕，破坏性命令自然就少了。