搞了这么多年运维数据库资产一直是权限管理里最让人头疼的一环。尤其PostgreSQL这种逻辑库多、角色权限细的系统直接让人连生产库账号密码满天飞不说出事了你连谁干的都查不到。前阵子刚把一套PostgreSQL完整接进了JumpServer从纳管到授权再到客户端连接走了一遍把过程里踩过的坑和最后沉淀下来的配置方式整理出来。这套流程适合正在用JumpServer、想把PostgreSQL纳入统一管理又不想给开发开公网直连的团队参考。1. 为什么要把PostgreSQL放进JumpServer统一纳管先说结论数据库纳管不是把连接信息登记一下那么简单核心是把数据库的访问入口、凭据保管、操作行为全部收口到一个平台里。以前我们团队访问PostgreSQL的方式很原始DBA在部署文档里写一段连接串开发用Navicat或者psql直接连。时间一长问题就来了。账号密码在聊天记录、本地文档里传得到处都是改密码要通知所有人不改就只能默认大家都很自觉。连接串暴露意味着数据库端口直接对办公网开放扫到端口之后再爆破弱口令谁都扛不住。出问题的时候DBA只能靠数据库自带的日志去猜是谁执行的。开了log_statement也只能记录到IP和账号对不上具体的人。JumpServer做数据库纳管解决的正是这三个问题账号密码统一托管在堡垒机里访问者看不到真实密码数据库端口不直接暴露给终端用户所有请求都先经过堡垒机这一层每一次会话都有完整录像和执行记录操作人可以定位到具体账号。有一个点容易被忽略就是合规审计。我们这边要过内部的安全检查要求数据库操作必须有操作人、时间、内容三要素可追溯用JumpServer之后直接导会话记录和命令记录就能交差省了DBA手工翻日志的工作。再说说连接方式。JumpServer对PostgreSQL的支持分两个层面Web终端里直接用内置的数据库客户端工具操作以及通过堡垒机端口转发让Navicat这类GUI客户端走加密隧道连数据库。后面这种对开发更友好他们不用改变日常工具习惯但对DBA来说管理难度比想象中大具体细节后面会展开。2. 纳管前的环境准备与版本选型2.1 版本匹配是第一个坑先强调一个容易踩的问题JumpServer版本不同对数据库纳管的支持完整度差异很大。早期开源社区版对PostgreSQL的支持比较基础一些高级特性比如基于会话级别的动态凭据、操作审计增强是在X-Pack增强包里才补齐的。所以在规划阶段第一件事是确认JumpServer版本。建议选最新的LTS版本并且确认开启了X-Pack增强包。不需要纠结是不是商业版社区版配合增强包也能用关键是功能完整度。我当初就是开始用了一个较老的版本结果创建PostgreSQL资产时发现协议选项缺失升级之后才正常。版本确认完之后再确认PostgreSQL的版本。JumpServer的数据库连接代理组件基于Python生态对PostgreSQL的协议版本兼容性总体不错。9.x到16.x都测试过注意高版本的PostgreSQL默认开启了scram-sha-256密码认证老版本堡垒机组件对scram支持不完善的话会出现认证失败的怪问题。2.2 网络规划堡垒机必须能直达数据库数据库纳管成功与否一半取决于网络规划。核心原则是堡垒机的核心组件必须能访问到PostgreSQL的5432端口而终端用户完全不需要直接访问数据库地址。具体网络拓扑上注意三点堡垒机与PostgreSQL数据库之间建议走内网尽量避免跨公网传输。延迟高了之后psql的交互体验会明显卡顿而且大结果集的传输时间会变长。防火墙放行规则要精确到端口不要图省事放行整个网段。如果PostgreSQL有多个实例确保堡垒机到各实例的网络策略是独立配置的方便后续排查问题。如果环境里PostgreSQL开启了SSL强制需要在配置资产时勾选对应的SSL选项或者提前在数据库端放开非SSL连接。虽然生产环境建议全SSL但堡垒机代理组件对SSL证书校验有时会较真直接配置受信任证书更稳。网络规划好之后记得在堡垒机上先手动测试一下数据库连通性。用telnet或者nc测一下5432端口是否可达这一步能避免后面创建资产成功后、实际连接时才发现网络不通的尴尬。除了网络和版本还有一个容易被漏掉的工作PostgreSQL账号权限准备。建议专门为纳管创建一个独立的运维账号或使用超级用户来做初始连接测试但实际授权给用户的时候遵循最小权限原则。只要JumpServer托管的是有权限的账号用户最终能执行的SQL就限定在这个账号的能力范围内。3. 创建PostgreSQL资产与凭据托管3.1 资产的参数配置逐项说明打开JumpServer管理后台在资产管理-资产列表里切换到数据库页签点创建。填参数的时候有些字段一看就懂有些字段比较隐晦我按实际填写经验逐个说明。资产名称建议按环境-业务-实例的格式命名比如生产-订单库-主实例后期授权和搜索会方便很多。单纯用IP做资产名时间一长就认不出来了。资产IP填PostgreSQL的真实内网地址不要填堡垒机自己的地址。数据库类型这个关键选PostgreSQL不要选MySQL。虽然两者都是关系型数据库但协议细节不一样选错后连上去协议握手就会失败。数据库名PostgreSQL里一个实例可以有很多库如果你希望用户在Web终端里直接落到某个默认库这里填对应的数据库名。留空的话登录后落在和用户名同名的库上PostgreSQL的默认行为没有同名库就会报错。我一般建议填省得用户连上去一脸懵。端口默认5432按实际实例配置修改。协议这个字段在部分版本里是自动根据数据库类型带出来的。如果是手动选选postgresql协议。设备类型一般选数据库资产编号、所属区域这些字段按公司规范填。有个标签字段建议利用起来比如打上生产高权限的标签后面做资产授权筛选时非常好用。需要注意的是有些版本创建数据库资产时会有是否启用SSL选项。如果PostgreSQL没开SSL这里不要勾选否则会不断尝试SSL握手然后失败。3.2 凭据设置密码托管与密钥模式凭据是纳管的核心。JumpServer支持密码和SSH Key两种方式PostgreSQL一般用密码。创建凭据的时候可以填数据库账号名和对应密码也可以使用同一账号方式一台数据库实例上建立一个专用账号所有用户通过堡垒机连接时JumpServer统一使用这个账号去连接数据库然后通过自身的用户体系来区分操作人。另一种是多账号方式在JumpServer里创建多个账号对应数据库里的不同用户再把这些账号分别授权给不同的JumpServer用户。从DBA视角看更推荐同一账号方式也就是统一使用一个只读或读写受控的账号操作人信息靠堡垒机自身来标识。这样数据库侧不需要为每个开发都创建账号密码也只需要在数据库上维护一个大大降低了账号管理成本。开发要连库的时候在账号列表里勾选授权即可。用户登录JumpServer后看到的不是数据库原始密码而是JumpServer动态生成的连接信息本质上是通过堡垒机间接访问。说实话关于动态密码社区版和增强版的能力有差异。如果团队比较大账号多建议用增强版的动态凭据功能每个用户连接时分配临时数据库账号或临时密码会话结束后自动回收审计上更干净。这个后面连接部分还会细说。3.3 授权策略的有效期设计资产和凭据有了之后不要忘了授权策略。JumpServer的授权模型是用户-资产-账号三者的绑定关系需要手动创建授权规则。创建授权规则时关键几个字段名称建议包含业务线和有效期比如订单开发组-生产库-30天临时授权。用户范围选择需要授权的JumpServer用户或用户组。资产范围选择具体资产可以用标签批量筛选。账号范围如果该资产下挂多个数据库账号这里决定用户能使用哪些账号去连接。连接方式勾选Web终端和数据库客户端都允许或者根据实际需要只放行一种。有效期支持固定时间段和相对时长。这个字段容易被忽略临时授权场景下设一个截止日期到期自动失效就不需要手工回收了。4. 三类连接方式Web终端、CLI工具与GUI客户端4.1 Web终端最轻量的数据库操作入口资产纳管完成后连接方式决定了用户体验。我先说Web终端因为这一步最直观也最适合快速验证纳管配置是否正确。用户登录JumpServer之后在控制台首页右侧的资产列表里找到刚授权的PostgreSQL资产点击连接下拉里选择Web终端。第一次连接时JumpServer会初始化一个Web Terminal这是一个内嵌在浏览器里的会话窗口里面包含了数据库客户端交互环境。进入之后会自动连接到PostgreSQL提示符变成了postgres#的结构。因为连接方式是JumpServer代理组件预先配置好的用户不需要输入主机名、端口、密码直接开始敲SQL就行。我发现一个细节Web终端里不是纯psql环境有些内置客户端工具的命令行交互和psql略有差异比如元命令\dt、\l这类可能支持不全。建议先敲一个SELECT version();验证连接再逐步验证常用命令。这里有几个隐藏的风险要注意Web终端里默认使用UTF-8字符集如果数据库里存储的数据编码是GBK或字段里包含特殊字符展示上可能出现乱码。不过大部分现代PostgreSQL环境都是UTF-8问题不大。另外Web终端有闲置超时时间长时间不操作会自动断开写复杂脚本前建议先在本地编辑好再粘贴执行。4.2 CLI方式psql走堡垒机代理连接对很多开发来说浏览器里的Web终端不够舒服他们还是习惯在自己终端里用psql操作。这时就需要用到JumpServer的身份验证连接方式。流程上用户下载JumpServer提供的客户端工具在本地触发一次连接请求会生成一个临时隧道或转发规则。隧道建立后告诉用户连localhost的某个特定端口就等价于连到了目标数据库。我用一个具体例子说明 用户执行某条连接命令后系统返回本地转发端口5433已就绪。用户在自己机器上执行psql -h 127.0.0.1 -p 5433 -U jump_user -d appdb这里的5433是JumpServer动态分配的本地端口jump_user是授权到该资产的数据库账号appdb是目标数据库库名。密码一般也是动态获取的有的方案会直接注入到客户端工具的配置里用户在psql提示输入密码时粘贴临时密码即可。需要明确的是CLI方式的底层仍然是端口转发只不过由官方客户端自动化完成了。好处是用户不用深入了解转发细节坏处是如果客户端版本和服务端不匹配偶尔会遇到握手失败的情况。遇到这类问题先检查本地工具版本和服务端JumpServer版本保持两边都相对新容错率会高很多。4.3 GUI客户端Navicat与DBeaver的接入配置让开发最舒服的方式还是继续用Navicat、DBeaver这些GUI工具。用JumpServer的GUI代理连接方式开发只需要修改一下连接地址的填写方式其他操作习惯完全不变。配置步骤大致如下在JumpServer资产授权里确保开启了数据库客户端连接权限。用户在本地客户端工具里发起一个GUI代理会话获取一组动态的连接参数通常包括本地地址、本地端口、数据库账号。在Navicat或DBeaver里新建PostgreSQL连接主机填127.0.0.1或其他提示的转发地址端口填动态分配的端口用户名和密码填JumpServer给出的动态账号密码。点击测试连接不出意外能直连成功。这里我踩过一个坑想分享出来动态账号的权限。JumpServer的GUI代理支持的账号类型和Web终端不完全一致如果资产创建时凭据选择的是数据库账号密码模式动态生成的连接信息一切正常但如果是SSH隧道方式组合不当GUI代理可能连不上。所以配置资产时凭据模式选数据库账号不要用SSH模式来连PostgreSQL。GUI连接方式下审计层面会弱一些虽然JumpServer能拿到会话开始和结束的记录但GUI工具发送的SQL具体内容不一定都能被完整捕获取决于数据库本身的会话日志。所以对于生产库的高危操作建议后续配置数据库层的log_statement堡垒机审计与数据库日志双保险。5. 高危命令过滤与操作审计的落地配置5.1 命令过滤器的规划思路资产纳管和连接方式定了之后重点就该转向安全控制。JumpServer的命令过滤器可以阻止用户执行指定的SQL模式这一步非常建议配置特别是对生产环境。但PostgreSQL的命令过滤比SSH命令过滤要复杂SSH命令是整行匹配而SQL语句可能有换行、注释、大小写混写还有各种表达式。纯字符串匹配很容易漏或者误杀。我梳理一下有效的匹配策略对无WHERE条件的DELETE和UPDATE用正则匹配重点拦截比如匹配^\sdelete\sfrom\s(\w)\s$这个能拦住没有where的裸删除。对DROP、TRUNCATE、ALTER这类DDL建议在授权策略上直接不给普通用户开通只有DBA账号才允许。对一些危险函数比如pg_sleep、pg_read_file也可以定义在过滤器里。需要注意命令过滤器不是在数据库层执行的它更像一个文本模式匹配器所以它防不住语义复杂的SQL比如通过子查询间接删数据。它最大的价值是防手滑、防低级事故而不是防恶意操作。生产环境我建议设置会话命令记录为开启这样用户在Web终端里执行的每一条SQL都会被记录下来审计回放时定位问题会快很多。CLI转发模式下命令日志的完整度受客户端工具影响较大最好也关注数据库自身的日志。5.2 访问控制策略与最小权限实践授权策略设计上有一个经验值得参考:永远从最小权限起步不要上来就给予库管理员权限。系统里我一般会建几个模板只读组授权给报表查询和数据分析同学对应数据库账号是只读角色不允许INSERT/UPDATE/DELETE。读写组授权给业务开发允许DML但不允许DDL。DBA组授权给运维和DBA允许一切操作但操作前需要审批。JumpServer支持授权策略的审批流程。对于DBA组的高危连接可以设置需要审批后才生效或者限定有效期。这样每次数据库变更都有记录而且必须有人为操作负责。还有一个功能命令过滤器的生效范围可以挂在授权策略上。这样可以对不同授权对象应用不同的过滤规则做到只读组连SELECT都只限制在指定库DBA组连DELETE都必须带WHERE。这是比较高级的用法配置时注意测试顺序过滤器是黑名单性质的命中即阻断。5.3 会见审计与回放的实战价值会话审计在真正出问题之前很容易被当成用完就忘的功能直到真的有一天需要追查一条线上数据是谁改的。我的建议是定期把会话记录导出归档。JumpServer的会话记录包含命令输入、输出和屏幕录像。分析时可以先用时间范围缩小到具体会话再定位到具体命令。有一次排查某个表被TRUNCATE的时间就是依托命令记录里的执行时间精确锁定了操作窗口再结合数据库日志把SQL定位到具体操作人。CLI和GUI连接方式的会话记录完整度不如Web终端如果想保证完全的审计闭环可以考虑约束所有用户必须走Web终端操作虽然体验差一点但审计最完整。这个取舍要根据团队实际情况来定。6. 排查实录纳管中最常翻车的6个问题6.1 认证失败密码正确但登录被拒这个问题的表现是用户拿着JumpServer给的动态账号密码在客户端工具里测试连接提示password authentication failed。排查思路建议按顺序来先确认为PostgreSQL创建的数据库账号密码是否正确直接数据库本机psql测试。如果本机正常再确认数据库的pg_hba.conf里允许的认证方式。JumpServer代理组件走的是TCP连接如果pg_hba.conf只允许本地trust远程连接肯定被拒。如果用的是动态账号功能确认JumpServer具备创建临时账号或动态密码的权限如果该功能试图去数据库里建角色却没有CREATEROLE权限也会报认证失败或者角色创建失败。一个冷门问题是PostgreSQL的密码加密方式。高版本如果设置password_encryption scram-sha-256而JumpServer的数据库代理组件仅支持md5方式会出现password authentication failed for user的经典报错。解决方式是修改代理组件的认证配置或者在pg_hba.conf暂时允许md5方式做过渡。6.2 连接超时与保证端口不通连接超时大多不是JumpServer配置问题而是网络策略问题。按照之前的规划堡垒机到PostgreSQL的5432端口必须通。如果连接超时先检查这两点一是堡垒机到数据库的防火墙规则二是PostgreSQL实例是否监听了正确的网卡地址。尤其多网卡服务器上PostgreSQL默认只监听127.0.0.1需要修改listen_addresses为实际内网IP并且重启服务。排查这类问题时用下面这条命令比GUI验证更直接telnet 数据库IP 5432如果telnet能通说明网络没问题问题在认证或者配置层不通就回去查网络策略。6.3 Web终端卡死与中文乱码Web终端卡死通常有两个原因一是数据库返回大结果集浏览器渲染压力大二是会话闲置时间太长系统断开了。解决大结果集的办法是限制查询在psql里设置FETCH_COUNT或者用LIMIT限制返回行数。会话闲置断开的逻辑可以在JumpServer里调整对经常写长SQL的同事可以把闲置超时调长一些。中文乱码的问题先确认数据库的client_encoding设置然后确认Web终端默认的字符集。PostgreSQL里可以执行SHOW client_encoding;查看当前客户端编码如果显示的是SQL_ASCII会有隐患建议明确设置成UTF8。6.4 客户端工具版本兼容与驱动问题这个现象比较隐蔽用DBeaver连接出错但Navicat连接正常或者反过来。本质上是各自的PostgreSQL JDBC驱动版本对协议和认证方式的支持不同。排查时留意DBeaver的错误信息里如果有SCRAM字样优先考虑调整JDBC驱动版本。DBeaver里可以在连接设置里指定自定义驱动版本选择较新的JDBC驱动。注意跳版本不宜太激进和数据库大版本匹配就好。6.5 动态凭据权限不足导致连接失败动态凭据功能开启后JumpServer需要有一个托底的管理员账号来生成临时账号。如果用的托底账号权限不足比如没有CREATEROLE或者不是超级用户动态账号的创建就会失败连接自然也就不可能成功。这种问题的报错可能非常隐晦日志里可能只显示动态账号创建失败或干脆显示认证失败。排查时先看JumpServer的应用日志定位到具体的权限错误然后把托底账号的权限补齐。6.6 授权策略未生效用户看不到资产用户登录后在Web终端资产列表里找不到PostgreSQL资产常见原因是授权策略没建好或者资产授权了但账号范围不包含。核对思路是检查授权策略的用户范围-资产范围-账号范围三元组是否匹配。还有一个容易踩的点授权策略的资产范围如果要选标签必须先给资产打标签。资产创建的时候没打标签后面授权时选不到就会误以为授权失败。修复方式很简单补标签之后再修改授权策略即可。7. 一些关键心得与铁律最后分享几条我在整个纳管过程中总结出来的心得可以当作后续操作的铁律数据库纳管不是一个一次性配置的事而是一个持续迭代的安全流程。资产上线之后定期检查授权策略和命令过滤器尤其重要尤其是人员变动频繁的团队。不要把所有PostgreSQL实例往一个资产IP里塞。一个实例对应一个资产一个数据库库对应一种授权不然审计时无法区分谁在哪里做了什么。高权限的PostgreSQL账号只放在JumpServer里不要让普通用户直接持有。密码定期轮换轮换后更新JumpServer的凭据即可不需要通知所有开发。定期导出会话记录做一次复检重点关注是否有疑似绕过过滤器的操作模式。命令过滤器是防手滑的不是防恶意的。核心数据库的最终防线仍然是PostgreSQL自身的日志和权限体系。数据库纳管这事儿刚开始配置的时候觉得繁琐但真的落地之后日常的工作反而变得更清爽开发不再追着DBA要密码DBA不用反复处理端口暴露的隐患安全审查的时候直接导记录。希望这篇记录能帮正要接PostgreSQL的团队少走几步弯路。