今天给大家带来的是 数人云工程师文权在高效运维线上群的分享实录。从传统单体应用架构到微服务架构,安全问题一直是人们关注的重点,文权与大家分享了关于微服务访问安全设计方案的探索与实践。
我们首先从传统单体应用架构下的访问安全设计说起,然后分析现代微服务架构下,访问安全涉及的原则,接着讨论目前常用的几种微服务架构下的访问安全设计方案。最后,详析Spring Cloud微服务架构下如何解决访问安全的问题。
1.传统单体应用的访问安全设计
上面的示意图展示了单体应用的访问逻辑。用户通过客户端发出http或者https请求,经过负载均衡后,单体应用收到请求。
接着经过auth层,进行身份验证和权限批准,这里,一般会有跟后端数据库的交互。通过后,将请求分发到对应的功能逻辑层中去。完成相关操作后,返回结果给客户端。
1.1 传统单体应用的访问安全设计——原则
从以上分析可以看到,传统单体应用的访问安全设计原则为:
第一,每次的用户请求都需要验证是否安全,这里可以分两种情况:
一种是没有session的请求,需要经过几个步骤完成session化。一般为验证当前用户的credential,获取当前用户的identity,这两步都需要访问数据库等持久化对象来完成,最后一步是为当前可用创建session,返回给客户端后,启用该session。
另一种是有session的请求,只需验证请求中当前session的有效性,即可继续请求。
第二,用户的操作请求都在后端单个进程中执行完成,完全依赖后端调用方法的可靠性。一旦出错,应用是无法再次重复请求。
1.2 传统单体应用的访问安全设计——优势和注意点
传统单体应用由于设计相对简单单一,暴露给外界的入口相对较少,从而具有被攻击并造成危害性的可能小的优势。
也正是由于单体应用简单单一的特点,需要注意相关问题:
应用后端保存了所有的credential等敏感信息
一旦入侵了对这个应用的请求,就有可能拿到所有的保存在后端的信息
应用的每次操作一般都需要和数据库进行交互,造成数据库负载变高
2.微服务架构下,访问安全设计原则
来看下这张典型的微服务设计架构图,如图所示,有以下几点特征:
- 每个服务只有权限去操作自己负责的那部分功能。
- 用户请求的身份验证和权限批准都由独立的gateway服务来保障
- 对外服务的LB层无法直接与提供业务服务的应用层进行访问
从上面的特征分析来看,想要给出一份访问安全设计的原则说明,就要看看微服务架构下,访问安全有哪些痛点,以下罗列了几点:
- 单点登录,即在微服务这种多独立服务的架构下,实现用户只需要登录一次就能访问所有相互信任的应用系统
- 微服务架构下的应用一般都是无状态的,导致用户的请求每次都需要鉴权,可能引发Auth服务的性能瓶颈
- 微服务架构下,每个组件都管理着各自的功能权限,这种细粒度的鉴权机制需要事先良好的规划
- 微服务架构下,需要考虑到那些非浏览器端的客户请求,是否具有良好的可操作性
根据实际情况,还有一些其他痛点,这里不再一一赘述,而这些痛点,就形成了我们在为微服务架构设计访问安全的原则。
3.微服务架构下,常用的访问安全设计方案
- 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的一种协议,企业内使用得较多。
下面一一做介绍。
3.1 微服务常用访问安全设计方案——Basic Auth + Independent Auth DB
一种,如上示意图所示,使用Basic Auth协议,配合每个服务自己都拥有存储Credential敏感数据的数据库(或者其他持久化仓库)。
简单介绍下Basic Auth协议,它是在用户的请求中添加一个Authorization消息头,这个消息头的值是一个固定格式:Basic base64encode(username+“:”+password)
完整的消息头列子为:Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Basic Auth协议基本上被所有流行的
网页浏览器都支持。
这种方案的特点:
1.每个提供功能的服务都拥有自己独立的鉴权和授权机制
2.每个提供功能的服务都拥有自己独立的数据库,来保存敏感信息
3.每次用户请求都需要携带用户的credential来完成操作
小结下使用这种方案的好处:1.微服务的应用可以实现100%无状态化
2.基于Basic Auth开发简单
同时,小结下使用这种方案需要注意的地方:
由于每个服务都有自己存储credential的机制,需要事先为每个服务设计好如何存储和查找用户的Credential由于每次用户请求都会携带用户的Credential,需要事先设计好如何管理鉴权机制。
3.2微服务常用访问安全设计方案——Basic Auth + Central Auth DB
二种,如上示意图所示,使用Basic Auth协议,与第一种方案相比,每个服务共用有同一个Auth DB。
第二种方案的特点和第一种很相似:
1.每个提供功能的服务都拥有自己独立的鉴权和授权机制
2.每个提供功能的服务共用同一个DB,来保存Credential等敏感信息
3.每次用户请求都需要携带用户的credential来完成操作
小结下使用第二种方案的好处:
除了拥有第一种方案相似的好处外,由于共用了同一个持久化仓库来管理用户信息,简化了原来独立管理的机制
同时,小结下使用这种方案需要注意的地方:
1.中心化Auth DB会被每次用户请求来访问连接,可能引发AuthDB性能瓶颈
2.需要在每个服务中实现对共有Auth DB查找用户信息的逻辑
3.3微服务常用访问安全设计方案——API Tokens
第三种,如上示意图所示,使用Token Based协议来对用户请求进行操作鉴权。
简单介绍下最基本的Token Based的交互方式:
1.用户使用包含用户名和密码的credential从客户端发起资源请求
2.后端接受请求,通过授权中心,生产有效token字符串,返回给客户端
3.客户端获得token后,再次发出资源请求
4.后端接受带token的请求,通过授权中心,获取相关资源,返回给客户端
业界常用的OAuth就是基于Token Based这套逻辑,实现的互联网级的鉴权机制。
第三种方案的特点明显:
使用token来进行鉴权,替换用户本身的用户名和密码,提高了交互安全性每次用户请求需要携带有效token,与Auth服务进行交互验证
小结下使用第三种方案的好处:
由于使用了token来鉴权,业务服务不会看到用户的敏感信息
同时,小结下使用这种方案需要注意的地方:
Auth服务可能需要处理大量的生产token的操作3.4微服务常用访问安全设计方案——SAML
第四种,如上示意图所示,使用SAML协议来对用户请求进行操作鉴权。它是一个基于XML的标准,用于在不同的安全域(security domain)之间交换认证和授权数据。在SAML标准定义了身份提供者(identity provider)和服务提供者(service provider),这两者构成了前面所说的不同的安全域。
以上图Google提供的Apps SSO的机制,简单介绍下SAML鉴权的交互方式:
1.用户请求访问自建的google application
2.当前application 生成一个 SAML 身份验证请求。SAML 请求将进行编码并嵌入到SSO 服务的网址中。
3.当前application将重定向发送到用户的浏览器。重定向网址包含应向SSO 服务提交的编码 SAML 身份验证请求。
4.SSO(统一认证中心或叫Identity Provider)解码 SAML 请求,并提取当前application的 ACS(声明客户服务)网址以及用户的目标网址(RelayState 参数)。然后,统一认证中心对用户进行身份验证。
统一认证中心生成一个 SAML 响应,其中包含经过验证的用户的用户名。按照 SAML 2.0 规范,此响应将使用统一认证中心的 DSA/RSA 公钥和私钥进行数字签名。
5.统一认证中心对 SAML 响应和 RelayState 参数进行编码,并将该信息返回到用户的浏览器。统一认证中心提供了一种机制,以便浏览器可以将该信息转发到当前application ACS。
当前application使用统一认证中心的公钥验证 SAML 响应。如果成功验证该响应,ACS 则会将用户重定向到目标网址。
6.用户将重定向到目标网址并登录到当前application。
目前SAML在业界也有相当的使用度,包括IBM Weblogic等产品。
第四种方案的特点有:
由Identity Provider提供可信的签名声明服务的访问安全由可信的Identity Provider提供
小结下使用第四种方案的好处:标准的可信访问模型
同时,小结下使用这种方案需要注意的地方:
基于XML协议,传输相对复杂对非浏览器客户端适配不方便。
4.Spring Cloud Security解决方案
Spring Cloud Security特点有:
1.基于OAuth2 和OpenID协议的可配置的SSO登录机制
2.基于tokens保障资源访问安全
3.引入UAA鉴权服务,UAA是一个Web服务,用于管理账户、Oauth2客户端和用户用于鉴权的问题令牌(Issue Token)。UAA实现了Oauth2授权框架和基于JWT(JSON web tokens)的问题令牌。
下面简单介绍下UAA,事实上,它是由CloudFoundry发起的,也是CloudFoundry平台的身份管理服务(
https://docs.cloudfoundry.org…)。
主要功能是基于OAuth2,当用户访问客户端应用时,生成并发放token给目标客户端。
UAA认证服务包含如下几个方面的内容:
1.认证对象。如用户、客户端以及目标资源服务器
2.认证类型。主要有授权码模式、密码模式以及客户端模式
3.认证范围,即认证权限,并作为一个命名的参数附加到AccessToken上。
接下来,结合实例,一起来看下UAA在Spring Cloud中的实践。
如图所示,这是一个简单的基于Spring Cloud微服务架构的例子,它的主要组件有:
1.Eureka组件提供服务发现功能
2.独立的Config组件提供类似配置中心的服务,持久化层可以是文件系统,也可是git repository
3.Auth组件提供基于UAA的鉴权服务
4.Account组件保存用户的业务信息 其他组件不一一介绍了
这里主要讲Auth组件和Account组件是如何基于UAA服务进行认证和授权。
一为Auth组件业务代码中定义了不同客户端的认证类型和认证范围,其中:
浏览器端的认证类型是password,认证范围是uiaccount组件端的认证类型是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协议。不会暴露用户的敏感信息
- 基于认证类型和认证范围,实现细粒度的鉴权机制
- 非浏览器客户端下良好的操作性
5.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
来源:数人云