docs(security): 安全评估报告 + IDOR修复方案 + 安全开发规范v1.1

- 新增安全评估报告与P0修复方案(IDOR水平越权~29接口 + 全局LLM脱敏)
- 新增安全开发规范v1.1(9大安全规范 + Code Review检查清单)
- 采纳架构师审查意见补充OSS签名URL、导出审计、接口限流、依赖安全
- 更新开发规范README索引

Made-with: Cursor

docs/09-架构实施/安全开发规范(v1.0)架构师审查与补充评估报告.md

@@ -0,0 +1,81 @@
+# **《“医点点”平台安全开发规范（v1.0）》架构师审查与补充评估报告**
+
+**审查人：** 资深技术架构师
+
+**审查日期：** 2026-03-03
+
+**审查对象：** 12-安全开发规范.md (v1.0)
+
+**总体评价：** 基础扎实，针对性强，有效覆盖了 OWASP Top 10 中的注入和越权风险。但在文件存储安全、业务风控防刷、底层数据加密方面存在明显遗漏。
+
+## **一、 核心遗漏点（P0/P1级别盲区）**
+
+在之前的《关于“医点点”平台安全审查报告的补充评估与攻坚方案》（Security\_Action\_Plan.md）中，我们明确了卫健委窃取数据的几大通道，但在 v1.0 规范中并未体现对这些通道的防御指导：
+
+### **遗漏 1：OSS 对象存储与文件下载规范（P0级遗漏）**
+
+**现状问题：** 规范中提到了 API 的 IDOR 防护，但**完全没有提及文件/附件的下载安全规范**。卫健委正是通过遍历文件下载链接拿走的数据。
+
+**补充建议：** 必须在规范中新增专门的【OSS 与文件存储安全规范】章节，强制要求：
+
+1. **禁止前端直连**：前端永远不允许拼接 OSS 的固定 URL 下载文件。  
+2. **鉴权后签名**：前端必须调用后端的 /api/v2/files/:fileId/download-url 接口，后端在校验 userId 所属权后，临时生成阿里云 OSS 预签名 URL（Pre-signed URL）。  
+3. **极短有效期**：预签名 URL 的有效期强制设定为 **\<= 60 秒**，严禁生成长效链接。  
+4. **Bucket 权限**：代码中严禁调用将 Bucket 设置为 public-read 的 SDK API。
+
+### **遗漏 2：数据导出/批量下载的审计日志盲区（P1级遗漏）**
+
+**现状问题：** 规范 7.3 审计日志 仅规定了“管理员的增删改操作必须记录”。这忽略了系统最大的风险面——**内部用户的恶意/异常数据导出**。
+
+**补充建议：** 必须扩展 7.3 节，强制要求：
+
+凡是涉及“报表导出”、“Excel 数据下载”、“批量文献导出”的业务接口，必须记录 DataExportLog。记录内容必须包含：userId、IP、导出模块、导出数据量（行数）。这是我们在发生数据泄露时唯一的溯源反制手段。
+
+### **遗漏 3：API 速率限制与防暴力破解（P1级遗漏）**
+
+**现状问题：** 规范中未提及接口限流（Rate Limiting）。即使修补了 IDOR，攻击者依然可以利用高并发请求轰炸系统，甚至暴力破解密码或短信验证码。
+
+**补充建议：** 在 8\. 网络安全规范 或 4\. 认证规范 中加入限流要求：
+
+1. **登录/验证码接口**：单 IP 或单手机号，每分钟不得超过 5 次，连续失败 5 次锁定 15 分钟。  
+2. **数据查询接口**：采用 Token Bucket 算法限制单用户的高频抓取（如每秒最多 10 次请求）。
+
+## **二、 架构设计层面的缺失（P2级别改进）**
+
+### **缺失 1：数据库层的 PII 静态加密（Data at Rest Encryption）**
+
+**现状问题：** 规范 3\. LLM 调用安全规范 很好地解决了发给大模型时的数据脱敏（Data in Transit）。但是，患者的真实姓名、手机号等 PII 数据在存入我们的 RDS PostgreSQL 时，依然是**明文**的。
+
+**补充建议：** 规范应增加【数据库层敏感字段加密规范】。要求对于 phone、id\_card 等高敏字段，在 Prisma 层面实现应用层 AES-256-GCM 加密，数据库中只存储密文。
+
+### **缺失 2：服务端请求伪造（SSRF）防护**
+
+**现状问题：** 我们的 AI Agent（如 ASL 智能文献工具、IIT 质控工具）未来可能需要根据用户提供的 URL 抓取外部文献或对接医院内部系统，规范中缺乏对 SSRF 的警惕。
+
+**补充建议：** 增加限制：禁止后端直接请求用户提交的未经验证的 URL；如果必须请求，必须校验目标 IP 不能是内网 IP（如 127.0.0.1，172.16.x.x，10.x.x.x 等）。
+
+### **缺失 3：依赖库安全审查（SCA）**
+
+**现状问题：** 规范未提及对 npm 依赖包的安全管理。Node.js 生态中常常出现供应链投毒。
+
+**补充建议：** 在【部署与网络安全规范】中加入：每次发布前，强制在 CI/CD 流水线中执行 npm audit，出现 High/Critical 级别的漏洞必须修复后才能上线。
+
+## **三、 针对《安全开发规范(v1.0)》的具体修改建议 (Action Items)**
+
+为了闭环这套规范，建议技术架构师将以下内容合并进 12-安全开发规范.md：
+
+1. **新增章节 1.7 文件与 OSS 下载防越权规范**：  
+   明确写出生成临时预签名 URL 的代码示例，并强调过期时间 \<= 60s。  
+2. **修改章节 7.3 审计日志**：  
+   将标题改为 7.3 管理与高危操作审计日志，把“批量下载、导出 Excel”明确列为必须写日志的高危操作。  
+3. **新增章节 8.5 接口限流与防刷规范**：  
+   要求使用 @fastify/rate-limit 中间件，并在代码示例中展示如何给 /api/v2/login 挂载限流器。  
+4. **更新 9\. Code Review 安全检查清单**：  
+   增加三项勾选项：  
+   * \[ \] 导出/下载接口是否记录了审计日志？  
+   * \[ \] 生成的文件下载链接是否为短期时效（\<60s）的预签名 URL？  
+   * \[ \] 暴露到公网的对外查询、登录接口是否配置了 Rate Limit？
+
+## **四、 结论**
+
+《安全开发规范(v1.0)》是一份优秀的急救指南。如果在 v1.1 版本中补齐上述**OSS文件流转、审计溯源和接口限流**三大盲点，它将成为一份达到医疗行业等保三级要求的、坚不可摧的企业级安全基线文件。