当前位置：首页 > news >正文

⸢ 肆-Ⅱ⸥ ⤳ 风险发现体系的演进（上）：背景与现状

news 2025/9/17 5:52:26

👍点「赞」📌收「藏」👀关「注」💬评「论」

在金融科技深度融合的背景下，信息安全已从单纯的技术攻防扩展至架构、合规、流程与创新的系统工程。作为一名从业十多年的老兵，将系统阐述数字银行安全体系的建设路径与方法论，旨在提出一套可落地、系统化、前瞻性的新一代安全架构。

序号	主题	内容简述
1	安全架构概述	全局安全架构设计，描述基础框架。
👉2	默认安全	标准化安全策略，针对已知风险的标准化防控（如基线配置、补丁管理）。
3	可信纵深防御	多层防御体系，应对未知威胁与高级攻击（如APT攻击、零日漏洞）。
4	威胁感知与响应	实时监测、分析威胁，快速处置安全事件，优化第二、三部分策略。
5	实战检验	通过红蓝对抗演练验证防御体系有效性，提升安全水位。
6	安全数智化	运用数据化、自动化、智能化（如AI）提升安全运营（各部分）效率。

4.5 风险发现体系的演进

4.5.1 背景及现状

4.5.2 安全产品的转变

4.5.3 实现思路

4.5.3.1 算力驱动：安全分析的“发动机”

4.5.3.2 数据打通：构建统一的“数据湖”

4.5.3.3 图数据模型存储：绘制“安全知识图谱”

4.5.3.4 应用逻辑数据化

1.程序分析：从“资产数据化”到“逻辑数据化”的跨越

2.构建应用内部逻辑图

3. 如何方便地使用？

4. 需要做到什么粒度？

👍点「赞」➛📌收「藏」➛👀关「注」➛💬评「论」

4.5 风险发现体系的演进

4.5.1 背景及现状

随着企业中台战略的推行，安全组织架构演进 “安全中台” 与 “业务线安全团队” 协同模式。

具体如下：

组织职责分工：
- 安全中台部门：核心职能是提供通用安全能力，并为各业务线安全部门的工作提供支持。
- 业务线安全团队：作为一线团队，与业务部门协同作战，承担直接保障业务安全的责任，具体工作包括业务安全评估、业务漏洞收敛，是实现安全能力赋能业务 “最后一公里” 的关键。
安全产品运营模式：
- 每个安全产品由专属小团队负责日常开发与运营，需为所有业务线的 CISO 团队提供其日常工作所需的安全能力。
- 各安全产品拥有独立的能力体系，包含自身的调度中心、数据中心与运营中心，这是多数集团企业安全组织及安全产品的普遍现状。

这种模式在过去有效支撑了企业安全运营，但随着安全工作的深化，暴露出的三大核心问题：

挑战	具体表现与痛点	导致的后果
🚧 1. 能力与数据孤岛	各安全产品自有体系（调度、数据、运营中心），缺乏协同设计。所需协作常是子功能模块或中间数据的调用，而非简单结果互通。	协作成本极高，无法高效应对复杂的复合型安全风险。
⚔️ 2. 需求多元与资源矛盾	CISO需求复杂多样、要求快速迭代、且常需定制。安全中台资源有限，响应需求流程长、排期慢。	风险空窗期长；CISO可能自建能力，导致重复建设；中台核心能力投入被稀释。
🧩 3. 运营体验割裂	一线人员需登录多个独立的运营中心（控制台）才能完成一个整体性的安全评估任务。	工作流程被打断，效率低下，影响风险评估的全面性和准确性。

场景示例比喻：

