国密算法的支持情况是否应纳入国产数据库选型考察范围.docx

?

?

国密算法的支持情况是否应纳入国产数据库选型考察范围

?

?

国密算法的支持情况是否纳入国产数据库选型中？

现在国产数据库品牌很多，但是支持国密算法的数据库好像并不多，大部分都是支持AES加密算法，那是否考虑将国密算法纳入考察范围呢？

目前支持国密算法的有哪些数据库呢？我所知道的OB是支持的，其他数据库不太清楚。

问题来自社区会员@wangzk0206某农信数据库管理员，以下内容来自社区会员探讨

@anikikong中国民生银行数据库运维工程师：

这个应该是要考虑的，而且也不难做，国产厂商是可以很快搞定的。

我们用openGauss也是支持国密算法的。

@匿名用户：

要看下你的应用是不胖代理还是瘦代理，一旦开加密都会涉及到性能损耗。如果是胖代理，是在应用侧进行的加密，对应用性能的影响比较大，如果是瘦代理是把加密这块放到数据库来加密，应用的性能是无损的，而且加密包括传输加密和落盘加密，特别是落盘加密是数据库选型需要考虑的，最好是传输加密和落盘加密都可以由数据库来承接，这样对于应用是最友好的方式。

@jillmeCIO：

最好纳入，现在国内个人信息保护和去国外技术的大趋势下。国密基本成为唯一的选择项。但是基本上上很多企业做的国密加密都是只能保障等值查询的性能，对于多分段多段的模糊查询是无法有效的支持的。这个也是目前国内的一个比较尴尬的现状。很多还需要借助2次加工。

@twt大禹?数据库架构师：

国密算法的当然应该列入国产数据库选型中来，国密加密是数据安全的需求，是必然的发展的方向。问题是，传统的Btree的数据库架构的国密加密，做成TDE，性能下降50%。而LSM架构的数据库，性能影响在2%~4%之间。

如果开启国密算法，性能下降50%，我理解没有一家金融机构可以接受这样的性能损失，因此，我特别认同中国信通院的数据库发展。

2018年大数据白皮书说，单机数据库(eg:DB2、Oracle、Mysql、PostgreSQl)==》嵌入式==分库分表中间件的数据库==原生分布式架构，这是必然的发展方向。基于开源数据库的分库分表慢慢淡出市场，已经逐渐成为落伍者。

@jxq：

这或许是一种办法：

在“商用密码认证业务网”的“商用密码产品认证证书查询”页面

/cer/cersearch/signle-c37.html

在“产品名称”框输入“数据库”查询。

刚刚查了一下，列出了26项结果（不全是“国产数据库”）。

然后，通过结果列表“产品名称”栏的内容，筛选出“国产数据库”。

-全文完-