一、导语
道路千万条，安全第一条。治理不规范，老板两行泪”。
当企业从单体架构逐渐转向微服务架构时， 服务安全 的需求也随之分散到了整个微服务体系的各个部分中。这就需要构建一套配置活、成本低的安全防控体系，覆盖请求链路中的各个部分，满足用户的安全诉求。本章将从安全的视角介绍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] [password]
-
operation: 加解密选项 encrypt或decrypt
-
content: 密文内容或明文内容
-
password: 自定义密钥
通过如下方法进行测试：
-
在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/document/product/649/19051
https://cloud.tencent.com/developer/article/1987889
http://www.caict.ac.cn/kxyj/qwfb/ztbg/202008/P020200812382865122881.pdf
https://www.weforum.org/agenda/2021/10/why-the-time-has-come-for-the-zero-trust-model-of-cybersecurity/
https://csrc.nist.gov/publications/detail/sp/800-207/final