当前网络环境的大背景下,中台类应用架构设计愈加复杂。
云原生技术的引入,使得单纯的安全测试和扫描,已经无法满足对中台类应用的检查需求。
故而我们根据组织内部的研发现状,以及过往的审计经验,为这类应用定制了架构安全评审的标准流程。
建立可复制的标准评审流程,储备架构安全元数据,进行风险识别及评审的半自动化能力建设。
本评审流程适用于大多数中台类应用,包含基础中台和业务中台。
2.1.1 应用信息确认
在启动评审前,应用开发人员需要完成对信息的填报,再由安全评审人员需要对应用信息进行审计。
完成以上工作后,安全评审人员需要根据IT资产库的数据进行复核,最后完成对应用的基础信息评估。
以下是开发人员填需要填报的信息表示例(均为模拟数据):
评审项 | 详细描述 | 评审标准 | 更新时间 |
---|---|---|---|
是否接入认证 | 统一认证或者自建认证体系。 |
| 2022-08-25 |
是否涉及鉴权 | 包括横向鉴权、纵向鉴权、授权访问。 |
| 2022-08-24 |
2.1.2 业务信息确认
在启动评审前,安全团队要求应用业务方完成对业务信息的填报。
在完成填报后,安全评审人员需要对的内容进行审计。
通过线下沟通和产品文档Review,最后完成对应用的业务信息评估。
以下是业务人员需要填报的业务信息表示例(均为模拟数据):
评审项 | 详细描述 | 评审标准 | 更新时间 |
---|---|---|---|
敏感信息类型 | 针对组织内部的基线制度要求,对敏感信息的类型进行枚举。 |
| 2021-12-11 |
系统使用对象 | 用于判定系统的风险类型和等级。 |
| 2021-12-13 |
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.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 基础架构绘制
对于中台类应用而言,为其绘制相对完整的基础架构图是很有必要的。
由于应用安全架构评估,会更专注于针对攻击面和路径的覆盖。
剔除原有噪声数据,尽可能只保留安全属性,可能会让评估更加高效。
示例如下(均为模拟数据):
在准备好应用相关的基础信息后,我们可以选用STRIDE模型,针对应用的架构进行了威胁识别分析。
特定场景需要特定分析,以下均为模拟数据:
2.5.1 问题复现
我们基于安全检查清单的校对结果,以及威胁建模的结论。
最终可以生成模拟攻击路径,并进行灰盒测试演练。
除此以外,我们还可以通过和研发/测试人员进行访谈,再针对无法实施攻击
的路径进行确认,完成沙盘练兵的效果。
某次攻击演练示例如下(均为模拟数据):
2.5.2 闭环解决
对于已经确认可用的风险路径,我们会录入安全运营平台,通过人工督办的形式直至修复闭环。
对于无法整改的风险,我们会录入例外平台,督促开发人员添加长短期风险缓释措施。
同时,会安排专人定期跟踪审计,直到应用下线为止。
2.6.1 元数据聚合
针对架构安全评审的结果,我们会录入元数据平台,并定期对数据进行人工审计运营。
对于实时性强的基础信息(如接口字段),我们会通过自动化手段进行爬取解析,动态更新到元数据平台。
2.6.2 动态评审
目前的人力投入比较有限,同时安全评审人员的水准也不一,仅能保障核心的中台类应用完成有效评审。
我们计划优化完善现有的安全评审平台,针对业务人员和研发人员填报的内容,通过语义识别能力进行要素提取。
最终借助安全评审平台上的审计规则,实现半自动化架构安全评审。
对于应用架构的安全评审,我们从组织的实际情况进行考量,定制了可以在内部自适应拓展的方案。
从实施的效果来看,确实还存在一些不尽如意的地方,对于自动化能力的建设更是路长道远。
希望有兴趣的专家朋友不吝赐教。