企业官网建设流程全解析

很多团队在数据库管理上还停留在"把连接串发到群里，谁需要谁自己连"的阶段。表面上大家都能干活，实际上权限边界模糊、操作无法追溯、密码长期不变也没人管，等出了问题查日志都不知道该找谁。PostgreSQL作为开源生态里使用率很高的关系型数据库，在JumpServer这类开源堡垒机里的纳管方案其实已经相当成熟。这篇教程就基于我自己的部署和日常使用经验，把PostgreSQL数据库在JumpServer中的纳管流程、连接方式、常见坑位一次讲清楚，适合正在搭建运维审计体系、或者刚接触堡垒机的运维和DBA朋友参考。

1. 先想明白：把PostgreSQL收进JumpServer，到底解决了什么问题

1.1 数据库直连模式下的真实痛点

很多公司内部对数据库的访问是很随意的。开发要查数据，找DBA要个账号；测试要造数据，再要一个账号；外包同事临时接手，又给一个账号。慢慢账号越开越多，谁在用、用了多久、执行过什么SQL，完全没有记录。更麻烦的是，一旦有人误操作删了表，只能靠数据库本身的日志去查，而数据库日志默认又不记录每条SQL的完整执行人。

把PostgreSQL托管到JumpServer之后，情况会完全不一样。所有连接都先经过JumpServer认证，权限由资产授权统一控制，每一次会话都有录像和操作日志。这意味着"谁能连""怎么连""连上去做了什么"三个核心问题都有据可查。

1.2 JumpServer纳管数据库和纳管服务器有什么不同

如果你之前只用JumpServer管过SSH服务器，第一次纳管数据库可能会有一个认知落差：数据库资产不依赖SSH协议，走的是数据库原生协议。在JumpServer的资产模型里，PostgreSQL属于"数据库"类型，连接方式是JDBC或psql客户端直连，而不是登录到某台机器上再敲psql命令。这一点决定了后续的连接链路、账号模型、甚至排错思路都和普通服务器资产不一样。

我刚开始踩坑就是在这里：习惯性地去找数据库所在主机的SSH信息，结果发现JumpServer里的数据库资产只需要数据库IP、端口、库名和账号，不需要关心这台数据库跑在哪台机器上。理解了这一点，后面的配置思路就顺了。

1.3 纳管之后的访问模式长什么样

纳管完成后，典型的使用路径是：

• 开发/运维人员登录JumpServer Web界面，选择某个PostgreSQL资产，打开Web终端，直接进入psql交互界面。
• 或者在本地用DBeaver、Navicat、psql等客户端，通过JumpServer开放的代理端口连接数据库。

两种模式都会经过JumpServer的会话审计。也就是说，不论你是用Web终端还是本地客户端，操作行为都能被记录下来，这才是纳管的真正价值。

2. 纳管前的准备工作：版本、账号、网络三件事

2.1 版本兼容性先确认，少踩一半的坑

我建议你在动手之前先确认一下JumpServer和PostgreSQL两边的大版本，特别是JumpServer的版本太老的话，对新版PostgreSQL的认证协议支持可能会出问题。

如果你用的是JumpServer比较老的版本（比如v2.x），数据库纳管还依赖额外的数据库代理组件，配置链路会长一些，建议直接升级到v3.x以上，省心很多。

2.2 为纳管创建专用数据库账号

不要直接用postgres超级管理员账号去纳管。生产环境的最佳实践是创建一个"给JumpServer用的专用账号"，权限范围根据业务诉求收紧。一个典型的只读账号创建SQL类似这样：

-- 创建登录角色，密码自行替换 CREATE ROLE jmp_reader WITH LOGIN PASSWORD 'StrongPassword_2024'; -- 赋予只读权限 GRANT CONNECT ON DATABASE yourdb TO jmp_reader; GRANT USAGE ON SCHEMA public TO jmp_reader; GRANT SELECT ON ALL TABLES IN SCHEMA public TO jmp_reader; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO jmp_reader;

