2021年API成重大威胁，如何建立有效的API的安全策略？

Posted 2021-06-26 jinggege795

保护API的安全

安全性是与基于微服务的架构相关的最常讨论的问题之一。对于所有与安全相关的话题来说，始终绕不开一个主要问题，那就是网络。对于微服务，通常网络上的通信比一体化应用程序要多得多，所以应该重新考虑认证和授权的方法。传统系统通常采用构筑边界的形式进行保护，然后允许前端服务完全访问后端组件。迁移到微服务则迫使开发人员将这种方法改为委托访问管理。

 

Spring Framework 如何解决基于微服务架构的安全问题? 它提供了若干个实现有关身份验证和授权的不同模式的项目。第一个项目是Spring Security,它是安全的基于Spring的Java应用程序的事实标准。它由一些子模块组成，可以帮助开发人员开始使用SAML、OAuth2或Kerberos.另外还有Spring Cloud Security项目，它提供了若干个组件，允许开发人员将基本的Spring Security功能与微服务架构的主要元素集成在一起， 如网关、负载均衡器和RESTHTTP客户端。

本章将介绍保护基于微服务的系统的所有主要组件。我们将从Eureka的服务发现开始，然后转到Spring Cloud Config Server和服务间通信，最后再讨论API网关的安全性。

本章将要讨论的主题包括:

口为单个Spring Boot应用程序配置安全连接。

口为基于微服务架构的最重要元素启用HTTPS通信。

口加密和解密存储在ConfigServer上的配置文件中的属性值。

口使用OAuth2为微服务进行基于内存的简单身份验证。

口使用JDBC后端存储和JWT令牌进行更高级的OAuth2配置。

口在与Feign客户端的服务间通信中使用OAuth2授权。

接下来就让我们先从基础开始，演示如何创建第一个安全微服务，并且通过HTTPS公开其API。

为Spring Boot启用HTTPS

如果要使用SSL并通过HTTPS提供RESTful API，则需要生成证书。实现这一目标的最快方法是通过自签名证书(Self-Signed Certificate)，这对于开发模式来说已经足够了。

Java运行时环境(Java Runtime Environment, JRE) 提供了一个简单的证书管理工具一keytool。它位于JRE_ HOME\\bin 目录下。以下代码中的命令将生成自签名证书并将其放入PKCS12 KeyStore。 除了KeyStore 的类型，开发人员还必须设置其有效性、别名和文件名。在开始生成过程之前，keytool 还会询问密码和一些其他信息，如下所示。

keytool -genkeypair -alias account-key -keyalg RSA -keysize 2048 -storetype

PKCS12 -keystore account-key.p12 -validity 3650

Enter keystore password:

Re-enter new password:

What is your first and last name?

[Unknown]: localhost

What is the name of your organizational unit?

[Unknown]: -

What is the name of your organization?

[Unknown]: piomin

What is the name of your City or Locality?

[Unknown]: Warsaw

What is the name of your State or Province?

[Unknown]: mazowieckie

What is the two-letter country code for this unit?

[Unknown] : PL

Is CN=localhost, OU-Unknown, 0-piomin, L-Warsaw, ST-mazowieckie, C-PL

correct?

[no]: yes

我们已将生成的证书复制到Spring Boot应用程序内的src/main/resources目录中。构建并运行应用程序后，它将在类路径中可用。要启用SSL,必须在application.yml文件中提供一些配置设置。通过设置各种servessl.*属性，可以为Spring自定义SSL.

server :

port: ${PORT: 8090}

ssl :

key-store: classpath:account-key.p12

key-store-password: 123456

key-store-type: PRCS12

key-alias: account-key

security:

require-ss1: true

保证发现服务器的安全

如前文所述，微服务应用程序的SSL配置并不是- .项非常艰巨的任务。但是，是时候提高其难度等级了。我们已经启动一个通过HTTPS提供RESTful API的单一微服务。现在希望微服务与发现服务器集成。由此产生了两个问题。第一个是需要在Eureka上发布有关安全微服务实例的信息；第二个问题涉及通过HTTPS暴露Eureka 并强制发现客户端使用私钥对发现服务器进行身份验证。接下来我们将详细讨论这些问题。

 

注册安全的应用程序

