本文目录导读：
关基（关键信息基础设施）场景下的微服务鉴权，比普通互联网应用要严苛得多，核心矛盾在于：既要满足等保2.0、关基保护条例等合规要求，又要应对微服务分布式架构带来的高动态、低延迟挑战。
以下从行业实践、技术选型、关键实现三个层面阐述关基微服务鉴权的核心方案：
核心架构范式：集中式鉴权 + 分布式传递
关基系统通常禁止使用完全去中心化的鉴权（如JWT无状态透传，因为无法及时吊销），主流方案是 “集中认证、局部鉴权”：
- API网关 / 统一认证中心：作为流量入口，进行身份认证（AuthN）和基础授权（AuthZ），这里采用OAuth2.0 + OIDC协议族，但必须做关基增强。
- 内嵌令牌（Token）：认证通过后，后端服务间交互使用短时效、可回调吊销的令牌（如基于PEP/PDP架构的令牌或上下文化Token）。
- 策略执行点（PEP）与策略决策点（PDP）分离：这是关键，每个微服务内部（或边车Sidecar）只负责执行（PEP），鉴权决策下沉到统一的PDP服务（策略引擎）。
关基场景下必须实现的5项鉴权特性
动态细粒度鉴权（ABAC / RAdAC）
不能只做“用户-角色-权限”（RBAC），需要基于属性决策：
- 用户属性：岗位、密级、是否双人操作。
- 环境属性：网络IP段（是否内网）、终端环境（是否国产化终端）、时间（非工作时间是否允许操作）。
- 资源属性：数据密级（普通/机密/绝密）、资产类别。
- 动作属性：读、写、删除、导出（导出通常需要二次审批）。
实现：在PDP中引入策略引擎（如Open Policy Agent, OPA），微服务调用时携带上下文，PDP返回
allow/deny。
零信任身份化
关基要求“永远验证，从不信任”，微服务调用链路上的每一个调用方（包括另一个微服务）都必须持有身份证书（mTLS）或服务账户令牌，不能因为服务A是“内部服务”就信任它。
- mTLS：服务间通信强制双向TLS，验证客户端和服务端证书。
- SPIFFE / SPIRE：用于在动态环境中为每个微服务分配唯一身份ID（类似身份证）。
令牌失效与审计追溯
JWT（JSON Web Token）无状态特性在关基场景下是重大安全隐患（无法立即踢下线、无法检测令牌被盗用）。
- 解决方案：使用红名单机制（Reference Token）或短时效JWT（TTL < 5分钟）+ 关键操作二次鉴权。
- 审计：每次鉴权决策（Allow/Deny）必须被不可篡改地记录（写入专用日志系统或区块链审计系统），包括：请求方ID、资源ID、策略ID、决策结果、时间戳。
防重放与抗抵赖
- 时间戳 + Nonce（随机数）：每个API请求必须携带时间戳和一次性随机数，服务端缓存Nonce防止重复使用。
- 签名：使用私钥对请求核心参数进行签名，保证传输过程未被篡改。
分级熔断与降级
关基系统不允许“一刀切”的熔断。
- 低风险操作（如查询公共信息）：允许降级为弱鉴权甚至放行，保障高可用。
- 高风险操作（如修改配置、删除数据）：必须经过严格鉴权，若PDP不可用，直接拒绝（Fail-Close）。
主流关基技术实现方案选型
| 方案 | 组件 | 优点 | 关基适配度（1-5星） | 典型工具 |
|---|---|---|---|---|
| OAuth2 + OIDC + PDP | 网关、授权服务器、策略引擎 | 标准成熟，能实现ABAC，审计友好 | ★★★★★ | Keycloak（需定制）+ OPA（Open Policy Agent） + Istio（服务网格） |
| 服务网格（Service Mesh） | Sidecar代理（Envoy） | 流量拦截无侵入，mTLS天然支持，PEP可下沉到Sidecar | ★★★★★ | Istio + Citadel（证书管理） + OPA（外部鉴权） |
| API密钥 + 签名 | 网关 | 实现简单，但管理复杂，不适合动态策略 | ★★★ | Kong / APISIX（需配合插件实现动态鉴权） |
| JWT（纯无状态） | 无服务器 | 性能好，但吊销难、安全风险高（除非T<60秒） | ★★ | 不推荐单独用于关基核心业务 |
| 国密改造 | 替换RSA为SM2, 替换SHA为SM3 | 合规必须，性能略有下降 | ★★★★★ | 使用支持国密的网关（如信安世纪、绿盟、华为） |
典型的关基微服务鉴权流程（结合零信任）
[用户] --> HTTPS --> [负载均衡/LB] --> [API网关/统一身份网关]
|
1. 认证请求（账号/证书/动态令牌）
2. 返回Access Token + Refresh Token
3. 用户携带Token请求业务A
4. 网关验证Token有效性（调用Auth Server）
5. 网关将鉴权请求转发到PDP（含用户属性、环境属性、资源属性）
6. PDP返回决策（Allow/Deny）
7. 网关将原始请求转发给【业务微服务A】
|
[业务微服务A] 内部调用【业务微服务B】
|
8. 服务A使用mTLS连接到服务B
9. 服务A在请求头中添加内部服务Token（或Propagate原始Token）
10. 服务B的Sidecar（PEP）再次请求PDP进行鉴权
11. 服务B返回数据给A
|
12. 请求返回给用户落地关基鉴权的特别警告
- 绝对不要用共享密钥：关基系统中，不同微服务之间的API密钥必须是动态分发、周期轮换的（如使用Vault或K8s Secrets）。
- 网络隔离优先：微服务间通信必须限于私有网络（VPN/VPC），不允许暴露公网接口，鉴权失败时，应记录告警并触发SIRT（安全事件响应）。
- 双人授权：对于“超级管理员”或系统高危操作（如修改防火墙、导出用户数据库），鉴权流程必须集成双人复核（甚至M个N的审批流）。
- 性能与安全的平衡：每增加一次PDP调用会增加1-2ms延迟，关基场景下，建议将高频低风险操作的策略缓存到PEP本地（TTL 30秒），而高风险操作实时呼叫PDP。
关基微服务鉴权的核心口诀是：“入口集中强认证，内部零信弱信任，策略决策集中管，执行分散不可省，审计日志不可逆，国密改造必须走。”
落地时,推荐 OAuth2 + OPA + Istio 组合，并配合 SPIFFE/SPIRE 进行服务身份管理，这是目前满足关基合规且最成熟的云原生架构方案。
