lijiaoqiao/review/deep_security_review_v1_2026-03-18.md

# 专业安全深度评审报告

> 评审日期：2026-03-18
> 评审方法：威胁建模 + STRIDE分析 + 行业最佳实践对照
> 评审范围：全部安全相关设计

---

## 1. 评审团队与方法

### 1.1 评审专家
- **安全架构师** - 负责威胁建模
- **渗透测试专家** - 负责攻击面分析
- **合规顾问** - 负责ToS合规性评估

### 1.2 评审方法
| 方法 | 用途 |
|------|------|
| STRIDE | 威胁分类识别 |
| MITRE ATT&CK | 对手技战术映射 |
| OWASP Top 10 | Web安全对照 |
| 行业最佳实践 | 对标金融级安全标准 |

---

## 2. 威胁建模分析

### 2.1 系统架构威胁视图

```
                    ┌──────────────────────────────────────────────────┐
                    │                   用户请求                        │
                    └─────────────────────┬──────────────────────────┘
                                          │
                    ┌─────────────────────▼──────────────────────────┐
                    │              API Gateway (LGW)                  │
                    │  ┌─────────────────────────────────────────┐  │
                    │  │  1. Key识别 (lgw-/sk-/other)           │  │
                    │  │  2. 格式验证                            │  │
                    │  │  3. 权限检查                            │  │
                    │  │  4. ToS合规                            │  │
                    │  └─────────────────────────────────────────┘  │
                    └─────────────────────┬──────────────────────────┘
                                          │
          ┌───────────────────────────────┼───────────────────────────────┐
          │                               │                               │
          ▼                               ▼                               ▼
┌─────────────────────┐    ┌─────────────────────┐    ┌─────────────────────┐
│   自研Router Core   │    │     subapi          │    │    供应商API         │
│   (国内供应商)      │    │  (海外供应商)       │    │   (OpenAI等)        │
└─────────────────────┘    └─────────────────────┘    └─────────────────────┘
```

### 2.2 攻击面清单

| 编号 | 攻击面 | 暴露等级 | 已有防护 |
|------|--------|----------|----------|
| AS-1 | API Key鉴权 | 🔴 高 | ✅ 自建Key体系 |
| AS-2 | 账号凭证存储 | 🔴 高 | ✅ KMS加密 |
| AS-3 | 供应商API调用 | 🟡 中 | ⚠️ 需增强 |
| AS-4 | 计费数据 | 🔴 高 | ⚠️ 需审计 |
| AS-5 | 用户数据 | 🟡 中 | ⚠️ 需脱敏 |
| AS-6 | ToS合规检测 | 🟡 中 | ⚠️ 需完善 |

---

## 3. STRIDE威胁分析

### 3.1 威胁矩阵

| 威胁类型 | 场景 | 风险等级 | 建议 |
|----------|------|----------|------|
| **Spoofing（伪造）** | | | |
| S-1 | 伪造API Key访问 | 🔴 高 | 已设计自建Key体系 ✅ |
| S-2 | 伪造激活码 | 🟡 中 | 需增加激活码校验 |
| S-3 | 伪造用户身份 | 🟡 中 | 需增强身份验证 |
| **Tampering（篡改）** | | | |
| T-1 | 篡改计费数据 | 🔴 高 | 需防篡改机制 |
| T-2 | 篡改套餐配额 | 🔴 高 | 需完整性校验 |
| T-3 | 中间人攻击 | 🟡 中 | 需mTLS |
| **Repudiation（抵赖）** | | | |
| R-1 | 用户否认操作 | 🔴 高 | 需操作日志 |
| R-2 | 供应方否认挂载 | 🔴 高 | 需电子签约 |
| R-3 | 管理员否认修改 | 🟡 中 | 需审计日志 |
| **Information Disclosure（信息泄露）** | | | |
| I-1 | API Key泄露 | 🔴 高 | 需Key轮换 |
| I-2 | 账号凭证泄露 | 🔴 高 | 需加密存储 |
| I-3 | 用户数据泄露 | 🟡 中 | 需脱敏 |
| I-4 | 计费数据泄露 | 🟡 中 | 需访问控制 |
| **Denial of Service（拒绝服务）** | | | |
| D-1 | API洪泛攻击 | 🟡 中 | 需限流 |
| D-2 | 供应商API耗尽 | 🔴 高 | 需降级策略 |
| D-3 | 账号额度耗尽 | 🔴 高 | 需实时监控 |
| **Elevation of Privilege（权限提升）** | | | |
| E-1 | 普通用户提权 | 🟡 中 | 需RBAC |
| E-2 | 跨租户访问 | 🔴 高 | 需强隔离 |
| E-3 | 供应商权限提升 | 🟡 中 | 需最小权限 |

---

