ClickHouse 动了密码的奶酪

数据库密码这个陪伴行业五十年的老物件，正在被一枚短命的小令牌悄悄替代。

2024 年 10 月，ClickHouse 在 24.10 版本发布说明中宣布引入 JWT 认证支持，ClickHouse Cloud 随之向企业版客户开放了这项能力：用户可以直接使用自己身份提供方（IdP）签发的短期令牌连接数据库，而不必再依赖长期有效的数据库密码。这条藏在月度更新列表里的发布公告，背后却是一场数据平台安全范式的大迁徙。

我的判断很直接：这不是一个功能点，而是一个信号——云数据库的竞争，正在从『算力快不快、查询强不强』转向『身份接没接、凭证干不干净』。

🔑 密码的末日，从一条发布动态开始

每个带过数据库的工程师，都经历过这样的深夜。

凌晨两点，安全团队在群里 @ 你：某台跳板机的日志里扫出了明文密码，那个密码连着生产数仓。你一边挂 VPN 一边手心冒汗——改密码？下游几十个 ETL 任务、三张 BI 看板、还有两个对外的数据服务全挂在这个账号上，改完就是一次连环故障；不改？万一这串字符已经流出了内网呢。

这不是虚构的剧情。Verizon《2024 年数据泄露调查报告（DBIR）》（基于对 10,626 起真实泄露事件的分析）显示，凭证滥用连续多年位居初始入侵手段前列，是最常见的突破口之一；而 IBM《数据泄露成本报告》（2023 年版）测算了更残酷的代价：涉及被盗凭证的泄露，平均需要 292 天才能被识别并控制——是所有初始入侵媒介中最慢的一类，泄露平均成本则高达数百万美元量级。凭证一旦泄漏，问题往往不是『改不改』，而是『什么时候被发现改晚了』。

这就是静态密码的原罪：它必须长期存在，才配得上『稳定连接』；而它存在得越久，就越像一个定时炸弹。

ClickHouse 这次发布解决的正是这个死结。根据官方发布说明与配套文档，ClickHouse 用户可以从自己的身份提供方获取短生命周期的 JWT 令牌，直接拿去连接数据库——密码不再需要被创建、被存储、被轮换、被泄漏之后被紧急修改。

一句话概括变化：凭证不再由数据库保管，而是由身份体系随时签发、随时作废。

泄漏凭证的规模问题也有据可查：GitGuardian《State of Secrets Sprawl》2024 年度报告显示，仅 2023 年一年，其在公开 GitHub 仓库中就扫描到超过 1,280 万个新泄漏的密钥，同比增长 34%。密码之于数据平台，就像钥匙挂在门上之于住户——门再厚也没用。

🧩 一枚 Token 背后的架构重构

看懂这次发布，得先看懂连接方式的变化。

过去，一个服务要连 ClickHouse Cloud，流程是：管理员在控制台创建一个数据库用户，把用户名密码塞进密钥管理或配置文件，服务启动时读出来登录。整条链路上，密码至少要在三四个地方『躺』着。

现在，流程变成了这样：

落到配置层面，这次能力包含三个关键点（具体字段以其官方文档为准，可能随版本演进调整）：

第一，服务端配置 JWKS 端点。 管理员在服务器配置中指定 IdP 的 JWKS（JSON Web Key Set）地址，数据库据此获取公钥来验签，并设置密钥的刷新周期：

`xml

https://your-idp.example.com/.well-known/jwks.json

3600

true

`

第二，用户与令牌声明的绑定。 数据库侧的用户不再绑定静态密码，而是通过声明（claim）与令牌关联——默认要求令牌的 sub 声明与数据库用户名匹配，并可通过信任声明配置限定 aud、issuer 等字段，确保只有自家 IdP、为正确受众签发的令牌才能通过。

第三，客户端携带令牌连接。 服务从 IdP 获取令牌后，以 Bearer Token 的方式随连接传入（HTTP 协议下放在 Authorization: Bearer 头中），数据库验签、核对有效期与声明后放行会话。

