企业官网建设流程全解析

OceanBase 安全基线巡检实战：一次通过等保测评的 5 项巡检清单

【免费下载链接】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 集群的默认账号动了没有？传输加密开了吗？"运维当场只答上来一半——不是没做，是从来没人系统性地查过一遍。这就是安全基线巡检要解决的事：把散落在各处的安全隐患，用一份固定清单在测评前自己先过一轮，避免被卡住。

📋 阶段一：巡检前的准备

巡检最怕"拿着锤子找钉子"——不知道集群长什么样就开始敲。动手之前，先做三件事。

摸清部署版图

先画清楚你的 OceanBase 部署形态：几台 OBServer、几台 OBProxy、几个 Zone、业务从哪个网段连进来。 OceanBase 是分布式架构，数据在服务节点间多副本分布，任何一台节点都可能承接客户端流量，所以巡检范围要覆盖所有 OBServer，而不只是"主"那几台。

工具与权限准备

• 权限：拿一个只读诊断账号（能查系统视图、能看账号与权限，但不能改数据），巡检用专用账号是底线，别拿业务账号来查；
• 工具：客户端连上各节点，准备好查__all_user、__all_database_privilege等系统表的能力；仓库里 script/sqlaudit/ 就有一个轮询V$OB_SQL_AUDIT拉审计记录的现成脚本，巡检审计留存时可以参考它的写法；
• 清单：把下文 5 个高频巡检项打印出来，逐项打勾，做完一项勾一项。

风险怎么分档

发现隐患后别眉毛胡子一把抓，按"档位"决定处置节奏：

分档的依据对齐等保 2.0 / GB/T 22239 的身份鉴别、访问控制、安全审计要求即可，条文不用背，知道"身份鉴别要强度、访问控制要最小化、审计要留存"这三条主线就行。

🔍 阶段二：高频巡检项逐个过

以下 5 项是测评里被问得最多的，也是生产环境最容易出问题的。每项按"为什么重要 → 怎么做 → 达标判据 → 常见踩坑"四步走。

1. 默认账号与口令强度

为什么重要：默认管理员账号是攻击者第一目标，弱口令 + 默认账号 = 免密进门。

怎么做：连上集群查SELECT user_name, tenant_id FROM __all_user;，确认生产租户里只有业务必需的账号；给每个账号设置带大小写、数字、特殊字符的强口令，并设置有效期。

达标判据：生产租户无默认弱口令账号；管理员账号与应用账号分离；口令策略（复杂度、长度、更换周期）已开启。

常见踩坑：只改了密码没收敛账号——建库时顺手创建的test、dev账号在半年后还在，巡检时顺手清掉。

2. 权限收敛

为什么重要：权限最小化就像发门禁卡，只开该进的那几扇门。业务账号拿着DROP权限，一次误操作或一次拖库就能放大成数据事故。

怎么做：按库、按账号梳理授权。日常只读账号给SELECT，写入账号给SELECT/INSERT/UPDATE，DDL 权限收回到 DBA 专用账号。授权用GRANT ... ON 库.* TO 账号，逐库逐账号过一遍__all_database_privilege。

达标判据：普通业务账号不持有DROP、GRANT OPTION、ALTER SYSTEM类高危权限；能说出每个高危权限账号对应的责任人。

常见踩坑：图省事直接GRANT ALL。还有"一人多角"——同一个账号既跑报表又跑写入，出事没法区分责任，建议拆账号。

3. 传输加密

为什么重要：内网不等于安全网，明文 SQL 在链路上可被抓包，账号密码、业务数据一览无余。

怎么做：给集群启用 TLS，并约束最低协议版本——仓库参数定义里可见 src/share/parameter/ 中的ssl_client_authentication、sql_protocol_min_tls_version等配置项，把 TLS 版本下限至少抬到 1.2，淘汰掉过时的老版本。客户端连接串带上证书校验。

