关于微服务:TSF微服务治理实战系列四服务安全

一、导语

路线千万条，平安第一条。治理不标准，老板两行泪”。
 
当企业从单体架构逐步转向微服务架构时，服务平安 的需要也随之扩散到了整个微服务体系的各个局部中。这就须要构建一套配置活、成本低的平安防控体系，笼罩申请链路中的各个局部，满足用户的平安诉求。本章将从平安的视角介绍 TSF 相干的能力，包含服务和网关的鉴权机制、如何保障利用配置的平安、权限治理及事件审计等方面。

二、作者介绍

崔凯
腾讯云 CSIG 微服务产品核心产品架构师
多年分布式、高并发电子商务系统的研发、零碎架构设计教训，善于支流微服务架构技术平台的落地和施行。
目前专一于微服务架构相干中间件的钻研推广和最佳实际的积淀，致力于帮忙企业实现数字化转型。

三、平安攻防与零信赖

针对零碎的攻打伎俩层出不穷，堪称道高一尺，魔高一丈。黑客们总有办法绕过零碎的种种防御机制，窃取零碎权限、用户重要信息等。比方常见的 SQL 注入、XSS、CSRF，比拟暴力的 DDOS 或代码开发引入的业务逻辑破绽，还有序列化破绽、文件上传破绽和框架组件破绽（如 fastjson、log4j2）等。

对于已知的平安危险或者破绽，咱们能够提前进行进攻，然而实践上没有一个零碎能够做到 100% 不被攻破。所以，在系统安全建设方面，进攻方须要通过较少的投入进步攻打方老本。另外，也须要缩小整个零碎的攻击面，比方通过 WAF 防火墙过滤歹意 URL、标准代码开发缩小业务逻辑破绽、缩小应用安全漏洞频发的组件或框架等。

不过，头痛医头脚痛医脚的进攻形式，往往顾此失彼。那么，有没有相干的规范和最佳实践经验来帮忙零碎进步架构的安全性呢？

追述到 2010 年，Forrester 的分析师 John Kindervag 提出的零信赖（Zero Trust），其核心思想为：默认状况下，企业内外部的任何人、事、物均不可信，应在受权前对任何试图接入网络和拜访网络资源的行为进行验证，简略来说就是 “永不信赖、始终验证”。

之后，Google 在 2014 年发表了一系列论文，并在 BeyondCrop 我的项目中将零信赖大规模落地。同时，国内也嗅到了零信赖的重要性，中国信通院在 2020 年 8 月公布了《网络安全先进技术与利用倒退系列报告——零信赖技术》报告，其中对零信赖相干准则、架构、场景等均进行了具体论述。

There are several ways that an enterprise can enact a ZTA for workflows. These approaches vary in the components used and in the main source of policy rules for an organization. Each approach implements all the tenets of ZT but may use one or two (or one component) as the main driver of policies. A full ZT solution will include elements of all three approaches. The approaches include enhanced identity governance–driven, logical micro segmentation, and network-based segmentation.

此外，NIST（National Institute of Standards and Technology）在 2020 年 8 月也公布了《SP800-207.Zero Trust Architecture》的终稿（片段如上），其中详细描述了 3 条零信赖架构支流的技术实现门路，包含加强的身份治理（Enhanced Identity Governance）、微隔离（Micro-Segmentation）、网络基础设施和软件定义边界（Network Infrastructure and Software Defined Perimeters），且这 3 种技术解决的问题域并不完全相同，组合起来能力造成残缺的 ZTA 解决方案。（原文可从附录中查阅）

四、微服务 ZTA 参考模型

腾讯云 TSF 基于上述零信赖架构相干参考文献及微服务畛域多年的教训积攒，梳理总结了微服务 ZTA 参考模型。其次要用于形象形容微服务架构场景中，零信赖各组成元素间的关系和逻辑。

其中，数字化拜访主体蕴含微服务架构中的人员、终端、服务等，且服务作为微服务架构的外围元素，所以其重要水平更高。

