分布式数据库查询引擎的认证缺陷

分布式数据库查询引擎的认证机制，在很多设计文档里被轻描淡写地归结为“建立连接时的用户名密码验证”，这种思维定式直接导致了大量数据泄露事故。实际上，查询引擎的认证缺陷往往不是密码强度不够，而是认证上下文与数据访问路径的割裂。当一个查询请求经过负载均衡、连接池复用、联邦查询转发后，最初通过认证的那个身份早已在链路中丢失，最终执行查询的节点可能根本不知道“是谁”在要数据。

绝大多数查询引擎为了性能，都会使用数据库连接池。问题在于，连接池复用的是底层TCP连接，而认证信息只在物理连接建立时校验一次。一旦连接被放回池中，下一个拿到该连接的请求可以直接使用前一个身份的高权限会话。这种缺陷在PostgreSQL的pgBouncer事务模式下尤为典型，如果应用层没有严格执行DISCARD ALL或RESET ROLE，后续查询就会带着上一个用户的角色执行。更隐蔽的情况发生在HikariCP这类客户端连接池中，当connection-init-sql配置被绕过或者抛出异常被静默吞掉时，连接就处于一种不确定的认证状态。

在Trino或Presto这类联邦查询引擎中，用户通过协调节点认证后，查询会被拆解下推到MySQL、Hive、Elasticsearch等多个数据源。默认配置下，下推查询使用的是数据源配置文件中预设的“服务账户”，而非终端用户的身份。这意味着一个只应看到脱敏数据的分析师，通过联邦查询可能直接拿到源库的完整表数据。虽然Trino支持通过impersonation传递用户身份，但绝大多数部署为了“省事”，直接使用单一高权限账号连接所有数据源。更糟糕的是，当数据源本身不支持Kerberos委托或JWT转发时，身份传递在协议层面就彻底断掉了。

很多查询引擎为了优化性能，会在解析SQL后进行重写，比如将视图展开、谓词下推、子查询扁平化。如果权限检查发生在重写之前，而重写后的查询访问了用户本无权限的底层表，就会形成权限绕过。ClickHouse的某些版本中就出现过此类问题：用户对物化视图有查询权限，但对底层源表无权限，通过巧妙地构造查询触发物化视图的实时更新逻辑，实际上读取了源表数据。Apache Calcite作为查询优化框架，其权限拦截器如果只挂在根节点而不遍历重写后的关系表达式树，同样会漏掉对中间表的鉴权。

查询引擎的中间结果集、物化缓存、临时表空间是认证控制的盲区。在Greenplum或Apache HAWQ这类MPP引擎中，查询执行时会在Segment节点上创建临时表，这些临时表的文件系统权限通常是数据库进程用户，而非终端用户。这意味着任何能够登录到该物理节点的操作系统用户，都可以直接读取临时文件中的查询结果。同样，Redis作为查询缓存层时，如果缓存键设计不当（比如仅用SQL模板哈希，不加用户ID前缀），不同用户会命中同一份缓存结果，完全绕过了行级安全策略。

MySQL 8.0引入了caching_sha2_password作为默认认证插件，但为了兼容旧客户端，服务器端通常保留了mysql_native_password的回退支持。攻击者可以通过中间人方式强制降级到旧认证协议，利用其已知的弱点进行暴力破解或重放攻击。MongoDB的SCRAM认证同样存在类似问题，当客户端声明只支持MONGODB-CR这种已废弃的旧机制时，部分配置不当的节点会选择兼容而非拒绝。更隐蔽的是LDAP/AD集成认证中的注入缺陷：查询引擎将用户输入的用户名直接拼接到LDAP查询过滤器中，攻击者可以通过构造特殊的用户名实现LDAP注入，绕过密码验证直接绑定成功。

分布式查询引擎通常暴露HTTP API用于提交查询、获取执行状态、取消任务等。这些API的认证往往与主数据库认证体系脱节。Presto的协调节点API默认监听在8080端口，/v1/query端点可以提交任意SQL，而/v1/query/{queryId}可以查看任何用户提交的查询详情和结果预览。很多生产环境只在前端加了一层Nginx反向代理，但内部微服务之间的调用完全走HTTP明文，不携带任何认证令牌。一旦攻击者进入了内网，这些API就是完全不设防的数据出口。