## 4. 深度问题发现

### 4.1 严重问题（Critical）

#### 问题 S-01：计费数据防篡改缺失

**发现**：
当前设计只记录了 usage_records，但未考虑：
- 如何防止内部人员篡改计费数据
- 如何验证计费数据的完整性
- 如何对账

**行业最佳实践**：
```
金融级计费要求：
1. 写前日志（WAL）
2. 双重记账
3. 定期对账
4. 异常检测
```

**建议**：
```sql
-- 增加计费防篡改表
CREATE TABLE billing_audit_log (
    id BIGINT PRIMARY KEY,
    record_id BIGINT NOT NULL,
    operation VARCHAR(20) NOT NULL,  -- INSERT/UPDATE/DELETE
    old_value JSON,
    new_value JSON,
    operator_id BIGINT,
    ip_address VARCHAR(45),
    checksum VARCHAR(64),  -- 数据完整性校验
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 增加防篡改触发器
CREATE TRIGGER trg_usage_before_update
BEFORE UPDATE ON supply_usage_records
FOR EACH ROW
BEGIN
    INSERT INTO billing_audit_log (record_id, operation, old_value, new_value, operator_id)
    VALUES (OLD.id, 'UPDATE', JSON_OBJECT(...), JSON_OBJECT(...), CURRENT_USER());
END;
```

**风险评级**：🔴 P0

---

#### 问题 S-02：跨租户隔离不完善

**发现**：
当前设计使用 team_id 和 organization_id，但未明确：
- 如何防止横向越权
- 如何处理组织架构变更
- 如何隔离计费数据

**攻击场景**：
```
攻击者获取了 Team A 的 API Key
→ 尝试访问 Team B 的计费数据
→ 当前系统可能返回 Team B 的数据
```

**建议**：
1. API层强制租户上下文验证
2. 数据库层行级安全（RLS）
3. 敏感操作二次验证

**风险评级**：🔴 P0

---

#### 问题 S-03：密钥轮换机制缺失

**发现**：
当前设计的 API Key 没有失效机制：
- 密钥泄露后无法撤销
- 无法强制轮换
- 无密钥生命周期管理

**行业最佳实践**：
```
密钥管理最佳实践：
1. 密钥有效期（建议90天）
2. 强制轮换策略
3. 密钥泄露应急流程
4. 密钥版本管理
```

**建议**：
```python
class APIKeyManager:
    KEY_EXPIRY_DAYS = 90
    WARNING_DAYS = 14

    def is_key_valid(self, key: APIKey) -> bool:
        # 1. 检查是否过期
        if key.is_expired():
            return False

        # 2. 检查是否在泄露黑名单
        if key.is_compromised():
            return False

        # 3. 检查是否需要轮换提醒
        if key.should_rotate():
            self.notify_user(key)

        return True
```

**风险评级**：🔴 P0

---

### 4.2 高风险问题（High）

#### 问题 S-04：ToS合规检测不完整

**发现**：
当前只检查了静态规则，但未考虑：
- 动态ToS变更
- 不同区域的法律差异
- 实时使用模式检测

**建议**：
1. 建立ToS变更监控
2. 增加行为分析引擎
3. 支持区域化配置

**风险评级**：🟡 P1

---

#### 问题 S-05：激活码安全强度不足

**发现**：
当前激活码格式可预测，校验和强度可能不足

**当前设计**：
```
lgw-act-{user_id}-{expiry}-{random}-{checksum}
```

**问题**：
- user_id 和 expiry 可预测
- 6位随机数 entropy 不足
- MD5 校验和可碰撞

**建议**：
1. 使用 UUID 作为激活码主体
2. 增加 crypto.random 的 entropy
3. 使用 HMAC 代替纯校验和

**风险评级**：🟡 P1

---

#### 问题 S-06：供应链安全缺失

**发现**：
未考虑对供应商的信任边界：
- 供应商API凭证存储
- 供应商API调用日志
- 供应商故障隔离

**建议**：
1. 供应商凭证单独加密
2. 调用日志完整记录
3. 熔断降级策略

**风险评级**：🟡 P1

---

### 4.3 中等风险问题（Medium）

| 问题编号 | 问题 | 建议 | 风险等级 |
|----------|------|------|----------|
| S-07 | 管理员权限过大 | 实施最小权限原则 | 🟡 P1 |
| S-08 | 日志保留策略不明确 | 制定日志保留规范 | 🟢 P2 |
| S-09 | 缺少安全演练 | 建立应急响应流程 | 🟢 P2 |
| S-10 | 加密算法未明确 | 指定国密算法 | 🟢 P2 |

---

## 5. 合规性分析

### 5.1 ToS合规矩阵

