2. AI服务接口资产测绘与分类分级

在AI服务接口安全工程中，资产测绘是后续所有防护动作的起点。如果连“有哪些接口、它们暴露了什么、数据从哪里流到哪里”都说不清楚，访问控制、审计、脱敏和限流就无从谈起。AI服务接口与传统REST接口最大的区别在于：它往往同时暴露模型推理端点、管理端点、向量检索端点、文件上传端点和流式响应通道，且同一模型可能以多个版本、多个别名、多个部署形态存在。因此，资产测绘不能只做一次URL扫描，而应围绕“接口发现—模型端点识别—数据流映射—资产标签体系—分级保护策略”形成一条可复用的工作链。

一、接口发现：从被动扫描到主动登记

接口发现的目标是形成一份尽可能完整的接口清单。实际工作中，建议同时使用三种手段：流量镜像分析、代码与配置扫描、网关与注册中心导出。流量镜像能发现实际被调用的路径，但会遗漏低频或未上线接口；代码扫描能发现定义但可能未部署的接口；网关导出则能拿到已注册但可能被绕过的路由。三者交叉比对，才能得到较可靠的清单。

以某AI推理平台为例，假设网关导出的路由如下（示例数据，非实测）：

GET  /v1/models
POST /v1/chat/completions
POST /v1/embeddings
POST /v1/files
GET  /v1/files/{file_id}
POST /v1/fine_tuning/jobs
GET  /admin/model_versions
POST /internal/vector/upsert

仅凭这份清单，还无法判断哪些是模型端点、哪些是管理端点、哪些涉及敏感数据。下一步需要做端点识别。

二、模型端点识别：区分推理、管理与数据面

模型端点识别不是简单看路径里有没有“model”，而是根据请求语义、响应结构、调用方身份和计费维度综合判断。通常可将AI服务接口分为四类：

• 推理端点：接收prompt、图像、音频等输入，返回生成结果或向量，如 /v1/chat/completions、/v1/embeddings。
• 模型管理端点：涉及模型版本、权重、微调任务、部署配置，如 /admin/model_versions、/v1/fine_tuning/jobs。
• 数据面端点：处理文件、向量、知识库，如 /v1/files、/internal/vector/upsert。
• 元数据端点：返回模型列表、配额、健康状态，如 /v1/models。

识别时可用一个简单判据：若请求体中包含自然语言、图像或音频，且响应由模型生成，则归为推理端点；若请求体包含模型ID、版本号、训练参数，则归为管理端点；若请求体包含文件或向量，则归为数据面端点。管理端点通常要求更高权限，数据面端点则直接关联敏感数据，二者都应优先纳入重点保护范围。

三、数据流映射：把接口串成数据链路

单个接口的风险有限，真正危险的是数据在多个接口之间流动。数据流映射要回答三个问题：数据从哪来、经过哪些组件、最终落到哪里。对AI服务而言，典型链路包括：用户上传文件 → 文件服务 → 向量化端点 → 向量数据库 → 推理端点 → 日志与审计存储。

下面这张图展示了一个AI服务接口资产测绘与数据流映射的核心关系。图中左侧为接口发现来源，中间为四类端点，右侧为数据流经的存储与审计组件，底部为资产标签与分级策略的映射关系。

四、资产标签体系：让每个接口可检索、可分组

标签体系的价值在于把零散接口变成可管理的资产集合。建议至少包含四类标签：接口类型（推理/管理/数据面/元数据）、数据敏感度（公开/内部/机密/绝密）、暴露面（公网/内网/本地）、责任团队。标签不是装饰，而是后续策略匹配的依据。例如，一个“推理端点 + 机密数据 + 公网暴露”的接口，其保护等级应明显高于“元数据端点 + 公开数据 + 内网”。

标签的赋值应尽量自动化：从网关路由中提取路径和认证方式，从代码注解中提取数据分类，从流量中提取调用方身份。人工只负责复核和例外处理。这样，当新增一个 /v1/chat/completions 的模型别名时，系统能自动继承“推理端点、公网、需认证”等标签，减少遗漏。

五、分级保护策略：从标签到动作

分级保护策略的核心是“不同级别、不同动作”。以下是一份可直接参考的分级策略示例（示例参数，需根据实际组织调整）：

策略落地时，建议把分级结果写入网关策略或服务网格配置，而不是停留在文档里。例如，对L3及以上接口强制开启请求体审计，对L4接口强制走独立网络通道。每次接口变更后，应重新评估其标签和级别，避免“新增接口默认低风险”的惯性思维。

总结来说，AI服务接口资产测绘与分类分级的关键在于：发现要全、识别要准、映射要清、标签要活、分级要落地。只有把接口、模型端点、数据流和标签体系串成一条可维护的链路，后续的访问控制、审计、脱敏和限流才有可靠的依据。