我和OceanBase集中式滚了4个月，安全这关我真的是担心多余了

❝

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群加群请联系 liuaustin3 ，（共3400人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 ）(1 2 3 4 5 6 7 8群已经爆满  9群 为纯聊天群，默认不加入不得发广告，自己公众号文章链接等，发一次直接踢，默认加入8群，开10群PolarDB专业学习群115+)

下载链接   https://fs80.cn/duykvo   

欢迎大家下载 本人和OB集中式老师 摸爬滚打 4个月产出的 OB 集中式兼容MySQL 报告

其实在和OceanBase 滚的四个月里面，兼容性我并没有特别的担心，反倒是安全，对国产数据库的安全方面我是担心的。测试之前我有一个"先入为主"的观念：国产数据库的安全能力，可能是"够用但不惊艳"。

一、第一个测试项：多租户资源隔离 这一项严格来说属于"架构安全"的范畴，但我放在安全测试里是因为：资源隔离本身就是防止"一个烂 SQL 拖垮整机"的第一道防线。

我让 DBA 老张给我演示了一遍 OceanBase 的多租户配置流程，设计非常清晰：

声明资源规格（CREATE RESOURCE UNIT）——定义一个"图纸"：最大/最小 CPU、内存大小、IOPS、日志磁盘大小 打包成资源池（CREATE RESOURCE POOL）——给图纸定规格数量和可用 zone分配给租户（CREATE TENANT）——把资源池绑到租户上，租户就拿到了自己独占的物理资源。

我亲手创建了两个租户：tenant_oltp 和 tenant_olap，分别绑了不同的资源池。然后在 tenant_oltp 里跑一个超级大查询——故意写了一条没有索引的全表扫描，让它把 CPU 占满。同时在 tenant_olap 里跑正常查询，响应时间几乎没有受到任何影响。

这就是多租户资源隔离的价值。你可以把不同业务的数据库跑在同一台 OceanBase 上，每个租户各自用各自的 CPU 和内存，互不干扰。MySQL 做不到这一点——MySQL 的"多租户"要么靠分库分表（运维复杂度爆炸），要么靠 Proxy 做逻辑隔离（不是物理隔离，防不住"烂 SQL"拖垮整机）。

二、SSL/TLS：改完配置秒生效，不需要重启 这一项是我整个安全测试中"落差感"最大的部分——因为我是先测的 MySQL，再测的 OceanBase。

MySQL 的 SSL 配置流程：改 my.cnf 里的 ssl_ca / ssl_cert / ssl_key → FLUSH SSL 或者直接重启 MySQL → 主从或集群环境下每个节点都要单独配一遍 → 还要担心 ProxySQL 之类的代理系统有没有各自的 SSL 配置问题。整个过程至少十几分钟，业务中断不可避免。

OceanBase 的 SSL 配置流程——三条命令，一分钟搞定

-- 开启 SSL 认证
ALTER SYSTEM SET ssl_client_authentication = 'TRUE';

-- 加载证书（一条 JSON 搞定 CA 证书 + 服务端证书 + 私钥）
ALTER SYSTEM SET ssl_config = '{"ssl_ca":"/path/ca.pem", "ssl_cert":"/path/server.pem", "ssl_key":"/path/key.pem"}';

-- 强制业务用户必须用 SSL 连接
ALTER USER biz_user@'%' REQUIRE SSL;

然后我从另一台机器用 obclient 测试——obclient -h x.x.x.x -P 2881 -ubiz_user@tenant -p --ssl-ca=ca.pem，连接成功。进库之后执行 SHOW STATUS LIKE 'Ssl_cipher'，返回值是 ECDHE-RSA-AES128-GCM-SHA256——SSL 加密链路已生效。整个过程不到一分钟，不需要重启 OBServer 进程。

对比 MySQL 需要重启才能生效的体验——这根本不是同一个维度的便捷性。

三、全球只有 4 个原生分布式关系型数据库通过，OB集中式通过了。

这事情还的说咱们拿OB集中式当亲儿子的产品经理，瑶婴老师，我是真的感受到说一句OB集中式有问题，她都特别关心，然后过不了多长时间，就给你来一个新的版本把提出的事情给解决了。