变化的核心在于：数据库从『凭证的保管者』退位成『凭证的验证者』。 密码的生成、分发、轮换、吊销，全部收敛到 IdP 一处。数据库只管一件事——验签、看有效期、放行。

两种模式的差异，摆在桌面上看更清楚：

尤其值得注意最后一行：审计粒度。过去团队共用一个 svc_etl 账号，出了问题只能查到『某个服务干的』；令牌与 IdP 身份绑定后，『谁在什么时候连了库、跑了什么查询』可以落到具体的人和系统上。

这正是 JWT 认证区别于『换个复杂一点的密码』的本质：它不是把锁换成更贵的锁，而是把『配钥匙』这件事，交给了一个有完整档案的第三方。

🏇 身份即边界，云数仓的新起跑线

把镜头拉远一点，这次发布是云数据平台竞争重心迁移的一个切片。而且要承认：在『凭证身份化』这条路上，ClickHouse 是追赶者，不是先行者。看看两个最主要的竞对已经走到了哪里：

Snowflake 早在 2019 年就推出了 External OAuth，支持 Okta、Microsoft Entra ID（原 Azure AD）、Ping 等外部 IdP 直接签发令牌接入；对机器负载长期提供密钥对认证，2024 年起又陆续推出了可过期、可吊销的程序化访问令牌（PAT）与工作负载身份联邦（Workload Identity Federation）预览版，让外部云厂商上的计算负载无需密钥即可接入。

BigQuery 则走得更彻底——它压根没有『数据库密码』这个东西。认证完全内建于 Google Cloud IAM：人走 OAuth，服务走 Service Account 令牌；2021 年上线的 Workload Identity Federation 更允许 AWS、Azure、Okta 等外部 IdP 的身份直接换取 BigQuery 访问凭证，全程无密钥。

按照认证方式的演进，可以粗略分成三个阶段：

• 本地部署时代：用户名密码写进连接串，安全靠内网隔离；
• 云托管时代：静态 API Key 加上轮换策略，安全靠流程纪律；
• 身份联邦时代：短期令牌由 IdP 统一签发，安全靠身份生命周期管理。

第一阶段到第二阶段，行业走了十多年；第二阶段到第三阶段，各家云数仓正在抢跑。逻辑不复杂——当数据基础设施全面上云，企业边界溶解了，远程办公、多云部署、SaaS 工具直连数仓，传统的『网络边界』已经画不出来。安全行业喊了多年的零信任，落到数据平台上的第一个抓手，就是凭证的身份化与短命化。

更重要的是一个新的变量：机器身份的爆炸。CyberArk《2023 Identity Security Threat Landscape》对约 2,400 位安全决策者的调研显示，企业内机器身份与人类身份的比例已达到约 45:1，且 68% 的受访机构计划增加对机器身份管理的投入。 过去连数据库的主要是人，现在是服务、调度器、BI 工具，以及越来越多的 AI Agent。人的数量以千计，机器身份的数量以万计，AI 应用起来之后可能以十万计。给每台机器发一个需要人工轮换的密码？在工程上根本不成立。只有『随用随签、到期即焚』的令牌模式，才能承载这个量级。

从这个坐标系看，ClickHouse 在 2024 年 10 月补上 JWT 认证，补的不只是一个功能，而是一张迟到但必须交的企业级采购答卷——当 Snowflake 和 BigQuery 的用户早已习惯『没有密码』的连接方式，凭证模式本身就成了选型评估表上会被打分的那一行。

💰 工程师的账本：成本、可靠性与落地坑

作为亲手踩过凭证管理坑的人，我对这项能力的价值判断是肯定的，但也要把账算清楚——短期令牌不是免费的午餐，它把运维复杂度从数据库侧搬到了身份侧。

收益端很好算：

