本文作者：阿里安全 安全专家 郑虔

2020年中，一名白帽子在GitHub上发现了某新能源车企的一个后台系统所使用的凭据，该凭据简单使用了Base64加密。虽然该凭据并不能直接登录对应的后台系统，但是白帽子通过掌握到的API列表，成功找到几个没有鉴权的接口，通过这些接口，可以批量获取后台数据。

这次潜在危机本应该敲响警钟，但是2020年8月，该车企又遇到了同类安全事件。车主爆料，自己的车辆管控APP上竟然出现了几辆别人的车。虽然车主反馈给车企之后，车企默默修复了该问题。白帽子们通过分析，一致认为该问题又是一起典型的接口缺少鉴权的漏洞。

随着云服务的兴起，传统的企业架构形成了当前比较常见的云+本地的混合部署形态，网络架构也朝混合部署转变，传统的安全防御已不足以应对混合部署下的威胁。

攻防的本质是信息不对称，而漏洞的本质是数据出入口缺少有效控制。在当前的混合部署形势下，“我知道我的企业资产有哪些出入口有问题”就显得极为重要。

行业痛点：盘点自家到底有“多少钱”

这个问题该如何解决，各个企业都有自己的探索与实践。不过在阿里安全看来，问题的根本是企业无法实时掌握自己的资产，尤其是混部结构下的资产。就是我“不知道”我有这些接口，或者我“不知道”这些接口存在安全问题。

当然，知道了我有哪些出入口，还远远不够，当评估业务风险时，又会发现一堆问题都没有得到答案：

 风险有多大？影响面是多少？

 现在的防护策略覆盖了多少？

 如何判断策略是否有效？

 是否还有遗漏在外的资产？

 还有多少可提升的空间？

这一系列问题需要用具体的安全数据来回答，但是现实情况一点都不乐观。

不同类型的资产数据散落在各条业务线，一是很难搜集整合，一是很难理解消化，同时很难进行整体沉淀经验，不同业务线之间很难复用彼此的业务结果。 

我们在期待这样的“天使同事”，她手里有我需要的所有“资产数据”，已经帮我把数据都关联解析完毕，还能根据自己支撑的业务场景，对数据进行了沉淀与打标，你可以完全复用她的方法论，不但可以直接用，还可以根据需要自由组合。

“资产蓝图”就致力于成为这样的“天使同事”。

资产蓝图的解法

2020年3月，阿里巴巴发布了数字基建新一代安全架构。在新的安全架构下，我们重新思考安全防御该如何走的时候，急需一个能用数据说明的可量化驱动系统提供数据输入。这个系统最大的目标就是用数据驱动安全防御走向，这就是蓝图诞生的背景。

蓝图是一个资产采集系统，专注于梳理、盘点、管理大型企业内网资产，可用于发现企业内网的各类基础资产信息、资产指纹、资产间的数据流动血缘；并提供了多维度标签的资产清单，发布成为标签资产目录，以满足业务提出的各类分析应用需求的快速搭建，让资产流动起来，利用起来，让数据从业务中而来，最终为业务所用。

“蓝图”的建设目前经历了四个阶段：

第一阶段，基础资产盘点，需要盘点清楚资产范围、状态、安全防控情况，并了解企业内部的主机、应用、存储、中间件、供应链、源代码、权限等等相关资源。

第二阶段，关联资产盘点，需要盘点不同类节点资产之间的访问关系、关联关系。

第三阶段，血缘资产盘点，需要分析数据在南北向（网络边界从外到内）、东西向（跨应用资源、跨节点访问）的流动路径，画出资产间的边界范围和链路血缘流动关系。

第四阶段，标签资产盘点，在资产数据支撑业务需求后，沉淀有针对性的数据标签，最大化价值。

蓝图选择这种阶梯型的发展计划，原因之一是每个阶段互相支持，但每个阶段的成果都是相对独立可交付使用的。优势是，随着每个阶段的建设完成，可以快速交付每个阶段的成果，让业务快速使用，比如在“基础资产”盘点阶段，主机与应用都可以快速交付给业务进行资产盘点。完成基础资产盘点后，建立主机与应用、域名、负责人的关联关系，可以快速进行安全应急响应、溯源定位。而整个资产大盘可以让业务方清晰地看到现在的资产全貌，甚至通过大盘看到现在安全水位、资产管理水位以及对应的风险。

