⸢ 拾陆-Ⅱ⸥⤳ 安全数智化建设：安全大材料平台

点「赞」收「藏」关「注」评「论」

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

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

16 安全数智化建设与应用实践

16.2 安全大数据平台

16.2.1 工艺架构

16.2.1.1 流式与批计算平台：安全分析的“双核引擎”

2.工作原理：图查询的“翻译”与“执行”之旅

16.2.2 数据模型

16.2.2.1 资产模型

1.痛点：为何需要统一的资产模型？

2.解决方案：如何绘制地图？—— 领域建模与八大分域

16 安全数智化建设与应用实践

16.2 安全大数据平台

在数字银行的建设中，技巧与业务的深度融合是一把“双刃剑”。它带来了极致便捷的用户体验，但同时也让安全形势变得空前复杂：资产、流程、数据和攻击面呈指数级增长。

在此背景下，仅依靠安全工程师进行人工风险运营与告警跟进，无异于“大海捞针”，既不现实，效率也极低。因此，我们必须借助技术手段，为安全工程师打造强大的“武器”与“外骨骼”，核心目标就是：提升效率，减轻负担。

这个关键的技术手段，就是安全大数据平台一个就是——它本质上利用大数据技术来消除大数据安全问题的“智慧大脑”。

16.2.1 技术架构

安全大数据平台的技术架构可以形象地理解为三层：存储层、计算层、数据模型层。其协同工作关系如下图所示：

架构分层详解

架构层	核心角色	关键能力与技术	解决的问题
存储层	数据基石生产要素的承载方	湖仓一体架构，融合数据湖的灵活性与数据仓库的规范性	海量、异构安全信息的统一存储与管理，打破数据孤岛。
计算层	动力引擎计算能力的提供方	实时计算、离线计算、联邦查询、图分析算法	提供多样化的算力，满足从秒级响应到深度挖掘的不同场景需求。
数据模型层	智慧蓝图安全业务的知识体系	规划安全数据的组织方案与关联关系	将原始数据转化为具有安全语义的信息，让数据“会说话”，支撑精准分析。

这套引擎带来了两大关键能力：

联邦查询： 实现了 “一处查询，多处响应”。在面对分散在不同源头的数据时，无需再进行繁琐的数据搬运与整合，即可实现跨数据源的快速关联分析，极大提升了调查效率。
统一图分析：基于同一套存储结构，无缝集成了图分析功能。这意味着安全分析师可以轻松调用图分析算法，飞快挖掘深藏的黑产团伙、隐蔽的攻击链路等复杂关系，让威胁“无处遁形”️。

通过这样的技术架构与创新，安全大素材平台真正将安全工程师从重复、低效的告警“苦海”中解放出来，赋能他们专注于更高价值的威胁狩猎、策略优化和安全创新工作。

16.2.1.1 流式与批计算平台：安全分析的“双核引擎”

在安全大数据平台的计算层，批计算与流式计算如同两位特性各异的超级英雄，协同作战，共同应对不同场景下的安全挑战。它们的协同工作模式如下图所示：

为了更清晰地展示它们的区别与分工，见下表：

维度	批计算（Batch Processing）	⚡ 流计算（Stream Processing）
角色比喻	深思熟虑的“学者”	反应迅速的“哨兵”
计算模式	对有界的、累积的海量历史数据进行集中处理	对无界的、连续的实时数据流进行即时处理
数据特征	数据先存储，后计算，处理的是“过去时”的数据	数据实时计算，无需全量存储，处理的是“现在时”的数据流
核心价值	深度洞察与模型训练 • 大规模数据分析与回溯 • 安全想法与模型的快速验证 • 跨部门数据共享与打通	瞬时感知与响应 • 异常实时告警 • 持续威胁感知 • 秒级风险响应
技术依托	公司级大数据底座（如Hadoop/Spark）	Blink资源集群（即Flink，流处理引擎）
典型场景	安全态势分析、攻击事件回溯、用户行为建模	实时入侵检测、异常登录告警、DDoS攻击瞬时缓解

16.2.1.2 湖仓一体计算引擎