| 供应商 | 账号共享 | 转售 | 代理 | 地区限制 | 我们的合规策略 |
|--------|----------|------|------|----------|----------------|
| OpenAI | ❌ | ❌ | ⚠️ | ❌ | 禁止+告警 |
| Anthropic | ❌ | ❌ | ❌ | ❌ | 禁止+告警 |
| Azure | ✅ | ✅ | ✅ | ✅ | 合规 |
| 国内供应商 | ⚠️ | ⚠️ | ⚠️ | ❌ | 需确认 |

### 5.2 隐藏合规风险

**风险点1：平台法律地位不明确**
- 平台作为"中间商"是否需要特定资质？
- 资金流转是否涉及支付牌照？
- 用户协议是否完善？

**风险点2：跨境数据传输**
- 用户数据存储地点
- 供应商API调用跨境
- GDPR/个保法合规

**建议**：法务需确认上述问题

---

## 6. 安全加固建议

### 6.1 优先级排序

| 优先级 | 任务 | 负责人 | 截止 |
|--------|------|--------|------|
| P0 | 计费防篡改机制 | 后端 | S1前 |
| P0 | 跨租户隔离强化 | 架构 | S1前 |
| P0 | 密钥轮换机制 | 后端 | S0-M1 |
| P1 | 激活码强度提升 | 后端 | S0-M1 |
| P1 | ToS动态监控 | 产品 | S1 |
| P1 | 供应链安全 | 架构 | S1 |

### 6.2 安全架构建议

```
┌─────────────────────────────────────────────────────────────────┐
│                        安全架构分层                               │
├─────────────────────────────────────────────────────────────────┤
│  身份认证层    │ MFA / OAuth2 / JWT / API Key                  │
├─────────────────────────────────────────────────────────────────┤
│  授权控制层    │ RBAC / ABAC / 资源级权限                      │
├─────────────────────────────────────────────────────────────────┤
│  数据安全层    │ 加密 / 脱敏 / 行级安全                        │
├─────────────────────────────────────────────────────────────────┤
│  审计追溯层    │ 操作日志 / 计费审计 / 合规报表                 │
├─────────────────────────────────────────────────────────────────┤
│  威胁防护层    │ WAF / 限流 / 熔断 / 风控                     │
└─────────────────────────────────────────────────────────────────┘
```

---

## 7. 行业最佳实践对照

### 7.1 对标金融级安全标准

| 安全领域 | 行业标准 | 当前状态 | 差距 |
|----------|----------|----------|------|
| 密钥管理 | KMS + HSM | KMS | 建议引入HSM |
| 计费准确 | 双重记账 | 单表记录 | 需增加审计表 |
| 身份认证 | MFA | API Key | 建议增强 |
| 权限控制 | ABAC | RBAC | 需升级 |
| 日志保留 | 5年 | 未定义 | 需明确 |

### 7.2 OWASP Top 10 对照

| OWASP风险 | 相关问题 | 防护状态 |
|-----------|----------|----------|
| A01 访问控制失效 | 跨租户隔离 | ⚠️ 需加强 |
| A02 加密失败 | Key存储 | ✅ 已设计 |
| A03 注入 | SQL注入 | ✅ 参数化查询 |
| A04 不安全设计 | 计费防篡改 | ❌ 缺失 |
| A05 安全配置错误 | 密钥轮换 | ❌ 缺失 |
| A06 易受攻击组件 | subapi依赖 | ⚠️ 需监控 |
| A07 认证失败 | 激活码强度 | ⚠️ 需加强 |
| A08 软件和数据完整性失败 | 计费数据 | ⚠️ 需加强 |
| A09 安全日志缺失 | 审计日志 | ⚠️ 需完善 |
| A10 服务端请求伪造 | 供应商调用 | ⚠️ 需隔离 |

---

## 8. 总结

### 8.1 评分

| 维度 | 评分 | 说明 |
|------|------|------|
| 身份认证 | 7/10 | 基础API Key，需增强MFA |
| 访问控制 | 6/10 | RBAC基础，跨租户需加强 |
| 数据安全 | 7/10 | 加密已设计，防篡改缺失 |
| 审计追溯 | 5/10 | 日志不完善，计费审计缺失 |
| 合规管理 | 6/10 | 静态规则已设计，动态监控缺失 |

**安全综合评分：6.5/10**

### 8.2 关键行动项

| 优先级 | 行动项 |
|--------|--------|
| 🔴 P0 | 实现计费数据防篡改机制 |
| 🔴 P0 | 强化跨租户隔离 |
| 🔴 P0 | 实现密钥轮换机制 |
| 🟡 P1 | 增强激活码安全强度 |
| 🟡 P1 | 建立ToS动态监控 |
| 🟢 P2 | 完善日志保留策略 |

---

**评审完成时间**：2026-03-18
**下次评审**：S0安全实现完成后