如果你希望纳管后能在Web终端里执行写操作，再按需把INSERT、UPDATE、DELETE权限加进去。注意一点：JumpServer的账号密码是托管在平台里的，创建账号时的密码强度尽量高一些，后面可以开启定期改密策略。

2.3 网络打通：JumpServer到数据库的链路要通

很多连接失败的问题都不是配置问题，而是网络不通。JumpServer本身可能部署在内网，PostgreSQL数据库也可能在内网，但仍然存在跨网段、防火墙拦截、数据库绑定地址只监听127.0.0.1等情况。

在配置资产之前，先手动从JumpServer的核心组件所在主机（或者数据库代理组件所在主机）验证一下网络连通性。最简单的方式：

telnet 192.168.x.x 5432

或者用nc：

nc -zv 192.168.x.x 5432

如果从JumpServer主机能正常连通5432端口，再继续后面的资产配置，不要跳过这一步。

另外还要确认PostgreSQL的监听地址和pg_hba.conf配置。默认安装的PostgreSQL通常只监听localhost，需要确认postgresql.conf里：

listen_addresses = '*'

以及pg_hba.conf里放了JumpServer主机的访问规则。这里的原则是：只给JumpServer所在的网段或IP放行，不要把数据库端口暴露到办公网甚至公网。

3. 在JumpServer里创建PostgreSQL资产：关键字段逐个说明

3.1 创建资产的完整路径

登录JumpServer控制台之后，依次进入"资产管理" → "资产列表" → "创建资产"。资产类型选择"数据库"，这时会出现数据库类型下拉框，里面包括MySQL、PostgreSQL、Oracle等，选择"PostgreSQL"即可。下面是你需要填的核心字段：

这里有一处容易忽略：某些版本里的数据库字段叫"数据库名"，有些版本叫"库名"，本质一样。如果你填的是连接串习惯写法里的dbname，对应就是它。

3.2 账号配置：特权账号和普通账号分开

创建资产后，会进入资产详情页，里面有"账号"页签。JumpServer会要求至少配置一个特权账号，也就是能登录数据库的账号。你可以把前面创建好的jmp_reader填进去，密码也一并录入。录入之后JumpServer会做一次连通性测试，测试通过才说明账号配置没问题。

如果后续有多套库、多套账号，建议做法是：

• 特权账号只保留一个（用于资产纳管、密码轮换）
• 普通账号按需关联给用户或用户组（用于实际日常登录）

我在实际使用中习惯这样做：特权账号用DBA创建的专属账号，权限范围相对完整但不滥用；给普通用户授权时，优先授权只读账号，需要写权限再单独申请。这样即使某个开发账号泄露，影响面也是可控的。

3.3 授权：让指定的用户或用户组能连接

资产创建好、账号配置好，接下来就是授权。在JumpServer中，授权通常通过"权限审计" → "资产授权"来完成，或者直接在资产详情里找到"授权"入口快速配置。

授权时要选：

• 授权对象：某个用户、用户组或部门
• 授权资产：刚才创建的PostgreSQL资产
• 授权账号：下拉选择jmp_reader，或者选择"全部账号"

授权成功后，被授权的用户登录JumpServer，就可以在"我的资产"里看到这个数据库资产，点击即可连接。如果授权完发现用户那边看不到资产，大概率是授权对象或授权账号没选对，回来看一眼。

4. 连接PostgreSQL的三种方式，分别怎么用

4.1 Web终端方式：最快、最省事、审计最完整

用户登录JumpServer后，在资产列表找到PostgreSQL资产，点击连接按钮，默认会拉起Web终端。这个终端本质上是JumpServer内部集成的数据库客户端，打开后你会直接进入psql交互界面。

psql (15.3) Type "help" for help. yourdb=>

在这里可以直接执行SQL查询和操作，整个会话过程被完整录制，后续可以在会话审计里回放。对有合规需求的团队来说，Web终端是首选的访问方式，因为不存在绕过审计的可能。我自己的使用习惯是：日常追查问题、临时看数据，一律用Web终端，不需要在自己的电脑上配任何客户端。