这事情还的说到这个安全合规的认证，大家熟悉的是等保 2.0、GDPR、PCI-DSS。但 CIS Benchmark 是一个更"硬核"的国际标准——由互联网安全中心（Center for Internet Security）制定，它的基准要求细到操作系统的文件权限应该设成 0600、密码复杂度至少 12 位包含大小写和特殊字符、TLS 版本必须 ≥ 1.2。

OceanBase 是全球仅有的 4 个通过 CIS Benchmark 的原生分布式关系型数据库之一。这个认证对我们很重要——一方面证明 OceanBase 的安全设计经过了国际权威机构的审查，另一方面我们做国际业务时，CIS Benchmark 是很多跨国项目的"入场券"。

我记得，我在第一时间被瑶婴老师告知，OB集中式获得了CIS测试，能不能把这段写到安全的部分里面，因为安全的部分我之前就写完了，正在审核中，而恰巧此时CIS的认证过了，我还特意查了通过CIS 在OB集中式里的意义。

CIS OceanBase V4 Benchmark 从 5 个层面给出了安全基线：

操作系统级：数据库部署在非系统分区；日志分区 ≥ 内存 3-4 倍；专用低权限账户运行

安装与补丁：必须用官方签名安装包；优先 LTS 版本

MySQL 租户加固：复杂密码策略、禁用 GRANT 自动建用户、限制高权限、启用 TDE + 全量审计

Oracle 租户加固：DBA_PROFILES 管理登录失败次数、密码锁定时间；严格审计 SYS 操作

传输安全：强制 TLS v1.2+；白名单限制访问节点

四、细粒度审计：基于过滤器的多维事件筛选

最后测的是审计能力。数据库安全有一个"常识"：加密和权限控制防得住外部入侵，但防不住内部人的权限滥用。审计就是专门对付这个的——对所有合法权限用户的操作做精准、可追溯的持续记录。

OceanBase 的审计架构让我印象深刻——它不是简单的"全量审计"或者"按用户审计"，而是基于过滤器的多维事件筛选：

主体维度：可以按用户账号、客户端 IP、IP 网段过滤——比如只审计来自运维组 10 个用户的操作，或者只审计来自某个 IP 段的连接。

客体与事件类型：可以按登录/登出、DML、DDL、CMD（系统命令）等事件类型过滤——比如只审计 DROP TABLE 和 TRUNCATE，平时的 SELECT 不审计（减少审计日志量）。

事件属性维度：还能按执行状态（成功/失败）、错误码过滤——比如只审计"执行失败的权限变更"，或者"耗时超过 30 秒的查询"。

-- 创建审计过滤器：只审计 DBA 组用户的 DDL 和 CMD 操作
CREATE AUDIT FILTER filter_dba (
'ACTION IN (CREATE, ALTER, DROP, TRUNCATE, CMD)',
'USER IN (dba1, dba2, dba3)'
);

-- 绑定过滤器到用户
ALTER USER dba_user ADD AUDIT filter_dba;

-- 查看审计日志
SELECT * FROM oceanbase.GV$OB_AUDIT_LOG ORDER BY log_time DESC;

审计日志的存储策略也很完善：可以存本地磁盘，也可以实时同步到 OSS 做长周期合规留存；支持对敏感 SQL 参数做动态脱敏（比如审计日志里只显示信用卡号前 4 位和后 4 位）；审计日志本身也能落盘加密 + 传输加密；系统可以按策略自动轮转、压缩归档、过期清理——不用担心日志无限增长撑爆磁盘。

总结：OceanBase多租户资源隔离（资源单元 → 资源池 → 租户 三层映射）、原生透明加密（AES + 国密 SM4）、SSL 动态配置（秒级生效不需要重启）、CIS Benchmark V4 认证、基于过滤器的细粒度审计——每一项都踩在了金融合规的刚需上。

扣掉的 2 分：多租户资源池配置的学习曲线稍微有点陡——资源单元、资源池、租户这三层关系，新手上手需要时间。不过这是工具链的问题，不是安全能力的问题。对比 MySQL 社区版：没有 TDE、SSL 配置要重启、没有审计过滤器、没有 CIS 认证——MySQL 在安全方面几乎是"裸奔"状态。

所以OceanBase的确在安全和MySQL不兼容，因为的确MySQL在安全方面没有可以对标的部分。