实录分享 | 微服务访问安全设计方案全探索

今天给大家带来的是 数人云工程师文权在高效运维线上群的分享实录。从传统单体应用架构到微服务架构,安全问题一直是人们关注的重点,文权与大家分享了关于微服务访问安全设计方案的探索与实践。

我们首先从传统单体应用架构下的访问安全设计说起,然后分析现代微服务架构下,访问安全涉及的原则,接着讨论目前常用的几种微服务架构下的访问安全设计方案。最后,详析Spring Cloud微服务架构下如何解决访问安全的问题。

一、传统单体应用的访问安全设计

上面的示意图展示了单体应用的访问逻辑。用户通过客户端发出http或者https请求,经过负载均衡后,单体应用收到请求。接着经过auth层,进行身份验证和权限批准,这里,一般会有跟后端数据库的交互。通过后,将请求分发到对应的功能逻辑层中去。完成相关操作后,返回结果给客户端。

传统单体应用的访问安全设计——原则

从以上分析可以看到,传统单体应用的访问安全设计原则为:

第一,每次的用户请求都需要验证是否安全,这里可以分两种情况:

一种是没有session的请求,需要经过几个步骤完成session化。一般为验证当前用户的credential,获取当前用户的identity,这两步都需要访问数据库等持久化对象来完成,最后一步是为当前可用创建session,返回给客户端后,启用该session。

另一种是有session的请求,只需验证请求中当前session的有效性,即可继续请求。

第二,用户的操作请求都在后端单个进程中执行完成,完全依赖后端调用方法的可靠性。一旦出错,应用是无法再次重复请求。

传统单体应用的访问安全设计——优势和注意点

小结,传统单体应用由于设计相对简单单一,暴露给外界的入口相对较少,从而具有被攻击并造成危害性的可能小的优势。

也正是由于单体应用简单单一的特点,需要注意相关问题:

  • 应用后端保存了所有的credential等敏感信息
  • 一旦入侵了对这个应用的请求,就有可能拿到所有的保存在后端的信息
  • 应用的每次操作一般都需要和数据库进行交互,造成数据库负载变高

二、微服务架构下,访问安全设计原则

先来看下这张典型的微服务设计架构图,如图所示,有以下几点特征:

  • 每个服务只有权限去操作自己负责的那部分功能。
  • 用户请求的身份验证和权限批准都由独立的gateway服务来保障
  • 对外服务的LB层无法直接与提供业务服务的应用层进行访问 从上面的特征分析来看,想要给出一份访问安全设计的原则说明,就要看看微服务架构下,访问安全有哪些痛点,以下罗列了几点:

  • 单点登录,即在微服务这种多独立服务的架构下,实现用户只需要登录一次就能访问所有相互信任的应用系统

  • 微服务架构下的应用一般都是无状态的,导致用户的请求每次都需要鉴权,可能引发Auth服务的性能瓶颈
  • 微服务架构下,每个组件都管理着各自的功能权限,这种细粒度的鉴权机制需要事先良好的规划
  • 微服务架构下,需要考虑到那些非浏览器端的客户请求,是否具有良好的可操作性

根据实际情况,还有一些其他痛点,这里不再一一赘述,而这些痛点,就形成了我们在为微服务架构设计访问安全的原则。

三、微服务架构下,常用的访问安全设计方案

  • HTTP Basic Authentication + Independent Auth DB
  • HTTP Basic Authentication + Central Auth DB
  • API Tokens
  • SAML

这里列出4种,首先简单介绍下,然后一一叙述。

第一种,使用HTTP Basic Auth协议,加上独立的Auth数据库。 第二种,也是使用HTTP Basic Auth协议,跟第一种不同的是,使用集中式的Auth数据库 第三种,API Tokens协议,这种大家应该比较熟悉,很多公有服务(比如Github、Twitter等)的API都是用这种方式。 第四种,SAML,即Security Assertion Markup Language,翻译过来,是『安全声明标记语言』,它是基于XML的一种协议,企业内使用得较多。

下面一一做介绍。

微服务常用访问安全设计方案——Basic Auth + Independent Auth DB

第一种,如上示意图所示,使用Basic Auth协议,配合每个服务自己都拥有存储Credential敏感数据的数据库(或者其他持久化仓库)。

简单介绍下Basic Auth协议,它是在用户的请求中添加一个Authorization消息头,这个消息头的值是一个固定格式: Basic base64encode(username+“:”+password)

完整的消息头列子为: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Basic Auth协议基本上被所有流行的网页浏览器都支持。

这种方案的特点:

  • 每个提供功能的服务都拥有自己独立的鉴权和授权机制
  • 每个提供功能的服务都拥有自己独立的数据库,来保存敏感信息
  • 每次用户请求都需要携带用户的credential来完成操作

小结下使用这种方案的好处:

  • 微服务的应用可以实现100%无状态化
  • 基于Basic Auth开发简单

同时,小结下使用这种方案需要注意的地方:

由于每个服务都有自己存储credential的机制,需要事先为每个服务设计好如何存储和查找用户的Credential 由于每次用户请求都会携带用户的Credential,需要事先设计好如何管理鉴权机制

