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;看是否存在rootsys且从未改过口令再查ob_password_complexity参数当前值。初始化部署时该参数默认不强制复杂度意味着 123456 级别的口令能直接通过。判定标准rootsys必须使用自定义强口令ob_password_complexity取值 3口令需同时包含大写字母、小写字母、数字、特殊字符四类字符。任一不满足即 P0。处置动作修改系统管理员口令并收紧复杂度策略两条命令一次到位ALTER USER rootsys 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_user10.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现状诊断TDETransparent Data Encryption指数据库落盘时自动加密、读取时自动解密DBA 和业务无感知。检查各节点enable_ss参数是否全部为 true。判定标准集群所有 observer 节点enable_ss true磁盘文件数据目录、备份件被直接拷走时应为不可读密文。任一节点关闭即 P1。处置动作配置好 TDE 密钥后开启存储加密ALTER SYSTEM SET enable_ss true;验证方式直接查看数据目录下文件内容应为不可读的二进制密文同时把密钥轮换周期建议 ≤ 90 天纳入 P2 台账跟踪。05 通道威胁面端口收敛与连接来源限制05.1 端口收敛现状诊断OceanBase 常规开放 2881MySQL 协议端口与 2882RPC 端口。先用下面的命令确认本机监听与来源情况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_user10.20.% IDENTIFIED BY Str0ng_Pwd!2026;验证方式从网段外主机使用该账号登录应直接拒绝存量%账号按业务出口 IP 逐批改造每改一批复验一次。06 运维威胁面审计留痕与工具入口06.1 SQL 审计开关现状诊断查询enable_sql_audit参数。关闭状态下DDL 与高危 DML 不产生审计记录事后追问谁在凌晨改过表结构只能翻业务日志碰运气。判定标准生产集群enable_sql_audit true且审计范围默认覆盖 DDLDROP 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 rootsys -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身份rootsys 口令已改强口令且复杂度3P0□未开始 □进行中 □已验证T-ID-02身份业务账号 DDL 权限DROP/ALTER 持有数0P1□未开始 □进行中 □已验证T-DA-01数据链路 TLS抽查连接协商出非空套件P1□未开始 □进行中 □已验证T-DA-02数据存储加密 enable_ss全部节点trueP1□未开始 □进行中 □已验证T-NW-01通道2882 端口来源仅集群网段可达P0□未开始 □进行中 □已验证T-NW-02通道账号 host 模式% 业务账号数0P1□未开始 □进行中 □已验证T-OP-01运维SQL 审计开关enable_sql_audittrueP0□未开始 □进行中 □已验证T-OP-02运维审计留存归档可还原≥180天P1□未开始 □进行中 □已验证T-OP-03运维ob_admin 调用管控100% 走 sudo 白名单P2□未开始 □进行中 □已验证把下一季度的首扫命令排进日历基线就从一份文档变成了会自己转的循环。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 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;看是否存在rootsys且从未改过口令再查ob_password_complexity参数当前值。初始化部署时该参数默认不强制复杂度意味着 123456 级别的口令能直接通过。判定标准rootsys必须使用自定义强口令ob_password_complexity取值 3口令需同时包含大写字母、小写字母、数字、特殊字符四类字符。任一不满足即 P0。处置动作修改系统管理员口令并收紧复杂度策略两条命令一次到位ALTER USER rootsys 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_user10.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现状诊断TDETransparent Data Encryption指数据库落盘时自动加密、读取时自动解密DBA 和业务无感知。检查各节点enable_ss参数是否全部为 true。判定标准集群所有 observer 节点enable_ss true磁盘文件数据目录、备份件被直接拷走时应为不可读密文。任一节点关闭即 P1。处置动作配置好 TDE 密钥后开启存储加密ALTER SYSTEM SET enable_ss true;验证方式直接查看数据目录下文件内容应为不可读的二进制密文同时把密钥轮换周期建议 ≤ 90 天纳入 P2 台账跟踪。05 通道威胁面端口收敛与连接来源限制05.1 端口收敛现状诊断OceanBase 常规开放 2881MySQL 协议端口与 2882RPC 端口。先用下面的命令确认本机监听与来源情况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_user10.20.% IDENTIFIED BY Str0ng_Pwd!2026;验证方式从网段外主机使用该账号登录应直接拒绝存量%账号按业务出口 IP 逐批改造每改一批复验一次。06 运维威胁面审计留痕与工具入口06.1 SQL 审计开关现状诊断查询enable_sql_audit参数。关闭状态下DDL 与高危 DML 不产生审计记录事后追问谁在凌晨改过表结构只能翻业务日志碰运气。判定标准生产集群enable_sql_audit true且审计范围默认覆盖 DDLDROP 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 rootsys -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身份rootsys 口令已改强口令且复杂度3P0□未开始 □进行中 □已验证T-ID-02身份业务账号 DDL 权限DROP/ALTER 持有数0P1□未开始 □进行中 □已验证T-DA-01数据链路 TLS抽查连接协商出非空套件P1□未开始 □进行中 □已验证T-DA-02数据存储加密 enable_ss全部节点trueP1□未开始 □进行中 □已验证T-NW-01通道2882 端口来源仅集群网段可达P0□未开始 □进行中 □已验证T-NW-02通道账号 host 模式% 业务账号数0P1□未开始 □进行中 □已验证T-OP-01运维SQL 审计开关enable_sql_audittrueP0□未开始 □进行中 □已验证T-OP-02运维审计留存归档可还原≥180天P1□未开始 □进行中 □已验证T-OP-03运维ob_admin 调用管控100% 走 sudo 白名单P2□未开始 □进行中 □已验证把下一季度的首扫命令排进日历基线就从一份文档变成了会自己转的循环。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考