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

随着计算机和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应用程序使用将会话状态保存在服务器端以供用户登录访问的方案. 用户请求通常使用“粘性”会话或“复制”会话策略来维护客户端和服务器之间的会话.

对于会话共享，必须将会话信息写入公共缓存或，从而导致微服务应用程序之间的耦合. 不建议在微服务架构中将会话保存在服务器端. 如果不需要状态管理，则应用程序应保持无状态运行. 建议使用基于访问令牌的另一种模式. 在这种模式下，应用程序不需要保存会话状态，并且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客户端，例如批处理调度系统，物联网设备程序等，这些客户端通常无需用户登录授权即可自动运行. 使用客户端证书权限类型更合适.

上面的客户端凭据是OAuth2.0规范的标准流程图. 结合此方案（对应于OAuth2.0中的角色），API客户端充当OAuth2.0客户端，而IAM是授权服务器. 其他说明:

此类应用程序通常没有与用户交互的UI，不需要用户授权，并且能够确保客户端凭据的安全性

此类应用程序的后端需要具有通过https访问授权服务器的能力

此类应用程序或设备需要具有存储访问令牌的能力

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

2.2.1 Web应用程序OAuth2.0协议提出，前端单页Web应用程序可以使用简单权限模型，但是简单权限模型有一些限制. 令牌已过期，您需要再次登录以进行授权. 不支持令牌刷新. 用户体验很差. 许多使用简单授权的应用程序将发行几天甚至几周的长期令牌，以改善用户体验. 如果有条件地使用授权码模式，则支持刷新令牌是一个更好的选择. 对于短至2分钟的访问令牌和刷新令牌是一次性令牌，有效期略长于30分钟. 如果请求使用无效的刷新令牌来交换访问令牌，则授权端点还可以及时发现入侵处理，例如取消用户的所有刷新令牌. 在保持良好的用户体验的同时，还考虑了一些安全性.

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

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

为了维护前端会话，访问令牌作为响应将由网关返回到前端，并存储在前端存储空间中，例如cookie，本地存储和会话存储.

访问令牌失效后，网关根据其客户端凭证+刷新令牌发送授权服务器，获取新的访问令牌和刷新令牌，并返回响应令牌，将访问令牌写给用户浏览存储

在授权码模式下，用户的凭据（用户名，密码）是用户通过浏览器与授权服务的交互，而无需通过网关，因此安全性是最高的.

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

用于移动应用程序以实现登录重定向的授权代码通常可以通过以下方式完成: 移动应用程序的操作环境不受信任，并且容易受到恶意应用程序入侵的威胁，包括以下两种情况:

在重定向过程中，回调URL参数很容易被恶意应用用来拦截URL方案或在localhost端口上侦听.

操作环境不可靠. 该移动应用程序无法安全存储客户端密钥，并且在使用授权码获取访问令牌时需要验证客户端密钥.

基于上述风险和问题，需要优化和解决基于移动应用授权码获取访问令牌的过程. 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入口. 当面对外部网络的访问者时，网关仍然是内部和外部网络之间的边界. 访问令牌验证应由网关负责. 服务供应商. 网关负责验证，这不仅可以防止未经身份验证的请求进入Intranet，而且可以简化服务提供商的代码. 服务提供商不需要处理不同类型客户的验证. 实际上，益处不限于这些. 流量控制可以在网关中统一，而无需在应用程序侧重复类似功能的构造. 系统的内部调试和更改非常灵活，从而减少了跨组织的交互. 网关验证访问令牌有两种方案: 网关委托的身份验证服务验证和网关直接验证. 说明如下:

网关委托IAM验证令牌

客户端成功通过身份验证后，使用UUID类型访问令牌在网关上调用服务

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