PostgreSQL 远程访问配置

远程访问 PostgreSQL 很常见，也很容易配错。去年某 ERP 客户把数据库 5432 端口直接暴露公网，三天内遭遇两次勒索扫描。原则是：能连不等于该裸奔。SaaS 后端、跨境 ERP 报表库、Shopify App 业务库，只要需要远程连库，都应按同一套基线配置，而不是先通再说。开发同学习惯 localhost 直连，上线若照搬，往往忘记改 listen 和 pg_hba，留下大洞。

网络层：最小暴露面

postgresql.conf 里 listen_addresses 明确绑定内网 IP 或 localhost，禁止星号裸监听。pg_hba.conf 仅放行应用服务器网段，认证方式用 scram-sha-256，禁用 trust 和弱口令。云安全组或 iptables 只开放受信来源到 5432，DBA 运维走 VPN 或堡垒机跳转，不直接对公网开库。Docker Compose 部署时，数据库服务不要 publish 5432 到 0.0.0.0，应用容器走内部网络名连接即可。Kubernetes 场景用 ClusterIP，只有需要 DBA 运维时才临时 port-forward，用完即关。

账号与权限：业务账号不是超级用户

为每个应用建独立账号，只授予必要 schema 的增删改查。迁移用单独账号，日常业务禁止 SUPERUSER。连接串放环境变量或密钥管理服务，禁止提交到 Git。条件允许时强制 SSL，sslmode 设为 require，证书定期轮换。多租户 SaaS 可在 PostgreSQL 启用 Row Level Security，即使连接串泄露，也缩小横向移动面。只读账号给 BI 和报表，禁止 CREATE 和 DROP。定期 rotate 密码，应用侧配合连接池优雅重连，避免 midnight 硬断。

连接池与稳定性

短连接风暴是 SaaS 常见坑。应用侧用 PgBouncer 做 transaction 模式池化，Max connections 与 Postgres max_connections 对齐规划。ERP 报表类慢查询走只读副本，避免拖垮主库写入。监控连接数、锁等待和 replication lag，告警阈值比事后救火便宜得多。NestJS、Rails 等框架默认池大小往往偏大，生产环境必须压测调参。Idle 连接超时、statement_timeout 和 lock_timeout 合理设置，防止一条坏 SQL 拖死整库。

变更可审计与备份

开启 log_connections 和 DDL 审计，配合 pgAudit 记录敏感表访问。备份策略与远程访问同步设计：逻辑备份加密存储，恢复演练季度一次。变更 pg_hba 走变更单，先在 staging 验证应用连通性。把数据库暴露面收干净，跨境 ERP 和 Shopify 后端才撑得住长期运营，也才能放心把 AI 和 Webhook 高频写入压上来。常见踩坑还包括：把 postgres 超级用户写进 ORM 连接串、在 pg_hba 里对 0.0.0.0/0 放行、忘记关 Docker 暴露端口。上线前用 nmap 从公网扫一遍自己的 IP，确认 5432 不可达，比等勒索信到来更便宜。远程访问配置一次做对，后续扩容只加连接池和只读副本即可。若团队必须用 GUI 连库，统一走堡垒机上的 pgAdmin，禁止每人本地保存超级用户密码。SaaS 多租户库尤其要避免「为了方便调试临时开公网」，这类临时往往变成永久。生产库变更走 migration 工具，禁止手工连库改数据；紧急 hotfix 也要留审计记录，PostgreSQL 的 responsibility 和 SaaS 合规同样重要。Dev 与 Staging 也不要把弱口令库暴露公网，攻击扫描不区分环境；统一用与生产相同的 pg_hba 模板，只是网段更小。连接 PostgreSQL 的应用容器应通过私有网络 DNS 解析，不要把 IP 写死在代码里；迁移到云 RDS 时，安全组规则要和应用 autoscaling 组联动更新，避免扩容后新实例连不上库。定期用只读账号跑 pg_stat_activity 检视异常连接来源，是廉价又有效的安全巡检手段。远程访问不是一次性配置，应随应用扩容和人员变动定期复审。

小结

远程访问 PostgreSQL 可以方便排障，但必须默认按最小暴露面设计：网络白名单、强认证、审计日志缺一不可。开发便利不能压过数据安全。对生产库的临时开通要有工单与过期回收，避免「临时规则」变成永久后门。

实践中把上述清单变成可勾选的发布门禁，比事后补救更省时间。