如何在微服务架构中实现安全性？

简介: 网络安全已成为每个企业面临的关键问题. 几乎每天都有关于黑客如何窃取公司数据的头条新闻. 为了开发安全的软件并远离头条新闻，公司需要解决各种安全问题，包括硬件的物理安全性，传输和静态数据的加密，身份验证，访问授权以及修补软件漏洞的策略等. 无论您使用的是单片架构还是微服务架构，大多数问题都是相同的. 本文重点介绍微服务架构如何影响应用程序级安全.

应用程序开发人员主要负责实现安全的四个不同方面:

■身份验证: 验证应用程序或尝试访问该应用程序的人的身份（称为主体的安全术语）. 例如，应用程序通常会验证访问凭据，例如用户的ID和密码，或应用程序的API密钥.

■访问授权: 验证是否允许访问主体对指定数据完成请求的操作. 应用程序通常结合使用基于角色的安全性和访问控制列表（ACL）. 基于角色的安全性为每个用户分配一个或多个角色，并授予他们调用特定操作的权限. ACL授予用户或角色对特定业务对象或聚合执行操作的权限.

■审核: 跟踪用户在应用程序中执行的所有操作，以检测安全问题并帮助客户实现并强制遵守法规.

■安全的进程间通信: 理想情况下，应使用传输层安全性（TLS）对服务内外的所有通信进行加密. 服务之间的通信甚至可能需要使用身份验证.

下面将重点介绍如何实现身份验证和访问授权. 有关审核和安全的进程间通信的更多详细信息，请参阅Chris Richardson的“微服务体系结构设计模式”.

我首先描述如何在FTGO整体应用程序中实现安全性. 然后介绍在微服务体系结构中实现安全性的挑战，以及为什么在单片体系结构中运行良好的技术为何不能在微服务体系结构中使用. 之后，我将介绍如何在微服务架构中实现安全性.

让我们首先回顾FTGO整体应用程序如何处理安全性.

FTGO应用具有多个用户，包括消费者，食品配送人员和饭店员工. 他们使用基于浏览器的Web应用程序和移动应用程序访问FTGO. 所有FTGO用户都必须登录才能访问该应用程序. 图1显示了整体FTGO应用程序的客户端如何验证和发出请求.

图1 FTGO应用程序的客户首先登录以获得会话令牌，该令牌通常是cookie. 客户端在对FTGO应用程序的每个后续请求中都包含会话令牌

当用户使用其用户ID和密码登录时，客户端会将包含用户凭据的POST请求发送到FTGO应用程序. FTGO应用程序验证凭据并将会话令牌返回给客户端. 客户端在FTGO应用程序的每个后续请求中都包含一个会话令牌.

图2显示了FTGO应用程序如何实现安全性. FTGO应用程序是用Java编写的，并且使用Spring Security框架，但是我将使用通用术语，这些术语也适用于其他框架（例如Passport for Node.js）来描述此设计.

图2当FTGO应用程序的客户端发出登录请求时，登录处理程序对用户进行身份验证，初始化会话用户信息，然后返回会话令牌cookie以安全地标识会话. 接下来，当客户端发送包含会话令牌的请求时，SessionBasedSecurityInterceptor从指定的会话中检索用户信息并建立安全上下文. 请求处理程序（例如OrderDetailsRequestHandler）从安全上下文中检索用户信息

使用安全框架

实施身份验证和访问授权具有挑战性. 最好使用经过验证的安全框架. 使用哪种框架取决于您应用程序的技术堆栈. 流行的框架包括:

■SpringSecurity（）: Java应用程序的流行框架. 这是一个可以处理身份验证和访问授权的复杂框架.

■ApacheShiro（）: 另一个Java安全框架

■Passport（）: 一种安全框架，专注于流行的Node.js应用程序中的身份验证.

安全体系结构的关键部分是会话，该会话存储委托人的ID和角色. FTGO应用程序是传统的Java EE应用程序，因此该会话是HttpSession内存会话. 会话令牌代表每个特定的会话，客户端在每个请求中都包含会话令牌. 它通常是一串不可读的数字令牌，例如加密的强随机数. FTGO应用程序的会话令牌是一个称为JSESSIONID的HTTP cookie.

