新上线系统如何安全评审

本文目录导读：

1. 第一阶段：评审准备与信息收集
2. 第二阶段：安全架构评审（设计阶段）
3. 第三阶段：安全测试评审（开发/测试阶段）
4. 第四阶段：评审会议与风险定级
5. 第五阶段：上线后跟进
6. 常用的安全评审检查清单（Checklist）
7. 让评审高效的关键点

新上线系统的安全评审是一个系统性工程，核心目标是在上线前尽可能发现并修复安全漏洞，避免将风险带入生产环境，以下是一个标准、可落地的安全评审流程，分为五个阶段：

第一阶段：评审准备与信息收集

在开始评审前,需要先了解系统的基本情况。

1. 确定评审范围：
   • 是整个新系统,还是某个核心模块？
   • 是否涉及敏感数据（用户隐私、支付、身份信息）？
   • 是否暴露在公网？
   • 是否有第三方集成（API、SDK、数据库连接）？
2. 收集必要文档：
   • 架构设计文档：了解网络拓扑、数据流、认证方式。
   • 接口文档（API）：明确所有对外暴露的接口。
   • 数据流图：了解数据从哪里来、存哪里、如何处理、发哪里。
   • 依赖清单：使用的开源组件、框架、库及版本。
3. 确定评审人员：
   • 安全工程师（主导）。
   • 开发负责人（解释业务逻辑）。
   • 运维负责人（提供部署、网络配置信息）。
   • 业务方（明确关键业务路径）。

第二阶段：安全架构评审（设计阶段）

这是最高杠杆率的环节，越早发现架构问题，修复成本越低。

1. 认证与授权：
   • 认证：是否使用强密码策略、MFA（多因素认证）？Session/Token管理是否安全（如JWT的签名算法、过期时间）？
   • 授权：是否存在越权风险（水平越权如A用户看B用户订单，垂直越权如普通用户点管理员接口）？是否有严格的权限矩阵（如RBAC/ABAC）？
2. 数据安全：
   • 敏感数据（密码、身份证、支付卡号）是否加密存储（如使用bcrypt/argon2，而非MD5或明文）？
   • 传输过程是否使用HTTPS（TLS 1.2+）？
   • 日志中是否会打印敏感字段（防止信息泄露）？
3. 网络与基础设施：
   • 是否使用了安全组/防火墙限制入站/出站流量？
   • 是否需要WAF（Web应用防火墙）或RASP（运行时应用自我保护）？
   • 数据库、Redis等是否暴露在公网？是否使用堡垒机/跳板机访问？
4. 第三方依赖：
   • 是否使用了已知有漏洞的组件（利用OWASP Dependency-Check、Snyk等工具扫描）？
   • 第三方API是否经过认证和限流？

第三阶段：安全测试评审（开发/测试阶段）

架构通过后,重点验证实现层面的安全性。

1. 自动化漏洞扫描：
   • 使用SAST（静态应用安全测试）工具（如SonarQube、Checkmarx）扫描代码注入、XSS、CSRF等问题。
   • 使用DAST（动态应用安全测试）工具（如Burp Suite Pro、Acunetix）对已部署的测试环境进行主动扫描。
2. 人工渗透测试：
   • 重点测试 OWASP Top 10 常见漏洞：
     • SQL注入、命令注入。
     • 跨站脚本攻击（XSS）。
     • 不安全的反序列化。
     • SSRF（服务端请求伪造）。
     • 文件上传漏洞（是否限制类型、大小、内容检查）。
   • 业务逻辑漏洞：这是自动工具无法很好覆盖的，
     • 支付时是否可以篡改金额？
     • 优惠券或积分是否可以无限刷？
     • 签到/投票机制是否可以绕过周期限制？
3. 配置检查：
   • 是否启用了默认账户或弱口令（如admin/admin）？
   • HTTP响应头是否配置了安全头（CSP、X-Frame-Options、HSTS等）？
   • 错误页面是否暴露了堆栈信息或服务器路径？
4. 数据合规检查：
   • 是否符合GDPR、CCPA或《个人信息保护法》要求（用户是否有删除自己数据的接口）？
   • 是否对用户数据进行脱敏处理（如手机号中间四位打星号）？

第四阶段：评审会议与风险定级

测试完成后，召开安全评审会议,输出最终结果。

1. 汇总问题清单：
   • 按风险等级（紧急/高/中/低）归类。
   • 每个问题必须包含：漏洞描述、复现步骤、影响范围、修复建议。
2. 制定处置策略：
   • 阻止上线（Blocker）：紧急漏洞（如可直接获取数据库数据或RCE远程代码执行）,必须修复后才能上线。
   • 有条件上线：高风险漏洞（如越权、XSS）,通常要求修复后上线。
   • 可接受风险：中/低风险，或修复成本过高、业务影响较小的风险（需留档并签署知情书）。
3. 签字确认：

   安全团队、开发、项目经理三方明确风险接受程度,签字确认。

第五阶段：上线后跟进

安全评审不是一次性的,上线后仍需持续关注。

1. 灰度发布观察：先放开10%-20%的流量，持续监控日志、错误率、异常攻击行为。
2. 部署Web应用防火墙（WAF）：在公网入口开启WAF,针对已知漏洞进行虚拟补丁。
3. 设置监控告警：
   • 关注500错误、SQL错误、异常登录、高频接口调用。
   • 使用RASP工具检测运行时攻击。
4. 回滚预案：确保有稳妥的快速回滚方案,以防上线后发现严重安全问题。

常用的安全评审检查清单（Checklist）

你可以在评审时参照以下核心条目打勾：

让评审高效的关键点

1. 左移安全（Shift Left）：不要等到上线前一晚再开始评审。架构评审、代码提交时就引入安全审查。
2. 工具+人工：自动扫描工具解决已知漏洞，人工负责业务逻辑和越权测试,两者缺一不可。
3. 清单化：固定使用一份可复用的检查清单,减少遗漏。
4. 拒绝一刀切：内部管理系统的安全级别可以低于面向用户的支付系统,根据业务风险灵活调整。

最终交付物应包含： 一份《新系统安全评审报告》，列出风险等级、当前状态、处置结论，只有风险可控后,才允许上线。

如果你需要针对特定系统（如移动App、微服务架构、AI模型）的安全评审细节，可以进一步说明,我可以提供更专注的解答。