【能力孤岛问题】
- 比喻：某“行政区”报告发现一个可疑仓库（主机检测发现漏洞jar包）。区管委会想知道这个仓库的物资是否流入了区的超市（代码是否使用了该jar包）。这需要协调“市政总公司”旗下的警务系统（数据）和工商管理系统（能力）联合排查。
- 现状：但警务系统和工商系统数据不互通，流程独立，写报告、打申请、等审批，协作成本极高，错过最佳检查时机。
【资源瓶颈问题】
- 比喻：金融区要求给所有银行金库加装一种新型防爆门，电商区要求给所有快递站升级最新安检仪。它们都拿着图纸去找“市政总公司”的工程部。
- 现状：工程部人手就那么多，既要维护现有设施，又要应对所有区的定制化新需求，根本忙不过来。结果，金融区等不及，只好自己找人先装了个简易的；电商区因为单子大，优先排期，其他区的需求就只能等着。市政总公司疲于应付各种需求，反而没精力去升级核心的全市供水供电网络了。
【体验割裂问题】
- 比喻：区安全员想全面了解一栋重点大楼（某个业务接口）的安全状况。他需要：
  - 跑去水务局查这栋楼的用水异常情况（Web漏洞）。
  - 跑去电力局查用电负荷和隐患（主机漏洞）。
  - 跑去消防局查消防设施是否合格（配置风险）。
- 现状：他得跑三个地方，填三张不同的表格，看三套不同的系统。而他理想的工作方式，是有一个 “城市安全一网通办” 平台，输入大楼名字，水、电、气、消防所有安全信息一目了然。

4.5.2 安全产品的转变

安全产品的核心驱动力正从 “规则与功能” 转向 “数据与算力” 。企业安全团队必须利用自身独特的资产信息透明优势，将安全产品重构为数据采集的“传感器”，通过云端统一的数据处理与计算，构建全局视角的“安全资产大图”，从而实现更智能、更高效的风险发现与运营。

核心转变：从IT时代到DT时代

维度	🛠️ IT时代（传统安全）	📊 DT时代（现代安全）
核心驱动力	规则库、漏洞特征、单个产品功能强弱	数据 + 算力
工作模式	各个安全产品独立扫描，在自己的控制台内输出结果	安全产品作为传感器，只负责采集数据，统一上报到云端进行分析
优势比较	与黑客比拼谁的扫描器规则更多、节点更多	利用黑客没有的透明资产数据，先发制人
风险发现方式	在单个扫描器上编写规则进行匹配	在云端基于资产大图进行关联计算和分析
目标	发现一个特定的、已知类型的漏洞	还原资产及内部运行逻辑的全貌，发现未知、关联性风险

通俗比喻：从“独立侦探”到“天网系统”

想象一下传统的安全模式：

🕵️‍♂️ IT时代 - 独立侦探：每个安全产品就像一個独立的侦探（Web扫描侦探、主机扫描侦探）。他们各自为政，用自己的方法（规则库）在自己的地盘（业务线）上调查，然后分别向你报告：“A地点发现一个脚印”（发现一个Web漏洞）、“B地点听到一声异响”（发现一个系统漏洞）。你需要自己把他们的信息拼凑起来，才能猜测整个事件的全貌。 效率低，且容易遗漏关键关联。

而现在倡导的DT时代模式：

📡 DT时代 - 天网系统：每个安全产品不再自己做复杂判断，而是转型为遍布全城的“摄像头”和“传感器”（传感器）。它们只负责采集最原始的、多维度的事实数据（谁、在哪里、什么时间、发生了什么）。
所有这些视频流和数据流都被实时传送到中央数据处理中心（云端算力）。
中心拥有强大的计算能力，基于所有数据绘制出整个城市的实时动态地图（安全资产大图）。
一旦有异常发生，中心不是基于一条单一规则（比如发现一把刀），而是通过综合分析（一个人从五金店买了刀，快速走向人流密集的广场，表情紧张……）来预警风险。它能发现看似无关的事件间隐藏的关联，从而预测和发现更复杂的威胁。

这个转变的核心优势在于：企业自己拥有“城市”的所有蓝图（资产信息透明），这是外部的“破坏者”（黑客）永远无法获得的全局视角。充分利用这个优势，就能在他们动手前，提前发现和加固最脆弱的地方。

4.5.3 实现思路