实现安全性的另一个关键是安全性上下文，它存储有关发出当前请求的用户的信息. Spring Security框架使用标准的Java EE方法将安全性上下文存储在静态线程局部变量中，可以通过调用处理该请求的任何代码访问该变量. 请求处理程序可以调用SecurityContextHolder. GetContext（）. GetAuthentication（）获取有关当前用户的信息，例如其身份和角色. 相反，Passport框架将安全上下文存储为请求对象的用户属性.

图2中所示的事件顺序如下:

1. 客户端向FTGO应用程序发送登录请求.

2. 登录请求由LoginHandler处理，LoginHandler验证凭据，创建会话并将有关主题的信息存储在会话中.

3. 登录处理程序将会话令牌返回给客户端.

4. 客户端在每个后续呼叫请求中都包含一个会话令牌.

5. 这些请求首先由SessionBasedSecurityInterceptor处理. 通过建立会话令牌并建立安全上下文来验证每个请求. 安全上下文描述了主体及其作用.

6. 请求处理程序使用安全上下文获取其身份，并使用此身份确定是否允许用户执行请求的操作.

FTGO应用程序使用基于角色的授权. 它定义了与不同类型的用户相对应的几个角色，包括消费者，餐厅，COURIER和ADMIN. 它使用Spring Security的声明性安全性机制来限制对特定角色URL和服务方法的访问. 角色也与业务逻辑交织在一起. 例如，消费者只能访问自己的订单，而管理员可以访问所有订单.

单个FTGO应用程序使用的安全性设计只是实现安全性的一种可能方法. 例如，使用内存中会话的一个缺点是，它必须将对特定会话的所有请求路由到同一应用程序实例. 此要求使负载平衡和操作变得复杂. 例如，您必须实现一种会话耗尽机制，该机制将在关闭应用程序实例之前等待所有会话到期（以免丢失内存中已有的会话）. 避免这些问题的另一种方法是将会话存储在中.

开发人员可能根本不保存服务器端会话. 例如，许多应用程序都有API客户端，这些客户端可以随每个请求提供其凭据，例如API密钥和私钥. 因此，无需维护服务器端会话. 或者，应用程序可以将会话状态存储在会话令牌中. 在本文的后面，我将介绍一种使用会话令牌存储会话的方法

状态方法. 但是，让我们首先来看一下在微服务架构中实现安全性的挑战.

微服务架构是分布式架构. 每个外部请求均由API网关和至少一项服务处理. 例子

例如，考虑getOrderDetails（）查询. API网关通过调用多种服务来处理此查询，包括订购服务，厨房服务和会计服务. 每个服务必须实现安全性的某些方面. 例如，订单服务必须仅允许消费者查看自己的订单，这需要身份验证和访问授权的结合. 为了实现微服务架构的安全性，我们需要确定谁负责验证用户身份以及谁负责访问授权.

在微服务应用程序中实现安全性的挑战之一是，我们不只是从整体应用程序中借鉴设计思想

路. 这是因为单片应用程序的安全体系结构的某些方面不适用于微服务体系结构，例如:

■内存中的安全上下文: 使用内存中的安全上下文（例如ThreadLocal）来传递用户的身份. 服务无法共享内存，因此它们不能使用内存中的安全上下文（例如ThreadLocal）来传递用户身份. 在微服务架构中，我们需要一种不同的机制来将用户的身份从一种服务转移到另一种服务.

■集中式会话: 因为内存中的安全上下文没有意义，所以内存会话也没有意义. 从理论上讲，多个服务可以访问基于的会话，但是这将违反松散耦合的原理. 我们需要在微服务架构中使用不同的会话机制.

让我们开始通过研究如何处理身份验证来探索微服务架构中的安全性.

