4. 权限粒度层次分析：系统级、模块级、数据行级、字段级
4.1 边界定义与分层模型
权限粒度的核心在于“在正确的位置施加正确力度的控制”。从边界向外看，粒度从粗到细形成四层纵深防御模型：系统级决定“能否进门”，模块级决定“能否使用功能”，数据行级决定“能否看到这条记录”，字段级决定“能否看到这个属性”。四层之间存在严格的信任链——只有通过外层校验，请求才会进入内层过滤。
核心原则：外层控制以高效拦截为主，内层控制以精准脱敏为主。切忌在外层执行细粒度行过滤（性能灾难），也不要在内层反复校验基础身份（信任链路断裂）。
4.2 组件职责与信任链路
| 层级 | 执行点 / 组件 | 核心职责 | 信任传递条件 |
|---|---|---|---|
| 系统级 | API Gateway, Service Mesh, 网络策略 | TLS终止、JWT验签、IP白名单、限流 | Token合法性 + 来源可信 |
| 模块级 | 应用路由、功能开关、API Scope | 菜单可见性、API路由授权、功能开关 | 用户角色与资源Scope匹配 |
| 数据行级 | 数据访问层 (DAL)、策略引擎 | 过滤行集（Owner、Org、Region） | 模块授权通过 + 数据上下文注入 |
| 字段级 | 序列化器、视图层、脱敏中间件 | 列屏蔽（SSN、Email、薪资）、加密输出 | 行级过滤完成 + 字段策略匹配 |
信任链路设计要点：系统级不关心业务身份，只验证“你是谁”（JWT Sub）；模块级不关心数据内容，只验证“你能做什么”（Scope）；行级和字段级才结合“数据你是谁”（Owner/Context）完成最终放行。
4.3 数据流与控制流
一次跨安全域的请求，必须严格按照“系统 → 模块 → 行 → 字段”的顺序逐层通过。控制流携带上下文令牌（Context Token），数据流在最后一层完成脱敏后返回。
// 典型请求链路（伪代码）
1. [系统级] verify_jwt(token) -> subject="user_123", role="admin"
2. [模块级] check_scope(token, "/api/v2/employees") -> PASS
3. [行级] apply_filter("org_id = user.org_id") -> 返回匹配行集
4. [字段级] apply_mask(rows, ["ssn", "salary"]) -> 数据脱敏后响应
风险点：粒度跳跃
如果行级过滤未严格依赖模块级注入的上下文（如直接使用前端传入的user_id进行SQL过滤），攻击者可通过修改请求参数实现越权访问。必须确保控制流上下文由外层逐级签名传递，禁止内层从不可信来源重新获取。
如果行级过滤未严格依赖模块级注入的上下文（如直接使用前端传入的user_id进行SQL过滤），攻击者可通过修改请求参数实现越权访问。必须确保控制流上下文由外层逐级签名传递，禁止内层从不可信来源重新获取。
4.4 选型权衡
| 评估维度 | 系统级 | 模块级 | 数据行级 | 字段级 |
|---|---|---|---|---|
| 性能影响 | 低（静态规则匹配） | 低（路由表查询） | 中（动态过滤/索引依赖） | 高（逐字段处理/加密开销） |
| 实施复杂度 | 低（基础设施配置） | 中（代码框架集成） | 高（数据模型与策略绑定） | 中上（序列化层改造） |
| 灵活度 | 固定 | 中 | 高 | 精细 |
| 管理成本 | 低 | 中 | 高（策略数量膨胀） | 中（字段变动需同步） |
推荐组合策略：对于大多数业务系统，建议“系统级 + 模块级”作为默认防线，仅在涉及敏感数据（PII/金融）的场景启用“行级 + 字段级”的纵深防御。避免在全量数据接口上做行级过滤，优先通过应用层路由缩小数据范围。
4.5 风险点
- 粒度跳跃攻击：模块级未验证用户Scope，直接暴露行级SQL查询接口，导致水平越权。
- 性能衰减：在字段级对大数据集进行逐行脱敏（如10万行+10个字段），P99延迟可能上升300%以上。
- 策略不一致：系统级允许了某个IP，但模块级未同步路由白名单，造成认证通过但授权失败的黑洞现象。
- 字段级过度脱敏：字段策略未与数据分类联动，导致非敏感字段（如用户名）被错误脱敏，影响业务可用性。
4.6 落地步骤
- 资产映射与分级：梳理所有API端点，标记其对应的系统、模块、数据表和字段的分类等级（公开/内部/敏感/绝密）。
- 架构锚点识别：在现有代码中定位4层对应的具体组件（如Spring Gateway对应系统级，Controller路由对应模块级，MyBatis拦截器对应行级，Jackson序列化器对应字段级）。
- 策略定义与编排：采用配置中心（如Apollo/Nacos）统一管理策略，避免硬编码。示例策略JSON：
{
"layer": "FIELD",
"resource": "/api/v2/employees/*",
"fields": {
"ssn": {"mask": "LAST_FOUR"},
"salary": {"mask": "RANGE", "min": 0, "max": 999999}
},
"conditions": {
"role": ["HR_MANAGER", "AUDITOR"]
}
}
- 性能压测与缓存：对行级和字段级新增策略执行全链路压测，引入行级结果缓存（如Redis）降低数据库压力。
- 灰度发布与监控：按“系统级 → 模块级 → 行级 → 字段级”的顺序灰度放量，实时监控鉴权通过率和响应延迟。
4.7 验收标准
- 安全穿透测试：跳过系统级直连模块级后端接口，请求被正确拦截（返回401/403）。
- 行级隔离验证：用户A通过API查询看到的数据行集不包含用户B所属的记录。
- 字段级脱敏正确性：敏感字段（如身份证号）在非授权角色下返回脱敏值（如"310***********1234"）。
- 性能基准：引入4层全量策略后，核心API的P99延迟增幅不超过5%，数据库连接池未出现雪崩。
- 策略热更新：修改配置中心的字段策略后，5分钟内生效且不中断现有请求。
常见验收陷阱：测试环境通常数据量小（几千行），容易忽略生产环境千万级数据下的行级过滤性能问题。务必在生产环境的影子库或全量压测环境中执行最终验收。