批量越权与多租户隔离失效风险评估

可视化演示

多租户风险认知：共享大楼里的暗墙

云上智能公寓里，每家公司都是一位“房客”（技术黑话叫租户），大家共享电梯、走廊和机房——也就是 GPU、共享存储与模型服务平台。大管家在宣传册上保证“房间互不打扰”，可事实是，只要一堵暗墙出现裂缝，隔壁公司的对话数据、训练语料甚至权重文件就可能全被看到。

这些裂缝来自何处？最常见的是租户隔离失效：平台把多个公司的数据放在同一套存储与推理管道里，却只靠“查询时带上 tenant_id”来区分你我。一旦 API 层忘记校验这个字段，房客 A 就能点开房客 B 的包裹。跨租户数据泄露的后果不只是隐私问题，训练好的模型权重被偷走，等于整家公司被“连锅端”。

安全领域习惯用两个因子衡量风险：攻击发生的可能性，以及事件造成的影响。于是评估公式很简单：

回到公寓视角：管委会只有先盘清“哪堵墙可能不牢、墙后是什么资产”，才能决定每条防线值多少预算。风险评估永远是安全建设的第一块砖。

批量越权原理：挨个试锁的房卡

一个送外卖的小偷混进公寓，捡到一张普通房卡，便开始在走廊里挨家挨户刷卡。他不在乎哪扇门会开，反正每扇都试一遍，把所有能打开的房间洗劫一遍——这就是批量越权的形象画面。

技术上，攻击者拿到一个合法令牌后，按规律遍历 API 端点中的资源 ID：GET /api/v1/model?id=1001、id=1002……这种“直接引用对象”却缺乏授权校验的漏洞，英文叫 IDOR（Insecure Direct Object Reference，不安全的直接对象引用）。同级别的房客互相偷看对方房间叫水平越权；普通房客去刷管理员办公室的门叫垂直越权。两者都源于同一个毛病：只验了“你是谁”，没验“你能不能碰”。

为了量化批量枚举的杀伤力，可以统计所有请求中“认证通过但授权缺失”的资源数量：

小偷试完一栋楼只需几分钟，攻击脚本跑完一万个 ID 也只需几秒。因此防住“第一扇门被刷开”只是及格线，还要让每一扇门都默认上锁。

身份认证防线：前台验明正身

公寓大堂里坐着一位前台，所有访客进门都要出示证件——这是身份认证，回答的问题是“你是谁”。但请注意，前台只负责验明正身，她并不决定你能走进哪间房。

在 AI 平台里，最常见的“门禁卡”是 JWT（JSON Web Token，一种轻量令牌）。它由三段构成：头部声明用什么算法签名，载荷里装着用户 ID、所属租户、角色和过期时间，最后用平台密钥生成签名。房客想私改卡上的“允许进入 5 层”，签名立刻对不上，门禁直接亮红灯。

除了签名防篡改，还要给门禁卡加“有效期”：会话到期自动失效，管理员可远程吊销；高权限操作再加一步多因素认证（MFA）。前台验得越严，小偷手里的假卡越难流通。

资源隔离设计：真正的隔断墙

光有前台还不够，房间之间必须砌起真正的隔断墙，而不是只在图纸上画一条线。多租户资源隔离要覆盖四个维度：存储、网络、算力、密钥。

存储上，每个租户使用独立的对象存储桶和数据库 schema，桶与桶之间默认拒绝跨账号读取；网络上，通过 Kubernetes NetworkPolicy 或云安全组规定“只有台就能访问模型服务 Pod”；算力上，GPU 配额按租户隔离，防止恶意邻居抢占资源顺带旁路窃取显存数据；密钥更是要独立管理——每个租户一套 KMS 密钥，平台管理员也不得随意解密租户模型。

四个维度的目标用一句话概括：任意两个租户的资源集合不能有交集。这是“墙”的数学定义：

当业务不得不共享底层存储或 GPU 池时，就相当于公寓里共用走廊——可以共享通道，但每扇房门必须各自上锁，并用强制访问控制（MAC）约束系统账号，而不是依赖房客自觉。

API权限校验：电梯里二次刷卡

走进公寓只是第一步，电梯里的楼层按钮同样要刷卡才能点亮。授权回答的是“你能做什么”，与认证完全两回事。多租户平台最常见的漏洞，恰恰是认证做了、授权没做。

推荐的授权模型是 RBAC（基于角色的访问控制）：给角色绑定操作权限，给用户绑定角色。但光有 RBAC 还不够，平台必须把租户上下文（tenant_id、user_id、role）随请求一路传递到服务端，再由服务端做二次校验，绝不能信任前端传过来的资源归属字段。判断一个请求是否放行的决策函数是：

就像电梯刷到楼层后，走廊里的房门还要再刷一次锁：网关做第一道判断，服务端业务层做第二道判断。即使攻击者伪造了租户上下文，资源归属校验仍是最后一道保险。

纵深防御方案：从大门到保险柜的多道锁

小偷要是已经混进大楼呢？这正是纵深防御要回答的问题：不要指望任何单一防线永远不出错。公寓从小区门禁、单元门禁、电梯刷卡到房间智能锁，层层设卡，破一道还有四道。

AI 平台的四道标准防线是：网关注入与拦截——统一校验令牌、注入租户上下文、过滤可疑批量请求；服务端校验兜底——业务代码里再次核对资源归属；敏感数据脱敏——即使数据被带出，也只剩打码的壳；全链路审计日志——记录谁在什么时间访问了哪个资源，为溯源和红队复盘留下证据。

每道防线都有可能被绕过，但整体安全性遵循概率相乘的规律：

