六、使用 Azure 活动目录保护微服务

安全性是 web 应用最重要的交叉问题之一。不幸的是，如今知名网站的数据泄露似乎司空见惯。考虑到这一点，信息和应用安全对于 web 应用来说变得至关重要。出于同样的原因，安全应用不应再是事后的想法。安全是组织中每个人的责任。

与微服务相比，单片应用有更大的攻击表面积；然而，微服务本质上是分布式系统。此外，原则上，微服务是相互隔离的，因此与单片应用相比，实施良好的微服务更加安全。与微服务相比，单块有不同的攻击媒介。微服务架构风格迫使我们在安全的背景下进行不同的思考。让我提前告诉你，微服务安全是一个很难理解和实现的复杂领域。

在我们深入研究微服务安全之前，让我们了解一下我们的方法。我们将更加关注认证 ( 认证)和授权 ( 认证)—在本章中统称为认证—如何工作，我们将讨论中可用的选项.NET 生态系统。

我们还将探索 Azure 应用编程接口管理服务及其作为应用编程接口网关的适用性.NET 的微服务环境，以及 Azure API Management 如何通过其安全特性帮助我们保护微服务。然后，我们将简要介绍不同的外围方面，它们具有针对微服务安全的深度防御机制。

在本章中，我们将讨论以下主题:

  • 为什么传统的认证系统不起作用？
  • 引入 OAuth 2.0
  • 引入 Azure 应用编程接口管理作为应用编程接口网关
  • 使用 Azure 应用编程接口管理安全性
  • 服务间通信安全方法
  • 集装箱安全和其他外围安全方面

技术要求

本章包含各种代码示例，以便解释它所描述的概念。代码保持简单，只是为了演示。大多数示例都涉及一个. NET Core 控制台应用，它是用 C#编写的。

Note that there will be a difference between the actual screen you'll see and the screenshots that are in this chapter. The look and feel of Visual Studio depends on the themes you select.

要运行和执行本章中的代码，您需要以下先决条件:

  • Visual Studio 2019 或更高版本
  • .NET Core 3.1 或更高版本

要安装和运行这些代码示例，您需要安装 Visual Studio 2019 或更高版本(首选 IDE)。为此，请遵循以下步骤:

  1. 从https://docs . Microsoft . com/en-us/Visual Studio/install/install-Visual Studio下载 Visual Studio 2019(社区免费)。
  2. 按照操作系统的安装说明进行操作。Visual Studio 有多个版本。我们使用的是视窗操作系统。

如果你没有.NET Core 3.1 安装完毕，可以下载设置，前往https://dotnet.microsoft.com/download/dotnet-core/3.0。

The complete source code is available at: https://github.com/PacktPublishing/Hands-On-Microservices-with-CSharp-8-and-.NET-Core-3-Third-Edition/tree/master/Chapter%2006.

单片应用的安全性

为了理解微服务安全性，让我们回顾一下我们是如何保护的.NET 单片应用。这将帮助我们理解为什么微服务的授权机制需要不同。

用于保护应用安全的关键机制一直是 auth。认证验证用户的身份。授权管理用户可以访问或不能访问的内容，也称为权限。当数据在客户端和服务器之间传递时，加密是帮助您保护数据的机制。不过，我们不会过多讨论加密——只是为了确保通过网络传输的数据在任何地方都是加密的。这可以通过使用《HTTPS 议定书》来实现。

下图描述了中典型身份验证机制的流程.NET 单片:

在上图中，我们可以看到用户通常通过网络浏览器输入他或她的用户名和密码。然后，这个请求到达负责授权的 web 应用中的一个薄层。在. NET Core 应用的情况下，该层或组件连接到用户凭据存储，用户凭据存储通常是一个 SQL 服务器。身份验证层根据存储在凭据存储中的用户名和密码验证用户提供的凭据。

一旦验证了用户的会话凭据，就会在浏览器中创建一个会话 cookie。除非用户拥有有效的会话 cookie，否则他们无法访问该应用。通常，每个请求都会发送一个会话 cookie。在这些类型的单片应用中，模块可以自由地相互交互，因为它们在同一个进程中并且具有内存访问。这意味着信任在这些应用模块中是隐含的，因此它们在相互对话时不需要单独的请求验证和确认。

这一节的重点主要是研究单片应用中的安全性，我们通过查看图表了解了安全性的流程。在下一节中，我们将讨论微服务中的安全性，并了解如何保护分布式系统。

微服务的安全性

现在，让我们看看微服务的例子。本质上，微服务是分布式系统。从来没有一个应用实例；相反，有几个不同的应用相互协调，以产生所需的输出。

在微服务安全方面，当与 ASP.NET Core 合作时，我们可以使用不同的安全机制，如 OAuth2.0、JWT 和 Azure Active Directory(带有额外的授权实现)。在微服务的情况下，并不是每个服务都必须进行身份验证，有些服务不需要任何身份验证来返回响应。总的来说，现在安全是一个大问题。