拜访主体发送不受信的申请后，必须由数据面的可信代理进行验证和受权。可信代理在微服务 ZTA 模型中次要以 Agent、Sidecar 和 SDK 等形式作为实现，其验证时会联动管控引擎，依据动静策略和实时信赖评估进行动静断定。

信赖评估除了实时接管管制面的日志、身份、权限等外部信息变动，还能够接管内部剖析及信赖评估平台提供的内部危险信息。

身份认证平台及设施是整个微服务架构 ZTA 参考模型的基石，它须要有提供整个验证和受权流程必须的身份和权限治理的能力。

五、TSF 的零信赖实现

腾讯云 TSF 以微服务为视角，通过网关鉴权、服务鉴权、配置平安、权限治理、行为审计 5 个平安点，以点带面的造成了一套针对微服务架构平安的解决方案。

从整个架构平安体系建设的角度看，在常见的 WAF 防火墙、入侵检测、动静感知、破绽扫描、主机防护、加密机、平安审计等多种平安防护伎俩中，服务平安 尽管只是架构平安中的一个环节，但其重要性显而易见，因为服务和数据是最重要的爱护对象。

以上图为例，假如一个用户想要拜访 DB 数据，首先通过网关对所有的申请进行鉴权并监控拜访行为。TSF 微服务网关通过 JWT、OAuth、密钥对等插件，使用户不便的将原有利用和鉴权形式疾速集成到 TSF 体系中，同时针对网关提供了具体的监控指标和可视化视图；通过收集 TSF 平台中的资源、公布、服务、配置等类型的事件，并对立汇聚到 TSF 事件核心和操作记录中，使得每一个用户行为都有迹可循；服务平安通过黑名单、白名单两种鉴权形式，让用户简略配置后就能够取得服务鉴权的能力；在权限治理方面，通过角色 + 数据集的形式，实现了多租户场景下用户对于 TSF 各性能项的权限调配和管控；针对配置平安，TSF 提供了即插即用的加解密组件，能够适配本地文件配置和分布式配置；

TSF 通过本身撑持侧中服务、接口、人员等元数据信息，对立治理拜访主体和受访对象，以标签化的形式构建了 TSF 身份认证平台。通过业务利用侧和撑持侧长连贯通信，一方面可将管制面中的信赖评估及动静策略下沉到可信代理，进步可信代理逻辑判断的效率；另一方面可将数据面产生的各类信息、记录、事件等上传到管制面，帮忙更精确、更高效的优化治理引擎策略。

网关鉴权

微服务网关作为后端服务的入口，次要提供路由转发、API 治理、Filter 过滤等作用，是微服务体系中的重要组件。

从 ZTA 的角度剖析，网关因为次要解决内部申请，所以受访主体次要是人员和终端。同时 TSF 基于插件的模式，对 JWT、OAuth、密钥对等常见的鉴权办法热插拔化，使得可信代理的能力能够依据应用场景灵便配置。最初网关也能够通过原有的 Filter 机制，对接内部剖析及信赖评估平台，如对接自建 OAuth 平台实现高度定制化鉴权管控。

网关分组

分组为 TSF 微服务网关自有概念，其将微服务网关中托管的后端服务 API 进行分类管理，以分组作为 API 的治理单元。如同一个分组下的 API 汇合都应用雷同的鉴权办法（JWT、OAuth、密钥对等），或者雷同业务的不同终端（PC 端、H5 端、APP 端）须要独立监控，都能够别离创立不同的分组进行治理。

创立分组时，每一个分组都须要一个固定的 Context 用以相互区别，同时能够在分组中配置多个密钥对，或挂载 JWT、OAuth 插件。

密钥对鉴权

密钥对须要在控制台中手动创立，蕴含 SecretId 和 SecretKey，值由 TSF 随机生成。SecretKey 是公钥，SecretId 是用来索引 SecretKey 的，能够认为是 SecretKey 的 ID 编号。密钥对会绑定在微服务网关分组上，倡议针对本身平安需要，制订对应的密钥更新打算。
 
