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.

此外NISTNational 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=Base64hmacSha256secretkeynoce+secretId+secretKey。

客户端header请求头参数说明

名称	位置	是否必选	说明
x-mg-traceid	请求/响应	是	请求响应 ID用于跟踪异常请求调用。
x-mg-secretid	请求	是	授权的 SecretID用于加签开启密钥对鉴权时需要从控制台获取。
x-mg-alg	请求/响应	是	加密算法开启密钥对鉴权时需要由客户端自行指定。0hmac_md5 1hmac_sha_1 2hmac_sha_256 3hmac_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鉴权

JWTJSON 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 的权限管理借鉴了经典的 RBACRole-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: 自定义密钥通过如下方法进行测试

• 通过链接下载SDK工具main.qcloudimg.com/raw/3ed3e6e…* 在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方面的落地案例和经验。

引用

cloud.tencent.com/document/pr…cloud.tencent.com/developer/a…www.caict.ac.cn/kxyj/qwfb/z…www.weforum.org/agenda/2021…csrc.nist.gov/publication…

最后

整理了一套《前端大厂面试宝典》包含了HTML、CSS、JavaScript、HTTP、TCP协议、浏览器、VUE、React、数据结构和算法一共201道面试题并对每个问题作出了回答和解析。

有需要的小伙伴可以点击文末卡片领取这份文档无偿分享

部分文档展示

文章篇幅有限后面的内容就不一一展示了

有需要的小伙伴可以点下方卡片免费领取