⸢ 柒-Ⅲ⸥⤳ 可信纵深防御建设方案：数据使用可信端安全可信
👍点「赞」📌收「藏」👀关「注」💬评「论」
在金融科技深度融合的背景下，信息安全已从单纯的技术攻防扩展至架构、合规、流程与创新的系统工程。作为一名从业十多年的老兵，将系统阐述数字银行安全体系的建设路径与方法论，旨在提出一套可落地、系统化、前瞻性的新一代安全架构。
| 序号 | 主题 | 内容简述 |
|---|---|---|
| 1 | 安全架构概述 | 全局安全架构设计，描述基础框架。 |
| 2 | 默认安全 | 标准化安全策略，针对已知风险的标准化防控（如基线配置、补丁管理）。 |
| 👉3 | 可信纵深防御 | 多层防御体系，应对未知威胁与高级攻击（如APT攻击、零日漏洞）。 |
| 4 | 威胁感知与响应 | 实时监测、分析威胁，快速处置安全事件，优化第二、三部分策略。 |
| 5 | 实战检验 | 通过红蓝对抗演练验证防御体系有效性，提升安全水位。 |
| 6 | 安全数智化 | 运用数据化、自动化、智能化（如AI）提升安全运营（各部分）效率。 |
目录
7 可信纵深防御建设方案
7.3 关键能力建设
7.3.4 数据使用可信
7.3.4.1 简介：从分散风险到集中治理
1.分散式架构的弊端
2. 解决方案：基于授权模型令牌的可信防护方案
7.3.4.2 技术方案
1.令牌生成
2.令牌透传
3.令牌验证
4.权限鉴定
7.3.5 端安全可信
7.3.5.1 移动端安全可信 (以iOS为例)
1.简介
2.技术方案
7.3.5.2 终端安全可信（台式机）
1.简介
2.技术方案
👍点「赞」➛📌收「藏」➛👀关「注」➛💬评「论」
7 可信纵深防御建设方案
7.3 关键能力建设
7.3.4 数据使用可信
7.3.4.1 简介：从分散风险到集中治理
1.分散式架构的弊端
在当前典型应用架构下，数据权限鉴权逻辑由各边界应用分散实现，如图所示，这引入了显著的安全与管理风险。
> 此种分散式架构存在三大核心弊端：
| 序号 | 核心弊端 | 导致后果 |
|---|---|---|
| ① | 🛡️ 安全意识不足：开发人员可能忽略鉴权。 | 直接产生越权漏洞。 |
| ② | 🐛 安全能力薄弱：即使实现鉴权，逻辑也可能存在缺陷。 | 产生隐蔽的安全漏洞。 |
| ③ | 🔗 代码耦合度高：鉴权逻辑与业务代码耦合，难以审计。 | 安全团队难以发现与治理。 |
结论：以上原因导致越权漏洞很难被彻底发现与根治。
2. 解决方案：基于授权模型令牌的可信防护方案
为解决上述风险，提出核心思路：将鉴权能力收拢，在数据应用处实现统一、标准的鉴权逻辑。
> 方案核心：
-
位置转变：鉴权主体从 “边界应用” 转变为 “数据应用”。
-
标准化：由信息安全团队提供标准的鉴权SDK，数据应用强制接入。
-
可信访问：确保所有对数据应用的访问都经过符合安全规范的校验。
> 方案收益：此方案通过架构调整，带来了以下四方面显著收益：
| 序号 | 核心收益 | 详细说明 |
|---|---|---|
| ① | 🛡️ 漏洞根本防御 | 即使边界应用未做鉴权，数据应用层的统一校验也能杜绝越权。 |
| ② | ✅ 鉴权质量提升 | 经过安全评估的标准SDK，大幅降低鉴权逻辑本身的缺陷概率。 |
| ③ | ⚙️ 开发成本降低 | 鉴权与业务解耦，开发人员无需各自实现，降低成本与负担。 |
| ④ | 🔍 安全治理高效 | 鉴权逻辑集中且标准，安全扫描与评估更高效、准确。 |
7.3.4.2 技术方案
整体方案主要包含4部分：令牌生成、令牌透传、令牌验证、权限鉴定。具体是：
本方案的核心是通过一个安全的授权模型令牌，在数据流动过程中实现可靠的权限验证。其协作流程如下图所示：
1.令牌生成
目标：在边界应用上，将本次访问的授权信息封装成一个安全、可信的令牌。
-
🔑 授权模型：基于“主体-资源-操作-授权列表”模型。
-
登录主体 (Subject)：请求发起方（如：用户账号、应用任务）。
-
资源客体 (Resource)：被访问的业务数据（如：一条订单、客户信息）。
-
授权主体列表 (AuthorizationSubjectList)：该资源允许被哪些主体访问的名单。
-
资源属性（Attribute）：资源的属性(表现为数据库字段)。
-
-
💡 实例说明（微信朋友圈）：
模型要素 对应实例 登录主体 张三 资源客体 朋友圈信息 操作请求 查看朋友圈（HTTP请求，参数为“李四”） 授权主体列表 李四、王五（即，张三被授权访问李四和王五的朋友圈） -
🏷️ 令牌数据结构：包含核心信息与签名，以确保其完整性，明文结构示例如下：
{"loginSubject": "张三","authorizationSubjectList": ["李四", "王五"],"sceneType": "查好友","sceneCode": "查询微信朋友圈","timestamp": "1660116950327","signature": "xxxxxxxx" // 对以上字段的签名，防篡改 }字段名 字段含义 备注和数据样例 loginSubject 登录主体是操作资源请求的发起方，可以是：
一个自然人或企业账号，一个内部员工域账号、或一个定时应用任务等
1.表示自然人
{"uid":"zhangsan"}
authorizationSubjectList 当前登录用户操作资源的授权主体列表是一个KV结构，K表示资源字段名，V表示授权当前登录用户操作资源的主体列表 {
"resourceFieldName":"orderld",
"authList":
[ { "uid": "lisi","uid":"wangwu",}]
}
sceneType 业务操作权限模型场景类型，枚举类型 场景码/场景含义
1、查个人2、查好友
sceneCode 边界应用业务接口场景码 queryWeChatMoments timestamp 令牌生成时间戳 1660116950327 signature 对以上字段内容进行签名 xxxxxxxx
-
2.令牌透传
目标：将边界应用生成的令牌，高效、无侵入地传递到数据应用。
-
🚫 传统方式问题：通过接口参数传递，需要改造所有链路应用，工作量大。
-
✅ 本方案方案：利用安全平行切面技术，在网络协议层（如HTTP Header）实现自动透传，业务代码！零改造。
-
⚙️ 透传机制（以Java为例）：通过安全平行切面（AOP） 技术，以 “请求头” 为媒介，利用
ThreadLocal为容器，实现令牌在调用链路上的无侵入自动透传。其核心是发送端与接收端的对称操作逻辑，具体流程如下：
🔧 核心组件与角色
| 角色 | 组件示例 | 核心职责 |
|---|---|---|
| 请求发送端 | HttpClient, RpcClient, 消息发布方 | 从 ThreadLocal 取令牌，放入请求头 |
| 请求接收端 | HttpService, RpcService, 消息订阅方 | 从请求头 取令牌，放入 ThreadLocal |
💡令牌透传的原理：参考蚂蚁金服开源的分布式链路跟踪解决方案SOFATracer，详细内容：https://www.sofastack.tech/projects/sofa-tracer/overview/。
3.令牌验证
目标：确保令牌的真实性与完整性。是安全防护的第一道关口。
-
🛡️ 安全特性：令牌必须具备：
-
防伪造 🚫
-
防篡改 🚫
-
防重放 🚫 (在有效期内)
-
-
🔒 实现方式：对令牌内容进行加密和签名。
-
⚡ 验证策略：链路中的应用在收到令牌后，首先进行验证，验证失败则立即中止请求。
4.权限鉴定
目标：在数据应用处，统一执行鉴权逻辑，实现安全收口。
-
🎯 核心价值：
-
拦截遗漏：高效发现并拦截边界应用遗漏的鉴权。
-
统一收口：降低因开发人员水平不一导致的逻辑缺陷概率。
-
易于治理：鉴权逻辑集中，便于安全团队扫描和评估。
-
-
🔍 鉴定流程：
-
令牌解密：数据应用的鉴权SDK将令牌解密为明文。
-
获取参数：数据应用从接口获取请求参数值及其对应的用户ID（即资源的实际归属者）。
-
核心校验：鉴权SDK判断 “参数值对应的用户ID”是否在令牌的
AuthorizationSubjectList中。 -
执行决策：根据校验结果执行拦截或放行。
-
-
👨💻 接入改造：数据应用需进行少量代码改造，明确指定资源创建者并调用鉴权SDK。安全团队可在代码合并时进行规范符合性扫描。
7.3.5 端安全可信
信任链从服务器端延伸至终端，构建端到端的安全可信体系。终端层：是员工与应用的直接边界，也是数据泄露与攻击的重灾区。本节以移动端(iOS) 和办公终端为例，详细说明终端层的安全可信防护能力建设。
7.3.5.1 移动端安全可信 (以iOS为例)
🎯 核心目标：通过非侵入式的安全切面技术，实现对线上App服务快速管控、防护和止血。
1.简介
通过集成iOS安全切面，确保策略控制点不侵入App构建流程，而是仅集成即可。安全团队可通过下发配置动态注册/注销切点，实现对App服务的灵活管控。
移动端安全可信的iOS端架构如下：
2.技术方案
| 关键技术 | 说明 | 优势 |
|---|---|---|
| 🔧 端动态切面技术 | 利用Objective-C运行时机制，动态修改类结构，替换原方法的实现为一个自定义的“壳”函数。 | 无侵入性，无需修改原业务代码。 |
| 🛠️ 动态构造管控函数 | 处理消息时，能够在这个“壳”函数内部，可获取所有参数、返回值及自定义数据，并通过ffi_call灵活调用其他函数。这个调用可以通过前面说过的函数模板函数指针参数地址实现。 | 实现精细化的控制逻辑与安全校验。 |
| ⚙️ 灵活的安全配置 | 仅需集成Pod，通过下发配置即可动态开启/关闭切面功能。未开启切面时就是纯净版App，通过配置即可部署切点，无需发布新版本。 | 响应迅速，可实现线上热修复与实时防护。 |
7.3.5.2 终端安全可信（台式机）
🎯 核心目标：基于终端管控组件，实现设备、软件、进程和网络的全面可信，有效应对内外部的攻击与违规行为，规避数据泄露风险。
1.简介
办公终端是安全防护的最后一道关口。通过建立终端EDR等管控组件，对终端运行态的各类资源与行为进行管控，确保其是可信且符合预期的。终端安全可信能力整体架构如图：
2.技术方案
终端可信管控基于以下三个核心能力构建，其协同工作流程如下图所示：
> 三大核心可信能力详解：
| 可信维度 | 管控目标 | 关键技术实现 |
|---|---|---|
| 🖥️ 终端设备可信 | 验证请求来源设备的合法性。 | 1. 终端安装安全管控组件，收集设备指纹（唯一标识、账号、IP等）。 2. 统一代理网关校验设备信息与账号的绑定关系。 3. 判定为不可信设备则进行验证或阻断。 |
| ⚙️ 终端进程可信 | 确保终端上运行的进程是安全、可信的。 | 1. 通过注册系统驱动，在系统早期启动阶段进行监控。 2. 校验启动文件的文件名、哈希值、数字签名、路径等信息。 3. 有效防御软件供应链攻击（如Putty注入攻击）。 |
| 🌐 终端网络行为可信 | 防止攻击者利用可信进程发起恶意网络连接。 | 1. 基于可信IP集和域名集建立白名单策略。 2. 通过对TCP流量（五元组）和DNS流量的管控。 3. 利用DNS劫持与驱动层阻断，实现网络行为管控。 |
> 关键实施流程：
-
终端设备可信：依赖统一代理网关与终端管控组件的覆盖率，实现联动验证。
-
终端进程可信：
-
建立初始可信进程集作为白名单基准。
-
为被拦截进程预留申请通道，经安全评估后纳入白名单。
-
依据角色和岗位，下发不同的可信策略集（如对研发人员开放
Powershell,cmd）。
-
-
终端网络行为可信：
-
整理银行内外部资产，形成初始可信IP与域名集。
-
上线网络白名单策略，并为业务需要预留申请通道。
-
参考资料：《数字银行安全体系构建》
👍点「赞」➛📌收「藏」➛👀关「注」➛💬评「论」
🔥您的支持，是我持续创作的最大动力！🔥
