【央国企数据安全专辑｜观察篇（四）】认证≠授权：token 不是万能钥匙

✨ 摘要

将认证等同授权是央国企系统常见且危险的误区。本文沿用系列统一风格，把"认证-授权-审计"提升为可落地的工程体系：明确 token 选型与强化、网关与后端分工、策略引擎设计、缓存与一致性折衷、可观测与应急流程，并给出可复制的策略片段、伪代码与 30/90/180 天落地路线，确保高风险写/审批/导出操作始终由后端做资源级、上下文感知的最终裁决。

1 🔎 风险速览与攻击模型

核心问题：把 token 当作"万能钥匙"，只校验是否存在而不做资源级授权与上下文判断。
攻击能力模型：窃取 token、横向发现资源 ID、篡改请求参数、重放、利用缓存滞后。
高危后果：链式越权、IDOR、审批跳步、敏感数据批量导出、审计缺失导致不可取证。
安全目标：所有写/审批/导出操作由后端做资源级且上下文敏感的授权决策，并被结构化审计记录。

2 ⚠ 关键设计抉择与代价权衡

Token 选型
- JWT（自包含）：低延迟但难撤销，适合短期或读密集场景。
- 不透明 token + introspection：支持即时撤销与上下文校验，代价是额外延迟与可用性依赖。
- 推荐策略：高风险接口使用不透明 token 或短期 JWT + token binding / proof-of-possession。
撤销与一致性：短 TTL + 事件驱动失效或 selective introspection，权衡性能与安全。
网关 vs 后端：网关做格式/速率/签名初筛；后端策略引擎做最终裁决与审计输出。

3 🧭 授权架构与执行流（含流程图）

否是是否请求进入网关网关初筛: 验证
Authorization;
X-Signature;
速率后端 auth 验证 token (JWT/introspect) 构建 context:
user, resource, action, expectedStep, txId, risk 策略引擎 evaluate(RBAC+ABAC) 允许 ? 写拒绝: 返回
401/403;
写拒绝审计是否写操作? 资源锁 & 流程一致性校验;
写入; 写审计响应正常返回;
写审计(只读操作可选)

关键约束：策略评估输出必须包含 policy_id 与拒绝原因；所有决策产出结构化审计事件。

4 🔐 深度实现要点与代码片段

策略引擎设计

Context = { user, resource, action, expectedStep, txId, ip, ua, risk_score }。
支持 dry-run、版本管理、canary 发布与回退。

核心 Rego 策略示例

rego 复制代码

package authz

default allow = false

allow {
  valid_role
  in_expected_step
  risk_ok
}

valid_role {
  input.user.role == "approver"
}

in_expected_step {
  input.context.expected_step == input.resource.current_step
}

risk_ok {
  input.context.risk_score < 70
}

后端统一裁决伪代码（含缓存与锁）

pseudo 复制代码

on request(req):
  user = auth.verify_token(req.token)               # JWT verify or introspect
  if not user: audit.write(...); reject 401

  ctx = build_context(req, user)                    # expectedStep, txId, ip, ua, risk_score
  cache_key = hash(user.id, resource.id, action, ctx.hash)
  decision = cache.get(cache_key)
  if decision is null:
    decision = policy_engine.evaluate(user, resource, action, ctx)
    cache.set(cache_key, decision, ttl=short)
  if not decision.allow:
    audit.write(user, req, decision); reject 403

  if is_write_action:
    lock(resource.id)
    if not flow.verify_step(resource.id, ctx.expected_step):
      audit.write(...); unlock; reject 422
    perform_write()
    audit.write(user, req, decision, tx_id)
    unlock(resource.id)
  else:
    audit.write(user, req, decision)
    proceed

撤销与缓存策略

缓存决策 TTL 短（数秒到数十秒），在角色变更或撤销事件时触发失效。
对关键路径支持"强一致"模式：绕开缓存执行即时 introspection。

5 📊 测试、可观测与应急响应

测试矩阵：策略单元测试、集成并发场景、授权灰盒测试、AI 驱动模糊测试覆盖边界案例。
审计事件结构：{ timestamp, tx_id, user_id, resource, action, req_hash, resp_hash, policy_id, decision, latency, cache_hit }。
关键指标：授权决策延迟 P50/P95、缓存命中率、撤销生效时间、策略拒绝率、审计上报率。
应急方案：快速 token 强制失效（version bump）、切换强一致路径、导出 tx_id 审计包进行溯源取证。

6 ✅ 路线图与行动清单（30/90/180 天）

30 天止血

强制写/导出接口鉴权；启用签名与限流；关键写操作写审计。
KPI：写接口鉴权覆盖率 100%；审计上报率 100%。

90 天加固

策略引擎上线（支持 dry-run）；资源级授权覆盖核心流程；幂等与时间窗校验部署。
KPI：授权决策延迟 P95 ≤ 200ms；撤销生效 ≤ 60s。

180 天体系化

审计回放、异常行为建模并联动 SOC；策略治理纳入日常 KPI。
KPI：红蓝演练整改闭环率 100%；授权决策率 100%。

结语

把认证与授权彻底分离是消除"token 万能钥匙"风险的核心工程实践。关键落地要点：对高风险接口选择短期 JWT 或 introspection、把资源级与上下文感知的决策交给后端策略引擎、并将每次授权决策作为结构化审计事件纳入上线验收。做到可测、可撤、可追溯，才是真正的防护闭环。

下篇预告

观察篇·第5篇：浏览器调试攻防 --- 提供一张主流程图、授权测试用例库、DevTools 检查清单与 CI/DAST 集成要点，聚焦可复制的"发现---验证---取证"方法。