基础知识：AI平台的基本架构、常见安全威胁与权限管理核心概念
2.1 AI平台的基本架构分层
要理解AI平台的安全问题，首先需要建立对平台整体架构的清晰认知。现代AI平台通常采用分层架构，每一层承担不同职责，也暴露不同的攻击面。我们可以将AI平台划分为以下五个核心层次：
| 层次 | 核心组件 | 典型安全关注点 |
|---|---|---|
| 基础设施层 | GPU/CPU集群、存储、网络 | 硬件漏洞、网络隔离、侧信道攻击 |
| 数据层 | 数据湖、特征库、标注系统 | 数据泄露、投毒、越权访问 |
| 模型开发层 | 训练框架、实验管理、代码仓库 | 代码注入、模型窃取、依赖供应链 |
| 模型服务层 | 模型仓库、推理服务、API网关 | 模型逃逸、提示注入、拒绝服务 |
| 应用与用户层 | Web应用、客户端、业务系统 | 身份冒用、越权操作、滥用配额 |
这五个层次并非孤立存在，而是通过数据流与控制流紧密耦合。数据从底层存储流向训练任务，训练产物注册到模型仓库，再部署为推理服务，最终被上层应用调用。安全防护必须贯穿这条完整链路，任何一层的薄弱点都可能成为攻击入口。
2.2 AI平台常见安全威胁全景
AI平台的安全威胁与传统IT系统既有重叠，也有其独特的AI属性风险。根据攻击目标与阶段，我们可以将威胁归纳为以下四大类：
2.2.1 针对数据完整性与隐私的威胁
- 数据投毒（Data Poisoning）：攻击者向训练数据中注入恶意样本，使模型学习到错误模式。例如在图像分类数据中混入带有特定触发器的图片，导致模型在真实场景中被后门触发。
- 隐私窃取：通过成员推断攻击（判断某样本是否在训练集中）或模型逆向攻击，从模型输出中还原训练数据中的敏感信息。
- 数据越权访问：利用平台存储权限配置错误，跨项目读取他人数据集或特征库。
2.2.2 针对模型资产的威胁
- 模型窃取（Model Stealing）：通过大量API查询，利用输入输出对训练一个功能近似的替代模型，从而绕过付费或复制核心能力。
- 模型逆向：从模型参数或梯度信息中推断训练数据属性，在联邦学习场景中尤为突出。
- 模型篡改：攻击者获得模型仓库写权限后，替换或修改模型文件，植入恶意行为。
2.2.3 针对推理服务的威胁
- 提示注入（Prompt Injection）：在LLM应用中，用户通过精心构造的输入覆盖系统指令，诱导模型执行非预期操作，如泄露系统提示词或调用危险工具。
- 拒绝服务（DoS）：通过大量高复杂度请求耗尽GPU算力，导致正常用户无法获得推理服务。
- 输出内容违规：模型生成有害内容，造成合规风险与品牌损害。
2.2.4 针对平台基础设施的威胁
- 供应链攻击：训练依赖的开源库被植入恶意代码，在训练过程中窃取数据或模型。
- 容器与编排层攻击：利用Kubernetes RBAC配置错误或容器镜像漏洞，横向移动至其他租户的计算资源。
常见误区：许多团队认为AI平台安全等同于网络安全，只关注防火墙和WAF，却忽视了数据投毒和模型窃取这类AI特有的攻击面。实际上，后者往往造成更隐蔽且更严重的经济损失——模型是AI企业最核心的知识产权。
2.3 权限管理的基本概念与模型
权限管理是AI平台安全的核心控制机制。在AI平台中，权限管理需要覆盖人、服务账号、数据集、模型、训练任务、推理API等多类主体与资源，远比传统Web应用复杂。
2.3.1 核心术语
- 主体（Subject）：发起访问请求的实体，可以是用户、服务账号或应用。
- 资源（Resource）：被访问的对象，如数据集、模型文件、训练任务、API端点。
- 动作（Action）：对资源执行的操作，如读取、写入、删除、部署、调用。
- 策略（Policy）：定义“谁在什么条件下可以对什么资源执行什么动作”的规则集合。
- 授权（Authorization）：系统根据策略判断是否允许某次特定访问请求的过程。
2.3.2 主流权限模型对比
| 模型 | 核心思想 | AI平台适用场景 | 局限性 |
|---|---|---|---|
| RBAC（基于角色） | 用户→角色→权限 | 平台管理后台、团队协作 | 细粒度不足，角色爆炸 |
| ABAC（基于属性） | 根据主体/资源/环境属性动态判断 | 跨项目数据访问、临时授权 | 策略编写复杂，性能开销 |
| ReBAC（基于关系） | 根据资源间关系推导权限 | 数据集→特征→模型的血缘访问控制 | 实现复杂度高 |
2.3.3 最小权限原则与职责分离
在AI平台中落实权限管理，必须遵循两条黄金原则：
- 最小权限原则（Least Privilege）：每个主体只应拥有完成其任务所必需的最小权限集合。例如，数据标注员只需要对“标注数据集”有读写权限，不应拥有模型部署权限。
- 职责分离（Separation of Duties）：关键操作需要多人协作完成，避免单人拥有过高权限。例如，模型发布应要求“开发人员提交→安全审核→管理员审批→运维部署”的流程。
实践建议：在AI平台中，建议采用RBAC + ABAC混合模型。用RBAC管理基础角色（如数据工程师、算法工程师、运维、审计员），用ABAC补充动态条件（如“仅允许在工作时间访问生产环境模型”“仅允许访问自己项目组的数据集”）。同时，所有权限决策必须记录审计日志，便于事后追溯。
2.4 典型风险场景复盘：一个权限失控的教训
某AI公司曾发生一起严重的数据泄露事件，复盘过程极具教育意义。
事件经过：该公司使用一套开源AI平台，平台默认创建了一个admin服务账号，该账号拥有全部API权限。开发团队为了方便调试，将admin的API密钥硬编码在Jupyter Notebook中，并提交到了公共代码仓库。攻击者扫描到该密钥后，直接调用平台API，遍历下载了所有训练数据集（包括用户隐私数据），并进一步获取了模型仓库的写权限，在模型中植入后门。
根因分析：
- 未禁用或轮换默认
admin账号，权限过大。 - 服务账号与个人账号混用，无法追溯具体责任人。
- 缺少网络层限制，API可从公网直接访问。
- 没有数据分级分类，所有数据集对admin完全开放。
- 缺少异常行为检测，短时间内大量下载未被告警。
改进措施：
- 禁用默认管理员，创建细粒度的自定义角色，遵循最小权限原则。
- 强制使用短期凭证（如STS Token），禁止硬编码密钥。
- API网关开启IP白名单与调用频率限制。
- 对数据集打标分级，敏感数据访问需二次审批。
- 部署审计与异常检测系统，对批量下载、非工作时间访问等行为实时告警。
复盘要点：权限管理不是一次性配置，而是持续治理的过程。建议每季度进行一次权限审计，清理僵尸账号、回收冗余权限，并验证权限策略是否与实际业务匹配。AI平台中模型与数据资产的价值密度极高，权限失控的代价远超传统IT系统。