4.2 本地客户端方式：DBeaver/Navicat/psql都能连

有人不习惯Web终端，或者需要做大量交互式查询，用本地客户端更顺手。JumpServer也支持这种方式，思路是在JumpServer上开一个代理端口，本地客户端通过这个代理端口连接目标数据库。

具体操作路径因JumpServer版本略有差异，一般是在Web终端/我的资产页面找到"连接信息"或"数据库代理客户端"入口，获取一个代理连接串，格式类似：

主机：127.0.0.1 端口：xxxxx（动态分配的本地映射端口） 数据库：yourdb 用户名：jmp_reader 密码：对应密码

本地DBeaver新建连接时，把主机端口填成JumpServer分配的代理地址和端口，就能正常连上。这种情况下，流量经过JumpServer的数据库代理组件，审计信息同样会被记录。

4.3 命令行方式：适合自动化脚本和运维批量操作

如果要写脚本批量执行SQL，或者需要在服务器上通过命令行直连数据库，可以配置JumpServer的命令行工具或使用SSH隧道方式。简单理解就是：通过SSH登录JumpServer，再借助JumpServer的数据库代理能力转发到PostgreSQL。

这种方式的优点是不依赖Web界面和图形客户端，适合放在定时任务里。代价是需要额外维护命令行连接信息，配置复杂度略高。如果只是偶尔跑一两条SQL，建议还是用前两种方式，不值得专门为了命令行去折腾。

5. 实际踩坑记录：连接失败最常见的五个原因

5.1 密码认证失败：scram-sha-256和版本不匹配

数据库账号密码明明正确，但通过JumpServer连接时一直提示authentication failed。这个问题在PostgreSQL 14及以上版本中比较常见，因为新版默认密码加密方式是scram-sha-256，而JumpServer某些版本中的数据库连接组件如果只实现了md5认证，就会对不上。

解决思路有两种：

• 升级JumpServer到最新版本，新版连接组件已经兼容scram-sha-256。
• 在PostgreSQL端把该账号的密码改为md5加密方式，但我不太推荐在生产环境这么做，等于主动降低了安全等级。

最稳的验证方式是：先在数据库本机用psql用同样的账号密码手动连接一次，确认账号密码没问题，再排查JumpServer侧的认证兼容性。

5.2 pg_hba.conf没放行JumpServer的连接来源

这个问题很隐蔽。数据库本机用psql连接一切正常，但通过JumpServer连接却被拒绝，很可能是pg_hba.conf里没有放行JumpServer主机的IP。PostgreSQL的认证规则是逐条匹配的，默认配置通常只允许127.0.0.1和::1的本地连接。

我的排查链路是：

# 在JumpServer主机上测试端口连通 nc -vz 数据库IP 5432 # 再测试认证，看报错信息 PGPASSWORD='密码' psql -h 数据库IP -U jmp_reader -d yourdb -c "select 1"

如果端口通但认证被拒，基本可以确定是pg_hba.conf的问题，放行JumpServer来源网段后重载配置：

pg_ctl reload

5.3 连接建立后不久就断开

有的场景是刚连上能正常查询，几十秒或几分钟后连接就中断了。这通常是网络链路中的空闲超时或代理空闲超时导致。JumpServer的数据库代理默认可能会有空闲会话回收策略，而PostgreSQL本身的keepalive参数也可能不够健壮。

解决办法分两层：

• 在JumpServer侧调大数据库代理会话的空闲超时时间。
• 在PostgreSQL的参数里设置合适的tcp_keepalives_idle、tcp_keepalives_interval值。

不过也要理解一点：堡垒机为了安全，回收长时间空闲的会话是合理行为，如果你只是断在空闲期，重新连接一下问题不大，不建议为了省事把超时调到无限长。

5.4 Web终端里中文乱码

Web终端进入psql后，查询结果里的中文显示成乱码，多半是客户端环境的字符集和数据库字符集不一致。先确认数据库本身：

