如何保护HTTP trigger类型Azure Function安全 仅允许Azure Pipeline调用

选型结论 #

基于Azure AD的客户端凭证流（Client Credential Flow）是该场景的最优实现，完全适配你的需求。你的场景属于典型的无用户参与的服务间调用，正好匹配客户端凭证流的设计适用范围，比自定义静态令牌校验的安全性、可维护性高很多，不需要自行实现令牌签发、校验、轮换、吊销逻辑。

落地实现步骤 #

• 开启Function原生身份防护
  不需要在.NET Function代码里手写令牌校验逻辑，直接启用Azure Function内置的App Service身份验证（俗称Easy Auth），选择Azure AD作为身份提供商，将Function的访问规则设置为「拒绝所有匿名请求」。开启后平台会自动在请求路由到你的业务代码前完成令牌合法性校验，非法请求直接返回401状态码，能避免自行实现校验时容易遗漏的令牌签发者校验、受众校验、过期时间校验、签名校验等逻辑漏洞。
• 配置Pipeline调用身份
  在Azure DevOps中创建关联Azure资源的服务连接（Service Connection），优先选择托管身份模式的服务连接，这种模式不需要你手动生成、存储任何客户端密钥。如果用应用注册类型的服务连接，对应在Function关联的AAD应用中暴露应用类型的API权限，将该权限授予服务连接对应的服务主体即可。
• Pipeline侧调用配置
  在azure-pipeline.yml中通过服务连接自动获取访问令牌，不需要硬编码任何凭据，拿到令牌后作为请求头发起调用即可，参考配置片段：

  - task: AzureCLI@2
    inputs:
      azureSubscription: '你配置的服务连接名称'
      scriptType: 'pscore'
      scriptLocation: 'inlineScript'
      inlineScript: |
        # 自动获取针对目标Function的有效访问令牌
        $accessToken = az account get-access-token --resource "<Function对应AAD应用的客户端ID>" --query accessToken -o tsv
        # 发起带鉴权头的请求
        $dbQueryResult = Invoke-RestMethod -Uri "<你的HTTP Trigger函数地址>" -Headers @{Authorization = "Bearer $accessToken"} -Method Get
        # 后续处理查询结果即可
  

凭据存储最佳实践 #

严禁将任何凭据、令牌明文写入代码仓库、流水线配置文件，对应不同方案的存储要求：

• 采用上述AAD客户端凭证流+托管身份服务连接的方案时，你不需要存储任何静态凭据：服务连接的鉴权信息由Azure DevOps加密存储，运行时自动换取临时令牌，全程不会暴露明文密钥，也不需要手动做密钥轮换。如果暂时用不了托管身份，应用注册的客户端密钥也要存在Azure Key Vault中，通过DevOps的变量组关联Key Vault拉取机密，不要直接存在流水线变量里。
• 如果暂时选择自定义静态令牌的过渡方案，必须将令牌存储在Azure DevOps的机密变量或者Azure Key Vault中，同时配置至少90天一次的自动轮换策略，令牌校验逻辑必须加时间戳、签名校验，避免令牌被篡改。

额外加固建议 #

• 在Function的网络配置中加IP访问限制，仅将Azure DevOps对应组织的出站IP段加入允许列表，就算令牌意外泄露，非信任来源的IP也无法发起调用，增加一层防护。
• 开启Function的访问日志审计，记录所有调用的来源IP、令牌对应的主体信息、请求时间，方便排查异常调用。

为什么不推荐自定义静态令牌方案 #

自定义静态令牌需要自行实现完整的校验、轮换、吊销逻辑，很容易出现校验逻辑遗漏导致的安全漏洞，且静态令牌长期有效，一旦泄露很难第一时间止损，维护成本远高于原生AAD鉴权方案。

内容的提问来源于stack exchange，提问作者Ask