处理身份验证有两种不同的方法. 每个服务的一种选择是分别认证用户. 这种方法的问题在于它允许未经身份验证的请求进入内部网络. 它依靠每个开发团队在所有服务中正确实现安全性. 因此，安全漏洞的风险和可能性很高.

在服务中实现身份验证的另一个问题是，不同的客户端以不同的方式进行身份验证. Pure API客户端使用基本身份验证为每个请求提供凭据. 其他客户端可以先登录，然后为每个请求提供会话令牌. 但是我们必须避免在服务中处理多种不同的身份验证机制.

一种更好的方法是让API网关在将请求转发到服务之前对其进行身份验证. API网关中集中式API身份验证的优点在于，您只需要确保验证正确即可. 因此，安全漏洞的可能性要小得多. 另一个好处是，只有API Gateway才需要处理各种身份验证机制. 这使其他服务的实现变得简单.

图3显示了此方法的工作方式. 客户端使用API​​网关进行身份验证. API客户端在每个请求中都包含凭据. 基于登录的客户端将用户的凭据发送到API网关进行身份验证，并接收会话令牌. 一旦API Gateway验证了请求，它将调用一个或多个服务.

图3 API网关对来自客户端的请求进行身份验证，并在其服务请求中包含安全令牌. 该服务使用令牌来获取有关主题的信息. API Gateway还可以将安全性令牌用作会话令牌

模式: 访问令牌

API网关将包含用户信息（例如其身份和角色）的令牌传递到它调用的服务. 参见: .

APIGateway调用的服务需要知道发出请求的主体（用户的身份）. 它还必须验证请求已通过身份验证. 解决方案是让API网关在每个服务请求中都包含一个令牌. 该服务使用令牌来验证请求并获取有关主题的信息. API网关还可以为面向会话的客户端提供相同的令牌，以用作会话令牌.

客户端的事件顺序如下:

1. 客户端向API网关发送包含凭据的请求.

2. API Gateway会对凭据进行身份验证，创建安全令牌，然后将其传递给服务.

基于已登录客户端的事件顺序如下:

1. 客户端发出带有凭据的登录请求.

2. API网关返回安全令牌.

3. 客户端在请求中包括安全令牌以调用操作.

4. API Gateway会验证安全令牌并将其转发给服务.

首先让我们看看安全性的另一个主要方面: 访问授权.

验证客户的凭据很重要，但这还不够. 应用程序还必须实现访问授权机制，以验证是否允许客户端执行所请求的操作. 例如，在FTGO应用程序中，只能由发出此Order的消费者（基于实例的安全性的示例）和为所有消费者服务的客户服务代表调用getOrderDetails（）查询.

用于访问授权的一个位置是API网关. 例如，它可以将对GET / order / {orderId}的访问限制为消费者和客户服务代表. 如果不允许用户访问特定路径，则API网关可以在将请求转发到服务之前拒绝该请求. 像身份验证一样，API Gateway中的集中式访问授权可以降低安全漏洞的风险. 您可以使用安全框架（例如Spring Security）在API Gateway中实现访问授权.

在API网关中实现访问授权的一个缺点是，它可能导致API网关和服务之间的耦合，要求它们以同步方式更新其代码. 而且，API网关通常只能实现对URL路径的基于角色的访问. API网关通常无法对单个域对象实施访问授权，因为这需要详细了解服务的域逻辑.

访问授权的另一个位置是服务. 服务可以为URL和服务方法实现基于角色的访问授权. 它还可以实现ACL以管理对聚合的访问. 例如，可以在订单服务中实现基于角色和基于ACL的授权机制，以控制对订单的访问. FTGO应用程序中的其他服务也可以实现类似的访问授权逻辑.

在微服务架构中实现安全性时微服务之间调用安全，您需要确定应使用哪种类型的令牌API网关将用户信息传递给服务. 有两种类型的令牌可供选择. 一种选择是使用不透明（不可读）令牌，这些令牌通常是一串UUID. 不透明令牌的缺点是它们会降低性能和可用性，并增加延迟. 因为此令牌的接收者必须启动对安全服务的同步RPC调用，以验证令牌并检索用户信息.

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