PostgreSQL数据库集群漏洞防护运维

PostgreSQL数据库集群的漏洞防护，本质上不是装个补丁、配个防火墙就完事，而是一套围绕“暴露面收敛、权限最小化、协议层加固、日志与恢复联动”的持续运维动作。多数生产事故的起点不是0day，而是默认配置、过度授权、复制链路明文传输和备份文件未加密。下面直接拆解具体风险和可落地的处置方法。

很多集群节点默认监听所有网卡，或者把管理端口暴露在业务网段。第一件事是检查postgresql.conf里的listen_addresses，只保留内部通信网卡地址，业务入口统一走负载均衡或连接池，不要让应用直连主节点和从节点。pg_hba.conf的规则顺序极其重要，必须把拒绝规则放在最前，再逐条放行具体业务网段和运维跳板机。认证方式不要使用trust，哪怕内网也不建议。对于复制账号，单独创建replication角色，限制来源IP，并且禁止该账号登录普通数据库。

PostgreSQL小版本更新经常包含安全修复，但很多团队因为担心升级影响业务而长期停留在旧版本。建议把“小版本跟进”纳入月度运维计划，主版本升级单独评估。至少要做到：所有节点版本一致，从节点不能高于主节点，避免流复制协议不兼容。升级前在测试环境验证pg_upgrade或逻辑复制迁移路径。对于无法立即升级的节点，应通过pg_hba.conf和连接池限制来源，降低被利用概率。

主从流复制默认使用明文传输WAL日志，如果跨机房或跨云同步，等于把数据变更暴露在链路上。必须启用SSL，并且在从节点配置sslmode=verify-full，同时校验主节点证书的CN。复制账号使用scram-sha-256认证，不要用md5。对于延迟敏感的场景，可以在内网使用专用复制通道，但仍然要加密。定期检查pg_stat_replication里的客户端地址和状态，发现异常连接立即断开并审计来源。

很多集群里应用账号直接使用postgres超级用户，或者拥有CREATEROLE、CREATEDB权限。正确的做法是：应用账号只授予DML权限，DDL由迁移工具使用独立账号执行，日常运维使用只读账号，紧急修复才使用超级用户。数据库层面的权限要细化到schema和函数，特别是SECURITY DEFINER函数，必须检查函数属主和执行权限，防止低权限用户通过函数提权。定期执行以下SQL审计高风险对象：

SELECT nspname, proname, proowner 
FROM pg_proc p JOIN pg_namespace n ON p.pronamespace = n.oid 
WHERE prosecdef = true AND nspname NOT IN ('pg_catalog', 'information_schema');

对返回结果逐一确认，非必要的SECURITY DEFINER函数应改为SECURITY INVOKER。

手工检查永远赶不上环境变化。建议把漏洞扫描接入CI/CD或定时任务，使用开源工具定期对集群执行安全基线检查，重点包括：是否暴露默认端口、是否允许弱密码认证、是否有超级用户远程登录、是否开启SSL、日志参数是否合理。扫描结果输出到工单系统，按风险等级限期修复。对于容器化部署的PostgreSQL，还要检查镜像来源和启动参数，避免使用latest标签，固定镜像摘要。

很多人只关注数据库本身，却忘记WAL归档目录和备份文件也是敏感数据。归档目录必须限制操作系统权限，只允许postgres用户和备份工具访问。备份文件在传输和存储时要加密，使用pgBackRest或Barman等工具时开启加密选项。定期做恢复演练，验证备份可用性，同时检查备份文件是否被篡改。如果备份文件泄露，等于把整个数据库交出去，所以备份存储的访问日志要保留至少半年。

PostgreSQL默认日志记录较粗，建议调整以下参数：log_connections、log_disconnections、log_statement至少设为ddl，log_min_duration_statement设为1000或更低。对于敏感表，可以创建触发器记录变更前后的数据。日志文件本身要集中收集，限制读取权限，防止攻击者删除日志掩盖痕迹。同时配置日志轮转和保留策略，避免磁盘被占满导致数据库不可用。

很多集群前面有PgBouncer或Pgpool-II，这些组件如果配置不当，会成为新的攻击面。PgBouncer的admin用户必须设置强密码，管理端口只监听内网。连接池的日志也要开启，记录客户端来源和执行的SQL。对于高并发业务，连接池的超时参数要合理，避免慢查询占满连接导致拒绝服务。定期检查连接池版本，及时更新安全补丁。

如果使用逻辑复制，发布端和订阅端的连接同样需要SSL和强认证。逻辑复制槽如果长期不消费，会导致WAL堆积，甚至磁盘写满，这是一种隐蔽的拒绝服务风险。监控pg_replication_slots的active状态和restart_lsn推进情况。对于安装的扩展，特别是第三方扩展，要审查其来源和权限，部分扩展会创建超级用户函数或外部调用，存在提权风险。不用的扩展及时卸载。

一旦发现异常，第一时间不是重启数据库，而是保留现场：导出pg_stat_activity、pg_locks、近期日志、连接来源。对可疑会话执行pg_terminate_backend，并在pg_hba.conf中临时拒绝该来源。如果确认主节点被入侵，不要立即切换到从节点，因为从节点可能已经通过复制同步了恶意操作。应先断开复制，检查从节点数据是否被污染，再决定是否提升。日常运维中要准备一份书面的应急手册，明确每个步骤的负责人和命令。

PostgreSQL集群漏洞防护不是一次性工程，而是需要持续投入的运维能力。核心思路是：减少不必要的暴露、加密所有通信链路、按最小权限分配角色、自动化审计配置和日志、备份与恢复同样纳入安全体系。做到这些，大部分已知漏洞和常见攻击手段都能被有效阻断，剩下的就是保持对版本更新和安全公告的敏感度。