本文目录导读:

微服务架构由于服务拆分的粒度更细、网络交互更频繁、技术栈更多样,其安全挑战与单体应用截然不同,保障微服务安全需要构建一个纵深防御体系,而非依赖单一的手段。
以下是保障微服务安全的核心维度和实践策略,可以将其分为外部入口安全、服务间安全、数据与访问安全、基础设施安全四个层面。
外部入口安全:守住大门
所有来自客户端(Web、App、第三方)的请求,都应该经过一个统一的API网关。
- 身份认证
- 机制:使用标准协议,如 OAuth 2.0 和 OpenID Connect (OIDC)。
- 实践:网关验证用户的身份(通过JWT Token或Session),用户登录后,网关发放一个令牌(Token),后续请求都携带该令牌。
- 访问控制与限流
- IP白名单/黑名单:限制来源。
- 速率限制:防止DDOS攻击或暴力破解,同IP每秒允许100次请求。
- 输入校验:
在网关层对请求参数进行格式校验、大小限制,阻止SQL注入、XSS等常见Web攻击。
- SSL/TLS终止:
网关处理HTTPS加密解密,后端服务间可以(且建议)使用HTTP(在安全网络内),降低后端证书管理复杂度。
服务间安全:内部通信的信任
这是微服务安全中最核心且容易出问题的环节,服务之间互相调用时,不能默认“内网是安全的”,需要建立强信任。
-
零信任模型
- 原则:绝不信任任何请求,无论来源是外部还是内部,每次调用都必须验证。
- mTLS:服务间最强的信任机制,双向TLS(Mutual TLS,即双向传输层安全协议),每个服务都有客户端证书,调用时双方互相验证证书,这可以防止“中间人攻击”和“非法服务混入”。
- 实践:使用服务网格(如Istio、Linkerd)可以自动为每个Envoy代理启用mTLS,应用代码几乎不需改动。
-
Service-to-Service 认证
- JWT交换:服务A调用服务B时,传递一个JWT令牌。
- 令牌来源:可以由API网关生成并转发,或者由各服务通过OAuth2的Client Credentials Grant(客户端凭证授权)向一个认证中心获取。
- :包含服务身份(Service Account,服务账号)、权限范围(Scope)。
-
API Key
对于内部服务调用(特别是没有用户上下文的),可以使用预共享的API Key或HMAC签名,但这不如mTLS安全,适合低敏感场景。
数据与访问安全:权限与加密
-
细粒度授权(RBAC/ABAC)
- RBAC(基于角色的访问控制):用户具有角色(如管理员、普通用户),角色有权限。
- ABAC(基于属性的访问控制):更灵活,基于用户属性、资源属性、环境属性(如时间、IP)决定。“只允许用户A在办公时间修改自己的订单,且IP在公司内网”。
- 通用模式:每个微服务内部实现自己的权限校验,或者通过一个中央的 Policy Engine(如Open Policy Agent,OPA) 来做决策。
-
数据加密
- 传输中加密:全链路TLS(外部HTTPS + 内部mTLS)。
- 静态加密:数据库、缓存、消息队列中的敏感数据(如密码、身份证号)必须加密存储(AES-256),密钥管理建议使用专门的密钥管理服务(KMS)。
- 脱敏处理:日志、监控、API响应中不应输出明文密码、信用卡号、Token等,使用脱敏函数替换。
基础设施与DevSecOps
-
安全的配置管理
- 不要硬编码:数据库密码、API Key、证书等敏感配置绝不能写在代码里。
- 工具:使用专门的密钥管理服务(如AWS Secrets Manager、HashiCorp Vault、K8s Secrets)。
- 动态注入:在容器启动时,由Secrets Store CSI driver(容器存储接口驱动)自动挂载到Pod中。
-
容器与镜像安全
- 镜像扫描:将镜像推送到仓库前,使用Trivy、Clair、Snyk等工具扫描已知漏洞。
- 最小化基础镜像:使用Alpine或Distroless镜像,减少攻击面。
- 无特权运行:容器内进程不要以root运行(设置
USER 1000)。
-
运行时安全
- 网络策略:在Kubernetes中,使用NetworkPolicy严格限制哪些Pod可以与哪些Pod通信(微隔离)。
- Falco等工具:检测异常行为,如shell进入容器、写入敏感目录。
常见的安全热点问题与对策
| 问题 | 场景 | 对策 |
|---|---|---|
| 令牌泄露 | JWT被盗,冒用身份 | - 使用短时效的Access Token(如15分钟),配合Refresh Token。 - 绑定Token到客户端IP或User-Agent。 |
| API滥用 | 爬虫、恶意刷单 | - 网关限流+熔断。 - 使用Captcha(验证码)。 - 行为分析(如短时间内修改地址次数异常)。 |
| 依赖漏洞 | 使用了一个有RCE漏洞的开源库 | - 定期漏洞扫描(Dependency Check)。 - 使用Software Bill of Materials(SBOM,软件物料清单) 追踪所有依赖。 |
| 日志泄露 | 日志中打印了用户密码或加密密钥 | - 日志脱敏(Log Masking)。 - 使用动态配置,避免敏感字段被记录。 |
一个典型的安全调用流程
- 用户 -> 登录 -> API网关(验证OAuth2,获取JWT)。
- 用户 -> 带JWT -> API网关(校验JWT签名、过期时间,限流后转发)。
- API网关 -> 带JWT -> 服务A(服务A校验JWT,确认用户身份和角色)。
- 服务A -> 需要查询服务B -> 服务B。
- 连接时:mTLS验证(服务A和服务B互相出示证书,防中间人)。
- 调用时:服务A使用自己的Service Account JWT(不是用户的JWT)调用服务B,服务B验证服务A是否有权调用该API。
- 服务B -> 查询数据库:使用最小权限数据库账户,且数据库连接加密。
- 流程完成,所有日志输出前,经过脱敏处理。
推荐的轻量级技术栈
- 认证:Keycloak / Auth0 / 自建OAuth2 Server
- 网关:Kong / Spring Cloud Gateway / Envoy
- 服务网格:Istio(自动mTLS、可观测性)
- 密钥管理:HashiCorp Vault / K8s Secrets
- 策略引擎:Open Policy Agent (OPA)
- 镜像扫描:Trivy
最后的重要建议:安全不是一次性的工作,建议建立红蓝对抗(安全团队模拟攻击,开发团队防御)机制,并定期进行渗透测试,因为微服务架构的复杂性常常会引入意想不到的绕过路径。