怎样配置PostgreSQL的pg_hba.conf增强安全性：限制特定IP的访问权限

说到数据库安全，访问控制是第一道防线。PostgreSQL的pg_hba.conf文件，正是这道防线的核心配置。它决定了“谁”能从“哪里”连接到“哪个”数据库。配置得当，能有效将风险隔绝在外；配置不当，则可能形同虚设。今天，我们就来聊聊如何精准地利用它来限制特定IP的访问，避开那些常见的“坑”。

怎么在 pg_hba.conf 里写一条只允许 192.168.1.100 访问 testdb 数据库

方法很简单，直接添加一行规则即可。但这里有个至关重要的细节——顺序。pg_hba.conf的规则是自上而下逐条匹配的，系统会采用第一条匹配成功的规则，后面的就直接忽略了。所以，务必将更精确、更严格的规则，放在那些宽松的规则（比如允许所有IP的0.0.0.0/0）之前。

具体该怎么写呢？看这个示例：

host    testdb    appuser    192.168.1.100/32    md5

我们来拆解一下：

• host：表示使用TCP/IP连接。
• testdb：目标数据库名。
• appuser：被允许连接的用户名。
• 192.168.1.100/32：这是关键，指定了允许的单个IP地址。注意，必须带上CIDR掩码/32，只写192.168.1.100会导致PostgreSQL报错。
• md5：要求密码使用MD5加密传输，这是比明文更安全的基础认证方式。

几个实用的补充点：

• 如果需要允许多个固定IP，要么重复写多行规则，要么改用CIDR网段表示法，例如192.168.1.0/24。
• 如果这个用户也可能从服务器本地的Unix Socket连接，别忘了检查local类型的规则是否也做了相应限制。
• 修改后必须执行重载配置：运行SELECT pg_reload_conf();或者使用pg_ctl reload命令，无需重启数据库服务，更改即可生效。

为什么加了限制还是能从其他 IP 连上

规则明明写了，但其他IP还是能连进来？这通常是规则未能真正生效导致的。最常见的原因有两个：一是规则位置太靠后，被前面一条宽松的规则（比如host all all 0.0.0.0/0 md5）“截胡”了；二是规则中使用了trust认证方法，这相当于跳过了密码验证，风险极高。

排查起来可以这么做：

• 在PostgreSQL 10及以上版本，直接运行SELECT * FROM pg_hba_file_rules();。这个视图能清晰展示当前已加载的所有规则及其顺序，一目了然。
• 仔细检查是否有遗漏的规则，比如用于流复制的host replication ...规则，或者IPv6的规则（如host all all ::/0）。系统可能通过你没注意到的路径连接进来。
• 立刻将生产环境中的trust方法替换掉。即使在内网，也建议使用md5或更安全的scram-sha-256加密认证。

如何限制用户只能从指定 IP 连指定数据库，且不能连其他库

这是一个更精细的需求，但需要明确：单靠pg_hba.conf无法实现“禁止连接其他数据库”。它的职责是控制连接能否建立，属于“门卫”；而用户连接后能在哪个数据库执行什么操作，是数据库内部权限体系的事，属于“房间权限”。

因此，必须组合拳出击：

1. 在pg_hba.conf中做连接准入控制：为每个数据库编写独立的规则。例如，允许用户appuser从IP192.168.1.100连接salesdb，但拒绝其连接reportdb。

   host    salesdb    appuser    192.168.1.100/32    scram-sha-256
   host    reportdb   appuser    192.168.1.100/32    reject

2. 在数据库内收回连接权限：即使pg_hba.conf允许连接，也可以在数据库层面彻底收回权限。在reportdb中执行：REVOKE CONNECT ON DATABASE reportdb FROM appuser;。这样，即使用户尝试连接，也会在认证后因权限不足而被拒绝。

注意：reject是pg_hba.conf中的一种规则动作，直接拒绝连接，它比任何认证方法（如md5）的优先级都高，并且不依赖于数据库用户是否存在。

修改后连不上，日志里出现「connection closed due to idle timeout」或「no pg_hba.conf entry」

修改配置后客户端连不上了？别慌，看日志信息对症下药。

• 「connection closed due to idle timeout」：这个错误其实和pg_hba.conf配置无关。它指的是TCP连接空闲超时，通常由操作系统或中间件的tcp_keepalives_idle等参数控制，需要检查网络环境或调整相关超时设置。
• 「no pg_hba.conf entry」：这才是典型的配置问题。PostgreSQL明确告诉你，当前连接请求（包含IP、数据库名、用户名）没有在任何一条规则中找到匹配项。

遇到后者，可以按以下步骤排查：

• 首先，去查看PostgreSQL的日志文件（路径由postgresql.conf中的log_directory和log_filename参数决定），搜索上述关键词，日志会给出被拒绝连接的详细信息。
• 其次，确保客户端连接时使用-h参数显式指定主机地址，避免其默认使用Unix Socket连接。因为Unix Socket对应pg_hba.conf中的local类型规则，与TCP/IP的host类型规则是两套体系。
• 最后，检查IP地址格式。IPv6地址必须完整书写，例如::1/128。同时注意，all关键字在混用IPv4和IPv6的环境下，并不总是同时覆盖两者，可能需要分别配置。

当然，还有一个最常被忽略的步骤：确认配置重载成功。执行了SELECT pg_reload_conf();之后，请务必确认其返回值为t（true），这才能证明重载指令被成功接收并执行。否则，你的修改可能还静静地躺在文件里，并未生效。