OceanBase 数据库安全基线：用 4 个威胁面快速完成安全合规检查与等保整改-二趣网

OceanBase 数据库安全基线：用 4 个威胁面快速完成安全合规检查与等保整改

【免费下载链接】oceanbaseOceanBase is the unified distributed database for the AI era — open-source, multi-model, one engine for your most demanding workloads.项目地址: https://gitcode.com/GitHub_Trending/oc/oceanbase

等保测评或内部审计现场，被追问最多的往往不是"有没有加密"，而是"默认账号改没改、审计日志留了多久、哪些端口还对外开放"。本文以 OceanBase 分布式数据库为例，按身份、数据、通道、运维 4 个威胁面拆解数据库安全基线，给出可执行的安全合规检查与等保整改动作：每一项都有量化判定标准，改完就能当场验证。

01 场景：一次测评现场被点名的三个问题

某团队把 OceanBase 用于生产订单库，等保测评组进场半天就列了三条：

系统租户的root账号仍用初始化口令，且没有开启密码复杂度要求；
SQL 审计没开，测评员要"上个月谁执行过 DROP TABLE"的记录，DBA 答不上来；
2882 号 RPC 端口对整段办公网开放，任何办公电脑都能扫到。

这三条恰好落在三个不同的威胁面上。如果放任不管，后果是具体的：拿到任意业务凭证的人可以直接登录系统租户把权限提到集群级；数据泄露后没有任何留痕可以追溯，等保三级要求的"安全审计"直接不达标；内网任何一台失陷主机都能对 RPC 端口发起探测，攻击面从应用网段扩散到整个办公网。等保整改的意义不在于凑材料，而是把这三类路径逐一焊死。

02 评估视角：按威胁面分层，而不是按功能模块罗列

常见的检查清单按"账号 / 加密 / 日志 / 网络"分模块，问题是攻击者不按模块行动。本文改用四个威胁面来组织，对应攻击者进入系统的四条路径：

身份威胁面：谁来登录？凭证强度够不够？权限收没收？
数据威胁面：数据在链路和磁盘上被偷走时，能不能读？
通道威胁面：攻击者从哪些端口能摸到数据库？连接来源收没收敛？
运维威胁面：操作之后能否追溯？运维工具本身会不会被滥用？

OceanBase 是共享存储可选、多副本架构的分布式数据库，每个 observer 节点都要满足同一套基线，节点数越多，"逐项人工确认"越不现实，这正是把判定标准做成可执行查询的原因。

先定义风险分级。不同团队的处置节奏不同，下表给一套可直接套用的定级规则：

优先级	定义	典型判定条件	处置时限
P0 紧急	可直接获得集群级控制或数据批量泄露	默认账号未改口令、审计日志关闭且集群已承载生产数据、RPC 端口对非集群网段开放	24 小时内
P1 重要	存在可利用的配置缺口，但需额外条件才能得手	业务账号持有 DDL 权限、传输链路未启用 TLS、审计留存不足 180 天	7 天内
P2 一般	不符合最佳实践，短期难以直接利用	口令复杂度等级偏低、证书临近轮换周期、工具账号未走 sudo 管控	30 天内

03 身份威胁面：锁死默认账号，把权限收到最小

03.1 默认账号与口令强度

现状诊断：用SELECT user_name, host FROM oceanbase.__all_user;看是否存在root@sys且从未改过口令；再查ob_password_complexity参数当前值。初始化部署时该参数默认不强制复杂度，意味着 "123456" 级别的口令能直接通过。

判定标准：root@sys必须使用自定义强口令；ob_password_complexity取值 3（口令需同时包含大写字母、小写字母、数字、特殊字符四类字符）。任一不满足即 P0。

处置动作：修改系统管理员口令并收紧复杂度策略，两条命令一次到位：

ALTER USER root@sys IDENTIFIED BY 'New_Str0ng_Pwd!2026'; ALTER SYSTEM SET ob_password_complexity = '3';

验证方式：用旧口令登录应被拒绝；再用一个不含特殊字符的新口令执行ALTER USER，应报复杂度校验失败。

