从五个方面入手，保障微服务应用安全

随着计算机、互联网技术的飞速发展，信息安全已然是一个全民关心的问题，也是各大企业非常重视的问题。企业一般会从多个层次着手保障信息安全，如：物理安全、网络安全、系统安全(主机和操作系统)、应用安全等。

对于应用程序安全，需要在应用架构、代码、运维、管理等多个角度进行安全性评估，在整个应用程序生命周期中，软件工程师们则主要负责身份验证、访问授权、进程间通信安全、代码安全、安全的管理与审计这五方面的方案落地。这五个方面中，前三个侧重于技术实现，代码安全、管理与审计则更需要规范的管理和执行，本文将着重对认证、授权、通信等技术相关内容重点介绍，管理规范相关内容仅做简单说明。

文中以采用了微服务架构的应用程序为背景进行描述，但多数的应用程序的安全方案与是否采用微服务架构并没有强关联，如有差异的地方，文中会提出来。文中描述过程中会涉及到一些微服务架构中相关的概念名词，说明如下：

微服务架构中安全访问相关的简化版的运行视图如下：

运行视图

图中星号*标注的位置就是服务调用过程中安全访问过程中的一些需要认证鉴权的关键位置，如：内外部访问认证、令牌验证与授权、内外网通信协议等。后续章节将对这部分展开分析。

1.身份认证

多数业务功能类的应用的首要任务就是需要做身份认证。对于数据公开或新闻发布类的门户网站类应用不需要考虑这一点，他们更关注的是数据开放之前的管理和审批。

身份认证或身份验证(Authentication)，顾名思义就是对应用程序的"访问者"的身份进行验证识别。访问者分两类。

• 基于用户登录的客户端(Login-based Client)：用户访问服务提供者的应用程序的功能时，需要通过一个客户端交互界面来与服务提供者交互，用户需要先登录，然后由客户端代表用户身份去访问服务提供者应用程序。
• API 客户端(API Client)：客户端程序类型的访问者，这类客户端自身具备部分API的访问权限，不需要用户授予其访问权限。

1. 使用认证管理系统IAM进行访问者注册认证

不论是用户还是API客户端，在访问应用之前，均需要先到认证管理系统IAM进行注册，以创建其的身份凭证(用户账号和密码、客户端ID和密码)。有了身份凭证，才能通过认证服务的验证。

统一认证管理系统IAM(Identity and Access Management )负责身份识别和访问管理，其核心业务是应用系统的访问者的注册、账号密码凭证、访问者基本信息的管理、对已注册的访问者进行合法性认证和访问的初级授权(获取访问者自身数据)等等。

有些企业还会将组织机构、角色甚至业务功能权限数据也一并归入IAM系统管理。IAM对权限管理范围可大可小，不同企业的管理需求和力度也不一样，需要集中进行功能授权管理还是下放到业务系统中自治各有优缺点，选择合适自己的方式就好。

2. IAM认证管理系统使用OAuth2.0进行访问者授权

传统WEB应用对于用户登录访问，采用会话状态在服务端保存的方案，用户请求通常采用会话粘滞(Sticky session)或会话复制(Replication session)策略，来保持客户端和服务端的会话。为了会话共享而不得不将会话信息写入公共缓存或数据库，导致微服务应用之间产生了耦合性。

微服务架构中不推荐采用服务端保存会话的方式，如果引入状态管理不是必要的，那么应用尽量保持无状态运行。推荐使用另外一种基于访问令牌的模式，这种模式下应用中不需要保存会话状态，并且API客户端和基于登录的客户端均方便使用访问令牌。微服务架构推荐使用OAuth2.0 授权协议来搭建IAM系统。Spring 体系可以基于Spring Security OAuth实现授权服务器和客户端。

在本文的上下文中，面向的是企业基于微服务的总体架构进行方案设计，企业整体架构中，默认认证体系方案为企业统一认证而非业务系统各自认证(此方案的前提条件)。OAuth2.0本身是为三方授权而设计的，而在本方案中讨论的是企业内部应用的整体认证和授权，不存在第三方。因此本方案中基于OAuth2.0实现的授权服务可以简单理解为仅为IAM统一认证管理系统中的“账号管理应用资源提供者”做授权，并且默认实现为认证通过自动授予已登录账号数据的读写权限，不在登录通过后与用户交互确认是否同意授权。其他业务系统作为资源提供者的授权则是系统管理员预置好的授权，也不需要由用户登录时决定是否授权。这个OAuth2.0的使用场景可能与其他OAuth2.0相关资料或授权框架默认实现有所不同，请大家注意区分。

OAuth协议中定义了四种角色：

• 资源所有者

能够许可对受保护资源的访问权限的实体。当资源所有者是个人时，它被称为最终用户。

• 资源服务器

托管受保护资源的服务器，能够接收和响应使用访问令牌对受保护资源的请求。

• 客户端

使用资源所有者的授权代表资源所有者发起对受保护资源的请求的应用程序。术语“客户端”并非特指任何特定的的实现特点(例如：应用程序是否是在服务器、台式机或其他设备上执行)。

• 授权服务器

在成功验证资源所有者且获得授权后颁发访问令牌给客户端的服务器。

角色分析：

• 对于前面提到的API 客户端，自身具备API访问权，不需要用户授权，因此在OAuth角色对应时，它既是客户端又是资源所有者。
• 微服务架构中Web应用一般采用前后端分离的模式，前端为基于浏览器访问的纯前端应用，网关作为应用程序的入口，此时网关本身可以代表OAuth中的客户端身份访问服务提供端应用的功能接口。
• 在微服务架构中，负责颁发访问令牌的授权服务通常在IAM系统中实现
• 资源服务器，在微服务架构中，所有的业务系统中的服务功能提供者都是资源服务器，也包括IAM系统的账号、组织机构服务、资源权限管理服务等等

在OAuth2.0授权协议中，主要定义了四种许可类型：授权码许可、简单许可、密码凭据许可和客户端凭据许可，详细请参见规范内容：rfc6749 - The OAuth 2.0 Authorization Framework

(https://tools.ietf.org/html/rfc6749)

下面我们根据访问者类型，分别推荐合适的授权方案。

2.1 API客户端作为访问者，使用客户端凭证许可

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!