API 数据访问权限怎么设计：从接口鉴权到数据级权限的四层模型

API 的数据访问权限要回答三个问题：谁在调用这个接口、能调用哪个接口、能拿到哪些数据。多数机构把前两个问题解决得不错——网关上有鉴权、接口上有白名单、后台有令牌校验。真正容易出事的，是第三个问题。

一个已经通过认证的调用方，带着合法的令牌请求某个订单详情接口，服务端如果只校验“这个令牌有效”，而不校验“这个令牌能不能看这条订单”，那么把路径末尾的编号改一改，就可能读到别人的订单。这类问题在 OWASP API Security Top 10（2023 版）里排在第一位——对象级授权失效（API1:2023）。

什么是 API 数据访问权限

API 数据访问权限是指在 API 调用链路上，对“谁能访问、能访问什么”做出判断并执行的一套控制机制。它的判断依据可能来自调用方的身份凭据，也可能来自请求本身携带的信息——调用的接口、传递的参数、发起请求的终端与网络位置。关键在“数据”二字。传统接口权限只管到接口这一层，而 API 数据访问权限要求把判断下沉到数据这一层：同一个接口，不同调用方能拿到的记录范围可以不同。

四层权限模型

把 API 的数据访问权限拆开看，它由四层叠加而成。四层的控制对象不同，能拦住的风险也不同。

传输层：先把通道加密

这一层解决的是“数据在路上会不会被看走”。通过 TLS 等加密通道，防止请求与响应在传输途中被抓包读取。

它是一道必要的基础防线，但它只保证“内容不被第三方看到”，不判断“这个调用方该不该拿到这些数据”。通道再密，也挡不住一个带着合法凭据的越权请求——加密与越权是两回事。

身份层：确认谁在调用

这一层解决的是“你是谁”。API Key、OAuth 令牌、JWT、客户端证书，都是这一层的常见手段。认证不过，后面的判断都无从谈起。但认证只回答身份问题，不回答权限问题。OWASP API Security Top 10（2023 版）把“认证失效”单列为一项风险（API2:2023），又另列了三项授权类风险——这本身就说明，认证与授权是两件事，通过了认证不等于获得了权限。

接口层：限定能调用哪些端点

这一层解决的是“你能调哪个接口”。按调用方身份开放特定的端点集合，是网关与 API 管理平台最常见的做法。它对应 OWASP 的“功能级授权失效”（API5:2023）——普通用户能否触达本应只给管理员的端点。做细一点，可以在端点层面区分读写、区分内部与外部。但它只管到端点这一层。同一个端点，参数里的对象标识不同，返回的数据就不同——接口级的判断看不见这层差异。

数据层：判断能拿到哪些记录

这一层解决的是“你能拿到哪些数据”。它要回答两个更细的问题：这个调用方能不能拿到这条记录（对象级授权，API1:2023），以及能拿到这条记录里的哪些字段（属性级授权，API3:2023）。数据层判断的难处在于，它需要把调用方身份与数据内容关联起来。请求里的对象标识不能自己证明权限——“我请求了这条记录”不等于“我有权看这条记录”。判断必须基于认证后的身份，在返回数据的那一刻做出。两者常被混为一谈，风险却不相同。对象级越权是“不该拿的记录拿到了”——把请求参数里的编号换成别人的，就看到了别人的数据。属性级越权是“该拿的记录里多了不该看的字段”——接口按业务需要返回了整条客户信息，顺带把证件号码、联系方式一并吐了出来。前者是范围问题，后者是字段问题，对应的控制手段也不一样。

四层权限的分工

四层是叠加关系，不是替代关系。只做前三层，等于把“能访问哪些端点”管住了，却没有管住“端点背后哪些数据能被带走”——而后者往往才是数据泄露真正的出口。

为什么多数机构卡在数据层

一个已经部署 API 网关、接入统一认证的机构，前三层通常都做到了。卡在数据层，原因有几个。

判断依据不在网关手里。 网关能看到接口路径和令牌，但“这条记录属于谁”这个信息在业务数据里。要让网关来判断，就得把业务数据或它的映射关系同步到安全侧，这超出了多数网关的能力范围。

判断要实时做。 数据访问权限不是上线前配置一次就完事的策略，它要在每个请求返回数据的那一刻生效。判慢了，业务响应受影响；判宽了，等于没判。

权限配置有历史惯性。 系统上线时为了不误伤业务，接口权限往往开得比较宽；等到数据合规要求收紧，这些历史配置很难一次回收，只能逐个接口去核，工作量不小。

规则要能表达业务语言。 “客服只能看本人负责客户的记录”“理财经理只能看名下的客户”——这类规则写不成简单的通配符，它需要以用户属性、机构归属、业务关系为条件，并且支持“属于/不属于”这类匹配逻辑。

落到工具上，数据层权限需要什么

如果要把第四层补齐，工具至少需要具备几项条件。

• 授权条件要贴近业务：除了调用方身份，还应支持以自然人、应用账号、API 端点、应用客户端 IP、业务特征等作为策略条件。
• 能在返回数据上执行：支持按响应数据值裁剪返回给请求方的记录，把高敏感查询自动过滤掉。
• 支持多维用户属性：规则的适用对象能细到用户、用户组、角色、职位、机构等多个维度。
• 授权要有时间与场景维度：不少数据访问是临时性的，权限能按申请人、生效时间、有效期收敛，比长期开放更稳妥。
• 身份关系要能穿透：从真实自然人到应用账号，再到具体的数据访问行为，中间的关联关系要能建立起来，否则“谁在用这个账号”始终是个谜。

常见问题

Q：已经有 API 网关了，还需要单独做数据访问权限吗？

A：取决于网关管到哪一层。网关通常解决身份与接口层的控制，数据层判断需要业务数据参与，多数网关不具备这个条件。两者不冲突，是补充关系。

Q：数据级权限会不会影响接口性能？

A：会有开销，取决于判断方式。把规则条件尽量结构化、避免在每次请求里做复杂关联查询，是控制开销的常见做法。

Q：内部接口也需要数据级权限吗？

A：需要。内部接口的调用方可信度更高，但内部人员越权读取数据的风险并不低，“能调用接口”不等于“该看到全部数据”。

Q：这四层要一次做齐吗？

A：不必。前两层通常是既有建设的存量能力，可以从接口层往数据层补。先挑数据敏感度高、调用方复杂的接口做试点，再逐步铺开。

结语

API 数据访问权限的四层，从加密通道到数据级判断，一层比一层更靠近数据本身，也一层比一层更难做。多数机构的能力分布呈现同一个形状：前三层扎实，第四层薄弱。补齐第四层的意义在于，把“接口能被调用”和“数据能被看到”这两件事分开——前者是业务的需要，后者不该是默认的结果。