聊聊政企国产化那些事：MongoDB迁移到KingbaseES，安全合规到底怎么破？
各位兄弟，咱们干IT这行的，最近几年肯定没少折腾国产化替换。其实大家心里都有数，政企客户对数据安全这事儿，现在是看得比天还大。特别是提到非关系型数据库，很多人脑子里立马就会蹦出来一个词，那就是MongoDB。早些年搞MongoDB的时候，经常有单位因为配置不当导致数据泄露。这种事儿一出，那可是要命的。所以现在很多政企客户搞MongoDB迁移，心里都直打鼓。那么，咱们今天就拿金仓的KingbaseES来和MongoDB对比对比，看看作为国产数据库，KingbaseES在安全合规上，到底有啥天然的优势，能不能解决咱们政企客户的焦虑。
一、 咱们为啥怕MongoDB，数据泄露的刻板印象咋来的
其实说起MongoDB，很多人第一反应就是快，写代码方便。但是，在安全这块，它的口碑确实不咋地。这也是为啥很多政企客户现在非得搞MongoDB迁移的原因。那为啥大家会对它有这种数据泄露的刻板印象呢？咱们得从它早些年的设计说起。
1.1 早期配置不当惹的祸，默认没密码
大家还记不记得前几年，网上经常爆出某某公司的MongoDB数据被勒索，或者直接被脱库了。为啥会这样呢？其实往往仅仅只是因为一个很小的原因。那就是MongoDB早期版本，默认是不开启身份验证的。也就是说，你把MongoDB装上，起来之后，它默认就监听在27017端口上。它不需要你输账号密码，谁连上来，谁就能直接读写数据。
这事儿放在内网测试环境，那叫方便。你写个代码，直接一连就能存数据，不用配那些烦人的认证。但是，如果是个粗心的运维，直接把这玩意儿部署到了公网上，或者映射到了公网上。那就完了。黑客用个端口扫描工具，一扫就能扫到这个27017端口。然后直接连上去，你的数据就全裸奔了。这种事儿出现的太多了。也就是从那时候起，MongoDB在很多人心里，就贴上了“不安全”的标签。虽然它后来的版本也改了，默认要求开认证了，但是这个刻板印象，在政企客户心里那是根深蒂固的。
1.2 单一防护太脆弱，一旦突破全完了
除了默认没密码这个坑，MongoDB在整体的安全架构上，也比较单薄。它是一种典型的单一防护模式。啥叫单一防护呢？就是它把宝全压在网络边界和那一个账号密码上了。如果你的网络防火墙没配好，或者账号密码被泄露了，被暴力破解了。那黑客进到数据库里头，那就能随便翻，随便改。
它没有那种一层一层的防护机制。也就是说，它缺乏咱们常说的纵深防御。数据在磁盘上存着，很多情况就是明文存的。黑客要是把文件拷走了，直接就能看。它也没有那种很细粒度的权限控制，比如我想限制某个用户只能看某几个字段，它做不到那么细。这种单一防护，在面对现在越来越复杂的攻击手段时，是很脆弱的。政企客户的数据那么敏感，要是用这种库，晚上老板都睡不着觉。
1.3 名录内没品类，合规审查过不去
其实对政企客户来说，比数据泄露更让人头疼的，是合规审查。现在国家有信创名录，也就是那个国产化产品目录。你要搞国产化替换，你得用名录里头的产品。但是名录里头，没有独立缓存库或者NoSQL库这个品类。也就是说，你用MongoDB这种纯NoSQL库，它是过不了合规审查的。
那为啥名录里没这个品类呢？因为NoSQL库种类太多了，标准不统一，安全测试也难做。这也就是为啥很多单位现在急着搞MongoDB迁移的原因。你不用名录里的东西，出了事谁负责？这其实是悬在咱们头上的一把剑。那怎么解决这个合规焦虑呢？这就得找那种既能在名录里，又能干NoSQL这活儿的国产数据库。KingbaseES就是冲着这个去的。
二、 KingbaseES的纵深防御体系，到底咋护着咱们数据的
前面说了MongoDB防护太单一。那KingbaseES作为国产数据库的排头兵，在安全上是怎么做的呢？它搞了一套叫纵深防御的体系。这玩意儿就是一层套一层。你就算破了一层，还有下一层挡着你。这就比MongoDB那种光杆司令强多了。咱们来看看这个体系里都有啥。
2.1 访问控制和身份鉴别，门得看紧了
咱们先说第一道关，也就是门卫。KingbaseES这块做得特别细。它不光是有个账号密码那么简单。它支持三权分立。也就是说，DBA（数据库管理员）、安全管理员（SSO）、还有审计员（SA），这三个人是分开的。DBA只管系统运行，他看不到敏感数据。安全管理员管谁有权限看啥数据。审计员管记录谁干了啥。这三个人互相制约。这就避免了DBA权力过大，一手遮天的问题。MongoDB可没有这么细的分权。
还有就是身份鉴别。KingbaseES支持强制访问控制（MAC）。这玩意儿可厉害了。它不光看你有没有权限，还看你的数据安全级别。比如有个表是“机密”级别的。你是个“秘密”级别的用户。那就算DBA给了你查询权限，你也查不到。因为你的级别不够。这种基于标签的安全，在政企里头太有用了。另外，它还支持密码复杂度检查。你设个“123456”，它直接不让你设。还有登录失败锁定。黑客想暴力破解你的密码？试几次就给你锁死，IP都给你封了。这比MongoDB那点防护强太多了。
2.2 传输和存储加密，明文裸奔可不行
门卫再严，也有可能被突破。那数据在传输过程中，在硬盘上存着，会不会被偷看？MongoDB如果不特别去配证书，传输就是明文的。别人一抓包，你执行的啥SQL，查的啥数据，全都能看到。这肯定不行。
KingbaseES这块支持SSL/TLS加密传输。也就是说，客户端和数据库通信，全都是密文。黑客就算抓了包，看到的也是一堆乱码，根本解不开。这就保证了数据在路上是安全的。
那存在硬盘上的数据呢？MongoDB默认是明文存的。要是有人把硬盘偷了，或者把存储文件拷走了，直接就能看。KingbaseES有透明存储加密（TDE）。这玩意儿是在数据库引擎层做的加密。数据在写进硬盘之前，就先加密了。读出来的时候再解密。对咱们应用来说是透明的，感觉不到。但是你要是直接去扒硬盘文件，那你看到的也全是乱码。而且它的密钥管理也很严格，可以跟外部的密钥管理机对接。这就彻底断了黑客从物理层面偷数据的念想。也就是说，不管数据是在跑着还是在歇着，都给它捂得严严实实的。
2.3 事后安全审计，谁干的坏事得能查出来
万一真出了事，或者怀疑有人干坏事，咱们得能查出来啊。这就要靠审计了。MongoDB的审计功能挺弱的，也就是记点基本操作。而且日志还容易被篡改。要是DBA干点坏事，自己把日志删了，你都找不着证据。
KingbaseES的审计功能那是相当强大。它有专门的审计员来管。审计开关一开，谁能连、连了干啥、干了啥操作、成功没成功，全给你记得明明白白的。而且它还能按规则来审计。比如我就想审计对某个核心表的修改操作。行，配上就行。最重要的是，审计日志是单独存的，普通DBA根本改不了，也删不掉。只有审计员能看。这就保证了审计的权威性。出了事，一查日志，谁干的坏事一清二楚。这在政企里头，是合规审查必须要有的硬指标。没有这个，你根本过不了关。
三、 自主研发和最高安全认证，政企客户的定心丸
前面讲了那么多技术细节。其实对政企客户来说，最看重的还是那个资质。你技术再好，没资质，人家也不敢用。这就是咱们常说的“自主研发无风险”和“最高安全认证”。
3.1 名录内无独立缓存库品类，用Redis/MongoDB的合规焦虑
咱们前面提过一句。现在很多单位为了提高性能，或者处理非结构化数据，都用了大量的Redis或者MongoDB。但是，信创名录里头，没有独立缓存库或者纯NoSQL这个品类。这可是个大麻烦。
也就是说，你用了这些库，在过等保或者信创审查的时候，审查的人一看，这玩意儿不在名录里啊。那就得整改。要么你把它换掉，要么你得写一堆说明证明它没问题。但是证明也没用，不在名录就是不在名录。这就让很多单位很焦虑。特别是有些业务强依赖这些库，改起来工作量巨大。这种合规焦虑，一直悬在咱们干活的头上。大家都怕哪天审查来了，让你把这个库给撤了。
3.2 KingbaseES的安全资质，不用担心被卡脖子
那怎么解决这个焦虑呢？KingbaseES这就派上用场了。KingbaseES是中电科金仓搞的。它是纯正的国产，自主研发。代码都是咱们自己的。不存在被国外卡脖子的问题。最关键的是，它在信创名录里。而且它拿到了国家公安部颁发的最高安全等级认证，也就是等保四级。这在国内数据库里头，能拿到这个认证的没几家。
也就是说，政企客户用KingbaseES，是完全合规的。审查来了，一看是名录里的产品，等保四级，直接就过了。而且，因为它是自主研发的，如果发现了安全漏洞，国内厂商响应特别快，打个补丁就完事了。不像用国外的库，出了大漏洞，你还得等人家发补丁，心里没底。这种“最高安全认证”，就是政企客户的一颗定心丸。
3.3 未来使用无二次改造风险，一劳永逸
其实大家搞国产化替换，最怕的就是折腾。今天换了这个库，过几年名录变了，或者政策变了，又得换那个库。这种二次改造，对业务伤害太大了。每次换库，应用得改一遍代码，测试得重做一遍。费时费力。
但是如果你现在用KingbaseES，就能避免这个问题。因为它在名录里，而且它是关系型数据库。关系型数据库的标准是很稳定的。它不会像NoSQL那样，今天流行这个，明天流行那个。而且KingbaseES还出了MongoDB兼容版。也就是说，你可以用它的这个版本，把原来的MongoDB替掉。代码还不用大改。以后政策再怎么变，名录里关系型数据库这个品类是肯定会一直在的。这就叫“未来使用无二次改造风险”。你用上它，以后就能踏踏实实跑业务了，不用再瞎折腾了。这也算是解决了名录内无独立缓存库品类带来的长远焦虑。
四、 技术实现细节：KingbaseES MongoDB兼容版咋玩
咱们前面说了，KingbaseES能替MongoDB，还不用改代码。这是咋回事呢？这就要说说它的MongoDB兼容版了。这玩意儿其实挺有意思的。它不是简单地做个接口转换，而是从协议层面做了兼容。
4.1 原生协议兼容是咋回事，代码真能零修改
大家知道，MongoDB有自己的通信协议。客户端是用这个协议跟服务端通信的。KingbaseES弄了个MongoDB协议组件。也就是说，你用MongoDB的原生驱动，连上去的其实是KingbaseES。但是你感觉不出来。它把MongoDB的协议给翻译成了KingbaseES能懂的协议。这样你的应用代码一行都不用改。直接把原来的连接串里的IP和端口改一下，指向KingbaseES，就完事了。这就是“零代码平替”。这比把NoSQL数据迁到关系型库，然后再重写一堆SQL代码，要省事太多了。
而且，它兼容得挺全。像那些插入、更改、删除、查询的API，全兼容。甚至聚合管道的很多操作符也兼容。对于开发人员来说，以前怎么用MongoDB，现在还怎么用。底层的事儿KingbaseES给兜底了。
4.2 配置参数怎么改，搭个环境试试
光说不练假把式。咱们看看怎么在KingbaseES里把这个兼容模式给开起来。其实也不难。首先，你initdb初始化数据库的时候，得加个参数，指定为兼容pg模式。命令大概是这个样子：
kingbase initdb -m pg -U system
这里那个-m pg就是指定模式的，-U system是建个默认用户。
接着，得改配置文件kingbase.conf。这里有几个关键参数得设上。
enable_protocol_compat=on
extension_protocol_port=27017
documentdb_core.bsonUseEJson=on
这几个参数是干啥的呢？enable_protocol_compat=on就是把协议兼容开关打开。extension_protocol_port=27017就是让它在27017端口上监听MongoDB的请求。这也就是为啥你不用改客户端端口的原因。documentdb_core.bsonUseEJson=on这个是处理BSON数据格式的，MongoDB存的就是这玩意儿。
然后还得在那个shared_preload_libraries项后面，加上几个插件。加上kdb_cron,kdb_documentdb_core,kdb_documentdb。这就告诉数据库，启动的时候把这几个模块先加载进来。这几个模块就是处理文档数据的。
4.3 创建插件和测试连接，跑起来看看
参数配好了，重启一下数据库。接着就要创建插件了。这步也很重要。你得登录到数据库里头去敲个命令。
ksql –Usystem -p 54321 dbname
登进去之后，执行这么一句：
create extension documentdb cascade;
这个命令就是装那个文档数据库的插件。那个cascade意思是把它依赖的组件也一起装了。装完了，别忘了给那个system用户设个密码，因为MongoDB连上来得要密码。
alter user system with password '123456';
这就算弄完了。现在你的KingbaseES就处于兼容MongoDB模式了。你可以拿MongoDB的客户端来连它试试。用mongosh连：
mongosh "mongodb://system:[email protected]:27017/dbname?maxPoolSize=1&directConnection=true&authMechanism=SCRAM-SHA-256"
你看，这就是标准的MongoDB连接串。连上之后，你敲那些db.collection.insertOne()之类的命令，都能跑。这就说明你迁移成功了。是不是挺简单的？这就把底层的库换了，但是上层应用一点没动。这种平滑过渡，对政企客户来说，是最喜欢的。
五、 多模数据处理：收敛技术栈，别搞那么多花样
咱们前面聊了安全，聊了兼容。其实用KingbaseES替MongoDB，还有个很大的好处，就是能把技术栈给收敛一下。这其实也是降低运维成本和安全风险的一个大招。
5.1 传统“烟囱式”架构的毛病
以前搞系统，那是啥流行用啥。处理关系型数据，就上Oracle或者MySQL。处理点非结构化数据，或者为了图开发方便，就上MongoDB。搞缓存就上Redis。这就导致了系统里头一堆各种各样的库。这就是所谓的“烟囱式”架构。这种架构毛病太多了。首先就是信息分散。你想跨库关联个数据，难死你。还得写个程序去这个库查点，去那个库查点，再拼起来。数据还不一致，这个库改了那个库没改。
再就是技术封闭，学习成本高。你招个人，得会这个还得会那个。运维也累，得管好几套系统。每套系统都有自己的毛病。而且资源利用率也低。每个库都得占一台机器，哪怕这台机器闲着，那个库也占着。这都是钱啊。这种架构在政企里头，特别不受待见。
5.2 KingbaseES多模一体的优势
KingbaseES为了解决这个问题，搞了个多模一体。也就是说，它一个数据库里头，能支持关系模型，也能支持文档模型，还能支持GIS空间数据啥的。这就叫多模数据一体化存储。你不用为文档数据再单独引一个MongoDB了。直接用KingbaseES的内置能力就行。关系数据和文档数据放在一个库里，甚至能一起联合查询。这就把技术栈收敛了。
收敛技术栈有啥好处呢？首先，学习成本降下来了。运维人员只要会KingbaseES就行了。不用再去学MongoDB那一套命令和原理。其次，库间数据同步的开销也没了。数据都在一个库里，不用同步了。信息也就一致了。这对于政企客户来说，能省下一大笔运维和培训的钱。而且，因为只留了一个库，安全防护只要把KingbaseES这一道防线守好就行了。不用东补西漏的。安全风险也降到了最低。这也是KingbaseES在架构层面的一个核心竞争力。
六、 总结一下咱们今天聊的这些个事儿
咱们今天唠得挺多。从MongoDB的数据泄露刻板印象，一直聊到KingbaseES的纵深防御体系，再到它的多模兼容和自主安全资质。其实归根结底，就是想跟大伙儿说明白一个道理。
在政企国产化这个大背景下，选数据库不能光看它用着顺不顺手，或者跑得快不快。最关键的，得看它安不安全，合不合规。MongoDB虽然好用，但是它的单一防护和早期的安全问题，让它在国内政企市场越来越难混。加上它不在信创名录里，这就是个硬伤。
而KingbaseES作为国产数据库的头部产品，它有自主研发的底层，有等保四级的最高安全认证。它搞的那套纵深防御体系，从访问控制到存储加密再到审计，把数据捂得严严实实的。这就解决了政企客户对数据泄露的担忧。而且它还出了个MongoDB兼容版，能让咱们零代码平替，还能收敛技术栈，解决名录内无独立缓存库品类的合规焦虑。用上它，未来也不用担心二次改造的风险。这就是咱们国产数据库的硬实力。
所以说，如果你现在正头疼手头的MongoDB项目过不了合规审查，或者担心哪天数据裸奔被查水表，那不妨考虑一下把MongoDB迁移到KingbaseES。这或许是个一劳永逸的招儿。今天就跟大家啰嗦到这儿，希望对兄弟们有点启发。以后有空再跟大伙儿聊聊具体的迁移踩坑细节。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/weixin_43151418/article/details/167268096