在安全分析中，威胁的踪迹往往隐藏在分散、异构的多源数据中。传统方式需要耗费大量精力进行复杂且易出错的数据同步（ETL），如同一个要求精通多国语言的翻译，效率低下。为了解决这一核心痛点，自主研发了湖仓一体计算引擎，它就像一位内容“联邦”的“指挥家”，无需移动数据，即可对分散各处的数据源进行统一的关联查询与分析，极大地加速了安全研判效率。

1.核心价值：为何需要这位“指挥家”？

维度	传统数据孤岛模式	湖仓一体引擎模式
数据管理	需要维护复杂、易错的数据同步任务	✅ 数据原地不动，逻辑统一访问
查询分析	跨源关联困难，效率低下	✅ 联邦查询，快速关联
上手难度	需学习多种数据源技术，门槛高	✅ 统一SQL接口，学习成本低
业务响应	响应缓慢，错过最佳处置时机	✅ 迅速发现潜在风险

2.湖仓一体计算引擎：引擎如何协同工作？

该计算引擎的分布式存储依托OceanBase，各组件各司其职又协同高效，其工作流程如下图所示，完美诠释了“指挥家”的角色：

各层子系统详解：

HTTP Gateway（网关层）
- 角色：系统的“外交官”。
- 功能：提供RESTful API 和 JDBC/ODBC等多种标准接入方式，让用户和应用能够像访问单一数据库一样轻松接入这个复杂的联邦架构。
Session Manager（会话管理层）
- 角色：负责维持对话的“记忆官”。
- 功能：管理用户查询会话的上下文，确保长链路任务的稳定执行。
Meta Service（元数据服务）
- 角色：负责统一数据格式的“总编”。
- 功能：将各种异构数据（如JSON、日志、数据库表）统一抽象成标准的二维表格式，为上层计算提供一致的视图。
Planner & Generator（优化器）
- 角色：负责制定最优路线的“大脑”。
- 功能：接收标准SQL查询，并将其转换为最高效、可执行的分布式物理计划。
Executor Runtime（执行层）
- 角色：负责具体执行的“肌肉”。
- 功能：供应分布式计算原语，管理和施行优化器生成的物理执行计划。
Connector（连接器层）
- 角色：负责对接不同数据源的“万能适配器”。
- 功能：这是引擎的核心魔力所在！它把异构数据转换为统一二维表的具体物理实现的能力，该层屏蔽了不同异构数据之间的细节差异。在每一次查询时，执行器都需要从不同的连接器中拉取统一格式的数据。按照不同的存储介质（如关系型数据库、分布式存储和消息队列）行有不同的Connector。它屏蔽了不同数据源（如关系型数据库、分布式存储、消息队列）的技术细节，实现了连接复用、Join谓词和投影下推等高级能力，极大提升了查询性能和便利性。

湖仓一体计算引擎的成功实践，为安全运营带来了颠覆性的便利：

效率倍增：数据无需搬运与复制，分钟级即可完毕过去需要数日的跨源关联分析，让威胁无所遁形。
门槛降低：安全分析师只需掌握SQL这一种技能，即可操作全局数据，极大降低了新成员的上手难度，提升了团队整体人效。
架构简化：告别了繁琐易错的数据同步管道，使素材架构更加清晰、稳定和易于维护。

16.2.1.3 多模建模引擎

在强大的湖仓一体计算引擎之上，多模建模引擎扮演着“智能升级套件”的角色。它赋予了大家一种超凡能力：将普通的二维表数据，建模成更高阶、更富表现力的模式（其中最具代表性的就是图模型），从而让我们能够洞察数据之间深藏的、复杂的关系。

1.核心价值：为何需要“升维”思考？

在安全分析中，我们常常需要回答这类问题：“这个IP背后关联了多少个用户？这些用户又通过哪些设备登录过？这些设备是否曾与某个恶意URL产生过交集？” 这类多跳关联查询若是用传统SQL实现，会变得异常复杂和低效。

多模建模引擎，特别是其图模型能力，正是为此而生。它带来的变革如下：

维度	传统二维表模式	多模建模（以图为例）
分析模式	基于行和列的离散查询	基于实体和关系的关联遍历
查询语言	SQL	Gremlin, Cypher等图查询语言
处理流程	需预先导出素材到专用图数据库	✅ 无需数据导出，原地计算
关联深度	多表JOIN，性能随深度增加急剧下降	✅ 高效多跳查询，轻松挖掘深层关系
直观性	关系隐含在键值中，不直观	✅ 关系一目了然，直观展示网络

