编辑

通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

限制服务间通信

Azure
Microsoft Entra ID
Azure 应用服务

本示例方案限制两项 Azure 后端服务在应用程序层和网络层上的通信。 通信只能在明确允许的服务之间进行，并遵守最低权限原则。 此示例使用 Azure 应用服务来托管服务，但你可以对 Azure Functions 应用使用类似的技术。

服务间通信限制只是基于谨慎计划、威胁建模和安全开发生命周期的总体安全策略的一部分。 整体安全规划应包含业务、合规性、法规和其他非功能性要求。

可能的用例

虽然当前方案侧重于网络限制，但许多组织现在采用一种假设存在漏洞的零信任安全模型，使网络层置于次要位置。

体系结构

Diagram showing both network layer and application layer communications restrictions between two Azure App Service backend services.

下载此体系结构的 Visio 文件。

数据流

此图显示了从服务 A 到服务 B 的受限通信。基于令牌的授权限制了应用程序层上的访问，服务终结点限制了网络层上的访问。

基于令牌的身份验证

与 OpenID Connect (OIDC) 兼容的库（如 Microsoft 身份验证库 (MSAL)）支持此基于令牌的客户端凭据流。 有关详细信息，请参阅方案：用于调用 Web API 的守护程序应用程序和用于守护程序方案的示例应用程序。

  1. 服务 A 和服务 B 均在 Microsoft Entra ID 中注册。 服务 A 具有共享机密或证书形式的客户端凭据。
  2. 服务 A 可以使用自己的客户端凭据来请求服务 B 的访问令牌。
  3. Microsoft Entra ID 提供了一个带有服务 B 受众或 aud 声明的访问令牌。
  4. 根据 OAuth 2.0 持有者令牌使用规范，服务 A 将令牌作为持有者令牌注入到发送给服务 B 的请求的 HTTP 授权标头中。
  5. 服务 B 对该令牌进行验证，以确保 aud 声明与服务 B 应用程序匹配。

服务 B 使用以下方法之一来确保只有明确允许的客户端（在此例中为服务 A）可以获得访问权限：

  • 验证令牌 appid 声明。 服务 B 可以验证令牌 appid 声明，该声明标识哪个已注册到 Microsoft Entra 的应用程序请求了令牌。 服务 B 根据已知的访问控制调用方列表显式检查声明。

  • 检查令牌中的角色。 同样，服务 B 可以检查传入令牌中声明的某些角色，以确保服务 A 具有显式访问权限。

  • 要求用户分配。 或者，服务 B 所有者或管理员可以将 Microsoft Entra ID 配置为要求用户分配，以便只有对服务 B 应用程序具有显式权限的应用程序才能获取服务 B 的令牌。除非业务逻辑需要特定角色，否则服务 B 不需要检查是否存在特定角色。

    若要设置用户分配要求以访问服务 B，请执行以下操作：

    1. 在 Microsoft Entra ID 中，在服务 B 上启用用户分配。
    2. 在服务 B 上至少公开一个应用角色，服务 A 可请求该角色权限。 此角色的 AllowedMemberTypes 必须包含 Application。
    3. 向公开的服务 B 角色请求服务 A 的应用权限。
      1. 从服务 A 应用注册的“API 权限”部分，选择“添加权限”，然后从列表中选择服务 B 应用程序。
      2. 在“请求 API 权限”屏幕上，选择“应用程序权限”，因为此后端应用程序可在没有登录用户的情况下运行。 选择公开的服务 B 角色，然后选择“添加权限”。
    4. 对服务 A 应用程序权限请求授予管理员同意。 只有服务 B 所有者或管理员才能同意服务 A 的权限请求。

服务终结点

此体系结构图的下半部分显示了如何在网络层上限制服务间通信：

  1. 服务 A Web 应用使用区域 VNet 集成通过集成子网的 IP 范围内的专用 IP 地址来路由所有出站通信。
  2. 服务 B 具有服务终结点，这些终结点仅允许来自服务 B 的集成子网中的 Web 应用的入站通信。

有关详细信息，请参阅设置 Azure 应用服务访问限制。

