一范式二范式三范式bc范式_微服务范式中的安全性

一范式二范式三范式bc范式

安全是实现微服务体系结构最不光彩的方面之一。 与断路器或服务发现之类的事物相比，它既不有趣也不酷，但是它是生态系统中至关重要的部分，尤其是在企业环境中。

我正在为东海岸的一家医疗企业从事大型微服务项目。 我们协助的基础架构的第一部分就是安全性，事实证明，它是所有之后的一切的救命稻草。 我能够看到在微服务环境中哪种安全性很好，哪些不好。 在这篇博客文章中，我将对如何在微服务中实现安全性进行中到高级的探讨。

安全概述

首先，安全实际上是什么意思？ 大多数企业在安全性的保护下有三个独立的方面：身份验证，授权和访问。

身份验证回答了以下问题：“此用户是否具有访问系统的有效凭据？”

授权回答问题“此经过身份验证的用户是否有权执行此操作？”

Access回答问题“此经过身份验证和授权的用户是否有权在此实体上执行此操作？”

在此博客文章中，我们将从身份验证开始，然后转到授权，然后从Access结束。

认证方式

通常，API网关是验证身份验证和执行授权的最佳场所。 这使您可以确保从边缘到生态系统的所有内容均已正确认证。

在Java世界中，Spring Security OAuth2的即用型设置将使您设置一个微服务，您可以调用该微服务来获取API令牌。 由于它是OAuth2客户端，因此您的API网关在收到针对OAuth2微服务验证API令牌的请求时，便具有Servlet过滤器。

在我的客户中，我们不希望每次您访问API网关时都要花费额外的费用来调用身份验证微服务。 因此，相反，我们在部署时为API网关和身份验证微服务注入了秘密加密字符串。 每个环境（DEV，QA等）都有自己的秘密加密字符串。 尽管我不确定如何在Spring Security中进行设置，因为我的客户端是.NET企业，但这对我们来说确实很好。

身份验证服务生成API令牌时，我们会在其中嵌入用于授权目的的信息。 （有关稍后提供的信息的更多信息。）这具有使我们的API令牌过长的副作用，因此您必须牢记您的应用服务器对HTTP标头长度的默认限制。 这样做的好处是，我们不再需要会话来存储相同的信息，并且借助部署时共享的加密密钥来安全地传输该信息。

通过将其存储在会话中（我们在职业生涯中都做到了这一点），这使我们免于开发人员一起窃取功能（我们在职业生涯中都做到了），并且由于负载平衡无需担心粘性会话，因此扩展服务非常容易。

我们还在API令牌中嵌入的一件事是有关它何时过期的信息。 API网关收到令牌后，便对其进行解密，这是授权检查，因为只有授权微服务才能发出该令牌。 然后，我们验证令牌尚未过期。

这花了我一些时间来适应，但是对于微服务（如我在下面的注释中看到的），有效身份验证要求的注释是level.done在API网关级别而不是在微服务的控制器/方法级别。

授权书

您可以选择两种授权方案。 大多数人知道的更多是基于角色的授权 。 使用此方案，端点定义角色。

例如： DELETE /user/:userId API端点需要SuperAdministrator角色，而GET /user/favoriteCereal仅需要一个User角色。 如果您的角色很少，并且访问权限很少改变，我会建议您这样做。

因此，您将存储在API令牌中的信息（JWT适用于那些令牌，而我们的某些其他客户端则使用它们）将是一组角色名称。 Spring Security 开箱即用地支持基于角色的授权 。

不幸的是，我们大多数中型和大型客户的角色都是色拉，他们对API的许可会不断变化，如果更改许可要求重新部署JAR，他们会杀死我们。 而是这些客户需要基于声明的授权 。 （角色定义端点。）

例如：SystemAdministrator角色为* /user/* ，User GET /user/favoriteCereal 。

您将存储在API令牌中的信息将是API网关最容易/最快地消化以决定解密的令牌是否正确执行该调用的信息。

不幸的是，我不认为这是Spring Security内置的。 为我们实现此功能的时间可能是2017年第三季度或第四季度，所以至少从C＃的角度我将了解更多。

访问

确认API令牌的授权后，您需要将其传递给您的API网关将要调用的微服务。 这是必需的，以便您可以填充数据库中的字段，例如CreatedByUserID等。 您可以选择将解密的JWT传递给微服务，这可能很好。

如果要提高安全性，则应在部署时为API网关和微服务注入自己的加密密钥。 这不同于API网关和身份验证微服务所共享的那种。 或保持不变。 这只是公司安全部门认为最好的。

到目前为止，我所谈到的授权实际上只是与执行API调用有关。 关于回答“发出此请求的实体是否有能力对数据库Y中的记录执行操作X？”的回答，最好的方法是对数据库记录中的访问控制列表（ACL）进行操作。是的

较大的客户端需要定期旋转SSL证书和密钥。 这可能会导致微服务问题，因为如果在部署时注入加密密钥（如我建议的那样），则需要部署更多的服务。

您可以进行蓝色/绿色部署，也可以使其成为验证所依据的一系列加密密钥。 您需要在其中一个密钥过期之前重新部署一个月，然后将新密钥首先包含在API网关中。 然后，您将新密钥添加到身份验证微服务。 然后，当旧密钥过期时，您可以先将其从Authentication微服务中删除，然后在宽限期后从API网关中将其删除。 如果您将过期时间嵌入令牌中，则宽限期至少应为该长度。

使用API​​令牌需要考虑的最后一件事是如何处理到期时间。 微软的策略是实质上发行两个令牌：API令牌和Refresh令牌。

API令牌是我在本博客中一直在谈论的内容，用于对API执行操作。

刷新令牌只能用于获取新的API令牌，而不必与身份验证微服务重新进行身份验证。 如果您的API令牌每20分钟失效一次，并且您不希望最终用户每次都再次输入密码，此功能将非常有用。 刷新令牌的到期时间通常是API令牌的到期时间的2倍或3倍。

最后的想法

最后，对于安全性方面的所有事情，请确保团队编写的代码量最少，并且可以从防弹库利用的代码量最大化。 安全性至关重要，在大多数情况下，您都希望信任从事安全性业务的公司编写的代码。

翻译自: https://www.javacodegeeks.com/2017/03/security-microservices-paradigm.html

一范式二范式三范式bc范式