2.工作原理：图查询的“翻译”与“执行”之旅

多模建模引擎的核心魔力在于，它无需移动材料，就能将高级的图查询“翻译”成底层熟悉的二维表查询原语来执行。

以一次具体的Gremlin图查询为例：

g.V().has('user','id','123').out('login_from').list() 详解其过程：

解析与翻译 (Parser & Planner)
- Gremlin解析器首先理解这条指令的语义：“查找所有属性为‘user’且‘id’是‘123’的顶点（V），并找出从这些顶点凭借‘login_from’边指向的所有顶点，最后列出结果。”
- 优化器会生成一个最优的图物理执行计划。
转换与执行 (Execution)
- 关键的魔法发生在这一步：物理执行计划被分解并转换为一系列底层熟悉的二维表计算原语。
- 这个过程对用户完全透明。引擎可能会先执行一个SELECT查询找到ID为123的用户，再执行一个JOIN查询找到所有的登录记录，最终返回结果。

多模建模引擎的设计，带来了两大根本性优势：

统一素材，多样视角：得益于分层解耦的设计，大家可以在同一份数据上构建不同的数据模型（如二维表、图）。这极大地降低了知识建模的成本，无需为不同模型维护多份数据副本。
⚡ 效率革命，洞察深层：它彻底屏蔽了底层困难查询的细节，使安全分析师能够轻松、高效地进行多跳关系数据提取。无论是追踪攻击链、挖掘黑产团伙，还是分析内部违规关系网，效率都得到了前所未有的提升，让隐藏在复杂关系背后的风险无所遁形。

16.2.2 数据模型

拥有强大大数据平台，如同拥有一片肥沃的土壤，但这并不意味着能自动收获累累硕果。假如缺乏顶层设计与科学规划，最终只会形成一个数据野蛮生长、难以利用的“数据堰塞湖” 。

我们的目标是：构建一个可持续、易管理、能增值的“材料花园”。而这，正依赖于一份行之有效的“数据模型”蓝图。

数据模型的建设绝非事后的修补，而应与安全数字化建设同频共振，贯穿其整个生命周期。它与业务模型的关系，共同构成了数字化运营的“灵魂”与“骨架”：

模型类型	角色比喻	核心职能	最终价值
业务模型	“灵魂” - 业务指挥官	定义做什么，是安全运营业务数字化的指导方针	确保所有数字化努力聚焦于正确的业务目标
数据模型	“骨架” - 架构工程师	定义怎么做，是数据接入、清洗和组织的准则与蓝图	提升数据质量与可关联性，为数字化提供可靠基石

一个清晰、前瞻的数据模型规划，是激活大数据平台潜力、实现安全数字化运营从“拥护”走向“引领”的关键转变。接下来，大家将从资产模型、安全模型、运营模型三个维度，深入探讨数字银行在数据模型建设上的具体实践。

16.2.2.1 资产模型

在安全攻防中，“知己知彼，百战不殆”。资产正是我们需要守护的城池与疆土，而资产模型就是这份至关重要的“战略地图”️。只有清晰地知道自己要保护什么，才能在这场攻防游戏中占据先发优势。

1.痛点：为何应该统一的资产模型？

在统一资产模型构建之前，安全团队仿佛置身于一座信息的迷宫，面临严峻挑战：

指标计算不准确
对外输出口径不统一
风险面梳理冗长，重复工作严重
策略验证时，不知去何处寻找内容

这些困难的根源在于严重的“材料孤岛” 与 “信息茧房”。各团队甚至个人都拥有自己的“小账本”，导致数据无法互通，语言无法统一，协同效率极其低下。

2.解决方案：如何绘制地图？—— 领域建模与八大分域

为克服上述难题，我们借鉴领域建模思想，将庞杂的资产内容科学地划分为八个核心域，构建了统一的资产模型与安全数据集市。

通过对这八大分域的基础数据进行彻底梳理，我们搭建了基础资产、数据资产等核心板块，为基础设施安全领域、应用安全领域、数据安全领域等对于主要数据资产的需求给予了坚实的素材支撑。

3.创新与深化：让地图“活”起来

