提高微服务安全性的11个方法( 三 ) _微服务

Spring Security 5.3.0完全支持RSocket应用程序。
要了解有关RSocket的更多信息，我建议阅读RSocket入门：Spring Boot Server 。
4.使用身份令牌OAuth 2.0自2012年以来就提供了委托授权。2014年，OpenIDConnect在的OAuth 2.0之上添加了联合身份。它们共同提供了一个标准规范，你可以据此编写代码，并可以在 IdPs (Identity Providers) 中使用。
该规范，还允许你通过向/userinfo端点发送访问令牌来查找用户的身份。你可以使用OIDC发现来查找此端点的URI，这提供了一种获取用户身份的标准方法。

文章插图

如果要在微服务之间进行通信，则可以使用OAuth 2.0的客户端凭据流来实现安全的服务器到服务器通信。在下图中，API Client是一台服务器，而API Server另一台服务器。

文章插图

授权服务器：多对一还是一对一？如果你使用OAuth 2.0保护服务安全，使用的还是授权服务器。典型的设置是多对一关系，在这种关系中，你有许多微服务与授权服务器通信。

文章插图

这种方法的优点：

服务可以使用访问令牌与任何其他内部服务进行对话（因为它们都是连接到同一个授权服务器）
有了一个可以查找所有范围和权限定义的地方
开发人员和安全人员更易于管理
交互更快

缺点：

如果一项服务的令牌遭到破坏，则所有服务都将面临风险
安全边界模糊

另一种更安全的替代方法是一对一方法，其中每个微服务都绑定到其自己的授权服务器。如果他们需要相互通信，则需要在信任之前进行注册。

文章插图

这种体系结构使你可以明确定义安全边界。但是，它比较慢，也难于管理。
我的建议：使用多对一关系，直到你有计划和文档来支持一对一关系为止。
在JWT上使用PASETO令牌在过去的几年中，JSON Web Tokens (JWT) 变得非常流行，但也遭到了抨击。主要是因为许多开发人员尝试使用JWT，来避免会话的服务器端存储。请参阅为什么不建议使用JWT 。
我的同事Randall Degges和Brian Demers在PASETO( platform-agnostic security tokens)上写了一些有益的文章。

全面了解PASETO
用Java创建和验证PASETO令牌

长话短说：使用PASETO令牌并不像听起来那么容易。如果你想编写自己的安全性，则可以使用它。但是，如果你要使用知名的云提供商，则很可能它还不支持PASETO标准。
5.加密和保护密钥当你开发与授权服务器或其他服务通信的微服务时，这些微服务可能会存储用于通信的密钥。这些密钥可能是API密钥，客户密钥或用于基本身份验证的凭据。
要更安全地使用密钥，第一步是将其存储在环境变量中。但这只是开始，你应该尽力加密你的密钥。
【提高微服务安全性的11个方法】在Java世界中，我最熟悉HashiCorp Vault和Spring Vault 。
下图展示的是Amazon KMS是如何工作。

文章插图

简而言之，它的工作方式是：

使用KMS生成主密钥
每次你想要加密数据时，你都要求AWS 为你生成一个新的数据密钥。
然后，你可以使用数据密钥对数据进行加密
然后，Amazon将使用主密钥对你的数据密钥进行加密
然后，你将合并加密的数据密钥和加密的数据以创建加密的消息。该加密的消息是你的最终输出，你就可以将它存储在文件或数据库中。

这样，你就无需担心保护密钥的安全性-密钥始终是唯一且安全的。你还可以使用Azure KeyVault来存储你的密钥。
6.通过交付流水线验证安全性依赖关系和容器扫描，从源头保障了程序的安全，但是在执行CI（持续集成）和CD（持续部署）流水线时，还应该执行测试。
Atlassian有篇文章，DevSecOps：将安全性注入CD流水线，建议使用安全性单元测试，静态分析安全性测试（SAST）和动态分析安全性测试（DAST）。
你的代码交付流水线可以自动执行这些安全检查，但是可能会花费一些时间来设置。
可以了解一种“ Continuous Hacking ”的软件交付方法，请参阅Zach Arnold和Austin Adams的这篇文章。他们建议以下内容：