在下一节中，我们将讨论为什么传统的.NET 身份验证机制不起作用，然后我们将讨论各种其他身份验证机制。

为什么传统的？NET 身份验证机制工作正常吗？

微服务安全的一种可能方法如下:我们模拟与单块中授权层相同的行为。这可以描述如下:

在这种方法中，我们分发了身份验证层，并将其提供给所有微服务。因为每个都是不同的应用，所以它需要自己的身份验证机制。这本质上意味着每个微服务的用户凭据存储也是不同的。这引发了很多问题，比如，我们如何在所有服务中保持身份验证同步？我们如何验证服务间通信，还是跳过它？我们对这些问题没有满意的答案，所以这种方法没有意义，只会增加复杂性。我们甚至不能确定这种方法在现实世界中是否行得通。

对于现代应用，我们还需要考虑一个因素。在微服务领域，我们需要支持原生移动应用和其他非标准外形设备，以及物联网应用。随着本地移动应用的大量增加，微服务架构也需要支持这些客户端和微服务之间的安全通信。这不同于传统的基于网络浏览器的用户界面。在移动平台上，网络浏览器不是任何本地移动应用的一部分。这意味着在大多数应用中，基于 cookie 或基于会话的身份验证是不可能的，除非您使用特殊的方法或框架。例如，您可以在手机上使用 cookies 和会话，尤其是使用渐进式网络应用 ( PWAs )。因此，微服务需要支持客户端应用之间的这种互操作性。这从来不是一个问题.NET 单片应用。

在传统身份验证的情况下，浏览器负责根据每个请求发送 cookie。但是我们没有将浏览器用于本地移动应用。事实上，我们也没有使用 ASPX 页面，也没有使用表单的身份验证模块。对于 iOS 客户端或安卓系统来说，这完全是两码事。此外，我们还试图限制对我们的应用编程接口的未经授权的访问。在前面的例子中，我们将保护客户端，无论是 MVC 应用还是电话应用，而不是微服务。此外，所有这些移动客户端设备都不是信任子系统的一部分。对于每个请求，我们不能相信移动用户确实是所有者；通信信道也不安全。这意味着来自他们的任何请求根本不可信。

但是除了这些问题，我们还有另一个更概念性的问题。为什么应用应该负责验证用户和授权？这不应该分开吗？

对此的另一个解决方案是使用 SAML 协议，但同样，这是基于 SOAP 和 XML 的，因此它并不真正适合微服务。SAML 的实现复杂度也很高。

因此，很明显，我们需要一个基于令牌的解决方案。微服务授权的解决方案以开放身份连接和开放身份验证 2.0 的形式出现。OpenID Connect 是认证的标准，而 OAuth 2.0 是授权的规范；然而，这种授权是自然委托的。

我们将在接下来的章节中详细讨论这一点。但是在此之前，让我们绕道看看 JSON 网络令牌，看看它们为什么在微服务安全方面如此重要。

JSON Web 令牌

JSON 网络代币 ( JWT )发音为 JOT 。这是一个定义良好的 JSON 模式或格式，用于描述数据交换过程中涉及的令牌。JSON 网络令牌在https://tools.ietf.org/html/rfc7519详细定义。JWTs 可以用来验证请求，而不需要使用 OpenID 和 OAuth2.0.NET Core 应用。

OpenID Connect is an authentication layer, on top of OAuth 2.0 (which is an authorization framework).

在 JWT 的实现中，我们使用基于 JWT 的安全令牌。这个令牌是一个 JSON 对象，它包含关于发送者和接收者的信息，以及发送者的身份。因此，令牌应该通过电线进行保护，这样它们就不会被篡改。为此，令牌被分配对称或非对称密钥。这意味着当接收者信任令牌的发行者时，也可以信任令牌内部的信息。

If you want to find more general information related to security, visit the Open Web Application Security Project (OWASP) at http://www.owasp.org and the Microsoft Security development life cycle at https://www.microsoft.com/en-us/sdl/.

这里有一个 JWT 的例子:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

这是 JWT 的编码形式。如果我们看到相同的令牌的解码形式，它有三个组成部分:报头、有效载荷和签名。它们都用句点(.)隔开。前面的令牌可以如下解码:

Header: {"alg": "HS256", "type": "JWT"}
Payload: {"sub": "1234567890","name": "John Doe","admin": true}
Signature:HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),secret)

.NET Core 内置了生成和消费 JWTs 的支持。您可以在任何位置安装 JWT 支持.NET Core 应用，通过使用包管理器控制台和以下命令:

Install-Package System.IdentityModel.Tokens.Jwt

Visit https://jwt.io/ if you want to view and decode JWTs very easily. Moreover, you can add it as part of the Chrome debugger as well, which is quite handy.

本节向您概述了 JWT，包括如何独立于 OpenID Connect 和 OAuth2.0 使用它。在下一节中，我们将学习如何使用 OAuth2.0

