security

安全 — 合规与保护

假设已遭入侵。纵深防御。始终遵循最小权限原则。

步骤 0：识别技术栈

在针对具体实现提供建议前，先识别项目的技术栈（检查 package.json、go.mod、Gemfile、pyproject.toml、pom.xml、Cargo.toml）。安全原则是通用的，实现这些原则的库则因技术栈而异。始终推荐当前技术栈的惯用解决方案，而非仅适用于 JavaScript 的方案。

安全默认配置

每个项目都应具备以下配置：

控制措施	实现内容
身份验证	使用技术栈的标准库实现 OAuth 2.0 / OIDC
会话	HTTP-only、Secure、SameSite=Strict Cookie
密码	bcrypt 或 argon2，至少 12 个字符，不限制最大长度
API 身份验证	设有过期时间的 Bearer 令牌，以及刷新令牌轮换
CORS	明确的允许列表；生产环境中绝不使用 *
HTTPS	全面启用，不得例外。添加 HSTS 标头。
CSP	在所有页面添加 Content-Security-Policy 标头
速率限制	身份验证端点：每分钟 5 次。API：每分钟 100 次。根据用途调整。

OWASP Top 10 速查

漏洞	防护措施
注入（SQL、NoSQL、OS）	使用参数化查询、ORM，绝不拼接字符串
身份验证失效	MFA、会话超时、账户锁定
敏感数据泄露	对静态数据和传输中数据加密，尽量减少数据收集
XXE	禁用外部实体处理
访问控制失效	在服务端检查每个请求的权限
安全配置错误	默认关闭，强化配置，生产环境不启用调试
XSS	输出编码、CSP 标头、清理 HTML
不安全的反序列化	验证所有序列化数据并检查其类型
已知漏洞	使用适用于技术栈的依赖项审计工具（npm audit、pip audit、go mod tidy、bundle audit 等），并自动更新
日志记录不足	记录身份验证事件、访问被拒绝事件和输入验证失败事件

HIPAA 合规（健康科技）

如果处理 PHI（受保护健康信息），则必须满足以下要求：

要求	实施方式
静态数据加密	对数据库和文件存储使用 AES-256
传输中数据加密	全面使用 TLS 1.2+
访问控制	基于角色、记录审计日志、遵循最小权限原则
审计跟踪	记录每次 PHI 访问，包括访问者、操作内容和时间
BAA	与每个接触 PHI 的供应商签订业务伙伴协议
数据最小化	仅收集临床上必要的数据
泄露通知	必须在 60 天内通知 — 制定好应对计划
员工培训	每年开展安全意识培训

**PHI 包括：**姓名、日期、电话号码、电子邮件地址、SSN、病历编号、设备 ID、生物识别数据、照片，以及任何可能识别患者身份的数据。

供应商检查清单：

• 你的云服务商是否签署 BAA？（AWS、GCP、Azure：是。许多其他服务商：否。）
• 你的分析工具是否会接触 PHI？如果会，则需要签订 BAA，或先剔除 PHI。
• 你的错误跟踪工具是否会在堆栈跟踪中采集 PHI？请将其剔除。

SOC 2 基础知识

信任原则	实现内容
安全性	访问控制、加密、防火墙、IDS
可用性	正常运行时间监控、事件响应、备份
处理完整性	输入验证、错误处理、QA
保密性	加密、访问日志、数据分类
隐私	同意、数据保留、删除、隐私政策

**从以下方面开始：**安全性 + 可用性。客户有要求时再添加其他方面。

安全审查清单

审查代码安全性时：

1. 每个端点都经过身份验证？ — 不仅是路由，数据查询也要经过身份验证
2. 是否在边界处验证输入？ — 在进行任何处理之前，使用适用于你所用技术栈的架构／验证库
3. 机密信息是否存储在环境变量中？ — 绝不存储在代码、Git 或客户端包中
4. 查询是否使用参数化？ — 不要拼接字符串，也不要将内容插入 SQL 或命令中
5. 错误消息是否安全？ — 不要向用户显示堆栈跟踪或内部路径
6. 依赖项是否保持最新？ — 运行你所用技术栈的依赖项审计工具
7. 日志记录是否充分？ — 记录身份验证事件、权限失败和异常
8. 数据是否已最小化？ — 只收集所需数据，并且只在必要期限内保留