如何识别访问Azure Service Bus的未知请求来源？

这种“幽灵请求”的情况我之前碰过好几次，给你梳理几个能快速定位问题的方向：

1. 先确认诊断日志的配置是否到位 #

有时候日志没抓到全量请求，大概率是配置的问题：

• 检查诊断日志的类别勾选：务必确保勾选了OperationalLogs和RequestLogs，其中RequestLogs是关键——它会记录每一个API请求的细节，包括调用者IP、操作类型、身份信息
• 直接去存储账户查原始日志：诊断日志会以Blob形式存在存储账户的容器里，路径一般是insights-logs-requestlogs/resourceId=/SUBSCRIPTIONS/[你的订阅ID]/RESOURCEGROUPS/[资源组]/PROVIDERS/MICROSOFT.SERVICEBUS/NAMESPACES/[命名空间]/y=xxxx/m=xx/d=xx/h=xx/m=00/PT1H.json，手动打开几个JSON文件看看，说不定Log Analytics还没同步完，原始日志里藏着线索
• 确认日志保留策略：虽然你才12小时，但还是要检查下是不是设置了过短的保留期导致日志被自动删除了

2. 用Azure Monitor指标钻取细节 #

门户概览的请求数太笼统，换用Metrics视图细化分析：

• 选择Requests指标，然后添加维度筛选：Entity Name（定位到具体被访问的队列/主题）、Operation Name（看是发送、接收还是管理类操作）、Response Code（区分是成功请求还是错误探测）
• 如果能定位到具体实体，再查看该实体的专属指标，比如Active Messages有没有异常波动，确认是不是真的有消息在流动

3. 排查访问权限与连接字符串 #

• 检查连接字符串泄露风险：进入Service Bus资源→Shared access policies，查看所有策略，确认有没有非预期的权限规则；同时回忆下现有策略的连接字符串是不是被嵌入在旧代码、配置文件、CI/CD变量里，或者被意外分享给了第三方
• 查看Azure活动日志：在Service Bus资源的Activity log里，筛选过去24小时的操作，看看有没有Regenerate Keys、Update Authorization Rule这类敏感操作，说不定有人改动了权限配置
• 检查托管身份与IAM权限：如果你的Service Bus用了托管身份，去IAM→Role assignments里查看所有拥有访问权限的主体，看看有没有其他Azure资源（比如Function App、Logic Apps、VM）在使用这个身份访问它

4. 排查隐式的自动化服务调用 #

很多时候请求来自你没注意到的自动化工具：

• 检查订阅内的Logic Apps/Automation Accounts：搜索所有Logic App，看看有没有触发条件关联了这个Service Bus的触发器（比如“当有消息到达时”的触发器）
• 检查Azure Functions：查看有没有使用Service Bus触发器的函数，哪怕是测试环境的函数可能在后台运行
• 排查第三方监控工具：如果你用了Azure以外的云管理或监控工具，看看是不是它们在定期探测Service Bus的状态
• 注意：Azure平台本身的健康检查也会产生少量请求，这类请求的源IP一般是Azure内部IP，日志里会有标识

5. 用Network Watcher追踪流量 #

如果以上方法都没线索，试试用Azure Network Watcher抓包：

• 如果你的Service Bus启用了VNet集成，配置Network Watcher的Packet Capture，或者开启NSG Flow Logs记录进出流量
• 分析抓包结果，查看请求的源IP、端口，再反向查询这个IP对应的服务（可以通过Azure门户的IP范围工具或活动日志关联）

最后，要是还是找不到根源，可以临时重新生成所有共享访问密钥——如果请求数明显下降，说明确实是连接字符串泄露；如果没变化，那大概率是Azure内部服务或平台操作导致的。

内容的提问来源于stack exchange，提问作者Morten Nørgaard