如果应用程序通过安全的SsL 端口公开，则应将EurekaInstanceConfig-nonSecurePortEnabled中的两个标志更改为false,将securePortEnabled 更改为true。这迫使Eureka发布实例信息，显示对安全通信的明确偏好。对于以这种方式配置的服务,SpringCloud DiscoveryClient将始终返回以HTTPS开头的URL,并且Eureka 实例信息将具有安全的运行状况检查URL。

eureka:

instance :

nonSecurePortEnabled: false

securePortEnabled: true

securePort: ${PORT:8091 }

statusPageUrl: https://localhost:S feureka. instance. securePort}/info

heal thCheckurl: https://localhost:s{ eureka. instance . securePort } /health

homePageUrl: https://localhost:$ leureka. instance . securePort}

通过HTTPS服务Eureka

当Eureka服务器以SpringBoot启动时,它将部署在嵌入式Tomcat容器上,因而SSL配置与标准微服务相同。不同之处在于我们必须考虑客户端应用程序，该应用程序将通过HTTPS与发现服务器建立安全连接。发现客户端应该针对Eureka 服务器进行身份验证，并且还应验证服务器的证书。客户端和服务器之间的通信过程称为双向安全套接层(Two-way SSL)或相互身份验证(Mutual Authentication) 。还有单向身份验证，这实际上是默认选项，它只有客户端验证服务器的公钥(Public Key) 。

 

Java 应用程序使用KeyStore和trustStore存储与公钥对应的私钥( Private Key)和证书(Certificate)。trustStore和KeyStore之间的唯一区别是它们存储的内容和用途。执行客户端和服务器之间的SSL握手时，将使用trustStore验证凭据，而使用KeyStore 提供凭据。换句话说，KeyStore为给定的应用程序保留私钥和证书，而trustStore 保留用于从第三方识别它的证书。在配置安全连接时，开发人员通常不会过多关注这些术语，但正确理解它们可以帮助开发人员轻松了解接下来会发生什么。

 

在典型的基于微服务的架构中，有许多独立的应用程序和单个发现服务器。一方面，每个应用程序都有自己的私钥存储在KeyStore 中,并且证书对应于trustStore中的发现服务器的公钥。另一方面，服务器保留为客户端应用程序生成的所有证书。这就是现在的理论。如图12.1所示，它说明了在前面的章节中作为示例使用的系统的情况。

 

1. Keystore 的生成

在讨论了Java中的安全性基础知识之后,即可继续为我们的微服务生成私钥和公钥。和以前一样，我们将使用JRE下提供的命令行工具keytool。让我们从一个众所周知的用于生成带密钥对的keystore 文件命令开始，首先为发现服务器生成一个KeyStore,然后为一个选定的微服务(在这个特定示例中，我们选定的是account-service服务)生成第二个KeyStore。

keytool -genkey -alias account -store type JKS - keyalg RSA -keysize 2048 -

keystore account.jks -validity 3650

keytool -genkey -alias discovery -storetype JKS -keyalg RSA -keysize 2048 -

keystore discovery.jks -validity 3650

然后，必须将自签名证书从KeyStore导出到文件，例如，扩展名为.cer或.crt的文件。然后，系统将提示输入KeyStore生成期间提供的密码。

keytool -exportcert -alias account -keystore account.jks -file account. cer

keytool -exportcert -alias discovery -keystore discovery.jks - file

discovery. cer

鉴于已经从KeyStore中提取了与公钥对应的证书，因而现在可以将其分发给所有感兴趣的各方。来自account-service 服务的公共证书应包含在发现服务器的trustStore 中，反之亦然。

keytool - importcert -alias di scovery -keystore account.jks -file

discovery. cer

keytool - importcert -alias account -keystore di scovery.jks -file

account. cer

必须为在Eureka服务器中注册自身的每个后续微服务重复执行与account-service服务相同的步骤。以下是用于为order-service服务生成SsL密钥和证书的keytool命令。

keytool -genkey -alias order -storetype JKS -keyalg RSA -keysize 2048 -

keystore order.jks -validity 3650

keytool -exportcert -alias order -keystore order.jks -file order.cer

keytool - importcert -alias di scovery -keystore order. jks -file

discovery. cer

keytool - importcert -alias order -keystore discovery.jks -file

order. cer

