编者按：
2026时序数据技术创新大会， 以 ⌈ DB × AI ⌋为主题，聚焦时序数据库与 AI 技术融合，技术分论坛围绕内核研发、安全治理、落地实践等方向展开深度交流。
天谋科技数据库内核研发工程师、Apache IoTDB PMC Member 侯昊男，带来《TimechoDB 安全增强与漏洞治理实践》主题分享，围绕时序数据库安全建设的两大核心命题：如何降低安全风险发生概率、漏洞出现后如何缩短风险暴露窗口，分享 TimechoDB 2.0 的安全能力建设与漏洞闭环治理实践。
今天我给大家分享的一个主题是《TimechoDB 安全增强与漏洞治理实践》。本次分享，我主要想回答两个问题：
1.数据库产品如何通过持续增强安全能力，降低安全风险发生、被攻击成功的概率？
2.漏洞被发现之后，如何依靠一套稳定、可预测的响应机制，来缩短风险暴露的时间？
TimechoDB 始终重视产品的安全能力，已经通过国家安全可靠测评。我也借此机会，拆解 TimechoDB 2.0 在安全能力与漏洞治理上的实践。
很多人谈到数据库安全，首先想到的是账号、密码和权限。
但对一套真正运行在生产环境中的数据库来说，这些只是起点。用户如何登录、权限如何划分、数据如何传输和落盘、高权限操作是否留痕、第三方依赖出现漏洞后如何处置，任何一个环节失守，都可能让原本看似严密的安全体系出现缺口。
因此，我想先把这次分享最核心的观点放在前面：产品安全不能只是一张功能清单，而应当是一套贯穿风险发生前、发生时和发生后的安全体系。我们希望让风险可预防、可发现、可处置、可控、可追溯。
我今天想分享的内容包括三方面：
1.安全挑战
2.安全能力
3.漏洞响应机制
时序数据库面对的真实安全挑战：风险贯穿数据全生命周期
为了说明为什么单一安全功能远远不够，我沿着数据从访问到使用的全过程进行了梳理。
风险可能出现在六个位置
第一，登录入口。弱口令、密码复用和暴力破解，都可能导致账号被冒用。
第二，权限边界。用户能够登录数据库，但不代表他有权访问全部数据，所以需要对访问权限继进行限制。
第三，集群的通信链路。客户端与数据库之间、数据库节点之间都会进行数据通讯，所以需要防止通信内容被窃听或篡改。
第四，数据落盘。磁盘上的明文文件、删除后仍可恢复的数据，都可能成为泄露入口。
第五，运维操作。授权变更、数据操作和高权限命令如果没有被完整记录，出现问题后就很难回答“谁在什么时间做了什么”。
第六，组件依赖。操作系统、运行时和第三方组件的公开漏洞，可能沿着软件供应链传导至数据库产品。
这也意味着，单点防护只能解决单一风险。安全能力必须分层协同。
运行期防护和漏洞响应，也不是两套互相独立的体系。 运行期防护负责压低风险发生概率；当漏洞出现，我们要完成复现、评估、修复、版本发布。重大漏洞处理结束后，不能简单关闭工单就结束，需要回溯技术根因，把经验沉淀为新的安全能力，形成闭环迭代。
从身份鉴别到稳态治理，分层构建防护底座
围绕上述风险，我们把 TimechoDB 安全能力拆解为五层能力地图：身份鉴别、访问控制、通信保护、数据与审计、稳态治理。
2.访问控制，避免权力过度集中
传统数据库常常设置一个权限极高的管理员账号：既能创建用户、修改授权和执行系统操作，又能查看业务数据和审计配置。这种方式操作简单，却容易形成权力过度集中，一旦账号泄露或者误用，风险极高。
为此，我们落地“三权分立”机制，把全局管理职责拆分为三类互相独立、互相监督的管理员角色：
系统管理员：负责系统操作与配置，但不负责用户授权，也不能检查自己的审计记录。
安全管理员：专门负责用户、角色、授权，不承担系统运维和审计职责。
审计管理员：管理审计规则与审计日志，承担独立监督职责，不直接修改业务权限。
启用三权分立后，一个用户最多只能拥有一种全局管理权。它解决的不是普通业务用户能否读写数据的问题，而是高权限管理职责如何相互制约，从而降低误操作、权限滥用以及高权限账号失陷带来的风险。
3.身份鉴别，让账号更难被冒用
密码安全不能只看是否包含大小写字母、数字和特殊字符，还要同时考虑强度、生命周期和重复使用问题。
在 TimechoDB 中启用强密码策略后，用户可以对密码长度和字符组成提出要求；管理员可以设置密码有效期，由系统在到期前提醒，并在到期后限制登录；密码历史机制则可以阻止用户循环复用旧密码，真正降低账号失陷概率。
除此之外，用户可以在 TimechoDB 中通过 IP 黑白名单限制客户端连接，并记录最近一次成功登录的时间和来源，以及近期失败的登录尝试。这些信息既能帮助用户感知异常，也为后续审计提供依据。
4.通信保护，同时守住集群内外
TimechoDB 通信保护覆盖集群外部和集群内部两类通信链路，对外客户端连接，支持 TLS 和国密 TLCP（SM2/SM3/SM4）协议，支持双向 mTLS 认证；集群内部 ConfigNode 与 DataNode 之间通信强制双向认证，防止非可信节点接入集群，实现传输内容加密、链路身份可信、报文不可篡改。
5.数据加密与审计，既要防泄露，也要能追责
存储层面实现业务无感知的透明加密：上层业务 SQL、JDBC 访问方式完全不变；数据库内部透明加密层完成写入加密、读取解密，磁盘落盘全部为密文，读取时，数据库在内部解密后再将结果返回客户端。我们采用的 SM4-GCM 算法，可以同时保护数据的机密性与完整性。
但安全不仅要阻止问题发生，也要在问题发生后还原过程。因此，审计系统需要回答五个基本问题：谁、从哪里来、作用于什么对象、执行了什么操作、结果如何。
通过异步采集机制，把审计记录存入 TimechoDB 中，在减少关键业务路径额外负担的同时，让授权变更、高权限命令和数据操作都有迹可循。
6.稳态治理，控制资源与残余信息风险
安全问题不一定来自恶意攻击。单一账号大量创建连接，也可能耗尽连接、计算或存储资源，最终影响整个系统。因此，我们已经在 TimechoDB 中开展会话治理，通过为用户设置连接配额来限制资源消耗；针对 CPU、内存和磁盘等资源的进一步治理也在推进中。
关于残余信息保护，对标等保相关要求。删除数据如果只是在逻辑上“不可见”，底层磁盘或内存中仍可能保留可恢复的内容。
为降低这一风险，我们让 TimechoDB 可以在文件释放前，对 TsFile 等文件执行写零覆盖；内存释放时，也可以对可能被复用的缓冲区进行清零。目前该能力重点适配 Linux，同时权衡安全收益与性能开销，并以开关形式提供，用户可以结合实际场景权衡。
漏洞响应闭环：从线索接收到复盘演进，缩短风险暴露窗口
无论安全功能做得多完善，软件无法做到绝对零漏洞。一套清晰、可落地的漏洞响应机制，是安全体系必不可少的部分。
在实践中，我们主要从三个方向获取 TimechoDB 的漏洞线索：
内部：人工代码审计、自动化扫描和专项安全测试；
用户侧：用户及合作伙伴通过安全邮箱、实施和交付渠道提交的反馈；
供应链侧：持续监控第三方组件漏洞库，识别组件依赖带来的传导风险。
我们对外公开安全反馈邮箱 security@timecho.com。 如果发现安全问题，提交报告建议包含：产品版本模块、复现场景步骤、截图日志样例、影响范围与联系方式。信息越完整，复现、评估、修复就越快，邮箱同时用于后续漏洞状态同步沟通。
收到漏洞线索，不会直接打上高/低危标签，执行标准化五步流程：接收线索材料→复现验证最小触发场景→评估数据、权限影响范围→划分超危 / 高危 / 中危 / 低危等级→向报告者反馈结果。无法复现的漏洞，也会说明原因给到反馈人。
对于超危和高危问题，我们会立即启动核实，力争当天完成验证和反馈；对于中危和低危问题，则在 24 小时内启动处理。
对于漏洞修复，也不是原始 POC 不再复现就结束。如果只堵住表面入口，可能遗漏相邻攻击路径，甚至给正常业务带来副作用。因此我们需要一套完整的复测流程，来保证修复没有副作用。
完整验证流程包含：修复原始问题、验证正常业务功能、安全回归相邻入口、重新执行攻击场景并确认路径被阻断，最终形成验证报告。
完成修复后，还要结合风险和版本策略确定修复版本，发布补丁与漏洞修复通知，并通过官网发布漏洞修复通知，向相关用户同步修复结果。到这一步，我们就完成了漏洞治理真正的闭环：一次问题的修复，不仅是消除一个已知漏洞，更是降低同类问题再次发生的概率。
写在最后
时序数据库安全，不是一份功能清单，而是一套持续演进的闭环体系。 事前多层防护降低被攻击概率，事中可观测可审计，事后标准化漏洞响应缩短风险暴露时间，再将漏洞复盘沉淀成新安全能力，循环迭代，最终实现风险可预防、可发现、可处置、可追溯，为时序数据提供完整的安全底座。
