PostgreSQL日志安全：log_statement参数的风险与防护

1. 理解log_statement参数的安全隐患

数据库管理员们可能都熟悉PostgreSQL的log_statement参数，但很少有人意识到这个看似无害的配置选项可能成为系统安全的致命弱点。当我们将log_statement设置为ddl或更高级别时，实际上是在数据库日志中记录了大量敏感信息——包括那些本应保密的SQL语句。

我曾在一次安全审计中发现，某金融系统将log_statement设置为all，导致所有包含明文密码的CREATE USER语句都被完整记录在日志文件中。这些日志文件又被配置为全局可读，相当于把数据库的钥匙直接放在了公司门口。

重要提示：任何包含log_statement=ddl或更高日志级别的生产环境都应被视为存在潜在安全风险，需要立即审查。

2. log_statement参数详解与风险场景

2.1 参数级别解析

PostgreSQL的log_statement参数控制哪些SQL语句会被记录到服务器日志中，它有四个可能的取值：

• none：不记录任何语句
• ddl：记录数据定义语句（CREATE、ALTER、DROP等）
• mod：记录所有数据修改语句（包括DDL和INSERT、UPDATE等）
• all：记录所有语句（包括SELECT）

2.2 密码泄露的具体场景

当参数设置为ddl及以上级别时，以下类型的敏感信息可能被记录：

1. 用户管理语句：

sql复制CREATE ROLE admin WITH LOGIN PASSWORD 's3cr3tP@ss';
ALTER ROLE user1 WITH PASSWORD 'newPassword123';

2. 连接字符串：

sql复制CREATE SERVER foreign_server FOREIGN DATA WRAPPER postgres_fdw 
OPTIONS (host '10.0.0.1', dbname 'target_db', password 'connectPwd');

3. 加密函数调用：

sql复制SELECT crypt('myPassword', gen_salt('bf'));

我曾处理过一个案例，攻击者通过获取日志文件中的ALTER USER语句