1.概述

完整的安全评审会包含安全架构评审、安全代码审核和安全测试三个手段

安全架构评审聚焦于探寻安全设计中的漏洞，以宏观视野全面考量应用的安全性状况，能够迅速甄别业务系统关键的安全需求，同时精准判断当前安全防护机制能否契合这些需求，此乃极具投入产出效益的活动。故而，安全架构评审径直左右着整个安全评审工作的品质优劣，并且为安全编码以及安全测试清晰地指引出核心要点与方向

安全设计的系统不会只着眼于眼前的攻击和已知漏洞，还应该对未知的漏洞0day都具备一定的抵御能力

---

2.安全设计原则

安全防护的三大支柱：

1、纵深防御

在构建防御体系时，不应仅仅依赖某一种单一的防护机制，而应着重依靠能够相互补充的多层次、多方位且多角度的综合性机制。

纵深防御体系的构建可依据多个维度展开部署，例如从物理层级到应用层级的不同层面，基于物理位置差异所设定的各个控制点，区分是处于外围防线还是内置防线的不同布局，以及按照防护的时机与阶段的规划等。当成功构建并妥善部署这样的纵深防御体系后，即便其中某一种防护手段失效，也能够有效阻止攻击轻易达成目的，即便在遭受攻击并部分被突破的情况下，依然可以将损失控制在可承受的范围之内，从而最大程度地保障系统安全。

2、最小权限

在一个系统（如操作系统、数据库系统、应用程序等）中，无论是用户、进程还是其他实体，都应该被赋予完成其工作任务所必需的最小限度的权限，而不应该拥有超出其需求的额外权限

能否实现最小权限，往往是对一个公司对安全努力程度，以及对应的技术水平的试金石

3、默认安全

默认安全的基本原则就是，让安全一开始就成为内置的属性。一个带有漏洞的容器镜像发布出去，可能就意味着几万乃至几十万的主机存在漏洞的副本。默认安全需要大量额外的工作，但这些工作又绝对是值得的

4、注定失效

在设计安全系统时，需要考虑到你的防护注定会失效，并充分考虑并演练不同的失效场景，确保你的安全性在失效时依然能够得到保证。这点除了通过按纵深防御原则部署你的防控机制外，每个系统事先设计、反复演练失效时的应急预案至关重要。其中保证系统可用性的降级方案，不能牺牲安全性是首先需要考虑的。

5、适用性原则

安全注定要提高成本。然而好的安全性设计，以及应用适当的技术，是能够有效降低这种成本

6、开放性设计

不要自创算法。尤其是像加密、认证等关键的安全方案

---

3.美团安全架构评审模型

安全架构评审的产出主要包含下面文件：

安全需求分析

安全需求应该作为非功能需求在应用开发早期提出，并在应用设计和实现中得到实现，安全需求主要包括：

1️⃣ 安全目标综述

依据应用的核心功能，对应用的整体安全目标进行描述，说明应用处理的关键资产，这些资产面临的风险以及安全防护的要求。安全需求描述例子：系统存储的用户姓名、手机号等个人信息，在存储、传输过程中必须得到保护，一旦防护失效，导致大批量泄漏会直接影响用户资产乃至导致公司声誉、业务收到严重影响；数据库root权限一旦泄漏，将导致所有数据泄漏，或者被删除。

2️⃣ 通用安全需求

• 身份认证的安全需求
• 会话安全需求
• 权限控制安全需求
• 日志审计安全需求
• 数据加密安全需求
• 网络以及其他隔离安全需求
• 基础设施安全需求
• 安全编码相关需求

架构review

架构评审主要目的是准确、详细的还原应用系统的原貌。首先要有一个整体的架构图，具体的架构图可以依据应用的复杂度分层次给出。

1、逻辑架构图

以服务为粒度画出应用的内外部组件以及相互间的访问关系。对于复杂的系统还要给出更深层次的详细架构图，可以细到微服务，或者单个集群的单个主机，包含所有的中间件如负载均衡、消息队列等。

2、应用场景的数据流图

