chore: initial public snapshot for github upload
This commit is contained in:
Your Name
406
review/deep_security_review_v1_2026-03-18.md
Normal file
406
review/deep_security_review_v1_2026-03-18.md
Normal file
@@ -0,0 +1,406 @@
|
||||
# 专业安全深度评审报告
|
||||
|
||||
> 评审日期：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安全实现完成后
|
||||
Reference in New Issue
Block a user