微服务框架的安全管控机制的设计

微服务框架的安全管控机制的设计

潘孝阳 黄晓芳

【摘 要】摘要：针对现有微服务框架存在的安全问题，提出了一种应用在微服务之间的安全管控解决方案。在微服务框架中应用了挑战应答机制并设计了权限控制中心，实现了微服务间通信的强身份认证，提高了其安全性。通过对方案的抗攻击及隐蔽信道能力的安全分析，证明该方案能够抵抗通信认证的重放攻击和跳板攻击，有效提高微服务开发框架的安全性。 【期刊名称】西南科技大学学报 【年(卷),期】2018(033)004 【总页数】5

【关键词】微服务 挑战应答机制 访问控制 重放攻击

近年来，随着软件的不断发展，软件市场对软件的开发技术有着越来越高的诉求，不断提升的用户量和业务依赖复杂度都对软件开发技术提出许多挑战。因此，软件开发技术以高性能、易扩展为核心设计理念，从单一架构到分布式架构的逐步转型。微服务的特性正符合了我们所期望的目标，所以被大多数的开发者所看好，也说明了微服务框架是软件开发的必然选择。

普遍认为2014年Fowler与Lewis首次提出了微服务的概念[1]，但当时并没给出精准的定义，只是将微服务描述为：微服务就是将单个应用程序拆分成多个小的服务的集群，每个微服务都围绕具体业务进行实现，相互之间通过轻量级通信机制，有着极少的统一管理。每个微服务可以独立部署，使用不同的编程语言，使用不同的数据存储技术[1-2]。反观SOA框架，它对某些技术栈的依赖性较高，从而使得切换时间长，花费成本高，让决策者望而生畏。由此也

可以看出，虽然同样是以服务模块化为目标，微服务架构与SOA架构有着很大的差别。

微服务框架在很大程度上优化了现有的软件开发流程，主要表现在：细化的服务模块相互独立，使得各部分逻辑更为清晰简洁；某一部分的改动可以单独发布，对整体的影响也相对较小；服务间相互技术隔离，也使得开发工具的选择更加灵活；各模块独自成为一个项目，可以对不同的业务部分进行需求性能调优。但是，微服务并不是一个完美的解决方案：分散的服务模块需要更庞大的运维团队，提升了服务监控和日志审计难度；分布式的数据同步和跨平台检索等技术问题同样也带入了微服务框架中；进程中的接口调用变成了服务间的接口调用，提高了调用的改动成本和性能成本；多个服务相互依赖，使得测试更加困难；微服务模块之间无条件相互信任，为攻击者提供了很多可乘之机。所以，本文将在分析微服务框架的安全性问题后，提出一些针对性的解决方案。

1 微服务框架脆弱性分析

微服务的分布式架构解决了一些目前SaaS业务的复杂性问题，但同时也引入以下安全隐患：

(1)分布式的框架设计暴露了更大的可攻击面[3]。在整体架构中，接口与接口之间的调用是进程中的调用，难以被外部介入，但在分布式的微服务框架中，各个模块被细化成为了单独的项目，相互间接口的调用和数据的传递都必须通过轻量级的通信机制实现，因此，微服务之间的通信内容就直接暴露了出来，特别是在现在比较常用的第三方云环境中部署时，不同节点上的微服务之间的通信也就直接通过网络进行传输了，攻击者便可以通过针对网络通信的攻击手段对系统数据进行篡改。

(2)各个微服务相互信任，整个应用更容易受个别已被攻陷的服务的影响[4]。各个微服务之间相互协作以完成一个复杂的业务逻辑，服务与服务之间相互信任对其他模块的数据和请求没有做较为完善的数据校验，在这种情况下，一旦某个微服务被攻击者攻陷，攻击者便可以利用这种信任关系对整个系统进行数据获取或者篡改。

2 微服务框架的安全管控解决方案设计

微服务的设计核心之一是业务去中心化，但对于微服务模块集群的管理工作则需要采用中心化的管理手段，强化微服务框架中的安全策略。因此，笔者案设计权限中心微服务，在认证每个微服务的同时对系统内部框架访问进行权限控制，保障安全的访问。

当单个的系统被拆分成为了多个服务模块后，服务与服务之间的权限控制和信任关系便成为了安全控制的关键点。对微服务集群提供身份认证机制可以提高微服务的可信度，而以最小化权限思想来考虑微服务的访问权限，可以在很大程度上降低微服务集群被单点突破的不良影响。因此，本文考虑使用挑战应答的模式对微服务进行认证，同时在微服务框架中应用权限控制模型来控制微服务的可访问范围，进而降低微服务会受到系统中的其他被攻陷微服务的影响的可能性。

2.1 挑战应答式心跳机制

通常微服务框架中需要一个注册发现机制，一般分为客户端的注册发现和服务端的注册发现，以实现对分散的微服务的统一识别。在服务端的注册发现机制中，注册服务器利用客户端发送的心跳包实时监控微服务的存活状态。权限中心微服务的设计参考了这种客户端与服务端的联系方式，使用不间断的挑战应