PostgreSQL安全权限体系详解（第二期）：端到端加密传输与强认证体系
引言
在上一期文章中，我们系统梳理了PostgreSQL的角色、权限体系与最小权限原则，完成了安全体系的第一层——基础访问控制的构建。然而，仅有访问控制还远远不够——当数据在客户端与服务器之间传输时，如果缺乏加密保护，用户名、密码乃至敏感业务数据都可能暴露在网络中，面临中间人攻击、流量嗅探等严重风险。
本期作为系列第二期，我们将聚焦于 认证与传输安全，涵盖从客户端连接到服务器身份验证的全链路保障。这是任何生产级数据库安全体系的“第一道大门”，也是合规审计的重点关注领域。
系列回顾与预告：
- 第一期：角色与权限体系、最小权限原则、权限管理最佳实践 ✅
- ****第二期（本期）：认证方式配置（pg_hba.conf详解）、SSL/TLS加密传输
- 第三期：行级安全（RLS）深度实践、多租户数据隔离
- 第四期：审计日志（pgAudit）、备份加密、透明数据加密（TDE）
- 第五期：综合场景实战（多租户SaaS、金融系统、企业内网完整安全方案）
本文将以 “加密传输”和“强身份认证” 两条主线展开，从原理到实操，帮助读者构建一个既符合安全合规要求、又经得起实战检验的数据库连接安全体系。
一、认证体系全景：从连接到授权的完整链路
在深入具体配置之前，我们首先需要理解PostgreSQL管理客户端连接的完整链路。这条链路可以分为四个关键环节，任何一个环节的薄弱都可能导致安全隐患：
1.1 认证链路的四个关键环节
第一环：网络监听配置（postgresql.conf）
listen_addresses 参数决定PostgreSQL监听哪些网络接口。默认值为 localhost（只监听本地），这是安全的选择。生产环境务必避免使用 '*' 暴露到公网，除非使用了防火墙和SSL双重保护。
-- postgresql.conf
listen_addresses = '192.168.1.100' -- 只监听特定内网IP
port = 5432
第二环：认证规则文件（pg_hba.conf）
这是客户端接入认证的“总开关”，控制允许哪些IP、以什么身份、用什么认证方法连接。每一行记录对应一条认证规则，规则之间按顺序匹配，首条匹配的规则生效。
第三环：密码存储加密（pg_authid系统表）
用户的密码哈希存储在 pg_authid.rolpassword 中，当前推荐使用SCRAM-SHA-256哈希算法。加密算法的选择至关重要——弱算法（如MD5）在今天的计算能力下已被证明是可破解的。
第四环：用户角色权限（已在第一期详述）
认证通过后的操作权限由角色和权限体系控制，形成纵深防御。
1.2 认证方法全景对比
PostgreSQL支持多种认证方法，从完全不设防的 trust 到高度安全的 cert（客户端证书认证），安全强度差异巨大：
| 认证方法 | 安全级别 | 适用场景 | 说明 |
|---|---|---|---|
trust | ❌ 极低 | 仅限本地管理维护 | 无条件允许连接，仅适用于 localhost 且要求底层网络完全可信及操作系统账号严格控制 |
peer | ⚠️ 低 | 本地连接 | 通过操作系统用户匹配验证，安全性依赖操作系统身份验证，仅适用于local连接 |
password | ❌ 极低 | 不推荐 | 明文密码传输，立即被网络嗅探窃听，禁止使用 |
md5 | ⚠️ 中低（已过时） | 兼容老旧系统 | 哈希算法已被证明存在碰撞风险，且密码哈希在网络中传输可被捕获，逐步淘汰 |
scram-sha-256 | ✅ 高 | 推荐生产环境 | 行业标准强认证算法，密码哈希在网络中传输，并提供更强的抗破解能力 |
ldap / radius | ✅ 高 | 企业统一认证 | 对接企业已有身份目录，集中管理账号 |
cert | ✅ 极高 | 高安全等级金融/政务系统 | 双向证书认证，客户端也需持有CA签发的证书 |
gss / sspi | ✅ 高 | Windows/Kerberos环境 | 使用Kerberos票据认证，适合内网统一身份认证 |
核心建议：生产环境统一使用 scram-sha-256 作为密码认证方法，高敏感场景叠加 cert（客户端证书认证） 实现双因子认证。
二、pg_hba.conf：认证规则的“控制中枢”
pg_hba.conf（Host-Based Authentication）是PostgreSQL客户端接入认证的核心配置文件，通常位于数据目录（如 /var/lib/pgsql/data/ 或 /etc/postgresql/xx/main/）下。任何对该文件的修改都需要执行 pg_ctl reload 或 SELECT pg_reload_conf() 才能生效，且修改前建议先用 pg_hba.conf 的完整备份或版本控制记录变更，便于回滚与审计。
2.1 规则格式精要
# TYPE DATABASE USER ADDRESS METHOD [OPTIONS]
2.2 详细字段一表速查
| 字段 | 含义 | 常用取值与示例 |
|---|---|---|
TYPE | 连接类型 | local（Unix域套接字）、host（TCP/IP，加密或非加密均可）、hostssl（强制SSL加密）、hostnossl（禁用SSL） |
DATABASE | 目标数据库 | 数据库名、all、replication。使用 all 时需谨慎，会匹配所有数据库包括 postgres、template0、template1 |
USER | 目标用户 | 用户名、all、+组名（组内所有用户）。注意 +组名 匹配的是角色成员关系（PostgreSQL的ROLE继承体系） |
ADDRESS | 来源地址 | IPv4（192.168.1.0/24）、IPv6、samehost、samenet。建议使用最严格的CIDR表示法，避免使用整个 /0 或 ::/0 开放互联网访问 |
METHOD | 认证方法 | 见上节表格。推荐 scram-sha-256，高安全场景使用 cert |
OPTIONS | 可选参数 | 如 clientcert=verify-full、map=mapname。clientcert 可配合 scram-sha-256 实现“密码+证书”双因子验证 |
2.3 安全配置模板：生产环境强制加密配置
以下是一套生产环境推荐的安全配置模板，遵循 “最小暴露面、强制加密、强认证” 原则：
# TYPE DATABASE USER ADDRESS METHOD
# 1. 本地管理通道（仅限超级用户）
local all postgres scram-sha-256
local all all reject
# 2. 强制SSL加密的远程连接（对接标准应用账号）
hostssl app_db app_user 192.168.10.0/24 scram-sha-256
# 3. 只读副本的复制连接（必须走SSL）
hostssl replication replica_user 192.168.20.0/24 scram-sha-256
# 4. DBA安全通道（IP最严格限制+证书认证）
hostssl all dba_user 10.88.88.88/32 cert
# 5. 明确拒绝所有未匹配连接（安全兜底）
host all all 0.0.0.0/0 reject
host all all ::/0 reject
⚠️ 重要提醒：上述配置仅为示例。
ADDRESS段的IP网段必须按实际网络环境替换，确保不会因为网段过大而引入风险；reject兜底规则只匹配明确host的连接，不会影响之前已匹配的hostssl规则。
2.4 生产环境安全规则书写要点
- 禁用超级用户远程访问：生产环境禁止配置
hostssl ... postgres ...规则。超级用户应仅限本地管理，日常运维使用专用dba_user角色。 - 最小化暴露面：
ADDRESS字段尽可能细化到具体IP或最小CIDR网段。即使内网环境，也应按业务模块划分独立网段。 - 强制加密：远程连接统一使用
hostssl，确保传输层加密。如果存在遗留系统必须允许非SSL连接，应另行规划隔离网络环境。 - 规则顺序有讲究：pg_hba.conf 按顺序逐条匹配，首次匹配即生效。因此最严格的规则应放在文件前面，通用规则放在后面，
reject规则作为兜底放在最后。 - 配置变更后重载验证：修改完配置文件，执行
SELECT pg_reload_conf();或系统命令pg_ctl reload使配置生效，然后通过psql从各IP测试认证是否按预期工作，避免生产故障。
2.5 认证常见故障排查
| 错误信息 | 原因 | 解决方案 |
|---|---|---|
FATAL: no pg_hba.conf entry for host "x.x.x.x" | 没有匹配的认证规则 | 检查ADDRESS是否覆盖了客户端IP，确认规则顺序未被过早匹配，使用psql -h <client_ip> 在服务器端本地测试参数 |
FATAL: password authentication failed for user "xxx" | 密码错误或认证方法不一致 | 确认密码正确，检查数据库中的密码哈希算法（SELECT rolpassword FROM pg_authid WHERE rolname='xxx';）与pg_hba.conf中的METHOD是否兼容 |
FATAL: connection requires a valid client certificate | SSL证书认证失败 | 检查客户端证书文件路径和权限，确认pg_hba.conf中使用cert方法且服务器配置了正确的CA证书 |
FATAL: no SSL connections allowed | 客户端未使用SSL但服务器要求SSL | 修改客户端连接字符串添加sslmode=require，或在pg_hba.conf中将hostssl改为host（不推荐） |
FATAL: database "xxx" does not exist | 数据库名拼写错误 | 检查DATABASE字段配置，确认目标数据库已创建 |
FATAL: role "xxx" does not exist | 用户角色不存在 | 先创建对应的LOGIN ROLE，或检查USER字段写法 |
三、SSL/TLS 加密传输：从原理到生产实践
仅依靠认证规则不足以保障传输安全——密码和认证信息在网络中仍然是明文传输的（即使使用scram-sha-256，密码哈希在网络中传输虽然无法直接还原原始密码，但仍存在哈希被捕获用于重放攻击的风险，因此必须结合SSL/TLS实现链路层加密）。SSL/TLS加密正是在客户端与服务器之间建立安全隧道，保护整个通信链路。
3.1 SSL/TLS与连接类型的矩阵对应
| 连接类型 | 加密状态 | 适用场景 |
|---|---|---|
local | Unix域套接字（不经过网络，无需SSL） | 本地管理工具、运维脚本、备份脚本等。虽然不走网络，仍需通过文件系统权限控制访问 |
hostnossl | 明文TCP/IP | 仅限完全隔离的信任网络或测试环境 |
host | 可为明文或SSL（根据客户端选择协商） | 过渡环境，不推荐生产使用 |
hostssl | 强制SSL加密 | 所有生产远程连接推荐标准 |
3.2 SSL/TLS配置全景图
服务器端启用SSL（postgresql.conf）：
ssl = on -- 开启SSL
ssl_cert_file = 'server.crt' -- 服务器证书
ssl_key_file = 'server.key' -- 服务器私钥（权限600）
ssl_ca_file = 'ca.crt' -- 根证书（用于验证客户端证书）
ssl_crl_file = 'crl.pem' -- 证书吊销列表（可选）
ssl_min_protocol_version = 'TLSv1.2' -- 最低TLS版本，当前标准TLSv1.2/1.3；TLSv1.0/1.1已被证明存在漏洞，不应在生产使用
ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' -- 加密套件
客户端连接配置（sslmode关键参数）：
| sslmode | 加密 | 证书验证 | 适用场景 |
|---|---|---|---|
disable | ❌ | ❌ | 仅测试环境 |
allow | 可能 | ❌ | 不推荐 |
prefer | 优先 | ❌ | 有旧版客户端的环境 |
require | ✅ | ❌ | 仅防窥探，无防中间人能力 |
verify-ca | ✅ | ✅（验证CA） | 内部服务间调用 （推荐最低标准） |
verify-full | ✅ | ✅（CA+主机名） | 金融/监管/合规场景强制要求 |
核心建议：生产环境客户端至少配置 sslmode=verify-ca，高安全等级业务强制要求 verify-full 并对主机名进行校验。如果必须在公网暴露PostgreSQL端口，务必配置verify-full 并严格限制IP访问。
3.3 完整七步配置指南
以下是从零开始配置SSL/TLS加密的完整流程。
第一步：确认OpenSSL环境
openssl version
# 建议使用 OpenSSL 1.1.1 或更高版本，以支持 TLSv1.3
第二步：生成自签名CA证书（仅测试环境）
# 生成CA私钥
openssl genrsa -out ca.key 4096
# 生成CA根证书
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \
-out ca.crt -subj "/C=CN/ST=Beijing/L=Beijing/O=MyOrg/CN=MyOrg Root CA"
第三步：生成服务器证书
# 生成服务器私钥
openssl genrsa -out server.key 2048
# 生成证书签名请求（CN必须是服务器域名或IP）
openssl req -new -key server.key -out server.csr \
-subj "/C=CN/ST=Beijing/L=Beijing/O=MyOrg/CN=db.example.com"
# 使用CA签名（配置subjectAltName扩展支持多域名）
cat > server-ext.cnf << EOF
subjectAltName = DNS:db.example.com,DNS:db.internal.com,IP:192.168.1.100
EOF
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out server.crt -days 365 -sha256 \
-extfile server-ext.cnf -extensions subjectAltName
# 设置正确权限
chmod 600 server.key
第四步：配置postgresql.conf
ssl = on
ssl_cert_file = 'server.crt' -- 放置于数据目录，如 '/var/lib/pgsql/data/'
ssl_key_file = 'server.key' -- 同上目录
ssl_ca_file = 'ca.crt' -- 如果需要客户端证书验证
ssl_min_protocol_version = 'TLSv1.2'
ssl_ciphers = 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384'
第五步：配置pg_hba.conf强制SSL
hostssl all all 192.168.0.0/16 scram-sha-256
第六步：重载配置并验证
SELECT pg_reload_conf();
-- 查看SSL是否启用
SHOW ssl;
-- 查看当前连接的加密状态
SELECT pid, usename, application_name, client_addr, ssl, ssl_version, ssl_cipher
FROM pg_stat_ssl
JOIN pg_stat_activity USING (pid);
第七步：客户端配置示例
# psql命令行
psql "host=db.example.com port=5432 dbname=mydb user=app_user \
sslmode=verify-full sslrootcert=ca.crt"
# JDBC URL
jdbc:postgresql://db.example.com:5432/mydb?ssl=true&sslmode=verify-full&sslrootcert=ca.crt
# Python (psycopg2)
conn = psycopg2.connect(
host="db.example.com",
sslmode="verify-full",
sslrootcert="ca.crt"
)
3.4 证书续期与轮换流程
证书过期是生产环境中常见的问题，建议建立以下自动化流程：
- 监控告警：通过监控系统（Prometheus、Zabbix等）定期检查证书有效期，在过期前30天、15天、7天分级告警。
- 生成新证书：在CA环境下生成新证书，确保新旧证书有重叠有效期（至少15天）。
- 滚动替换：
- 将新证书（server_new.crt）和私钥传输到数据库服务器，放置于数据目录。
- 修改postgresql.conf中的证书相关路径指向新文件。
- 执行
SELECT pg_reload_conf();使配置生效（无需重启数据库）。 - 验证新连接使用新证书后，保留旧证书至少一个监控周期作为回退。
- 撤销旧证书：将旧证书加入到
ssl_crl_file对应的吊销列表中，强制客户端更新。
3.5 云数据库SSL配置差异
各大云厂商对SSL的支持有所不同，需特别关注：
| 云厂商 | SSL默认状态 | 证书来源 | 特殊说明 |
|---|---|---|---|
| 阿里云RDS | 可选开启 | 云端证书（可下载） | 提供CA证书下载，需配置sslmode=verify-ca |
| 华为云RDS | 默认开启 | 内置证书 | 服务端默认开启SSL加密，加密取决于客户端SSL配置 |
| Azure Database | 强制开启 | 内置CA | 默认强制TLS 1.2/1.3，拒绝TLS 1.0/1.1 |
| AWS RDS | 可选开启 | rds-ca-rsa2048-g1等 | 提供多种CA证书选项，支持证书轮换 |
云环境核心原则：使用云厂商提供的CA证书配置 sslmode=verify-ca 或 verify-full，并将证书随应用代码纳入版本管理。
四、高级认证：证书双向认证（cert）
对于金融系统、政务平台等 高安全等级场景，单纯的密码认证可能不足以满足合规要求。cert 方法利用TLS协议的客户端证书特性，实现“你有证书才准入”的强身份认证。
4.1 cert认证工作原理
客户端 服务器
| |
|--- 建立TLS连接 ------------->|
| |
|--- 发送客户端证书 ---------->|
| |--- 使用CA证书验证客户端证书
| |--- 检查证书中的CN与请求的数据库用户匹配
| |--- 返回认证结果
|<--- 认证通过/失败 -----------|
4.2 完整配置流程
服务器端配置：
-- postgresql.conf
ssl = on
ssl_cert_file = 'server.crt'
ssl_key_file = 'server.key'
ssl_ca_file = 'ca.crt' -- 必须配置，用于验证客户端证书
-- pg_hba.conf（明确要求cert认证，并映射证书CN到数据库用户）
hostssl all all 192.168.0.0/16 cert
hostssl all all 192.168.0.0/16 cert clientcert=verify-full
客户端证书生成：
# 生成客户端私钥
openssl genrsa -out client.key 2048
# 生成客户端证书签名请求（CN必须与数据库用户名一致）
openssl req -new -key client.key -out client.csr \
-subj "/C=CN/ST=Beijing/L=Beijing/O=MyOrg/CN=app_user"
# 使用CA签名（与服务器相同的CA）
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out client.crt -days 365 -sha256
客户端连接配置：
psql "host=db.example.com port=5432 dbname=mydb user=app_user \
sslmode=verify-full sslrootcert=ca.crt \
sslcert=client.crt sslkey=client.key"
4.3 cert + 密码双因子认证
对于极高安全场景，可以同时要求证书认证 和 密码认证，实现双因子验证：
hostssl all all 192.168.0.0/16 scram-sha-256 clientcert=verify-full
此时，客户端必须同时提供有效的客户端证书和正确的数据库密码才能登录，安全性达到金融级标准。
五、密码加密算法深度解析
5.1 为什么必须淘汰MD5？
MD5在设计时并非为密码存储而优化，在现代计算能力下已可以被高效攻击。PostgreSQL中的MD5认证机制其实传递的是“salt+hash over the network”，攻击者即使捕获通信包也能通过线下彩虹表或暴力破解尝试还原密码。相比之下，SCRAM-SHA-256通过迭代哈希计算（默认4096次）和随机盐机制，大幅提升了破解难度。
5.2 迁移到SCRAM-SHA-256的完整路径
步骤一：修改密码加密算法配置
-- postgresql.conf
password_encryption = 'scram-sha-256'
-- 重载配置
SELECT pg_reload_conf();
步骤二：为所有用户重置密码（使新加密算法生效）
ALTER USER app_user PASSWORD 'new_strong_password';
-- 或保留原密码但重设加密方式（密码本身不变）
ALTER USER app_user PASSWORD 'existing_password';
步骤三：检查密码加密状态
SELECT rolname, rolpassword
FROM pg_authid
WHERE rolpassword LIKE 'SCRAM-SHA-256%'
OR rolpassword LIKE 'md5%';
-- 确保所有业务账号均显示为 SCRAM-SHA-256
步骤四：更新pg_hba.conf中的认证方法
# 替换原有的 md5 为 scram-sha-256
hostssl app_db app_user 192.168.0.0/16 scram-sha-256
步骤五：灰度验证与回退方案
在生产环境中，可通过以下方式实现平滑迁移：
- 在pg_hba.conf中为同一用户同时保留两条规则（先
scram-sha-256后md5），支持新旧客户端共存。 - 观察日志确认所有客户端成功切换到SCRAM后，再移除md5规则。
- 为关键业务准备快速回退方案（恢复pg_hba.conf备份并重载）。
六、安全验证与监控
6.1 自动化安全配置检查脚本
将以下检查集成到CI/CD或定期巡检中：
-- 1. 验证所有远程连接强制使用SSL
SELECT EXISTS (
SELECT 1 FROM pg_hba_file_rules
WHERE type IN ('host', 'hostnossl')
AND auth_method NOT IN ('reject', 'trust')
);
-- 期望返回 false（无未加密的非拒绝规则）
-- 2. 检查是否存在弱认证方法
SELECT type, database, user_name, address, auth_method
FROM pg_hba_file_rules
WHERE auth_method IN ('trust', 'password', 'md5');
-- 期望为空
-- 3. 检查SSL配置状态
SHOW ssl; -- 应为 on
SHOW ssl_min_protocol_version; -- 应为 TLSv1.2 或更高
-- 4. 检查当前连接的加密情况
SELECT ssl, count(*)
FROM pg_stat_ssl
JOIN pg_stat_activity USING (pid)
WHERE backend_type = 'client backend'
GROUP BY ssl;
-- 期望非SSL连接为0
6.2 典型不安全配置清单（禁止项）
| 配置项 | 不安全示例 | 改为 |
|---|---|---|
| 信任认证 | host all all 0.0.0.0/0 trust | 删除该规则，改用scram-sha-256或cert |
| 明文密码 | host all all 0.0.0.0/0 password | 使用scram-sha-256 |
| 过时TLS | ssl_min_protocol_version = 'TLSv1' | 升级到TLSv1.2及以上 |
| MD5密码 | password_encryption = md5 | 改为scram-sha-256 |
| 超级用户远程 | hostssl all postgres 0.0.0.0/0 scram-sha-256 | 删除该规则，优先使用角色继承 |
| SSL关闭 | ssl = off | 改为ssl = on并配置证书 |
6.3 安全事件响应流程
当检测到认证异常或可疑连接时，建议建立以下标准响应流程：
- 快速定位：通过PostgreSQL日志（配置了
log_connections=on）定位来源IP、用户名和时间。 - 遏制措施：在pg_hba.conf中临时添加拒绝规则（
host all all <malicious_ip>/32 reject），执行pg_reload_conf()阻断。 - 分析取证：检查
pg_stat_ssl确认可疑连接是否使用了加密，分析pg_stat_activity中的查询历史。 - 修复加固：根据根本原因强化认证配置，轮换受影响账号的密码或证书。
- 复盘优化：更新安全配置检查清单，完善监控告警规则。
七、最佳实践汇总
7.1 认证配置黄金法则
- 强制加密不可妥协：所有远程连接必须同时满足三个条件：
hostssl+sslmode=verify-ca+ssl_min_protocol_version = TLSv1.2 - 淘汰弱认证方法：
trust、password、md5禁止在生产环境使用 - 密码算法升级到SCRAM：
password_encryption = scram-sha-256 - 最小暴露面原则：
listen_addresses限定最小范围，ADDRESS精确到最少CIDR，禁止超级用户远程连接 - 自动化配置检查：将6.1节中的检查脚本纳入CMDB或安全基线系统，确保配置偏离时及时告警
7.2 配置检查清单
| 检查项 | 验证方法 | 健康标准 |
|---|---|---|
| 密码加密算法 | SHOW password_encryption; | scram-sha-256 |
| SSL是否启用 | SHOW ssl; | on |
| 最低TLS版本 | SHOW ssl_min_protocol_version; | TLSv1.2 或更高 |
| pg_hba.conf禁止trust | SELECT ... WHERE auth_method='trust'; | 返回空 |
| pg_hba.conf禁止md5 | SELECT ... WHERE auth_method='md5'; | 返回空 |
| 远程超级用户 | 检查pg_hba.conf中USER postgres的远程规则 | 不允许存在 |
| 证书有效期 | openssl x509 -in server.crt -noout -dates | 距离过期>30天 |
7.3 常见陷阱与避坑指南
| 陷阱 | 后果 | 解决方案 |
|---|---|---|
| SSL证书使用IP地址作为CN，生产环境通过域名访问 | 主机名校验失败 | 证书CN使用域名，同时在subjectAltName中包含IP地址 |
| 私钥文件权限过大（如644） | PostgreSQL拒绝启动 | chmod 600 server.key |
仅配置hostssl规则但未开启SSL | 客户端无法连接 | 确保postgresql.conf中ssl=on并配置证书 |
客户端使用sslmode=require | 易受中间人攻击 | 强制使用verify-ca或verify-full |
| 服务端更换证书后客户端缓存旧证书 | 连接失败或安全降级 | 同步更新客户端的sslrootcert，并在变更窗口进行验证 |
八、总结与下期预告
本期作为系列第二期，深入解析了PostgreSQL认证体系和SSL/TLS加密传输的两大核心主题。至此，我们已具备构建 “强身份认证 + 加密传输” 的基础安全能力。
然而，仅靠连接安全和基础权限控制，仍然无法解决 多租户数据隔离 这一典型业务挑战。在第三期中，我们将揭开PostgreSQL最为强大的安全特性之一——行级安全（Row Level Security，RLS） 的深层奥秘，学会如何在数据库内核层面实现行级数据隔离，让每个租户只能看到自己的数据，再也不用担心WHERE条件被恶意篡改。
参考文献
- PostgreSQL全球开发组，"18.9. 使用SSL安全地进行TCP/IP连接", PostgreSQL官方文档（中文版）, 2025. [1†L4-L7]
- PostgreSQL全球开发组，"20.1. The pg_hba.conf File", PostgreSQL官方文档, 2026. [0†L14-L18]
- 华为云，"RDS for PostgreSQL安全最佳实践", 华为云帮助文档, 2026. [3†L27-L30]
- 阿里云，"使用云端证书快速开启SSL加密", 阿里云帮助文档, 2025. [1†L28-L30]
- Microsoft Azure，"配置TLS连接到Azure Database for PostgreSQL", Azure文档, 2026. [3†L17-L20]
- 华为云，"修改PostgreSQL配置文件以确保数据安全", 华为云开发者社区, 2025. [0†L37-L39]
- 百度云，"PostgreSql连接权限管理：从基础到进阶的全面指南", 百度云开发者社区, 2025. [4†L7-L10]
- Percona，"Best practices for securing PostgreSQL in hybrid environments", Percona博客, 2025. [4†L23-L27]
- 阿里云，"Configure a client CA certificate", 阿里云帮助文档, 2026. [5†L9-L14]
- Kaspersky，"情景：验证PostgreSQL服务器", Kaspersky企业文档, 2026. [5†L39-L42]