网关开启密钥对鉴权后，所有流经网关的申请都需通过密钥对验证。常见应用场景包含：内部服务通过微服务网关拜访网关外部服务的接口时须要鉴权的状况。此处留神，网关密钥对是应用对称加密进行签名验证，即尽管网关生成 SecretId 和 Secretkey 时是成对的，但并不是非对称加密的公钥和私钥。

用户的客户端申请时须要在 Header 中携带 SecretId、加密算法、Sign 数字签名、Nonce 随机数参数，其中 Sign 的计算形式如下（以 HmacSha256 举例），而后在服务端通过客户端指定的算法从新计算 Sign 并比对。

数字签名的计算公式：sign=Base64（hmacSha256（secretkey，noce+secretId+secretKey））。

客户端 header 申请头参数阐明：

| 名称 | 地位 | 是否必选 | 阐明 |
| — | — | — | — |
| x-mg-traceid  | 申请 / 响应 | 是 | 申请响应 ID，用于跟踪异样申请调用。|
| x-mg-secretid | 申请 | 是 | 受权的 SecretID，用于加签，开启密钥对鉴权时须要，从控制台获取。|
| x-mg-alg | 申请 / 响应 | 是  | 加密算法，开启密钥对鉴权时须要，由客户端自行指定。0：hmac_md5 1：hmac_sha_1 2：hmac_sha_256 3：hmac_sha_512 4: 国密 sm3|
| x-mg-sign | 申请 / 响应 | 是 | 签名值。开启密钥对鉴权时须要。|
| x-mg-nonce | 申请 / 响应 | 是 | 随机数。开启密钥对鉴权时须要。|
| x-mg-code | 响应 | 是 | 响应码。|

用户申请需在 x-mg-alg 参数中需指明算法。且 TSF 除了反对常见的 HMAC，还 反对国密 SM3 算法（在 SHA-256 根底上改良的一种明码杂凑算法），进步了在某些政务加密场景中的适配水平。

利用（Service/APP）生成签名的规定：

第一步：组装摘要字符串
digestValue = (x-mg-noce)+secretId+secretKey

第二步：应用签名算法加密摘要，失去签名
signValue = Base64String(签名算法(secretKey, digetValue),”utf-8″)

服务端校验签名

第三步：将客户端申请头中的 x-mg-sign 与服务端依据生成签名规定（同客户端）计算的 SignValue 进行比对，如果两值雷同则认为鉴权通过，不同则认为鉴权失败。

场景: 跨业务线调用鉴权

在大型金融场景中，因为原有业务线须要和零碎管理权限对应，会造成各业务线各自分管本人所属微服务的资源、权限配置。那么，在业务线、子公司之间拜访时的权限管控问题，就须要借助密钥对鉴权的性能来实现。

微服务 Service 5 通过微服务网关 Gateway A 调用 Service 3，调用胜利流程如下图：

调用失败流程如下图：

基于如上场景，须要联结应用鉴权白名单 + 微服务网关分组 + 密钥对鉴权，配置步骤如下：

• 利用部署：如上图实现 Business A 和 Business B 两条业务线中全副 Gateway 和 Service 的部署。
• 配置业务线内白名单：实现 Business A 中 Service1-4 的白名单配置，即各 Service 只容许 Business A 内的 Gateway A 和 Service1-4 拜访。
• 创立网关分组：创立属于 Business A 的网关分组，留神部署组抉择属于本业务线的微服务网关。

• 公布分组 API：控制台进入创立的分组 Business-A，点击 API 列表，点击导入 API，抉择 Service 3 须要被 Service 5 拜访的 API，返回网关分组列表，点击公布分组，实现所选 API 在 Gateway A 网关上的公布。

• 配置密钥对鉴权：从微服务网关 Gateway 进入刚创立的网关分组 Business-A，在访问信息页下方密钥治理中新建密钥。