微服务常用访问安全设计方案——Basic Auth + Central Auth DB

第二种,如上示意图所示,使用Basic Auth协议,与第一种方案相比,每个服务共用有同一个Auth DB。

第二种方案的特点和第一种很相似:

  • 每个提供功能的服务都拥有自己独立的鉴权和授权机制
  • 每个提供功能的服务共用同一个DB,来保存Credential等敏感信息
  • 每次用户请求都需要携带用户的credential来完成操作

小结下使用第二种方案的好处:

除了拥有第一种方案相似的好处外,由于共用了同一个持久化仓库来管理用户信息,简化了原来独立管理的机制

同时,小结下使用这种方案需要注意的地方:

  • 中心化Auth DB会被每次用户请求来访问连接,可能引发AuthDB性能瓶颈
  • 需要在每个服务中实现对共有Auth DB查找用户信息的逻辑

微服务常用访问安全设计方案——API Tokens

第三种,如上示意图所示,使用Token Based协议来对用户请求进行操作鉴权。

简单介绍下最基本的Token Based的交互方式:

  • 用户使用包含用户名和密码的credential从客户端发起资源请求
  • 后端接受请求,通过授权中心,生产有效token字符串,返回给客户端
  • 客户端获得token后,再次发出资源请求
  • 后端接受带token的请求,通过授权中心,获取相关资源,返回给客户端

业界常用的OAuth就是基于Token Based这套逻辑,实现的互联网级的鉴权机制。

第三种方案的特点明显:

使用token来进行鉴权,替换用户本身的用户名和密码,提高了交互安全性 每次用户请求需要携带有效token,与Auth服务进行交互验证

小结下使用第三种方案的好处:

由于使用了token来鉴权,业务服务不会看到用户的敏感信息

同时,小结下使用这种方案需要注意的地方:

Auth服务可能需要处理大量的生产token的操作

微服务常用访问安全设计方案——SAML

第四种,如上示意图所示,使用SAML协议来对用户请求进行操作鉴权。它是一个基于XML的标准,用于在不同的安全域(security domain)之间交换认证和授权数据。在SAML标准定义了身份提供者(identity provider)和服务提供者(service provider),这两者构成了前面所说的不同的安全域。

以上图Google提供的Apps SSO的机制,简单介绍下SAML鉴权的交互方式:

  • 用户请求访问自建的google application
  • 当前application 生成一个 SAML 身份验证请求。SAML 请求将进行编码并嵌入到SSO 服务的网址中。
  • 当前application将重定向发送到用户的浏览器。重定向网址包含应向SSO 服务提交的编码 SAML 身份验证请求。
  • SSO(统一认证中心或叫Identity Provider)解码 SAML 请求,并提取当前application的 ACS(声明客户服务)网址以及用户的目标网址(RelayState 参数)。然后,统一认证中心对用户进行身份验证。
  • 统一认证中心生成一个 SAML 响应,其中包含经过验证的用户的用户名。按照 SAML 2.0 规范,此响应将使用统一认证中心的 DSA/RSA 公钥和私钥进行数字签名。
  • 统一认证中心对 SAML 响应和 RelayState 参数进行编码,并将该信息返回到用户的浏览器。统一认证中心提供了一种机制,以便浏览器可以将该信息转发到当前application ACS。
  • 当前application使用统一认证中心的公钥验证 SAML 响应。如果成功验证该响应,ACS 则会将用户重定向到目标网址。
  • 用户将重定向到目标网址并登录到当前application。

目前SAML在业界也有相当的使用度,包括IBM Weblogic等产品。

第四种方案的特点有:

由Identity Provider提供可信的签名声明 服务的访问安全由可信的Identity Provider提供

小结下使用第四种方案的好处:标准的可信访问模型

同时,小结下使用这种方案需要注意的地方:

基于XML协议,传输相对复杂 对非浏览器客户端适配不方便

四、Spring Cloud Security解决方案

