PostgreSQL数据源认证核心是通过pg_hba.conf文件配置，主要方法包括scram-sha-256（推荐）、md5、trust（不安全）和peer/ident（本地使用），需按规则顺序精确设置用户、IP、数据库及认证方式，并结合SSL与最小权限原则确保安全。
PostgreSQL数据源的认证方式设置，核心在于通过修改其配置文件
pg_hba.conf
来定义哪些用户、从哪个IP地址范围，可以以何种认证机制连接到数据库。这就像是给你的数据库设置了一套非常精密的门禁系统，决定了谁能进来，以及他们需要出示什么样的“通行证”。
解决方案
要配置PostgreSQL的数据源认证，你主要需要找到并编辑
pg_hba.conf
文件。这个文件通常位于PostgreSQL数据目录的根下。它的每一行都代表一条认证规则，PostgreSQL会按照文件中规则的顺序，从上到下匹配连接请求，一旦匹配成功，就会采用该规则指定的认证方式。
一条典型的
pg_hba.conf
规则格式如下：
TYPE DATABASE USER ADDRESS METHOD [OPTIONS]
TYPE：连接类型，可以是
local
（Unix域套接字）、
host
（TCP/IP连接，包括SSL和非SSL）、
hostssl
（仅限SSL连接）、
hostnossl
（仅限非SSL连接）。DATABASE：目标数据库，可以是具体的数据库名，
all
（所有数据库），或
sameuser
（与连接用户名同名的数据库）。USER：目标用户，可以是具体的用户名，
all
（所有用户），或
samerole
（与连接数据库同名的角色）。ADDRESS：客户端IP地址范围，可以是具体的IP地址（如
192.168.1.100
），CIDR格式的IP段（如
192.168.1.0/24
），
all
（所有IP地址），或
0.0.0.0/0
（IPv4所有地址）/
::/0
（IPv6所有地址）。对于
local
连接，此字段通常被忽略。METHOD：认证方法，这是最关键的部分，决定了如何验证连接。常见的有：
trust
：无条件信任，不进行密码验证（极不安全，不推荐生产环境使用）。
reject
：无条件拒绝连接。
md5
：使用MD5加密的密码验证。
scram-sha-256
：使用SCRAM-SHA-256加密的密码验证（推荐，比MD5更安全）。
password
：明文密码验证（极不安全，不推荐）。
ident
：通过操作系统ident服务验证（主要用于
local
或内部受信任网络）。
peer
：通过操作系统用户验证（主要用于
local
）。
gssapi
、
ldap
、
cert
、
pam
等：企业级或高级认证方式。OPTIONS：认证方法的额外选项，例如
scram-sha-256
可以有
channel_binding=require
。
配置步骤：
定位
pg_hba.conf
文件：通常在PostgreSQL的数据目录下。你可以通过
SHOW data_directory;
命令在
psql
中查询。备份文件：在进行任何修改前，务必备份
pg_hba.conf
。编辑文件：使用文本编辑器打开
pg_hba.conf
。添加或修改规则：根据你的需求添加新的认证规则，或修改现有规则。记住，规则的顺序很重要，PostgreSQL会使用它遇到的第一个匹配规则。例如，允许来自
192.168.1.0/24
网络的所有用户通过
scram-sha-256
方式连接所有数据库：
host all all 192.168.1.0/24 scram-sha-256
允许本地
postgres
用户通过Unix域套接字连接所有数据库，并使用
peer
认证：
local all postgres peer
重新加载配置：修改
pg_hba.conf
后，你需要让PostgreSQL重新加载配置才能生效。这可以通过执行
pg_ctl reload
命令，或在
psql
中执行
SELECT pg_reload_conf();
来完成。无需重启数据库服务。
PostgreSQL数据源认证，究竟有哪些核心方法值得我们关注？
说实话，在PostgreSQL的数据源认证方法里，我们日常开发和运维最常打交道的，无外乎
md5
和
scram-sha-256
这两种密码认证方式，以及偶尔会用到的
trust
（但请务必慎用，甚至可以说，除非你非常清楚你在做什么，否则不要用它）和
peer
/
ident
（主要用于本地连接）。
我个人在项目里，如果不是特别古老的系统，基本都会力推
scram-sha-256
。为什么呢？因为它比
md5
安全得多。
md5
在密码学领域已经算是“过时”的哈希算法了，它容易受到彩虹表攻击和碰撞攻击。虽然PostgreSQL在实现
md5
时加入了一些盐值（salt）来增加破解难度，但
scram-sha-256
（Salted Challenge Response Authentication Mechanism using SHA-256）则是一种更现代、更健壮的挑战-响应认证机制。它不仅使用了更强的哈希算法SHA-256，还引入了客户端和服务器之间的多次交互，有效防御了重放攻击和中间人攻击，并且支持双向认证。
如果你连接的是内部应用或者在非常受控的网络环境，有时为了方便，或者因为应用架构的限制，可能会用到
md5
。但只要条件允许，升级到
scram-sha-256
几乎是零成本却能带来巨大安全提升的操作。对于新项目，我基本都是直接配置
scram-sha-256
，这应该是默认且推荐的选择。至于
trust
，它意味着“无条件信任任何连接”，这在生产环境里，我只能说，除非你真的想让你的数据库裸奔，否则别碰。而
peer
和
ident
，它们通过操作系统用户来认证，通常用于本地连接，比如你用
psql
连接本地数据库，或者某些特定的本地服务。它们在本地环境很方便，但不能跨网络使用。
如何安全地配置pg_hba.conf文件，避免常见的安全漏洞？
配置
pg_hba.conf
，可不是简单地把规则往里一堆就完事了，这里面有很多“坑”需要注意，不然分分钟就会给你的数据库留下一个大大的安全漏洞。
ImagetoCartoon
一款在线AI漫画家，可以将人脸转换成卡通或动漫风格的图像。
106 查看详情 
首先，规则的顺序至关重要。PostgreSQL是自上而下地匹配规则的，一旦找到第一个匹配的规则，就会立即停止并应用该规则。这意味着，你必须把最具体的、限制性最强的规则放在前面，而把最通用、限制性最弱的规则放在后面。举个例子，如果你想允许特定IP
192.168.1.10
通过
scram-sha-256
连接，而其他
192.168.1.0/24
网段的机器只能通过
md5
连接，那么
192.168.1.10
的规则必须放在
192.168.1.0/24
的规则之前。
# 正确的顺序：具体规则在前host all all 192.168.1.10/32 scram-sha-256 # 优先匹配这个特定IPhost all all 192.168.1.0/24 md5 # 再匹配整个网段# 错误的顺序：通用规则在前，特定规则永远无法匹配host all all 192.168.1.0/24 md5 # 这个规则会先被匹配，192.168.1.10也会走md5host all all 192.168.1.10/32 scram-sha-256
其次，避免使用
0.0.0.0/0
配合弱认证方法。我见过不少新手直接把
host all all 0.0.0.0/0 md5
一放了事，这简直是给黑客发邀请函。这意味着任何人都可以从任何地方，只要猜对一个MD5密码就能连接你的数据库。如果非要允许来自所有IP的连接（例如某些云环境），那么必须使用
scram-sha-256
，并且强烈建议配合SSL加密连接（
hostssl
），确保传输过程的安全性。
再者，细化访问权限。尽量不要使用
all
来指定数据库和用户。如果你的应用只需要访问特定的数据库，那就明确指定数据库名。如果某个用户只用于某个应用，那就只给那个用户权限。例如，
host myappdb appuser 192.168.1.100/32 scram-sha-256
就比
host all all 192.168.1.100/32 scram-sha-256
要安全得多。
最后，文件权限和重新加载。
pg_hba.conf
文件本身也应该有严格的权限设置，确保只有PostgreSQL的运行用户和管理员可以读取和修改。修改文件后，记住使用
pg_ctl reload
或
SELECT pg_reload_conf();
来重新加载配置，而不是重启整个数据库服务，这样可以避免服务中断。
在实际应用中，如何选择最适合的PostgreSQL认证策略？
选择PostgreSQL的认证策略，这不像点外卖，随便选个口味就好。得结合你的应用场景、安全预算和运维能力来定。没有放之四海而皆准的最佳方案，只有最适合你当前环境的。
1. 内部应用与受信任网络：如果你的应用运行在受严格控制的内部网络中，并且客户端IP地址是已知的、有限的，那么
scram-sha-256
是首选。对于一些本地服务，
peer
或
ident
认证方式可以提供无缝的单点登录体验，但要确保操作系统用户的安全性。
# 示例：允许内部应用服务器通过SCRAM-SHA-256连接host all all 192.168.10.0/24 scram-sha-256# 示例：允许本地操作系统用户连接，使用peer认证local all all peer
2. 外部应用与非受信任网络（如互联网）：这几乎是所有Web应用和云服务面临的场景。在这种情况下，
scram-sha-256
是强制性的，并且必须结合SSL/TLS加密连接。这意味着你的
pg_hba.conf
规则应该使用
hostssl
类型，并且数据库服务器需要配置SSL证书。这样可以确保密码和所有数据在传输过程中都是加密的，防止窃听和中间人攻击。
# 示例：允许来自任意IP的外部应用通过SCRAM-SHA-256和SSL连接hostssl all all 0.0.0.0/0 scram-sha-256
同时，在应用连接字符串中也要指定SSL模式，例如
sslmode=require
或
sslmode=verify-full
。
3. 遗留系统兼容性：如果你的应用非常老旧，可能只支持
md5
认证，那么你可能别无选择。在这种情况下，你需要采取额外的安全措施来弥补
md5
的弱点，比如：
将数据库服务器放在一个高度隔离的网络中。严格限制允许连接的IP地址范围。定期更换密码。尽快计划升级应用，使其支持
scram-sha-256
。
4. 企业级集中认证：对于大型企业环境，可能已经有了LDAP、Kerberos（GSSAPI）或PAM等集中认证系统。PostgreSQL支持这些认证方式，可以与企业现有的身份管理系统集成，实现统一的用户管理和认证。这能大大简化用户管理，并提高整体安全性。
# 示例：通过LDAP认证host all all 0.0.0.0/0 ldap ldapserver=your.ldap.server ldapport=389 ldapbinddn="cn=admin,dc=example,dc=com" ldapbindpasswd="password" ldapsyncdb=1
总结一下，我的建议是：优先选择
scram-sha-256
配合SSL。这是在安全性和易用性之间取得平衡的最佳实践。只有在确实无法实现或有特殊需求时，才考虑其他认证方式，并且务必对潜在的安全风险有清晰的认识和应对方案。安全，永远是数据库配置的第一要务。
以上就是PostgreSQL数据源认证方式设置_PostgreSQL数据源认证配置的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1058711.html
微信扫一扫 
支付宝扫一扫 
