14 KiB
14 KiB
专业安全深度评审报告
评审日期：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. 异常检测
建议：
-- 增加计费防篡改表
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 的数据
建议：
- API层强制租户上下文验证
- 数据库层行级安全（RLS）
- 敏感操作二次验证
风险评级：🔴 P0
问题 S-03：密钥轮换机制缺失
发现： 当前设计的 API Key 没有失效机制：
- 密钥泄露后无法撤销
- 无法强制轮换
- 无密钥生命周期管理
行业最佳实践：
密钥管理最佳实践：
1. 密钥有效期（建议90天）
2. 强制轮换策略
3. 密钥泄露应急流程
4. 密钥版本管理
建议：
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变更
- 不同区域的法律差异
- 实时使用模式检测
建议：
- 建立ToS变更监控
- 增加行为分析引擎
- 支持区域化配置
风险评级：🟡 P1
问题 S-05：激活码安全强度不足
发现： 当前激活码格式可预测，校验和强度可能不足
当前设计：
lgw-act-{user_id}-{expiry}-{random}-{checksum}
问题：
- user_id 和 expiry 可预测
- 6位随机数 entropy 不足
- MD5 校验和可碰撞
建议：
- 使用 UUID 作为激活码主体
- 增加 crypto.random 的 entropy
- 使用 HMAC 代替纯校验和
风险评级：🟡 P1
问题 S-06：供应链安全缺失
发现： 未考虑对供应商的信任边界：
- 供应商API凭证存储
- 供应商API调用日志
- 供应商故障隔离
建议：
- 供应商凭证单独加密
- 调用日志完整记录
- 熔断降级策略
风险评级：🟡 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安全实现完成后