• 复制密钥到应用方：将刚生成的密钥的 SecretId 和 SecretKey 复制进去，并配置在调用方 Service 5 中的代码利用配置中。
• 应用方通过密钥编写数字签名代码：通过代码计算 Sign 签名，而后将 Sign、SecretId、Nonce、AlgType 参数封装在调用申请的 Header 中。
• 实现服务调用：应用 Service 5 调用 Gateway A 所暴露出的 API。

JWT 鉴权

JWT（JSON Web Token）的表现形式是一个 Token，可将其了解为一个 Json 对象，对象中蕴含 Header、Payload、Sign 三局部。如用户登录换取 Token 时，该 Token 除了代表用户已登录，还可用来代表用户所具备的权限。因 JWT 中的 Sign 使得通信内容是通过加密签名的，保障了通信单方的数据真实性和完整性，常应用在有通信加密的场景。

JWT 的原理是，客户端通过 JWT 认证服务器认证当前，会返回给客户端一个 JWT 令牌（Token），示例如下（实在长度会更长）。

JWT 分为三局部：Header（头部）、Payload（负载）、Signature（签名），两头用点（.）分隔成三个局部。

• Header:Header 局部形容 JWT 的元数据。
• Payload:Payload 局部用来寄存理论须要传递的数据，包含官网定义的字段和用户自定义字段。
• Signature:Signature 局部是对前两局部的签名，避免数据篡改。

用户应用 JWT 进行整体流程验证的过程如下：

可见，客户端与服务端通信的时候，都要携带这个 JWT 令牌（Token）。微服务网关 JWT 插件凭此令牌（Token）来校验客户端权限，同时可从 Payload 中获取用户信息，服务端就不再保留任何 Session 数据。此时服务端变成无状态了，比拟容易实现横向扩大。

场景：JWT 登录校验

在登录场景中，能够应用 JWT 进行登录的令牌验证，同时能够在 JWT 中携带一些可用信息，能够在服务接口调用过程中进步调用效率。

如下图所示为登录场景下 JWT 生成及业务调用的逻辑流程:

具体配置步骤如下：

• 实现认证代码编写：Auth Server 验证 Username、Password 及生成 JWT 逻辑。
• 在微服务网关中配置 JWT 插件：依据应用的密钥对文件，如下图配置 JWT 插件。

• 绑定插件对象：将创立的 JWT 插件绑定到某个微服务网关分组，即可针对拜访此分组中 API 进行 JWT 鉴权。

OAuth 鉴权

OAuth 插件提供了简略的第三方鉴权对接的能力。内部待鉴权申请先到网关，网关再向第三方鉴权服务申请校验。所以，OAuth 插件须要在已具备 OAuth 验证服务的场景下应用，且插件仅帮忙转发 OAuth 认证的申请。

OAuth 插件的时序图如下：

内部申请到业务 API 的申请，会在通过微服务网关时，由网关转发到认证服务器进行认证，认证服务器将认证后果返回给网关，由网关决定内部申请是否持续向下转发。

服务鉴权

TSF 的服务鉴权的对象是在注册核心已注册的微服务，鉴权的形式分为 黑名单和白名单，通过 TSF 注册核心与 SDK 的下发通道下发鉴权规定到 TSF-SDK 中（下发通道详见本系列第一篇《治理蓝图》）。当申请到来时，TSF-SDK 通过本地鉴权规定进行判断，通过则交由后续流程持续解决申请，不通过则返回鉴权失败（状态码 403 Forbidden）。

当某一个服务配置了多个鉴权规定时，会对多个鉴权规定进行程序匹配。对于白名单鉴权，程序匹配时满足某一条规定，申请即被放行。所有规定都不满足，则拒绝请求；对于黑名单鉴权，程序匹配时满足某一条规定，则拒绝请求，所有规定都不满足，则申请被放行。

同样的，TSF 服务鉴权依靠标签化整体能力，通过粗粒度的零碎标签和细粒度的自定义标签，灵便对微服务体系内南北流量和货色流量进行权限治理。其基本原理如下图：