构建下一代安全能力体系的三大核心基石是：算力驱动、数据打通和图数据模型存储。这三者相辅相成，共同为实现“全局安全视野”和“数据驱动安全”提供支撑。

核心思路	核心要求	解决的问题	价值
算力驱动	强大的分布式大数据计算平台（如MaxCompute, TuGraph）	海量安全数据的处理与分析能力不足	提供动力，让大规模、复杂的数据分析成为可能
数据打通	统一数据计算平台，减少API调用，直接底层取数	数据孤岛，数据交换效率低、成本高	奠定基础，极大降低数据使用成本，保证数据灵活性
图数据模型	使用图数据库（而非关系型数据库）存储和关联数据	多维度数据关联计算爆炸、业务逻辑还原困难	实现关键，高效还原资产全貌，支持复杂关联分析

4.5.3.1 算力驱动：安全分析的“发动机”

强大的算力是处理海量安全数据的前提。它将安全人员从“能不能算”的束缚中解放出来，专注于“算什么”和“怎么算”的策略问题。

在网商银行，使用MaxCompute、TuGraph等强大的分布式大数据计算产品以及足够的算力，这为安全数据分析提供了支持。

4.5.3.2 数据打通：构建统一的“数据湖”

这是实现“全局视野”的第一步。其核心不是简单地把数据放在一起，而是打通存储底层，实现高效、低成本的数据访问。

传统方式 vs 理想方式：

4.5.3.3 图数据模型存储：绘制“安全知识图谱”

数据取到之后，需要整合这些数据并且构建它们的关系大图，往后所有的安全运营工作都基于这张大图，而不再依赖安全产品自身的规则检测能力。

为什么选择图数据库？

对比维度	❌ 关系型数据库 (如MySQL)	✅ 图数据库 (如TuGraph)
数据模型	表结构， rigid	图结构：节点（实体）和边（关系）进行抽象，灵活
关联查询	JOIN操作，表越多性能越差，复杂度高	遍历关系，速度快，复杂度可低至O(1)
扩展性	新增关系可能需要改变表结构	增加关系只是增加节点、边，无需改变现有结构
业务贴合度	难以直观表达复杂关系	天然贴合，轻松还原业务逻辑和资产关系

优势维度	核心思想	效果对比
1. 模型直观性	高度贴合现实世界，直接用节点（实体）和边（关系）进行抽象。	✅ 一目了然：像画地图一样自然还原复杂的资产和业务逻辑全貌。 ❌ 传统方式：像用Excel表记录社交关系，难以直观呈现网络结构。
2. 扩展灵活性	增维成本极低，新增数据维度仅需添加节点属性或新的边。	✅ 线性扩展：增加新关系，如同在地图上画一条新线，简单高效。 ❌ 传统方式：像数据库表结构，每增加一种新关系可能需创建新表并复杂关联（JOIN），导致计算量爆炸。
3. 关联高效性	为关联查询而生，探索关系是其原生优势，时间复杂度极低。	✅ 瞬时关联：查询“朋友的朋友”仅需遍历边，速度极快（接近O(1)）。 ❌ 传统方式：查询如同在多个电话簿中反复翻找和匹配（大量JOIN操作），性能开销大且缓慢。

通俗比喻：

关系型数据库像一本电话簿，你要找“谁和谁是朋友”需要翻遍整本书去比对。

图数据库像一张社交网络关系图，一眼就能看出谁和谁相连，关系多远。你想知道“朋友的朋友的朋友谁开了家便利店？”，图数据库能瞬间告诉你答案，而关系型数据库可能已经卡死了。

图数据库通过节点（资产，如服务器、代码包、API）和边（关系，如“运行在”、“调用了”、“依赖于”）来构建一个 interconnected 的网络（大图）。基于这个大图，进行风险溯源、影响面分析等操作变得异常高效和自然。

图模型实践挑战：

尽管图模型在数据关联分析上具有巨大优势，但其在实际企业级部署中仍面临挑战，主要可归纳为以下两点及相应的解决思路：