2.配置微服务和Eureka服务器的SSL

每个keystore文件都放在每个安全微服务和服务发现的src/main/resources目录中。每个微服务的SSL配置设置与第12.1节“为Spring Boot启用HTTPS"中的示例非常相似。唯一的区别是当前使用的KeyStore的类型，现在是JKS而不是PKCS12。但是，之前的示例和服务发现配置之间存在更多差异。首先，我们已经通过将server s.client-auth属性设置为need来启用客户端证书身份验证,这反过来要求我们提供带有serevr.s.trust-store属性的trustStore。以下是application.yml文件中发现服务的当前SSL配置设置。

server :

port: S{PORT:8761}

ssl:

enabled: true

client-auth: need

key-store: classpath:discovery.jks

key-store-password: 123456

trust-store: classpath:discovery.jks

trust-store -password: 123456

key-alias: di scovery

如果开发人员使用上述配置运行Eureka应用程序，然后尝试访问htpt:p:/lhost:8761/下可用的Web仪表板，则可能会收到类似SSL_ ERROR. _BAD. CERT_ ALERT 的错误代码。发生此错误的原因是没有可信证书导入Web浏览器。为此，我们可以从服务(如acount-service服务)中导入客户端的应用程序KeyStore。但首先，我们需要将其从JKS格式转换为Web浏览器支持的另一种格式，如PKCS12。以下是用于将KeyStore从JKS转换为PKCS12格式的keytool命令。

keytool - importkeystore - srckeystore account.jks - srestoretype JKS -

deststoretype PKCS12 -destkeystore account.p12

所有最流行的网络浏览器都支持PKCS12，如Google Chrome和Mozilla Firefox。 要将PKCS12 KeyStore 导入Google Chrome浏览器，开发人员可以单击“设置”命令，然后显示“高级”设置部分，找到“管理证书”(管理HTTPS 1 SSL证书和设置)，单击打开“证书”对话框。如果再次尝试访问Eureka Web仪表板，则应成功进行身份验证，并且将能够看到已注册服务的列表。但是，在这里并没有已注册的应用。为了在发现客户端和服务器之间提供安全通信，我们需要为每个微服务创建一个 DiscoveryClientOptionalArgs类型的@Bean,它会覆盖发现客户端的实现。

 

有趣的是，Eureka 使用Jersey 作为REST客户端。使用EurekaJerseyClientBuilder, 开发人员可以轻松构建新的客户端实现并传递keystore和truststore文件的位置。以下是来自account-service的代码片段，我们在其中创建了一个新的EurekaJerseyClient对象并将其设置为DiscoveryClientOptionalArgs的参数。

public DiscoveryC1 ient . DiscoveryCl ientoptionalArgs

discoveryClientoptionalArgs() throws NoSuchAlgori thmException (

DiscoveryClient. DiscoveryClientOptionalArgs args = new

DiscoveryClient。
DiscoveryClientOptionalArgs () ;

System. setProperty ("javax.net.ss1.keyStore",

"src/main/ resources/account.jks") ;

System. setProperty ("javax .net.ssl. keyStorePassword", "123456") ;

System. setProperty ("javax.net.ssl. truststore",

"src/main/resources/account. jks") ;

System. setProperty ("javax.net.ss1. trustStorePassword", "123456") ;

EurekaJerseyClientBuilder builder = new EurekaJerseyClientBuilder( ;

builder .withClientName ("account-client") ;

builder.withSystemSSLConfiguration( ) ;

builder。wi thMaxTotalConnections (10) ;

builder。withMaxConnectionsPerHost (10) ;

args. setEurekaJerseyClient (builder . build());

return args;

}

在我们的示例系统中，应该为每个微服务提供类似的实现。GitHub ttps:/github.com/piomin/sample- spring cloud- scuritygt)上提供了示例应用程序的源代码。开发人员可以克隆它并使用集成开发环境运行所有Spring Boot应用程序。如果一切正常，则应该在Eureka仪表板中看到相同的注册服务列表，如图12.2 所示。如果SSL连接有任何问题，则可以尝试在应用程序启动期间设置-Djava.net.debug-ssl VM参数，以便能够从SSL握手过程中检查出完整日志。

 

觉得文章不错的朋友可以转发此文关注小编，有需要的可以扫码下方获取资料。