使用 OAuth 2.0

好吧，你可能不知道 OAuth 2.0 是什么，但你肯定在几个网站上用过。如今，许多网站允许你使用脸书、推特和谷歌账户的用户名和密码登录。转到您最喜欢的网站，例如https://stackoverflow.com/登录页面。例如，有一个登录按钮，表示您可以使用您的谷歌帐户登录。当你点击谷歌按钮时，它会带你进入谷歌的登录页面，以及我们之前提到的一些权限。在这里，你提供你的谷歌用户名和密码，然后你点击允许按钮，授予你最喜欢的网站的权限。然后，谷歌将你重定向到堆栈溢出，你以堆栈溢出中适当的权限登录。这仅仅是 OAuth 2.0 和 OpenID Connect 的最终用户体验。

OAuth 2.0 处理 web 上、本地移动应用中以及所有无头服务器应用中的授权(在我们的上下文中，这些只不过是微服务实例)。您可能想知道为什么我们首先讨论授权，而不是身份验证。原因是 OAuth 2.0 是一个委托授权框架。这意味着，为了完成授权流程，它依赖于身份验证机制。

现在，让我们来看看与此相关的一些术语。

OAuth 2.0 角色描述了授权过程中涉及的各方，如下所示:

  • 资源:正在得到保护以防止意外访问和使用的实体。在我们的例子中，这是一个微服务。
  • 资源所有者:顾名思义，资源所有者可以是拥有资源所有权的个人，也可以是实体。他们也被称为最终用户。
  • 客户端:客户端是用来指代各种客户端应用的术语。这是指任何试图访问受保护资源的应用。在微服务上下文中，涉及的应用是单页应用、web 用户界面客户端和本地移动应用，甚至是试图访问下游其他微服务的微服务。
  • 授权服务器:简单来说，这个服务器叫做授权服务器，因为它通过颁发有效的令牌来认证终端用户。我们也可以称之为服务器，它对资源所有者进行身份验证，并向客户端颁发令牌。该令牌由托管在授权服务器上的安全令牌服务生成。

您可能已经注意到，OAuth 区分了最终用户和最终用户使用的应用。这有点奇怪，但这很有意义，因为它基本上是说，我授权这个应用代表我执行这些操作。

下图描述了在 OAuth 框架的一般授权流程中，这些角色如何相互作用:

在上图中的步骤 6 中，客户端将授权许可传递给授权服务器。这一步并不像看起来那么简单。授权有不同的类型。授权类型代表了在 OAuth 2.0 中获取访问令牌的四种不同的可能用例。如果您选择了错误的授权类型，您可能会危及安全性。让我们来看看它们:

  • 授权代码:这是服务器端网络应用使用的典型 OAuth 授权，也是你在 ASP.NET 应用中使用的授权。
  • 隐式:这对于单页应用非常有用，因为单页应用中的通信大部分是公共的，但也可以是私有的。身份验证是通过识别从服务器返回到浏览器的访问令牌来完成的，然后可以使用它来访问资源。
  • 资源所有者密码凭证:这需要用户直接在应用中输入自己的用户名和密码。这在您开发第一方应用时非常有用，以便使用您自己的服务器进行身份验证。
  • 客户端凭证:在您会遇到的大多数场景和情况下，访问受保护的资源都需要客户端凭证。除此之外，它们通常在客户端代表自己行动时使用(客户端也是资源所有者)。

本节的目的是强调分布式系统的安全性。微服务是分布式系统，所以我们研究了为什么不能采用经典的安全方法。然后，我们了解了 JWT 和 OAuth 的安全机制。下一节将重点介绍 OpenID Connect，它是 OAuth 2.0 协议之上的一层。

探索开放身份连接

OpenID Connect 1.0 是 OAuth 2.0 协议之上的一个简单的身份层。OpenID Connect 是关于身份验证的。它允许客户端根据授权服务器执行的身份验证来验证最终用户。它还用于以可互操作和类似 REST 的方式获取终端用户的基本配置文件信息。

OpenID Connect 允许所有类型的客户端——基于网络的、移动的和 JavaScript——请求和接收关于经过身份验证的会话和最终用户的信息。我们知道 OAuth 2.0 定义了访问令牌。好吧，OpenID Connect 定义了一个标准化的身份令牌(通常称为 ID 令牌)。身份令牌被发送到应用，以便应用可以验证用户是谁。它定义了一个端点来获取该用户的身份信息，例如他们的姓名或电子邮件地址。这是用户的信息端点。

它建立在 OAuth 2.0 之上，所以流程是相同的。它可以与授权码授权和隐式授权一起使用。这对于客户端凭证授权是不可能的，因为客户端凭证授权是用于服务器到服务器的通信。