组件

此方案使用以下 Azure 服务：

  • Azure 应用服务同时托管 A 和服务 B，可以实现自动缩放和高可用性，无需管理基础结构。
  • Microsoft Entra ID 是一种基于云的标识和访问管理服务，可对服务进行身份验证并支持基于 OAuth 2.0 令牌的授权。
  • Azure 虚拟网络是 Azure 中专用网络的基本构建块。 通过 Azure 虚拟网络，Azure 虚拟机 (VM) 等资源能够以安全方式彼此通信、与 Internet 和本地网络通信。
  • Azure 服务终结点通过 Azure 主干网络上的优化路由，提供与 Azure 服务的直接安全连接，并且只允许从集成子网中的专用源 IP 范围进行访问。
  • Microsoft 身份验证库 (MSAL) 是一个与 OIDC 兼容的库，它允许服务使用客户端凭据流从 Microsoft Entra ID 中提取访问令牌。

备选方法

示例方案有多种备选方案。

托管标识

服务 A 可以使用托管标识来提取访问令牌，而不是在 Microsoft Entra ID 中注册为应用程序。 通过托管标识，操作员无需管理用于应用注册的凭据。

虽然托管标识可让服务 A 提取令牌，但它不提供 Microsoft Entra 应用注册功能。 对于其他服务，若要请求服务 A 自身的访问令牌，服务 A 仍需要 Microsoft Entra 应用注册。

不能通过 Azure 门户将托管标识分配给应用角色，只能通过 Azure PowerShell 命令行进行分配。 有关详细信息，请参阅使用 PowerShell 向应用程序角色分配托管标识访问权限。

Azure Functions

可以在 Azure Functions 而不是应用服务中托管服务。 若要使用区域 VNet 集成限制网络层上的访问，你需要在应用服务计划或高级计划中托管 Functions 应用。 有关详细信息，请参阅 Azure Functions 网络选项。

应用服务内置身份验证和授权

根据设计，此方案通过执行令牌验证（作为应用程序代码的一部分），将授权代码与其余业务逻辑共置在一起。 应用服务内置身份验证和授权（或称为“简易身份验证”）还可以在向服务发送请求之前执行基本令牌验证。 然后，该服务依赖于托管基础结构来拒绝未经授权的请求。

若要配置应用服务身份验证和授权，请将授权行为设置为“使用 Microsoft Entra ID 登录”。 此设置仅验证令牌并限制对有效令牌的访问。

使用简易身份验证的缺点是，如果服务移动到其他位置，则会失去身份验证和授权保护。 尽管应用服务身份验证和授权适用于简单方案，但复杂的授权要求应使用应用程序代码中的逻辑。

服务终结点与专用终结点

此方案使用服务终结点而非专用终结点，因为只有服务终结点才允许限制从给定子网对 Web 应用的访问。 不支持通过网络安全组 (NSG) 或通过使用应用服务访问限制来筛选专用终结点上的入站流量。 具有可见网络的每项服务都可以与 Web 应用程序的专用终结点通信。 这限制了专用终结点在锁定网络层上的流量方面的作用。

注意事项

  • 应用服务区域 VNet 集成为每项应用服务计划提供一个集成子网。 同一计划中的所有 Web 应用都与相同子网集成，并共享同一组专用出站 IP 地址。 接收服务无法区分流量来自哪个 Web 应用。 如果需要确定原始 Web 应用，则必须在单独的应用服务计划中部署 Web 应用，并且每个计划都要有自己的集成子网。

  • 应用服务计划中的每个辅助角色实例都在集成子网中占用一个单独的专用 IP 地址。 若要对规模进行计划，请确保集成子网足够大，能够容纳所需的规模。

成本优化

此方案的定价取决于具体的基础结构和要求。 Microsoft Entra ID 具有免费层到高级层，具体取决于需求。 Azure 应用服务或其他主机的成本因具体规模和安全需求而有所不同，如备选方案和注意事项中所述。

若要计算方案的成本，请参阅 Azure 定价计算器。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

首席作者：

后续步骤