【Azure云】限制Azure上的服务间通信

此示例场景限制应用程序层和网络层上两个Azure后端服务之间的通信。通信只能在明确允许的服务之间流动，遵循最小特权原则。此示例使用Azure应用程序服务来承载服务，但您可以对Azure功能应用程序使用类似的技术。

军种间通信限制只是基于精心规划、威胁建模和安全开发生命周期的整体安全战略的一部分。总体安全规划应包含业务、法规遵从性、管理法规和其他非功能性要求。

潜在用例

虽然当前的场景侧重于网络限制，但许多组织现在采用了零信任安全模型，该模型假设存在漏洞，因此网络层具有次要的重要性。

架构

显示两个Azure应用程序服务后端服务之间的网络层和应用程序层通信限制的图表。

在网络层步骤1中，服务A使用客户端凭据从Microsoft Entra ID请求并接收服务B的OAuth 2.0令牌。在步骤2中，服务A将该令牌注入到针对服务B的通信请求中。在步骤3中，服务B评估访问令牌的aud声明并验证该令牌。在应用层中，服务A位于虚拟网络中的集成子网中。在步骤1中，服务A使用应用程序服务区域VNet集成仅从其集成子网的专用IP地址进行通信。在步骤2中，服务B使用服务端点仅接受来自服务A集成子网中的IP地址的通信。

Download a Visio file of this architecture.

数据流

该图显示了从服务A到服务B的受限通信。基于令牌的授权限制应用层上的访问，服务端点限制网络层上的接入。

• 这两个服务都使用Microsoft Entra ID注册，并在客户端凭据流中使用基于OAuth 2.0令牌的授权。
• 服务A通过使用区域VNet集成从其虚拟网络集成子网中的专用IP地址进行通信。服务B服务终结点仅接受来自服务A集成子网的入站通信。

基于令牌的授权

与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的用户分配要求，请执行以下操作：

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

服务终结点

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

• 服务A web应用程序使用区域VNet集成通过集成子网IP范围内的专用IP地址路由所有出站通信。
• 服务B的服务端点仅允许来自服务B的集成子网上的web应用程序的入站通信。

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

组件

此方案使用以下Azure服务：

• Azure应用程序服务同时承载服务A和服务B，允许自动扩展和高可用性，而无需管理基础设施。
• Microsoft Entra ID是基于云的身份和访问管理服务，用于验证服务并启用基于OAuth 2.0令牌的授权。
• Azure虚拟网络是Azure中私有网络的基本构建块。Azure虚拟网络允许像Azure虚拟机（VM）这样的资源安全地相互通信、互联网和本地网络。
• 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功能

您可以在Azure功能而不是应用程序服务中托管服务。要使用区域VNet集成限制网络层的访问，您需要在应用程序服务计划或高级计划中托管功能应用程序。有关更多信息，请参阅Azure功能网络选项。

App Service内置身份验证和授权

根据设计，该场景通过作为应用程序代码的一部分执行令牌验证，将授权代码与其他业务逻辑并置。App Service内置的身份验证和授权，或Easy Auth，也可以在向服务发送请求之前执行基本的令牌验证。然后，该服务依赖于托管基础设施来拒绝未经授权的请求。

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

使用Easy Auth的缺点是，如果服务移动到其他位置，它将失去身份验证和授权保护。虽然应用程序服务身份验证和授权适用于简单的场景，但复杂的授权需求应该使用应用程序代码中的逻辑。

服务端点与专用端点（Service endpoints vs. private endpoints）

此方案使用服务终结点而不是专用终结点，因为只有服务终结点允许限制从给定子网访问web应用程序。不支持通过网络安全组（NSG）或使用应用程序服务访问限制来筛选专用端点上的入站流量。每个具有网络视线的服务都可以与web应用程序的私有端点进行通信。这限制了专用端点在网络层上锁定流量的有用性。

注意事项

• 应用服务区域VNet集成为每个应用服务计划提供单个集成子网。同一计划中的所有web应用程序都与同一个子网集成，并共享同一组专用出站IP地址。接收服务无法区分流量来源于哪个网络应用程序。如果您需要识别发起的web应用程序，则必须将web应用程序部署在单独的应用程序服务计划中，每个计划都有自己的集成子网。
• 应用程序服务计划中的每个工作实例都在集成子网中占用一个单独的专用IP地址。要规划规模，请确保集成子网足够大，可以容纳您期望的规模。

成本优化

此方案的定价取决于您的特定基础设施和要求。Microsoft Entra ID根据需要提供高达高级级别的免费服务。Azure应用程序服务或其他主机的成本因您的特定规模和安全要求而异，如备选方案和注意事项中所述。

要计算场景的成本，请参阅Azure定价计算器。

• Message encoding considerations for cloud applications
• Enterprise deployment using App Services Environment
• Web app private connectivity to Azure SQL database

• App Service networking features
• Zero to Hero: securing your web app
• Zero to Hero: multi-tier web apps
• Microsoft Entra client credentials flow
• Service endpoints
• App Service Regional VNet Integration
• Sample application demonstrating client credentials flow for daemon apps
• Azure Security Baseline for App Service