什么是 Azure Front Door 的服务标签匹配？

适用于： ✔️ Front Door Premium

Azure Web 应用程序防火墙（WAF）在Azure Front Door上可以将请求与客户端IP地址所属的服务标签进行匹配。服务标签代表给定Azure服务的一组IP地址前缀。 Microsoft 管理每个服务标签中的前缀，并会随着地址变化自动更新这些前缀。

你可以通过自定义规则使用服务标签匹配，将匹配变量设置为 SocketAddr 或 RemoteAddr，操作符设置为 ServiceTagMatch。

服务标签匹配在你想针对Azure服务写访问控制规则时最有用，而不是针对地址列表。允许监控服务到达你的应用，或者阻止来自你的应用从未合法接收请求的服务的流量，这两种情况都比表示为一组需要你维护的前缀更容易表示为一个标签。

服务标签匹配的工作原理

每个服务标签对应Microsoft发布的一组IP地址前缀。当请求到达 Azure Front Door 时，WAF 会将客户端地址解析为包含该地址的服务标签，并将这些标签与自定义规则中的值进行比较。如果地址落在你指定的标签内，匹配条件会被评估为true，规则的操作就会被应用。

由于 Microsoft 维护每个标签背后的前缀，针对服务标签编写的规则在底层地址变化时仍能继续生效。服务添加或停用地址范围时，你不需要更新规则。

一个IP地址可以属于多个服务标签。宽义标签（如 AzureChinaCloud）包含许多更窄标签所涵盖的范围，因此，来自 Azure 服务的请求既匹配该服务的特定标签，也匹配包含它的更宽泛标签。编写规则时，应针对最具体的标签来表达你的意图。

为什么服务标签在 Azure Front Door 上有用

网络安全组也支持服务标签，但它们并不总是适用于 Azure Front Door 后方的应用程序：

Azure Front Door 终止客户端连接并将请求转发到你的源端，因此网络安全组在源端评估的地址是 Azure Front Door 地址，而不是原客户端的地址。源站制定的规则无法作用于原客户端。
托管在 Azure 外部的源站根本没有网络安全组。

在WAF处评估服务标签，即原始客户端连接到达处，可以获得类似于网络安全组在更靠近客户端的位置所提供的控制力。

选择合适的匹配变量

服务标签匹配支持两个匹配变量，它们之间的差异很重要：

匹配变量	它评估的内容
`SocketAddr`	到达Azure Front Door的TCP连接的IP地址。这是实际打开该连接的对象的地址，可能是代理或其他服务，而非最终用户。
`RemoteAddr`	原始客户端 IP 地址，存在时取自 `X-Forwarded-For` 标头。

当你想对实际连接到 Azure Front Door 的服务采取行动时使用SocketAddr，这也是服务标签规则的常见情况。你关心的地址，也就是发送请求的 Azure 服务，就是开启连接的地址。

当流量通过中介，需要评估其所转发的客户端时使用 RemoteAddr 。请记住，X-Forwarded-For 由调用方提供，任何人都可以设置，因此，基于 RemoteAddr 允许流量的规则比基于 SocketAddr 的规则更容易被伪造。

没有其他匹配变量可与 ServiceTagMatch 运算符一起使用。

配置服务标签匹配条件

服务标签匹配条件使用以下设置。

设置	Value
匹配变量	`SocketAddr` 或 `RemoteAddr`
Operator	`ServiceTagMatch`
匹配值	一个或多个服务标签名称
否定条件	Optional. 设置为 `true` 以匹配与你列出的标签不匹配的所有地址。

在 Azure 门户中，匹配值是可用服务标签的可搜索列表，而非自由文本字段。选择你希望规则匹配的标签。你可以在单一条件下选择多个标签；如果地址属于其中任一标签，则条件匹配。

服务标签名称完全匹配。通配符、部分名称和正则表达式不被 ServiceTagMatch 运算符支持。

有关服务标签的完整列表及每个标签涵盖内容的说明，请参见 Azure 服务标签概览。

Examples

允许来自可信 Azure 服务的流量

假设监控或健康检查服务需要访问WAF本应屏蔽的端点。以下规则允许来自该服务的流量：