这个过程中没有最终用户，因此也没有最终用户身份。同样，对于资源所有者的使用路径或流程来说，这也没有意义。那么这是如何工作的呢？我们将从安全令牌服务 ( STS )请求一个额外的 ID 令牌，而不是只请求一个访问令牌，后者实现了 OpenID Connect 规范。客户端接收一个标识令牌，通常还有一个访问令牌。要为经过身份验证的用户收集更多信息，客户端可以使用访问令牌向用户信息端点发送请求；然后，该用户信息端点将返回关于新用户的声明。OpenID 支持授权代码流和隐式流。它还增加了一些附加协议，即发现和动态注册。

身份验证和授权是任何安全应用都需要的重要元素。在本节中，我们了解了 OpenID Connect，它是 OAuth 框架之上的一个身份层。在下一节中，我们将讨论 Azure Active Directory，它是一个遵循 OpenID Connect 和 OAuth2.0 规范的提供程序。

了解 Azure 活动目录

OAuth 2.0 和 OpenID Connect 1.0 规范有多个提供者。 Azure 活动目录 ( AAD )就是其中之一。AAD 为组织提供企业级身份管理，用于云应用。AAD 集成将为您的用户提供简化的登录体验，它将帮助您的应用符合 it 政策。AAD 提供了高级安全功能，例如多因素身份验证，并且它可以随着应用的增长而很好地扩展。它用于所有微软 Azure 云产品，包括 Office 365，每天处理超过 10 亿次登录。

传统的一个更有趣的方面.NET 环境中，他们可以很好地将他们组织的 Windows Server 活动目录与 AAD 集成在一起。这里，我们使用了 OAuth/OIDC，因为我们采用了活动目录联合服务 ( ADFS )。但是在基于生产的应用中，我们有一个混合的情况，在内部 AD 中有一个不同的协议集(Kerberos、LDAP 等)。

Azure Active Directory

AAD

例如，假设组织的一名员工希望从特定位置访问特定资源。在这里，AAD 帮助验证该访问。这可以通过 AAD 同步工具或新的直通身份验证功能来完成，因此组织的信息技术合规性仍将得到管理。

Path-Through Authentication

PTA

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta

Password Hash Synchronization

PHS

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs

在这一节中，我们了解到 Azure Active Directory 是一个提供者，并且遵循 OpenID Connect 和 OAuth2.0 的规范。在下一节中，我们将借助一个代码示例来介绍 OpenID Connect、OAuth2.0 和 AAD。

使用 OpenID Connect、OAuth 2.0 和 Azure AD 的微服务身份验证示例

既然我们已经具备了所有的必备知识，我们就可以开始编码了。让我们构建一个ProductService应用。我们将保护FlixOne.BookStore.ProductService，它代表了我们的微服务之一。在解决方案中，FlixOne.BookStore微服务由FlixOne.BookStore.ProductService项目代表，FlixOne.BookStore.Web代表服务器端 web 应用。如果您打开本章提供的名为OpFlixOne.BookStore.sln的 Visual Studio 解决方案，将会更容易理解。此示例使用客户端凭据授予。

请注意，由于 Azure 门户和相应的 Azure 服务用户界面的不断变化的性质，建议您使用 Azure 资源管理器 ( ARM )应用编程接口，并自动执行您即将执行的一些注册任务。然而，出于学习的目的，并且主要是为了鼓励对 Azure 不熟悉或者第一次尝试 Azure 广告的开发人员，我们将遵循 Azure 门户用户界面。

以下是先决条件:

  • Visual Studio 2019 或更高版本
  • Azure 订阅(如果您没有这个，您可以使用免费试用帐户进行演示)
  • Azure AD 租户(单租户)—您还可以使用 Azure 帐户的默认目录，该目录应该不同于 Microsoft 组织的目录

本节旨在让您开始实施 AAD。我们创建了两个项目:服务和网络。在接下来的部分中，我们将扩展这个例子，从向 AAD 租户注册我们的应用开始。

向 Azure 广告租户注册我们的应用

我们需要将我们的应用集成到微软身份平台，这要求我们使用 Azure 门户中的应用注册体验来注册我们的应用。

现在，我们来看看如何注册FlixOne.BookStore.ProductService。