达标判据：客户端到 OBProxy/OBServer 的连接默认走加密；关闭 TLS 会直接连不上（这才是真开了）。

常见踩坑：加密"开了"但客户端不强制，弱客户端走明文也能连——等于没开。证书到期没轮换，某天全员连不上库，这种故障单在运维圈很常见。

4. 审计日志与留存周期

为什么重要：等保对安全审计的要求很直白：记录谁、在什么时间、干了什么，而且能留得住。审计缺失在测评里基本是必扣分项。

怎么做：OceanBase 的 SQL 审计记录落在V$OB_SQL_AUDIT视图中，关键 SQL 会按审计开关和保留策略留存。巡检时确认审计功能开启、保留时长设置到位，并把审计数据定期导出到日志平台统一归档；导出脚本可以参考仓库 script/sqlaudit/ 的实现思路，按时间增量拉取即可。

达标判据：审计覆盖登录、授权变更、DDL 等关键操作；留存周期 ≥ 6 个月（等保三级的 180 天要求）；能按账号 + 时间范围检索出历史操作。

常见踩坑：只留了审计开关没留数据——V$OB_SQL_AUDIT是滚动窗口，超期数据会被刷掉，"留存 180 天"必须靠导出归档落地，而不是指望视图里的存量。

5. 网络访问控制

为什么重要：数据库端口对全网开放，是渗透测试报告里出现频率最高的一条。

怎么做：两层配合——集群侧配置 IP 白名单（如ip_white_list一类参数，限制仅允许业务网段和运维跳板机的地址接入）；网络侧用防火墙/安全组把 2881 客户端端口、2882 RPC 端口之外的入口收掉。白名单要具体到网段甚至单机，不写0.0.0.0/0。

达标判据：从非白名单网段发起连接会被拒绝；端口暴露面与业务需求一一对应，能解释每个开放端口的用途。

常见踩坑：图方便留了个"临时调试"的宽泛网段，三个月后没人记得删。白名单项后面最好挂上"谁加的、什么时候回收"的备注。

🔁 阶段三：闭环与长效机制

整改怎么验证

改完不等于达标，要回头复查：白名单收紧后从非白名单 IP 实测连一次；加密开启后确认明文连接被拒；权限回收后拿该账号试着DROP一下（在测试库），确认确实不行。建议把每次巡检发现的问题记进一张表：问题、档位、处置人、复查人、复查日期，形成闭环——没有复查人签字的整改，等于没做。

定期节奏与自动化

人工巡检的价值在"建立基线"，常态靠自动化：

• 节奏：季度做一次全量巡检（5 项全过），月度跑一遍高危项（账号、白名单、加密），账号或网络变更当天触发临时巡检；
• 脚本化：把查__all_user、查授权、查白名单参数的 SQL 固化成脚本，输出统一格式的报告，接到 CI 或定时任务里跑，超阈值就告警。仓库的 script/ 目录放了不少巡检类脚本样例，可以照着组织自己的巡检工具；
• 版本跟进：跟着官方发布节奏关注安全公告，新版本发布后评估升级窗口，别等高危漏洞公告才动。

❓ 常见误区澄清

• "内网部署就不用加密了"——内网横向渗透是真实场景，加密防的是"进了内网的人"，不只是外网。
• "审计开关开着 = 审计合规"——视图里的数据会滚动过期，合规看的是归档留存能力，不是开关状态。
• "权限收敛会影响性能"——授权检查发生在登录和 SQL 路由阶段，收敛权限的性能开销可以忽略；该省的是出事后追责和误操作的成本。
• "等保测评过了就一劳永逸"——账号、网段、端口每天都在变，基线是活的，巡检才把它"养"住。

✅ 可直接抄走的行动清单

把这张表贴在工单系统里，下次测评前自己先跑一遍，被问住的情况基本就不会再出现了。建议每季度安排一次全量巡检，让基线跟着环境一起"活"着。

【免费下载链接】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