Spring Cloud Security特点有:

  • 基于OAuth2 和OpenID协议的可配置的SSO登录机制
  • 基于tokens保障资源访问安全
  • 引入UAA鉴权服务,UAA是一个Web服务,用于管理账户、Oauth2客户端和用户用于鉴权的问题令牌(Issue Token)。UAA实现了Oauth2授权框架和基于JWT(JSON web tokens)的问题令牌。 下面简单介绍下UAA,事实上,它是由CloudFoundry发起的,也是CloudFoundry平台的身份管理服务(https://docs.cloudfoundry.org/concepts/architecture/uaa.html)。

主要功能是基于OAuth2,当用户访问客户端应用时,生成并发放token给目标客户端。

UAA认证服务包含如下几个方面的内容:

  • 认证对象。如用户、客户端以及目标资源服务器
  • 认证类型。主要有授权码模式、密码模式以及客户端模式
  • 认证范围,即认证权限,并作为一个命名的参数附加到AccessToken上。

接下来,结合实例,一起来看下UAA在Spring Cloud中的实践。 如图所示,这是一个简单的基于Spring Cloud微服务架构的例子,它的主要组件有:

  • Eureka组件提供服务发现功能
  • 独立的Config组件提供类似配置中心的服务,持久化层可以是文件系统,也可是git repository
  • Auth组件提供基于UAA的鉴权服务
  • Account组件保存用户的业务信息 其他组件不一一介绍了

这里主要讲Auth组件和Account组件是如何基于UAA服务进行认证和授权。 图一为Auth组件业务代码中定义了不同客户端的认证类型和认证范围,其中:

浏览器端的认证类型是password,认证范围是ui account组件端的认证类型是client_credentials,认证范围是server

图二为config组件(配置中心)定义的请求路由的规则,其中:

使用/uaa/来转发基于uaa的认证请求至auth组件 使用/accouts/来转发请求至account组件,并标记serviceId为account-service,与图一中的withClient对应。 图一为浏览器打开应用入口后,输入用户名和密码后,发出的认证请求:

认证url为/uaa/oauth/token,这是uaa模式下标准的请求获取token的url 表单中包含了字段scope(认证范围)和字段password(认证类型)

图二为图一发出认证请求的返回结果:

Access_token为有效认证token,将来被其他请求使用

图三为发出获取当前用户的信息的请求:

在请求里的Authorization的值为图二中获得的access_token 图一为Account组件在Config组件(配置中心)定义的OAuth2协议下获取token的方式,这里定义了:

clientID和clientSecret accessTokenUrl,这里指定了auth组件的uaa获取token的url grant-type,即认证类型,这里指定为client_credentials scope,这里指定了server,说明是这个认证请求只适用在各微服务之间的访问。

图二为Accout组件业务代码中定义了需要使用Auth组件进行事先鉴权的方法:

使用@PreAuthorize annotation中可以指定认证范围的具体条件,这里是限定了server或者是demo账户,才有权限发起认证。 最后小结下Spring Cloud Security的特点:

  • 基于UAA,使用OAuth2协议。不会暴露用户的敏感信息
  • 基于认证类型和认证范围,实现细粒度的鉴权机制
  • 非浏览器客户端下良好的操作性

Q&A

问题:Basic Auth + Central Auth DB这种方式中,每个服务有自己的鉴权DB,这块只是一个缓冲吗?如果中途通过别的方式修改了中心DB的数据,而缓冲又没过期,这个时候有什么解决方案吗? 答:不是缓冲,这里的Central Auth DB是指各个微服务共用一个数据库。

问题:微服务架构需要服务路由和服务注册么?跟esb的区别在哪里? 答:服务路由组件和服务注册组件和是相对必要的,他们保证了用户请求能发到正确的微服务中去。ESB企业服务总线是相对比较重的组件,而不是像微服务组件一样只负责单个业务。

问题:在微服务中,对于数据权限的粒度,是可以集中在在gateway中进行还是由每个微服务自己独立配置? 答:推荐由那个专门负载权限的微服务组件来配置。

问题:您好,辛苦了,请问现在有类似SAML协议,但是不基于XML,而是基于JSON或者其他简化格式的协议吗? 答:目前据我所知没有基于JSON的SAML协议。有个叫JWT(JSON web token)的协议,它是完全基于JSON的,Spring Cloud架构中也使用了JWT。

问题:对于这个架构,服务划分的粒度有没有什么好的建议?另外登录凭证保存在客户端如何解决报文被拦截的安全漏洞? 答:服务划分需要按具体业务来说,一般来说,一个业务实体作为一个微服务。使用https可以一定程度上提高安全性。

问题:spring cloud security可以解决token重放攻击么? 答:token重放攻击不是特别了解,可能是数据弱一致性导致的,建议设计尽可能短的过期时间。

问题:我们公司现在在设计DMP,从行业的状况来看,采用了微服务,但是有一点,首先对于应用本身暴露出来的服务,是和应用一起部署的,也就是并非单独的部署,那么业务组件接口暴露部署是否合理呢? 答:业务组件的接口一般可以通过统一网关来管理。也可以对业务接口像spring cloud中设置访问scope限制。

问题:所有暴露的微服务是否需要一个统一的服务管控和治理平台? 答:是的,一般有服务网关和服务发现组件来管理用户请求。

问题:微服务的gateway需要实现底层多个细粒度的API组合的场景,我们现在一部分使用异步,但是遇到了没办法全面的解藕。我想问问,对于此,使用响应式?还是异步回调式?它们的区别点会有哪些呢? 答:使用哪种API方案,其实要看业务。如果后端业务需要强数据一致性,建议使用响应式的。反之,可以使用异步回调或者消息队列。

问题:uaa和netflix zull集成 可行吗?是否做过这方面的尝试? 答:可以。Zuul组件提供网关服务,uaa是基于OAuth2协议,提供授权服务的。微服务架构下,他们是独立的,是可以自由组合的。举个例子,可以在zuul组件的配置文件中,为授权服务(auth-service)组件的指定路由表。可参照:https://gist.github.com/nevermosby/875b9f7b1799a6207832010d6eafcfc3