挑战维度	核心问题	应对策略与解决方案
1. 技术门槛与兼容性	查询语言不统一：存在Gremlin、Cypher等多种标准，增加了学习成本。工程师习惯差异：数据分析师更熟悉SQL和结构化数据分析。	混合架构，灵活输出： • 核心层：保持图数据库存储，进行复杂的关联关系分析。 • 应用层：将图分析结果导出为传统表格（如CSV）或物化视图，供数据分析师使用熟悉工具（如SQL、Pandas）进行下游特定场景的深度分析。
2. 性能与可扩展性	数据量巨大：所有数据存入单一物理图数据库可能导致性能瓶颈和压力过大。	逻辑统一，物理分离： • 逻辑大图：在概念上保持一个完整的全局图视角。 • 物理分图：在底层，按业务域或数据类型拆分成多个子图存储和计算，降低单一数据库压力。 • 离线计算：对非实时、计算密集型的分析任务，将数据导出到大数据平台（如MaxCompute、Spark）上进行分布式离线计算，最终将结果汇回。

通俗比喻：

挑战1（语言与习惯）：就像这个导航系统的核心引擎非常强大，但操作界面是专业术语（图查询语言）。为了让普通司机（数据分析师）也能方便地使用，系统提供了一个“一键导出路线报告” 的功能，将最优路线转换成一份简单的文字说明（结构化表格），司机可以用自己的方式去理解。
挑战2（性能与扩展）：就像无法用一张无比精细的纸质地图来显示全世界的实时路况。我们的解决方案是：
- 逻辑统一：在逻辑上仍然在使用一个完整的“全球地图”App（逻辑大图）。
- 物理分离：但后台实际上是由北美、欧洲、亚洲等多个服务器集群（物理分图） 共同支撑的，数据查询被路由到最近的节点。
- 离线计算：对于“预测明天全球最拥堵路段”这种复杂计算任务，则交给离线大数据系统处理，计算完再把结果更新到在线系统中。

4.5.3.4 应用逻辑数据化

1.程序分析：从“资产数据化”到“逻辑数据化”的跨越

当前企业安全已基本完成基础资产的数据化，即摸清了“有什么”（如服务器、IP、端口、负载均衡），但这仅相当于绘制了一张静态的城市地图，只知道建筑的位置，却不知道建筑内部的运作逻辑。

应用逻辑数据化是实现更高阶安全能力所欠缺的关键一跃。其目标是超越对基础设施的简单盘点，深入还原代码内部的业务逻辑、数据流、调用关系，从而构建一个动态的、能真实反映业务运行全貌的“数字孪生体”。

程序分析技术（静态+动态分析） 是实现这一跨越的关键技术手段。

分析方式	核心原理	优点	缺点	工程角色
静态分析	在不运行代码的情况下，直接分析源代码或编译后的字节码。	覆盖广：可分析所有代码路径。性能零损耗：不影响线上应用运行。易于自动化：适合大规模扫描。	存在误报/漏报：难以处理动态特性（如反射、多态）。分析深度有限：无法获取运行时状态。	主力军：绘制“蓝图” 快速、低成本地构建出应用逻辑的主体框架和大部分数据流。
动态分析	在应用运行时，通过插桩（Instrumentation）技术收集执行数据。	结果精确：基于真实运行状态，误报率极低。能捕获动态行为：可处理反射、运行时代理等复杂场景。	性能开销：插桩可能影响应用性能。覆盖不全：只能分析被执行到的代码路径。部署复杂：需介入运行时环境。	特种部队：精准补全用于验证静态分析结果、补全静态无法分析的调用边、采集运行时真实数据。

2.构建应用内部逻辑图

