180 lines
9.8 KiB
Markdown
180 lines
9.8 KiB
Markdown
# SQL-Platform-Pro 优化清单
|
||
|
||
> 基于当前实现状态（commit 39ffc14）的差距分析，按优先级 P0/P1/P2 分级。
|
||
> 状态标记：🟢已有基础 🟡部分实现 🔴未实现
|
||
|
||
---
|
||
|
||
## 一、假阳性/假阴性治理
|
||
|
||
### 现状
|
||
- MySQL 117 条审核规则（DDL-036 + DML 等），已持久化到 DB + 前端可调 severity/enabled
|
||
- 已做一轮降级（9 条 ERROR→WARNING），但缺少「为什么误报」的反馈闭环
|
||
- PostgreSQL / Redis / MongoDB 审核规则薄弱（PG 少量、Redis 仅 FLUSHDB 拦截、MongoDB 无专用规则）
|
||
|
||
### 优化项
|
||
|
||
| # | 优先级 | 内容 | 现状 | 工作量 |
|
||
|---|--------|------|------|--------|
|
||
| 1.1 | **P0** | **审核结果反馈机制** — 审批人在审批时可标记某条 finding 为「误报」，记录到 `audit_feedback` 表（rule_code, ticket_id, feedback_type, reason），月度统计误报率 TOP10 规则 | 🔴 | 2d |
|
||
| 1.2 | **P0** | **上下文感知规则** — `ALTER TABLE ADD INDEX` 在小表（<1万行）应 WARNING 而非 ERROR；连接目标库查 `table_rows` 动态调整 severity | 🔴 | 3d |
|
||
| 1.3 | **P1** | **规则分组白名单** — 支持实例级别禁用/调整规则（如测试环境放宽所有 DDL 规则），`instance_rule_override` 表 | 🔴 | 2d |
|
||
| 1.4 | **P1** | **PG 审核规则补全** — 参照 MySQL 规则体系，补齐 PG 特有规则（SERIAL 滥用、JSONB 无索引、VACUUM 建议、大对象等） | 🟡 | 3d |
|
||
| 1.5 | **P2** | **MongoDB 审核规则** — Pipeline 复杂度限制、`$where`/`eval` 禁止、`dropDatabase` 拦截、索引建议 | 🔴 | 3d |
|
||
| 1.6 | **P2** | **规则测试基准** — 每条规则至少 3 个 case（正常通过/应拦截/边界），CI 自动验证规则回归 | 🔴 | 3d |
|
||
|
||
---
|
||
|
||
## 二、大 SQL / 复杂语句处理
|
||
|
||
### 现状
|
||
- `_split_statements()` 用 sqlparse 切割多条 SQL
|
||
- 无 SQL 长度/复杂度上限（有 `max_query_length` 但仅查长度）
|
||
- MongoDB Pipeline 无复杂度检查
|
||
|
||
### 优化项
|
||
|
||
| # | 优先级 | 内容 | 现状 | 工作量 |
|
||
|---|--------|------|------|--------|
|
||
| 2.1 | **P1** | **SQL 复杂度评分** — 解析 JOIN 数量、子查询嵌套层数、UNION 数量，超过阈值（可配置）提升 risk_level | 🔴 | 2d |
|
||
| 2.2 | **P1** | **审核超时保护** — 单条 SQL 审核超过 5s 自动跳过（标记 timeout），避免正则/解析卡死 | 🔴 | 1d |
|
||
| 2.3 | **P1** | **审核缓存** — 相同 SQL 文本（去空格后 hash）短期不重复审核，LRU 缓存 1000 条 | 🔴 | 1d |
|
||
| 2.4 | **P2** | **MongoDB Pipeline 复杂度** — 限制 stage 数量（默认 20）、`$lookup` 嵌套层数、`$group` 内存风险 | 🔴 | 2d |
|
||
| 2.5 | **P2** | **SQL 格式化展示** — 审核详情中高亮问题位置（行号+列号），用 sqlparse 格式化 | 🔴 | 1d |
|
||
|
||
---
|
||
|
||
## 三、事务一致性（多条 SQL 原子性）
|
||
|
||
### 现状
|
||
- MySQL 执行有 `conn.rollback()` 失败回滚
|
||
- PG 执行有 `transaction()` 包裹
|
||
- 但 **跨库没有事务**，同库多条 SQL 部分成功部分失败时缺少明确的补偿机制
|
||
- Redis/MongoDB 多命令无事务概念（Redis 有 MULTI/EXEC 但未使用）
|
||
|
||
### 优化项
|
||
|
||
| # | 优先级 | 内容 | 现状 | 工作量 |
|
||
|---|--------|------|------|--------|
|
||
| 3.1 | **P0** | **执行进度透明** — 多条 SQL 逐条执行，每条记录 status( pending/running/success/failed )，前端实时展示 | 🟡 | 3d |
|
||
| 3.2 | **P0** | **部分失败处理策略** — 可选：`stop_on_error`（默认，遇错停止）/ `continue_on_error`（跳过失败继续）/ `transaction`（整体回滚） | 🔴 | 2d |
|
||
| 3.3 | **P1** | **自动回滚 SQL 生成** — INSERT→DELETE、UPDATE→反向 UPDATE、DDL→DROP/ALTER REVERSE，记录到 `rollback_sql` 字段 | 🔴 | 5d |
|
||
| 3.4 | **P1** | **Redis MULTI/EXEC** — 工单中多条 Redis 命令用 pipeline 批量执行，保证原子性 | 🔴 | 1d |
|
||
| 3.5 | **P2** | **跨库事务标记** — 跨库工单标注「无原子性保障」警告，审批人二次确认 | 🔴 | 1d |
|
||
|
||
---
|
||
|
||
## 四、锁表与业务影响分析
|
||
|
||
### 现状
|
||
- 有工单执行锁（防并发执行同一工单）
|
||
- **无 EXPLAIN 预估**、无影响行数预估、无锁表风险提示
|
||
- 无大表 ALTER 的 pt-osc / gh-ost 建议
|
||
|
||
### 优化项
|
||
|
||
| # | 优先级 | 内容 | 现状 | 工作量 |
|
||
|---|--------|------|------|--------|
|
||
| 4.1 | **P0** | **EXPLAIN 预检** — 审核阶段对 DML 执行 EXPLAIN（MySQL）/ EXPLAIN ANALYZE（PG），提取 `rows` 预估扫描行数，超过阈值（可配置，默认 10 万）标 ERROR | 🔴 | 3d |
|
||
| 4.2 | **P0** | **大表 ALTER 检测** — 查 `information_schema.tables` 获取表行数，大表（>10万行）ALTER 时提示「建议使用 pt-online-schema-change / gh-ost」，risk_level=high | 🔴 | 2d |
|
||
| 4.3 | **P1** | **影响行数预估** — DML 工单执行前用 `SELECT COUNT(*) FROM ... WHERE <condition>` 预估影响行数，超过阈值（默认 1 万）强制高等级审批 | 🔴 | 2d |
|
||
| 4.4 | **P1** | **执行时间预估** — 基于 EXPLAIN 的 rows × 历史执行平均耗时，给出粗略预估（快<1s / 中<30s / 慢>30s / 极慢>5min） | 🔴 | 2d |
|
||
| 4.5 | **P2** | **执行超时强杀** — MySQL `max_execution_time` / PG `statement_timeout` 硬超时，超时自动 KILL 并标记 failed | 🟡 | 1d |
|
||
| 4.6 | **P2** | **维护窗口控制** — 可配置允许执行 DDL 的时间窗口（如凌晨 2-5 点），窗口外提交自动拒绝 | 🔴 | 1d |
|
||
|
||
---
|
||
|
||
## 五、敏感操作审核强化
|
||
|
||
### 现状
|
||
- DROP TABLE → 审核规则 ERROR（DDL-004）
|
||
- Redis FLUSHDB/FLUSHALL → 仅限 admin
|
||
- **但审批只有一级**（任意 admin/dba 可批），无多级审批
|
||
- 无风险等级区分（所有工单走同一审批流）
|
||
|
||
### 优化项
|
||
|
||
| # | 优先级 | 内容 | 现状 | 工作量 |
|
||
|---|--------|------|------|--------|
|
||
| 5.1 | **P0** | **工单风险等级** — 根据 SQL 类型 + 操作对象自动计算 risk_level(low/medium/high/critical)：DROP/TRUNCATE/FLUSHDB=critical，大表 ALTER=high，普通 DML=medium，SELECT=low | 🔴 | 2d |
|
||
| 5.2 | **P0** | **多级审批流** — risk_level=high 需要 2 人审批（DBA+管理员），critical 需要 3 人审批（DBA+管理员+CTO 或指定人），利用现有 WorkflowStep 模型 | 🟡 | 3d |
|
||
| 5.3 | **P1** | **高危操作二次确认** — critical 级别工单执行前，执行人必须输入工单编号确认（防误操作） | 🔴 | 1d |
|
||
| 5.4 | **P1** | **敏感表保护** — 配置「保护表清单」（如 user/password/order/pay），对这些表的任何 DML/DDL 自动提升 risk_level，额外审批 | 🔴 | 2d |
|
||
| 5.5 | **P2** | **执行前备份** — critical 工单执行前自动备份受影响表（`CREATE TABLE xxx_backup AS SELECT *`），备份保留可配置天数 | 🔴 | 3d |
|
||
| 5.6 | **P2** | **MongoDB 危险操作** — `dropDatabase`、`dropCollection`、`remove({})` 拦截 + 多级审批 | 🔴 | 1d |
|
||
|
||
---
|
||
|
||
## 六、数据脱敏与审计
|
||
|
||
### 现状
|
||
- `MaskingRule` 模型已有（full/partial/hash/truncate/regex 5 种类型）
|
||
- 查询接口有 `DataMasker` 应用脱敏
|
||
- 审计日志 `AuditLog` 记录操作
|
||
- **但审核详情中 SQL 可能看到生产敏感数据**、通知中可能泄露信息
|
||
|
||
### 优化项
|
||
|
||
| # | 优先级 | 内容 | 现状 | 工作量 |
|
||
|---|--------|------|------|--------|
|
||
| 6.1 | **P0** | **通知脱敏** — 通知消息中的 SQL 内容截断（>200 字符只显示前 100 + ...），隐藏 WHERE 中的值（如 `phone='138****1234'`） | 🔴 | 1d |
|
||
| 6.2 | **P1** | **审核日志不可篡改** — AuditLog 表增加 `checksum` 字段（SHA256 of content），定期校验完整性；或写入只追加日志文件 | 🔴 | 2d |
|
||
| 6.3 | **P1** | **操作导出** — 审计日志支持 CSV/Excel 导出（按时间/用户/操作类型过滤），满足合规审计需求 | 🔴 | 2d |
|
||
| 6.4 | **P1** | **审核详情脱敏** — 审批人看到的工单 SQL 中，对配置了脱敏的字段值做 mask（如 INSERT INTO users (phone) VALUES ('138****1234')） | 🔴 | 2d |
|
||
| 6.5 | **P2** | **会话级脱敏策略** — 不同角色看到不同级别的脱敏（admin 看完整、dba 看部分脱敏、developer 看完全脱敏） | 🔴 | 2d |
|
||
| 6.6 | **P2** | **SQL 注入检测** — 审核阶段检测疑似 SQL 注入模式（如连续单引号、UNION SELECT 注入、hex 编码绕过） | 🔴 | 2d |
|
||
|
||
---
|
||
|
||
## 优先级排序（建议实施路线）
|
||
|
||
### 第一阶段（2 周）— 安全基线
|
||
```
|
||
5.1 工单风险等级 → 后续所有功能的基础
|
||
1.2 上下文感知规则 → 减少误报最有效的手段
|
||
4.1 EXPLAIN 预检 → DML 执行安全核心
|
||
3.1 执行进度透明 → 多条 SQL 可观测性
|
||
6.1 通知脱敏 → 快速见效
|
||
```
|
||
|
||
### 第二阶段（2 周）— 体验优化
|
||
```
|
||
5.2 多级审批流 → 基于风险等级的审批
|
||
3.2 部分失败处理策略 → 多条 SQL 容错
|
||
4.2 大表 ALTER 检测 → DBA 最关心的场景
|
||
4.3 影响行数预估 → 审批人最需要的信息
|
||
1.1 审核结果反馈机制 → 持续优化规则质量
|
||
2.2 审核超时保护 → 稳定性兜底
|
||
```
|
||
|
||
### 第三阶段（2 周）— 高级特性
|
||
```
|
||
3.3 自动回滚 SQL 生成 → 最高价值但最复杂
|
||
4.4 执行时间预估 → 配合维护窗口
|
||
5.3 高危操作二次确认 → 防呆机制
|
||
5.4 敏感表保护 → 细粒度管控
|
||
1.4 PG 审核规则补全 → 多 DB 支持
|
||
6.2 审计日志不可篡改 → 合规需求
|
||
```
|
||
|
||
### 第四阶段（持续）— 生态完善
|
||
```
|
||
1.5 MongoDB 审核规则
|
||
1.6 规则测试基准
|
||
2.1 SQL 复杂度评分
|
||
5.5 执行前备份
|
||
6.3 操作导出
|
||
6.6 SQL 注入检测
|
||
```
|
||
|
||
---
|
||
|
||
## 预估总工作量
|
||
|
||
| 阶段 | 工作量 | 核心目标 |
|
||
|------|--------|----------|
|
||
| P0 合计 | ~15 人天 | 安全基线 + 防误报 |
|
||
| P1 合计 | ~23 人天 | 审批流 + 影响分析 |
|
||
| P2 合计 | ~18 人天 | 高级特性 + 合规 |
|
||
| **总计** | **~56 人天** | — |
|