📚 课程目录第2章金融模型服务基础

2. 金融模型服务基础

在讨论安全鉴权与审计之前，必须先建立对金融模型服务运行形态的清晰认知。鉴权发生在请求入口，审计贯穿调用链路，而这两者的设计都取决于服务本身的架构、接口协议与部署方式。本节从模型服务架构、API 接口、微服务与容器化部署、常见金融业务场景四个维度展开，为后续安全机制打下基础。

一、模型服务架构的核心分层

金融模型服务并非单一进程，而是由多层协作构成的系统。典型架构自下而上可分为四层：模型层、推理服务层、接口网关层与业务编排层。模型层承载训练好的评分卡、风控模型、时序预测模型等资产；推理服务层负责加载模型、执行批量或实时推理；接口网关层统一暴露 API 并承担限流、鉴权、路由；业务编排层则把多个模型服务组合成完整的信贷审批、反欺诈或投研流程。

这种分层带来的直接后果是：鉴权点可能出现在网关，也可能出现在服务间调用；审计日志需要跨层关联同一个请求 ID。理解分层，才能理解为什么安全设计不能只做“入口拦截”。

二、API 接口：同步、异步与批量三种形态

金融模型服务的接口形态直接影响鉴权与审计的实现方式。常见有三类：

同步实时接口：以 REST/JSON 为主，单笔请求单笔响应，适用于支付反欺诈、实时授信等毫秒级场景。鉴权通常在 HTTP 头携带令牌，审计需记录请求体摘要与响应码。
异步任务接口：提交任务后返回任务 ID，通过回调或轮询获取结果，适用于批量评分、模型回测。鉴权需覆盖提交与查询两个动作，审计要关联任务全生命周期。
批量文件接口：以文件上传下载方式交互，适用于日终跑批。鉴权依赖签名与证书，审计需记录文件哈希与行数。

下面是一个典型的同步推理接口请求示例，注意其中与安全相关的字段：

POST /v1/model/credit-score HTTP/1.1
Host: model-gateway.finance.internal
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
X-Request-Id: req-20240612-8f3a9c
X-Client-Id: loan-approval-svc
Content-Type: application/json

{
  "applicant_id": "CUST-88213",
  "features": {"income": 18000, "debt_ratio": 0.42, "overdue_cnt": 0},
  "model_version": "credit_v3.2"
}

其中 Authorization 承载身份凭证，X-Request-Id 用于跨服务审计关联，X-Client-Id 标识调用方服务，model_version 则关系到模型变更审计。这些字段在后续章节会反复出现。

三、微服务与容器化部署

金融模型服务普遍采用微服务架构，每个模型或模型组独立部署、独立扩缩容。容器化（Docker + Kubernetes）进一步带来弹性与隔离，但也引入新的安全边界：服务间调用需要 mTLS 或服务网格鉴权，容器镜像需要签名校验，Pod 需要网络策略限制。

在微服务下，鉴权不再是单点问题，而是“入口鉴权 + 服务间鉴权”的双层结构。审计也随之分为网关访问日志与服务间调用链日志。若缺少统一请求 ID，跨服务审计将无法拼接完整链路。

容器化部署中，模型文件常通过挂载卷或对象存储加载。审计需记录模型版本、加载时间与哈希值，防止模型被替换而无人察觉。

四、常见金融业务场景与安全诉求

不同业务场景对鉴权与审计的诉求差异明显。下表归纳了四类典型场景：

业务场景	接口形态	鉴权重点	审计重点
实时反欺诈	同步 REST	低延迟令牌校验、调用方白名单	请求响应全量留痕、异常评分告警
信贷审批评分	同步 + 异步	按业务线细粒度授权	模型版本、特征快照、决策结果
日终批量评分	批量文件	证书签名、文件完整性	文件哈希、行数、处理耗时
投研组合计算	异步任务	任务提交与查询双重鉴权	任务生命周期、参数变更记录

五、误区与复盘

常见误区一：认为“内网调用无需鉴权”。实际上横向移动攻击正是利用内网信任，服务间鉴权不可省略。
常见误区二：只记录访问日志，不记录模型版本与特征。一旦出现决策争议，无法复现当时输入。
常见误区三：鉴权与审计分离设计，导致请求 ID 不统一，事后无法关联。

复盘来看，金融模型服务的安全基础可以归纳为三句话：架构分层决定鉴权位置，接口形态决定审计粒度，部署方式决定信任边界。只有先把这三件事对齐，后续的令牌设计、权限模型与审计存储才有稳固的落脚点。