建议|从五个方面入手，以确保微服务应用程序的安全性

由OSCAR会员单位普元科技推动

随着计算机和Internet技术的飞速发展，信息安全已经成为所有人关注的问题，也是大企业高度重视的问题. 企业通常开始从多个级别确保信息安全，例如: 物理安全，网络安全，系统安全（主机和操作系统），应用程序安全等.

对于应用程序安全性，需要从多个角度进行安全性评估，例如应用程序体系结构，代码，操作，维护和管理. 在整个应用程序生命周期中，软件工程师主要负责身份验证，访问授权和进程间交互. 实现了通信安全，代码安全，安全管理和审核的五个方面. 在这五个方面中，前三个集中在技术实施上，并且代码安全性，管理和审计要求更标准化的管理和执行. 本文将重点介绍认证，授权和通信以及其他技术内容. 与管理相关的内容仅作简要说明.

本文介绍了以微服务体系结构为背景的应用程序，但是大多数应用程序的安全性方案与是否采用微服务体系结构并不紧密相关. 如果存在差异，将在本文中提出. 描述过程将涉及微服务体系结构中的一些相关概念术语，其解释如下:

术语解释

是一个应用程序，本文专门针对微服务应用程序

业务系统

这是传统的软件系统，例如: OA办公系统，个人借贷系统等. 在微服务体系结构中，业务系统不是业务逻辑概念. 一个业务系统由一个或多个应用程序（微服务）组成.

也就是说，API网关是客户端访问应用程序的入口，而API门户是后端应用程序的入口. 通常负责身份验证，API管理，路由，编排等.

是API，专门指程序接口. 如果服务调用是API调用. 应该注意的是，在本文中，请勿将其与微服务，应用程序等的概念相混淆.

认证管理系统

身份验证管理系统（IAM），负责身份识别和访问管理. 它的核心业务是对应用程序系统的访客进行注册，帐户密码凭据，访客的基本信息管理以及注册访客的合法性验证和访问授权.

授权服务

是指身份认证和授权服务. 在微服务架构中，它通常是身份验证管理系统（IAM）的应用程序. 认证中心有权读取“访客”的身份信息. 负责验证“访问者”的身份，为访问者，访问令牌和其他功能发布授权代码

在安全性字段中通常称为“主体”，它是指应用程序功能UI或API的用户，包括两类: 1.基于登录的客户端2. API客户端

API客户端

API客户端是客户端程序类型的访问者. 这种客户端本身具有对某些API的访问权限，并且不需要用户向他们授予访问权限.

基于登录的客户端

基于登录的客户端，当用户访问服务提供商的应用程序的功能时，他们需要通过客户端交互界面与服务提供商进行交互. 用户需要先登录，然后客户端才能代表用户访问服务提供商. 应用程序.

与微服务体系结构中的安全访问相关的简化版本的操作视图如下:

运行视图

图中标有星号*的位置是在服务调用期间安全访问过程中需要认证和身份验证的关键位置，例如内部和外部访问身份验证，令牌验证和授权以及内部和外部网络通信协议. 随后的章节将对此部分进行分析.

1. 身份认证

大多数业务功能应用程序的主要任务是进行身份认证. 诸如数据公开或新闻发布之类的门户应用程序无需考虑这一点，它们在打开数据之前更加关注管理和批准.

顾名思义，

身份验证或身份验证（Authentication）用于验证应用程序“访问者”的身份. 访客有两种类型.

1. 使用身份验证管理系统IAM进行访客注册身份验证

无论是用户还是API客户端，在访问应用程序之前，都必须向IAM身份验证管理系统注册以创建其身份凭证（用户帐户和密码，客户端ID和密码）. 使用身份凭证，可以由身份验证服务对其进行验证.

统一身份验证管理系统IAM（身份和访问管理）负责身份识别和访问管理. 它的核心业务是对应用程序系统的访客进行注册，帐户密码凭据，访客基本信息的管理以及注册访客的注册. 执行合法性认证和访问的主要授权（获取访问者自己的数据）等.

一些公司还将组织，角色甚至业务功能许可数据包括到IAM系统管理中. IAM的权限管理范围可以大小，并且不同的公司具有不同的管理需求和优势. 有必要集中功能授权管理或分散到业务系统. 自治有其自身的优点和缺点. 只需选择自己的方式即可.

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

