等保测评命令——OceanBase数据库做等保测评的兄弟都知道数据库层面的检查项是整个测评里的大头而OceanBase这两年上线的项目特别多金融、政务、运营商核心系统都在往OB迁移。很多测评师第一回遇到OceanBase时往往有点懵分布式架构、多租户模式、MySQL和Oracle两种兼容模式跟传统单机数据库差别不小网上能查到的现成命令又少。这篇东西把我实际在等保测评项目里用到的OceanBase核查命令完整梳理了一遍覆盖身份鉴别、访问控制、安全审计、入侵防范、数据安全这几个最核心的测评项。想省时间照着敲就行同时也附上判定依据和坑点说明适合测评机构的技术人员、数据库运维同学以及准备等保自查的甲方安全岗参考。1. 等保测评数据库检查项在OceanBase上的几个关键变化1.1 OceanBase的架构特点直接影响测评方式面对OceanBase你得先接受一个事实它跟你以前查MySQL、Oracle的思路完全不一样。OceanBase是分布式架构一个集群里通常有多个zone每个zone里有多台observer节点数据以分区和副本的方式打散存储。也就是说你连上某个节点的IP和端口不代表你查到的就是全集群的唯一状态很多配置是集群级的或租户级的需要区分清楚。第二个关键点是多租户机制。OceanBase在集群之上划了多个租户tenant每个租户之间资源隔离、数据隔离系统租户sys租户和业务租户都不是一回事。等保测评里查身份鉴别策略、审计开关这类配置得先进对租户查用户账号、权限分配也是基于租户维度去查不能拿MySQL的show databases那套思路硬套。第三个变化是兼容模式。OceanBase的租户可以设置成MySQL兼容模式或者Oracle兼容模式不同模式下查询某些系统表和视图的写法会有差异。我遇到的大部分国产化替代项目用的是MySQL兼容模式但Oracle模式的存量迁移项目也不少。下面的命令我会尽量兼容两种模式个别差异会单独标注。1.2 等保2.0数据库测评项对应到OceanBase的检查思路等级保护2.0里与数据库相关的控制点大概能落到这几个方向身份鉴别用户唯一标识、登录失败处理、超时锁定、口令复杂度策略访问控制账号权限分离、默认口令修改、多余账号清理、权限最小化安全审计审计开关、审计范围、审计记录保护、审计日志留存入侵防范最小化安装、补丁升级、敏感命令限制数据完整性与保密性传输加密、存储加密、备份恢复可控对应到OceanBase上你既要在OMSOceanBase迁移服务或OCPOceanBase管控平台上查看一些界面信息也要通过命令行深入到数据库内部核查实际配置。界面上的东西可能被人改动过、也可能只反映了部分配置命令行查出来的才是实际生效的。我建议大家以命令行核查为主OCP平台配置作为辅助证据。2. 身份鉴别测评登录策略与口令管理实操命令2.1 核查用户的唯一标识和登录方式等保测评第一步会看“是否采用用户名口令等组合鉴别技术”在OceanBase上我们通常检查用户账号是否设置了密码以及能否通过SSH或其他非交互方式绕开数据库认证。# 登录到业务租户示例MySQL模式租户obmysql obclient -h10.10.10.10 -P2881 -urootobmysql#cluster_name -p -c # 查看租户下的所有用户账号 SELECT user_name, host, password_last_changed FROM oceanbase.__all_user WHERE user_name NOT IN (SELECT user_name FROM oceanbase.__all_user WHERE user_name IN (LBACSYS,ORAAUDITOR,ORADBMS_LOGMNR));这里注意__all_user是OceanBase的内部系统表实际查询中我更习惯用视图方式-- MySQL兼容模式 SELECT user, host, password_last_changed FROM mysql.user; -- Oracle兼容模式 SELECT username, account_status, lock_date FROM dba_users;以上命令能查到的结果要逐一核对所有应用账号是否设置了强密码是否禁用了root以外的匿名账号是否存在共享账号现象。我做过一个项目甲方把所有开发人员都用一个账号连库这属于真真实实的高风险不合规项测评报告里被记了高危。共享账号的问题靠命令还查不出来得配合访谈和代码审计看连接串这是等保测评里比较恶心的地方光拿命令结果说话不全面。2.2 登录失败处理与超时锁定核查等保里要求“登录失败处理功能、结束会话、限制非法登录次数和登录超时自动退出”。OceanBase从3.x版本开始支持connection_control插件模拟MySQL的实现逻辑先看插件是否启用-- 查看connection_control相关插件 SHOW PLUGINS; -- 查看登录失败策略参数 SHOW VARIABLES LIKE connection_control%;正常情况下应该能看到这几项connection_control_failed_connections_threshold触发延迟的失败次数阈值通常建议设置成3或5connection_control_min_connection_delay单次失败后最小延迟毫秒数connection_control_max_connection_delay最大延迟毫秒数如果上面的查询结果是空值或参数为0说明登录失败防护没有生效。有些版本需要在启动时加plugin_dir并INSTALL PLUGINOceanBase的MySQL模式支持这个机制Oracle模式暂时没有完全对齐。在测评里如果Oracle模式的租户没有这个能力就要通过应用侧或堡垒机侧的补偿措施来判定。等保专项里有一个很常见的检查方法就是实测连续输错密码。注意不要把管理员账号锁死测评师在项目上真干过这事最后只能找OB的sys租户去解锁场面尴尬但经验值得分享-- 连续输错密码导致用户被锁后管理员可在sys租户执行解锁 ALTER USER testuser ACCOUNT UNLOCK;超时自动退出的参数在OceanBase上主要是会话超时设置-- 查看会话超时时间单位秒 SHOW VARIABLES LIKE ob_trx_idle_timeout; SHOW VARIABLES LIKE wait_timeout;ob_trx_idle_timeout是OceanBase特有的表示事务空闲超时默认120秒等保要求一般建议不超过15分钟。wait_timeout控制非事务会话的超时时间。多数测评项目里能看到默认值但这里有个坑OceanBase连接池通常由应用侧中间件维持长连接数据库层的超时未必真能把连接断开最好在测评报告中描述清楚验证手段避免后续扯皮。2.3 口令复杂度策略检查口令复杂度策略在OceanBase上也是通过变量控制的MySQL模式下支持SHOW VARIABLES LIKE validate_password%;重点关注这四项validate_password_length最小长度等保一般要求不少于8位validate_password_mixed_case_count大小写字母最少数量validate_password_number_count数字最少数量validate_password_special_char_count特殊字符最少数量如果结果是空说明没装validate_password插件。OceanBase官方镜像默认是不启用密码复杂度校验的需要手动配置。我们通常建议在OCP上开启密码策略同时配合PASSWORD_LOCK_TIME这样的锁定配置。Oracle兼容模式的租户里口令复杂度靠profile管理SELECT profile, resource_name, limit FROM dba_profiles WHERE resource_typePASSWORD ORDER BY profile, resource_name;重点看PASSWORD_VERIFY_FUNCTION、FAILED_LOGIN_ATTEMPTS、PASSWORD_LOCK_TIME的取值。我在不少Oracle模式租户里查到的都是DEFAULTprofile然后FAILED_LOGIN_ATTEMPTS值是UNLIMITED这是可以直接判定为不符合的典型情况。3. 访问控制测评权限分离与账号管理3.1 梳理用户角色权限访问控制这块等保关注的是“是否授予管理用户最小权限、是否实现管理用户的权限分离”。OceanBase用户权限包括系统权限、对象权限和角色。把用户、角色、权限摊开来看是检查的核心。-- 查看租户下的所有角色 SELECT * FROM oceanbase.dba_roles; -- 查看所有用户 SELECT * FROM oceanbase.dba_users; -- 查看用户被授予的角色 SELECT * FROM oceanbase.dba_role_privs; -- 查看用户拥有的系统权限 SELECT * FROM oceanbase.dba_sys_privs; -- 查看用户拥有的对象权限 SELECT * FROM oceanbase.dba_tab_privs;MySQL兼容模式下也可以走mysql.user、mysql.db这系列表SELECT * FROM mysql.user; SELECT * FROM mysql.db; SELECT * FROM mysql.tables_priv;核查思路要清晰第一有没有存在root%、xxx%这种允许任意主机登录的账号第二管理类账号如root是不是只给运维使用业务系统账号是否只有DML权限第三是否有用户被赋予了SUPER或全局ALL PRIVILEGES但实际业务根本不需要。有一回我在一个政务项目里发现应用连接账号居然有GRANT ALL PRIVILEGES ON *.*问运维人员怎么回事答复说“当初导数据方便就给了”后边评审会直接被专家点名。线上去查高权限账号时思路是先把所有用户的全局权限拉出来过滤出包含ALL PRIVILEGES或SUPER的记录查到类似情况必须追问授权目的。3.2 清理冗余账号和测试账号等保里对“多余账号”的要求往往容易被忽视实际上评审专家看报告时很爱翻这条。OceanBase的系统租户默认会有一堆内部账号比如ORAAUDITOR、LBACSYS这些它们是系统内置的不能删除也不算多余账号测评时别误报。但业务租户里那些test、demo、tmp之类的账号就要建议清理。-- 找出近期从未登录过的账号需要开启审计后才能判断 SELECT user_name, last_login_time FROM oceanbase.__all_user;不过__all_user里不一定记录了每个账号的最后登录时间更实在的办法是配合审计日志或OCP的登录记录做判断。我们在测评现场一般这样操作先从dba_users里拉出全部账号清单再去OCP用户管理页面比对账号的创建人和用途说明拉出近期无操作记录的账号基本就能识别出长期闲置的“僵尸账号”。这类账号建议在报告里写“限期禁用或删除”。3.3 检查默认口令和弱口令等保有一项专门查“是否已避免使用默认口令”。Oracle数据库有scott/tiger这种著名的默认账号OceanBase上被问得最多的是root账号。OceanBase集群部署时rootsys的密码是部署者设置的但如果项目交付时运维没改或者是初始化脚本里写死了一个通用口令那就是典型的高危风险。实操时我一般先看部署文档或OCP里的密码策略再结合访谈确认root密码是否为强密码。单纯用命令去验证默认口令有点敏感而且现场反复试密码容易触发账号锁定不建议测评师直接暴力尝试除非甲方书面委托你进行弱口令检测。做得更专业一点的团队会用专门的弱口令扫描工具但要注意工具的SQL脚本对OceanBase兼容性参差不齐经常有工具明明连不上或漏报的情况。我的习惯是先用工具扫一遍再人工复核疑似弱口令的账号两轮判定后在报告里交叉取证。4. 安全审计测评审计开关、审计范围与记录保护4.1 检查审计功能的启用状态安全审计是OceanBase等保测评里的绝对重点也是新入行的测评师最容易踩坑的地方。OceanBase的审计分为两类一是数据库内部操作审计需要开启audit_trail参数二是登录审计。只能两个都看缺一个报告都不完整。-- 查看审计相关的参数 SHOW GLOBAL VARIABLES LIKE audit%; -- MySQL模式下查看审计插件 SHOW PLUGINS;正常开启的状态下应该能看到audit_trail参数的值为DB或OSDB表示审计记录写入数据库内部表OS表示写入操作系统文件。很多OB集群刚部署时这个参数是空的等于审计没开。开启审计需要sys租户权限来执行注意下面这个语句在不同版本里有细微差异-- 开启审计session级只对当前租户生效 SET GLOBAL audit_trail DB; -- 更严格一点的配置记录所有执行失败的SQL SET GLOBAL audit_log_archive ON;需要注意的是OceanBase的审计能力是租户隔离的你在业务租户里设置的参数不会影响其它租户测评多个租户时得逐个检查。4.2 查看审计记录内容与覆盖范围审计开没开是一回事审计内容能不能覆盖等保要求的“每个用户”是另一回事。OceanBase里审计记录可以通过视图查询-- 查看数据库审计记录MySQL模式 SELECT * FROM oceanbase.__all_audit_log ORDER BY exec_timestamp DESC LIMIT 20; -- 通过视图查询部分版本支持 SELECT * FROM information_schema.ob_audit_log ORDER BY exec_timestamp DESC LIMIT 20;实操中要重点核对的审计字段包括被审计的操作类型、执行用户、源IP、目标对象、执行时间、SQL文本。如果SQL文本被截断或者记录里缺少源IP就需要调整审计策略。这里有个小技巧OB的审计记录里源IP并不总是准确的因为中间可能存在obproxy转发你很可能记录的是obproxy的地址。测评时如果抓到这样的现象说明需要检查是否开启了obproxy的客户端IP透传否则源IP地址这项证据就不成立。审计日志留存期也常常被检查。等保要求一般建议日志留存不少于6个月。数据库内部审计表的记录会随磁盘空间滚动清理靠命令查看留存时间比较被动我一般让甲方提供OCP上的日志存储配置或备份保留策略来作为证据。很多项目OB审计表默认只保留最近几天的数据这是比较容易出现的短板。4.3 审计记录的保护与防篡改等保条款里有“审计记录应受到保护防止未授权删除、修改或覆盖”。OceanBase的审计日志存在系统表里理论上只有sys租户有权限访问但为了显得更专业测评时我还会额外确认一下-- 查看审计记录相关表是否被普通用户具备访问权限 SELECT grantee, privilege_type FROM information_schema.schema_privileges WHERE table_schemaoceanbase AND table_name LIKE %audit%;如果业务账号对审计表有权限那不管审计开没开都算一项风险点。再进一步看审计日志是否被定期归档通常通过OCP配置日志采集到外部SIEM平台有外部归集的算加分项。补充一个实战细节有一次我核查一个Oracle兼容模式的租户发现dba_audit_trail视图查询报错原因是没有执行DBMS_AUDIT.INIT_AUDIT_TRAIL初始化脚本。这种情况下审计功能本身可能是开的但审计表没有初始化导致记录写不进去。遇到这种情况需要在报告中写清楚是“功能未生效”而不是简单判“不符合”。现场技术人员如果熟悉OB的这套初始逻辑对测评结果是很有帮助的。5. 入侵防范与数据安全专项核查5.1 最小化安装与服务暴露面检查等保的入侵防范控制点里最少要核查数据库软件是否“最小化安装”、是否关闭了不必要的服务和端口。OceanBase比较特殊不存在传统MySQL那种“安装组件可选勾选”的概念但暴露面检查依然有活可干查看OceanBase集群对外开放的端口默认是2881客户端通信、2882节点间通信、8080obproxy等检查obproxy是否暴露在公网或非受信网络检查操作系统层防火墙状态确认2881端口只对应用服务器网段开放# 在observer节点上查看监听端口及对应进程 netstat -tunlp | grep -E 2881|2882 # 查看防火墙策略 iptables -L -n | grep 2881实际等保测评里测评师还会抽查observer节点上是否绑定了非业务IP。分布式数据库集群的节点IP往往由部署配置文件统一管理修改起来比较麻烦所以有的项目图省事把节点IP暴露在了办公网段这种不合规情况我在测评里见过不止一次。5.2 补丁与版本核查等保要求“应及时安装安全补丁”。OceanBase作为国产数据库补丁发布节奏和Oracle这类商业库不同它的版本迭代相当快。判断补丁是否及时实际上要看的是版本号和发布时间-- 查看OceanBase数据库版本 SELECT version(); -- 查看observer内核版本命令行 observer -V在测评报告里写“版本较新”不如明确记录主版本号和发布时间再补一句“建议持续关注官方发布的安全公告”。我见过最极端的案例某个项目还在用OceanBase 2.2.x的老版本上线都三年了没人升级跟官方最新版本差了三个大版本数据库层存在已知漏洞也没人管。这个如果不记进整改清单以后出了事测评机构是有责任的。5.3 传输加密与存储加密核查数据完整性和保密性部分OceanBase支持两层加密传输层SSL/TLS加密和存储层透明加密TDE。测评时两边都要查。传输加密检查-- 查看SSL相关参数 SHOW VARIABLES LIKE ssl%; SHOW VARIABLES LIKE ob_ssl%; -- 查看当前会话是否使用SSL连接 SHOW STATUS LIKE Ssl_cipher;如果Ssl_cipher为空说明当前连接没有走加密通道。注意一点即使数据库端开了SSL客户端连接串里没有指定ssl属性实际通信依然可能是明文。所以报告里最好同时记录服务端参数和客户端连接配置缺哪边都算“不合规”。存储加密检查-- 查看TDE加密状态不同版本视图名略有差异 SELECT * FROM oceanbase.__encrypt_table;OceanBase的透明表空间加密使用tde功能开启后需要配置密钥管理。测评时很多甲方说“我们开启了加密”结果一看只对个别表加密整个数据目录并没有全加密磁盘拖走照样能读数据。判断存储加密是否符合标准不是“有没有开TDE”而是“核心数据是否都被加密覆盖”。我一般建议测评师在OB集群的obdata目录抽查几个sstable文件# 在observer节点上查看数据文件是否加密加密后文件头标记会有不同 strings -a sstable文件路径 | grep -i encrypted这条命令的效果在不同版本上有差异但它至少能给评审专家展示你做了深层验证。5.4 备份与恢复策略核查数据安全这块还会看备份机制是否可靠。OceanBase的备份推荐用官方的备份恢复工具或者OCP的备份功能逻辑备份可以用obdumper。测评时我会核查# 查看是否配置了定时备份OCP界面或命令行 # OCP平台备份任务里看备份策略、备份窗口、保留周期命令行层面备份目录和归档日志可以通过系统表查看-- 查看备份信息 SELECT * FROM oceanbase.__all_backup_task; -- 查看归档状态 SELECT * FROM oceanbase.__all_backup_archive;如果这些表查出来是空的基本说明这个集群从部署到现在没做过数据库级备份而只靠底层存储快照这在等保评审里通常只能算补偿措施不能完全替代应用级备份。恢复能力验证更特殊绕不开实操演练测评报告里可以记录“甲方近一年是否进行过恢复演练”有演练报告最好复印留存。6. 常见问题与排查技巧实录6.1 权限不够导致命令执行报错排查等保命令时最常遇到的就是权限不足。OceanBase的运维账号和系统账号的权限管理很严格普通租户的账号哪怕有all privileges也有可能查不到oceanbase库下面的视图。遇到ERROR 4014之类的报错切换成sys租户的root账号基本就能解决如果还不行再检查账号是否通过obproxy连接有些系统视图在obproxy链路下返回不全。# 通过直连observer节点的方式连接绕过obproxy避免路由问题 obclient -hobserver_ip -Pobserver_port -urootsys#cluster_name -p -c SHOW PARAMETERS LIKE %audit%;6.2 视图在不同兼容模式下报错同样的检查项MySQL兼容租户下用information_schema查参数Oracle兼容租户下却查不到这种情况很常见。比如SHOW VARIABLES语句在Oracle模式租户下不是不支持而是返回的结果集字段名大小写敏感脚本解析容易出错。我们在项目里会为两种兼容模式各维护一份命令清单执行前先确认租户模式避免现场手忙脚乱。-- Oracle兼容模式下查询参数的方式 SELECT * FROM sys.parameter_effective WHERE name LIKE %audit%;6.3 审计表被误清理过OceanBase某个版本后系统表自动清理策略有变化曾经有客户遇到“审计开着但记录只有当天的”最后查出来是OCP上配置了历史数据清理任务。碰到审计数据保留期不足的情况查一下oceanbase.__all_variable里的清理策略参数把它写进整改建议。6.4 密码复杂度插件版本影响之前在某项目里执行SHOW VARIABLES LIKE validate_password%返回空我们一度以为租户没启用密码策略。查了OCP才发现密码复杂度是在OCP的密码策略里配置的数据库层确实没有启用插件。也就是说这类检查结果要以OCP策略和数据库变量两者结合来看不能一棍子打死。OceanBase 4.x版本中密码复杂度策略逐步向系统参数统一新的项目建议直接查password_length_min这类系统参数。6.5 多租户环境下漏查租户等保对象如果是一个OceanBase集群那么所有业务租户都要单独核查一遍不能只查默认的sys租户或者第一个业务租户。我有过一次教训现场只查了核心交易租户漏了另一个数据分析类租户后来客户自查时发现那个租户的审计根本没开只能补充整改后复查。这种漏项在质控环节很致命测评前就要规划好租户清单把每个租户的检查结果单独记录。一套实测下来最大的感受是等保测评命令本身并不复杂复杂的是你得先搞懂OceanBase的架构逻辑。它像一个多租户的大楼不同楼层用的钥匙不一样查配置要进对房间看日志要找对文件。把身份鉴别、访问控制、审计、入侵防范、数据保护这几大类命令都跑一遍再配合OCP平台的操作记录整个数据库层面的证据链就完整了。最后再给个小建议OceanBase版本升级很快不同版本之间系统视图和参数名称可能变化做项目前先确认版本拿到对应版本文档再动手能省下不少现场踩坑的时间。