SHOW SERVER_ENCODING; SHOW CLIENT_ENCODING;

如果数据库是UTF8，而JumpServer终端环境默认非UTF8，就会出问题。可以在psql里手动设置：

\encoding UTF8

或者更本质一点，确认JumpServer系统的locale设置。这个问题不常见，但一旦遇到会非常影响体验，建议记下这个命令。

5.5 授权正确但用户看不到资产

最后一个常见问题是：明明授权也做了，资产也创建了，但用户登录JumpServer后看不到这个数据库资产。我排查过几次，原因都是在创建授权时选了"资产"这个层级，但没正确关联用户或用户组；或者选择了"指定账号"但账号下拉为空，导致授权关系实际是不完整的。

一个容易理解的检查方法是：在JumpServer后台分别看"资产-账号"和"授权-关联资产"两个视图，确认资产、账号、授权对象三条链路都是通的。如果任何一环缺失，用户端就不会展示该资产。

6. 纳管之后的安全落地：权限最小化与审计闭环

6.1 权限最小化，不只是"能连"而已

JumpServer解决的是"谁能连"和"连接过程可追溯"，但它不会替代PostgreSQL内部的权限体系。一个账号连上数据库之后能干什么，仍然是数据库侧权限说了算。所以我在实际落地时，有一套固定的权限组合：

• 只读场景：SELECT权限，不赋予任何DML权限。
• 开发调试场景：可以额外给INSERT、UPDATE、DELETE，但坚决不给DDL。
• 结构变更场景：单独申请DDL权限，并有运维人员在场复核。

千万不要因为JumpServer做了授权管理，就觉得数据库内部权限可以放开。堡垒机是外层的门禁，数据库账号是内层的房间钥匙，两层都不能松。

你可以用这样的表格来梳理不同角色的权限：

6.2 开启定期改密，让账号密码不"长毛"

数据库账号密码如果长时间不变，一旦泄露就相当于长期后门。JumpServer支持账号密码的定期轮换能力，可以把纳管的数据库账号纳入改密策略，周期自己定（建议30到90天）。

开启定期改密之后，JumpServer会按照策略自动修改PostgreSQL账号的密码，并同步更新自己这边的托管记录。这样团队成员不需要感知密码变化，仍然通过JumpServer登录，但底层密码已经悄悄换过一轮了。我在生产环境开启了90天的改密周期，运行大半年没有因为这个出过问题。

6.3 审计回放：事后溯源的最后一道防线

纳管PostgreSQL后，每次会话都会在JumpServer的"会话审计"里留下记录。出现疑似误操作或安全事件时，直接按时间、账号、资产检索会话，回放那个时间段的终端录像，基本能还原完整的操作过程。和以前"查数据库日志半天找不到人"相比，效率完全是两个级别。

有一点要提醒：Web终端的回放依赖会话录像文件，本地客户端通过代理连接的会话也建议开启连接级日志，让审计数据更完整。不要等到出了事故才想起开审计，那会儿已经晚了。

6.4 我的落地建议：先小范围试点，再全量推广

如果你所在团队是第一次把PostgreSQL纳入堡垒机管理，我不建议一上来就全部库都纳管。更稳妥的路径是：

• 先选一个非核心的数据库实例做试点，跑通资产创建、账号配置、授权、Web终端连接、本地客户端连接、会话审计全链路。
• 试点过程把本文提到的坑位都踩一遍，确认没问题。
• 再逐步把其他库纳入，同时把已有账号回收清理掉，要求所有人的数据库访问都必须走JumpServer。

最后再分享一个小技巧：如果你发现JumpServer里对数据库资产的操作按钮和文档不一致，先去看一眼当前JumpServer版本，不同版本的功能入口差异确实不小。所有操作尽量在最新稳定版上做，很多旧版的数据库纳管问题其实都已经在新版里修复了。PostgreSQL的纳管链路一旦跑顺，后续再纳管MySQL、Redis这些资产，思路基本都是相通的，可以复用同一套经验。