03.2 业务账号权限最小化

现状诊断：逐库执行权限梳理，重点找"业务账号持有DROP、ALTER、GRANT"的组合——误操作和凭证泄露两个方向的风险都在这里。

判定标准：普通业务账号仅持有其访问对象上的SELECT、INSERT（按业务补UPDATE），不允许出现 DDL 与GRANT OPTION；做到这一点即满足权限最小化实践的基本盘。

处置动作：回收多余权限，只保留最小集合：

GRANT SELECT, INSERT ON app_db.orders TO 'app_user'@'10.20.%'; REVOKE DROP, ALTER ON app_db.orders FROM 'app_user'@'%';

验证方式：查询oceanbase.DBA_TAB_PRIVS，确认该账号名下无DROP、ALTER条目；拿该账号执行一次DROP TABLE，应返回权限不足。

04 数据威胁面：传输与存储两段都要加密

04.1 传输链路启用 TLS

现状诊断：连接握手协商出的密码套件是否为空。OceanBase 客户端默认走明文 MySQL 协议，经 OBProxy 接入时需在代理侧显式打开 TLS，否则整条链路在网络上都是明文。

判定标准：生产链路 TLS 启用率为 100%（抽查 5 个业务连接全部协商出非空密码套件）；证书轮换周期 ≤ 90 天，到期未换记 P1。

处置动作：在 OBProxy 配置中打开 TLS 并挂载证书链（enable_tls = true并指定证书文件路径）。若此处不加固，同一网段内任何能抓包的主机都能直接读到 SQL 与数据，且不触发任何数据库侧告警。

验证方式：用openssl s_client对代理端口握手，确认返回证书与协商算法；把证书到期时间记入轮换台账。

04.2 存储层透明数据加密（TDE）

现状诊断：TDE（Transparent Data Encryption）指数据库落盘时自动加密、读取时自动解密，DBA 和业务无感知。检查各节点enable_ss参数是否全部为 true。

判定标准：集群所有 observer 节点enable_ss = true；磁盘文件（数据目录、备份件）被直接拷走时应为不可读密文。任一节点关闭即 P1。

处置动作：配置好 TDE 密钥后开启存储加密：

ALTER SYSTEM SET enable_ss = true;

验证方式：直接查看数据目录下文件内容，应为不可读的二进制密文；同时把密钥轮换周期（建议 ≤ 90 天）纳入 P2 台账跟踪。

05 通道威胁面：端口收敛与连接来源限制

05.1 端口收敛

现状诊断：OceanBase 常规开放 2881（MySQL 协议端口）与 2882（RPC 端口）。先用下面的命令确认本机监听与来源情况：

ss -lntp | grep -E ':(2881|2882)'

判定标准：2882 仅对集群节点互访网段开放，对应用网段、办公网段一律关闭；2881 仅对应用所在网段开放。任一端口对0.0.0.0/0或整个办公网段可达即 P0。

处置动作：用主机防火墙（如iptables/安全组）按网段白名单下发规则，而不是依赖数据库自身——数据库层没有细粒度的来源封禁能力，这一环必须在操作系统或云安全组完成。

验证方式：分别从一台办公网主机和一台应用网主机执行nc -zv <ob_ip> 2882，前者应超时、后者仅集群节点可达。

05.2 连接来源按网段收敛

现状诊断：查oceanbase.__all_user中 host 字段为%的业务账号。%表示任意来源均可用该账号登录，等于把白名单做成了全通。

判定标准：业务账号数量中@'%'形式占比为 0；每个账号的 host 模式精确到应用出口网段（如10.20.%）。

处置动作：新建账号时直接用网段模式限定来源：

CREATE USER 'app_user'@'10.20.%' IDENTIFIED BY 'Str0ng_Pwd!2026';

验证方式：从网段外主机使用该账号登录，应直接拒绝；存量@'%'账号按业务出口 IP 逐批改造，每改一批复验一次。

06 运维威胁面：审计留痕与工具入口

06.1 SQL 审计开关