应用场景要尽量全，不仅要涉及日常使用场景，还需要从服务注册、接入到使用乃至注销变更等生命周期的所有场景都覆盖。

3、识别关键技术

除了画出架构和数据流图，还要列出系统各个组件使用的技术、模块，包括但不局限于操作系统、数据库和其他中间件存储组件，给出技术清单。对于内部依赖的组件，要求必须经过评审；对于外部组件，要求必须进行过扫描和安全配置评审，确保没有漏洞。

4、识别关键资产

形成系统处理的数据清单，并明确它的生成、传输、存储是否加密，访问控制是否到位。明确这些数据的密级，以及保护需求。这里要注意，除了业务数据、访问系统的密码、加密的密钥等数据凭证需要作为最核心的资产首先要标示出来。

形成应用的资产清单，从域名、微服务ID、主机集群、IP地址，域名，使用的各种组件清单。此外，还包括应用的研发、项目资源，如代码仓库，制品库，系统镜像。

5、安全防护配置记录

主要审查以下几项： 安全防护机制是否覆盖所有的访问入口和资源？防护技术采用的算法和具体实现是否存在缺陷？是否有明确的安全策略，配置是否进行过审计？尤其要注意自创的算法和实现方案，往往容易出现漏洞。

具体的防护机制需要采集的信息有：

• 认证系统相关信息

• 权限控制系统相关信息

• 加密方案以及实现机制

  ▸包括密码和凭据的生成，保存方案

  ▸业务敏感数据的存储加密方案

  ▸传输通道的加密方案

• 日志审计和监控方案

• 网络隔离方案

攻击面分析和威胁建模

安全架构分析的核心，就是威胁建模。对于威胁建模，SDL两个问题制约了它的发展：第一个是太重了，流程化的东西太过繁琐、僵化。面对微服务、DevOps等小、快、零的开发模式明显头重脚轻，无法集成到产品的流水线当中；第二是太追求傻瓜化，和微软其他软件理念一样，希望教给一个小白都可以完成安全评审，忽略了安全系统中的复杂性和专业性。

对于简化的威胁建模过程主要分攻击面分析（过程）和威胁列表（结果）两部分：

攻击面分析

1、信任边界识别

常见信任边界：

• 网络边界：常用的有Internet、办公网、开发测试网、生产网，或安全生产网（Security Zone）
• 应用、服务边界：不论是微服务还是单体架构，服务往往会形成自己的集群，服务内部相当于一个可信区，内部组件可以自由访问
• 主机边界：主机通常是服务的载体，也是服务实现的原子单位
• 用户边界
• 租户、项目逻辑边界：对于SaaS层服务，用户资源是共享在一个公用的集群，并没有明显的物理边界，实际的边界是通过基于认证和权限的访问控制隔离的

2、攻击入口识别

每一个数据流入、流出的入口点就是攻击入口。你需要在每一个数据入口点对应的信任边界识别有哪些必要的防护机制缺失，就能识别出漏洞，生成威胁列表了。把缺失的防护机制补上，就相当于修复了

威胁列表

威胁列表是整个安全架构评审中重要的产出。具体字段和描述如下：

●  威胁ID●  威胁描述▸某某资产对象，在某过程中，未做XX防护或者xx防护缺失，导致XX信息泄漏。●  威胁分类▸有多种分类方法•身份认证•日志审计•权限控制•流量加密•静态或者存储加密•账户、凭据保护•服务鉴权•特权账户或服务保护•网络隔离●  威胁等级▸两个因素： 产生的影响和触发的容易程度，可以参考DREAD模型▸值：高中低●  威胁来源▸这块结合整个安全评审上下文，重点是反映漏洞发现能力的指标•架构评审•代码审核•安全测试•外报和渗透测试●  威胁状态▸跟踪威胁进度•创建•已确认（代码确认、测试确认、人为确认）•修复（未验证）•修复（已验证）●  修复方案▸通用问题，需要启动安全控制项目，本字段做项目-漏洞关联•更新代码、配置（快速修复）•解决方案修复（指明解决方案ID）