核心技术：使用程序分析技术（如静态分析、抽象语法树AST解析）生成代码属性图（CPG）。CPG是一种将代码的结构（类、方法）、控制流（执行顺序）、数据流（变量传播）等信息统一表示的图模型。
下图为应用内部逻辑图：
存储选择：将CPG持久化存储在图数据库中（如Neo4j, Nebula Graph, JanusGraph）。因为图数据库天生为处理“关系”而设计，非常适合表达代码元素之间的复杂互联，并能高效执行图遍历查询。
关键补充：利用动态分析（如插桩、APM工具）获取运行时信息（如真实的调用链、反射调用的目标、拦截器的生效情况），用来修正、补充和确认静态分析生成的图模型，使其更准确。

3. 如何方便地使用？

查询语言：使用图查询语言（如Gremlin, Cypher）来编写分析规则。这就像用SQL查询数据库一样自然。例如，您的漏洞检测规则就变成一条“从源点出发，沿着数据流边，寻找能否到达汇点”的路径查询。
UDF（用户自定义函数）：为了表达复杂的语义（如判断一个过滤函数是否净化了数据），需要提供UDF扩展机制，与图查询语言配合使用。这正是Tabby和CodeQL的强大之处。
统一分析平台：最终目标是将所有应用的数据都整合到一张巨大的“应用关系大图”中。在这个统一的平台上，可以：
- 进行跨应用、跨语言的安全漏洞分析（白盒）。
- 进行运行时风险监控（灰盒）。
- 实现软件组成分析（SCA）、API治理、架构依赖分析等几乎所有应用治理工作。

4. 需要做到什么粒度？

这是一个在理想和现实之间的权衡。

理想粒度：记录所有的控制流、数据流、函数调用、字段读写、甚至代码语义。实现“全知全能”，分析无所遗漏。
现实粒度：必须向性能（分析耗时、内存占用）、可扩展性（支持大型项目）、工程复杂度妥协。
- 常见取舍：
  - 对语言特性（如复杂的反射、动态代理）做保守估计或摘要。
  - 对第三方库采用不同的分析策略（通常只分析其公共API，而不是深入其内部实现）。
  - 在保证核心数据流和控制流准确的前提下，适当放弃一些精度。

通俗比喻：绘制“城市交通与建筑蓝图”

想象一下你要为一个庞大的城市（企业数字业务）构建一个完整的数字孪生体，用于进行应急演练和风险排查（安全分析）。

基础资产数据化（我们已经有的）：

这相当于我们已经有了城市的地图，上面标明了所有建筑的位置（服务器IP）、道路（网络）、建筑的高度和材质（系统配置）。

局限性：你只知道楼在哪，但不知道楼里每个房间是做什么的（业务功能）、人怎么在里面走动（内部逻辑）、以及楼与楼之间的人们如何往来（应用间调用）。

应用逻辑数据化（本节的目标）：

就是要绘制出每一栋建筑的详细内部蓝图（静态分析：分析建筑图纸）并结合人员流动的热力图（动态分析：在关键通道安装传感器观察实际人流）。

静态分析如看蓝图：能知道承重墙、管道布局、房间功能划分（类、方法、代码逻辑），但无法知道人们是否真的按设计来使用。

动态分析如传感器：能知道哪些走廊最拥挤、人们实际上从哪个房间到哪个房间（运行时调用链），但无法全覆盖，且装太多传感器会影响正常通行（性能损耗）。

构建应用逻辑图（最终成果）：

将所有建筑的蓝图和传感器数据整合起来，你就得到了一张超详细的“城市智慧运营图”。

这张图不仅包含建筑，还包含了里面所有的房间、走廊、人员流动关系。这就是存储在图数据库里的应用逻辑图。

全局应用调用关系大图（终极愿景）：

最后，把城市里所有建筑的“智慧运营图”通过“街道”（API调用、RPC调用）连接起来，就形成了整个城市的数字孪生体。

在这个数字城市里，你可以轻松模拟和发现：

“如果这条主水管（公共组件）破裂，会影响哪些建筑？”（漏洞影响面分析）

“有毒物质（恶意数据）从城北入口进入，可能通过什么路径扩散到市中心？”（跨应用污点追踪）

“这座新建的体育馆（新上线应用）和周围的交通流量的关系是怎样的？”（新应用接入治理）