案例：安全审计，发现 4 个 SUPER 权限账号和远程 root¶
场景背景¶
- 时间：2026-06-18 上午（季度合规检查）
- 角色：安全工程师，负责数据库权限合规审计
- 背景：公司刚通过等保 2.0 初评，数据库权限管理是扣分项
- 目标：用 dbskiter 全盘扫描安全风险，输出合规报告
生活化比喻：数据库账号就像公司门禁卡。SUPER 权限是"万能钥匙"，远程 root 是"把老板钥匙挂在门口"。安全审计就是检查谁拿了万能钥匙、谁把钥匙带出了公司。
执行步骤¶
1. 一键安全审计（1 分钟）¶
dbskiter --database=jump security audit
输出摘要：
安全审计结果：
==============================
[通过] 空用户名检查：0 个
[通过] 无密码用户检查：0 个
[通过] 匿名用户检查：0 个
[通过] test 数据库检查：0 个
[通过] SSL 连接检查：已启用
[警告] SUPER 权限用户：4 个
[警告] 远程 root 访问：1 个
[INFO] 大字段分布：10 个字段 / 6 张表
2. 详细权限审计（2 分钟）¶
dbskiter --database=jump security permissions
详细输出：
权限审计详情：
用户: root@%
权限: ALL PRIVILEGES, SUPER, GRANT OPTION
风险等级: CRITICAL
说明: 允许从任意 IP 远程连接，拥有最高权限
用户: app_admin@10.0.%.%
权限: SUPER, RELOAD, PROCESS
风险等级: HIGH
说明: 应用账号拥有 SUPER 权限，超出最小权限原则
用户: backup_user@localhost
权限: SUPER, REPLICATION CLIENT
风险等级: MEDIUM
说明: 备份账号需要 SUPER 做一致性备份，但建议限制为 REPLICATION SLAVE
用户: monitor@10.0.0.10
权限: SUPER, PROCESS
风险等级: HIGH
说明: 监控账号需要 PROCESS 查线程，但 SUPER 可修改配置，风险过高
3. 弱密码扫描（1 分钟）¶
dbskiter --database=jump security weak-passwords
结果：
弱密码扫描：
[通过] 未发现弱密码用户
[通过] 未发现空密码用户
[INFO] 密码策略检查：
- validate_password.policy: MEDIUM
- validate_password.length: 8
- 建议：升级到 STRONG，长度 >= 12
4. 敏感数据扫描（2 分钟）¶
dbskiter --database=jump security sensitive-data
发现结果：
敏感数据扫描：
[高] 表: users
字段: phone (手机号) → 样本: 138****1234
字段: id_card (身份证号) → 样本: 310***********1234
建议: 建议加密或脱敏存储
[高] 表: orders
字段: receiver_phone (收货手机号) → 样本: 139****5678
建议: 建议脱敏或单独加密存储
[中] 表: payment_logs
字段: card_last4 (银行卡后四位) → 样本: ****6789
说明: 已脱敏，符合规范
[中] 表: logs
字段: content (日志内容) → 可能包含敏感信息
建议: 增加日志脱敏规则，过滤手机号、身份证
总计：4 张表含敏感数据，2 张需整改
5. SQL 注入风险检测（2 分钟）¶
dbskiter --database=jump security sql-injection "
SELECT * FROM users WHERE username = '${username}' AND password = '${password}'
"
检测结果：
[CRITICAL] 发现 SQL 注入风险：
类型：字符串拼接注入
位置：WHERE username = '${username}'
风险：攻击者可输入 ' OR '1'='1 绕过认证
修复建议：
1. 使用参数化查询（PreparedStatement）
2. 输入校验：只允许字母数字下划线
3. 最小权限：应用账号禁止 DROP/DELETE
整改方案与实施¶
优先级 1：远程 root（当天修复）¶
-- 步骤 1：删除远程 root 用户（危险！先确认有本地 root 或其他管理员）
DROP USER 'root'@'%';
-- 步骤 2：确保本地 root 存在
SELECT user, host FROM mysql.user WHERE user = 'root';
-- 预期结果：应有 'root'@'localhost'，无 'root'@'%'
-- 步骤 3：新建管理员账号（仅限特定 IP）
CREATE USER 'dba'@'10.0.0.100' IDENTIFIED BY 'StrongP@ssw0rd!2026';
GRANT ALL PRIVILEGES ON jump.* TO 'dba'@'10.0.0.100';
FLUSH PRIVILEGES;
优先级 2：SUPER 权限回收（本周内）¶
-- 应用账号 app_admin：去掉 SUPER，保留必要权限
REVOKE SUPER ON *.* FROM 'app_admin'@'10.0.%.%';
GRANT SELECT, INSERT, UPDATE, DELETE ON jump.* TO 'app_admin'@'10.0.%.%';
-- 监控账号 monitor：去掉 SUPER，只保留 PROCESS
REVOKE SUPER ON *.* FROM 'monitor'@'10.0.0.10';
GRANT PROCESS ON *.* TO 'monitor'@'10.0.0.10';
-- 备份账号 backup_user：SUPER 改 REPLICATION SLAVE
REVOKE SUPER ON *.* FROM 'backup_user'@'localhost';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'backup_user'@'localhost';
GRANT SELECT ON jump.* TO 'backup_user'@'localhost';
FLUSH PRIVILEGES;
优先级 3：敏感数据加密（1 周内）¶
-- 方案：使用 MySQL 透明数据加密（TDE）或应用层加密
-- 示例：应用层加密 phone 字段（需修改业务代码）
-- 或：创建脱敏视图给分析人员
CREATE VIEW users_safe AS
SELECT
id,
username,
CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) AS phone,
CONCAT(LEFT(id_card, 4), '**********', RIGHT(id_card, 4)) AS id_card
FROM users;
-- 限制分析师只能访问脱敏视图
GRANT SELECT ON jump.users_safe TO 'analyst'@'10.0.%.%';
REVOKE SELECT ON jump.users FROM 'analyst'@'10.0.%.%';
验证整改效果¶
# 重新审计，确认问题已修复
dbskiter --database=jump security audit
预期结果：
[通过] SUPER 权限用户：0 个（原来是 4 个）
[通过] 远程 root 访问：0 个（原来是 1 个）
[通过] 弱密码：0 个
[通过] 匿名用户：0 个
剩余风险：
[INFO] 敏感数据：2 张表需加密（users, orders）→ 需业务配合，1 周内完成
[INFO] 密码策略：建议升级到 STRONG
合规报告模板¶
【数据库安全审计报告】2026 Q2
数据库：jump（MySQL 8.0.32）
审计时间：2026-06-18
审计工具：dbskiter security audit
一、整体评分
安全评分：82 / 100（良好）
已修复风险：2 项（远程 root、SUPER 权限滥用）
剩余风险：2 项（敏感数据未加密、密码策略中等）
二、发现与整改
| 序号 | 风险项 | 风险等级 | 整改前 | 整改后 | 状态 |
|------|--------|---------|--------|--------|------|
| 1 | 远程 root 访问 | CRITICAL | 1 个 | 0 个 | 已修复 |
| 2 | SUPER 权限用户 | HIGH | 4 个 | 0 个 | 已修复 |
| 3 | 敏感数据未加密 | HIGH | 2 张表 | - | 进行中 |
| 4 | 密码策略中等 | MEDIUM | MEDIUM | - | 计划中 |
三、合规结论
- 已满足等保 2.0 数据库访问控制基本要求
- 建议：补充数据加密和审计日志留存 6 个月
四、下一步计划
- 2026-06-25：完成 users、orders 表敏感字段加密
- 2026-07-01：升级密码策略为 STRONG
- 2026-07-15：启用 general log 做操作审计
复盘要点¶
1. 权限最小化原则¶
| 角色 | 需要权限 | 禁止权限 |
|---|---|---|
| 应用账号 | SELECT, INSERT, UPDATE, DELETE | SUPER, DROP, GRANT |
| 监控账号 | PROCESS, SELECT | SUPER, DELETE, DROP |
| 备份账号 | SELECT, REPLICATION SLAVE | SUPER, DELETE, DROP |
| DBA 账号 | ALL（仅限特定 IP） | - |
2. 安全审计频率¶
| 频率 | 检查项 | 命令 |
|---|---|---|
| 每日 | 登录安全（暴力破解） | security login-security |
| 每周 | 权限变更审计 | security audit-log |
| 每月 | 全盘安全扫描 | security audit |
| 季度 | 敏感数据扫描 | security sensitive-data |
| 上线前 | SQL 注入检测 | security sql-injection |
3. 常见误区¶
| 误区 | 正确做法 |
|---|---|
| "root 方便，大家都用" | root 仅限本地 DBA，应用和监控用独立账号 |
| "SUPER 权限给备份没问题" | 备份只需 REPLICATION SLAVE，不需要 SUPER |
| "密码复杂就行，不用定期换" | 定期扫描弱密码，启用密码过期策略 |
| "敏感数据加密影响性能" | 只对高敏感字段加密，或用脱敏视图 |
| "SQL 注入是开发的事，DBA 不管" | DBA 应定期扫描存储过程和应用程序 SQL |
延伸阅读¶
- 案例：月度巡检实战
- 案例：业务卡顿查慢查询
- dbskiter 命令：
security audit、security permissions、security weak-passwords、security sensitive-data、security sql-injection