ActiveProtect 加 Azure Blob 存储报网络或权限错误？防火墙、专用端点、ABAC 三层排查
痛点场景
ActiveProtect 站点要挂一个 Azure Blob Storage 当远程存储，添加时反复报网络或权限错误：连接串确认没填错，IAM 角色也看着给了，换浏览器重试、重建任务都一样。这种"看起来都对就是不通"的故障，官方知识库给了一套结构化的排查路径。
官方诊断：两束根因
- 网络访问受限：Azure Blob Storage 账户的防火墙正在阻止流量，公共网络访问已关闭，或者专用端点或 DNS 设置不完整；
- 权限尚未完全生效：IAM 角色看起来正确，但 ABAC（基于属性的访问控制）条件、拒绝分配或同步延迟正在阻止访问。
对应"网络四查、权限三查"，走完基本能落点。
网络侧四查
1. 存储账户防火墙：把 APM 加进允许名单
网络访问设置为"从选定网络启用"时，APM 的 IP 地址或 VNet 子网可能不在允许名单中。动作：在 Azure 门户中进入存储账户，选择 安全性 + 网络 > 网络，将 APM 的 IP 或 VNet 子网添加到允许名单。
2. 公共访问禁用后，必须走专用端点
公共网络访问设置为"已禁用"时，APM 只能通过专用端点连接；APM 没有通过专用端点路由，连接就会失败。请确认 APM 和存储账户位于同一 VNet 中，或两者之间存在专用端点连接。
3. DNS 是否真把流量引到了专用 IP
专用端点只有在 DNS 指向它时才生效。在客户端对存储账户的 Blob 域名执行 nslookup：结果应为专用 IP。如果返回的是公共 IP，说明客户端仍在访问公共端点——而公共端点会被防火墙拦截。此时检查 DNS 里是否已为私有链接（privatelink）子域配置了地址记录。
4. 专用端点是否涵盖 Blob
专用端点若是给 Data Lake（而非 Blob 存储）创建的，即使端点存在，Blob 操作也会失败。打开专用端点，检查它连接到了哪些存储类型；Blob 不在其中，就另外创建一个专门用于 Blob 访问的专用端点。
权限侧三查
1. 角色分配上的 ABAC 条件
角色看起来可能是正确的，但仍可能存在某个条件，把它限制为特定前缀、容器、子网或专用链接。动作：存储账户 > 访问控制 (IAM) > 角色分配，找到该应用程序，检查"条件"列，移除任何阻止 APM 访问的条件。
2. 拒绝分配会压过允许角色
拒绝分配会覆盖允许角色。存储账户由 Azure 托管资源或 Deployment Stack 管理时，Azure 可能会自动创建拒绝分配。动作：访问控制 (IAM) > 拒绝分配，检查是否有规则正在阻止应用程序访问数据平面。若有，要通过拥有该资源的 Deployment Stack 或托管服务去更新，而不是直接在 IAM 里改——这是官方明确强调的坑点。
3. 权限同步延迟
新的角色分配可能需要几分钟才能生效；分配角色后立即测试，仍会看到错误。官方口径：分配角色后等待 5-10 分钟再试一次。
排查顺序建议
先网络、后权限——网络不过，权限配得再对也白搭：防火墙允许名单 → 公共访问与专用端点连通 → nslookup 验证解析 → 端点涵盖范围 → ABAC 条件 → 拒绝分配 → 等同步重试。
预防与注意
- 存储账户侧的网络规则变更（开关公共访问、调整防火墙名单）要纳入变更通知范围，与 APM 侧的添加/重试同批执行，避免"两头各自改完互不知情"；
- APM 与存储账户同 VNet 的架构，把专用端点与 DNS 记录一次配齐再添加，比事后逐项补查省一半时间；
- 每次为备份用途新建应用注册/服务主体时，把角色、条件、拒绝分配三项现状截图留档——出错时对照"当时给过什么"，比凭记忆翻 Azure 面板快得多。