现状诊断：查询enable_sql_audit参数。关闭状态下，DDL 与高危 DML 不产生审计记录，事后追问"谁在凌晨改过表结构"只能翻业务日志碰运气。

判定标准：生产集群enable_sql_audit = true，且审计范围默认覆盖 DDL（DROP TABLE、ALTER USER等），留存可追溯最近 7 天以上的执行明细。开关关闭即 P0。

处置动作：在集群级打开审计：

ALTER SYSTEM SET enable_sql_audit = true;

验证方式：执行一次DROP TABLE测试表，随后在oceanbase.V$OB_SQL_AUDIT视图中按query_sql过滤，应能查到该语句的执行者、时间与来源。

06.2 审计日志留存 ≥ 180 天

现状诊断：审计明细默认保留窗口有限，等保三级要求日志留存不少于 6 个月，必须靠定期归档把audit.log类文件搬进归档区。仓库自带的script/sqlaudit/下就有基于V$OB_SQL_AUDIT增量拉取的脚本，可直接作为归档起点改造。

判定标准：归档区可连续还原最近 180 天的审计记录；抽查任意一天的 DDL 事件均可定位到执行人。缺口任一天即 P1。

处置动作：部署定时任务每日增量导出并压缩归档，归档区设最小/最大两个保留期（建议 180 天起）。

验证方式：跑一条统计命令确认没有超期文件遗漏在热盘上：

find /data/log -name 'audit*.log' -mtime +180 -print -quit

无输出说明热盘无超期文件；再用随机取一天从归档区还原一次做抽查。

06.3 运维工具与高权限入口

tools/ob_admin/下的工具集（日志处理、日志流工具等）需要以高权限执行，本身就是一个提权入口。判定标准：所有 ob_admin 调用走sudo白名单并留存 sudo 日志，禁止业务主机直接 root 执行。若工具入口失控，持有主机权限的人可以在不碰数据库账号体系的情况下直接操作本地日志与数据文件。

07 持续运营：PDCA 循环代替一次性整改

基线不是一次验收动作。等保整改的常见死法是"测评前突击、测评后回弹"——账号又改回去了、审计又关掉了。解法是把复评做成固定节奏的闭环：

节奏建议：每季度一次全量复评，新增 observer 节点或新增租户时触发一次增量检查。扫描不需要手工逐项查，一条命令拉出全部关键参数的当前值：

obclient -h 127.0.0.1 -P 2881 -u root@sys -p \ -e "SELECT svr_ip, svr_port, name, value FROM oceanbase.__all_virtual_sys_parameter_stat \ WHERE name IN ('enable_sql_audit','enable_ss','ob_password_complexity');"

把输出粘贴进下面的清单模板，对照判定阈值逐项打勾，闭环率低于 100% 的项按 02 节的优先级定级进入处置队列：

编号	威胁面	诊断要点	判定阈值	优先级	处置状态
T-ID-01	身份	root@sys 口令	已改强口令且复杂度=3	P0	□未开始 □进行中 □已验证
T-ID-02	身份	业务账号 DDL 权限	DROP/ALTER 持有数=0	P1	□未开始 □进行中 □已验证
T-DA-01	数据	链路 TLS	抽查连接协商出非空套件	P1	□未开始 □进行中 □已验证
T-DA-02	数据	存储加密 enable_ss	全部节点=true	P1	□未开始 □进行中 □已验证
T-NW-01	通道	2882 端口来源	仅集群网段可达	P0	□未开始 □进行中 □已验证
T-NW-02	通道	账号 host 模式	@'%' 业务账号数=0	P1	□未开始 □进行中 □已验证
T-OP-01	运维	SQL 审计开关	enable_sql_audit=true	P0	□未开始 □进行中 □已验证
T-OP-02	运维	审计留存	归档可还原≥180天	P1	□未开始 □进行中 □已验证
T-OP-03	运维	ob_admin 调用管控	100% 走 sudo 白名单	P2	□未开始 □进行中 □已验证

把下一季度的首扫命令排进日历，基线就从一份文档变成了会自己转的循环。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析