特殊场景下微服务安全鉴权通用方案探索：每个微服务独立部署的安全挑战

背景

我们公司面临一个独特的业务场景：每个微服务都需要独立部署到客户的私有环境中，无法依赖中心化的 API 网关。这导致每个服务都必须自带一套完整的安全鉴权逻辑，带来了大量的重复代码和配置管理工作，尤其是在处理用户认证令牌和多租户权限隔离方面。

问题分析

1. 重复代码： 每个微服务都包含相同的用户认证、权限校验逻辑，导致代码冗余，维护成本高。
2. 配置管理： 身份验证配置（如 JWT 密钥、OAuth 配置）需要在每个服务中单独配置和管理，容易出错且难以统一更新。
3. 安全风险： 如果某个服务的安全逻辑出现漏洞，需要在所有服务中修复，增加了安全风险。
4. 多租户隔离： 如何在每个微服务中有效地实现多租户的数据隔离和权限控制是一个挑战。

通用解决方案探索

为了解决上述问题，我们需要一个通用的安全鉴权方案，能够在不牺牲安全性的前提下，减少重复代码和配置管理。以下是一些可能的方案：

1. Sidecar 模式

• 方案描述： 为每个微服务部署一个 Sidecar 容器，负责处理所有的安全鉴权逻辑。微服务只需要与 Sidecar 通信，无需关心具体的鉴权细节。
• 技术选型： 可以使用 Envoy、Istio 等服务网格技术，或者自定义 Sidecar。
• 优点：
  • 减少重复代码，将安全逻辑集中在 Sidecar 中。
  • 统一配置管理，只需要管理 Sidecar 的配置。
  • 易于扩展，可以方便地添加新的安全策略。
• 缺点：
  • 增加部署复杂度，需要管理 Sidecar 容器。
  • 增加网络延迟，微服务需要与 Sidecar 通信。

2. Auth SDK

• 方案描述： 开发一个通用的 Auth SDK，包含用户认证、权限校验等功能。每个微服务引入 Auth SDK，并调用相应的 API 进行鉴权。
• 技术选型： 可以使用 Java、Go、Python 等语言开发 Auth SDK。
• 优点：
  • 减少重复代码，将安全逻辑封装在 Auth SDK 中。
  • 易于使用，微服务只需要调用 Auth SDK 的 API。
• 缺点：
  • 需要维护 Auth SDK，并确保其兼容性。
  • 更新 Auth SDK 需要重新部署所有微服务。

3. JWT (JSON Web Token) 方案 + 自定义拦截器

• 方案描述： 使用 JWT 作为用户认证令牌，并在每个微服务中实现自定义拦截器，解析 JWT 并进行权限校验。
• 技术选型： 可以使用 Spring Security、Shiro 等安全框架，或者自定义 JWT 解析和校验逻辑。
• 优点：
  • 无状态，易于扩展。
  • JWT 包含用户信息和权限信息，方便进行权限校验。
• 缺点：
  • JWT 的大小有限，不适合存储大量用户信息。
  • JWT 的撤销比较困难，需要额外的机制来处理。

多租户权限隔离

无论选择哪种方案，都需要考虑多租户权限隔离。以下是一些实现多租户权限隔离的常见方法：

• 数据库隔离： 每个租户使用独立的数据库，实现物理隔离。
• Schema 隔离： 每个租户使用独立的 Schema，实现逻辑隔离。
• 共享数据库，行级别隔离： 在同一张表中，通过租户 ID 来区分不同租户的数据。

总结

针对每个微服务独立部署到客户私有环境的特殊业务场景，我们需要一个通用的安全鉴权方案，减少重复代码和配置管理。Sidecar 模式、Auth SDK 和 JWT 方案 + 自定义拦截器都是可行的选择。在选择方案时，需要综合考虑部署复杂度、性能、可扩展性等因素。同时，还需要考虑多租户权限隔离，确保数据的安全性。