{
  "name": "AllowAzureMonitor",
  "priority": 10,
  "ruleType": "MatchRule",
  "matchConditions": [
    {
      "matchVariable": "SocketAddr",
      "operator": "ServiceTagMatch",
      "negateCondition": false,
      "matchValue": [
        "AzureMonitor"
      ]
    }
  ],
  "action": "Allow"
}

给允许规则一个高优先级（低数值），这样它们会在它们要绕过的阻止规则和速率限制规则之前被评估。请注意，允许操作会停止对该请求的默认规则集和机器人保护规则集的评估，因此请尽可能缩小允许规则的范围。

阻止来自服务标签的流量

如果你的应用从未合法地接收到某个 Azure 服务的请求，你可以直接屏蔽它：

{
  "name": "BlockUnexpectedServiceTraffic",
  "priority": 100,
  "ruleType": "MatchRule",
  "matchConditions": [
    {
      "matchVariable": "SocketAddr",
      "operator": "ServiceTagMatch",
      "negateCondition": false,
      "matchValue": [
        "AzureChinaCloud"
      ]
    }
  ],
  "action": "Block"
}

谨慎使用宽泛标签，如 AzureChinaCloud。 AzureChinaCloud涵盖了Azure上使用的公共IP范围，包括其他客户使用的地址，因此针对它的规则影响远大于针对特定服务的规则。

将管理路径访问限制为特定服务

将服务标签条件与URI条件结合，可以将规则限制在你打算影响的流量范围内。以下规则阻止任何不是来自你预期地址范围、发往 /admin 的请求。该 negateCondition 属性会反转服务标签匹配，且规则匹配必须满足这两个条件。

{
  "name": "RestrictAdminPath",
  "priority": 20,
  "ruleType": "MatchRule",
  "matchConditions": [
    {
      "matchVariable": "RequestUri",
      "operator": "Contains",
      "negateCondition": false,
      "matchValue": [
        "/admin"
      ]
    },
    {
      "matchVariable": "SocketAddr",
      "operator": "ServiceTagMatch",
      "negateCondition": true,
      "matchValue": [
        "AzureChinaCloud.chinanorth3"
      ]
    }
  ],
  "action": "Block"
}

对来自服务标记的流量实施速率限制

服务标签条件也可以用于速率限制规则，该规则限制匹配客户端发送的请求数量，而非直接阻断：

{
  "name": "RateLimitServiceTraffic",
  "priority": 50,
  "ruleType": "RateLimitRule",
  "rateLimitDurationInMinutes": 5,
  "rateLimitThreshold": 1000,
  "matchConditions": [
    {
      "matchVariable": "SocketAddr",
      "operator": "ServiceTagMatch",
      "negateCondition": false,
      "matchValue": [
        "AzureChinaCloud"
      ]
    }
  ],
  "action": "Block"
}

Considerations

在为服务标签制定规则时，请牢记以下几点：

服务标签识别服务，而非租户。 标签覆盖了 Azure 服务使用的所有 IP 地址，涵盖该服务面向所有客户时使用的所有 IP 地址。允许某个服务标签意味着任何能够通过该服务发送流量的人都将被允许，因此应将服务标签视为粗略过滤器，而非身份检查。
仅靠服务标签不足以保障流量安全。 在制定允许该服务流量的规则之前，了解该服务产生的流量，并同时保留其他保护措施。有关详细信息，请参阅 Azure 服务标记概述。
优先选择最窄的标签。 针对特定服务的规则更容易推理，也更不容易产生意外影响，而不是针对像 AzureChinaCloud 这样的宽泛标签所写的规则。
标签内容发生变化。 Microsoft 会随着服务添加和停用地址，更新标签对应的前缀。这次更新使服务标签规则变得持久有效，但也意味着你今天规则匹配的地址集合不再固定。变更会自动传播;你不需要更新规则。
从检测模式开始。 部署一个新的服务标签规则，使用记录操作，或者将WAF策略设置为检测模式，并在切换到阻止前查看日志。这一步对于允许规则尤为重要，因为错误会悄然削弱你的保护，而不是以明显的方式阻断流量。
结合条件以减少爆炸半径。 将服务标签条件与URI路径、主机或请求方法条件配对，可以将规则限制在你打算影响的流量范围内。

上次更新时间为 2026-10-23