现代查询引擎开始支持JWT或OAuth2.0进行认证，但实现细节中充满陷阱。一个常见问题是JWT的签名验证算法被设置为"none"时，部分库会默认接受无签名的令牌。另一个问题是audience和issuer校验被忽略，导致为一个系统签发的JWT可以被另一个系统直接使用。在Apache Druid中，如果配置了基于JWT的认证但未正确设置druid.auth.authenticator.basic.authorizerName与授权器的映射关系，认证通过后用户会获得一个空角色，而空角色在某些默认策略下反而拥有对所有数据源的读取权限。

查询引擎的审计日志通常会记录原始SQL、查询来源IP、执行时间等，但很多系统会错误地将认证过程中的密码、Token、Cookie也写入日志。Elasticsearch的慢查询日志在某些配置下会记录完整的HTTP请求体，其中包含Authorization头部的Bearer Token。ClickHouse的query_log表默认会记录所有查询，如果应用程序将敏感凭证拼在SQL注释中传递参数，这些凭证就会明文落盘。更严重的是，部分查询引擎的Web UI在报错页面会直接回显请求头信息，攻击者可以通过诱导管理员访问恶意链接来窃取其认证凭证。

针对连接池身份混淆，必须在每次从连接池获取连接时执行RESET ROLE和RESET SESSION AUTHORIZATION，或者使用支持会话级连接池的中间件，如pgBouncer的session模式。HikariCP应配置connection-test-query为SELECT 1并确保其执行成功才交付连接。对于联邦查询的身份传递，必须启用Trino的impersonation机制，并在数据源端配置Kerberos约束委派，确保下推查询以终端用户身份执行。如果数据源不支持身份传递，至少应在联邦层通过行级过滤或视图封装来模拟权限隔离。

查询重写阶段的权限控制，需要将鉴权逻辑嵌入优化器的规则执行之后。具体做法是在Calcite的HepPlanner或VolcanoPlanner执行完所有规则后，遍历最终的RelNode树，对每个TableScan节点进行权限校验。对于物化视图的权限绕过，必须在视图展开后重新检查底层表权限，而非仅检查视图本身的权限。临时表的安全问题可以通过设置临时表空间的文件系统ACL来解决，或者强制所有临时数据写入加密卷。缓存层的隔离，必须在缓存键中加入用户身份哈希和权限版本号，确保权限变更后旧缓存自动失效。

认证协议的降级攻击防御，需要在服务器端明确禁用旧版认证插件。MySQL可设置authentication_policy=caching_sha2_password,，拒绝任何降级请求。MongoDB应在启动参数中设置authenticationMechanisms=SCRAM-SHA-256，移除对旧机制的兼容。LDAP注入的防护，必须对用户名中的特殊字符进行转义，使用参数化LDAP查询而非字符串拼接。内部API的认证，应统一接入OAuth2.0的Client Credentials流程，服务间调用携带机器身份令牌，并在API网关上执行强制验证。JWT验证必须显式指定允许的算法列表，禁止"none"算法，并严格校验iss和aud声明。

# Trino 配置示例：启用身份模拟并限制可模拟用户
# config.properties
http-server.authentication.type=PASSWORD
http-server.authentication.allow-insecure-over-http=false

# password-authenticator.properties
password-authenticator.name=ldap
ldap.url=ldaps://ldap.example.com:636
ldap.user-bind-pattern=uid=${USER},ou=people,dc=example,dc=com

# 数据源配置中启用身份传递
# hive.properties
connector.name=hive-hadoop2
hive.metastore.uri=thrift://metastore:9083
hive.metastore.impersonation-enabled=true
hive.hdfs.impersonation-enabled=true

# PostgreSQL 连接池安全配置示例
# pgBouncer.ini
[databases]
mydb = host=127.0.0.1 port=5432 dbname=mydb

[pgbouncer]
pool_mode = session
server_reset_query = DISCARD ALL
server_reset_query_always = 1
ignore_startup_parameters = extra_float_digits

审计日志的凭证泄露问题，需要在日志输出层实现敏感信息脱敏。可以在查询引擎的日志配置中增加正则过滤规则，将Authorization、Cookie、Set-Cookie等头部值替换为[REDACTED]。ClickHouse的query_log可以通过设置log_queries=1但配合query_log_profiles设置来限制记录内容。更彻底的方案是在网关层就剥离认证头，查询引擎只接收网关转发的内部身份标识，这样即使日志泄露也不包含原始凭证。最终，所有查询引擎的认证缺陷都可以归结为一个根本问题：认证不是一次性的门禁检查，而应该贯穿查询执行的全生命周期，从SQL解析、优化重写、数据读取到结果返回，每一步都需要知道“谁在请求”，并根据这个身份做出最小权限的访问决策。