仅有静态的“骨架”不足以应对动态的威胁，让资产地图具备了“动态”与“智能”两大特性。

①静态关联（基础骨架）：
梳理了应用 ↔ 容器、应用 ↔ IP等基础关系，满足了基本探查需求。

②动态链路追踪（运行时血脉）：
业务是动态的，存在大量运行时资产。通过引入SOFATracer中间件，记录了接口、消息队列、数据库访问等调用日志，从而能够重建真实的线上调用链路。这使得诸如资金防盗链路探查等高级分析成为可能，让隐藏的攻击路径无处遁形。

③智能标签体系（统一视图）：

方法：收集各方需求，为资产打上丰富的标签 ️。
成果：基于标签体系，生成定义明确的标准资产资料视图。
收益：
- 解除口径统一困难
- 杜绝同类型数据重复建设
- 初步瓦解“数据孤岛”

16.2.2.2 安全模型

拥有了描绘“家底”的资产模型让这些数据能够直接就是（战略地图）后，下一步识别和衡量风险。安全模型就扮演着这个关键角色，它是将资产材料与安全业务关联起来的“黏合层”，如同一位精通双语的“翻译官”，将原始数据“翻译”成安全业务能理解的风险语言。

核心构成：三大域模型

安全模型用材料化的语言描述安全域内的要素与关系，通常构建在三个核心维度上：

模型域	角色与使命	核心衡量维度	解决的核心问题
风险域模型	“资产评估师” 关注自身弱点与潜在损失	资产的重要性、保密性、完整性、可用性	"我们的哪些资产最脆弱，一旦出问题损失最大？"
威胁域模型	“敌情侦察兵” 关注外部攻击与实际发生的事件	威胁事件的发生频次、严重等级、攻击路径	"我们正面临多少实际攻击？主导来自哪里？"
防护域模型	“防线审计官” 关注自身防御能力的建设情况	防护产品覆盖率、策略有效性、感知灵敏度	"我们的防御体系是否完备？策略是否生效？"

通过这三层模型的建立，能够将一个模糊的“不安全”感觉，转变为一系列清晰、可量化的内容指标，从而精准地指导安全建设的投入方向与优先级。

16.2.2.3 运营模型

运营模型位于整个数据模型体系的顶层，是最贴近安全工程师日常业务的一层。它将安全模型输出的量化指标，按照实际工作流程进行封装和组织，形成一个完整的作战指挥体系。

四大核心模块

根据安全运营的主要工作，运营模型被清晰地划分为四大模块，其协同工作关系如下图所示：

风险防护模块：聚焦于实时的威胁拦截与攻击缓解，确保日常安全防线稳固。
风险治理模块：聚焦于中期的漏洞修复与脆弱性收敛，从源头降低风险。
威胁对抗模块：聚焦于主动的威胁狩猎与情报分析，对抗高级持续性威胁。
✅ 有效性检验模块：聚焦于验证安全措施与策略是否按预期生效，完成运营闭环。

16.2.3 内容案例

基于安全大数据平台，构建了以下几个基础服务，以支撑具体的数字化安全场景：

1. 安全资产查询 ️

功能：提供飞快的资产检索与统一视图。
价值：安全工程师可利用资产信息或标签快速定位目标资产，并能管理和复用标准资产视图，提升资产查询与管理效率。

2. 快速溯源

功能：利用湖仓一体引擎达成跨数据源的实时关联查询。
价值：支持对告警事件进行快速关联分析（如日志流与资产信息Join），加速溯源过程，实现快速响应，并降低查询工艺门槛。

3. 威胁路径 ️

功能：利用攻防实体、场景、方式、技术等要素对威胁路径进行数字化建模。
价值：对攻击链路上的各要素进行系统化管理，辅助安全工程师清晰了解风险全景，优化防御布局。

4. 安全知识图谱与画像

功能：基于多模建模引擎将底层数据构建为图模型，生成应用、接口、数据分布等画像。
价值：提供直观的知识图谱查询能力，支撑安全智能平台的辅助决策，提升运营智能化水平。

参考资料：《数字银行安全体系构建》

点「赞」➛收「藏」➛关「注」➛评「论」

您的支持，是我持续创作的最大动力！

posted on 2025-12-17 20:01 ljbguanli 阅读(2) 评论(0) 收藏举报