一个问题：明文报警记录，谁能改、怎么防
某城燃集团 18 座门站/分输站的 SCADA 数据统一汇入集团监测数据库，一次内部安全检查发现：泄漏报警记录是明文存的——任何一个能连上数据库的人都能直接查看，甚至改掉一条报警记录。
检查结论写得很克制：报警记录缺少完整性保护，存在被静默篡改后无法追溯的风险。
这个问题本质上是存储层的信任问题：不是"谁有权限改"的问题，而是"改没改、谁改的、原始记录还在不在"——在明文数据库里，这些全都说不清。这也是为什么燃气门站这类工业 SCADA 系统的数据加密，核心验收项永远是"报警记录能不能被篡改"。
数据体量先看清：8.6 亿条，靠权限控制已经兜不住了
把集团监测库拆开看，四类数据：
| 数据类型 | 累计数据量 | 日均新增 | 敏感级别 |
|---|---|---|---|
| 甲烷浓度采样（ppm） | 4.3 亿条（滚动保留30天） | 约 1200 万条 | 高 |
| 泄漏报警记录（时间/点位/级别） | 58 万条 | 约 1600 条（含预警级） | 极高 |
| 压力/温度/流量运行参数 | 3.6 亿条 | 约 980 万条 | 中 |
| 门站视频与门禁事件 | 65 万条 | 约 2600 条 | 中 |
浓度采样这个量是怎么来的：全集团 2800 余路可燃气体检测点，每 20 秒轮询一次，一天约 1200 万条。四张表加起来约 8.6 亿条，全部明文落盘。数据量大到不能再靠"控制谁能登录"来兜底，只能靠存储层加密。
加密的三种做法，为什么多数人一开始选错
一说加密，第一反应是"应用层改代码"——往每个读写 SQL 里加解密函数。这条路改造的账通常这么算：
第1-2周 → 逐表梳理加密需求（监测库4类业务表、20+张物理表） 第3-6周 → 逐段SQL修改，加加解密函数（核心两张表的读写SQL涉及约800行） 第7-8周 → 全量回归测试，验证SQL执行计划不受影响 第9周 → 申请停机窗口，上线加密版本 ← 合计8周，停机1次问题出在最后一步：要停机。门站 SCADA 是 7×24 生产监控系统，年度可用性要求不低于 99.9%。为加密停一次机，等于安全改造期间先放弃监测——燃气门站没法接受。
对比三种加密路线的实际差异：
| 对比维度 | 应用层加密 | 数据库内置加密 | 驱动层透明加密(TDE) |
|---|---|---|---|
| 是否改应用代码 | 是，逐段SQL | 是，需表空间配置 | 否，零改造 |
| 改造周期 | 8周 | 4周 | 2-3周 |
| 是否停服上线 | 是 | 是 | 否，在线加密 |
| 运维/DBA隔离 | 无（DBA仍见明文） | 部分 | 按PID控制，DBA不可见明文 |
| 性能影响 | 5-15% | 5-10% | < 3% |
| 国密认证 | 需自证 | 需自证 | 已获国密局认证 |
透明加密（TDE）的落地，完整 SQL
以燃气门站监测库为例，落地分三步走。
第一步：先扫敏感字段，别靠人肉翻表
在从库上跑一遍 KDPS 敏感字段扫描，把四类数据里的敏感字段清单自动拉出来（从库扫描不影响主库运行，全程约 1 小时）。靠人工逐张翻 20 多张物理表列"哪些字段该加密"，既容易遗漏，验收时也说不清口径。
第二步：启用表级加密，一表一密
对每张核心表单独配置加密策略和密钥，在线加密不停机：
-- 泄漏报警表启用TDE加密（在线加密，不停机）EXECtde_enable_table_encryption@database_name='gas_station_leak',@table_name='t_leak_alarm',@encryption_algorithm='SM4_256',@key_id='tde_leak_alarm_key',@rotation_interval_days=90,@mode='online';报警记录表单独一把密钥、独立轮换——因为敏感级别最高（极高），要单独审计。
第三步：存量数据渐进加密，不锁表
4.3 亿条存量浓度数据不可能一次性加密完。TDE 走渐进加密，凌晨窗口执行，加密 I/O 不超过总 I/O 的 30%，不锁表。加密进度可实时查：
SELECTtable_name,ROUND(encrypted_mb/NULLIF(total_mb,0)*100,1)ASprogress_pct,estimated_remaining_minutesFROMtde_catalog.encryption_progressWHEREdatabase_name='gas_station_leak'ANDstatus='in_progress';密钥是怎么管的：三级体系 + 90 天轮换
加密不是配一次就完事，密钥的生成、轮换、销毁不管好，加密等于留后门。透明加密的密钥走三级体系：
- 根密钥 KEK：存于 HSM 国密密码机，永不导出
- 工作密钥 DEK：由 KEK 加密保护，数据库中存的是密文
- TDE 密钥：由 DEK 派生，运行时加载到 TDE 过滤驱动
即使门站数据库服务器被攻破，攻击者拿到的也只是 DEK 密文，根密钥在硬件里出不来。轮换配置在线执行不停机，旧密钥保留到存量数据全部重新加密完成：
# KSP 自动轮换配置（90天，凌晨执行，在线轮换）curl-XPOST https://ksp.internal.gasgroup.cn/api/v1/keys/rotation-policy\-H"Authorization: Bearer <ksp_admin>"\-d'{ "key_id": "tde_leak_alarm_key", "rotation_interval_days": 90, "rotation_time": "02:00", "online_rotation": true }'验收：三条 SQL 证明"真的防篡改了"
这是每个项目交付时被问得最多的问题，三条 SQL 当场可验：
-- 验证1：以数据库root身份直查泄漏报警表SELECT*FROMgas_station_leak.t_leak_alarmORDERBYalarm_timeDESCLIMIT10;-- 输出：密文（非授权进程不解密，DBA看不到明文）-- 验证2：以SCADA应用身份查同一张表SELECT*FROMgas_station_leak.t_leak_alarmWHEREalarm_level='HIGH'LIMIT10;-- 输出：明文（授权进程自动解密，业务照常）-- 验证3：查加密状态与进度SELECTtable_name,encryption_statusFROMtde_catalog.encryption_statusWHEREdatabase_name='gas_station_leak';三条走完，"报警记录能不能被改"就有了确定答案：
- 外部拖库→ 拿到的是密文，无用
- 内部 DBA 直查→ 看到的是密文，改不了
- 授权运行的燃气SCADA进程→ 正常读明文，业务无损
合规上对应什么
| 合规标准 | 要求 | 方案实现方式 |
|---|---|---|
| 等保2.0三级-数据保密性 | 数据库加密存储 | 驱动层SM4加密，DBA隔离 |
| 等保2.0三级-安全审计 | 操作日志留存 | 密钥轮换全链路审计日志 |
| GB/T 39786-2021 | 密码应用合规 | 产品国密局认证，证书直接举证 |
| 《城镇燃气管理条例》 | 燃气安全监测数据可追溯 | 报警记录加密落盘+防篡改 |
对燃气门站这类"不能停、不能改代码"的 SCADA 系统，透明加密是唯一能同时满足零改造、不停机、DBA 隔离三条硬约束的路线。安当 TDE 数据库透明加密 + KSP 密钥管理就是为这类工业场景设计的，可提供完整落地支持。
文章作者：安当加密技术负责人
