1. 引言
大家好，欢迎来到"每天10分钟学会OceanBase"的第21天！
回顾过去的20天，我们一路打怪升级，从部署集群、建表查询，到性能优化、数据备份，再到跨机房容灾，你的OceanBase技能树已经点亮了大半。但是，不知道你有没有想过一个问题：如果黑客拿到了你的数据库密码，或者内网里有个"手滑"的同事执行了 DROP DATABASE，你之前辛辛苦苦建的容灾架构还能撑得住吗？
这就好比你在银行建了一个坚不可摧的金库，不仅装了防爆门，还配了双路供电，但金库的大门却忘了上锁。不加固的数据库，就像没装锁的金库，里面的数据随时可能裸奔。今天，我们就来给OceanBase穿上"防弹衣"，把安全这块短板彻底补齐！
2. 核心概念：数据库安全的三大支柱
在动手实操前，我们先搞懂数据库安全的底层逻辑。数据库安全主要靠三大支柱： - 身份认证（Authentication） ：你是谁？（比如：刷脸进门、输入密码） - 权限控制（Authorization） ：你能干嘛？（比如：普通员工只能看不能改，保安可以进机房） - 审计（Audit）：你干了啥？（比如：监控录像，事后追责）
在OceanBase中，有几个非常核心的安全机制需要大家记住： - 租户级安全模型 ：OceanBase是多租户架构，每个租户就像一个独立的"沙箱"，租户之间的网络、资源、数据是完全隔离的，互不干扰。 - 角色（Role）机制 ：不要给每个用户单独配权限，而是把权限打包成"角色"（比如：只读角色、DBA角色），然后把角色分配给用户，管理起来既清晰又安全。 - 白名单机制：这是OceanBase的一道"护城河"。你可以指定哪些IP地址允许连接数据库，不在白名单里的IP，就算密码正确也连不上。
3. 10分钟实操：5步给数据库穿上防弹衣
接下来，我们用5个步骤，在OceanBase中完成一次完整的安全加固演练。
步骤1：创建数据库用户并设置密码策略
首先，创建一个专门的业务用户，并强制要求密码复杂度。
-- 创建用户，要求密码包含大小写字母、数字和特殊字符，且长度不少于8位
CREATE USER app_user IDENTIFIED BY 'App@2024Secure!';
步骤2：配置白名单（允许哪些IP访问）
通过修改租户变量，限制只有特定网段的机器才能访问。
-- 假设只允许 192.168.1.0/24 网段和 10.0.0.5 访问
ALTER SYSTEM SET ob_tcp_invited_nodes='192.168.1.%,10.0.0.5' TENANT = 'your_tenant';
步骤3：使用最小权限原则分配权限
千万别直接给业务账号 ALL PRIVILEGES！
-- 1. 创建只读角色
CREATE ROLE role_read_only;
GRANT SELECT ON db_name.* TO role_read_only;
-- 2. 将角色分配给用户
GRANT role_read_only TO app_user;
-- 3. 如果发现权限给多了，随时收回
REVOKE role_read_only FROM app_user;
步骤4：开启审计日志，查看审计记录
让数据库开启"监控录像"，记录谁在什么时间执行了什么高危操作。
-- 开启全局审计（记录所有DDL操作）
ALTER SYSTEM SET ob_enable_audit_log = 'ALL';
-- 查看审计日志（在sys租户下执行）
SELECT * FROM oceanbase.CDB_AUDIT_RECORD ORDER BY timestamp DESC LIMIT 10;
步骤5：修改高危操作密码强度，启用SSL加密连接
防止数据在网络传输中被窃听。
-- 在启动参数或配置文件中开启SSL（需提前配置好证书）
-- 客户端连接时指定SSL参数：
-- mysql -h127.0.0.1 -P2881 -uapp_user -p --ssl-mode=REQUIRED
4. 安全加固最佳实践
在生产环境中，光会敲命令还不够，以下4条最佳实践请务必刻在脑子里： 1. 严格执行密码策略 ：定期强制修改密码，禁止使用弱口令，密码绝不能明文写在代码或配置文件里。 2. 定期权限审计 ：每个月拉一次权限清单，看看有没有离职员工的账号没删，有没有人偷偷拿了DBA权限。 3. 禁用默认账户 ：安装完数据库后，第一时间锁定或删除不需要的默认测试账号。 4. 网络物理隔离 ：数据库服务器千万不要暴露在公网，必须放在内网，且通过跳板机或堡垒机进行运维访问。 5. 敏感数据加密：对于身份证号、密码等核心数据，应用层要哈希或加密后再存入数据库。
5. OceanBase特有安全优势
相比传统数据库，OceanBase在安全方面有几个"杀手锏"： - 租户级隔离的安全边界 ：多租户架构天然自带安全属性，即使某个租户被攻破，攻击者也极难穿透到物理机或其他租户，实现了真正的"沙箱级"防护。 - 透明数据加密（TDE） ：OceanBase支持TDE，数据在落盘时自动加密，读取时自动解密。就算黑客把硬盘偷走，拿到的也只是一堆乱码。 - SQL审计与合规报表：内置强大的审计引擎，不仅记录操作，还能自动生成符合等保2.0等合规要求的报表，省去大量人工整理的时间。
6. 运维避坑指南
安全无小事，这4个坑千万别踩： 1. 不要共用账号 ：开发、测试、运维、业务，必须一人一号。出了问题连日志都没法精准定位到人。 2. 定期清理孤儿账户 ：项目下线了、员工离职了，对应的数据库账号和权限一定要及时回收。 3. 审计日志不要关 ：有些DBA嫌审计日志占空间就关掉，这是大忌！真出事了，没有日志就等于"死无对证"。 4. 密码不要写在代码里：硬编码是安全大忌，请使用环境变量或专门的密钥管理服务（KMS）来管理连接字符串。
7. 今日小结
数据库安全不是买一个防火墙就万事大吉，而是通过身份认证、权限控制、审计三位一体，结合白名单、TDE加密等手段，构建起立体的防御体系。
8. 课后思考
今天我们开启了审计日志，记录了所有的操作。但是，如果黑客或者内鬼拥有了极高权限，把审计日志给篡改了或者删除了，我们该怎么发现？又该怎么恢复呢？
带着这个问题，我们明天（Day 22）将进入《OceanBase日志排查与故障诊断》，看看当系统真的"生病"甚至"被黑"时，我们该如何通过底层日志抽丝剥茧，找出真凶！