服务提供者通过配置核心下发的鉴权规定来判断是否解决服务消费者的申请。TSF-SDK 在收到鉴权规定后，会将鉴权规定缓存下来。当控制台中更新鉴权规定时，本地缓存也会进行准实时更新。

参考微服务 ZTA 参考模型，服务鉴权中的拜访主体、受访对象、身份认证、信赖评估、动静策略等局部，均以微服务为外围。TSF 加强的点在于基于标签化形象拜访主体和受访对象，并且拉齐了语言、通信协定、微服务框架、资源、操作系统、CPU 架构等差别，拓宽了服务鉴权可落地范畴。

场景：服务间接口拜访鉴权

黑名单鉴权常被用于服务间的接口鉴权场景中，比方 Consumer 服务调用 Provider 服务的 /Echo 接口，但 Consumer 服务有两个同时在保护的版本 V1 和 V2，要求只有 Consumer 的 V1 版本能够拜访 /Echo 接口。

此时就能够通过在 Provider 服务上配置黑名单来实现 API 粒度的鉴权。如下图所示，在 Provider 服务中创立黑名单鉴权规定，同时满足上游服务为 Consumer 且版本为 V2，拜访 Provider 服务的 /Echo 接口时，就会被回绝拜访。

场景：白名单放行局部 IP

在传统企业外部的财务部门，对于企业内拜访平安及窃密程度较高，个别对财务部门会采取物理隔离的形式实现财务部门的数据窃密。然而非凡状况下，财务部门须要被国家机关监管，这就要求财务部门的服务能够被内部拜访。

此时，能够通过 TSF 服务鉴权中白名单机制来管制。首先，配置能够拜访财务部门服务的跳板机并固定 IP。其次，在 TSF 服务鉴权中新建鉴权规定，勾选白名单并抉择 零碎标签 - 上游 IP，填写跳板机 IP，实现仅容许配置 IP 能够拜访财务服务的成果。

配置步骤如下：

• 用户在控制台中在 服务治理 - 服务鉴权 中点击 新建鉴权规定，并依据如下图所示进行配置。
• 通过失效状态按钮管制本条规定的失效状态。

权限治理

RBAC

TSF 的权限治理借鉴了经典的 RBAC（Role-Based Access Control）模型而进行设计，通过对于 TSF 用户、角色、权限的配置，以角色作为灵便治理的权限汇合，以数据集作为可操纵的对象汇合，清晰的描述了“用户”是否对“某个动作或对象”具备“权限”的模型关系。

以微服务 ZTA 的视角察看，TSF 通过“角色”来形象拜访主体和受访对象的身份，通过“数据集”来切割数据面的管控范畴，帮忙管制面灵便、多样、高效的进行身份评估，解决了权限管控变更难、治理粒度粗暴等问题。

TSF 语义形象

TSF 权限治理通过多租户机制隔离各租户，同时应用角色和数据集治理租户下各用户的权限，另外配合 TSF 的集群和命名空间设计，实现多种组织架构下权限场景的需要。

TSF 作为一体化微服务平台，通过形象微服务架构中各个概念，实现权限汇合（角色）和管制项汇合（数据集）的对应关联。

在理论应用场景中，常存在开发、运维、测试、管理者等多种角色，并且各企业中雷同角色也可能领有不同的权限。TSF 反对通过创立不同的角色，灵便的将 TSF 提供的性能关联到企业角色中。

数据集次要用于限定某个角色可治理的范畴，比方业务开发一组可能只关注本身应用的集群、命名空间、利用等资源，对其它业务开发组的内容并不心愿显示进去。

场景：集团公司权限治理计划

在大型集团公司中，因为组织内部人员架构的复杂性，对微服务平台的权限设计和治理会提出比拟高的挑战，其中常见的诉求点如下：

• 微服务平台的权限计划须要匹配现有团体下各子公司的人员及组织构造;
• 针对不同的角色灵便配置不同的权限范畴和可视范畴;
• 生产环境和测试环境（泛指所有测试环境）须要有严格、残缺的业务隔离和资源隔离;
• 权限的管控力度除了笼罩集群、命名空间等资源方面，还要笼罩到规定、策略等性能项.
• ……

