从跳板机到堡垒机：JumpServer开源运维审计平台部署实战

先明确一个事很多人把堡垒机和跳板机混着叫其实这俩根本不是同一个东西。跳板机更像一个中转入口你通过它跳到内网服务器上但跳上去之后干了啥它基本不管。堡垒机不一样它要管身份认证、权限控制、操作审计甚至能录下你敲的每一条命令。这次我选择JumpServer来落地就是看中它开源免费、社区活跃、功能基本对标商业堡垒机的特点。这篇文章我按自己的实际搭建过程来写从选型思路到部署细节再到日常使用和踩坑记录尽量把每一步都交代清楚让没接触过堡垒机的人也能照着搭起来。1. 先搞清楚需求为什么要给团队上堡垒机1.1 没有堡垒机之前团队是怎么管服务器的小团队初期管服务器基本就是一个共享账号走天下。所有人共用root密码放在微信群里谁要用谁自己去登。今天张三改了个配置明天李四重启了个服务出了问题都说是对方干的最后查无可查。我接手过一个维护项目服务器有二十多台团队六个人。出过一次线上事故有人把生产库的索引删了但没有人承认。因为没有操作记录最后只能看数据库binlog慢慢分析折腾了一晚上才定位到人。那次之后领导当场拍板要上堡垒机。这个场景应该是很多团队的真实写照。堡垒机解决的不只是“谁能登服务器”的问题更重要的是“登上去做了什么”必须有据可查。1.2 堡垒机在安全体系里的定位从信息安全角度看堡垒机属于运维安全审计范畴核心功能可以拆成三块认证管理统一入口所有运维人员必须先登录堡垒机再通过堡垒机跳转到目标服务器服务器本身不直接暴露给个人。权限控制按用户、按资产、按账号粒度定义谁能访问哪台机器细化到IP、端口、命令级别实现最小权限原则。操作审计完整记录会话过程包括命令行输入、屏幕录像、文件传输记录事后可回放形成闭环追溯。对比一下商业堡垒机和开源方案商业产品通常在合规报表、国密算法、硬件化方面做得更好但价格不低。对于中小型团队JumpServer的社区版覆盖80%以上的日常需求完全够用。1.3 为什么我选了JumpServer选型的时候我对比了市面上几款开源堡垒机方案包括一些老牌的跳板机工具。JumpServer胜出主要因为这几点功能完整认证、授权、审计、资产纳管、数据库连接都在一个平台上解决不用拼凑多个工具。部署简单官方提供一键部署脚本通过Docker Compose方式拉起所有组件半小时内能跑起来。界面现代化Web终端体验好还能通过浏览器直接操作RDP、VNC、数据库资产比传统只能SSH的方案强太多。社区活跃文档、issue、视频教程都很全遇到问题基本能搜到解决方案不会卡住。我实测下来的结论是JumpServer适合大多数有运维合规需求的团队尤其是预算有限但想认真做审计的公司。2. 部署前的准备工作版本选择、硬件评估与架构理解2.1 版本选择稳定版优先JumpServer的版本迭代很快我在部署时选择的是当前最新的稳定发布版本。这里建议不要盲目追求最新因为新版本偶尔会有一些还没暴露出来的问题。官方在GitHub Releases页面会明确标注稳定版和预发布版认准稳定版下载即可。社区版的核心功能包括资产纳管、Web终端、SSH客户端连接、录像审计、命令过滤、批量命令执行这些足够支撑一个几百台服务器的团队日常使用。企业版则额外提供一些增值能力比如改密计划、账号收集、合规报表、工单审批等这些后面统一说先按社区版搭建。2.2 硬件与操作系统评估关于硬件配置官方推荐的基线是4核8GB内存、50GB磁盘。我自己的实践是测试环境2核4GB可以跑起来但并发会话高的时候会明显卡顿视频录像回放也会有延迟。生产环境建议至少4核8GB起步如果资产数量多、在线会话频繁往上加到8核16GB会更从容。磁盘录像和日志会持续增长建议单独挂一块数据盘容量按每台资产每天约5MB录像文件估算留足余量。操作系统我选的是CentOS 7.9因为团队现有服务器大多是这个版本运维习惯一致。其实官方支持Ubuntu、Debian等多主流系统选自己熟悉的就行关键是要能正常装Docker。2.3 JumpServer的组件架构想要排查问题必须先理解JumpServer的组件构成。它不是一个单体服务而是多个组件配合工作Core核心服务负责API、认证、资产授权、审计存储等逻辑处理。KokoSSH客户端服务负责处理通过SSH协议接入的连接。LionWeb终端服务支持通过浏览器访问RDP、VNC、SSH等协议资产。Celery Worker异步任务处理比如批量执行命令、录像转码等。MySQL存储用户、资产、授权策略等元数据。Redis缓存会话状态、任务队列信息。理解这个架构之后你会发现日常排障基本都围绕这几个组件的状态展开。比如会话连不上优先看Koko和Core的日志录像丢失大概率是Celery Worker处理异步任务出了问题。3. 实际操作从零开始完成JumpServer的部署3.1 环境准备关闭防火墙和SELinux这一步被很多人忽略但恰恰是新手最容易卡住的地方。JumpServer需要监听80、443、2222等端口CentOS默认的firewalld和SELinux如果不处理后续访问会莫名其妙被拒。我的操作顺序是# 1. 关闭firewalld并禁止开机自启 systemctl stop firewalld systemctl disable firewalld # 2. 永久关闭SELinux需要修改配置文件 sed -i s/SELINUXenforcing/SELINUXdisabled/g /etc/selinux/config setenforce 0 # 3. 验证状态 getenforce提示setenforce 0只是临时生效重启后还会恢复。修改/etc/selinux/config文件才是永久方案。生产环境如果安全策略不允许关闭SELinux也可以配置放行对应的端口和策略但复杂度会高不少。3.2 安装Docker和Docker ComposeJumpServer的部署脚本依赖Docker Compose来编排容器。如果你的服务器之前装过旧版Docker建议先卸载干净再重装避免版本兼容问题。安装Docker用官方源或者国内镜像源执行常规安装流程即可# 安装依赖包 yum install -y yum-utils device-mapper-persistent-data lvm2 # 配置Docker yum源 yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo # 安装Docker社区版 yum install -y docker-ce docker-ce-cli containerd.io # 启动Docker并设置开机自启 systemctl start docker systemctl enable docker再检查一下docker compose命令是否可用。新版Docker引擎已经内置compose v2插件可以直接用docker compose version验证老版本没有的话需要单独装docker-compose。3.3 使用官方一键脚本部署JumpServerJumpServer官方提供了一个快速部署脚本它的作用是拉取当前最新稳定版的安装配置和镜像编排模板然后根据交互式提示自动生成配置文件并启动容器。# 下载并执行快速开始脚本 curl -sSL https://github.com/jumpserver/installer/releases/latest/download/quick_start.sh | bash脚本执行过程中它会引导你设置一些关键参数比如安装目录、数据库配置方式等。默认情况下MySQL和Redis会随JumpServer一起以容器方式部署这样可以开箱即用。脚本完成后检查所有容器是否正常运行docker ps正常情况下你至少能看到jms_core、jms_koko、jms_lion、jms_celery、jms_mysql、jms_redis这些容器状态都是Up。看到容器起来了部署这一关就算过了一大半。这里要提醒一下GitHub在某些网络环境下的下载速度可能不太稳定如果你执行脚本时长时间卡住或者镜像拉取超时需要自己配置镜像加速器或者从备用源下载安装包。不过这不影响使用目的是把整套组件拉起来。3.4 初始化Web控制台浏览器访问http://服务器IP默认80端口第一次打开会进入初始化页面。这里需要创建一个管理员账号注意这个账号是堡垒机自己的超级管理员不是后面创建运维用户用的普通账号。初始化步骤通常会涉及几个配置项管理员用户名和密码设置一个强密码注意和业务密码区分开。邮件服务器配置如果不打算用邮件发通知可以先跳过后面在系统设置里补。密钥配置JumpServer会自动生成加密密钥用于数据加密存储。初始化完成后登录进去看到的是JumpServer的管理控制台到这里部署工作就算完成了。从开始装Docker到看到登录页整个流程顺利的话半小时左右。4. 核心功能配置用户、资产与授权策略4.1 创建用户分管理员和普通用户JumpServer的用户角色分为系统管理员、审计管理员、普通用户等。系统管理员可以管理整个平台普通用户只能看到被授权给自己的资产。创建普通用户的位置在控制台左侧菜单“用户管理 - 用户列表 - 创建用户”。需要填用户名、姓名、邮箱、密码等基本信息。这里建议用户名为员工工号或拼音方便统一管理。密码首次由管理员设置并强制用户在第一次登录时修改。邮箱必须真实有效因为后续开通MFA、接收通知都会用到。4.2 纳管资产填入服务器的连接信息资产纳管是堡垒机的核心所有服务器都要在JumpServer里被当成资产管理起来用户才能通过堡垒机跳转过去。创建资产的入口是“资产管理 - 资产列表 - 创建资产”。对于一台Linux服务器需要填的关键信息包括主机名给资产起个容易识别的名字比如“生产-应用服务器-01”。IP地址服务器的内网IP。协议和端口SSH默认22RDP默认3389。账号信息可以后续单独维护资产账号库也可以在资产上直接填root或普通账号和密码。这里有个实用的功能是“批量导入”。如果有一批服务器要加入可以先下载Excel模板把资产IP、协议、账号、端口等按模板填好然后一次性导入效率会高很多。4.3 授权策略资产和用户的绑定关系资产建好、用户建好两者之间还需要授权策略关联起来。授权策略的作用是规定“谁”在“什么时间”能访问“哪些资产”的“哪个账号”。创建授权的入口是“权限管理 - 授权策略 - 创建授权规则”。我的实践习惯是按业务线分组资产比如前端组、后端组、数据库组。按角色创建授权比如给研发人员授开发环境的Linux资产给DBA授数据库应用资产。尽量细化到资产账号级别不要一个授权把所有资产全部开放避免权限过大。授权策略支持设置有效时间段比如只在工作时间开放这个对控制风险很有效。比如某个外包人员只需要在项目期内访问测试服务器那授权时间就设置在项目周期内到期自动失效。4.4 命令过滤限制高危命令JumpServer支持命令过滤这是运维安全里非常实用的一环。可以定义一组正则规则对用户在终端里敲的命令进行实时匹配命中后可以选择阻断或者审批。我自己设置的过滤规则包括禁止执行rm -rf /、mkfs等破坏性命令。禁止在非授权网段使用scp、rsync大量传输文件。对drop table、truncate table等数据库高风险操作进行二次审批。命令过滤配置好之后一定要先用测试账号自己试一遍确认规则能生效再对全员开放。我见过有人配了规则但没生效原因是协议版本选错了过滤规则只对SSH协议生效而实际连接走的是Web终端两者容易混淆。5. 日常使用实战三种常见连接方式与审计查看5.1 Web终端浏览器里的Linux操作台用户在浏览器里登录JumpServer后进入“我的资产”能看到分配给自己的所有资产列表。点击“连接”按钮会在当前浏览器窗口拉起一个Web Terminal体验和本地SSH终端几乎一样还支持文件上传下载。这个方式对前端同学特别友好不用装Xshell、Putty之类的软件打开浏览器就能干活。我测试过延迟情况在同等网络条件下Web终端比本地SSH客户端多了20毫秒左右的中转延迟日常操作感知不明显排障时如果觉得卡顿可以记录网络链路耗时作为参考。5.2 SSH客户端方式用本地终端连接堡垒机习惯用本地终端的运维人员也可以通过SSH协议直接连接堡垒机ssh -p 2222 用户名堡垒机IP这里的2222端口是JumpServer的SSH接入端口用户登录后进入的不是系统Shell而是一个对话式菜单界面上会列出你可访问的资产列表然后按提示输入资产编号即可跳转到目标服务器。需要注意的是这种方式要求用户在JumpServer中开启了SSH公钥认证或者允许密码认证。默认情况下密码认证是开的但建议生产环境把公钥认证开起来密码认证关掉更加安全。5.3 数据库应用连接MySQL、Redis都能通过堡垒机访问JumpServer一个很方便的扩展功能是支持数据库类型资产。你可以把MySQL、Redis、PostgreSQL等数据库服务也纳管进堡垒机用户通过Web页面连接时JumpServer会自动拉起一个数据库客户端页面直接操作SQL查询或数据变更。这个能力对有数据库审计需求又不想装商业数据库审计系统的团队来说很省事。配置数据库资产的要点在创建资产时选择协议为MySQL或Redis并填入地址、端口。资产账号信息填数据库用户的连接信息。授权策略中单独给DBA或开发人员配置访问数据库资产的授权。数据库操作全程会被记录下来包括执行的每一条SQL语句出问题可以精确回放。5.4 录像审计与操作回放审计功能是堡垒机的核心价值所在。在“审计台 - 会话审计”里可以查看所有历史会话记录包括会话时间、用户、资产、登录IP、时长等信息还可以点击播放录像回看当时的屏幕操作。录像回放对事故定位的帮助非常大。有一次我们排查线上配置被改动的问题通过会话录像一帧一帧看很快发现有人用Navicat直连数据库执行了敏感操作而他的操作路径根本没有经过堡垒机。这件事反过来推动了网络层规则调整把数据库端口收窄为仅允许堡垒机服务器访问从根源上杜绝了绕行。6. 进阶配置MFA、LDAP集成与高可用规划6.1 开启MFA多因子认证堡垒机的账号本身就很重要如果密码泄露所有纳管资产都会暴露。所以我强烈建议开启MFA多因子认证。JumpServer支持TOTP动态令牌也就是常见的Authenticator类App扫码验证。开启方式是在“系统设置 - 安全设置”中将两步认证开关打开。之后每个用户需要在自己的账号资料里绑定动态令牌手机上下载一个支持TOTP的认证器扫描JumpServer显示的二维码再输入动态验证码即可完成绑定。从实际使用体验看MFA的麻烦程度很低每次登录多花几秒钟但安全提升是很明显的。如果用户手机丢了管理员可以在后台重置该用户的MFA绑定不用怕被锁死。6.2 LDAP/AD域控集成公司如果已经用OpenLDAP或微软AD统一管理账号JumpServer可以直接对接省去单独维护堡垒机用户和密码的麻烦。集成后员工登录JumpServer时直接使用域账号密码人员离职只要在AD里禁用账号堡垒机就自动无法登录。配置位置在“系统设置 - 认证设置 - LDAP/AD”。需要填写域控服务器地址、Base DN、过滤条件等。我实践中的一个建议是先开启“用户自动导入”让域内用户登录后自动同步到JumpServer不要手动逐个创建。等人员同步正常后再做授权策略的批量绑定。6.3 备份策略与高可用规划堡垒机上保存着所有用户、资产、授权和审计录像一旦数据丢失影响非常大。我建议至少做两件事数据库备份JumpServer的元数据都在MySQL里可以配置每日mysqldump备份到远端存储。如果MySQL是容器方式部署需要进容器执行备份或者使用docker exec命令在宿主机上把备份脚本写好配合crontab定时执行。配置和录像备份配置文件目录和录像存储目录也要定期打包。尤其是录像文件一旦磁盘损坏很难恢复。高可用方面社区版默认是单机部署。如果业务规模更大、对稳定性要求更高可以考虑将MySQL和Redis外置到独立的高可用集群再通过负载均衡把Web和Koko服务多节点部署。这样架构会复杂一些但换来了故障容忍能力。6.4 企业版功能值得升级吗JumpServer社区版免费企业版需要商业授权。企业版主要在以下几个方向做扩展自动化运维改密计划、账号收集、资产自动发现减轻管理员重复劳动。合规报表自动生成符合等保、审计要求的报表减少人工整理。工单审批高危操作和资产访问走工单流程流程化管理。团队协同多人Share会话、同事代录等场景的支持。如果公司有等保合规要求且预算充足企业版确实省心。但如果没有硬性合规需求社区版加上一些人工流程规范也能把安全水位提得很高。7. 部署和日常使用中遇到的典型问题7.1 Web控制台无法访问Web控制台打不开我遇到的情况一般是Docker容器没起来先执行docker ps看是否有容器处于Exited状态。然后docker logs jms_core或对应容器名查看日志多半是数据库连接失败或端口被占。防火墙没有放行80端口虽然前面关了firewalld但有的云服务器安全组也需要放行对应端口。Nginx容器配置问题JumpServer前端默认通过容器内的Nginx服务入口如果Nginx容器有异常整体访问会受影响。排查思路是先用curl -I http://127.0.0.1在服务器本地测试再检查云安全组和网络策略逐层排除。7.2 SSH连接不上资产这个问题出现频率最高。用户能从JumpServer登录但点击连接资产时卡住或者超时可能的原因有两个资产账号密码错误建议先在本机用其他SSH工具直接连一下资产确认账号密码没问题。网络不通JumpServer服务器和目标资产之间的网络不通。注意JumpServer的访问链路是“用户电脑 - 堡垒机 - 资产服务器”所以堡垒机本身必须能访问到目标资产的内网IP。还有一种情况是多网段环境。JumpServer服务器在192.168.1.x网段目标资产在10.0.0.x网段中间没有路由这种情况下需要通过网域功能配置网络代理跳转让Koko通过指定的网络出口转发请求。7.3 录像无法回放或回放卡顿录像回放依赖Celery Worker对原始会话进行转码处理。如果录像一直加载不出来优先看Celery Worker容器的日志确认转码任务是否正常执行。转码本身是CPU密集型操作如果服务器资源紧张批量转码会排队。操作上不要积压太多录像才回放定期做录像备份和清理同时保证Celery Worker所在容器有足够的CPU配额。7.4 用户忘记密码或MFA失效用户密码忘了管理员可以在“用户管理 - 用户列表 - 编辑”里重置。MFA失效比如手机丢失、验证码总是不对管理员在用户详情页可以关闭两步认证让用户重新绑定。这里有个经验MFA解绑操作本身应该走一个审批流程否则管理员可以私下控制任何用户的账户。我在团队里指定只有安全组负责人有这个权限避免单人操作风险过大。7.5 版本升级的注意点JumpServer升级前一定要做两件事备份数据库和备份配置文件。升级过程中官方安装包会拉取新镜像并执行数据库迁移如果迁移中途失败有备份还能回滚到旧版本。升级完成后建议先检查所有容器状态和Web页面是否正常再用测试账号执行一次完整的资产连接流程确认核心链路没受升级影响再通知其他用户恢复正常使用。8. 部署完成后的个人体会整套JumpServer搭完并稳定运行之后我最明显的感觉是以前那种“密码满天飞、操作无人认”的混乱状态彻底结束了。有一次一个新同事入职给他的账号做完授权之后他直接就能看到自己权限范围内的所有测试服务器不用再找人要密码后来他误操作把测试环境的配置改坏了我们通过会话录像还原了整个操作过程第一时间定位了原因也让他意识到每一步都会被记录。给还想自己动手部署的人一个建议不要一开始就追求高可用和复杂架构先用官方一键脚本单机部署跑通“用户-堡垒机-资产”这条主链路再逐步加上MFA、命令过滤、LDAP这些进阶功能。等真正用起来、遇到真实业务问题了你自然知道自己该往哪个方向优化。最后再分享一个配置技巧上线之后先用一两个测试账号和低风险资产试运行两周让团队逐步适应通过堡垒机操作服务器的习惯。如果一上来就给全员推强制变更运维同事往往抵触情绪比较大。磨合期之后大家体会到“再也不用记一堆密码”的好处推广阻力反而会小很多。