血缘资产盘点则是整个系统价值的放大器。如果说前面两个节点都是后勤支援，那第三个阶段之后，蓝图就同前线安全团队，站到了一个战壕里，可以直接输出数字化“弹药”。一旦发现攻击行为，根据被攻击的IP地址，安全人员可以快速定位可能受到该服务器影响的一级、二级影响范围，并根据一、二级影响机器对应的应用等级，快速评估攻击风险。

挑战与风险

蓝图的内部发展虽然可谓是一帆风顺，占据了“天时、地利、人和”，但是在实际发展中仍然面临了巨大的挑战。

挑战一：“能用”

没有人事先能知道业务都需要哪些资产数据。

业务方需要盘点资产时，大多数情况下所需要的资产数据多且杂，不仅包括了已经明确的资产范围，甚至还要有供应链关系、特殊的中间件、小众的代码框架等。没有数据就意味着，无法对业务方进行有效的支撑。蓝图除了需要有一个标准化的资产数据输出流程（数据自助申请、接口或视图输出资产数据），来满足大多数业务的需求之外，还需要一个定制需求的入口，对于业务方自己都没有明确的资产数据需求的情况，需要跟业务方做详细的沟通，与业务一起理解所需的资产数据。

最后，蓝图再寻找并引入或者生产出业务方所需要的资产数据，在这个过程中，一方面满足了业务的需求，一方面也补全了蓝图自身的资产数据缺口。

挑战二：“敢用”

没有准召的数据就没有价值。

其实，很多公司都做过资产盘点，但大多都没有“做起来”。究其根源，是资产数据没有“准召”（准确和召回），或者上游资产没有准召，导致下游业务无法稳定使用。

蓝图提供的解法是，投入适当的资源到准召建设中去。依托自身资产数据检查经验，沉淀出具备蓝图特色的可配置化的自动化准召检查系统，利用该系统，完成如下的检查与准召：

 质量基础监控，主要包括完整性、准确性、一致性、及时性的规则配置沉淀及监控告警处置，其中规则分为通用性规则及自定义规则。

 多源头交叉验证，实现多个来源与资产数据&链路数据的对比校验、准召值计算、异常数据监控告警处置，支持自定义SQL以满足运营多样化的交叉验证需求。

 benchmark样本库，支持资产&链路的样本沉淀及使用，支持基于样本库的交叉验证、扫描验证。

 人工验证流程。在无法进行自动化验证的事物上，投入外包资源，抽取一定数量的样本，进行人工准召验证。

挑战三：“好用”

资产数据的价值不是罗列而是加工。

即便有了全面的资产数据，且每一份资产数据都能有准召，如果只是简单的罗列，那这种盘点结果也没有太高的价值。资产盘点的价值一定是在关联、加工的结果中体现的。

蓝图显然不会给自己定位成简单的资产数据堆砌平台，但是怎么实现1+1>2的放大效果，一直是资产盘点领域的难题。蓝图的入口是血缘数据。

通过自建血缘链路的代码分析能力，完成应用代码的自动化分析，提取应用中的接口调用、中间件使用、DB使用等等信息，再结合流量、应用等信息，生成调用链路与数据链路数据，不但解决南北向的边界信息流向路径描画，还完善了东西向应用间信息走向路径。

再结合在线信息、离线信息、以及在离线信息之间的血缘分析，生成血缘数据，掌握DB内数据的流动路径。

最后，应用数据链路/调用链路，加上数据血缘数据，真正实现了从接口到数据库的全向数据流动路径分析。

数据的价值体现大部分都在于第二个用户。

蓝图在服务业务方的同时，积极沉淀业务实际使用需求与经验，在标准化基础数据的基础上，建设具有业务属性的资产标签，复用多方业务效果，最大化业务治理的价值。

如在服务于内容安全风险业务场景时，蓝图从技术层面打标具有内容增改逻辑的接口，再结合业务具体使用情况，对接口进行标记。蓝图再结合改进后的逻辑，给其他的接口进行打标。在另外一个项目中，这批具备标签的内容增改接口，可以直接作为既定接口范围，根据业务需要，重点做二次筛选即可，不但做到业务价值最大化复用，也真正做到取自业务用于业务。

驱动安全运营

蓝图通过四个阶段的发展，依托海量资产数据，建立混合云架构下的资产盘点系统，协助业务方利用资产数据完成资产盘点、风险识别等等各种业务需求，然后提供标准化的资产使用方案，给业务方提供可靠、便捷的高效使用通道。

最终，阿里安全希望，通过客观资产盘点，驱动阿里安全的建设，就如同人体静脉图一样，蓝图通过清晰地资产盘点，能够主动发现风险问题，并成为帮助各安全单位进行有效安全运营的手段。

如若转载，请注明原文地址