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

Made-with: Cursor
2026-03-03 22:20:03 +08:00

5.5 KiB
Raw Blame History

《“医点点”平台安全开发规范v1.0)》架构师审查与补充评估报告

审查人: 资深技术架构师

审查日期: 2026-03-03

审查对象: 12-安全开发规范.md (v1.0)

总体评价: 基础扎实,针对性强,有效覆盖了 OWASP Top 10 中的注入和越权风险。但在文件存储安全、业务风控防刷、底层数据加密方面存在明显遗漏。

一、 核心遗漏点P0/P1级别盲区

在之前的《关于“医点点”平台安全审查报告的补充评估与攻坚方案》Security_Action_Plan.md我们明确了卫健委窃取数据的几大通道但在 v1.0 规范中并未体现对这些通道的防御指导:

遗漏 1OSS 对象存储与文件下载规范P0级遗漏

现状问题: 规范中提到了 API 的 IDOR 防护,但完全没有提及文件/附件的下载安全规范。卫健委正是通过遍历文件下载链接拿走的数据。

补充建议: 必须在规范中新增专门的【OSS 与文件存储安全规范】章节,强制要求:

  1. 禁止前端直连:前端永远不允许拼接 OSS 的固定 URL 下载文件。
  2. 鉴权后签名:前端必须调用后端的 /api/v2/files/:fileId/download-url 接口,后端在校验 userId 所属权后,临时生成阿里云 OSS 预签名 URLPre-signed URL
  3. 极短有效期:预签名 URL 的有效期强制设定为 <= 60 秒,严禁生成长效链接。
  4. Bucket 权限:代码中严禁调用将 Bucket 设置为 public-read 的 SDK API。

遗漏 2数据导出/批量下载的审计日志盲区P1级遗漏

现状问题: 规范 7.3 审计日志 仅规定了“管理员的增删改操作必须记录”。这忽略了系统最大的风险面——内部用户的恶意/异常数据导出

补充建议: 必须扩展 7.3 节,强制要求:

凡是涉及“报表导出”、“Excel 数据下载”、“批量文献导出”的业务接口,必须记录 DataExportLog。记录内容必须包含userId、IP、导出模块、导出数据量行数。这是我们在发生数据泄露时唯一的溯源反制手段。

遗漏 3API 速率限制与防暴力破解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.1172.16.x.x10.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文件流转、审计溯源和接口限流三大盲点,它将成为一份达到医疗行业等保三级要求的、坚不可摧的企业级安全基线文件。