PostgreSQL的pg_stat_statements模块会记录执行过的SQL语句及其统计信息，但它默认会完整记录查询文本，包括其中嵌入的明文密码、个人身份信息（PII）、API密钥等敏感数据。这些数据会持久化存储在系统目录中，任何能访问数据库的用户（如拥有pg_read_all_stats权限的用户）都可能查询到，从而导致严重的信息泄露。要解决此问题，最直接有效的方法是启用pg_stat_statements.track_utility参数，并结合使用pg_stat_statements.track参数来控制跟踪范围，同时，必须设置pg_stat_statements.save为off以防止敏感查询被永久保存，并定期使用SELECT pg_stat_statements_reset()来清空现有记录。
pg_stat_statements模块的工作原理与风险根源
pg_stat_statements是PostgreSQL的核心扩展之一，用于追踪服务器执行的所有SQL语句的执行统计信息，如调用次数、总耗时、内存使用等，是性能调优的利器。它通过一个共享哈希表来存储这些信息，并可以通过视图pg_stat_statements进行查询。然而，其默认配置是记录所有类型的语句（包括像SET、SHOW、ALTER USER等工具语句）以及完整的、未经任何处理的查询字符串。这意味着，如果一个应用程序执行了类似ALTER USER postgres WITH PASSWORD ‘MySecretPass123’; 这样的语句，那么完整的字符串，包括明文密码’MySecretPass123’，就会被原封不动地记录在pg_stat_statements中。任何拥有该视图查询权限的数据库用户，都可以通过简单的SELECT query FROM pg_stat_statements WHERE query LIKE ‘%PASSWORD%’; 来发现这些敏感信息。
敏感信息泄露的具体场景与验证方法
泄露风险不仅存在于密码修改语句。在实际应用中，多种场景都可能意外泄露数据：
1. 应用程序在连接字符串或初始化脚本中直接使用包含密码的SQL；
2. 动态生成的查询中包含了用户输入的敏感数据，如身份证号、手机号；
3. 调用存储过程或函数时传入的敏感参数；
4. 执行COPY命令时，文件路径或内联数据可能包含机密信息。要验证你的数据库是否存在此类泄露，可以执行以下查询来审查当前记录：
SELECT
query,
calls,
total_exec_time
FROM
pg_stat_statements
WHERE
query ~* ‘(password|secret|token|credit_card|ssn|身份证)’
AND query !~* ‘/\*.*\*/’ -- 可尝试过滤掉包含注释的查询（不完全可靠）
LIMIT 20;这条查询会寻找可能包含敏感关键词的语句。但请注意，攻击者或审计者可能会使用更复杂的模式匹配或直接遍历所有记录来提取信息。
核心解决方案：配置参数调整
解决泄露问题的关键在于正确配置pg_stat_statements。主要涉及以下三个核心参数，需在postgresql.conf文件中进行设置：
1. pg_stat_statements.track：控制跟踪哪些语句。推荐设置为’top’，即只跟踪顶层语句（由客户端直接发出的语句），忽略嵌套在函数内的语句。这可以在一定程度上减少敏感信息的记录范围，但并非根本解决之道。
2. pg_stat_statements.track_utility：这是最关键的一个参数。默认值为’on’，意味着工具语句（如SET, SHOW, ALTER, CREATE USER等）会被跟踪。必须将其设置为’off’。这样，绝大多数包含密码的管理命令将不会被记录。修改后需要重启PostgreSQL服务或发送SIGHUP信号给主进程以重载配置。
3. pg_stat_statements.save：控制统计信息是否在数据库关闭时保存到磁盘，并在启动时重新加载。默认值为’on’。在安全要求极高的环境中，可考虑将其设置为’off’，这样每次数据库重启后，历史统计信息都会被清空，防止敏感信息被持久化。但请注意，这会丧失对长期性能趋势的分析能力。
# 在postgresql.conf中的推荐安全配置示例 shared_preload_libraries = ‘pg_stat_statements’ # 确保模块已预加载 pg_stat_statements.max = 10000 pg_stat_statements.track = ‘top’ pg_stat_statements.track_utility = off pg_stat_statements.save = off
主动清理与监控策略
除了配置，主动的清理和监控是必不可少的防御层。即使关闭了track_utility，某些通过常规DML语句（如INSERT INTO users VALUES (‘name’, ‘secret_token’)）泄露的数据仍可能被记录。因此，需要定期清理统计信息。使用函数pg_stat_statements_reset()可以清空整个统计信息表。可以结合PostgreSQL的pg_cron扩展或操作系统的cron定时任务来执行清理，例如每小时或在执行高风险操作后立即清理。同时，应严格管理对pg_stat_statements视图的访问权限，只授予必要的监控角色，而非所有用户。
-- 手动清理所有统计信息 SELECT pg_stat_statements_reset(); -- 创建一个仅用于监控的只读角色，并授权查询该视图 CREATE ROLE stats_viewer; GRANT pg_read_all_stats TO stats_viewer; -- 注意：pg_read_all_stats是一个强大的权限，需谨慎授予。
进阶方案：使用查询规范化（Query Normalization）或第三方工具
对于不能完全禁用跟踪，又需要深度保护的环境，可以考虑更进阶的方案。PostgreSQL社区正在讨论为pg_stat_statements引入参数化查询或模糊化（obfuscation）支持，但在当前稳定版本中尚未实现。一个可行的变通方法是，在应用程序层或数据库代理层（如PgBouncer, HAProxy）对所有SQL语句进行预处理，将敏感字面量（常量）替换为参数化占位符或通用标记（例如，将密码替换为<REDACTED>），然后再发送给数据库执行。这样，被记录的就是处理后的“安全”查询文本。此外，可以考虑使用审计扩展（如pgAudit）来替代部分监控功能，因为它提供了更精细的日志控制能力，可以配置为不记录特定语句的详细参数。
对性能分析与调试的影响及平衡之道
关闭track_utility和频繁重置统计信息，无疑会对数据库的性能分析和历史问题排查带来挑战。性能优化专家可能会失去对特定管理操作或客户端错误行为的洞察。因此，安全与可观测性之间需要取得平衡。建议的策略是：在生产环境中采用严格的安全配置（track_utility=off, 定期清理），同时建立一个独立的、配置更宽松（track_utility=on, save=on）的监控或预发环境，用于性能分析和调试。所有包含敏感信息的操作（如用户管理、密钥轮换）应严格在脚本中实现，并确保在执行这些脚本前后，重置生产环境的统计信息。
总结：构建纵深防御策略
总之，防范pg_stat_statements导致的查询文本泄露，不能依赖单一措施，而应构建一个纵深防御体系：首先，将pg_stat_statements.track_utility设置为off是最关键、最有效的一步；其次，结合定期清理和严格的权限控制；然后，在应用程序开发规范中强制要求使用参数化查询（Prepared Statements），这不仅能从根本上防止敏感数据被pg_stat_statements记录，更是防御SQL注入攻击的首要手段；最后，通过架构设计（如分离监控环境）来弥补安全配置对可观测性造成的影响。定期进行安全审计，使用本文提到的验证查询检查泄露痕迹，是确保策略有效性的必要环节。