• 轮换成本归零。过去每季度一轮的密码轮换，涉及几十个下游系统的同步修改，一次事故级操作的工时往往以『人日』计；令牌到期自动失效，这项开销直接消失。
• 应急响应成本骤降。泄漏处置从『全链路改密 + 灰度验证』变成『等它过期』，处置窗口从小时级压缩到分钟级。对照前文 IBM 报告里 292 天的发现周期，这个差距就是风险敞口本身。
• 入网即合规。企业 IdP 上的多因素认证、设备状态检查、条件访问策略，自动延伸到了数据库连接这一层。

但落地时，几个坑要提前踩明白：

第一，令牌有效期的取舍。 设得太短，高频调度的任务可能在长事务中途令牌过期；设得太长，又稀释了『短命』的安全红利。建议按任务的最长运行时间倒推有效期，而不是一刀切——例如夜间批处理任务给小时级，交互式查询给分钟级。

第二，签发链路的可用性成了新的单点。 IdP 挂了，数据库连不上——这要求把 IdP 自身的可用性等级纳入数据平台的 SLO 计算，主备、缓存、降级路径都要有预案。JWKS 的本地缓存与刷新周期配置，正是为此留出的缓冲空间。

第三，保留应急通道。 无论自动化做到什么程度，都应该保留一个受严格管控的本地账号，作为身份体系整体故障时的最后手段。这是可靠性工程的老规矩：任何强依赖，都要有断链方案。

第四个坑往往藏在盘点环节：旧凭证散落在 CI 变量、IaC 模板、内网文档、离职员工的个人脚本里。GitGuardian 的报告里那每年上千万级的泄漏密钥，大部分并不是被黑客『攻破』的，而是被随手提交上去的——改造的第一步不是写新代码，而是把散落在各处的旧密码找出来。这份清单本身，就是许多企业数据资产盘点缺的那一块拼图。

🚪 数据要素流通的前提，是身份可信

再往前看一步，这项能力拼接进了一个更大的图景：数据要素流通。

数据要流通，第一个绕不开的问题就是『授给谁』。过去企业对外共享数据，要么导出文件、要么开一个共享账号，凭证一出手，控制权就部分让渡了。而当连接层建立在身份联邦之上，『授权』可以变得精确而短暂：外部合作方用自己企业的 IdP 身份接入，权限随令牌签发、随项目结束失效，每一次访问都带着可验证的身份印记留在审计日志里。

这对数据交易、跨企业数据协作这类场景是打底性质的。可推演的路径很清晰：可信的身份层 → 精细的授权层 → 可审计的流通层，三层层层递进，缺了第一层，后面两层都是空中楼阁。BigQuery 的 Workload Identity Federation 已经在企业间跨云身份互信上给出了可运行的样板，Snowflake 的数据共享与 Clean Room 能力也建立在身份可核验的前提之上——身份联邦不是概念，而是竞对已经跑通的生产路径。

从合规视角看也是如此。以欧盟 GDPR、我国《数据安全法》为代表的监管框架，共同要求对数据访问做到『可追溯、可问责』。共享账号模式天然与这个要求冲突；身份化的连接，则让合规取证从『考古』变成了『查表』。

ClickHouse 这一步，单个看是产品功能补齐，连起来看，是在为数据平台在要素流通时代的角色卡位。

结语：老物件的谢幕，总是悄无声息

数据库密码不会一夜消失——存量系统、遗留工具、工程师的肌肉记忆，都会让它继续存活很多年。但方向已经没有悬念：静态长期凭证，正在成为数据平台上的技术债；身份化的短期凭证，正在成为新的默认值。

ClickHouse 在 2024 年 10 月落下的这步棋，是一份迟到的答卷，却踩在了一个大转折的节点上。对于正在建设数据平台的企业，我的建议是：现在就启动凭证清单盘点，把 IdP 集成写进下一轮平台演进的路线图。等到下一次凌晨两点的密码泄漏告警响起时，你希望手里握着的，是一枚早已过期的令牌，而不是一串还得连夜通知几十个下游系统去改的密码。