应用架构安全评审能力建设
2023-5-22 19:6:33 Author: FreeBuf(查看原文) 阅读量:14 收藏

一、背景

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 动态评审

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

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

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

三、总结

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

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

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


文章来源: http://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651225060&idx=3&sn=e7dee03a4c4ad07e8dbb1fed36514a4c&chksm=bd1de96f8a6a60798ed7c5c6534d49501de20fe305b7ed5fa692b8c371e51e4d17cc2bd0efff#rd
如有侵权请联系:admin#unsafe.sh