Azure网络服务标签增强指南

微软安全响应中心（MSRC）于2024年1月收到行业合作伙伴Tenable Inc.的报告，指出使用服务标签功能可能存在跨租户访问网络资源的风险。微软确认Tenable为Azure社区提供了宝贵贡献，强调服务标签的使用方式和预期目的容易被误解。虽然微软最初确认了漏洞并向Tenable支付了奖金，但进一步调查确定服务标签按设计工作，需要通过服务文档明确传达最佳实践。

跨租户访问通过身份验证被阻止，仅在未使用身份验证时构成问题。然而，此案例确实突显了使用服务标签作为单一机制验证入站网络流量的固有风险。服务标签不应被视为安全边界，而应仅作为与验证控制结合的路由机制。根据我们的调查，未收到第三方报告或发现服务标签被利用或滥用。

我们强烈建议客户为其资源使用多层安全措施，例如监控网络流量和身份验证。根据Tenable的报告，我们更新了文档以提醒客户服务标签的功能。

此次服务标签文档更新的目标是提高客户对服务标签及其功能的理解。因此，客户无需采取强制行动，Azure门户也未提供额外消息。但微软强烈建议客户主动审查其服务标签的使用情况，并验证其安全措施，仅对受信任的网络流量进行身份验证。

技术细节

服务标签是表示许多Azure服务IP地址块的便捷方式。资源可以使用服务标签在其防火墙规则中引用Azure服务，例如允许来自给定服务的流量访问资源。

其中一些服务允许通过服务标签进行入站流量，并包含让用户控制Web请求部分的功能（即URL路径、目标主机等）。如果租户B配置为允许来自服务标签的流量且未提供任何形式的身份验证，则租户A中的攻击者可能使用这些Web请求访问租户B中的Web资源。

在这些情况下，影响部分取决于以下因素：

• 受害者服务是否执行自己的身份验证检查
• 攻击者可以控制多少请求体
• 攻击者是否可以查看响应内容

示例：Azure Monitor可用性测试

例如，Azure Monitor可用性测试服务具有ApplicationInsightsAvailability服务标签，使用户能够通过防火墙配置webtests以访问其服务端点并执行综合监控。由于这些webtests在共享基础设施中使用相同的公共IP地址调用用户的服务端点，用户可能配置Web请求从另一个Azure Monitor可用性测试订阅访问服务端点。如果恶意行为者有权访问启用了ApplicationInsightsAvailability服务标签的租户，且目标服务端点未执行任何自己的身份验证检查，则此行为可能使恶意行为者向其他用户的服务端点发送Web请求，应用程序可能处理意外的Web请求。

客户指南

服务标签表示给定Azure服务的IP地址范围，用于网络配置，如防火墙过滤、网络安全组（NSG）和用户定义路由（UDR）。服务标签的此功能对于允许Azure服务与用户服务端点之间的网络流量至关重要。鉴于服务标签的灵活用例，客户必须考虑租户之间的网络流量及其特定服务场景。

服务标签不是保护流向客户源流量的全面方法，也不能替代输入验证以防止可能与Web请求相关的漏洞。输入验证用于确保流量的来源和发送者。必须实施额外的身份验证和授权检查以实现分层网络安全方法。

强烈鼓励Azure客户审查其Microsoft虚拟网络服务标签的使用情况，并评估是否需要采取额外措施来保护Azure租户之间的网络流量。客户审查服务标签使用情况后，可以：

• 查看新的Microsoft服务标签最佳实践文章，并遵循服务提供的具体指南。
• 查看Azure安全基础文档，确保其Azure平台和基础设施设置考虑了通用和安全最佳实践。
• 查看Azure Monitor文档，确保其Azure平台和基础设施启用了适当的监控控制以收集、分析和响应系统事件。

示例：带身份验证检查的Azure Monitor可用性测试

Azure Monitor可用性测试为客户提供了监控其资源正常运行时间的机会。客户必须在其资源监控策略中考虑这一点。使用Azure Monitor可用性测试及相关服务标签确保遵循标准监控策略。

为防止ApplicationInsightsAvailability服务标签将不需要的网络流量传递到您的服务端点，请创建令牌并将其作为HTTP标头添加到可用性测试中。然后，您的服务可以验证传入请求中的HTTP标头，以验证流量来源是否来自您的可用性测试。因此，所有没有自定义HTTP标头的其他请求将被拒绝和丢弃。在此处了解有关Azure Monitor可用性测试的此应用层安全控制的更多信息。

此外，一些客户可能具有以下场景。公司A可能向多个行业合作伙伴提供API，以便他们在其服务或应用程序中使用。每个合作伙伴可能希望通过Azure Monitor可用性测试监控公司A API的正常运行时间。因此，公司A必须决定其API的资源监控策略以及如何将该策略传达给其行业合作伙伴。

在追求安全设计原则的过程中，公司A可以实施对其HTTP标头的验证检查。公司A的资源监控策略将仅对具有自定义标头的行业合作伙伴可访问，确保安全协作。或者，公司A可以决定不要求自定义标头，而是使用自己的身份验证方法，允许任何人通过Azure Monitor可用性测试监控其API。

微软的响应和事件时间表

微软在注意到此活动后采取了以下行动：

• 微软进行了全面的变体搜索、遥测调查和工程审查，影响了缓解策略。
• 具有入站服务标签的Azure服务更新了文档，包括其服务标签用例和/或确认网络流量的指南。
• Azure在通用文章中记录了服务标签的最佳实践。

我们提供了与此问题相关的关键事件时间表，并强调了我们增加可用服务文档以防止此问题的方法：

• 2024年1月24日：Tenable通过MSRC研究员门户提交潜在安全漏洞。
• 2024年1月31日：MSRC确认观察到的漏洞并向Tenable颁发奖金。
• 2024年2月2日：微软审查问题并开始进行全面的变体搜索、遥测调查和工程审查以确定缓解策略。
• 2024年2月26日：微软传达我们的客户披露策略和增强Azure服务服务标签文档以解决问题的承诺。
• 2024年3月6日：微软和Tenable同意此问题的协调披露。
• 2024年3月31日：微软完成此问题的全面变体搜索、遥测调查和工程审查。
• 2024年4月3日：微软在书面反馈中向Tenable表示此问题不是SSRF漏洞。
• 2024年5月3日：微软在书面反馈中向Tenable表示此问题不是防火墙绕过漏洞。
• 2024年5月10日：微软在Microsoft Learn上公开提供服务标签文档更改。
• 2024年6月3日：微软和Tenable向公众披露此问题。

致谢

我们感谢有机会调查Tenable报告的发现，并感谢他们在微软漏洞赏金计划条款下实践安全安全研究。我们鼓励所有研究人员与供应商合作，遵循协调漏洞披露（CVD），并遵守渗透测试的参与规则，以避免在进行安全研究时影响客户数据。

微软与第三方研究人员和安全社区的其他人有着悠久的合作历史。这反映在我们的安全未来倡议（SFI）中，进一步促进了我们与安全研究人员合作以及回应与我们产品和平台服务相关风险声明的透明度。微软致力于分享我们对研究人员声明的分析，并向客户和社区提供建议。

参考

• 有问题？通过Azure门户在aka.ms/azsupt打开支持案例
• 在Azure服务标签概述 | Microsoft Learn了解更多关于Azure虚拟网络服务标签的信息
• 在Azure安全基础文档 | Microsoft Learn了解更多关于Azure安全基础的信息
• 在Azure Monitor文档 - Azure Monitor | Microsoft Learn了解更多关于Azure Monitor的信息