背景
1、产品的问题点
- PG 不支持透明加密(TDE)功能, 实际上这个功能已开发好, 又因为没有完整的regress test被打回了.
- 《PostgreSQL 14 preview - TDE cluster_key_command 配置例子》
- 《PostgreSQL 14 preview - 支持TDE功能, 支持加密数据文件, 支持加密WAL日志文件》
2、问题点背后涉及的技术原理
- 安全风险存在于:
- 网络窃取客户端与数据库传输的内容
- 通过SSL链路、数据类型透明加密(传输加密内容)可以杜绝
- 机房直接窃取存储介质
- 通过介质加密、数据库数据文件TDE功能、数据类型透明加密(存储加密内容)可以杜绝
- 操作系统入侵, 窃取数据文件
- 通过数据文件加密(数据库数据文件TDE功能)、数据类型透明加密(存储加密内容)可以杜绝
- 数据库入侵, 通过流复制协议拷贝明文数据文件.
- 通过数据库数据文件TDE功能、数据类型透明加密(存储加密内容)可以杜绝
- 数据库入侵, 直接窃取数据库存储的表、字段、行等内容
- 数据类型透明加密(存储加密内容)可以杜绝
- 透明加密是指对业务没有侵入的加密方法, 例如不影响原有的计算、索引、排序等功能.
- 一般对业务有感的加密, 直接使用加密后的值无法像使用原始值一样进行计算、排序的动作, 因为加密后存储的内容发生了变化. 例如pgcrypto加密插件, 如果存储加密后的值, 排序和原始值的顺序肯定是不一样的, 也不能直接使用加密值进行加减乘除计算.
- 《DB吐槽大会,第30期 - PG 某些敏感信息未隐藏》
3、这个问题将影响哪些行业以及业务场景
- 通用
4、会导致什么问题?
- 非透明加密对业务有侵入,
- 无法实现数据库端的计算(等值查询除外, 但是等值查询也可能因为加密的hash value空间变小, 映射冲突导致结果与原始查询不一致. 需要拿到结果后在业务端使用原始值再次过滤. )
- 不能使用索引排序功能
- 不能使用排序功能
- 不能使用索引进行范围查询
- 非透明加密的密钥必须存储在客户端, 如果存储在数据库端有数据安全风险.
5、业务上应该如何避免这个坑
- 可以使用文件系统加密替代TDE
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 文件系统加密安全级别不够高, 在操作系统文件系统挂载的情况下, 可以拷贝明文的数据文件.
7、数据库未来产品迭代如何修复这个坑
- 希望TDE功能尽快合并到PG未来的大版本中. 解决机房直接窃取存储介质、操作系统入侵, 窃取数据文件、数据库入侵, 通过流复制协议拷贝明文数据文件的安全风险.
- 希望支持类型的透明加密, 例如阿里云提供的 SGX 全加密数据库功能. 解决所有安全风险. 需要硬件支持(例如CPU支持enclave)
