向第三方开放Azure Function应用的最优认证方案咨询

你当前计划直接共享自有Azure AD租户下应用注册的client_id、client_secret给外部团队的方案存在明显安全隐患，不建议直接落地。这种模式下你对凭据的扩散范围完全没有管控能力，一旦外部分发的密钥泄露，攻击者可以直接获取对应权限的token访问你的受保护资源，且你很难快速区分调用来源、做细粒度的权限吊销。

适配外部团队调用场景的优先落地方案 #

• 首选多租户Azure AD应用 + 外部主体授权模式
  你不需要给外部团队发放你自有租户下的应用凭据，只需要把绑定Function认证的应用注册配置为多租户模式，让外部团队在他们自己的Azure AD租户内自行创建服务主体、自行管理自己的调用凭据。你侧只需要在Function的访问权限配置中，给外部团队对应的服务主体单独授予最小范围的调用权限即可。这种模式下凭据完全由外部团队自行管控，你可以随时在自己的租户侧撤销单个外部主体的访问权限，Azure AD的审计日志也可以精准标记每笔调用对应的外部主体身份，不存在凭据泄露后牵连内部资源的风险。
• 无统一身份源场景前置API Management网关
  如果合作的外部团队没有自己的Azure AD租户，不要直接把Function端点暴露在公网。在Function前挂载Azure API Management作为统一入口，给每个外部团队单独生成专属的订阅密钥，按需配置客户端证书、OAuth2.0、API Key等不同强度的认证方式，同时在网关层直接做调用限流、IP白名单、请求校验、全链路调用审计。单个外部团队的凭据泄露时，你只需要在APIM侧吊销对应订阅密钥即可，完全不需要调整Function本身的认证配置。

最低成本改造方案（沿用现有Azure AD认证框架） #

如果暂时没有资源做上述架构调整，至少对现有方案做以下安全加固：

1. 为外部调用单独创建全新的应用注册，绝对不要复用内部服务正在使用的应用，给这个新应用仅授予Function调用的最小权限，不开放任何其他Azure资源的访问权限
2. 给该应用配置条件访问策略，仅放行外部团队官方出口IP段的token请求和接口调用
3. 配置客户端密钥的自动轮换规则，设置不超过90天的密钥有效期，要求外部团队定期更新凭据
4. 开启Azure AD登录审计和Function的调用日志，全量记录调用主体ID、请求来源IP、调用时间、操作内容，留存至少6个月的日志用于异常溯源

注意：无论用哪种方案，都不要把你自有租户下高权限应用的client_secret直接分发给外部实体，这是Azure身份认证场景下的典型高危操作。

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