传统的WEB应用程序使用将会话状态保存在服务器端以供用户登录和访问的方案. 用户请求通常使用会话粘性（Sticky会话）或会话复制（Replication会话）策略来维护客户端-服务器会话. 为了进行会话共享，必须将会话信息写入公共缓存或，从而导致微服务应用程序之间的耦合.

在微服务架构中，建议不要使用服务器保存会话. 如果不需要引入状态管理，则应用程序应尝试保持无状态运行. 建议使用基于访问令牌的另一种模式. 在这种模式下，应用程序不需要保存会话状态，并且API客户端和基于登录的客户端都可以方便地使用访问令牌. 微服务架构建议使用OAuth2.0授权协议来构建IAM系统. Spring系统可以基于Spring Security OAuth实现授权服务器和客户端.

在本文的上下文中，它面向基于微服务的整体体系结构的企业设计. 在企业的总体体系结构中微服务之间调用安全，默认的身份验证系统方案是企业统一身份验证，而不是业务系统的单独身份验证（此方案的前提）. OAuth2.0本身是为三方授权而设计的，并且在此解决方案中讨论了企业内部应用程序的整体身份验证和授权，并且没有第三方. 因此，在该解决方案中基于OAuth2.0的授权服务可以简单地理解为在IAM统一身份验证管理系统中仅授权“帐户管理应用程序资源提供者”，默认是通过自动授予读取权限来实现身份验证登录的帐户数据具有“写”权限，登录后请勿与用户互动以确认是否同意授权. 其他业务系统作为资源提供者的授权是系统管理员预先设置的授权，不需要用户决定登录时是否进行授权. 此OAuth2.0使用场景可能与其他OAuth2.0相关材料或授权框架默认情况下，请注意区分.

在OAuth协议中定义了四个角色:

字符分析:

在OAuth2.0授权协议中，主要定义了四种类型的权限: 授权代码权限，简单权限，密码凭证权限和客户端凭证权限，请参阅规范内容以了解详细信息: rfc6749-OAuth 2.0授权框架

（）

在这里，我们根据访问者的类型推荐适当的授权方案.

2.1使用客户端证书权限的访客作为API客户端

典型的API客户端（例如批处理调度系统，IoT设备程序等）通常在没有用户登录授权的情况下自动运行. 使用客户端证书权限类型更为合适.

客户凭证

上图是OAuth2.0规范的标准流程图. 在这种情况下，与OAuth2.0中的角色相对应，API客户端是OAuth2.0客户端，IAM是授权服务器.

其他说明:

此类应用程序通常没有与用户交互的UI，不需要用户授权，并且能够确保客户端凭据的安全性. 此类应用程序后端需要具有通过https访问授权服务器的能力. 此类应用程序或设备需要具有存储访问权限. 令牌功能

2.2以访问者身份登录的客户端，使用授权码权限

2.2.1 Web应用程序

OAuth2.0协议建议前端单页Web应用程序可以使用简单权限模型，但是简单权限模型有一些限制. 令牌已过期，需要重新登录授权. 它不支持令牌刷新，并且用户体验差. 为了改善用户体验，许多使用简单授权的应用程序会发布几天甚至几周的长期令牌.

如果有条件地使用授权码模式，则支持刷新令牌是更好的选择. 对于短至2分钟的访问令牌和刷新令牌是一次性令牌，有效期略长于30分钟. 如果请求无效的刷新令牌来交换访问令牌，那么授权端点也可以及时找出进行相应的入侵处理的过程，例如取消用户的所有刷新令牌. 在保持良好的用户体验的同时，还考虑了一些安全性.

此方案以微服务体系结构中常见的前端和后端分离的Web应用程序为例. 前端是一个单页应用程序，而作为Web背景的网关是服务提供者的服务应用程序应用程序入口. Web应用程序可以使用网关来实现授权代码交换. 因此，在微服务体系结构中，即使是具有纯前端单页应用程序的Web应用程序仍可以使用基于网关交互的授权代码模式来获取访问令牌. 没有从前端到后端分离的其他混合Web应用程序是客户端本身，不需要网关交换访问令牌.

授权码