基于上诉场景诉求，可别离通过：

• 每个子公司配置一个租户，实现每个子公司基于租户级别的隔离，从而在资源、治理上齐全隔开;
• 子公司内的每个业务线一套独自的集群，不便每个业务线对资源独占，同时满足只治理本身集群资源的诉求;
• 通过命名空间隔离测试、生产环境，实现不同环境间业务的齐全隔离和治理;
• 超级管理员负责 XX 集团公司的对立治理，各子公司设立本身的租户管理员，每个业务线设立业务线对应的总负责人，针对开发、测试、运维等角色别离创立角色和对应的数据集，通过如上办法让微服务平台权限体系适配到不同企业的人员组织架构中;

针对一些非凡的定制化权限诉求，能够将权限和可视粒度下放到具体的性能项，甚至某个利用上.

配置平安

针对敏感信息，TSF 提供了加解密的 SDK 工具，可通过 SDK 对敏感信息进行加解密爱护，如数据库、音讯队列、Redis 等中间件的用户名明码等。

通过 SDK 工具进行加解密的命令格局为：

java -jar spring-cloud-tsf-encrypt-1.1.1-RELEASE.jar [operation] [content]

• operation: 加解密选项 encrypt 或 decrypt
• content: 密文内容或明文内容
• password: 自定义密钥

通过如下办法进行测试：

• 通过链接下载 SDK 工具：https://main.qcloudimg.com/ra…
• 在 jar 包所在目录执行如下命令进行加密

java -jar spring-cloud-tsf-encrypt-1.1.1-RELEASE.jar encrypt TX_PwDemO_1hblsqT encryptPassword  

• 在 jar 包所在目录执行如下命令进行解密

java -jar spring-cloud-tsf-encrypt-1.1.1-RELEASE.jar decrypt 3M7wGw2XtFc5Y+rxOgNBLrm2spUtgodjIxa+7F3XcAo= encryptPassword  

配置加密内容时，能够配置在本地 yaml/properties、TSF 利用配置 / 全局配置中，举荐 yaml 文件中配置，示例如下：

tsf:  
  inventory:  
    password:  
      encrypt2: ENC(3M7wGw2XtFc5Y+rxOgNBLrm2spUtgodjIxa+7F3XcAo=)  

配置密钥内容时，能够在环境变量、JVM 参数、启动参数中配置，举荐环境变量中配置，密钥泄露的危险最小，示例如下：

tsf_config_encrypt_password=encryptPassword  

行为审计

操作记录

TSF 能够在控制台操作记录中察看到每个租户在什么工夫进行了什么样的操作，操作项简直涵盖了所有 TSF 控制台性能。并且操作记录反对对资源模块、操作类型的筛选和关键字的搜寻，不便用户更疾速的针对性查找。

事件核心

TSF 能够帮忙用户在运维、开发等场景，通过事件驱动的形式治理本身零碎。其中，事件类型次要包含资源、公布、服务、弹性方面的变更，还能够基于事件的变化趋势对系统状态进行预判。

最新事件能够及时查看以后产生的事件，同时在事件详情中能够依据时间段查看历史产生过的事件。

另外，事件核心还能够与事件总线联动进行事件告警，当触发预设事件后，通过云函数、传统音讯、音讯队列等形式进行告诉或转发。

六、结语

以上简要介绍了 ZTA 相干概念，以及 TSF 是如何依靠微服务架构 ZTA 参考模型理念实现本身服务平安的。将来对于微服务架构平安体系建设的挑战仍有很多，比方身份的智能剖析和自动化响应、无口令认证、特权拜访治理等。在新技术、新环境下，咱们也将继续关注微服务架构在 ZTA 方面的落地案例和教训。

援用

https://cloud.tencent.com/doc…
https://cloud.tencent.com/dev…
http://www.caict.ac.cn/kxyj/q…
https://www.weforum.org/agend…
https://csrc.nist.gov/publica…