百度技术架构师总结：微服务架构之访问安全 _微服务架构

来源：不止思考应用程序的访问安全又是我们每一个研发团队都必须关注的重点问题。尤其是在我们采用了微服务架构之后，项目的复杂度提升了N个级别，相应的，微服务的安全工作也就更难更复杂了。并且我们以往擅长的单体应用的安全方案对于微服务来说已经不再适用了。我们必须有一套新的方案来保障微服务架构的安全。
在探索微服务访问安全之前，我们还是先来回顾一下单体应用的安全是如何实现的。
一、传统单体应用如何实现「访问安全」？
下图就是一个传统单体应用的访问示意图：

文章插图

（图片来自WillTran在slideshare分享）
在应用服务器里面，我们有一个auth模块（一般采用过滤来实现），当有客户端请求进来时，所有的请求都必须首先经过这个auth来做身份验证，验证通过后，才将请求发到后面的业务逻辑。
【百度技术架构师总结：微服务架构之访问安全】通常客户端在第一次请求的时候会带上身份校验信息（用户名和密码）， auth模块在验证信息无误后，就会返回Cookie存到客户端，之后每次客户端只需要在请求中携带Cookie来访问，而auth模块也只需要校验Cookie的合法性后决定是否放行。
可见，在传统单体应用中的安全架构还是蛮简单的，对外也只有一个入口，通过auth校验后，内部的用户信息都是内存/线程传递，逻辑并不是复杂，所以风险也在可控范围内。
那么，当我们的项目改为微服务之后，「访问安全」又该怎么做呢。
二、微服务如何实现「访问安全」？
在微服务架构下，有以下三种方案可以选择，当然，用的最多的肯定还是OAuth模式。

网关鉴权模式（API Gateway）
服务自主鉴权模式
API Token模式（OAuth2.0）

下面分别来讲一下这三种模式：

网关鉴权模式（API Gateway）

文章插图

（图片来自WillTran在slideshare分享）
通过上图可见，因为在微服务的最前端一般会有一个API网关模块（API Gateway），所有的外部请求访问微服务集群时，都会首先通过这个API Gateway ，所以我们可以在这个模块里部署auth逻辑，实现统一集中鉴权，鉴权通过后，再把请求转发给后端各个服务。
这种模式的优点就是，由API Gateway集中处理了鉴权的逻辑，使得后端各微服务节点自身逻辑就简单了，只需要关注业务逻辑，无需关注安全性事宜。
这个模式的问题就是， API Gateway适用于身份验证和简单的路径授权（基于URL的），对于复杂数据/角色的授权访问权限，通过API Gateway很难去灵活的控制，毕竟这些逻辑都是存在后端服务上的，并非存储在API Gateway里。
服务自主鉴权模式