上图是OAuth2.0规范的标准流程图. 组合此方案对应于OAuth2.0中的角色，用户是资源所有者，浏览器是用户代理，网关是授权的客户端，IAM是授权的服务器.

其他说明:

为了维护前端会话，访问令牌作为响应将网关返回到前端，并存储在前端存储空间（例如cookie，本地存储和会话存储）中. 访问令牌无效后，网关根据其客户端凭证+刷新令牌发送授权服务器，获取新的访问令牌和刷新令牌，然后将响应令牌返回到用户浏览器的存储中. 模式，用户的凭据（用户名，密码）是用户通过浏览器与授权服务的交互，而无需通过网关，因此安全性是最好的.

2.2.2移动应用

安装在个人移动设备上的本机应用程序具有实施授权代码过程的能力，并且不需要网关即可实施授权代码过程. 进行身份验证后，网关仅负责验证访问令牌.

授权码

实现登录重定向的移动应用通常可以采用以下方法:

移动应用程序的操作环境不受信任，并且容易受到恶意应用程序入侵的风险，包括以下两种情况:

重定向过程中的回调URL参数很容易被恶意应用用来拦截URL方案或拦截本地主机端口. 操作环境不可靠. 该移动应用程序无法安全存储客户端密钥，并且在使用授权码获取访问令牌时需要验证客户端密钥.

基于上述风险和问题，需要优化和解决基于移动应用授权码获取访问令牌的过程. rfc规范中建议的实现解决方案是，移动应用授权过程使用具有PKCE支持的授权代码模型. PKCE，用于代码交换的证明密钥的全名，用于保护授权码授权. 实际上，这是通过一种加密方法来确保的，即使恶意第三方截获了授权码或其他密钥，也无法与身份验证服务器交换访问令牌.

PKCE改进的授权码和访问令牌交换过程如下:

PKCE

上图显示了在PKCE模式下申请授权码和交换访问令牌的过程，解释如下:

第三方无法从code_challenge导出code_verifier，因为code_challenge使用不可逆加密. 只有移动应用客户端知道这两个值. 因此，即使恶意应用拦截了code_challenge和授权代码，它也不能交换访问令牌以避免安全问题. 要为移动应用程序实现此PKCE授权代码模型，除了移动应用程序本身之外，还需要基于标准授权代码流程扩展来扩展和实现IAM的授权服务器.

有关移动应用安全认证的详细信息，请参阅官方规范

2.3高度受信任的特权客户端微服务之间调用安全，可以使用资源所有者的密码凭据进行许可

用户密码凭据

上图是OAuth2.0规范的标准流程图. 在这种情况下，与OAuth2.0中的角色相对应，用户是资源所有者，特权应用程序是客户端，而IAM提供授权服务器

其他说明:

3. 将API网关用作业务系统访问入口，负责验证访问令牌

访问者可以访问的接口通常有两种: 身份验证API和应用程序功能API.

用户登录身份验证是IAM授权服务器与用户资源服务合作的职责. 成功认证后，IAM访问者会发出访问令牌. 在随后的对应用程序功能的访问中，必须携带所有访问令牌以指示访问者的身份.

3.1客户端负责客户端身份验证

网关是业务系统的API入口. 当面对外部网络的访问者时，网关仍然是内部和外部网络之间的边界. 访问令牌验证应由网关负责. 令牌验证不应移交给服务提供商. 网关负责验证，这不仅可以防止未经身份验证的请求进入内部网，而且可以简化服务提供商的代码. 服务提供商不需要处理不同类型客户的验证. 实际上，益处不限于此. 流量控制可以在网关中统一，而无需在应用程序侧重复类似功能的构造；系统的内部调试和更改十分灵活，从而减少了跨组织的交互.

网关验证访问令牌有两个选项: 网关委托的身份验证服务验证和网关直接验证. 说明如下:

网关委托IAM验证令牌

客户端成功通过身份验证后，使用UUID类型访问令牌在网关上调用服务. 由于UUID类型令牌不包含客户的信息，因此网关需要委托IAM身份验证服务来验证令牌令牌是合法的，并且将请求令牌，即使路由到服务提供商应用程序时也无法解析. 您需要基于UUID令牌从IAM获取用户信息

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-189144-1.html