这就是为什么安全工程不追求“绝对打不破”，而是追求“打破它的成本远超收益”。小偷看到五道锁，大概率会转头去偷隔壁那栋没上锁的大楼。

自动化检测：不停巡逻的电子保安

公寓不能只靠前台，还得有电子保安巡逻——自动化越权检测。它的工作原理其实和黑客一样：用一个低权限令牌，批量向资源 ID 发起请求，然后看返回结果。返回 200 且带着别人的数据，那就是越权；返回 403 说明授权校验拦截住了；返回 404 也不一定安全，可能是数据被脱敏或挪了位置，需要进一步比对。

成熟的扫描器还会做基线比对：用管理员令牌扫一遍得到“全部资源清单”，再用低权限令牌扫一遍，两者差集就是疑似越权点。同时结合实时异常监测——短时间内某个租户令牌访问了大量不同租户 ID，直接触发告警，这就是“电子保安看见有人挨个试锁”。

检测效果如何量化？用覆盖率来衡量：

红蓝对抗则让电子保安“练手”：红队模仿批量越权攻击，蓝队调校扫描规则，每次对抗后把新手法沉淀成检测用例。巡逻得越勤，公寓的免疫力越强。

案例验证复盘：一次真实攻防演习

纸上谈兵终究要回到实战。某 AI 平台上线了“模型市场”功能：租户把自己微调好的模型上传，供其他租户按需调用。安全团队在发布前做了一次攻防演习，完整走了一遍“发现→修复→复测”闭环。

攻击场景复现：红队用租户 A 的普通令牌，对模型市场的下载接口做批量枚举——download?model_id=1,2,3…。结果发现接口只校验了“是否登录”，没有校验“模型归属租户”，租户 A 可以直接下载租户 B 上传的商业模型权重。第一轮扫描，越权成功率 100%，风险等级判定为严重。

纵深防御落地：平台随即做了三件事：一是网关统一注入并校验租户上下文，拒绝一切缺失租户声明的请求；二是服务端下载接口增加资源归属校验，owner 与调用者不一致直接 403；三是敏感模型下载链路开启审计日志和流量脱敏。整改后红队再次复现同样攻击，全部请求被拦截。修复效果用风险降幅量化：

演习的经验最终沉淀为两条清单：一条写进 API 开发规范（所有资源操作必须做租户归属校验），另一条做成自动化扫描插件，接入平台的 CI 发布流程。从此每次发布新功能，电子保安都会先“巡逻”一遍。

AI 应用场景

Python 演示

#!/usr/bin/env python3# 模拟多租户AI平台的批量越权检测与修复验证import jsonimport hmacimport hashlib SECRET = b"platform-secret-key"# 资源归属表: 资源ID -> 所属租户OWNERSHIP = {    "model_1001": "tenant_a",    "model_1002": "tenant_a",    "model_2001": "tenant_b",    "model_2002": "tenant_b",    "model_3001": "tenant_c",}  def build_token(tenant_name):    # 生成带租户声明的签名令牌(模拟攻击者持有的低权限身份)    payload = json.dumps({"tenant": tenant_name, "role": "viewer"})    sig = hmac.new(SECRET, payload.encode(), hashlib.sha256).hexdigest()    return payload + "." + sig  def api_without_authz(res_id, token):    # 模拟有认证但无租户隔离校验的脆弱API    claims = json.loads(token.split(".", 1)[0])    if claims["tenant"] not in OWNERSHIP.values():        return 401, None    if res_id not in OWNERSHIP:        return 404, None    return 200, {"resource": res_id, "owner": OWNERSHIP[res_id]}  def api_with_authz(res_id, token):    # 模拟修复后: 校验资源归属与调用者租户一致    claims = json.loads(token.split(".", 1)[0])    if claims["tenant"] not in OWNERSHIP.values():        return 401, None    if res_id not in OWNERSHIP:        return 404, None    if claims["tenant"] != OWNERSHIP[res_id]:        return 403, None    return 200, {"resource": res_id, "owner": OWNERSHIP[res_id]}  def scan_vulns(targets, token, api_func):    # 批量越权扫描: 枚举资源ID, 找出可越权读取的租户资源    leaked = []    for res_id in targets:        status, body = api_func(res_id, token)        if status == 200:            leaked.append(body["resource"])    return leaked  def main():    token = build_token("tenant_a")   # 攻击者只有租户A身份    targets = ["model_1001", "model_1002",               "model_2001", "model_2002", "model_3001"]    before = scan_vulns(targets, token, api_without_authz)    after = scan_vulns(targets, token, api_with_authz)    print("vulns before fix:", before)    print("vulns after fix:", after)    print("conclusion:", "batch IDOR found, add tenant ownership check"          if before else "isolation OK")  if __name__ == "__main__":    main()

1. payload = json.dumps({"tenant": tenant_name, "role": "viewer"})把租户身份和角色写进令牌声明，相当于在门禁卡上盖章。
2. sig = hmac.new(SECRET, payload.encode(), hashlib.sha256).hexdigest()用平台密钥给声明签名，防止房客私自改卡上信息。
3. claims = json.loads(token.split(".", 1)[0])解开令牌取出租户身份，模拟服务端“验卡”的第一步。
4. return 200, {"resource": res_id, "owner": OWNERSHIP[res_id]}脆弱 API 只认卡不认房，见卡就放行，正是越权的根源。
5. if claims["tenant"] != OWNERSHIP[res_id]:修复核心：房客要访问的资源必须属于自己家，否则一律返回 403。
6. before = scan_vulns(targets, token, api_without_authz)修复前后各跑一遍批量枚举，用数据对比证明防线有效。

常见误区

面试题