本文目录导读:

- 第一阶段:评审准备与信息收集
- 第二阶段:安全架构评审(设计阶段)
- 第三阶段:安全测试评审(开发/测试阶段)
- 第四阶段:评审会议与风险定级
- 第五阶段:上线后跟进
- 常用的安全评审检查清单(Checklist)
- 让评审高效的关键点
新上线系统的安全评审是一个系统性工程,核心目标是在上线前尽可能发现并修复安全漏洞,避免将风险带入生产环境,以下是一个标准、可落地的安全评审流程,分为五个阶段:
第一阶段:评审准备与信息收集
在开始评审前,需要先了解系统的基本情况。
- 确定评审范围:
- 是整个新系统,还是某个核心模块?
- 是否涉及敏感数据(用户隐私、支付、身份信息)?
- 是否暴露在公网?
- 是否有第三方集成(API、SDK、数据库连接)?
- 收集必要文档:
- 架构设计文档:了解网络拓扑、数据流、认证方式。
- 接口文档(API):明确所有对外暴露的接口。
- 数据流图:了解数据从哪里来、存哪里、如何处理、发哪里。
- 依赖清单:使用的开源组件、框架、库及版本。
- 确定评审人员:
- 安全工程师(主导)。
- 开发负责人(解释业务逻辑)。
- 运维负责人(提供部署、网络配置信息)。
- 业务方(明确关键业务路径)。
第二阶段:安全架构评审(设计阶段)
这是最高杠杆率的环节,越早发现架构问题,修复成本越低。
- 认证与授权:
- 认证:是否使用强密码策略、MFA(多因素认证)?Session/Token管理是否安全(如JWT的签名算法、过期时间)?
- 授权:是否存在越权风险(水平越权如A用户看B用户订单,垂直越权如普通用户点管理员接口)?是否有严格的权限矩阵(如RBAC/ABAC)?
- 数据安全:
- 敏感数据(密码、身份证、支付卡号)是否加密存储(如使用bcrypt/argon2,而非MD5或明文)?
- 传输过程是否使用HTTPS(TLS 1.2+)?
- 日志中是否会打印敏感字段(防止信息泄露)?
- 网络与基础设施:
- 是否使用了安全组/防火墙限制入站/出站流量?
- 是否需要WAF(Web应用防火墙)或RASP(运行时应用自我保护)?
- 数据库、Redis等是否暴露在公网?是否使用堡垒机/跳板机访问?
- 第三方依赖:
- 是否使用了已知有漏洞的组件(利用OWASP Dependency-Check、Snyk等工具扫描)?
- 第三方API是否经过认证和限流?
第三阶段:安全测试评审(开发/测试阶段)
架构通过后,重点验证实现层面的安全性。
- 自动化漏洞扫描:
- 使用SAST(静态应用安全测试)工具(如SonarQube、Checkmarx)扫描代码注入、XSS、CSRF等问题。
- 使用DAST(动态应用安全测试)工具(如Burp Suite Pro、Acunetix)对已部署的测试环境进行主动扫描。
- 人工渗透测试:
- 重点测试 OWASP Top 10 常见漏洞:
- SQL注入、命令注入。
- 跨站脚本攻击(XSS)。
- 不安全的反序列化。
- SSRF(服务端请求伪造)。
- 文件上传漏洞(是否限制类型、大小、内容检查)。
- 业务逻辑漏洞:这是自动工具无法很好覆盖的,
- 支付时是否可以篡改金额?
- 优惠券或积分是否可以无限刷?
- 签到/投票机制是否可以绕过周期限制?
- 重点测试 OWASP Top 10 常见漏洞:
- 配置检查:
- 是否启用了默认账户或弱口令(如admin/admin)?
- HTTP响应头是否配置了安全头(CSP、X-Frame-Options、HSTS等)?
- 错误页面是否暴露了堆栈信息或服务器路径?
- 数据合规检查:
- 是否符合GDPR、CCPA或《个人信息保护法》要求(用户是否有删除自己数据的接口)?
- 是否对用户数据进行脱敏处理(如手机号中间四位打星号)?
第四阶段:评审会议与风险定级
测试完成后,召开安全评审会议,输出最终结果。
- 汇总问题清单:
- 按风险等级(紧急/高/中/低)归类。
- 每个问题必须包含:漏洞描述、复现步骤、影响范围、修复建议。
- 制定处置策略:
- 阻止上线(Blocker):紧急漏洞(如可直接获取数据库数据或RCE远程代码执行),必须修复后才能上线。
- 有条件上线:高风险漏洞(如越权、XSS),通常要求修复后上线。
- 可接受风险:中/低风险,或修复成本过高、业务影响较小的风险(需留档并签署知情书)。
- 签字确认:
安全团队、开发、项目经理三方明确风险接受程度,签字确认。
第五阶段:上线后跟进
安全评审不是一次性的,上线后仍需持续关注。
- 灰度发布观察:先放开10%-20%的流量,持续监控日志、错误率、异常攻击行为。
- 部署Web应用防火墙(WAF):在公网入口开启WAF,针对已知漏洞进行虚拟补丁。
- 设置监控告警:
- 关注500错误、SQL错误、异常登录、高频接口调用。
- 使用RASP工具检测运行时攻击。
- 回滚预案:确保有稳妥的快速回滚方案,以防上线后发现严重安全问题。
常用的安全评审检查清单(Checklist)
你可以在评审时参照以下核心条目打勾:
| 类别 | 检查项 | 状态 |
|---|---|---|
| 认证 | 不使用明文密码,使用bcrypt/argon2 | ☐ |
| 认证 | 登录接口有防暴力破解机制(验证码、限流) | ☐ |
| 授权 | 所有后端接口均校验用户权限,不依赖前端控制 | ☐ |
| 输入 | 所有用户输入(URL、参数、Body)都经过校验和过滤 | ☐ |
| 输出 | 返回给前端的数据不包含敏感字段(如密码哈希、Token) | ☐ |
| 依赖 | 无已知高危CVE漏洞的开源组件 | ☐ |
| 传输 | 全部使用HTTPS(TLS 1.2+) | ☐ |
| 存储 | 数据库连接串、API Key等存储在配置文件或密钥管理服务中,非硬编码 | ☐ |
| 日志 | 不记录密码、身份证、银行卡号等明文信息 | ☐ |
| 配置 | 关闭目录列表、禁用TRACE方法、显示通用错误页 | ☐ |
让评审高效的关键点
- 左移安全(Shift Left):不要等到上线前一晚再开始评审。架构评审、代码提交时就引入安全审查。
- 工具+人工:自动扫描工具解决已知漏洞,人工负责业务逻辑和越权测试,两者缺一不可。
- 清单化:固定使用一份可复用的检查清单,减少遗漏。
- 拒绝一刀切:内部管理系统的安全级别可以低于面向用户的支付系统,根据业务风险灵活调整。
最终交付物应包含: 一份《新系统安全评审报告》,列出风险等级、当前状态、处置结论,只有风险可控后,才允许上线。
如果你需要针对特定系统(如移动App、微服务架构、AI模型)的安全评审细节,可以进一步说明,我可以提供更专注的解答。