应用架构安全评审能力建设

一、背景

1.1 概述

当前网络环境的大背景下，中台类应用架构设计愈加复杂。

云原生技术的引入，使得单纯的安全测试和扫描，已经无法满足对中台类应用的检查需求。

故而我们根据组织内部的研发现状，以及过往的审计经验，为这类应用定制了架构安全评审的标准流程。

1.2 目标

建立可复制的标准评审流程，储备架构安全元数据，进行风险识别及评审的半自动化能力建设。

1.3 评审对象

本评审流程适用于大多数中台类应用，包含基础中台和业务中台。

1.4 整体思路

二、操作步骤

2.1 问卷沟通

2.1.1 应用信息确认

在启动评审前，应用开发人员需要完成对信息的填报，再由安全评审人员需要对应用信息进行审计。

完成以上工作后，安全评审人员需要根据IT资产库的数据进行复核，最后完成对应用的基础信息评估。

以下是开发人员填需要填报的信息表示例（均为模拟数据）：

评审项	详细描述	评审标准	更新时间
是否接入认证	统一认证或者自建认证体系。	接入统一认证 接入自建认证 无认证	2022-08-25
是否涉及鉴权	包括横向鉴权、纵向鉴权、授权访问。	涉及鉴权 无需鉴权 没有鉴权	2022-08-24

2.1.2 业务信息确认

在启动评审前，安全团队要求应用业务方完成对业务信息的填报。

在完成填报后，安全评审人员需要对的内容进行审计。

通过线下沟通和产品文档Review，最后完成对应用的业务信息评估。

以下是业务人员需要填报的业务信息表示例（均为模拟数据）：

评审项	详细描述	评审标准	更新时间
敏感信息类型	针对组织内部的基线制度要求，对敏感信息的类型进行枚举。	证件信息 资金账号信息 交易流水信息	2021-12-11
系统使用对象	用于判定系统的风险类型和等级。	业务人员 合作厂商 外部客户	2021-12-13

2.2 标杆调研

2.2.1 业界竞品

对于中台类应用，我们会对业内同类竞品的方案设计进行调研。

其中，我们会重点关注开源产品的标准，以及业内优秀方案的提出标准。

对于其中涉及安全属性的部分，我们会作为重点项录入安全检查清单。

这里以网关产品作为演示，生成了一份安全检查清单，以下信息来源于网络资料：

网关	限流	鉴权	监控
Spring Cloud Gateway	可以通过IP/用户/集群限流，提供了相应的接口进行扩展	普通鉴权 Auth2.0	Gateway Metrics Filter
Zuul2	可以通过配置文件，配置集群限流和单服务器限流，亦可通过Filter实现限流扩展	Filter中实现	Filter中实现
OpenResty	需要Lua开发	需要Lua开发	需要开发
Kong	根据用户进行限流，粒度支持秒/分/时/天/月/年。 可在源码的基础上进行开发。	支持普通鉴权，Key Auth鉴权，HMAC，Auth2.0	可上报Datadog，记录请求数量，请求数据量，应答数据量；接收与发送的时间间隔，状态码数量，Kong内运行时间等等

2.2.1 内部竞品

对于组织内部的竞品，我们会以竞品间相对成熟的功能作为锚点。

对于其中涉及安全属性的部分，也会作为重点项录入安全检查清单。

大体核查方式和业内竞品识别类似，这里不再做赘述。

2.3 路径绘制

2.3.1 数据流绘制

我们需要针对数据流（Data Flow）进行绘制，确保路径节点能较为准确的进行记录，其中需要重点关注应用间的交互情况。

以下是某外购产品的数据流示例（均为模拟数据）：

在其中的关键实体节点，我们需要对带安全属性的表/字段进行标注，以下是数据表示例（均为模拟数据）：

重点字段	数据类型	是否完成国密加密	使用方式
密码	客户数据	是	传输
信用卡号	客户数据	否	存储

2.3.2 调用链绘制

针对调用链的绘制，主要依赖于上下游基础数据的建设。

这里是从应用和接口两个维度完成绘制：

（1）应用层面：

根据上下游调用关系，分层级建立树状图，示例如下（均为模拟数据）：

（2）接口层面：

聚合埋点调用栈，建立完整的回溯链路，这里的埋点数据通过基建中台的客户端SDK完成上报。

示例如下（均为模拟数据）：

来源应用	来源API	目标应用	目标API	调用关系
CORE_PAY	dubbo_cpay.getActData	XDR_CP	dubbo_xdr.share-info	正向

可以预见的是，对于复杂应用的接口链路，如果需要进行完整分析，

对绘制的生成和存储工作，都会耗费较多的资源。

所以，如果需要长期存储，建议仅涵盖涉及安全属性的链路。

2.3.3 基础架构绘制

对于中台类应用而言，为其绘制相对完整的基础架构图是很有必要的。

由于应用安全架构评估，会更专注于针对攻击面和路径的覆盖。

剔除原有噪声数据，尽可能只保留安全属性，可能会让评估更加高效。

示例如下（均为模拟数据）：

2.4 威胁建模

在准备好应用相关的基础信息后，我们可以选用STRIDE模型，针对应用的架构进行了威胁识别分析。

特定场景需要特定分析，以下均为模拟数据：

2.5 风险闭环

2.5.1 问题复现

我们基于安全检查清单的校对结果，以及威胁建模的结论。

最终可以生成模拟攻击路径，并进行灰盒测试演练。

除此以外，我们还可以通过和研发/测试人员进行访谈，再针对无法实施攻击

的路径进行确认，完成沙盘练兵的效果。

某次攻击演练示例如下（均为模拟数据）：

2.5.2 闭环解决

对于已经确认可用的风险路径，我们会录入安全运营平台，通过人工督办的形式直至修复闭环。

对于无法整改的风险，我们会录入例外平台，督促开发人员添加长短期风险缓释措施。

同时，会安排专人定期跟踪审计，直到应用下线为止。

2.6 自动化建设

2.6.1 元数据聚合

针对架构安全评审的结果，我们会录入元数据平台，并定期对数据进行人工审计运营。

对于实时性强的基础信息（如接口字段），我们会通过自动化手段进行爬取解析，动态更新到元数据平台。

2.6.2 动态评审

目前的人力投入比较有限，同时安全评审人员的水准也不一，仅能保障核心的中台类应用完成有效评审。

我们计划优化完善现有的安全评审平台，针对业务人员和研发人员填报的内容，通过语义识别能力进行要素提取。

最终借助安全评审平台上的审计规则，实现半自动化架构安全评审。

三、总结

对于应用架构的安全评审，我们从组织的实际情况进行考量，定制了可以在内部自适应拓展的方案。

从实施的效果来看，确实还存在一些不尽如意的地方，对于自动化能力的建设更是路长道远。

希望有兴趣的专家朋友不吝赐教。

原文始发于微信公众号（FreeBuf）：应用架构安全评审能力建设