在这一步中，我们将向 Azure AD 租户添加FlixOne.BookStore.ProductService。为此，请登录 Azure 管理门户。请遵循以下步骤:

  1. 登录蔚蓝门户(https://portal.azure.com)。
  2. 点击 Azure 活动目录，如下图所示:

  1. 前面的步骤将带您进入默认目录的概览屏幕。点击应用注册，如下图:

  1. 单击新建注册。这将打开注册应用屏幕，如下所示:

提供前面截图中显示的所有强制详细信息，然后单击注册应用屏幕底部的注册按钮。当我们提供登录网址时，请确保您为您的应用提供了该网址。在我们的例子中，FlixOne.BookStore.ProductService是一个微服务，所以我们不会有一个特殊的登录网址。这意味着我们必须提供默认的网址，或者仅仅是微服务的主机名。在这里，我们将从我们的机器上运行服务，所以本地主机网址就足够了。您可以找到登录网址，一旦右键单击FlixOne.BookStore.ProductService项目下的项目网址，然后导航到调试，如下图截图所示:

/

  1. 如果您使用微软 Azure 应用服务计划部署您的服务，您将获得一个类似于https://productservice-flixone.azurewebsites.net/的网址。如果您在 Azure 上部署服务，您可以随时更改登录网址。
  2. 单击注册按钮后，Azure 会将应用添加到您的 Azure 广告租户中。不过还有几个细节需要完成，才能完成ProductService的注册。导航至应用注册| FlixOne.BookStore.ProductService。您会注意到，现在已经提供了一些附加属性，例如应用标识 URI。
  3. 对于应用标识网址，输入https://[Your_Tenant_Name]/ProductService，用您的 Azure 广告租户的名称替换[Your_Tenant_Name]。单击“确定”完成注册过程。最终配置应该如下所示:

现在，让我们进入FlixOne.BookStore.Web的注册:

  1. 首先，我们注册FlixOne.BookStore.Web。这是必要的，因为我们将使用 OpenID Connect 来连接到这个基于浏览器的网络应用。因此，我们需要在最终用户——也就是我们——和FlixOne.BookStore.Web之间建立信任。
  2. 点按“应用注册”，然后点按“新注册”。这将打开注册应用屏幕，如下图所示。填写名称，然后单击注册:

  1. 类似于我们注册ProductServices时，输入一些额外的必填信息，如下:

  1. 注意注销网址设置:我们设置为https://localhost:44322/Account/EndSession。 这是因为，结束会话后，Azure AD 会将用户重定向到这个 URL。对于应用标识网址，输入https://[Your_AD_Tenant_Name]/TodoListWebApp，用您的 Azure 广告租户的名称替换[Your_AD_Tenant_Name]。单击“确定”完成注册过程。
  2. 现在，我们需要为 FlixOne 设置权限。书店。网络，这样它就可以调用我们的微服务:产品服务。导航至应用注册|动画。再次单击书店.网站|应用编程接口权限，然后单击添加权限。这将保存权限。

注册应用是必需的，这样我们的服务和网络应用就可以与微软身份服务集成。本节还向我们介绍了 AAD 的实现。在接下来的章节中，我们将详细介绍这个应用。

正在为 FlixOne 生成 AppKey。网上书店

注册的另一个重要步骤是添加client_secret，这是在 Azure AD 和FlixOne.BookStore.Web之间建立信任所必需的。这个client_secret只生成一次；它是在 web 应用中配置的。

要生成该密钥，请执行以下步骤:

  1. 导航至应用注册|动画。书店.网站|证书和机密|新的客户端机密，如下图所示:

  1. 然后，添加描述为AppKey，选择密钥何时到期(我们选择了 1 年)，点击【添加】，如下图截图所示:

  1. 保存密钥后，Azure 将自动生成密钥的值，并显示在描述旁边。该键仅显示一次，因此您必须立即复制并保存它以备后用。在这种情况下，我们将把这个密钥保存在FlixOne.BookStore.Web的appsettings.json文件中。

密钥将显示在 Azure 门户上，如下所示(密钥值将显示在右侧):

client_Secret

appsettings.json

https://azure.microsoft.com/en-us/services/key-vault/

Managed identities for Azure resources

MSI

https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview

这一部分帮助我们为假想的应用FlixOne.BookStore.Web生成一个 AppKey，通过引导我们完成生成一个 Key 的步骤。现在，我们需要使用项目的配置设置为我们的应用配置这个键。在下一节中，我们将使用 Visual Studio 配置我们的解决方案。

配置 Visual Studio 解决方案项目

一旦我们完成了应用的注册，我们需要确保我们配置了我们的项目，这样这些项目将按照我们的期望工作。首先我们来看看如何用ProductServices项目配置这个。

打开appsettings.json文件，然后为以下键添加一些值:

  1. 搜索Tenant键。用您的 AD 租户名称替换它的值，例如，contoso.onmicrosoft.com。这也将是任何应用的应用标识网址的一部分。
  2. 将Audience键值替换为https://[Your_AD_Tenant_Name]/FlixOneBookStoreProductService。 将[Your_AD_Tenant_Name]替换为您的 Azure AD 租户的名称。

现在，让我们学习如何使用FlixOne.BookStore.Web配置这个，以便我们的 web 项目具有正确的值。

打开appsettings.json文件。然后用提供的值查找并替换以下键:

  1. 将WebResourceid键的值替换为https://[Your_Tenant_Name]/ProductService。
  2. 将WebBaseAddress替换为https://localhost:44321/。
  3. 将ClientId替换为 FlixOneBookStoreWeb 的应用 ID。您可以通过导航到应用注册|动画电子书商店网站来获取它。
  4. 将AppKey替换为client_secret，这是我们在注册 TodoListWebApp 过程的步骤 2 中生成的。如果您没有注意到这个键，那么您需要删除以前的键并生成一个新的键。
  5. 将Tenant替换为您的 AD 租户名称，例如contoso.onmicrosoft.com。
  6. 当用户注销 TodoListWebApp 时，用您希望应用将您重定向到的网址替换RedirectUri。在我们的例子中，默认值是https://localhost:44322/，因为我们希望用户导航到应用的主页。

在本节中，我们学习了如何获取密钥以及如何处理项目。在下一节中，我们将了解为什么管理它至关重要。

在 IIS Express 上生成客户端证书

到目前为止，我们已经注册了我们的应用来利用微软服务器。现在，FlixOne.BookStore.ProductService和FlixOne.BookStore.Web将通过安全通道进行对话。要建立安全通道，FlixOne.BookStore.Web需要信任客户端证书。这两种服务都托管在同一台机器上，并且都在 IIS Express 上运行。

要将您的计算机配置为信任 IIS Express SSL 证书，请执行以下步骤:

  1. 以管理员身份打开 PowerShell 命令窗口。
  2. 查询您的个人证书库，找到CN=localhost的证书指纹。下面的代码片段显示了这个的 PowerShell 脚本。在这里，我们通过在本地计算机的证书存储上存储指纹，向 IIS Express web 服务器添加一个证书:
PS C:windowssystem32> dir Cert:LocalMachine\My
Directory: Microsoft.PowerShell.SecurityCertificate::LocalMachineMy
Thumbprint Subject
---------- -------
C24798908DA71693C1053F42A462327543B38042 CN=localhost
  1. 接下来，将证书添加到受信任的根存储中。下面的代码将证书添加到本地计算机上的证书存储中:
PS C:windowssystem32> $cert = (get-item cert:LocalMachineMyC24798908DA71693C1053F42A462327543B38042)
PS C:windowssystem32> $store = (get-item cert:LocalmachineRoot)
PS C:windowssystem32> $store.Open("ReadWrite")
PS C:windowssystem32> $store.Add($cert)
PS C:windowssystem32> $store.Close()

前面的一组指令将向本地计算机的证书存储中添加一个客户端证书。

要使用 HTTPS，我们应该安装 SSL 证书。为了展示和测试这一点，我们在本地机器上生成并添加了一个证书。在下一节中，我们将运行演示应用。

运行两个应用

我们已经完成了所有那些繁琐的配置屏幕和关键替换。但是在你按下 F5 之前，先把ProductService和FlixOne.BookStore.Web设置为启动项目。一旦你做到了这一点，你就可以安全地运行我们的应用，你会看到我们应用的登录页面。点击登录按钮，将被重定向至login.microsoftonline.com；这代表 Azure AD 登录。登录后，您将看到登录页面，如下所示:

当您登录到应用时，您将观察到网络流量和网址重定向。因此，研究身份令牌的详细交换，并获得一个访问令牌。如果您通过“产品列表”菜单浏览应用，您将能够访问“产品列表”屏幕，以及向“产品列表”添加项目。这是我们的ProductService微服务被调用的地方，也是它从FlixOne.BookStore.Web web 应用获得授权许可的地方。如果您浏览配置文件菜单，您将看到返回的标识令牌，以及您的名字、姓氏和电子邮件标识，这将显示 OpenID Connect 正在运行。

在这个例子中，我们使用 OAuth 和 OpenID Connect 来保护基于浏览器的用户界面、web 应用和微服务。如果我们在用户界面网络应用和微服务之间有一个应用编程接口网关，情况可能会不同。

要验证我们的功能，请打开ProductController，然后对[Authorize]属性进行注释，如下图所示:

在主屏幕中，单击产品列表。您将看到一条消息，提示您在访问产品列表之前应首先登录:

这表明我们不能访问我们的产品列表，直到我们登录或拥有特定的访问权限。

在这种情况下，我们需要在 web app 和 API 网关之间建立信任。我们还必须将标识令牌和访问令牌从网络应用传递到应用编程接口网关。这又将令牌传递给微服务；但是，在本章中讨论并实现它是不可行的。

为了利用微软 Azure 上的微软身份框架，通过使用 Azure 活动服务和 OpenID Connect，我们可以创建安全的应用。本节重点介绍并实现了 Azure 活动目录，使用了一个虚拟项目。接下来，我们将学习如何将其作为 API 网关进行管理。

将 Azure 应用编程接口管理作为应用编程接口网关进行管理

微服务实现中的另一个重要模式是前端的后端。这种模式是由山姆·纽曼引入并流行起来的。BFF 模式的实际实现是通过在各种类型的客户端和微服务之间引入一个 API 网关来完成的。

如下图所示:

蔚蓝色 API 管理(以下简称蔚蓝色 APIM 或刚好 APIM )正合适。它可以在中充当应用编程接口网关。基于. NET 的微服务实现。由于 Azure APIM 是云服务之一，它具有超强的可扩展性，可以很好地集成到 Azure 生态系统中。在本章中，我们将重点向您展示 Azure APIM 的功能。

蔚蓝 APIM 在逻辑上分为三个部分:

  • API 网关:API 网关基本上是客户端应用和服务之间的代理。它负责以下功能，这些功能主要由各种应用用来与微服务对话:
    • 接受应用编程接口调用，并将它们路由到后端
    • 验证应用编程接口密钥、JWTs 和证书
    • 支持通过 Azure AD 和 OAuth 2.0 访问令牌进行身份验证
    • 强制实施使用配额和费率限制
    • 动态转换您的应用编程接口，无需修改代码
    • 缓存设置它们的后端响应
    • 日志调用元数据进行分析
  • 发布者门户:这是一个管理界面，用来组织和发布一个 API 程序。它主要由微服务开发人员使用，以使微服务/应用编程接口对应用编程接口消费者或客户端应用可用。通过这一点，API 开发人员可以做到以下几点:
    • 定义或导入应用编程接口模式
    • 将原料药包装到产品中
    • 在应用接口上设置策略，如配额或转换
    • 从分析中获得见解
    • 管理用户
  • 开发人员门户:这是应用编程接口消费者的主要网络存在，他们可以在这里做以下事情:
    • 阅读应用编程接口文档
    • 通过交互式控制台尝试应用编程接口
    • 创建一个帐户并订阅它以获取 API 密钥
    • 访问分析以供自己使用

Azure APIM 提供了易于使用的用户界面和良好的文档。Azure API Management 还自带 REST API，因此 Azure APIM 门户的所有功能都可以通过 Azure REST API 端点以编程方式实现，该端点可用于 Azure APIM。

现在，让我们快速了解一下 Azure APIM 中的一些安全相关概念，以及它们如何在微服务中使用:

  • 产品:产品只是原料药的集合。它们还包含使用配额和使用条款。

  • 策略:策略是 API 管理的动态安全特性。它们允许发布者通过配置改变应用编程接口的行为。策略是根据应用编程接口的请求或响应按顺序执行的语句的集合。应用编程接口管理基本上是位于我们的微服务之间的代理，微服务托管在 Azure 和客户端应用中。由于它是一个中间层，它能够提供额外的服务。这些额外的服务是在一个名为策略的基于 XML 的声明性语法中定义的。蔚蓝 APIM 允许各种政策。事实上，您可以通过组合现有策略来构建自己的自定义策略。 一些重要的限制政策如下:

    • 检查 HTTP 头:该策略检查 Azure APIM 接收的每个请求中是否存在特定的 HTTP 头或其值。
    • 按订阅限制呼叫速率:此策略根据特定服务被调用的次数，在每个订阅的基础上允许或拒绝对微服务的访问。
    • 限制主叫 IP:此策略指的是白盒 IP 地址，这样只有已知的 IP 才能访问服务。
    • 按套餐设置使用额度:此政策允许多次通话。它允许您在每次订阅的基础上强制实施可续订或终身的呼叫量和/或带宽配额。
    • 验证 JWT :此策略验证应用中用于身份验证的 JWT 参数。

  • 一些身份验证策略如下:

    • 使用基本进行身份验证:该策略帮助我们对传入的请求应用基本身份验证。
    • 使用客户端证书进行身份验证:该策略帮助我们使用客户端证书对 API 网关后面的服务进行身份验证。

  • 一些跨域策略如下:

    • 允许跨域通话:这个政策允许我们通过 Azure APIM 进行 CORS 请求。
    • CORS :这为端点或微服务增加了 CORS 支持，允许基于浏览器的网络应用进行跨域调用。
    • JSONP:JSONP 策略为一个端点或者整个微服务增加了 JSON 填充 ( JSONP )支持，允许 JavaScript web 应用跨域调用。
  • 一些转换策略如下:
    • 屏蔽内容中的 URL:此策略屏蔽响应中的 URL；它是通过蓝色 APIM 实现的。
    • 设置后端服务:该策略改变了传入请求的后端服务的行为。

本节重点介绍了作为我们应用的应用编程接口网关的 Azure 应用编程接口管理服务。我们还讨论了策略以及如何将它们应用于入站和出站请求。接下来，我们将讨论利率限制和配额政策。

费率限制和配额政策的示例

在上一节中，我们学习了什么是策略。现在，让我们看一个例子。以下是已应用于端点的配额策略之一:

<policies>
  <inbound>
    <!-- Change the quota to immediately see the effect-->
    <rate-limit calls="100" renewal-period="60">
    </rate-limit>
    <quota calls="200" renewal-period="604800">
    </quota>
    <base />
  </inbound>
  <outbound>
    <base/>
  </outbound>
</policies>

在本例中，我们限制来自单个用户的传入请求(inbound)。这意味着应用编程接口用户只能在60秒内进行100调用。如果他们试图在这段时间内打更多的电话，用户会收到一个错误的状态代码429，它基本上表示超过了速率限制。我们还为同一用户分配了一年内200通话的配额限制。这种节流行为是保护微服务免受不想要的请求甚至 DOS 攻击的好方法。

Azure APIM 还支持使用 OAuth 2.0 和 OpenID Connect 进行身份验证。在发布者门户中，您可以看到 OAuth 和 OpenID Connect 选项卡，这样您就可以配置提供者。

本节重点介绍了 OAuth 2.0、OpenID Connect、Azure API 管理服务及其策略。接下来，我们将讨论容器安全性。

了解集装箱安全

当我们使用容器时，容器安全性是一个非常重要的考虑因素。我们在应用中使用 Docker 容器。Docker 是行业应用容器化的一大部分。随着集装箱的广泛使用，显然我们需要在集装箱周围采取有效的安全措施。如果我们看一下容器的内部架构，它们非常接近主机操作系统内核。

Docker 在隔离方面坚持最小特权原则，减少了攻击面。尽管在这一领域取得了进步，但以下最佳实践将帮助您了解可以对容器采取的安全措施:

  • 确保用于微服务的所有容器映像都经过签名，并且源自受信任的注册表。
  • 强化主机环境、守护进程和映像。
  • 要访问设备，请遵循最小权限原则，不要提升访问权限。
  • 使用 Linux 中的控制组来监视资源，如内存、输入/输出和中央处理器。
  • 尽管容器存在的时间很短，但是记录所有的容器活动是明智的，对于后期分析来说理解这一点很重要。
  • 如果可能，集成容器加工工具，如 Aqua(http://www.aquasec.com)或 Twistlock(https://www.twistlock.com)。

当我们使用任何 web 应用时，安全性是我们最应该考虑的方面。本节讨论了在使用容器时，我们应该考虑的安全因素。除了容器安全之外，我们应该考虑其他安全实践，以确保我们的应用是安全的。在下一节中，我们将了解其他安全最佳实践。

其他安全最佳实践

微服务架构风格是新的，尽管围绕基础设施和编写安全代码的一些安全实践仍然适用。在本节中，我们将讨论其中的一些实践:

  • 库和框架的标准化:在开发过程中应该有一个引入新的库和框架或者工具的过程。这将在发现漏洞时减轻修补工作；它还将最小化由围绕开发的库或工具的特别实现引入的风险。
  • R 规则漏洞识别和缓解:使用行业标准漏洞扫描器，扫描源代码和二进制文件，应该是开发的常规部分。这些发现和观察结果应被视为功能缺陷。
  • 第三方审核和笔测试:外部审核和渗透测试练习非常有价值。进行这样的练习应该是一种常规做法。这在处理关键任务或敏感数据的应用中非常重要。
  • 日志记录和监控:日志记录是一种非常有用的检测和恢复攻击的技术。在微服务的情况下，具有聚合来自不同系统的日志的能力是必不可少的。一些工具，如河床 Azure、AppDynamics(Azure 的性能监控工具)和 Splunk Azure，在这个领域非常有用。
  • 防火墙:在网络边界有一个或多个防火墙，总是有好处的。应该正确配置防火墙规则。
  • 网络隔离:在单片的情况下，网络划分受到约束和限制。但是，对于微服务，我们需要在逻辑上创建不同的网段和子网。当涉及到保持和开发额外的安全措施时，基于微服务交互模式的分段可能非常有效。

本节描述了一些其他的安全最佳实践。除了容器安全之外，我们应该考虑所有的安全实践，以确保我们的应用是安全的。

摘要

微服务架构风格是按设计分布的，在保护有价值的关键业务系统时，它为我们提供了更好的选择。传统。基于. NET 的身份验证和授权技术是不够的，它们不能应用于微服务领域。我们也看到了为什么安全的基于令牌的方法，比如 OAuth 2.0 和 OpenID Connect 1.0，正在成为微服务授权和认证的具体标准。

Azure AD 可以很好的支持 OAuth 2.0 和 OpenID Connect 1.0。Azure API Management 还可以充当微服务实现中的 API 网关，它提供了俏皮的安全特性，比如策略。

Azure AD 和 Azure API Management 提供了相当多的强大功能，因此我们可以监视和记录收到的请求。这非常有用，不仅对于安全性，而且对于跟踪和故障排除场景。

在下一章中，我们将关注日志记录、监控以及围绕微服务故障排除的整体检测。

问题

  1. 什么是软件安全？
  2. 单片应用的安全挑战是什么？
  3. 什么是 OAuth，你会如何使用它？
  4. 什么是授权服务器，它是如何工作的？
  5. 什么是 Azure API 管理，为什么我们需要一个用于微服务的 API 网关？

进一步阅读

版权属于：月萌API www.moonapi.com，转载请注明出处

本文链接：https://www.moonapi.com/news/32984.html