原文链接：https://mawei.blog/post/architecture-security-review/

“技术架构安全评审”是个什么活动？它解决什么问题？看上去给人感觉是个挺“重”的活动，有必要执行它吗？这个活动是如何进行的呢？希望这篇文章能为你揭开技术架构安全评审神秘的面纱。

解决的问题

技术架构安全评审的目标是，尽早识别出技术架构中的安全风险，使得开发团队能够在早期以更低的成本弥补或直接避免严重安全隐患的出现。

或者说，想要解决的问题是：由于技术架构层面存在安全隐患，并且没有被及时暴露出来得以修正，导致应用程序后期出现严重安全漏洞，或着造成安全漏洞修复成本极高（因为可能需要对技术架构进行大幅调整）甚至无法修复的问题。

想象一下，如果完全略过这一步可能会出现什么样的情况：应用上线前最后一刻被紧急叫停，渗透测试发现存在一处严重的安全漏洞。好消息是，通过对技术架构做出调整可以修复这个漏洞；坏消息是，修复难度大耗时长，这部分计划外的工作量给本来就面临交付压力的团队带来更多压力。团队面临两难：修，则可能影响上线计划；带病上线，背后的风险谁来承担？

什么时候做

在知道了技术架构安全评审解决什么问题后，你就知道这个活动越早做越好，最好是和技术架构一起做，直接设计出一个安全质量可靠的技术架构。

一些采用敏捷开发方式的团队，他们的技术架构是伴随着迭代的进行，根据业务和技术的最新情况而不断动态演进，最初的时候不见得有一个大而全的技术架构设计。这种情况下，并没有所谓的“尽早”，因为技术架构可能一直处于变化的状态。尽管如此，技术架构安全评审依然可以伴随着技术架构的演进而进行，也就是每当提出新的技术架构，或者要对现有技术架构做调整之前，都做一次技术架构安全评审。值得注意的是，只有把技术架构安全评审进行轻量化改造，才能做到技术架构安全评审伴随技术架构演进而进行。

谁来做

“评审”这个词给人留下的印象，仿佛应该是由安全团队来完成这个工作，在一些公司里也确实是按照这样的方式来运作的。

不过这个活动不一定只能由安全团队来完成，由安全团队和开发团队结对进行也是一种不错的选择。这种情况下，安全团队和开发团队之间会有更加频繁和紧密的沟通交流，能够更容易的从技术架构中寻找出潜在的安全风险，更准确的评估其风险级别，以及提出更可行的改进方案。

而在一些安全能力成熟度较高，或着拥有一支转变了思维模式的安全团队的组织里，安全团队会把做技术架构安全评审的能力赋能给开发团队，由他们自己独立完成安全评审，安全团队更多的是扮演幕后工作人员的角色，为开发团队提供支持。

可能有人会担心，如此一来开发团队岂不是既当运动员又当裁判？技术架构安全评审的结果如何保证？这种担心是可以理解的，而且如果操作不当确实有可能出现技术架构安全评审流于形式的局面，因此这种模式只适用于安全能力成熟度较高，且拥有一颗持续追求安全技术卓越之心的组织或团队。前者保证了团队具备相应的能力，后者确保了团队拥有极强的责任感。

以上几种执行方式各有所长，效果以及对前置条件的要求也各不一样，组织根据自己的实际情况来选择最适合的一种即可。通常我们更建议第二种，即开发团队和安全团队结对的方式。

怎么做

第一步，全面了解技术架构，知己知彼才能百战不殆。技术架构安全评审在某种程度上来讲，和黑客进行渗透测试之前的信息收集（“蹲点”）也有异曲同工之妙。两者都是在前期尽可能全面的了解被评审（测试）的对象。信息收集得越多越全面，更有利于准确的判断架构中是否存在安全缺陷或隐患。

根据我们的实践经验，威胁建模通常能给技术架构安全评审提供非常有价值的输入。一次高质量的威胁建模的结果基本上都会包含以下这些信息：
要保护哪些资产？
谁可能对我们发起攻击？他们的动机？
面临哪些威胁？
有哪些技术性应对策略可以采用？
应用将会采用的技术栈
应用将会对接的第三方系统
应用所处的网络、主机等运行环境

才外，还需要知道应用是否必须符合哪些外部法律法规、行业规范的要求。比如说，是否需要遵从GDPR？如果要处理信用卡信息，是否要符合PCI DSS的规范？等等

第二步，检查安全三要素是否满足。CIA是非常基础的安全三要素，分别是Confidentiality（机密性）、Integrity（完整性）、Availability（可用性）。我们可以基于上一步对技术架构（甚至包括对业务上下文）的了解，并围绕这三个要素提出并回答一些问题，从而正式开始我们的评审，例如：

• 应用是否要传输、处理或保存敏感数据（比如用户密码、每个月的运营数据）？如果是，这些数据是什么数据？它们各自的敏感程度如何？
• 是否需要对数据完整性进行保护？如果数据被外部攻击者或内部人员恶意修改了，会对应用或业务产生什么影响？
• 技术架构层面我们目前采取了哪些措施，用以保证应用具备足够高的可用性，避免出现业务中断？需要负载均衡吗？灾备方案如何？

第三步，基于安全清单对技术架构进行检查。有很多安全清单可以选择，有人把OWASP历次发布的TOP 10版本合并成一个大的清单，并以此来回顾技术架构中是否存在出现这些安全漏洞的可能。这是从最流行的安全漏洞的视角出发，来对技术架构进行评审。

例如对于Cross-Site Scripting这个漏洞，我们看到应用做了前后端分离，前端框架用的是VUE，其默认会对数据进行编码，看似架构选型直接避免了这个问题。但需要注意得是，我们有时候需要在页面上呈现一篇含有HTML的文章片段，因此也需要注意在渲染raw HTML的地方（也就是使用v-html指令），需要服务器端提前把不符合要求的HTML或脚本过滤掉。

也可以根据下面的这个比较常见的安全维度对技术架构进行评审：

• Authentication 认证
• Authorization 授权
• Session Management 回话管理
• Security Configuration 默认安全配置
• Input Validation 数据输入校验
• Output Encoding 数据输出编码
• Cryptography 加解密及其算法
• Error Handling 错误及异常处理
• Logging 日志处理
• Communication Protection 数据传输安全保护
• Files and Resources 文件上传下载保护
• SMS/Email 短信及邮件发送

第四步，根据历史经验教训，判断重复掉“坑”里去的风险。俗话说吃一堑长一智，要尽量避免在同一个问题上犯两次同样的错误，这对于技术架构设计也是适用的。如果历史上出现过安全事故，或者之前被发现过有安全漏洞，那么技术架构安全评审也就需要在这方面保持更高的警惕，看架构中是否依然存在类似的安全风险。

例如，某个团队在之前开发的某个应用程序中，由于缺乏预判，以至于其短信验证码登录模块缺乏足够的安全防护，被攻击者绕过导致注册了大量垃圾账号。而此刻，在对新的应用进行技术架构评审的时候，若发现应用依然涉及短信登录，那么就对这部分的的安全防护方案进行着重检查。

总结

技术架构安全评审的最大价值在于，使得开发团队可以在更早的时候得知应用的安全质量是否存在安全隐患，并且可以在这个时候以更低的成本做出改进，否则等到应用临近上线前的渗透测试再发现由于技术架构而引起的安全漏洞，其修复成本往往很高甚至无法修复。

技术架构安全评审确实对执行者的安全能力有所要求，与此同时也需要对技术架构甚至背后的业务上下文有所了解，因此推荐是安全团队和开发团队成员共同结对来完成这项工作。