微服务访问安全设计方案尝试

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

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

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

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

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

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

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

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

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

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

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

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

应用后端保存了所有的credential等敏感信息

一旦入侵了对这个应用的请求，就有可能拿到所有的保存在后端的信息

应用的每次操作一般都需要和数据库进行交互，造成数据库负载变高

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

每个服务只有权限去操作自己负责的那部分功能。

用户请求的身份验证和权限批准都由独立的gateway服务来保障

对外服务的LB层无法直接与提供业务服务的应用层进行访问
单点登录，即在微服务这种多独立服务的架构下，实现用户只需要登录一次就能访问所有相互信任的应用系统
微服务架构下的应用一般都是无状态的，导致用户的请求每次都需要鉴权，可能引发Auth服务的性能瓶颈
微服务架构下，每个组件都管理着各自的功能权限，这种细粒度的鉴权机制需要事先良好的规划
微服务架构下，需要考虑到那些非浏览器端的客户请求，是否具有良好的可操作性
根据实际情况，还有一些其他痛点，这里不再一一赘述，而这些痛点，就形成了我们在为微服务架构设计访问安全的原则。

微服务常用访问安全设计方案——API Tokens
简单介绍下最基本的Token Based的交互方式：

使用token来进行鉴权，替换用户本身的用户名和密码，提高了交互安全性

每次用户请求需要携带有效token，与Auth服务进行交互验证

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

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

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

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