当前位置：首页 > news >正文

15、架构-可靠通讯之服务安全

news 文章来源：https://blog.csdn.net/qq_29434541/article/details/139611019 2025/1/12 23:17:21

概述

我们已经了解了与具体架构形式无关的业界主流安全概念和技术标准（如TLS、JWT、OAuth 2等概念），在上一章节探讨了与微服务运作特点相适应的零信任安全模型。在本节中，我们将从实践和编码的角度出发，介绍在微服务时代（以Spring Cloud为例）和云原生时代（以Istio over Kubernetes为例）分别如何实现安全传输、认证和授权。通过这两者的对比，我们将探讨在微服务架构下如何将业界的安全技术标准引入并实际落地，实现零信任网络下安全的服务访问。

建立信任

零信任网络里不存在默认的信任关系。一切服务调用、资源访问成功与否，均需以调用者与提供者间已建立的信任关系为前提。此前我们曾讨论过，真实世界里能够达成信任的基本途径不外乎基于共同私密信息的信任和基于权威公证人的信任两种。在网络世界里，因为客户端和服务端之间一般没有什么共同私密信息，所以真正能采用的就只能是基于权威公证人的信任，这种信任有一个标准的名字：公开密钥基础设施（Public Key Infrastructure, PKI）。

PKI 和 TLS

PKI是构建传输安全层（Transport Layer Security, TLS）的必要基础。在任何网络设施都不可信任的假设前提下，无论是DNS服务器、代理服务器、负载均衡器还是路由器，传输路径上的每一个节点都有可能监听或者篡改通信双方传输的信息。要保证通信过程不受到中间人攻击的威胁，启用TLS对传输通道本身进行加密，让发送者发出的内容只有接受者可以解密是唯一具备可行性的方案。

TLS的实现

建立TLS传输，看似不复杂，只要在部署服务器时预置好CA根证书，以后用该CA为部署的服务签发TLS证书便可。然而，落到实际操作上，这事情就属于典型的“必须集中在基础设施中自动进行的安全策略实施点”。面对数量庞大且能够自动扩缩的服务节点，依赖运维人员手工去部署和轮换根证书必定是难以为继的。除了随服务节点动态扩缩而来的运维压力外，微服务中TLS认证的频次也显著高于传统应用。比起公众互联网中主流的单向TLS认证，在零信任网络中，往往要启用双向TLS认证，即不仅要确认服务端的身份，还要确认调用者的身份。

单向TLS认证与双向TLS认证

单向TLS认证：只需要服务端提供证书，客户端通过服务端证书验证服务器的身份，但服务器并不验证客户端的身份。单向TLS用于公开服务，即任何客户端都被允许连接到服务进行访问，它保护的重点是客户端免遭冒牌服务器的欺骗。
双向TLS认证：客户端和服务端双方都要提供证书，双方各自通过对方提供的证书来验证对方的身份。双向TLS用于私密服务，即服务只允许特定身份的客户端访问，除了可以保护客户端不连接到冒牌服务器外，也可以保护服务端不遭到非法用户的越权访问。

认证

根据认证的目标对象，认证可以分为两种类型：一种是以机器作为认证对象，即访问服务的流量来源是另外一个服务，称为服务认证（Peer Authentication，直译为“节点认证”）；另一种是以人为认证对象，即访问服务的流量来自于最终用户，称为请求认证（Request Authentication）。无论哪一种认证，无论是否有基础设施的支持，均需有可行的方案来确定服务调用者的身份，建立信任关系才能调用服务。

服务认证

Istio版本的Fenix’s Bookstore采用了双向TLS认证作为服务调用双方的身份认证手段。得益于Istio提供的基础设施的支持，我们不需要Google Front End、Application Layer Transport Security这些安全组件，也不需要部署PKI和CA，甚至无须改动任何代码就可以启用mTLS认证。

mTLS的配置

如果你的分布式系统还没有达到完全云原生的程度，其中仍存在部分不受Istio管理（即未注入边车）的服务端或者客户端，你也可以将mTLS传输声明为“宽容模式”（Permissive Mode）。宽容模式的含义是受Istio管理的服务会允许同时接收纯文本和mTLS两种流量，纯文本流量仅用于与那些不受Istio管理的节点进行交互，你需要自行解决纯文本流量的认证问题；而对于服务网格内部的流量，则强制要求使用mTLS加密。

例子配置

以下是一个示例配置：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:name: defaultnamespace: istio-system
spec:mtls:mode: PERMISSIVE

用户认证

对于来自最终用户的请求认证，Istio版本的Fenix’s Bookstore仍然能做到单纯依靠基础设施解决问题，整个认证过程无须应用程序参与。例如，通过配置Istio的RequestAuthentication CRD，可以对外部用户的请求进行JWT验证，从而实现用户认证的自动化和透明化。

RequestAuthentication配置示例

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:name: request-jwtnamespace: bookstore-servicemesh
spec:jwtRules:- issuer: "https://example.com"jwksUri: "https://example.com/.well-known/jwks.json"

授权

在零信任网络中，服务之间没有固有的信任关系。只有已知的、明确授权的调用者才能访问服务，阻止攻击者通过某个服务节点中的代码漏洞来越权调用其他服务。这一原则可阻止攻击者扩大其入侵范围，与微服务设计模式中使用断路器、舱壁隔离实现容错来避免雪崩效应类似，在安全方面也应当采用这种“互不信任”的模式来减小入侵危害的影响范围。

基于角色的访问控制（RBAC）

RBAC是一种常见的授权机制，通过预定义角色和角色与权限的对应关系来控制用户或服务的访问权限。在Istio中，通过配置AuthorizationPolicy CRD，可以实现基于角色的访问控制。

AuthorizationPolicy配置示例

以下配置声明了一个授权策略，允许具有“admin”角色的用户访问“bookstore-servicemesh”命名空间中的所有服务：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:name: allow-adminnamespace: bookstore-servicemesh
spec:rules:- from:- source:principals: ["cluster.local/ns/bookstore-servicemesh/sa/admin"]

通过上述配置，我们可以确保只有具有“admin”角色的用户才能访问指定的服务，从而实现细粒度的访问控制，提升系统的安全性。

总结

服务安全是零信任网络的重要组成部分，通过建立信任、认证和授权等机制，可以有效保护微服务系统的安全性。在微服务和云原生环境下，通过使用诸如Istio等服务网格技术，可以简化安全机制的实现，确保系统在任何情况下都能安全运行。尽管实现零信任安全模型需要克服诸多技术和运维挑战，但其在提升系统安全性方面的优势无疑是显著的。

概述